클라우드 네트워크

리전, 가용 영역, 엣지

대형 클라우드는 세계를 리전(region)으로 나눈다. 리전은 서울, 도쿄, 버지니아처럼 한 도시권에 모인 데이터센터 묶음이다. 리전 안에는 보통 셋 이상의 가용 영역(Availability Zone, AZ)이 있다. AZ는 전력·냉각·네트워크가 서로 독립된 데이터센터(또는 그 묶음)로, 한 AZ에 정전이나 화재가 나도 다른 AZ는 멀쩡하도록 수 km~수십 km 떨어져 있다. 그러면서도 같은 리전 안의 AZ끼리는 전용 광케이블로 이어져 왕복 지연이 보통 1~2 ms 수준이다. 그래서 서비스를 여러 AZ에 나눠 두고 데이터를 실시간 복제할 수 있다.

리전과 리전 사이는 클라우드 회사가 직접 깔거나 빌린 해저·육상 광케이블로 만든 사설 백본이 잇는다(5장). 공용 인터넷을 거치지 않으므로 혼잡이 덜하고 경로가 안정적이다. 그리고 사용자 가까이에는 수백 곳의 엣지 PoP(Point of Presence)가 있다. 리전보다 훨씬 작은 거점으로, 콘텐츠 캐시(CDN), DNS, 보안 필터, TLS 연결 종료를 맡아 사용자의 첫 접속 지점을 몇 ms 거리로 끌어당긴다.

서버 안의 스위치: 가상화와 네트워크

클라우드 서버 한 대(물리 호스트)에는 여러 고객의 가상 머신(VM)이 함께 산다. VM마다 진짜처럼 보이는 가상 NIC가 있고, 하이퍼바이저 안의 가상 스위치(virtual switch)가 이 가상 NIC들과 물리 NIC 사이에서 이더넷 스위치(6장) 노릇을 한다. 같은 호스트 안의 VM끼리는 패킷이 케이블을 타지 않고 메모리 복사로 오간다. 오픈소스 Open vSwitch(OVS)가 대표적이다.

가상 스위치는 단순히 넘기기만 하지 않는다. 이 패킷이 어느 고객의 어느 가상망 소속인지 확인하고, 방화벽 규칙(보안 그룹)을 검사하고, 다른 호스트로 갈 패킷은 오버레이 헤더로 감싼다. 이 일을 CPU가 다 하면 손님에게 팔 CPU가 줄어든다. 그래서 대형 클라우드는 이 기능을 SmartNIC/DPU(17장) 같은 전용 하드웨어로 옮겼다. AWS의 Nitro 카드가 대표적이다.

컨테이너는 VM보다 가볍게, 운영체제 커널 하나를 여러 앱이 나눠 쓴다. 컨테이너마다 독립된 네트워크 네임스페이스(자기만의 인터페이스·라우팅 테이블)를 받고, 한 쌍으로 이어진 가상 이더넷 케이블(veth)로 호스트의 브리지에 연결된다. 쿠버네티스는 모든 파드(pod)가 고유 IP를 갖고 NAT 없이 서로 통신해야 한다는 규칙만 정하고, 실제 연결은 CNI 플러그인(Calico, Cilium 등)에 맡긴다.

VPC: 내 전용 가상 네트워크 설계하기

VPC(Virtual Private Cloud)는 클라우드 안에 만드는 나만의 사설 네트워크다. 먼저 10.0.0.0/16처럼 사설 주소 범위(7장)를 정하고, 이를 AZ별 서브넷으로 쪼갠다. 다른 고객도 똑같이 10.0.0.0/16을 써도 서로 보이지 않는다. 각 서브넷에는 라우팅 테이블(8장)이 붙는다.

• 퍼블릭 서브넷: 라우팅 테이블에 “0.0.0.0/0(그 밖의 모든 곳) → 인터넷 게이트웨이” 경로가 있는 서브넷. 공인 IP를 붙인 서버가 인터넷과 직접 주고받는다.
• 프라이빗 서브넷: 인터넷 게이트웨이 경로가 없다. 바깥에서 들어올 길이 아예 없다. 안에서 바깥으로 업데이트를 받으러 나갈 때는 퍼블릭 서브넷의 NAT 게이트웨이를 거친다(7장의 집 공유기 NAT와 같은 원리). 나갈 수는 있지만 들어올 수는 없다.

여기에 두 겹의 방화벽이 붙는다. 둘의 차이가 시험에도, 실무 장애에도 자주 나온다.

오버레이: 상자 안에 상자를 한 번 더

