테크 블로그 TechBlog

# GS SHOP의 AWS 네트워크 변경 배경

GS SHOP은 오랜 기간 운영해온 인천 IDC의 서비스 종료에 맞춰, All Cloud 전환을 목표로 1,000대 이상의 서버를 클라우드로 이전하기 시작했습니다. 이 대규모 전환 작업은 2024년 성공적으로 마침표를 찍게 되었고, 이 과정에서 고도화 및 개선한 경험을 나눠보고자 합니다.

 

# 개요 및 목표

당시 AWS에 구성되어 있는 GS SHOP의 네트워크 환경을 유지한채로, IDC 이전시 초래될 복잡성과 기존 운영 하면서 불편했던 구조적 어려움을 해소하고자 두가지 방향성을 가지고 이관을 진행하였습니다.

 

첫번째. TGW와 DX Gateway 연동 구조를 통해 라우팅 구조를 간결하게!!

두번째. TGW 중심으로의 네트워크 통합 구조를 통해 복잡하게 얽혀있던 구성을 통합!!

 

***여기서 잠깐!! TGW 사전 지식을 알아봅시다*** GS SHOP의 네트워크 작업의 설명전에 우선 TGW가 무엇인지 어떤 장점을 가지고 있는지 먼저 TGW의 설명을 드리도록 하겠습니다. IDC시절 각 서비스 별로 네트워크 망을 구분하는 경우가 많습니다. 보통은 보안상의 목적이 큽니다. GS SHOP 또한 고객이 접점에 있는 DMZ망, 채널계망, 기간계망, 개발망, VAN전용망등으로 구분됩니다. 클라우드는 서비스의 경우 VPC로 구분을 하게 되며 VPC 각각이 사설 네트워크라고 할 수 있습니다.  그래서 VPC를 연결하기 위해서는 VPC간에 Peering이라는 기술로 연결하고 싶은 VPC끼리 1:1 매핑을 할 수 있습니다. ex) 1개의 IDC와 VPC 3개를 연결시 필요수량 : VPC N개당 필요한 VPC Peering 개수 = n(n-1)/2                    VPC N개당 필요한 VPN connection 개수 = n                   TOTAL =  n(n-1)/2 +n 3개의 VPC만 해도 서로를 연결하기 위한 VPC peering 3개와 IDC센터와 연결하기 위한 각각의 VPN 3개 라인이 필요로 합니다. 만약 서비스가 계속 증가하고 MSA화 되고있는 환경에서 VPC가 추가되기 시작하면 네트워크를 담당하는 엔지니어는 끔찍하겠죠.. VPC가 6개이면 VPC peering만으로도 벌써 별이 그려집니다.ㅠㅠㅠ 이를 개선하기 위해 등장한것이 Trangit Gateway입니다. (AWS기준 2021년 4월 출시) ( 참조 URL : https://aws.amazon.com/ko/about-aws/whats-new/2021/04/aws-transit-gateway-connect-available-additional-aws-regions/ ) Transit Gateway를 한줄로 요약하자면 각각 연결된 VPC peering을 중앙집중으로 관리하겠다! 입니다. 그럼 위의 예시를 Transit Gatway(이후부터는 TGW로 표기)로 묶는다면 어떻게 표현될까요? 1개의 TGW에 VPC들이 묶이게 되고, IDC로는 1개의 VPN만으로도 통신 할 수 있게 됩니다. 이후에는 VPC들이 계속 생성되어도 TGW에만 연결시켜주면 되겠죠? 작업을 나누어 보면 ①VPC 간에 통신을 통합하는 것  ②VPN을 TGW로 연결하여 통합하는것 두 단계로 크게 나눌 수 있습니다. 저희의 고민은 ①은 구성이 되었고  ②작업을 하는것이 주요 목적이었습니다.  ← 첫번째 작업에 해당 또한 인천IDC에  VPN 연결되어 있는 Toast, GCP 환경과, 센터의 이관을 위해 병행 운행 되고 있던 TGW들을 하나의 TGW로 연결통합하는 작업이 필요하였습니다.    ← 두번째 작업에 해당

 

 

첫번째, TGW와 DX Gateway 연동을 통한 IDC 통신

- 아래 그림은 GS SHOP AWS Landing Zone 구성 당시 초기 네트워크 환경입니다.

   -  모든 VPC는 Transit Gateway로 연결되어, VPC간의 통신을 한다. (그림에서 파란색 라인에 해당)

   -  VPC에서 IDC로의 통신은 각각의 VPC Virtual Private Gateway(이하 VGW)에서 Direct Connect를 통해 통신한다. (그림에서 빨간색 라인에 해당)

 

- 당시 위 네트워크 환경 구성을 채택한 주요한 이유는 다음과 같습니다.

1) IDC에 주요 DB를 포함한 많은 서버가 위치하고 있어, IDC 통신에 필요한 트래픽이 Transit Gateway를 거치게 되면 보다 높은 트래픽 비용 발생.

