[reinvent 2024] 하이브리드 환경을 위한 탄력적인 연결 구축
Summary
고객은 AWS와 온프레미스 시설 간에 리소스를 분할하여 미션 크리티컬 애플리케이션을 운영하는 경우가 많습니다. 이러한 애플리케이션의 가용성은 하이브리드 연결의 복원력에 따라 달라집니다. 본 세션에서는 AWS Direct Connect, AWS Site-to-Site VPN 및 AWS Transit Gateway와 같은 서비스를 사용하여 고가용성 및 재해 복구를 위한 하이브리드 연결을 설계하는 방법을 알아봅니다. 단일 및 다중 지역 네트워크 아키텍처를 모두 살펴보세요. 또한 Amazon CloudWatch Network Monitor의 활성 모니터링을 활용하여 관찰 가능성과 가용성을 향상하여 원활하게 관리하고 복구하는 방법을 알아보세요.
리인벤트 2024 테크 블로그의 더 많은 글이 보고 싶다면?
Overview
들어가며
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1277.png)
AWS에서 데이터센터 혹은 사무실과의 연결은 불가피한 일입니다.
그것이 대역폭이 보장되는 Direct Connect든, 인터넷을 경유하는 Site-to-Site VPN이든 연결이 될것이며, 그 순간부터 이중화의 대상이 되는 SPOF(Single Point Of Failure)가 됩니다. 본 세션에서의 주제는 하이브리드 환경에서의 복원력입니다. 이러한 환경을 운영할 때는 생산성과 복원력을 높이는 것이 정말 중요합니다. 연결하는 초기에 연결하는 회선에 대한 장애에 대비하여 회복력을 갖추는 계획을 준비해야 합니다.
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1278.png)
일원화 구성된 Direct Connect연결입니다. 왼쪽의 Data Center의 연결이 오른쪽에 AWS의 DX의 일부분인 Pop(Point of presence)를 거쳐 AWS와 연결됩니다. 정상적인 경우 통신은 잘 되겠지만, 장애포인트가 많습니다.
DC 내 고객측 라우터, DC 내 파트너 라우터, DX회선(파트너사), Pop측 파트너라우터, Pop측 DX라우터 등 1개로 구성된 모든 접점이 장애포인트가 됩니다. 파트너 명칭은 DX서비스를 AWS로부터 위임받은 회선사업자이며, 회선뿐만 아니라 파트너 라우터의 임대비용 또한 고객에게 청구한다는 가정이 있습니다.
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1279.png)
이런 상황에서 복원력을 가지게 하려면, 어떻게 해야할까요? 비용을 고려한다면, 가장 먼지 떠오른 방법은 다음일 것입니다.
- 2번째 회선연결은 VPN으로 구성은 다음과 같은 특징이 있습니다.
- 가장 쉽고, 비용이 적게 듭니다.
- Transit Gateway와 잘 연동됩니다.
- Direct Connect나 VPN의 백업회선으로 사용됩니다.
- 그러나,
- 인터넷 트래픽 품질은 균일하지 않습니다.
- 대역폭을 보장받을 수 없을 수도 있습니다.
- 확장은 즉시 이루어지지 않을수도 있습니다.
- 1.25Gbps 이상의 성능을 위해 복잡한 아키텍처가 필요합니다.
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1280.png)
여기서 Data Center와 AWS간에 가장 비용이 저렴하고, 쉽게 연결할 수 있는 Site-to-Site VPN연결이 있습니다.
장비는 단일화되어있지만, VPN연결당 2개채널을 구성하여 혹시라도 발생할 수 있는 인터넷회선 상의 사고에 대비하였습니다. Site-to-Site VPN연결이라도 Virtual Gateway를 사용하는 것보다 Transit Gateway를 통해 더 많은 장점을 꾀할 수 있습니다.
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1281.png)
Data Center에 2대의 VPN장비를 배치하고, AWS의 환경에서 Transit Gateway로 Site-to-Site VPN이 2개를 연결설정된 모습을 보십시요. 각 연결마다 2개의 채널이 존재하여 총 4개의 채널이 유지되는 방식입니다. 여기에서 VPN연결은 동등하지않으며, Primary와 Secondary로 차등을 두게되므로, 평상시에는 Secondary회선측으로 통신하지않습니다.
앞선 아키텍처보다 Site-to-Site VPN이 하나 더 추가되어 Data Center 내 Customer Gateway의 장애에 대비한 모습입니다. 조금 앞섰다고 하지만, 여전히 대역폭을 보장받지못하는 건 마찬가지 입니다.
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1282.png)
이제 Direct Connect와 Site-to-Site VPN이 혼용된 아키텍처 입니다.
평상시에는 Direct Connect로부터 대역폭을 보장받을 수 있고, Direct Connect의 장애시 Site-to-Site VPN으로 Fail-Over되는 구조입니다. 이게 최선일까요? 더 주요한 통신을 해야하는 상황에는 어떤 구조가 필요할까요?
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1283.png)
주요데이터가 오가므로 예산이 조금 확보된다면, 고복원력을 가진 아키텍처를 구성할 수 있습니다.
Direct Connect회선도 2개지만, 각각 다른 회선제공사를 거친다는걸 눈여겨 봐주십시요. Pop는 AWS라우터와 회선제공사가 관리하는 영역이지만, 각각 다른 회선제공사를 선택하여 구성함으로써 물리적인 위치를 이원화할 수 있습니다. 보통은 여기에서 끝나지만, 통신데이터가 너무 중요하고 가치있는 상황이라 예산으로부터 자유롭다면 어떨까요?
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1284.png)
궁극적이고 고정비용으로부터 자유로운 아키텍처입니다.
Data Center도 이원화되고, 모든 장치와 회선이 이중화된 상태입니다. 각기 다른 회선제공사도 각각 2개회선을 제공하는 상황임으로 최대한의 복원력을 가진 구조로 생각하시면 되겠습니다.
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1285.png)
Direct Connect서비스에 대한 CloudWatch가 제공하는 Metrics지표입니다.
Direct Connect는 광케이블 연결이 전제되므로, Tx/Rx light levels지표가 집계됩니다. 각 속도에 맞는 light levels지표값은 관심있게 보아두는 것이 좋겠습니다.
- 1G or 10G connection : -14.4 ~ 2.5 dBm
- 100G connection
- Tx : -4.3 ~ 4.5 dBm
- Rx : -10.6 to 4.5 dBm
회선연결을 나타내는 Connection 지표가 성능 및 정상여부를 확인하는데, 가장 보편적으로 사용될 것입니다.
- ConnectionState : Direct Connect의 연결상태를 표시 (0: Down, 1:Available, 2:Deleting)
- ConnectionErrorCount : Direct Connect의 연결에서 발생한 오류의 수를 표시
- ConnectionEncryptionState : Direct Connect의 연결에서 MACsec암호화 상태를 표시 (0: 암호화 비활성화, 1: 암호화 활성화, 2: 암호화 상태 확인불가)
- ConnectionBpsIngress : Direct Connect를 통해 Data Center에서 AWS로 들어오는 초당 비트 수 (Bits per second)
- ConnectionBpsEgress : Direct Connect를 통해 AWS에서 Data Center로 나가는 초당 비트 수 (Bits per second)
- ConnectionPpsIngress : Direct Connect를 통해 Data Center에서 AWS로 들어오는 초당 패킷 수 (Packets per second)
- ConnectionPpsIngress : Direct Connect를 통해 AWS에서 Data Center로 나가는 초당 패킷 수 (Packets per second)
회선의 인터페이스인 Virtual Interface지표는 성능 확인시 사용될 것입니다.
- VirtualInterfaceBpsIngress : 가상인터페이스를 통해 Data Center에서 AWS로 들어오는 초당 비트 수 (Bits per second)
- VirtualInterfaceBpsEgress : 가상인터페이스를 통해 AWS에서 Data Center로 나가는 초당 비트 수 (Bits per second)
- VirtualInterfacePpsIngress : 가상인터페이스를 통해 Data Center에서 AWS로 들어오는 초당 패킷 수 (Packets per second)
- VirtualInterfacePpsEgress: 가상인터페이스를 통해 AWS에서 Data Center로 나가는 초당 패킷 수 (Packets per second)
각 Metrics의 최대값은 Direct Connect연결의 프로비저닝된 대역폭에 따라 달라집니다. 회선그룹인 Link Aggregation Group의 경우, 그룹에 속한 각 회선대역폭의 합계로 계산됩니다.
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1286.png)
CloudWatch에 추가된 synthetic monitor를 통해 하이브리드 환경에 대한 가시성과 통찰력을 제공합니다.
Agent없는 네트워크 지표측정이 가능하며, ICMP와 TCP프로토콜을 지원합니다. 각 probe는 동일한 서브넷의 2 ENI를 사용하여 ENI당 5 packet/sec의 통신을 발생합니다. Probe로부터 발생하는 3가지 metrics가 제공됩니다.
- Round-trip time (micro-second)
- Packet loss (%)
- Network Health Indicator : NHI는 probe패킷이 Direct Connect에서만 사용할 수 있습니다.
![](https://img.iting.co.kr/wp-content/uploads/2024/12/image-1287.png)
Synthetic monitor에서 probe를 생성하면 소스 서브넷, 목적지 IP, IPv4/6여부, 프로토콜, 패킷사이즈를 조합할 수 있습니다. Probe마다 소스 서브넷에 AZ별로 생성합니다. End-to-end 모니터링을 위해 미션 크리티컬한 워크로드가 구성된 각 AZ에 probe를 배치하고, On-premise에 위치한 워크로드를 대상으로 구성하는 아키텍처입니다.
결론
AWS와 Data Center간의 Hybrid환경에 대한 구축과 운영은 워크로드만큼이나 서비스 신뢰성 및 지속가능성에 영향을 미칩니다. 그에 반해 AWS와 Data Center간의 네트워크 연결이상 및 지연에 관해 우리는 다소 속수무책인 면이 있었습니다. 가상으로 보이는 AWS의 리소스 중 회선은 물리적으로 존재하는 자원이며, 물리적인 충격 및 자연재해에 취약하므로 우리는 이를 탄력적으로 보호하고, 지속적으로 모니터링해야 합니다.
회선이 연결되면 그 기능동작에 만족하지말고, 이중화로 보완하고, 건강상태를 모니터링하여 가시화합시다.
한층 더 나은 인생과 좋은 서비스를 위해서 말이죠.