Today Keys : mapping, service, blackfoot, edge, hyperplane, vpc, aws, amazon, nlb, private, endpoint, link, nat, gateway
Amazon VPC를 사용하면서 굳이 몰라도 되지만, 한 번쯤 궁금할 수 있는 이야기를 몇 가지 다뤄보려고 합니다.
이번 포스팅은 그 세 번째이자 마지막 이야기는 'Hyperplane' 입니다.
이번에 다루게 될 주제들에 대해서는 정확한 자료가 오픈 된 것은 아니기 때문에 기존 re:Invent에서 발표된 내용과 동일 주제들도 내용을 다뤘던 글들을 토대로 작성된 내용이라서 제가 다룬 내용이 실제와 다를 수 있습니다. (사실 다를거라고 생각하긴 합니다. )
그럼에도 불구하고 포스팅에서 다뤄보려는 것은 한 3년전쯤 본 주제를 다뤄보려다가 정보의 제한과 두뇌의 제한으로 정리를 하다가 멈췄는 데, 그래도 한 번쯤은 다뤄보고 싶었던 주제라 사실과 조금 다른 점이 있더라도 제가 이해하려고 노력한 부분과 그 안에서 나름의 정리를 해보는 것도 가치가 있을 것 같아서 입니다.
다시 한 번, 얘기 드리지만 상세한 Spec. 기준의 문서 기반이 아니기 때문에 내용의 기술적인 사실성은 실제와 다를 수 있다는 것을 염두해두시고 전체적인 흐름 관점에서 보시면 좋을 것 같습니다.
마지막에는 이번 시리즈를 시작하게 되었던 이유와 그 궁금증에 대한 내용을 간략히 정리해 보았습니다.
첫 번째 이야기 : Mapping Service (바로가기)
두 번째 이야기 : Blackfoot Edge Device (바로가기)
세 번째 이야기 : Hyperplane
AWS HyperPlane는 이번 'Amazon VPC 한 번쯤 궁금한 이야기' 시리즈를 시작하게 만든 키워드입니다.
예전에 정리를 하려고 했던 때도, 이번에 다시 정리를 해보자고 다시 마음을 먹을 때도 그렇고..
정리를 하려다가 말았던 그 때도 그렇고... 지금 정리를 하기 위해서 이런 저런 자료를 보면서 정리하는 지금도..
이렇게 정리하는 것이 맞을까? 에 대한 고민이 들기도 하는 키워드이기도 합니다.
그럼에도 불구하고 내용을 꺼내서 정리해보고자 합니다. ^^;
AWS HyperPlane은 분산 네트워크 패킷 포워딩 시스템이라고 합니다.
Data Flow Status를 인지하고, 포워딩을 하기 때문에 Interal flow control service 라고도 합니다.
초기에는 내부적으로 S3 Load Balancer 역할을 위해서 만들어진 시스템이고,
그 이후에 아래와 같이 HyperPlane을 기반으로 한 서비스들이 계속 출시가 되고 있습니다.
Amazon Elastic Filesystem (2015)
VPC NAT Gateway (2016)
AWS Network Load Balancer (2017)
AWS VPC PrivateLink(2017)
Transit Gateway(2018)
Gateway Load Balancer(2020)
HyperPlane은 매우 큰 메모리를 갖고 있는 EC2 환경을 기반으로 구성되어 있습니다.
AWS 사용자가 사용하는 일반 EC2의 인프라 환경과 동일한 EC2 기반의 환경입니다.
EC2로 구성된 수평적으로 확장이 가능한 대규모 분산 시스템으로,
각 EC2는 5Gbit/s의 대역폭을 가지며, 5Gbit/s씩 Scale-out이 되면서 Terabits 수준까지 확장됩니다.
(기존 자료 기준이기 때문에 현재는 더 확장 가능한 수준 일 수도 있습니다.)
HyperPlane은 Scale 확장을 통해서,
초당 수 억개 새로운 Connection을 연결하며, 초당 수 십 억개의 패킷을 처리하고, 수 십 억개의 Flow를 추적 할 수 있습니다.
게다가 모든 처리 과정은 수십 마이크로초 미만의 지연(Latency)내에서 수행됩니다.
이러한 Latency을 위해서 모든 처리는 메모리에서 수행됩니다.
(앞서 얘기했던 HyperPlane이 매우 큰 메모리를 갖는 EC2 로 구성되는 이유이기도 합니다.)
HyperPlane은 Control Plane과 Data Plane이 각각 독립적으로 분리되어 있으며,
이러한 HyperPlane 구성은 AWS의 가용 영역별로도 독립적입니다.
(따라서, 특정 가용 영역의 장애가 발생하더라도 HyperPlane의 영향은 없습니다.)
HyperPlane은 한 종류의 시스템은 아니며, 3개의 컴포넌트로 구성되어 있으며 이에 대한 대략적인 아키텍처는 다음과 같습니다.
2개의 아키텍처 모두, AWS Slide에서 발췌한 것이며,
각 컴포넌트의 이름은 다르지만, 역할을 볼 때 동일한 컴포넌트를 다르게 부르는 것으로 생각됩니다.
HyperPlane을 구성하는 컴포넌트 역할을 살펴보면 다음과 같습니다.
Top / Packet Processor
- 실제 패킷을 처리하는 곳이며, 수평 확장 가능한 EC2로 구성되어 있습니다.
Flow Master / Flow Tracker
- Connection을 트래킹하여 모든 Flow를 추적하는 중앙 데이터 베이스 역할입니다.
- 대규모 클라우드 환경에서 거대한 Sclale과 Flow Tracking 요건을 기존의 데이터베이스로는 불가하여, 자체 분산 데이터 저장소를 만듬.
Decider / Inteligent, distributed Control Plane
- LB의 Target을 지정하거나, NAT의 Source port를 할당하는 것처럼 각 네트워크 기능 로직을 담당
- HyperScale 환경에 대한 추가 Provisioning 등을 관리합니다.
각각의 컴포넌트는 단일이 아니라 분산된 HyperPlane 노드로 구성되어 있지만,
수십 마이크로초 내에 트랜잭션에 대한 결정을 내리고, 그러한 상태(State)를 공유하여 장애 상황에서도 서비스의 연속성을 보장 할 수 있습니다.
Hyperplane에 대한 Availability에 대해서는 다음과 같이 설계 목표를 갖고 있다고 합니다.
HyperPlane 아키텍처를 설명 할 때, 또 한 가지 빠지지 않는 것이 Shuffle Sharding입니다.
Multi-tenancy 환경에서는 특정 tenant의 이슈가 다른 tenant에 영향을 최소화 할 수 있도록 해야 하는 데,
이를 위해 HyperPlane 노드들은 Shuffle Sharding으로 구성되어 있습니다.
HyperPlane에 대한 기술적인 정리는 이 쯤에서 마무리 하려고 합니다.
하지만, 처음 이 포스팅을 했던 이유와....
몇 년전 처음 이 서비스들에 대해서 관심을 갖게 된.. 내용을 다루지는 못했습니다.
그래서, 마지막 한 가지 내용을 덧 붙이려고 합니다.
지금부터 다루려는 내용은 앞서 다루었던 Mapping Service, Blackfoot Edge Device, HyperPlane이 모두 포함된 그림입니다.
사실 포스팅 하기도 애매할 정도로 정확하지 않은 정보이기는 하지만... 꽤나 고민을 해서 짜본 Flow입니다.
HyperPlane을 사용하는 AWS 서비스 중에 Network Load Balancer에 대한 Flow를 아래와 같이 도식화 해 보았습니다.
Network Load Balancer의 동작 방식을 얘기할 때 Target이 Instace인 경우에는 DSR처럼 동작한다고 합니다.
DSR은 아니지만, 어떻게 DSR처럼 동작을 하는지 하나의 가상 Flow를 따라가 보겠습니다.
|
※ DSR(Direct Server Return)은 명칭 그대로 사용자의 요청이 로드 밸런서를 통해 서버로 유입된 후에 다시 로드 밸런서를 통하지 않고 서버가 사용자에게 직접 응답하는 모드입니다.
- 참고 : IT 엔지니어를 위한 네트워크 입문(서적)
|
다음은 Internet facing으로 구성된 Network Load Balancer에서 외부 User가 서비스를 호출해서 응답 받는 과정에 대한 도식화입니다. 앞서도 얘기했지만, 실제 동작 Flow는 아니며 뇌피셜하게 그려 본 Flow라 실제 내용과 다를 수 있습니다. (아주 많이..)
제가 생각한 Flow를 차례대로 쫓아가 보겠습니다.
1. 인터넷에 있는 User(11.0.0.5)가 NLB(Network Load Balancer)의 공인 IP인 52.0.0.9를 목적지로 들어옵니다.
52.0.0.9는 ZIGI-VPC1에 연결된 IGW에 있기 때문에 해당 IGW로 들어가게 되고, IGW에서는 ZIGI-VPC1에 있는 NLB의 VPC IP인 10.0.0.9로 목적지 IP를 변경합니다.
2. IGW는 VPC에 연결되어 있기 때문에 VPC 내부 IP에 대한 정보 10.0.0.9를 가지고 Mapping Service를 이용해서 10.0.0.9의 위치를 확인 후, 해당 목적지가 A9라는 Host에 있는 것을 확인합니다.
3. 이제 NLB로 들어온 패킷은 적절한 Target을 선정하게 되고, 해당 세션의 정보를 기록하게 됩니다. 그리고 목적지를 NLB IP가 아닌 Target의 IP로 Destination NAT 처리를 합니다.
4. NLB에서 Target의 정보를 가지고 Mapping Service에서 해당 Target의 위치를 확인 후, 해당 Host인 A2로 전달합니다.
5. 목적지까지 전달된, 패킷은 처리 후, 응답을 하게 됩니다. 패킷의 출발지는 NLB가 아니라 최초 User IP이기 때문에 라우팅 테이블에서는 NAT G/W로 던지도록 되어 있지만, A2 호스트의 Virtual Router에서는 기존에 들어온 Connection 정보를 기억하고 있기 때문에 해당 정보를 토대로 다시 Encap 하여 NLB로 전달을 합니다.
6. NLB에서는 다시 응답 패킷의 출발지를 서버가 아닌 NLB의 IP로 Source NAT 처리한 이후에 IGW로 전달하게 됩니다.
7. IGW에서는 출발지 VPC에 대한 Encap 정보를 모두 제거하고, 출발지 IP를 NLB의 VPC IP인 10.0.0.9에서 공인 IP인 52.0.0.9로 변환하여 응답합니다.
이번 시리즈 포스팅은 앞서 얘기한 것처럼 이 Flow가 어떻게 구성되는 알아보기 위해서 시작된 궁금증으로 시작되었습니다.
정리하려다가 말았다가. 다시 한 번쯤 정리를 해보려고 시작했지만. .웬지 사두사미 같은 시리즈인 듯 같은 기분이 들긴하네요..
HyperPlane을 사용하는 NAT Gateway나 Transit Gateway, PrivateLink들도 위와 같이 Flow를 하나씩 만들어 보면서... 이런 Flow로 돌아가면 될까?라는 걸.. 고민해 보았을 때..
제가 그린 Flow상에서는 제법 그럴 법하게... 맞는 것 같았지만... 실제와는 많은 차이가 있으리라 생각되어... NLB에서 Interface Facing만 포스팅에 올려봅니다.
이것으로 'Amazon VPC 한 번쯤 궁금한 이야기'에 대한 포스팅을 진짜로 마무리 해 봅니다.
