Spring 7기 프로젝트/모임 플렛폼 프로젝트

확장성을 고려한 ECS 기반 배포 전략

JuNo_12 2025. 8. 14. 21:55

프로젝트 아키텍처

모놀리스 구조에서의 도메인 분리

저희 프로젝트는 모놀리스 구조를 기반으로 하되, 도메인 간 결합도를 최소화하는 방향으로 설계했습니다. 각 도메인은 메시지 큐(RabbitMQ)와 WebClient를 통해 통신하며, 이는 향후 마이크로서비스로의 분리를 용이하게 합니다.

 

도메인 분리 전략:

  • 비동기 통신: RabbitMQ를 활용한 이벤트 기반 아키텍처
  • 비동기 / 블로킹 통신: WebClient를 통한 내부 API 호출
  • 독립적 배포 준비: 각 도메인별 모듈화로 서비스 분리 대응 가능

 

확장성을 위한 인프라 선택

트래픽 증가에 대비해 ECS(Elastic Container Service) + Fargate를 선택했습니다. 단순한 EC2 배포 대비 다음과 같은 장점이 있습니다:

 

ECS 선택 이유:

  1. 유연한 확장성: 도메인별 서비스 분리 시 즉시 대응 가능
  2. 무중단 배포: 롤링 업데이트를 통한 서비스 연속성 보장
  3. 자동 스케일링: 트래픽에 따른 컨테이너 자동 증감
  4. 관리 부담 감소: Fargate를 통한 서버리스 컨테이너 운영

인프라 구성

애플리케이션 계층 - ECS Fargate

Spring Boot 애플리케이션은 ECS Fargate에서 운영됩니다:

  • 컨테이너 오케스트레이션: ECS 클러스터 기반 관리
  • 서버리스 실행: Fargate를 통한 인프라 관리 위임
  • 오토 스케일링: CPU/메모리 사용률 기반 레플리카 조정
  • 로드 밸런싱: ALB를 통한 트래픽 분산

 

데이터 계층 - EC2 인스턴스

비용 효율성과 안정성을 고려하여 5개의 EC2 인스턴스에 데이터 인프라를 분산 배치했습니다:

인스턴스 구성:

  1. MySQL: 메인 데이터베이스
  2. Redis: 캐싱 및 세션 관리
  3. RabbitMQ: 메시지 큐잉 시스템
  4. Elasticsearch: 검색 엔진
  5. 모니터링 스택: Grafana, Loki, Prometheus, OpenTelemetry

분리 기준:

  • 성능 특성: 각 서비스의 리소스 요구사항 차이
  • 운영 주기: 인프라 서비스는 한 번 설정 후 변경 빈도 낮음
  • 비용 최적화: 매니지드 서비스 대비 직접 운영으로 비용 절감

배포 파이프라인

GitHub Actions 기반 CI/CD

자동화된 배포 프로세스:

# 주요 배포 단계
1. 코드 체크아웃 및 Java 환경 설정
2. Flyway를 통한 DB 마이그레이션
3. Spring Boot 애플리케이션 빌드
4. Docker 이미지 생성 및 ECR 푸시
5. ECS Task Definition 업데이트
6. 무중단 롤링 배포 실행

핵심 특징:

  • 멀티 플랫폼 지원: ARM Mac에서도 linux/amd64 이미지 빌드
  • 환경변수 관리: GitHub Secrets를 통한 보안 설정
  • 배포 안정성: ECS 서비스 안정성 확인 후 완료

 

컨테이너 이미지 관리

ECR(Elastic Container Registry) 활용:

  • Git 커밋 해시를 이미지 태그로 사용하여 버전 추적
  • latest 태그와 병행 운영으로 유연한 배포 지원
  • 이미지 스캔 및 수명 주기 관리

비용 최적화 전략

하이브리드 인프라 운영

ECS vs EC2 분리 기준:

서비스 유형 배포 방식 이유
Spring Boot ECS Fargate 빈번한 배포, 오토스케일링 필요
MySQL, Redis EC2 안정적 운영, 비용 효율성
RabbitMQ EC2 설정 후 변경 빈도 낮음
Elasticsearch EC2 리소스 집약적, 전용 인스턴스 필요

 

스케일링 전략

수평적 확장성:

  • 현재: 모놀리스 구조에서 컨테이너 레플리카 증가
  • 미래: 도메인별 서비스 분리 시 개별 스케일링

수직적 확장성:

  • EC2 인스턴스 타입 조정을 통한 성능 향상
  • ECS 태스크 리소스 조정

운영 모니터링

통합 모니터링 시스템

모니터링 스택 구성:

  • Prometheus: 메트릭 수집 및 저장
  • Grafana: 시각화 대시보드
  • Loki: 로그 수집 및 분석
  • OpenTelemetry: 분산 추적

주요 모니터링 지표:

  • 애플리케이션 성능: 응답시간, 처리량, 에러율
  • 인프라 리소스: CPU, 메모리, 디스크, 네트워크
  • 비즈니스 지표: 사용자 활동, 거래량

향후 확장 계획

마이크로서비스 전환 대비

현재 구조의 장점:

  • 도메인별 모듈화로 서비스 분리 준비 완료
  • 메시지 큐 기반 비동기 통신 구조
  • 컨테이너 기반 배포로 개별 서비스 운영 가능

전환 시나리오:

  1. 1단계: 멀티 모듈 모놀리스로 독립 배포
  2. 2단계: 도메인별 서비스 분리
  3. 3단계: 완전한 마이크로서비스 아키텍처

 

기술적 고려사항

데이터 일관성:

  • 현재: 단일 데이터베이스 트랜잭션
  • 향후: Saga 패턴 또는 이벤트 소싱 도입

서비스 메시:

  • API Gateway 도입 검토
  • 서비스간 통신 보안 강화
  • 분산 추적 시스템 확장

결론

이번 프로젝트에서는 초기 개발 속도와 향후 확장성을 모두 고려한 인프라 전략을 수립했습니다. 모놀리스 구조의 장점을 유지하면서도 마이크로서비스로의 전환을 대비한 설계를 통해, 비즈니스 성장에 따른 기술적 요구사항에 유연하게 대응할 수 있는 기반을 마련했습니다.

 

특히 ECS Fargate와 EC2의 하이브리드 운영을 통해 비용 효율성과 운영 안정성을 동시에 확보했으며, 완전 자동화된 CI/CD 파이프라인으로 개발 생산성을 향상시켰습니다.