인프라팀 서종호

AWS ↔ IDC VPN 최적화 설정 경험

1. AWS 서비스 접속 방식 발전 방향

스타트업의 개발팀원의 증가에 따른 ‘AWS 서비스 접속 방식’ 발전 방향에 대해서 알아보겠습니다.

초기 개발자 1명인 상태에서는 자신의 PC에서 직접 ‘AWS EC2’에 접속하여 관리를 합니다.

Untitled

회사의 발전에 따라 개발자도 한명 더 충원이 되고, 조금 더 안전한 접속을 위해서 VPN Virtual Private Network을 통한 접속을 권장합니다.

VPN은 ‘공용 인터넷망’을 통하여 ‘데이터 암호화, 무결성, 인증’의 보안 통신 환경을 제공합니다.

Untitled

위 그림 예시 처럼, ‘AWS EC2’에 software vpn을 설치하여 VPN 서버를 구성하고, VPN 접속 계정을 생성합니다. 이후 개발자분들의 PC에 software vpn client설치 후 접속합니다.

이후 회사가 좀 더 발전을 해서 개발팀이 꾸려지고, 회사 사무실 환경에 별도의 방화벽 장비를 통해서 VPN 환경을 만들어서 접속을 합니다.

Untitled

AWS에 ‘관리형 VPN 서비스’와 회사 사무실에 ‘방화벽 장비’의 VPN 기능을 설정하여 사용하게 됩니다.

AWS 영역(Site)과 사무실 영역(Site)간 논리적인 VPN 터널이 생성이 되어, 개발자분들은 별도의 ‘VPN Client’ 설치 할 필요 없고, VPN 계정 관리도 필요 없습니다.

저희 쟁글 인프라 역시 ‘AWS - Office/IDC’ 간 Site-to-Site VPN을 사용하고 있습니다.

그럼 실제 업무 중 발생한 장애와 장애를 보완할 수 있는 최적화 설정 경험 업무에 대해서 설명드리겠습니다.

2. AWS VPN 관련 장애 기록

장애 전 상황 : AWS와 IDC간 Site-to-Site VPN(S2S)으로 연결되어 있고, 정기적으로 주말 기간 동안 배치 Job으로 AWS와 IDC간 App 애플리케이션 로직 동작

Untitled

‘AWS 관리형 VPN’은 논리적으로 Active Tunnel 과 Standby Tunnel로 연결됩니다.

평상 시 Active Tunnel로 통신을 하고 문제 발생 시, Standby Tunnel이 Active Tunnel로 전환되어 연속성 있는 VPN 통신 환경을 제공합니다.

장애 발생 : 이전 3주 주말 기간 동안은 배치 Job이 잘 동작하였으나, 4주차 주말 배치 Job이 실패

장애 원인 :

  • ‘애플리케이션 로그’을 확인해보니, 네트워크 연결이 끊어지고 몇 번의 재시도를 했으나 결국 통신 연결이 되지 않아서 로직이 실패
  • AWS VPN ‘모니터링과 로그’를 확인해보니, Active VPN Tunnel이 Down이 발생하였고 이로 인해 Standby VPN Tunnel 이 Active Tunnel로 전환이 되고, 정상 통신 환경이 마련되기 까지 대략 1분 정도의 통신 단절이 발생하였습니다.
  • AWS측에서 VPN의 정기적인 유지관리를 위해서, 대략 한달에 한번씩 VPN Tunnel을 순차적으로 Down 되는데, 이 부분이 원인이었습니다.
  • 참고로, AWS S2S VPN의 SLA Service Level Agreement는 99.95%로 한 달 기준 21분 44초에 비활성화 할 수 있습니다 - 링크
  • 즉, AWS VPN 정기 유지관리에 대비를 하기 위해서라도 반드시 VPN Tunnel 이중화 설정이 필수입니다.

장애 대응 방안 고민

  • (공통) 모니터링/알람 설정 : AWS VPN Tunnel Down 시 Slack 채널에 알람 발생 설정

