ECS 배포
도입 이유
- 기존의 단일 서비스 아키텍처는 모든 기능이 하나의 애플리케이션에 통합되어 있어 확장성과 유지보수가 어려웠습니다.
- 확장성과 유연성 향상: 각각의 마이크로서비스가 독립적으로 배포되고 확장될 수 있기 때문에 시스템의 확장성과 유연성이 향상됩니다.
- 서비스 분리를 통한 개발 용이성: 각 마이크로서비스는 특정 기능을 수행하므로 서비스 간의 독립성이 높아집니다. 이는 개발팀이 각 서비스를 별도로 관리하고 개발할 수 있게 해줍니다.
- 서비스간 장애 격리 가능: 특정 서비스가 장애가 나더라도 전체 시스템이 영향을 받지 않도록 구성할 수 있습니다.
기대 효과
- 서비스 성능 및 가용성 향상: 각 마이크로서비스가 독립적으로 운영되므로 전체 시스템의 성능과 가용성이 향상됩니다.
- 비용 절감 및 자원 효율화: MSA는 필요한 서비스만 확장할 수 있기 때문에 자원을 효율적으로 사용할 수 있습니다.
- 배포 유연성 확보: 서비스 단위로 빠른 배포가 가능하며, 장애 발생 시 영향 범위가 작아 Rollback이 쉽습니다.
주의 사항
- 처음부터 MSA를 통한 프로젝트 구축은 짧은 프로젝트 기간에 실패할 가능성이 매우 높습니다.
- 그래서 최소한의 모놀리식 구조를 먼저 구축하고 이후 MSA로 전환했습니다.
- 서비스가 분리될수록 통신 비용과 네트워크 구조가 복잡해지기 때문에, 서비스 간 공통 기능(API Gateway, 인증, 로깅 등)을 명확히 정의해야 합니다.
기존 아키텍처의 비용 문제
- 기존에는 ECR과 ECS를 사용하여 MSA 방식으로 서비스를 배포하고 운영했습니다.
- 하지만 Fargate 단가와 서비스별 컨테이너 운영 비용이 누적되면서, 프로젝트 규모 대비 과도한 비용 지출이 발생했습니다.
- 또한 서비스 단위로 스케일링이 가능하다는 장점이 있었지만, 실제 프로젝트 트래픽 특성상 지나치게 과한 인프라였기 때문에 비용 효율성이 낮았습니다.
- 비용 절감을 위해 임시로 Docker Hub를 사용하고 EC2 인스턴스에 5개의 컨테이너를 직접 배포하는 방식을 도입했습니다.
EC2 배포
보완 설명
- EC2 내부에 Front, User, Product, Order, Review 총 5개의 컨테이너를 직접 띄워 단일 서버에서 운영하는 구조입니다.
- 로드밸런서는 외부 HTTPS 트래픽을 받아 EC2 인스턴스로 전달합니다.
- 데이터베이스(RDS)와 캐시(ElastiCache)는 Private Subnet에 배치하여 보안을 강화했습니다.
- 리뷰 이미지 저장은 S3와 연동하며, 로그 수집은 Logstash → Elasticsearch → Kibana 순으로 처리합니다.
- 기존 MSA 구조의 장점(서비스 독립성)을 어느 정도 유지하면서도 비용을 크게 낮춘 구조입니다.