AWS ECS Fargate에서 프로덕션급 멀티티어 애플리케이션을 구축한 방법 (완전한 사례 연구)

Source: Dev.to

프로젝트 요약

시스템은 간단한 두 서비스 아키텍처입니다:

• React 프론트엔드 – Nginx로 제공
• Node.js 백엔드 API

결과: 완전히 프라이빗한 백엔드와 VPC 내부에서 안전하게 통신하는 공개 프론트엔드.

고수준 아키텍처

• Public ALB → 인터넷 트래픽 수신
• Internal ALB → 백엔드로 트래픽 라우팅 (공개 인터넷에 노출되지 않음)

네트워크 설계

• VPC
• 서브넷(퍼블릭 & 프라이빗)
• 라우트 테이블
• 보안 그룹

트래픽 흐름:

1. 인터넷 → Public ALB
2. Public ALB → 프론트엔드 서비스(퍼블릭 서브넷)
3. 프론트엔드 → Internal ALB → 백엔드 서비스(프라이빗 서브넷)

컨테이너 및 Dockerfile

• 프론트엔드: Nginx 멀티‑스테이지 빌드
• 백엔드: Node.js

두 이미지 모두 로컬에서 빌드한 뒤 Amazon ECR에 푸시합니다.

ECR + IAM 설정

• 두 개의 리포지토리: frontend, backend
• ECR에서 이미지를 풀 수 있는 권한을 가진 IAM 역할
• 프라이빗 서브넷에서 이미지 풀 타임아웃을 없애기 위해 ECR용 VPC 엔드포인트 추가

ECS 설계

• 클러스터(Fargate)
• 프론트엔드와 백엔드용 태스크 정의
• 업데이트를 위한 롤링 배포가 가능한 서비스

로드 밸런싱 및 라우팅

• 프론트엔드 서비스는 퍼블릭 ALB에 연결
• 백엔드 서비스는 내부 ALB에 연결
• 프론트엔드는 내부 ALB를 통해 백엔드와 통신

롤링 배포

새 이미지 롤아웃 흐름:

1. 새 이미지를 ECR에 푸시
2. 새 이미지 태그로 태스크 정의 업데이트
3. 서비스가 롤링 업데이트 수행:
   • 새 태스크가 시작되고 ENI가 프라이빗 서브넷에 프로비저닝됨
   • 새 태스크가 내부 ALB에 등록됨
   • 기존 태스크는 배출되고 중지됨

테스트를 통해 ENI 프로비저닝, ALB 등록, 로그 스트리밍, 그리고 정상적인 연결 배출이 확인되었습니다.

배포에서 얻은 주요 지표

• 0개의 퍼블릭 IP가 ECS 태스크에 할당됨(모든 태스크가 프라이빗 서브넷에서 실행)

도전 과제 및 해결책

• ENI 연결 지연 – 태스크 배치 전략을 조정하여 완화
• 이미지 풀 타임아웃 – ECR용 VPC 엔드포인트를 추가해 해결
• ALB 헬스 체크 실패 – 헬스 체크 경로와 임계값을 조정해 해결

배운 점

• Fargate가 프라이빗 서브넷 내에서 ENI를 어떻게 연결하는지
• 프라이빗 이미지 풀을 위한 VPC 엔드포인트 구성의 중요성
• ECS/Fargate에서 무중단 롤링 배포를 위한 전략

이 프로젝트가 중요한 이유

단순히 배포만 한 것이 아니라 실제 클라우드 시스템을 깊이 파고들었습니다—장애 처리, 네트워킹 디버깅, IAM 제한 관리, 필요에 따라 아키텍처 재설계 등. 다음을 결합했습니다:

• VPC 네트워킹 기본
• 컨테이너 이미지 라이프사이클(Docker → ECR → Fargate)
• 서비스 디스커버리 및 로드 밸런싱
• 자동화된 프로덕션 급 롤아웃 프로세스

저장소

GitHub – node-app-jenkins1

결론

DevOps나 AWS를 배우는 누구든 이와 같은 프로젝트에 도전해 보세요. 실제 시스템을 설계하는 엔지니어처럼 사고하게 만들고, 단순히 명령을 실행하는 수준을 넘어서는 자신감을 키워줍니다.

비슷한 프로젝트를 진행 중이거나 클라우드 아키텍처에 대해 논의하고 싶다면 언제든지 연락 주세요.