Architectural patterns & best practices #1 AWS Network Architecture

AWS의 Solutions Architect인 Arthi Raju가 AWS re:Invent 2020 온라인 행사에서 발표한

'Architectural patterns & best practices for workloads on VMware Cloud on AWS'에 대해 정리해 봅니다.

 

---------------------------------------------------

1편. AWS Network Architecture (이번글)

2편. VMware Transit Connect

3편. Data Storage

---------------------------------------------------

 

일반적으로 고객과 대화를 시작할 때 가장 먼저 묻는 질문은

과연 어떤 네트워크 아키텍처가 나에게 적합한가?(What network Architecture is righr for me?)입니다.

고객은 필요로 하는 사항에 따라 다양한 옵션을 선택하여 구성할 수 있습니다.

 

 

네트워크 아키텍처에 세부사항을 살펴보기에 앞서 AWS의 기본 구성 요소를 알아보겠습니다.

 

AWS는 전세계에 흩어져 있는 물리적인 위치를 뜻하는 Region(지역)이라는 개념을 가지고 있습니다.

각 Region은 다수의 격리된 Availability Zones(AZ)로 구성되어 있으며,

AZ는 AWS의 Region 내에서 이중화된 전원과 네트워크 그리고 연결성을 가진 하나 이상의 개별 데이터센터입니다.

 

Region 내에서 Virtual Private Cloud(VPC)를 구성할 수 있습니다.

VPC는 고객의 워크로드를 위해 직접 생성한 격리된 프라이빗 네트워크 환경으로,

VMware Cloud on AWS의 SDDC 또한 VPC 안에 위치하고 있습니다.

 

이외 살펴볼 네트워크 관련 추가 구성 요소가 더 있습니다.

 

1) NSX edge

NSX edge를 통해 SDDC에 들어오고 나가는 모든 트래픽을 제어할 수 있습니다.

SDDC를 생성하면 NSX Edge는 자동으로 배포됨으로, NSX edge를 직접 생성할 필요는 없습니다.

 

2) Customer Gateway

Customer Gateway는 고객의 On-premise 데이터센터에 위치한 네트워크 장치로,

데이터의 통신을 제어하거나, VPN 연결을 지원하는 방화벽이나 라우터일 수 있습니다.

3) Virtual Private Gateway

Virtual Private Gateway는 VPN이나 Direct Connet의 연결을 통해 외부로부터 AWS의 VPC로 들어오는 연결지점입니다.

 

4) AWS Direct Connect(DX)
AWS Direct Connect는 전용 대역폭을 보장하는 프라이빗 연결 회선으로,

전문 파트너를 통해 1G/10G 또는 다수의 1/10G 연결을 묶어 서비스로 제공되고 있습니다.

DX를 통해 On-premise 데이터센터에서 SDDC로 마이그레이션 할 때,

일관된 네트워크 경로 및 성능을 보장받을 수 있습니다.

 

5) Elastic Network Interface(ENI)
ENI는 EC2 인스턴스를 생성할 때마다 연결되는 가상 네트워크 인터페이스로,

프라이빗 IP 주소, 퍼블릭 IP 주소 및 MAC 주소 등과 같은 속성을 가지고 있습니다.

 

6) AWS Transit Gateway(TGW)

TGW 서비스는 다수의 고객들이 On-premise로부터의 트래픽이나 VPC간 또는 SDDC간 등 다양한 연결시,

라우팅을 제어할 수 있는 중앙집중식 허브를 지원하기 위해 2020년에 새롭게 출시 되었습니다.

 

AWS에 SDDC를 구성하는 아키텍처를 설계할때 가장 먼저 고려해야할 질문은

어떻게 On-premise 데이터센터를 AWS에 위치한 SDDC에 연결할 것인가에 대한 질문입니다.

연결 대상은 하나의 SDDC일 수도 있고 여러 개의 SDDC일 수도 있습니다.

 

첫번째로 On-premise 데이터센터와 다수의 SDDC가 배포된 AWS 리전간 연결할 수 있는 방법은 바로 VPN입니다.

