멀티호밍
고친 사람 github-actions[bot]
멀티호밍은 네트워크로 나가는 길을 두 갈래 이상 열어 둡니다. 한 갈래가 끊겨도 남은 갈래로 통신을 이어 가려는 것입니다. 이 말은 두 규모에서 씁니다. 컴퓨터 한 대가 회선 둘을 무는 것도, 회사가 인터넷을 두 통신사에서 받는 것도 멀티호밍입니다.
쉽고 빠른 이해
멀티호밍은 기계나 망 하나를 네트워크에 여러 회선으로 붙이는 구성입니다. 서버 한 대가 서비스용 망과 관리용 망에 동시에 붙어 있으면 그 서버는 멀티호밍한 상태입니다.
이게 없으면 회선 하나가 끊기는 순간 바깥과의 통신이 전부 끊깁니다. 케이블 한 가닥이나 통신사 한 곳이 서비스 전체를 멈출 수 있습니다.
어떻게 도나:
- 회선마다 따로 주소를 받습니다
- 내보낼 때마다 어느 회선, 어느 주소로 나갈지 고릅니다
- 한 회선이 죽으면 남은 회선으로 보냅니다
대가가 있습니다. 회선과 장비를 하나 더 유지해야 합니다. 어느 길로 나가고 들어올지를 맞추는 설정이 복잡해집니다.
회선이 둘이어도 이미 맺은 연결이 저절로 옮겨 가지는 않습니다. 연결은 맺을 때 쓴 주소로 구별됩니다. 그래서 그 주소가 달린 회선이 죽으면 연결도 같이 끊겨 다시 맺어야 합니다.
끊겼을 때 잃는 것이 회선 하나의 비용보다 클 때 씁니다. 서버를 클라우드에 올려 회선을 남이 챙기면 직접 멀티호밍을 꾸릴 필요가 줄어듭니다.
상세
이 절은 멀티호밍을 두 규모로 나눠 봅니다. 먼저 컴퓨터 한 대가 주소를 여럿 가질 때 무엇이 달라지는지 봅니다. 그다음 연결이 주소에 묶여서 생기는 문제와 그것을 푸는 전송 프로토콜을 봅니다.
마지막으로 회사 망 전체를 두 통신사에 잇는 경우를 봅니다.
비유로 보는 멀티호밍
집에 문이 둘 있으면 앞문 앞에서 공사가 벌어져도 뒷문으로 드나들 수 있습니다. 대신 손님에게 어느 문으로 오라고 알려 줘야 합니다. 택배 기사가 앞문 주소만 알고 있으면 앞문이 막힌 날 물건이 오지 않습니다.
멀티호밍이 문을 하나 더 내는 일입니다. 그리고 이 편의 대부분은 손님에게 어느 문을 알려 줄지, 막힌 문 대신 다른 문으로 어떻게 오게 할지의 문제입니다.
회선 하나가 곧 단일 장애점
서버가 네트워크에 붙는 길이 하나뿐이면 그 길이 끊길 때 서버도 바깥에서 사라집니다. 케이블이 빠지든 스위치가 죽든 통신사 회선이 끊기든 결과는 같습니다. 혼자 죽어서 전체를 멈추는 이런 지점이 단일 장애점입니다.
멀티호밍은 이 길을 하나 더 냅니다. 길이 둘이면 하나가 끊겨도 바깥과 닿을 수 있습니다. 장애가 나도 서비스를 이어 가게 하는 성질을 고가용성이라고 합니다. 멀티호밍은 그 성질을 네트워크 연결 쪽에서 챙기는 방법입니다.
길을 늘리는 이유가 장애만은 아닙니다. 두 회선으로 트래픽을 나눠 보내면 한 회선이 감당할 양이 줄어듭니다. 서비스용 회선과 관리용 회선처럼 회선마다 맡는 일을 달리 두기도 합니다.
주소를 여럿 가진 컴퓨터
네트워크에 붙어 통신하는 컴퓨터 하나를 호스트라고 합니다. 호스트가 네트워크에 닿는 접점은 네트워크 인터페이스입니다. 유선 랜 카드 하나, 와이파이 장치 하나가 각각 인터페이스입니다.
IP(Internet Protocol, 인터넷 프로토콜) 주소는 호스트가 아니라 이 인터페이스에 붙습니다. 그래서 인터페이스가 둘인 호스트는 IP 주소도 둘 이상 가집니다. 이런 호스트를 멀티홈드 호스트(multihomed host)라고 부릅니다.
flowchart TD
subgraph H["서버 한 대"]
E1["인터페이스 1 · 주소 A"]
E2["인터페이스 2 · 주소 B"]
end
E1 --> N1["서비스용 망"]
E2 --> N2["관리용 망"]
그림의 서버는 한 대지만 바깥에서 보이는 주소는 둘입니다. 서비스용 망에서는 주소 A 로, 관리용 망에서는 주소 B 로 이 서버를 찾아옵니다.
백엔드 서버에서 흔한 꼴이 이 그림입니다. 사용자의 요청은 서비스용 망으로 받습니다. 운영자의 접속과 모니터링, 백업은 관리용 망으로 돌립니다. 두 종류의 트래픽이 서로의 회선을 잡아먹지 않게 됩니다.
나갈 길을 고르는 일
주소가 하나뿐인 호스트는 고민할 것이 없습니다. 모든 패킷이 그 인터페이스로 나갑니다. 주소가 둘이 되면 패킷을 보낼 때마다 두 가지를 정해야 합니다. 어느 인터페이스로 내보낼지와 보낸 쪽 주소를 무엇으로 적을지입니다.
첫째는 라우팅 테이블이 정합니다. 라우팅 테이블은 목적지 주소의 범위마다 어느 인터페이스로 내보낼지를 적어 둔 표입니다. 호스트는 목적지를 이 표에 맞춰 보고 나갈 인터페이스를 고릅니다.
둘째는 출발지 주소 선택입니다. 패킷에는 보낸 쪽 주소가 적힙니다. 받은 쪽은 그 주소를 향해 답장을 보냅니다. 그래서 어느 주소를 적느냐가 답장이 어느 길로 돌아올지를 정합니다.
이 둘이 어긋나면 문제가 생깁니다. 주소 A 를 적은 패킷을 인터페이스 2 로 내보내면 답장은 주소 A 를 찾아 인터페이스 1 쪽으로 돌아옵니다. 나간 길과 들어온 길이 다른 이 상태가 비대칭 라우팅입니다.
비대칭 라우팅은 중간 장비에 막히기 쉽습니다. 앞의 예에서 인터페이스 1 쪽 방화벽은 나간 패킷을 본 적이 없습니다. 패킷은 인터페이스 2 쪽으로 나갔기 때문입니다. 그래서 돌아온 답장을 모르는 연결의 것으로 보고 버릴 수 있습니다.
통신사 쪽에서도 걸립니다. 통신사는 자기 망의 주소가 아닌 출발지를 단 패킷을 위조로 보고 버리기도 합니다. 이렇게 거르는 일을 인그레스 필터링이라고 합니다.
라우터와 닮은 고민
길을 고르는 일은 원래 라우터의 몫입니다. 라우터는 여러 망 사이에 서서 패킷마다 다음에 보낼 곳을 정하는 장비입니다. 멀티홈드 호스트는 그 고민 일부를 스스로 떠안습니다. 자기가 보내는 패킷을 어느 망으로 내보낼지 직접 판단해야 하기 때문입니다.
그렇다고 라우터가 되는 것은 아닙니다. 인터페이스가 둘이어도 한쪽으로 들어온 남의 패킷을 다른 쪽으로 넘겨주지는 않습니다. 남의 패킷을 넘겨주는 패킷 전달은 그 기능을 따로 켤 때만 합니다.
듣는 주소와 나가는 주소
소켓은 프로그램이 네트워크로 데이터를 주고받는 통로입니다. 서버 프로그램은 요청을 받기 전에 소켓을 주소와 포트에 묶어 둡니다. 이렇게 묶는 일을 바인드라고 합니다. 멀티홈드 호스트에서는 어느 주소에 묶느냐로 요청을 받는 범위가 달라집니다.
모든 주소에 묶으면 어느 인터페이스로 들어온 요청이든 받습니다. 한 주소에만 묶으면 그 주소로 들어온 요청만 받습니다. 관리용 화면을 관리용 망 주소에만 묶어 두면 서비스용 망 쪽에서는 그 화면에 닿을 수 없습니다.
나가는 연결도 주소를 탑니다. 서버가 데이터베이스에 연결을 맺을 때 출발지 주소를 정하지 않으면 운영체제가 라우팅 테이블을 보고 고릅니다. 데이터베이스 쪽 방화벽이 특정 주소만 허용하고 있으면 다른 주소로 나간 연결은 막힙니다. 그래서 소켓을 원하는 주소에 먼저 묶은 뒤 연결을 맺기도 합니다.
주소에 묶인 연결
주소를 여럿 가져도 연결 하나가 그 주소들을 다 쓰는 것은 아닙니다. TCP(Transmission Control Protocol, 전송 제어 프로토콜) 연결은 네 값으로 구별됩니다. 내 주소, 내 포트, 상대 주소, 상대 포트입니다.
이 넷 가운데 하나라도 바뀌면 다른 연결이 됩니다. 그래서 주소 A 로 맺은 연결은 주소 A 가 달린 회선이 끊기면 같이 끝납니다. 주소 B 가 살아 있어도 그 연결을 B 로 옮겨 붙일 방법이 없습니다. 응용 프로그램이 연결을 새로 맺어야 합니다.
그래서 멀티홈드 호스트만으로는 반쪽입니다. 새로 맺는 연결은 살아 있는 회선으로 갈 수 있습니다. 이미 맺어 둔 연결은 회선과 운명을 같이합니다. 휴대폰이 와이파이에서 모바일 데이터로 넘어갈 때 통화나 다운로드가 끊겼다 다시 붙는 일이 이 때문에 생깁니다.
연결 하나에 주소 여럿을 매다는 전송 프로토콜
이 반쪽을 메우려고 전송 계층에서 멀티호밍을 품은 프로토콜이 있습니다. 전송 계층은 두 프로그램 사이의 연결을 맡는 네트워크 계층입니다. 이 프로토콜들은 연결 하나에 주소를 여럿 매달아 둡니다.
SCTP(Stream Control Transmission Protocol, 스트림 제어 전송 프로토콜)는 처음부터 멀티호밍을 염두에 두고 만든 프로토콜입니다. SCTP 는 연결을 결합(association)이라고 부릅니다. 결합을 열 때 양쪽이 자기가 쓸 수 있는 주소 목록을 서로 알려 줍니다.
보내는 쪽은 상대 주소 가운데 하나를 주 경로로 정해 평소에 씁니다. 나머지 주소는 하트비트로 살펴 둡니다. 하트비트는 짧은 확인 메시지를 일정한 간격으로 보내 상대가 살아 있는지 보는 방법입니다.
주 경로로 보낸 데이터가 거듭 응답을 못 받으면 그 경로를 죽었다고 봅니다. 그러면 살아 있는 다른 주소로 다시 보냅니다. 결합은 끊기지 않습니다.
sequenceDiagram
participant S as 보내는 쪽
participant P1 as 받는 쪽 주소 1
participant P2 as 받는 쪽 주소 2
S->>P1: 데이터
P1-->>S: 받았다
S->>P2: 하트비트
P2-->>S: 살아 있다
Note over P1: 이 주소의 회선이 끊긴다
S->>P1: 데이터
Note over S: 답이 없다. 다시 보내도 답이 없다
S->>P2: 같은 데이터를 다시 보낸다
P2-->>S: 받았다
그림에서 결합은 한 번도 다시 맺어지지 않았습니다. 주소 2 가 살아 있다는 것을 하트비트로 미리 확인해 둔 덕에 바로 옮겨 갈 수 있었습니다. 기본 동작에서 SCTP 는 주소가 여럿이어도 한 번에 한 경로로만 보냅니다. 나머지 경로는 예비입니다.
MPTCP(Multipath TCP, 다중 경로 TCP)는 TCP 를 넓힌 것입니다. 응용 프로그램에는 평범한 TCP 연결 하나로 보입니다.
그 밑에서는 내 주소 하나와 상대 주소 하나로 된 짝마다 작은 TCP 연결을 하나씩 엽니다. 이 작은 연결 하나하나를 서브플로(subflow)라고 합니다. 데이터는 이 서브플로들에 나눠 싣습니다.
QUIC은 UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜) 위에서 도는 전송 프로토콜입니다. UDP 는 연결을 맺지 않고 패킷을 그냥 보내는 단순한 프로토콜입니다. QUIC 은 그 위에 연결을 스스로 꾸립니다.
QUIC 은 연결을 주소가 아니라 연결 ID 로 구별합니다. 연결 ID 는 연결을 맺을 때 정해 두는 식별 번호입니다. 그래서 휴대폰의 주소가 바뀌어도 같은 연결 ID 를 들고 오면 연결이 이어집니다. 이렇게 옮겨 가는 것을 연결 이전이라고 합니다.
셋은 연결을 묶는 방법도, 경로를 쓰는 방법도 다릅니다.
| 프로토콜 | 연결을 무엇으로 묶나 | 경로를 동시에 쓰나 |
|---|---|---|
| SCTP | 결합 하나에 양쪽 주소 목록을 매단다 | 아니다. 주 경로 하나에 나머지는 예비 |
| MPTCP | 겉의 연결 하나 밑에 주소 짝마다 서브플로를 연다 | 그렇다. 데이터를 나눠 싣는다 |
| QUIC | 주소가 아니라 연결 ID | 아니다. 주소가 바뀌면 옮겨 간다 |
표의 가운데 칸이 공통점을 말합니다. 셋 다 연결을 주소 한 짝에서 떼어 냈습니다. 그래서 회선 하나가 죽어도 연결은 남습니다.
셋 가운데 SCTP 는 주소를 바꿔치기하는 장비와 부딪힙니다. NAT(Network Address Translation, 네트워크 주소 변환)는 안쪽의 사설 주소를 바깥의 공인 주소로 바꿔 내보내는 장비입니다.
SCTP 가 결합을 열 때 알려 준 주소 목록은 보내는 쪽이 자기 주소로 아는 값입니다. NAT 를 지나면 바깥에서 보이는 주소가 달라집니다. 상대가 목록의 주소로 보내면 닿지 않습니다.
QUIC 은 이 문제를 덜 겪습니다. 연결을 주소가 아니라 연결 ID 로 찾기 때문입니다. NAT 가 바깥 주소를 바꿔도 같은 연결 ID 가 오면 같은 연결로 알아봅니다.
통신사 둘에 잇는 회사 망
지금까지는 컴퓨터 한 대의 이야기였습니다. 같은 말을 망 하나에도 씁니다. 회사나 데이터센터가 인터넷 회선을 두 통신사에서 받는 것도 멀티호밍입니다.
인터넷 회선을 파는 통신사를 ISP(Internet Service Provider, 인터넷 서비스 제공자)라고 합니다. 회사 망과 바깥이 맞닿는 곳에는 경계 라우터를 둡니다. 경계 라우터가 두 ISP 의 회선을 함께 뭅니다.
flowchart TD
subgraph C["회사 망"]
S["서버들"] --> R["경계 라우터"]
end
R --> A["ISP A"]
R --> B["ISP B"]
A --> I["인터넷"]
B --> I
나가는 길은 쉽습니다. 경계 라우터가 살아 있는 회선으로 내보내면 됩니다.
어려운 쪽은 들어오는 길입니다. 바깥의 클라이언트는 회사의 주소만 압니다. 그 주소로 가는 길이 두 ISP 양쪽에 있다는 사실을 인터넷 전체가 알아야 합니다.
방법은 크게 둘입니다. 하나는 회사가 자기 주소 블록을 갖고 두 ISP 에 모두 알리는 것입니다. 주소 블록은 연달아 붙은 주소를 한 덩어리로 묶은 범위입니다. 어느 ISP 에도 매이지 않은 이런 주소를 공급자 독립 주소라고 합니다.
알리는 데는 BGP(Border Gateway Protocol, 경계 게이트웨이 프로토콜)를 씁니다. BGP 는 망과 망이 서로 「이 주소로 가려면 나를 거쳐라」를 주고받는 프로토콜입니다.
이때 회사 망은 자율 시스템 하나로 나섭니다. 자율 시스템은 한 조직이 운영하는 망 덩어리입니다. 경로를 주고받을 때 하나의 단위로 다뤄집니다. 이 단위를 가리키려고 자율 시스템마다 번호를 받습니다.
한 회선이 끊기면 그쪽으로 낸 알림이 사라집니다. 인터넷의 라우터들은 남은 ISP 쪽 길로 경로를 바꿉니다. 클라이언트는 같은 주소로 계속 찾아옵니다.
다른 하나는 ISP 마다 그 ISP 의 주소를 받아 쓰는 것입니다. 이런 주소를 공급자 할당 주소라고 합니다. 회사는 주소 묶음을 두 벌 갖게 됩니다. 바깥에는 DNS(Domain Name System, 도메인 네임 시스템) 이름 하나에 두 벌의 주소를 함께 올려 둡니다.
이 방식에서는 ISP A 의 주소를 단 패킷이 ISP A 회선으로 나가야 합니다. 반대 회선으로 나가면 앞의 인그레스 필터링에 걸립니다. 그래서 경계 라우터가 NAT 를 겸하는 경우가 많습니다. 나가는 회선에 맞는 주소로 바꿔 내보내는 것입니다.
두 방법을 나란히 놓으면 이렇습니다.
| 방법 | 바깥에서 보이는 주소 | 회선 하나가 끊기면 | 갖춰야 할 것 |
|---|---|---|---|
| 자기 주소를 BGP 로 알리기 | 하나 | 경로가 남은 ISP 쪽으로 바뀐다 | 자기 주소 블록 · 자율 시스템 번호 · BGP 운영 |
| ISP 마다 주소 받기 | ISP 수만큼 | 죽은 쪽 주소를 DNS 에서 내리고 클라이언트가 기억한 답이 바뀌기를 기다린다 | 주소 두 벌 · 나가는 회선에 맞춘 주소 변환 |
첫 줄은 클라이언트 쪽에서 보면 아무것도 바뀌지 않습니다. 대신 준비할 것이 많습니다.
둘째 줄은 준비가 가볍습니다. 대신 클라이언트가 들고 있는 옛 주소가 사라질 때까지 일부 요청이 죽은 쪽으로 갑니다. 클라이언트는 DNS 에서 받은 답을 한동안 기억해 두고 그 주소를 계속 쓰기 때문입니다.
첫 줄에는 인터넷 전체가 치르는 비용도 있습니다. ISP 에게서 받은 주소는 그 ISP 의 큰 주소 블록 안에 들어 있습니다. 그래서 바깥에는 ISP 의 블록 한 줄로만 알려집니다.
자기 주소 블록은 어느 ISP 의 블록에도 들어가지 않습니다. 그래서 전 세계 라우터의 라우팅 테이블에 따로 한 줄이 됩니다. 이런 망이 늘수록 라우터가 들고 있어야 할 표가 커집니다.
길이 둘이라 드는 비용
가장 먼저 드는 비용은 회선과 장비입니다. 평소에는 덜 쓰는 회선을 하나 더 사서 유지해야 합니다. 방화벽 규칙과 라우팅 설정도 두 벌이 됩니다.
설정이 어긋나면 장애가 생깁니다. 비대칭 라우팅이나 엉뚱한 출발지 주소는 평소에는 드러나지 않습니다. 한 회선이 죽어 트래픽이 다른 쪽으로 몰리는 날에야 터지는 경우가 많습니다.
넘어가는 데도 시간이 듭니다. 회선이 죽었다는 것을 알아채려면 하트비트가 몇 번 빠지거나 BGP 알림이 사라져야 합니다. 그동안 보낸 데이터는 다시 보내거나 잃습니다.
두 회선이 같은 길로 지나면 길을 둘로 낸 보람이 없습니다. 두 회선이 같은 건물 입구, 같은 관로를 지나면 굴착 공사 한 번에 둘 다 끊깁니다. 같은 통신사의 회선 둘도 그 통신사가 통째로 멈추면 함께 멈춥니다.
멀티호밍을 쓸 만한 경우
네트워크가 끊겼을 때 잃는 것이 회선 하나의 비용보다 클 때 씁니다. 바깥과 늘 닿아 있어야 하는 서비스, 데이터센터, 회사의 인터넷 출구가 그렇습니다. 휴대폰처럼 와이파이와 모바일 데이터를 오가는 기기도 멀티호밍을 씁니다.
회선을 직접 관리하지 않는 서비스는 이 고민을 회선을 파는 쪽에 맡깁니다. 서버를 데이터센터나 클라우드에 올리면 그쪽 망이 이미 여러 통신사에 이어져 있는 경우가 많습니다. 이때 서비스가 챙길 것은 회선이 아니라 서버 쪽 이중화입니다.
헷갈리는 구성이 하나 있습니다. 같은 스위치에 케이블 두 가닥을 꽂아 하나처럼 묶어 쓰는 것은 링크 집계입니다. 주소도 하나이고 붙는 망도 하나입니다. 그래서 보통 멀티호밍이라 부르지 않습니다. 케이블이나 랜 카드 하나가 죽는 것은 막아도 그 스위치나 망이 죽는 것은 못 막습니다.
관련 항목
멀티호밍이 지키려는 성질
고가용성 · 단일 장애점 · 이중화 · 내결함성 · 페일오버
호스트가 여러 주소를 다루는 데 쓰는 구성 요소
호스트 · 네트워크 인터페이스 · IP 주소 · 경로표 · 기본 게이트웨이 · 출발지 주소 선택 · 소켓 · 바인드 · 리슨 · 소켓 주소 · 포트
연결 하나에 주소 여럿을 매다는 전송 프로토콜
SCTP · MPTCP · QUIC · TCP · UDP · 전송 계층 · 연결 이전 · 하트비트
회사 망을 여러 통신사에 잇는 라우팅 수단
BGP · 자율 시스템 · ISP · 공급자 독립 주소 · 공급자 할당 주소 · 경계 라우터 · 라우팅 · 라우터 · DNS
멀티호밍과 부딪히는 장비와 현상
비대칭 라우팅 · 인그레스 필터링 · NAT · 방화벽 · 상태 기반 방화벽 · 패킷 전달
멀티호밍과 혼동되는 다른 이중화 수단
링크 집계 · 애니캐스트 · 로드 밸런서 · 가상 IP
다른 이름: multihoming · multi-homing · 멀티홈 · 멀티홈드 호스트 · multihomed host