목차
EKS on Fargate로 구축한 티맵결제 플랫폼 (2022-04)
원문 정보
- 원문: 결제플랫폼 구축에 EKS on Fargate 적용하기
- 부제: 10편 - AWS에서 MSA 서비스 구축하기
- 매체 · 게시일: 티맵모빌리티 테크노트(브런치) · 2022-04-28
- 저자: 티맵모빌리티 (본문에 저자 미표기)
- 원문 내용을 바탕으로 재구성한 요약입니다.
도입 배경과 Fargate의 장단점
티맵모빌리티 출범 뒤에 새로 만든 서비스는 AWS 위에서 운영되고, 티맵결제도 그중 하나입니다. 결제플랫폼을 처음 세울 때 팀의 고민은 네 가지였습니다. 새 기술을 써 보고 싶다는 것, DevOps 담당이 없다는 것, AWS가 처음이라는 것, 서버 관리를 최대한 줄이고 싶다는 것입니다. 이 조건에서 고른 답이 EKS on Fargate였습니다.
EKS에서 Pod를 올리는 방법은 관리형 노드 그룹, 자체관리형 노드, AWS Fargate의 세 가지이고 섞어 쓸 수 있습니다. Fargate에서는 Pod의 CPU와 메모리만 정하면 그에 맞는 노드가 하나 만들어지고, Pod가 끝나면 노드도 함께 사라집니다. 원문의 예시는 2vCPU, 4GB 노드입니다.
원문이 꼽은 장점은 셋입니다. EC2를 따로 관리하지 않아도 됩니다. 노드와 Pod의 수명이 같아서 재배포만으로 EKS 업그레이드가 반영됩니다. VM 하나에 Pod가 하나뿐이라 다른 Pod의 호스트 리소스에 접근하는 공격에도 안전합니다.
단점은 둘입니다. vCPU와 메모리 조합이 정해져 있어 최대 4vCPU에 메모리 8GB에서 30GB까지만 쓸 수 있습니다. CPU를 많이 쓰는 애플리케이션은 노드 그룹이나 단일 EC2 같은 대안을 찾아야 합니다. 데몬셋도 지원하지 않아 로그 수집은 사이드카 컨테이너로 해야 하고, 두 컨테이너의 합이 같은 자원 한도를 넘을 수 없습니다. 팀은 단점을 받아들일 만하고 장점이 훨씬 크다고 판단했습니다.
클러스터와 ALB 컨트롤러 구성
VPC는 티맵의 기본 형태를 썼습니다. 클러스터는 eksctl에 fargate 옵션을 붙여 만들었고 버전은 1.18이었습니다. 원문은 쿠버네티스 마이너 버전이 약 3개월마다 나오고 12개월 동안 지원되니, 새로 설치할 때는 최신 버전을 따라가라고 권합니다.
이어서 클러스터에 IAM OIDC 공급자를 만들고, ALB 컨트롤러용 IAM 정책과 역할, 서비스 계정을 만들어 연결한 뒤 helm 차트로 AWS Load Balancer Controller를 설치했습니다. 정책 버전이 쿠버네티스 버전과 맞는지 확인해야 합니다. 구축 당시 낮은 버전의 정책을 만들고 높은 버전의 쿠버네티스를 쓰다가 ALB 오류를 겪었다고 합니다. 서브넷을 미리 만들어 쓰면 ALB용 태그를 직접 달아야 한다는 점도 짚었습니다. 서브넷을 지정하지 않으면 자동으로 만들어지고 태그도 붙습니다.
오토스케일과 배포 테스트
오토스케일은 메트릭 서버를 먼저 설치한 뒤 명령 하나로 설정합니다. 원문의 예는 배포 시 최소 3개에서 최대 5개 Pod를 두고, CPU 사용률이 50%를 넘을 때마다 하나씩 늘리는 설정입니다.
부하 중에 배포하면 Pod 수가 어떻게 바뀌는지 세 가지로 실험했습니다.
- 최소 10, 최대 20, replicas 8로 두고 부하를 주어 Pod가 14개까지 늘었을 때 배포하자, 배포 순간 Pod가 8개로 줄었습니다.
- 같은 설정에서 replicas를 비우고 배포하자 Pod가 1개로 줄었습니다. 기존 Pod 수를 기준으로 배포되리라는 기대와 달리 replicas를 1로 둔 것과 같았습니다.
- 최소 1, replicas 10으로 두고 부하 없이 배포하자, 10개가 대기하다가 부하에 맞춰 종료되고 필요한 수만 남았습니다.
원문은 트래픽이 많을 때 배포하면서 Pod가 줄어 요청을 못 받는 일을 막으려면 max와 replicas를 같은 값으로 맞추라고 권합니다.
Datadog 연동과 로그 경로
Datadog은 RBAC을 설정한 뒤 Datadog Agent를 사이드카로 Pod에 넣는 방식으로 연동했습니다. 매니페스트에는 이미지가 둘 들어가며, 두 컨테이너의 CPU 합이 4vCPU를 넘지 않게 했습니다.
로그는 두 단계를 거칩니다. Fargate Pod의 로그는 stdout으로만 내보낼 수 있어서 로그 라우터로 CloudWatch에 보냅니다. 그다음 CloudFormation으로 구성한 Datadog Forwarder가 Lambda로 CloudWatch 로그를 Datadog에 넘깁니다. CloudWatch에서 보면 파일 로그와 형식이 달라 조회가 어려웠습니다. 그래서 애플리케이션이 LoggingEventCompositeJsonEncoder로 JSON 로그를 내게 했고, 라우터에서 불필요한 항목을 걸러 애플리케이션이 찍은 로그만 남겼습니다. 파서와 필터를 구성한 결과 Datadog에서 로그를 볼 수 있었다고 합니다.
원문은 티맵결제가 2021년에 열렸고 아직 개선할 점이 많다는 말로 맺습니다.
원문의 주요 설정값과 테스트 조건
| 항목 | 값 |
|---|---|
| Fargate 노드 예시 | 2vCPU, 메모리 4GB |
| Fargate Pod 한도 | 최대 4vCPU, 메모리 8GB~30GB |
| 클러스터 버전 | 쿠버네티스 1.18 |
| ALB 컨트롤러 요구 버전 | v2.0.0~v2.1.3은 쿠버네티스 1.15 이상, v2.2.0 이상은 1.16 이상 |
| 오토스케일 예시 | 최소 3, 최대 5, CPU 50% 초과 시 하나씩 증가 |
| 배포 테스트 1 | 최소 10, 최대 20, replicas 8, Pod 14개에서 배포 시 8개로 감소 |
| 배포 테스트 2 | 같은 설정에 replicas 미지정, 배포 시 1개로 감소 |
| 배포 테스트 3 | 최소 1, replicas 10, 부하 없이 배포 |