고객 A의 VM(10.0.1.5)이 다른 호스트에 있는 같은 고객의 VM(10.0.2.9)에 패킷을 보낸다고 하자. 물리 데이터센터망(20장의 리프-스파인)은 고객의 사설 주소를 모른다. 게다가 고객 B도 똑같은 10.0.1.5를 쓸 수 있다. 해법은 3장의 캡슐화를 한 번 더 하는 것이다. 출발 호스트의 가상 스위치가 VM의 이더넷 프레임을 통째로 새 상자에 넣고, 겉면에 물리 호스트의 IP와 가상망 번호를 적는다. 물리망은 겉 상자만 보고 호스트에서 호스트로 나르고, 도착 호스트가 겉 상자를 벗겨 안쪽 프레임을 VM에게 건넨다.

이렇게 물리망(언더레이(underlay)) 위에 소프트웨어로 그린 가상망을 오버레이(overlay)라 한다. 가장 널리 쓰는 형식이 VXLAN(Virtual eXtensible LAN, RFC 7348)이다. 안쪽 프레임 앞에 8바이트 VXLAN 헤더를 붙이고 UDP(목적지 포트 4789)/IP/이더넷으로 감싼다. VXLAN 헤더의 VNI(VXLAN Network Identifier)는 24비트라 2²⁴ ≈ 1,677만 개의 가상망을 구분한다. VLAN(6장)의 12비트(4,094개)로는 수백만 고객을 감당할 수 없었다. 바깥 UDP 출발 포트는 안쪽 흐름의 해시로 정해, 20장의 ECMP가 오버레이 흐름도 여러 경로에 고르게 나누게 한다. 요즘은 확장 필드를 붙일 수 있는 GENEVE(UDP 6081)도 많이 쓴다.

SDN: 네트워크의 두뇌를 떼어 내기

전통적인 라우터와 스위치는 장비마다 두뇌와 손발을 함께 갖는다. 두뇌인 제어 평면(control plane)이 이웃과 라우팅 정보를 교환해 경로를 계산하고(8장의 OSPF, BGP), 손발인 데이터 평면(data plane)이 그 결과표대로 패킷을 초당 수십억 개씩 넘긴다(17장). 수천 대가 각자 계산하고 각자 설정을 받으니, 네트워크 전체를 한 번에 바꾸기가 어렵다.

SDN(Software-Defined Networking)은 두뇌를 장비 밖으로 꺼내 컨트롤러라는 소프트웨어에 모은다. 컨트롤러는 망 전체 지도를 보고 경로를 계산해 각 스위치의 “일치 → 동작” 표(이 주소면 3번 포트로, 저 포트면 버리기)를 직접 채운다. 2008년 스탠퍼드에서 나온 오픈플로우(OpenFlow)가 그 표를 원격으로 채우는 표준 규약이었다. 구글은 이 방식으로 데이터센터 간 백본(B4)의 링크 사용률을 크게 끌어올렸다고 발표했다.

순수한 중앙 집중 SDN은 컨트롤러가 병목이자 단일 장애점이 될 수 있다. 그래서 오늘날 클라우드는 분산 SDN을 쓴다. 사용자가 콘솔에서 보안 그룹을 바꾸면, 그 “의도”가 복제된 제어 평면 데이터베이스에 기록되고, 관련 호스트 수천 대의 가상 스위치에 몇 초 안에 퍼진다. 물리 스위치는 VXLAN 바깥 IP만 보고 나르는 단순한 IP 패브릭으로 남는다. 마이크로소프트의 VFP, AWS의 Nitro·Hyperplane, 구글의 Andromeda가 이런 구조다. 네트워크가 사실상 거대한 분산 소프트웨어가 된 것이다.

로드 밸런서: 손님을 창구에 나눠 보내기

인기 서비스는 서버 한 대로 감당할 수 없다. 앞에 로드 밸런서(load balancer)를 두어 하나의 주소로 들어온 요청을 뒤의 서버 여러 대에 나눈다. 고장 난 서버는 주기적인 헬스 체크(health check)로 찾아내 명단에서 뺀다.

• L4 로드 밸런서: IP와 포트(전송 계층, 9장)만 보고 TCP/UDP 연결 단위로 나눈다. 내용을 읽지 않아 매우 빠르고, 초당 수백만 연결도 처리한다.
• L7 로드 밸런서: HTTP 요청(10장)을 열어 본다. /api는 API 서버로, /images는 이미지 서버로, 쿠키에 따라 같은 사용자를 같은 서버로 보낼 수 있다. TLS 암호를 대신 풀어 주기도(TLS 종료) 한다. 더 똑똑한 대신 더 많은 계산이 든다.

