우리가 아직 EKS로 이동하지 않은 이유: 프로덕션에서 Kubernetes 대신 ECS 선택
Source: Dev.to
우리가 피하고 싶었던 “Kubernetes 세금”
Kubernetes는 훌륭하지만 도구와 유지보수에 상당한 투자가 필요합니다. EKS를 프로덕션에서 제대로 운영하려면 단순히 컨테이너를 관리하는 것이 아니라 플랫폼을 관리하는 것입니다. 다음이 필요합니다:
- GitOps 도구: 배포를 위한 ArgoCD 또는 FluxCD.
- 관측성: 로그 전송을 위한 Fluentd 등.
- Ingress 컨트롤러: NGINX 또는 ALB 컨트롤러.
- 보안: 컨트롤 플레인 및 워커 노드의 지속적인 패치.
우리 팀은 인프라 파이프라인을 관리하는 것이 아니라 애플리케이션 코드를 100 % 배포하는 데 집중하고 싶었습니다.
우리의 하이브리드 ECS 아키텍처
우리는 서버리스와 프로비저닝된 컴퓨트를 모두 활용하는 하이브리드 ECS 전략을 설계했습니다.
1. 무상태 워크로드를 위한 Fargate
주 애플리케이션 서버와 Sidekiq 백그라운드 워커는 ECS Fargate를 사용했습니다.
- 관리할 서버가 없음: OS 패치나 인스턴스 스케일링이 필요 없습니다.
- 올바른 사이징: 작업이 실제로 사용하는 vCPU와 RAM에 대해서만 비용을 지불합니다.
- 확장성: 필요 시 수천 개의 컨테이너를 시작하는 무거운 작업을 Fargate가 처리합니다.
2. 크론 작업을 위한 EC2 Launch Type
우리는 100 % Fargate만 사용하지 않았습니다. 스케줄된 크론 작업은 EC2 Launch Type을 유지했습니다.
- 왜? 크론 작업은 자주 실행되고 동일한 베이스 이미지를 반복해서 사용합니다.
- 비용 해킹: EC2 인스턴스에서 실행하면 Docker 레이어를 로컬에 캐시할 수 있어 ECR에서의 데이터 전송 비용을 크게 줄이고 시작 시간을 단축할 수 있습니다—이는 빈번하고 짧은 수명의 작업에 대해 Fargate가 효율적으로 지원하지 못합니다.
스택: 간단하고 관리형
우리는 컴퓨트 레이어를 순수하게 일시적인 상태로 유지하기 위해 상태 관리를 AWS 관리형 서비스에 맡겼습니다:
- 데이터베이스: Amazon RDS for PostgreSQL.
- 캐싱: Amazon ElastiCache (Redis).
CI/CD: 복잡성 건너뛰기
가장 큰 장점 중 하나는 ArgoCD나 Flux와 같은 “GitOps” 복잡성을 피한 것이었습니다. 우리의 파이프라인은 간단한 GitHub Actions 워크플로우입니다:
- Build: Docker 이미지 생성.
- Scan: 보안 취약점 스캔 실행.
- Push: ECR에 업로드.
- Deploy: ECS Task Definition을 업데이트하고 새 배포를 강제 실행.
그게 전부입니다. 별도의 동기화 서버도 없고, 복잡한 CRD도 없으며, Helm 차트 관리도 없습니다. 파이프라인은 견고하고 디버깅이 쉬우며 유지보수가 전혀 필요하지 않습니다.
결론: 시간은 돈
ECS를 선택함으로써 우리는:
- 학습 곡선 건너뛰기: 팀이
kubectl, 매니페스트, 클러스터 네트워킹을 배울 필요가 없습니다. - 운영 오버헤드 감소: 노드 패치, 컨트롤 플레인 업그레이드가 없습니다.
- 비용 절감: EKS 컨트롤 플레인 비용($73 / 월·클러스터)이나 워커 노드의 시스템 팟 오버헤드가 없습니다.
향후 커스텀 네트워킹이나 서비스 메시와 같은 요구사항이 복잡해지면 EKS로 전환할 수도 있습니다. 하지만 현재는 ECS가 안정적이고 고성능의 프로덕션 환경을 운영하는 데 가장 적합하며, 우리가 신경 써야 할 것은 오직 애플리케이션 코드뿐입니다.
때때로 가장 좋은 엔지니어링 결정은 지루한 선택일 때가 있습니다.