🎯 아키텍처 진화 분석 보고서: EC2 모놀리식에서 ECS, 그리고 EKS로의 도약
📑 목차
- 1. 아키텍처 진화 배경: 모놀리식 EC2의 한계 (Phase 1)
- 2. 중간 기착지로서의 ECS Fargate: 실용주의적 접근 (Phase 2)
- 3. 아키텍처 격리의 대가: 인프라 비용과 구조적 결합도
- 4. Phase 3: EKS 도입의 당위성과 기술적 맹점 분석
보고서 개요
본 보고서는 단일 EC2 인스턴스 환경에서 4개의 마이크로서비스(ECS Fargate)로 인프라를 분리하는 과정에서 발생한 기술적 의사결정과 트레이드오프(Trade-off)를 분석합니다. 무분별한 최신 기술(EKS) 도입을 지양하고, 시스템의 성장 단계에 맞춘 실용적 아키텍처(ECS)를 거쳐, 종국에 EKS로 나아가야만 하는 인프라 엔지니어링의 본질적 맥락을 다룹니다.
1. 아키텍처 진화 배경: 모놀리식 EC2의 한계 (Phase 1)
💡 초기 구성 및 한계점
초기 시스템은 단일 EC2 인스턴스 내에 모든 애플리케이션 모듈이 통합된 모놀리식(Monolithic) 구조였습니다. 초기 릴리즈 속도는 확보했으나, 서비스 규모 확장에 따라 다음과 같은 치명적 병목이 발생했습니다.
- 확장의 비효율성: 특정 도메인(예: 주문)에 트래픽이 집중되어도, 독립적인 스케일 아웃(Scale-out)이 불가능하여 서버 전체 스펙을 강제로 상향(Scale-up)해야 하는 리소스 낭비가 발생했습니다.
- 장애 격리(Fault Isolation) 실패: 단일 장애점(SPOF) 리스크가 컸으며, 한 모듈의 메모리 누수가 전체 시스템 다운으로 이어졌습니다.
- 맨아워(Man-Hour)의 심각한 누수:
user_data.sh스크립트 수정, SSH 직접 접속을 통한 수동 환경 구성 등 인프라 운영 오버헤드가 극심하여 비즈니스 로직 개발을 저해했습니다.
2. 중간 기착지로서의 ECS Fargate: 실용주의적 접근 (Phase 2)
MSA로의 전환 시점에서 산업계의 표준인 쿠버네티스(EKS) 도입이 가장 먼저 검토되었으나, 기술적 성숙도와 관리 비용을 고려하여 ECS Fargate를 전략적으로 채택했습니다.
EKS 맹목적 도입 지양과 분산 시스템의 본질적 이해
“EKS를 써봤다”는 것이 곧 “쿠버네티스와 분산 시스템을 이해했다”를 의미하지 않습니다. ECS Fargate를 통해 오케스트레이션과 컨트롤 플레인 관리 부담을 AWS에 위임함으로써, 우리는 인프라 관리가 아닌 분산 시스템 아키텍처 자체의 난제 해결에 맨아워를 집중할 수 있었습니다.
🎯 ECS 환경에서의 주요 기술적 성취
| 핵심 영역 | 구현 내용 및 성과 |
|---|---|
| 서비스 디스커버리 | IP 하드코딩 탈피. AWS Cloud Map을 통한 동적 서비스 탐색 및 라우팅 구현. |
| 통신 및 프로토콜 | 마이크로서비스 간 지연 시간 최소화를 위한 gRPC 기반 내부 통신망 구축. |
| 인프라 자동화(IaC) | Terraform을 통한 100% 인프라 코드화. Task Definition 선언만으로 프로비저닝을 완료하여 운영 오버헤드 혁신적 감소. |
⚙️ CI/CD 파이프라인의 명암: 자동화의 축복과 로그의 파편화
서비스가 4개로 분리되면서, 기존처럼 EC2에 붙어 수동으로 배포하는 방식은 ‘고통’ 그 자체가 되었습니다. 이를 해결하기 위해 GitHub main 브랜치 병합 시 자동으로 ECR 이미지 빌드 및 ECS 롤링 업데이트가 트리거되는 배포 자동화를 구축했습니다.
- GitHub Actions 대신 AWS CodePipeline을 선택한 이유: 단순 스크립트 실행은 GitHub Actions가 편리할 수 있으나, AWS 생태계 네이티브 통합이라는 관점에서 CodePipeline이 압도적 우위를 가졌습니다. GitHub 쪽에 장기(Long-lived) AWS 자격 증명(Access Key)을 노출할 필요 없이 IAM Role 기반으로 안전하게 통신할 수 있었고, ECS의 안정적인 롤링 배포 상태(Health Check)를 파이프라인 단에서 훨씬 정교하게 제어할 수 있었습니다.
- 운영의 맹점 (불편한 진실):
배포의 고통은 자동화로 해소되었으나, 4개의 서비스 컨테이너가 쏟아내는 로그를 AWS CloudWatch Log Group에서 각각 찾아 헤매야 하는 **‘로그의 파편화’**는 모놀리식 시절(단일 파일
tail -f)보다 현저히 불편했습니다. 분산 환경에서의 로깅과 추적(Observability) 체계가 반드시 뒷받침되어야 함을 체감한 순간이었습니다.
3. 아키텍처 격리의 대가: 인프라 비용과 구조적 결합도
아키텍처의 고도화는 무상으로 이루어지지 않았으며, 명확한 **청구서(Trade-off)**를 수반했습니다.
🚨 1. 인프라 비용의 구조적 증가 (NAT Gateway)
컨테이너를 완전한 Private Subnet에 격리하는 Zero-Trust 보안 모델을 채택하면서, 외부 API 통신 및 도커 이미지 풀링을 위해 NAT Gateway 배치가 강제되었습니다. 이는 기존 EC2 환경에서는 발생하지 않던 막대한 고정 비용 및 데이터 처리 비용의 증가를 초래했습니다.
🚨 2. 분산된 모놀리스(Distributed Monolith) 리스크
물리적 컨테이너는 4개로 분리되었으나, 단일 RDS 인스턴스를 공유하고 동기식(gRPC/HTTP) 통신으로 강하게 묶여 있습니다. 서킷 브레이커(Circuit Breaker) 등의 방어 기제가 부재한 현 구조에서는 특정 서비스의 지연이 전체 시스템으로 파급되는 ‘연쇄 장애(Cascading Failure)’ 위험을 내포하고 있습니다.
4. Phase 3: EKS 도입의 당위성과 기술적 맹점 분석
EC2에서 수동으로 서버를 구축하던 시절을 지나, ECS를 통해 컨테이너 오케스트레이션의 편의성(맨아워 절감)을 뼈저리게 체감했습니다. 그러나 ECS의 추상화된 환경은 결국 MSA의 고질적인 관리 난제와 누수 문제를 근본적으로 해결하지 못한다는 한계에 봉착했습니다. 이러한 한계점의 명확한 인지가 곧 EKS(Phase 3)로 도약해야 하는 당위성입니다.
💎 돈으로 사는 제어력, MSA의 복잡성을 통제하다
EKS는 클러스터 유지비(Control Plane 비용)와 가파른 학습 곡선이라는 초기 투자 비용이 큽니다. 하지만 이는 단순한 ‘운영 편의성 증가’를 넘어, MSA 아키텍처가 필연적으로 수반하는 복잡성과 관리의 누수를 자본(인프라 비용)을 통해 시스템적 제어력으로 치환하는 과정입니다.
- Karpenter: 무거운 ASG(Auto Scaling Group) 관리를 탈피하고, 트래픽 증감에 맞춰 최적의 노드를 수 초 내에 프로비저닝함으로써 리소스 누수를 근본적으로 차단합니다.
- Istio (Service Mesh): 애플리케이션 코드 수정 없이 인프라 레벨(Sidecar)에서 서킷 브레이커와 세밀한 트래픽 제어를 수행하여 ‘분산된 모놀리스’의 연쇄 장애 리스크를 원천 봉쇄합니다.
- ArgoCD (GitOps): 선언적 인프라 상태를 동기화하여 지속적 배포의 안정성을 보장하며 개발자의 배포 멘탈 모델을 단순화합니다.
⚠️ EKS와 CI/CD 도구의 맹점 (Silver Bullet은 없다)
그러나 EKS 자체나 화려한 CI/CD 툴체인이 모든 인프라 문제를 마법처럼 해결해 주는 것은 아닙니다.
- 서비스 패턴의 명확성: 트래픽 패턴과 서비스 도메인이 명확하게 식별되고 분리된 조직일수록 IaC와 EKS 노드 확장의 시너지를 극대화할 수 있습니다. 이 과정에서 아껴지는 맨아워는 비즈니스 로직 고도화로 선순환됩니다.
- 복잡성의 역습: 반대로 비즈니스 로직이 파편화되고 아키텍처 기반(결합도 제어 등)이 부실한 상태에서 섣불리 EKS를 도입하면, 오히려 쿠버네티스의 방대한 설정(YAML)과 네트워크 복잡성에 짓눌려 ‘인프라 문제의 꽃이 피는’ 최악의 상황을 맞이하게 됩니다. 기술 부채에 짓눌려 현상 유지조차 버거워지는 것입니다.
결론 및 시사점
ECS는 기술적 한계를 체험하기 위한 훌륭한 샌드박스였습니다. 우리는 EC2에서 ECS로의 진화를 통해 인프라 비용 대비 맨아워(Man-Hour) 절감의 가치를 실측했으며, ECS의 한계에 부딪혀 봄으로써 EKS가 왜 필요한지 스스로 증명해 냈습니다.
“EKS를 도입했다”는 표면적 사실보다 중요한 것은, 팽창하는 인프라의 혼돈을 시스템적으로 통제하기 위한 기술적 맥락을 이해하고 있다는 점입니다. EKS는 단지 더 좋은 기술이라서가 아니라, 비즈니스 성장을 감당하기 위한 필연적 결단입니다.