카테고리 없음

[Kubernetes] Amazon EKS를 사용하는 사례 정리

★용호★ 2023. 11. 19. 02:12

EKS + NLB + Istio

카카오 페이 사례

  • 기존에 Gateway 역할로 nginx를 사용하다가 istio의 Gateway를 사용하기로 결정
    • 트래픽이 증가할 경우 nginx 서버를 증설해야하고, 관리 부담이 있었음
    • istio의 경우 envoy가 트래픽 처리를 하고, 유연하게 확장될 수 있기 때문에 운영 부담이 줄어듦
  • 카카오페이에서 3년간 istio 운영 경험이 있어서 handling 할 수 있는 영역에 한해 제한적으로 istio 적용
  • 금융 업계의 보안 정책 준수를 위해 고정 IP를 사용해야 했기 때문에 NLB 선택

  • AWS 인프라 관리에 Terraform 사용
  • GitOps 도구인 atlantis로 배포 및 상태 관리
  • Git PR의 tag 정보로 배포 이력 관리

  • 애플리케이션은 Jenkins와 Spinnaker로 배포
  • istio를 통해 롤링 업데이트나 Canary 등의 배포 전략 사용
  • 노드 그룹(ASG)와 Cluster Autoscaler로 자동 확장 관리
  • 서비스 별 노드 그룹 분리 및 Spot 활용

HA Proxy + NLB, ALB Target Group Binding

당근 마켓 사례

  • 멀티클러스터 방식으로 버전 관리
    • NLB는 gRPC, HTTP 트래픽용
    • ALB는 기존 서비스 유지를 위함
  • Route53의 Weight를 사용한 방식은 DNS 캐싱으로 인한 지연이 있어서 HA Proxy로 트래픽 전환
    • 사내 HA Proxy 운영 경험이 있었음
  • ALB는 terraform으로 사전에 프로비저닝 후 TargetGroup Binding으로 멀티 클러스터 관리
  • istio는 Virtual Service와 Gateway만 사용 → 싱글 클러스터 업그레이드 시 istio 업그레이드에 어려움이 있었음

대규모 게임 사례

크래프톤 PUBG 사례 (Battlegrounds on AWS)

AS-IS 아키텍처

  • 인프라 생성 및 관리 부담 증가
    • 신규 서비스 추가 시 지속적으로 인프라 작업 필요
    • 각 서비스별로 ASG와 CodeDeploy 구성의 번거로움
  • 신규 QA 환경 구성 요청 증가
    • 환경 구성 시마다 DevOps 팀 지원 필요
  • 작은 서버 배포 증가
    • 서버 운영툴, CS툴, 모니터링 툴 등 배포 및 관리해야할 서버 증가
    • ECS를 사용하고 있었으며 case by case로 대응함
  • 30여개 이상의 서비스로 구성됨

TO-BE 아키텍처

  • GameShard는 Agones 사용

  • EKS 도입 후 QA 환경을 Kubernetes 상에 배포 할 수 있는 자동화 플랫폼을 개발하여 웹 UI를 통해 연관된 팀들에서 자유롭게 환경 구성
  • 100여개의 QA 환경이 있지만 운영 부담이 거의 없음

  • 글로벌 서비스라서 여러 리전을 사용하는데 리전마다 ECR 레파지토리의 도메인이 달라지는 문제로 오픈소스인 Harbor 사용
  • CF 캐싱 기능으로 15분 → 7분으로 pull 속도 개선
  • Kubelet flag에서 —serialized-image-pull=false로 설정하여 7분 → 3분으로 개선
  • Pod가 스케쥴 되기 전부터 이미지를 미리 pull 할 수 있는 DaemonSet을 구성해서 Pod 준비 시간을 더 단축
  • Node Bootstrap에도 이미지를 미리 Pull하도록 구성함

ALB 기반 멀티 클러스터

토스 페이먼츠 사례

  • 장애 대응을 유연하게 하기 위해 EKS 클러스터 이중화
  • AZ 장애를 감지할 수 있는 모니터링 시스템 구축
  • 문제 발생 시 트래픽을 정상 클러스터로 즉시 우회
    • 작업자의 심리적 불안감을 줄여서 개발 민첩성 증가

Istio LocalLB로 비용 절감 및 장애 대응

데브시스터즈 쿠키런:킹덤 사례

  • Global Accelerator 사용으로 글로벌 게임 서버 응답 시간을 줄임
  • Global Accelerator 장애 시 NLB로 전환하도록 아키텍처 구성

  • 게임 서버는 모두 Multi-AZ로 운영
  • 서버간 통신이 많아져서 DTO 비용 증가
  • istio의 Locality LB로 같은 AZ로 트래픽을 보낼 수 있어서 성능 개선 및 DTO 비용 절감
     

 

  • iptables 사용으로 인한 운영 부담과 성능 저하를 개선하기 위해 별도의 CNI 구성
  • DSR, eBPF 사용
  • 프로덕션까지 적용은 안했고, 검토 중

  • Node 장애 시 5분간 Pod 재배치가 안되는 문제로 Shardcake라는 오픈소스 개발
  • kube-apiserver로 지속적으로 Pod 상태를 모니터링해서 비정상 감지시 바로 재배포