2) IDC의 전체 시스템을 클라우드로 모두 Migration 한다면 기존 구성에 영향 없이 Direct Connect 제거 가능.

3) 각 VPC VGW에서 DX를 통한 IDC로의 통신은 가장 짧은 홉을 가지고 있음.

 

-  하지만 마이그레이션 및 신규 프로젝트를 AWS에 구성하며 VPC가 지속적으로 증가하게 되었고, 이는 아래와 같이 복잡도 및 작업 증가로 이어졌습니다.

1) VPC가 늘어나는 만큼 DX 통신을 위한 VGW 생성 / 연결 작업 증가

2) 트래픽 및 DX 연결 갯수에 따른 DX Gateway 증가로 네트워크 작업 증가

3) 기본적으로 들어가는 IDC로의 라우팅 정책이 20개 이상인데, 신규 서브넷 라우팅을 생성할 때마다 관리 정책수가 비례 증가함.

4) IDC의 IP 신규 / 변경 발생시 관련된 모든 서브넷 라우팅 정책을 다 수정/검토/반영/모니터링해야 하는 공수 증가함.

5) 라우팅 복잡도가 높아 질수록 신규/변경/삭제에 따른 네트워크 작업으로 인해 보다 높은 장애 환경에 노출됨.

 

 

 

 

여기서 하남 IDC로의 DX를 추가 구성하게 된다면 VGW 라인이 기존의 2배 되어, 아래 그림과 같이 라우팅 복잡도 또한 2배 이상으로 증가 할 것으로 예상되었습니다.

(그림에서 빨간색선이 VPC VGW에서 DX 로의 IDC 통신 라인. )

 

 

따라서, 본격적인 이전에 앞서 VGW를 제거하고 DX와 TGW를 연동하는 구조로 변경하게 되었습니다. 

 

DX와 TGW 연동 구성의 장점은 아래와 같습니다.

1) VPC 생성시에 수반되는 VGW 생성 / DX Gateway 작업등의 네트워크 작업이 없어짐.

2) 복잡한 서브넷 라우팅이 간소화됨. 라우팅 관리를 Transit Gateway 라우팅에서 중앙 집중 관리함. 

: 각각의 서브넷 라우팅 테이블 정책이 약 25라인 이상에서 3~5개 이하로 대폭 축소됨.

3) IDC로의 통신이 TGW를 거치게 되면서 추가 발생되는 비용 부분도, IDC의 리소스들이 AWS로 점차 마이그레션이 되고 있어 AWS<->IDC간의 트래픽이 점차 감소되므로 비용 상쇄됨.

4) 하남 IDC DX와 카카오 클라우드 DX 추가에 따른 라우팅 복잡도 및 수반되는 라우팅 등록 작업들이 축소됨.

5) 간소화된 라우팅으로 인해 네트워크 작업이 줄어들었고, 그 만큼 장애 노출도 줄어듬.

6) 라우팅 환경을 TGW 중심으로 통합하는 기본 틀을 마련.

 

 

TGW-DX 연동 방식으로 구조 변경함에 따라 아래 그림과 같이 VGW라인을 표시 했던 빨간색 라인이 전부 사라지게 됩니다. (TGW와 DX를 연동하는 4개의 라인을 제외하고는)

각 VPC간에 통신을 TGW를 통해 통신한것처럼, IDC도 하나의 VPC와 같이 TGW를 통해 통신한다고 생각하면 편할꺼 같습니다. (물론 IDC와의 트래픽이 높으니 DX 10G 회선일뿐)

 

 

