[reinvent 2024] 하이브리드 환경을 위한 탄력적인 연결 구축

Summary

고객은 AWS와 온프레미스 시설 간에 리소스를 분할하여 미션 크리티컬 애플리케이션을 운영하는 경우가 많습니다. 이러한 애플리케이션의 가용성은 하이브리드 연결의 복원력에 따라 달라집니다. 본 세션에서는 AWS Direct Connect, AWS Site-to-Site VPN 및 AWS Transit Gateway와 같은 서비스를 사용하여 고가용성 및 재해 복구를 위한 하이브리드 연결을 설계하는 방법을 알아봅니다. 단일 및 다중 지역 네트워크 아키텍처를 모두 살펴보세요. 또한 Amazon CloudWatch Network Monitor의 활성 모니터링을 활용하여 관찰 가능성과 가용성을 향상하여 원활하게 관리하고 복구하는 방법을 알아보세요.


리인벤트 2024 테크 블로그의 더 많은 글이 보고 싶다면?

Tech Blog

AWS re:Invent 2024 Tech Blog written by MegazoneCloud

Overview

  • Title: Building resilient connectivity for hybrid environments [REPEAT]
  • Date: 2024년 12월 4일(수)
  • Venue: Wynn | Convention Promenade | Lafite 1
  • Speaker:
  • Tanvir Kaur(Mgr III, PMT – External Svcs (PMT), AWS)
  • Nick Kniveton(Solutions Architect, AWS)
  • Industry: Professional Services

들어가며

AWS에서 데이터센터 혹은 사무실과의 연결은 불가피한 일입니다.

그것이 대역폭이 보장되는 Direct Connect든, 인터넷을 경유하는 Site-to-Site VPN이든 연결이 될것이며, 그 순간부터 이중화의 대상이 되는 SPOF(Single Point Of Failure)가 됩니다. 본 세션에서의 주제는 하이브리드 환경에서의 복원력입니다. 이러한 환경을 운영할 때는 생산성과 복원력을 높이는 것이 정말 중요합니다. 연결하는 초기에 연결하는 회선에 대한 장애에 대비하여 회복력을 갖추는 계획을 준비해야 합니다.

일원화 구성된 Direct Connect연결입니다. 왼쪽의 Data Center의 연결이 오른쪽에 AWS의 DX의 일부분인 Pop(Point of presence)를 거쳐 AWS와 연결됩니다. 정상적인 경우 통신은 잘 되겠지만, 장애포인트가 많습니다.

DC 내 고객측 라우터, DC 내 파트너 라우터, DX회선(파트너사), Pop측  파트너라우터, Pop측 DX라우터 등 1개로 구성된 모든 접점이 장애포인트가 됩니다. 파트너 명칭은 DX서비스를 AWS로부터 위임받은 회선사업자이며, 회선뿐만 아니라 파트너 라우터의 임대비용 또한 고객에게 청구한다는 가정이 있습니다.

이런 상황에서 복원력을 가지게 하려면, 어떻게 해야할까요? 비용을 고려한다면, 가장 먼지 떠오른 방법은 다음일 것입니다.

  • 2번째 회선연결은 VPN으로 구성은 다음과 같은 특징이 있습니다.
    • 가장 쉽고, 비용이 적게 듭니다.
    • Transit Gateway와 잘 연동됩니다.
    • Direct Connect나 VPN의 백업회선으로 사용됩니다.

  • 그러나,
    • 인터넷 트래픽 품질은 균일하지 않습니다.
    • 대역폭을 보장받을 수 없을 수도 있습니다.
    • 확장은 즉시 이루어지지 않을수도 있습니다.
    • 1.25Gbps 이상의 성능을 위해 복잡한 아키텍처가 필요합니다.

여기서 Data Center와 AWS간에 가장 비용이 저렴하고, 쉽게 연결할 수 있는 Site-to-Site VPN연결이 있습니다.

장비는 단일화되어있지만, VPN연결당 2개채널을 구성하여 혹시라도 발생할 수 있는 인터넷회선 상의 사고에 대비하였습니다. Site-to-Site VPN연결이라도 Virtual Gateway를 사용하는 것보다 Transit Gateway를 통해 더 많은 장점을 꾀할 수 있습니다.

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의 장애에 대비한 모습입니다. 조금 앞섰다고 하지만, 여전히 대역폭을 보장받지못하는 건 마찬가지 입니다.

이제 Direct Connect와 Site-to-Site VPN이 혼용된 아키텍처 입니다.

평상시에는 Direct Connect로부터 대역폭을 보장받을 수 있고, Direct Connect의 장애시 Site-to-Site VPN으로 Fail-Over되는 구조입니다. 이게 최선일까요? 더 주요한 통신을 해야하는 상황에는 어떤 구조가 필요할까요?

주요데이터가 오가므로 예산이 조금 확보된다면, 고복원력을 가진 아키텍처를 구성할 수 있습니다.

Direct Connect회선도 2개지만, 각각 다른 회선제공사를 거친다는걸 눈여겨 봐주십시요. Pop는 AWS라우터와 회선제공사가 관리하는 영역이지만, 각각 다른 회선제공사를 선택하여 구성함으로써 물리적인 위치를 이원화할 수 있습니다. 보통은 여기에서 끝나지만, 통신데이터가 너무 중요하고 가치있는 상황이라 예산으로부터 자유롭다면 어떨까요?

궁극적이고 고정비용으로부터 자유로운 아키텍처입니다.

Data Center도 이원화되고, 모든 장치와 회선이 이중화된 상태입니다. 각기 다른 회선제공사도 각각 2개회선을 제공하는 상황임으로 최대한의 복원력을 가진 구조로 생각하시면 되겠습니다.

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의 경우, 그룹에 속한 각 회선대역폭의 합계로 계산됩니다.

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에서만 사용할 수 있습니다.

Synthetic monitor에서 probe를 생성하면 소스 서브넷, 목적지 IP, IPv4/6여부, 프로토콜, 패킷사이즈를 조합할 수 있습니다. Probe마다 소스 서브넷에 AZ별로 생성합니다. End-to-end 모니터링을 위해 미션 크리티컬한 워크로드가 구성된 각 AZ에 probe를 배치하고, On-premise에 위치한 워크로드를 대상으로 구성하는 아키텍처입니다.

결론

AWS와 Data Center간의 Hybrid환경에 대한 구축과 운영은 워크로드만큼이나 서비스 신뢰성 및 지속가능성에 영향을 미칩니다. 그에 반해 AWS와 Data Center간의 네트워크 연결이상 및 지연에 관해 우리는 다소 속수무책인 면이 있었습니다. 가상으로 보이는 AWS의 리소스 중 회선은 물리적으로 존재하는 자원이며, 물리적인 충격 및 자연재해에 취약하므로 우리는 이를 탄력적으로 보호하고, 지속적으로 모니터링해야 합니다.

회선이 연결되면 그 기능동작에 만족하지말고, 이중화로 보완하고, 건강상태를 모니터링하여 가시화합시다.

한층 더 나은 인생과 좋은 서비스를 위해서 말이죠.

글 │메가존클라우드, Strategic Technology Center(STC), CS1그룹, CA1팀, 이태훈 SA
게시물 주소가 복사되었습니다.