[Cloud] 트래블월렛의 EKS 전환 여정 (AWS Unicorn Day 2024)

Intro

• 트래블월렛은 여행할 때 진짜 애용하는 서비스입니다.
  • 원하는 외화를 원하는 만큼만 즉시 충전해 해외 어디서든 카드로 사용할 수 있는 서비스입니다.
  • 수수료도 없을 뿐더러 현지 ATM에서 통화 출금도 가능하고, 전세계 주요 도시에서 사용할 수 있는 교통카드 기능도 수행해요.
• 저도 애용하고, 정말 양질의 서비스라고 생각하는 애플리케이션의 인프라는 어떻게 구성되어 있을지 궁금하군요!!
• 스타트업을 위한 AWS 비즈니스와 기술 지원 프로그램을 소개하고, 이를 기반으로 비즈니스를 전개하는 스타트업의 성장 사례를 공유하는 행사인 AWS Unicorn Day 2024에서 트래블월렛이 해당 사례를 공유해주셨습니다!!

트래블월렛 인프라의 변화

트래블월렛 1.0

• 온프레미스 기반 인프라 (금융보안데이터센터 - FSDC)
  • 초기 구축시 보안 및 금융 규제 준수를 위한 선택
  • 확장성 측면에서 제약
  • 운영, 비용 측면의 유연성 부족

트래블월렛 2.0

• AWS EKS 기반 인프라 운영
  • 클라우드 환경에서도 금융 규제 준수 가능
  • 확장성 제약이 없음
  • 운영, 비용 측면의 유연성

트래블월렛 서비스의 초기 EKS 구축

• Development, Production VPC를 각각 배치
• Worker 노드에는 WAS, Management 노드에는 GitOps 도구와 모니터링 툴 배포
  • Worker 노드가 상대적으로 높은 스펙의 인스턴스

• 보안 목적으로 서비스를 Namespace로 격리
• Namespace 마다 NLB, ALB 붙임
  • NLB: IP를 고정하기 위한 목적
  • ALB: Ingress 목적
  • FSDC나 외부에서 트래픽을 받아야 하기 때문

멀티 EKS 클러스터 확장

인프라 확장 이유

1. B2B 사업 확장 (광고 플랫폼) 및 PCI-DSS 구분

• 사업 확장과 비슷한 시기, VCC 기반 PCI-DSS (카드 업계에서 민감 정보의 보호를 위한 표준) 3.2.2 획득
  • 거래 정보
  • 개인 정보

• 해당 표준으로 인해 트래블월렛 서비스는 PCI-DSS Zone을 명확히 구분해 설계해야 했음
• 위와 같은 기존 인프라에는 트래블월렛 서비스만을 위한 EKS였기 때문에 광고 플랫폼을 위한 추가 Zone 필요

• 광고 플랫폼용 VPC를 구축하고, VPC 태그를 이용해 구분
• EKS 구조는 두 개의 노드 그룹 등 동일하게 관리

2. 외부 카드사와 제휴

• FEP 서비스를 기존 운영 중이던 EKS 어딘가에서 운영하기 애매한 상황
  • 외부 서비스와 통신 가능한 서비스를 기존 인프라에서 운영하면 보안 취약 가능성 발생

• 외부 통신용 VPC, EKS 별도 구축

확장된 최종 멀티 EKS 클러스터 구조

• 기존 트래블월렛 서비스는 PCI, 대외계 혹은 B2B 서비스는 No PCI Zone으로 분류

멀티 EKS 클러스터 운영 이슈

1. Management 도구의 증가

🚨 이슈

• 비즈니스 확장에 따라 향후 별도의 EKS를 구축할 가능성이 생김
  • 이를 관리하는 도구도 증가하면 DevOps 엔지니어의 관리가 어려워짐

✅ 해결

• Management EKS를 별도로 구축해 같은 Zone에 있는 EKS 클러스터들을 관리하도록 함

2. ELB 운영 이슈

🚨 이슈

• Load Balancer 자원 운영 비용 증가

• ELB 증가에 따른 Security Group의 보안 정책이 너무 많아지고 버저닝이 안 됨

• Canary 배포에서 트래픽 제어의 어려움
  • 참고: Canary 배포는 Ver 2.0에 대해 일부 트래픽만 적용하고, 문제가 없을 경우 전체 트래픽을 전환
• 기본적으로 서비스마다 Pod 4개를 운영하고 있는데, 모든 업데이트마다 정확한 Canary 비율을 맞춰주기가 어려움

✅ 해결: ISTIO 도입

• 처음에는 러닝 커브 문제도 있었고, 도입 필요가 없어 도입하지 않음

• ISTIO의 Ingress Gateway로 트래픽을 받아 ALB를 통합 (기존에는 Namespace 별로 달려 있었음)
• Security Group 대신 ISTIO의 Authorization Policy를 이용해 GitOps로 버전 관리

• Ingress Gateway Pod를 통해 모든 트래픽을 제어할 수 있다보니, Pod의 수를 늘리지 않고도 Canary Pod에 대해 원하는 비율로 트래픽을 전달할 수 있음

3. EKS 버전 이슈

🚨 이슈

• 평균 4개월에 한 번씩 새로운 Kubernetes 마이너 버전이 릴리즈됨
• EKS는 최초 릴리즈 이후 총 26개월까지 지원 (26개월이 지나면 강제 업그레이드)
  • 정식 지원 ~12개월, 확장 지원 ~26개월
• 강제 업그레이드 전에 무중단 버전 업그레이드 필요
• 트래블월렛은 정식 지원 기간(12개월)마다 한 번씩 EKS를 최신 버전으로 업그레이드 하는 것으로 운영 정책 수립

✅ 해결

• EKS 이중화를 통해 무중단 업그레이드 구현
• 같은 VPC 내에 신규 버전 EKS를 구축 (기존 환경과 동일하게)
  • Argo CD를 통해 GitOps화 해두었기 때문에 큰 어려움 없이 구축 가능
• ALB Target Group 설정을 통해 EKS 트래픽 조절
• 점진적으로 구버전 EKS의 트래픽 제거
• 트래픽 제거가 확인된 이후 신규 버전으로 업그레이드

• 업그레이드 후 트래픽을 50:50으로 변경해 리소스(EC2, Pod 등)를 균등하게 배분
• 이렇게 두 개의 EKS를 운영해도 되고, 하나로 통합해도 됨
• 트래블월렛이 두 개의 EKS로 운영하기로 한 이유
  • Prod 환경에서 작업시 안전하게 하기 위해

최종 구조