1. 발표 내용 정리
1.1. 티맵 모빌리티
•
티맵 모빌리티 소개
◦
2000만 가입자
◦
1400만 MAU / 600만 DAU
◦
10000 TPS (최대치)
◦
3000대 서버
◦
300억 로그 / 월
•
AWS Migration
◦
SKT IDC 기반 인프라 → AWS 로 이전 프로젝트 진행 중
◦
AWS 30% 정도 넘어옴
◦
내년에 전부 migration 하는 것을 목표로 함
1.2. 네트워크 구성
•
네트워크 성장 과정
◦
하나의 VPC로 시작해 점점 VPC가 증가
▪
단일 VPC 구성 → 복수 VPC 구성 & VPC Peering을 통한 서브넷간 연결
◦
AWS 계정과 VPC가 증가하고 외부 연결이 추가되면서 연결 구간이 복잡해짐
▪
라우팅 테이블 등 연결
▪
Organization 과 TransitGateway를 통한 통합 관리 방안
•
티맵 네트워크 구성
◦
TransitGateway를 중심으로 다수의 AWS 계정과 VPC, SKT/관계사의 IDC, 사무실 등 연결
◦
연결 구간
▪
내부 네트워크 구간별 연결 방안
•
Conn Subnet → SKT IDC 연결
◦
SKT IDC 연결할때 사용하는 서브넷
◦
SKT IDC와 겹치는 아이피 대역간 통신 필요
◦
협의된 100.64.0.0/10 대역에 NLB 구성
◦
한정된 대역을 /27, /28로 나누어 사용
•
VPC 간 연결
◦
개발 <> 운영간 트래픽 분리 필요
◦
VPC 라우팅 테이블로 트래픽 제어
◦
Subnet 단위로 라우팅 규칙이 상이함
•
문제점
◦
아이피 대역 관리
▪
아이피 대역만으로 환경 예측이 어려움
◦
복잡한 VPC 라우팅 테이블
▪
VPC 증가로 라우팅 테이블 복잡도 올라감
▪
다수 AWS 계정으로 인한 여러 계정을 돌아가면서 설정 필요
▪
신규 서브넷 생성 시 라우팅 테이블 반영이 안되는 경우가 생김
▪
라우팅 테이블의 아이피 대역만으로 환경 확인이 어려움
•
개선 요구사항
◦
IP 대역 가시성 확보
◦
라우팅 테이블 단순화
◦
외부 인입 트래픽 제어
◦
중앙 집중화 관리
→ 이 모든 것을 Infrastructure as Code (Terraform)
1.3. 작업 상세
1.3.1. 사전작업
•
IP 대역 가시성 확보
◦
IPAM 기능을 이용해 IDC, AWS 네트워크 대역을 한 군데서 확인하고 가시성 확보
◦
관리되지 않는 미사용 VPC 및 실제 IP 사용률 확인
▪
Subnet Utilizatiion
•
VPC 라우팅 테이블 정리
◦
IPAM Resource Discovery 기반으로 IP 대역 취합
◦
개발/운영 등 환경별로 Managed IP Prefix List 생성
◦
RAM을 이용해 다수 계정의 VPC에 한번에 변경 전파
•
Managed IP Prefix List
◦
전체 아이피 목록을 TGW로 라우팅
▪
VPC 라우팅 테이블 규칙
◦
개발 <> 운영간 트래픽 제어
▪
TransitGateway 라우팅 테이블 규칙
◦
공인 아이피로 접근 허용 필요 시
▪
SecurityGroup 규칙
◦
팁
▪
사소한 변경이 전체 계정의 장애로 이어질 가능성이 있음
▪
라우팅 테이블에 사용시 Prefix List 우선순위 확인 필요
▪
GWLB VPC Endpoint를 Destination으로 설정 불가
•
TGW 라우팅 테이블 분리
◦
단일 TGW 라우팅 테이블을 환경별로 나누어 구성
◦
TGW 라우팅 테이블과 AWS Netword Firewall을 이용한 트래픽 제어
▪
같은 환경 VPC 간의 요청은 바로 통신
▪
다른 환경 VPC 간의 요청은 방화벽 통하도록 구성
▪
외부 환경에서 들어오는 요청은 방화벽 통하도록 구성
▪
인터넷망으로 나가는 요청은 방화벽 통하도록 구성
◦
Network Firewall 옵션
▪
stateless 규칙은 forward
▪
strict order 사용
▪
도메인 기반 규칙은 suricata rule 사용
▪
keyword를 작업 메모 용도로 활용
•
티켓 넘버 등
1.3.2. 반영 작업
•
TGW 라우팅 테이블 변경
◦
TGW Attachment의 라우팅 테이블 변경 작업
◦
변경 시, 약 40초 정도 트래픽 중단 발생
◦
서비스 트래픽 최빈 시간대 확인
◦
중요도 낮은 QA, 개발 환경부터 서서히 트래픽 이전
◦
운영 환경까지 최종 작업 완료
•
정상 여부 점검
◦
미리 구성해놓은 Reachability Analyzer로 TGW 라우팅 정상 여부 점검
▪
네트워크간 라우팅 경로 검사
▪
TIP: 고려할 점
•
TGW 고려 시 단방향으로 동작하므로 양방향 확인 필요
◦
Response /Request
•
요청 후 상태 확인까지 약 4분정도 소요됨
•
GUI 편의성이 떨어져 CLI 및 스크립트 사용 권고
•
Organization 기반 다중 계정 환경에서는 권한 위임 설정 필요
1.4. 마무리
이모든 것을 Terraform을 통해 Gitops 파이프라인 구성(atlassian)
•
IPAM 구성
•
환경별 prefix List 구성
•
VPC 라우팅 테이블 작업
•
TWG 라우팅 테이블 분리
•
Network Firewall 구성
•
서비스 트래픽 이전
•
최종 라우팅 점검
1.5. 질의 응답
•
TGW 비용 괜찮은지?
◦
IDC → AWS 마이그레이션 과제가 시급
◦
트래픽 많을 시 트레이드오프
•
TGW 네트워크 대역폭 제한 고려가 되었는지?
◦
기존에 이미 들어가있었음
◦
TGW 대역폭 매우 큼 (티맵이 충분히 서빙가능한 수준)
•
VPC Peering 안쓰는지?
◦
VPC, 서브넷 너무 많음 → 관리가 사실상 불가….
•
보안그룹 가시성 어떻게 관리?
◦
참 어렵다… 고민이 많음
◦
CSPM 솔루션 → 규칙 기반 탐지 적발
2. 참석 후기
한번쯤 가봐야지 벼르고 있던 AWSKRUG 소모임 밋업을 용기내어 참석해보았다. AWS 소모임 특성상 Devops 개발자분들이 많이 참석한 것으로 보였고, 위 발표주제도 인프라의 이해도가 높지 않은 백엔드 개발자가 듣기에는 쉽지 않았던 것 같다. 첫술에 배부를순 없을 것 같다. 그렇지만 꾸준히 새로운 환경에 노출되어 새로운 개념들을 한번이라도 더 본다면 장기적으로는 이해도가 높아지지 않을까?
IGW, NGW, TGW, VPC Peering, 라우팅 테이블 등등 쉬운 개념들 부터 익숙해지려고 노력해봐야겠다.
•
IGW, NGW, TGW의 차이
◦
인터넷 게이트웨이(Internet Gateway)
▪
VPC와 인터넷 사이의 통신을 위한 게이트웨이
▪
하나의 VPC에 하나의 인터넷 게이트웨이를 연결할 수 있음
▪
VPC 내 퍼블릭 서브넷의 인스턴스들이 인터넷에 연결되도록 함
◦
NAT 게이트웨이(NAT Gateway)
▪
프라이빗 서브넷의 인스턴스가 인터넷에 연결되도록 함
▪
프라이빗 서브넷 인스턴스의 아웃바운드 트래픽을 인터넷 게이트웨이로 라우팅함
▪
서브넷별로 NAT 게이트웨이를 할당할 수 있음
◦
트랜짓 게이트웨이(Transit Gateway)
▪
다수의 VPC 및 온-프레미스 네트워크를 상호 연결하는 데 사용
▪
서로 다른 VPC 간의 트래픽 전달을 용이하게 함
•
VPC Peering & TGW 차이
◦
VPC Peering
▪
장점: 설정이 간편, 비용이 저렴
▪
단점: 한 번에 두 VPC만 피어링 가능, 모든 리전에서 사용 불가, 복잡한 네트워크 설계에 어려움
◦
TGW
▪
장점: 여러 VPC와 다른 서비스를 쉽게 연결 가능, 모든 리전에서 사용 가능, 복잡한 네트워크 아키텍처 구축에 유연
▪
단점: VPC Peering보다 구현/관리 비용이 더 높음
◦
정리
▪
단순한 경우에는 VPC Peering 권장
▪
복잡한 네트워크의 경우 TGW 권장