Untitled

  • 1안 : 애플리케이션 연결 실패 시, 자동 재시작 로직 추가 및 연결 Timeout 시간 늘리기
  • 2안 : AWS VPN Tunnel Down 시 통신 단절 시간 30초 이내로 최소화 하기
  • 2가지 방안 중, 인프라측면에서 2안 구성 시 향후 모든 애플리케이션 통신에 안정성이 높아지니 결국 2안 방안 설정을 하기로 결정하였습니다.

3. AWS VPN 최적화 설정

목표 구성 : AWS ↔ IDC 간 VPN Tunnel 을 Active - Active 로 구성하여 장애 시 빠른 절체를 구현

Untitled

  • 저희 쟁글에서는 AWS에 여러개의 VPC를 사용하고 있으며, 통신을 위해서 AWS TGW(Transit Gateway)를 사용하고 있습니다.
  • AWS TGW에 VPN 연결 설정 시 BGP와 ECMP를 사용하여, VPN Tunnel 2대를 모두 Active-Active로 사용이 가능합니다.
  • 예를 들어 1번 Active Tunnel 이 Down이 발생하더라도, 기존에 2번 Active Tunnel로 통신하는 트래픽은 무중단으로 통신이 가능합니다.
  • 또한 1번 Active Tunnel로 통신하는 트래픽도, 이전과 달리 30초 이내에 절체가 되어 빠른 통신 환경을 제공해줍니다.
  • 더불어, 각 VPN Tunnel이 최대 1.25Gbps 및 140,000PPS 제약을 가지고 있지만, ECMP 기능에 의해서 최대 2.5Gbps 통신이 가능합니다.

설정 확인

아래 그림은 IDC 방화벽에서 VPN Tunnel의 통신 트래픽 정보입니다. 2개의 Tunnel을 모두 Active-Active로 사용하고 있음을 알 수 있습니다.

Untitled

아래 라우팅 정보는 IDC 방화벽에서 확인한 정보입니다. AWS 172.16.0.0/16 대역에 대해서 2개의 VPN Tunnel 을 모두 라우팅 사용 가능을 확인 할 수 있습니다.

BGP  172.16.0.0/16 [20/100] via 169.254.110.1 (recursive via Xangle-AWS-VPN1 tunnel IP1)
BGP  172.16.0.0/16 [20/100] via 169.254.114.1 (recursive via Xangle-AWS-VPN2 tunnel IP2)
...

정리하자면, ‘AWS - IDC - Office’ 모두 VPN으로 안전한 통신 환경을 구현하고 있습니다.

그림에는 표현되지 않았지만, Office 방화벽 장비에는 재택 근무 직원을 위해 SSL VPN 서버가 설정되어 있습니다.

이를 통해 내부 직원분들은 안전하고 편리하게 ‘AWS, IDC’ 서버에 접속하여 사용하고 있습니다.

Untitled

4. 마치며

대략 3개월 정도의 기간 동안, AWS와 VPN 설정 후 최적화를 하기 까지 긴밀하게 개발팀과 협업하여 문제를 분석하고 대응 방안들을 논의하고 수행하였습니다.

요약하지면

  • AWS에 안전한 접속을 위해서 VPN을 사용하자
  • AWS 관리형 VPN 서비스의 유지관리를 대응하기 위해, 반드시 2개의 VPN Tunnel 설정을 하자
  • 좀 더 빠른 절체와 대역폭 확장을 위해서 AWS TGW에 VPN을 연동하고 ECMP를 사용하자

이와 같이 쟁글 인프라팀은 ‘AWS, IDC, Office’의 인프라 자원을 관리하고, 개발팀과 협업하여 ‘개발-검증-상용’ 환경을 구축하고 유지 관리 및 지속적인 최적화 활동을 하고 있습니다. 또한 ‘메인넷’ 노드를 설치와 운영을 하고 있고, 방화벽이나 VPN 등 인프라 보안 관련 업무도 병행하여 진행하고 있습니다.

인프라, 플랫폼(AWS, K8S), IDC, 보안, 메인넷 등 다양한 영역의 업무를 경험할 수 있고, 내부 스터디와 세미나도 꾸준히 있어서 빠르게 성장할 수 있습니다.

참고