당시 200개 이상의 서브넷 라우팅 테이블이 있었고, 각 테이블당 정책들은 아래 그림과 같이 25개 이상이었습니다.  (단순 계산시 전체 라우팅 정책이 5,000개 (200 RT * 25 policy))

여기에다가 IDC 이전에 따른 추가적인 정책이 늘어난다고 했을때 위에서도 언급한 라우팅 관리 공수/작업빈도/복잡도/장애노출 증가 문제에 직면하게 되었을것입니다. 

 

이러한 상황에서 DX-TGW 연동 방식으로의 구조 변경은 라우팅 정책을 크게 감소 시켰습니다.

라우팅 관리를 TGW RT에서 관리하니 서브넷 라우팅 테이블에서는 그저 0.0.0.0/0 TGW로 꺾어주는 정책만 남게 되었습니다.

테이블당 20개 이상에서 3~5개 이하로 축소 되었으니, 전체 정책은 800개(200 RT *4 policy)로

1/6 이하 수준으로 간소화 되었습니다. 

테이블 신규 생성시에도 간단하게 TGW 로 꺾어주는 정책 하나면 되고, 위에 계속 언급한 문제들의 반대 상황인 라우팅 관리 공수 감소, 네트워크 작업 빈도 축소, 복잡도 간소화, 장애노출 감소의 효과가 나타났습니다.

 

 

 

 

 

 

두번째, TGW 중심으로의 네트워크 통합 구조

인천 IDC의 서비스 종료로 옮겨야 될 여러 구성 환경들을 하나의 TGW에 통합하는 방향으로 이전 수행하였습니다. 기존 환경은 유지한 상태에서 이관용으로 생성한 TGW에 하나씩 통합하는 과정으로 진행하였습니다.

 

- 통합 대상은 다음과 같습니다.

1) 여러 용도의 TGW 제거하고 통합 TGW로 이전

2) Kakao, Toast, GCP Cloud를 통합 TGW로 VPN/DX 연결

3) 통합은 아니지만 각종 회선들을 인천 IDC에서 하남 IDC로 이전 (VAN사들, 보험회선들, 각종 사무소 회선들, 물류센터 회선들 등)

 

- 작업 내용들은 아래와 같습니다.

1. 양단의 라우팅 정책 분석통합 TGW로의 연결 구성

2. 양단의 테스트 환경 구성 및 통신 테스트

3. 작업 계획서 작성, 결제 및 작업 공지

4. DEV/STG/PRD 순으로 각각 일정 잡아 전환 작업

5. 관련 담당자들 일정 협의

6. 작업 시간은 주로 야간/새벽에, 작업시 모여서 전환하고 운영 담당자들의 서비스 체크

7. 전환 후에도 일정기간 모니터링 등

 

작업의 크고 작음은 있겠지만, 위 작업 내용들을 수십번 반복 수행한 결과 TGW로 통합/이관 완료하였습니다. 

 

TGW 통합의 장점은 아래와 같습니다.

1. 서브넷 라우팅 테이블에서는 0.0.0.0/0 TGW로 경로 설정 해주기 때문에 서브넷 라우팅 관리가 간결해짐.

2. 라우팅 신규/변경/삭제시 대부분 TGW-RT 정책 관리되므로 관리 용이.

3. 간결해진 네트워크 경로 구성.

4. TGW-RT를 통한 개발존 / 운영존 통신 망분리 운영.

 

#맺음말

오랜 기간 운영되어 온 시스템의 마이그레이션을 진행하면서 단순한 IP 변경조차 얼마나 방대한 작업인지 새삼 깨달았습니다. 하나의 서버가 아닌, 복잡하게 얽혀있는 시스템 전체를 고려해야 했고, IP와 라우팅 변경에 따른 방화벽 규칙 수정 등 수많은 변수를 관리해야 했습니다.

1년 이상의 기간동안 이 모든 과정을 성공적으로 마무리할 수 있었던 것은, 각자의 분야에서 최선을 다해 협력해주신 모든 구성원 덕분이라 생각합니다.

특히, 서비스 중단을 최소화하기 위해 주말과 새벽 시간도 마다하지 않고 지원해주신 모든 분들께 진심으로 감사드립니다.

 

 

---

 

송일호 | DX본부 > 홈쇼핑DX부문 > 클라우드2팀

Cloud TA 엔지니어

 

 

 

---