VPN 연결시 구성과 대역폭, 그리고 가용성 부분에 있어서 고려가 필요합니다.

 

1) Layer 3 VPN (Route/Policy)

VPN 연결은 SDDC의 NSX Edge에서 종료되며,

Layer 3 VPN 연결을 통해 경로 기반 또는 정책 기반의 연결을 선택할 수 있습니다.

 

2) Bandwidth Requirements

VPN에서 또하나의 중요한 고려 사항은 대역폭 요구 사항입니다.
VPN 연결은 인터넷을 통해 이루어짐으로 On-premise에서 연결에 사용되는 장비나 ISP에 따라

혹은 NSX edge에서 보내고 받는 트래픽의 양에 따라 대역폭의 제한이 발생할 수 있습니다.

따라서 고객이 SDDC 연결을 위해 VPN을 이용하고자 한다면, 사전에 스트레스 테스트를 수행하는 것을 권장합니다.

 

3) High Availability(HA) requirements

마지막으로 고려되어야할 사항은 고가용성입니다.

만약 On-premise와 SDDC 사이에 단일 VPN 연결이 있다면,

다수의 Customer Gateway와 다수의 VPN 터널을 이용하여 어떻게 HA를 구성할지 고민해야 합니다.

 

 

VPN의 고려사항 중에 대역폭이 핵심 요구 사항이였음으로, 이를 발전시켜 AWS Direct Connect를 구성할 수 있습니다.

 

1) Dedicated Connection and bandwidth

AWS Direct Connect(DX)는 AWS로부터 구매하는 1G 또는 10G의 전용 연결 서비스입니다.

DX 구매시 AWS는 고객에게 승인 통지서를 제공하며,

Equinix나 다른 Level-3의 회선 서비스 제공 업체를 통해 On-premise와 Region 간의 연결을 설정하도록 도와줍니다.

즉 서비스 제공 업체로부터 고객의 On-premise까지의 연결은 Point-to-Point 연결이나 MPLS 링으로 구성될 수 있으며,

AWS는 서비스 제공업체로부터 AWS Region까지의 구매된 대역폭을 보장합니다.

 

2) Cost

다음으로 고려해야 할 사항은 비용입니다.

DX연결은 비용이 발생하며, 사용자는 사용하는 속도에 따라 개별 포트 비용과 데이터 전송 비용을 지불해야 합니다.

데이터 전송 비용은 On-premise 데이터센터에서 Region으로 들어가는 경우에는 청구되지 않으며,

그 반대인 Region에서 On-premise로 전송되는 데이터는 Internet 비용보다는 훨씬 저렴한 비용이 청구됩니다.

 

3) HA requirement

이 구성에서 고가용성을 고려할 경우 단일 장애 지점(SPoF : Single Point of Failure)가 존재함을 고려해야 합니다.

On-premise 데이터센터에서 DX location까지 하나의 DX 회선만을 사용하고 있음으로, 문제가 될 수 있습니다.

 

 

단일 DX 구성시 발생할 수 있는 SPoF를 막기 위해 다수의 DX 회선을 구성하는 것이 권장됩니다.

 

1) HA requirments

다수의 DX 회선을 다수의 DX location에 연결하는 방식으로,

만약 2개의 DX Connection을 가져간다면, SDDC로 연결되는 다수의 인터페이스를 생성해야 합니다.

DX 위치가 여러 개로 분산되어 있음으로 HA에는 전혀 문제가 없습니다.

 

2) Route Priority

이제 route priority를 이용하여 경로간의 우선 순위를 구성해야 합니다.

예를 들어 BGP의 AS-PATH prepending을 사용하여 트래픽에 대해 선호하는 경로의 우선 순위를 지정할 수 있습니다.

 

3) Cost : VPN backup, if needed

고객이 다수의 DX 연결을 원하지 않는 경우에는 VPN을 백업으로 고려할 수 있습니다.

