Today Keys : mapping, service, blackfoot, edge, hyperplane, vpc, aws, amazon, nlb, private, endpoint, link, nat, gateway
Amazon VPC를 사용하면서 굳이 몰라도 되지만, 한 번쯤 궁금할 수 있는 이야기를 몇 가지 다뤄보려고 합니다.
이번 포스팅은 그 첫 번째 이야기로 'Mapping Service' 입니다.
앞으로 다룰 주제도 마찬가지이지만, 이번에 다루게 될 주제들에 대해서는 정확한 자료가 오픈 된 것은 아니기 때문에 기존 re:Invent에서 발표된 내용과 동일 주제들도 내용을 다뤘던 글들을 토대로 작성된 내용이라서 제가 다룬 내용이 실제와 다를 수 있습니다. (사실 다를거라고 생각하긴 합니다. )
그럼에도 불구하고 포스팅에서 다뤄보려는 것은 한 3년전쯤 본 주제를 다뤄보려다가 정보의 제한과 두뇌의 제한으로 정리를 하다가 멈췄는 데, 그래도 한 번쯤은 다뤄보고 싶었던 주제라 사실과 조금 다른 점이 있더라도 제가 이해하려고 노력한 부분과 그 안에서 나름의 정리를 해보는 것도 가치가 있을 것 같아서 입니다.
다시 한 번, 얘기 드리지만 상세한 Spec. 기준의 문서 기반이 아니기 때문에 내용의 기술적인 사실성은 실제와 다를 수 있다는 것을 염두해두시고 전체적인 흐름 관점에서 보시면 좋을 것 같습니다.
Amazon VPC 한 번쯤 궁금한 이야기
첫 번째 이야기 : Mapping Service
두 번째 이야기 : Blackfoot Edge Device (바로가기)
세 번째 이야기 : Hyperplane (작성 중)
Amazon VPC를 사용해서, 가상 네트워크를 만들면 아래와 같은 구성이 됩니다.
물리 Host 내의 다수의 VPC가 존재 할 수 있고, 각 VPC 간에는 독립적인 구성이 됩니다.
각 VPC 간은 논리적으로 독립적인 환경이기 때문에 ZIGI-VPC1과 ZIGI-VPC2 처럼 서로 다른 IP 주소 대역(CIDR)을 사용하는 것 뿐 아니라, ZIGI-VPC1과 ZIGI-VPC3 간의 동일한 IP 주소 대역도 사용 할 수 있습니다.
하나의 VPC는 여러 물리 Host로 나뉘어 위치하기도 합니다.
서로 다른 Host에 위치한 ZIGI-VM1과 ZIGI-VM3은 논리적으로 같은 네트워크이기 때문에 서로 간의 통신이 됩니다.
그럼 서로 물리적으로 서로 다른 Host에 위치한 ZIGI-VPC1의 ZIGI-VM1과 ZIGI-VM3은 어떻게 통신이 가능할까요?
바로 다음과 같이 VPC에 대한 정보를 Encapulation하고, 통신하고자 하는 물리 Host IP 정보를 하여 전송을 하게 됩니다.
그럼 이러한 VPC Encapsulation, 물리 Host IP 정보를 어떻게 알 수 있을까요?
이러한 정보를 얻기 위해서, Mapping Service 라는 것이 있습니다.
Mapping Service를 이용해서, 내가 통신하고자 하는 목적지 VM이 어느 Host에 있는지 알 수 있습니다.
예전 re:Invent에서 다뤄졌던 내용에서는 Mapping Service를 아래와 같이 설명합니다.
가볍게 구글 번역기를 손을 빌려서 첫 번째 문장을 해석하면,
"고객의 VPC 경로와 IP 및 물리적 대상 간의 매핑을 처리하는 분산 웹 서비스입니다."
즉, 서로 다른 Host 간의 위치한 서비스들이 통신 할 수 있도록 필요한 정보를 갖고 요청 시에 이러한 정보를 Mapping하여 제공해주는 서비스입니다.
그럼 이러한 정보를 Host에서 어떻게 얻어내고, 얻어낸 정보를 어떻게 Encap. 해서 통신을 할까요?
이러한 역할을 위해서 각 물리 호스트에는 가상 라우터가 존재합니다.
예전에는 이러한 가상 라우터가 Hypervisor 내에 S/W적으로 있었고, 현재는 Nitro Card(H/W)에서 가상 라우터 역할을 하고 있습니다.
지금까지의 내용을 정리하면 아래와 같이 정리될 수 있습니다.
그럼 VPC Encap. 에는 어떤 정보가 들어가 있을까요?
마찬가지로 re:Invent에서 다뤄졌던 내용을 보면,
가장 바깥쪽에는 실제 물리 호스트를 식별하기 위한 정보가 붙게 되고,
Encap 시에, VPC와 ENI에 대한 정보가 포함된다는 것을 볼 수 있습니다.
(물론 앞서 얘기한 것처럼 실제 어떻게 Encap.이 되는지에 대한 상세 정보는 알 수가 없었습니다.
그리고, 이러한 정보를 앞서 얘기한 Mapping service를 통해서 알 수 있는 것이죠.
그렇다면, Mapping Service에는 어떤 정보들이 들어가 있는 것일까요?
안타깝게도 정확한 정보를 찾을 수는 없었지만, 대략적으로 아래와 같은 정보들이 있지 않을까 생각됩니다.
하나의 Host에 다수의 VPC가 혼재되어 있기 때문에 어떤 VPC인지를 구분하기 위한 VPC 구분자와 VPC 내에서 통신하고자 하는 Resource에 대한 ID 값(ex. ENI ID), 그리고 Instance와 같은 서비스 내에서 통신하기 위해 필요한 Elastic Network Interface의 IP 주소, MAC주소, 실제 물리 Host 간의 통신을 위한 물리 Host IP 주소입니다.
Mapping Service가 갖고 있는 정보를 포함해서 다시 앞의 구성을 그려보면 아래와 같습니다.
이러한 Mapping Service를 통한 Encap. Decap. 의 과정은 사용자가 볼 수 없는 뒤에서 일어나는 과정이기 때문에 내용을 볼 수 없겠지만, Mapping Service가 활용되고 있다는 것을 추측 할 수 있는 예시를 한 가지 살펴 보는 것으로 첫 번째 포스팅을 마무리 지으려 합니다.
다음과 같이 ZIGI-VPC1에 ZIGI-VM1과 ZIGI-VM2가 있습니다.
서로 통신이 이뤄진 적이 없었다는 전제 하에,
이제 ZIGI-VM1(148)에서 ZIGI-VM2(185)으로 Ping을 보내고, 응답을 받습니다.
해당 통신 과정의 패킷을 ZIGI-VM1과 ZIGI-VM2에서 모두 tcpdump로 확인해 봅니다.
동일 네트워크에서는 통신하고자 하는 목적지 MAC 주소를 모를 경우에 ARP를 이용해서 목적지 IP 주소에 대한 MAC 주소를 확인하게 됩니다.
ZIGI-VM1(148)에서 ZIGI-VM2(185)에 대한 목적지 MAC 주소를 모르기 때문에 , IP 주소 10.0.0.185에 대한 ARP Request를 보내고,
ARP Reply를 받은 이후에 ICMP Request 보내고 ICMP Reply를 응답 받습니다.
이는 일반적인 통신 흐름입니다.
ZIGI-VM1에서 확인한 통신 흐름으로 보면, ZIGI-VM2에서도 ARP Request를 수신 받은 이후에 ARP Reply를 보내고,
ZIGI-VM1에서 ICMP Request를 수신한 다음 ICMP Replay를 보내야 합니다.
하지만, ZIGI-VM2(185)에서 확인해 보면, ICMP에 대한 Request가 먼저 수신됩니다.
이후에 ZIGI-VM1(148)의 IP 주소인 10.0.0.148에 대한 ARP Request를 보내고 ARP Reply를 받습니다.
마지막으로 ZIGI-VM1에서 보낸 ICMP에 대한 Reply를 보냅니다.
Amazon VPC에서는 Broadcast가 지원되지 않기 때문에, Broadcast를 사용하는 기존 On-Premises의 ARP 동작 방식이 그대로 사용되지 않습니다. ARP Request에 대해서 Virtual Router에서 Mapping Service에 대신 요청하고 응답을 받아서 ARP Reply를 보내는 것입니다.
이를 정리하면 다음과 같습니다.