나누는 방법(알고리즘)도 여러 가지다. 라운드 로빈은 순서대로 한 번씩, 최소 연결은 지금 처리 중인 요청이 가장 적은 서버에, 해시는 클라이언트 IP 같은 값의 해시로 정해 같은 손님이 늘 같은 서버로 가게 한다.

일관된 해싱: 서버가 바뀌어도 덜 흔들리게

캐시 서버나 분산 저장소는 “이 키(사용자 ID, 파일 이름)는 어느 서버에 있나”를 해시로 정한다. 가장 단순한 방법은 hash(키) mod N이다. 그런데 서버가 N대에서 N+1대가 되면 나머지 값이 거의 다 바뀌어 키의 대부분이 다른 서버로 옮겨 간다. 캐시라면 순식간에 거의 모든 캐시가 비어 원본 DB에 요청이 폭주한다.

일관된 해싱(consistent hashing)은 해시 값을 둥근 고리 위의 위치로 본다. 서버도 고리 위에 놓고, 각 키는 시계 방향으로 가다 처음 만나는 서버에 맡긴다. 서버가 하나 늘면 새 서버 바로 앞 구간의 키만 옮겨 가므로, 평균 1/(N+1)만 움직인다. 서버 하나를 고리 여러 곳에 가상 노드로 뿌리면 구간이 고르게 나뉘어 부하 편차도 줄어든다. 아마존 Dynamo, 카산드라, CDN 캐시, 구글의 Maglev 로드 밸런서가 이 아이디어를 쓴다.

가장 가까운 곳에서 답하기: CDN, 애니캐스트, 글로벌 로드 밸런싱

빛이 광섬유에서 1 ms에 약 200 km를 가므로(5장), 서울에서 버지니아 리전까지는 아무리 빨라도 왕복 150 ms를 넘는다. 웹 페이지 하나에 왕복이 수십 번 필요하다면 이 거리만으로 몇 초가 된다. 해법은 사용자 가까이에서 답하는 것이다.

• CDN(10장): 이미지·동영상 같은 정적 콘텐츠를 엣지 PoP에 복사해 두고 가까운 곳에서 준다. 인기 콘텐츠는 90% 이상이 엣지에서 끝난다.
• 엣지 컴퓨팅: 콘텐츠뿐 아니라 짧은 코드(로그인 검사, 이미지 변환, A/B 테스트)를 엣지에서 실행한다. TCP·TLS 연결도 엣지에서 맺으므로, 먼 리전까지 가는 왕복은 백본의 이미 열린 연결로 한 번만 하면 된다.
• 애니캐스트(anycast): 여러 곳의 서버가 같은 IP 주소를 BGP(8장)로 동시에 광고한다. 인터넷 라우팅이 각 사용자를 “가장 가까운”(BGP 기준) 곳으로 자연스럽게 보낸다. 공용 DNS(1.1.1.1, 8.8.8.8)와 루트 DNS 서버, CDN이 이 방식을 쓰며, DDoS 공격도 여러 곳으로 흩어진다.
• 글로벌 로드 밸런싱(GSLB): DNS가 질문한 사용자(또는 그 DNS 리졸버)의 위치를 보고 가장 가까운, 그리고 살아 있는 리전의 주소를 답한다. 리전이 장애 나면 다음 리전 주소를 답하는 페일오버도 DNS로 한다(TTL만큼 지연된다).

회사와 클라우드 잇기, 그리고 비용

대부분의 기업은 자기 데이터센터나 사무실을 클라우드와 함께 쓰는 하이브리드, 또는 여러 클라우드를 함께 쓰는 멀티 클라우드다. 이 둘을 잇는 방법은 크게 두 가지다.

클라우드 네트워크 설계에서 의외로 큰 변수는 돈이다. 대형 클라우드는 보통 데이터가 들어오는 것(ingress)은 무료지만, 인터넷으로 나가는 것(이그레스(egress))에는 GB당 약 0.05~0.09달러 수준의 요금을 매긴다(양이 많을수록 할인). 월 100 TB를 내보내면 수천 달러다. 같은 리전의 AZ 사이, 리전 사이 전송에도 요금이 붙는다. 그래서 CDN으로 엣지에서 응답하고, 통신이 많은 서비스는 같은 AZ에 두고, 데이터를 클라우드 밖으로 자주 옮기지 않도록 설계한다. 데이터를 한 번 넣으면 빼기 비싼 구조가 이른바 “클라우드 종속”의 한 원인으로 지적되기도 한다.