다만, 기존의 사용량에 대한 경로 전환시 애플리케이션에 어떤 영향을 미칠수 있을지 검토해야 합니다.

대부분의 경우 VPN 회선의 경우 DX보다 대역폭이 작은 경우가 대부분이기 때문입니다.

DX 10G를 사용하는 경우 HA를 통해 VPN으로 경로가 변경된다면, 서비스에 영향이 있을 수 있습니다.

 

 

고객이 서로 통신이 필요한 SDDC를 여러개 배포한 경우에는 어떻게 될까요?

각 SDDC에는 이미 NSX Edge가 배포되어 있음으로, 손쉽게 SDDC간에 VPN 연결을 만들기만 하면 됩니다.

다만, 이렇게 연결된 Layer 3 VPN을 이용하여 통신을 하는 경우에는,

NSX edge를 통해 처리되는 다른 일반 트래픽과 함께 사용되며,

호스트 유형이나 처리되는 트래픽의 양에 따라 최대 대역폭의 한계가 있을 수 있습니다.

또한 SDDC가 확장됨에 따라 VPN 연결 수에 제한이 있을 수 있습니다.

 

 

다음으로 SDDC와 사용자의 native VPC간에 연결을 살펴보겠습니다.

수많은 사용자가 native AWS 서비스와의 연결을 위해 native VPC와 연결이 필요하기 때문에

VMware Cloud on AWS를 설계할때부터 서로간의 확실한 연결을 반영하고 자동화해야 했습니다.

 

그 결과 초기에 SDDC가 배포될 때,

새로운 IAM roles를 생성하고, 제한된 특수 권한을 통해 VMware에 접근하는 Cloud Formation 템플릿이 실행됩니다.

또한, 템플릿을 통해 사용자가 선택한 VPC에 Elastic Network Interface(ENI)를 만들고, 

SDDC에서 구동중인 ESXi 호스트에 직접 연결되도록 구성하였습니다.

 

그 결과, i3.metal의 경우 25Gbps의 대역폭을 제공하는 ENI를 통해 프라이빗한 연결을 설정할 수 있습니다.

이는 외부 인터넷 게이트웨이를 사용하지 않고, 외부를 통해서 다시 들어오지도 않는 직접 연결 네트워크입니다.

native VPC와 SDDC 모두 동일한 Region 내에 있어 이러한 직접 연결 네트워크를 제공할 수 있는 것입니다.

또한, ENI를 통한 직접 연결임으로 별도의 Public IP 할당에 대해 고민도 필요 없습니다.

 

기본적으로 SDDC와 동일 Region 내 동일 AZ에서의 통신이라면, ENI를 통하는 경우 별도의 비용이 과금되지 않습니다.만약 동일 Region 내 다른 AZ간의 통신이라면 당연히 AWS의 데이터 전송요금이 과금됩니다.

 

ENI를 통한 아키텍처는 확장성 측면에서 본다면 1:1 연결만 가능한 모델로써,

하나의 SDDC를 여러 VPC에 연결하거나 그 반대로 연결할 수는 없습니다.

따라서 확장성의 고려가 필요한 경우 Transit Gateway를 사용하여 연결합니다.

 

고객에 따라서는 SDDC와 AWS native VPC 간의 VPN 연결도 필요한 경우가 있습니다.

이 경우 SDDC의 Layer 3 VPN을 지원하는 NSX edge와

VPC의 Virtual Private Gateway를 사용하여 VPN 연결을 생성할 수 있습니다.

그럼 다시 VPN 연결임으로 대역폭이 중요한 요구사항이 될 수 있습니다.

따라서 VPN 연결을 통해 통신해야 하는 워크로드들이 필요한 대역폭을 얼마일지 고민해야 합니다.

AWS의 Virtual Private Gateway의 대역폭은 1.25Gbps이며, NSX edge의 경우 호스트 유형에 따라 달라질 수 있습니다.

VPN 구성시는 대역폭에 대한 고민이 필수입니다.

 

고가용성(HA)의 경우 다수의 VPN 연결을 생성하면 해결 됩니다.