AWS ECS 기반 MSA 구축 시 서비스 디스커버리 방식 비교

안녕하세요. 이번 포스팅에서는 AWS ECS Fargate 환경에서 마이크로서비스 아키텍처(MSA)를 구축할 때 고민했던 서비스 디스커버리 방식에 대해 공유하고자 합니다.

프로젝트 배경

저희 팀은 음악 크라우드펀딩 플랫폼을 MSA로 구축하고 있으며, 다음과 같은 환경에서 개발하고 있습니다.

• 기술 스택: Spring Boot (Java 21), AWS ECS Fargate
• 서비스 구성: 5개의 마이크로서비스 (Funding, Payment, Reward 등)
• 예상 트래픽: DAU 50,000 ~ 100,000명, 피크 타임 TPS 5,000 ~ 10,000
• 프로젝트 기간: 1개월
• 팀 구성: 4명

이러한 환경에서 서비스 간 통신을 어떻게 구성할지 고민하게 되었고, 3가지 방식을 비교 분석했습니다.

제가 생각한 우리 서비스가 인프라에서 가져가야할 1순위는 '비용 및 운영 관리 부담 감소' 였습니다.

---

비교 대상 방식

1. Eureka Server 기반 (클라이언트 사이드 로드밸런싱)

Spring Cloud Netflix Eureka를 활용한 전통적인 MSA 서비스 디스커버리 방식입니다.

아키텍처:

---

[외부 클라이언트]
    ↓
[GateWay]
    ↓
[Public ALB] → 각 마이크로서비스
    ↓
[Eureka Server] ← 서비스 등록/조회
    ↓
서비스 간 직접 통신 (클라이언트 사이드 로드밸런싱)

---

 

장점으로는

1. Spring Cloud 생태계와 완벽한 통합

2. 클라이언트 사이드 로드밸런싱 학습 가능

3. 클라우드 벤더 독립적 (벤더 락인 방지)

등이 있습니다.

 

반면, 단점으로는

1. Eureka Server를 별도로 운영해야 함 (관리 포인트 증가)

2. Fargate 환경에서 Eureka Server 비용 추가 ($41/월)

3. 짧은 프로젝트 기간에 추가 학습 곡선

4. ECS와의 통합이 네이티브하지 않음

등의 단점이 있습니다.

 

예상 비용으로는 달에 41.45USD 가 나옵니다.

---

2. ALB 기반 (서버 사이드 로드밸런싱)

Application Load Balancer를 활용하여 모든 트래픽을 처리하는 방식입니다.

아키텍처:

---

[외부 클라이언트]
    ↓
[Public ALB] → 각 마이크로서비스
    ↓
[GateWay]
    ↓
[Private ALB] → 각 마이크로서비스
    ↓
서비스 간 통신도 ALB를 통해 라우팅

---

 

장점으로는

1. 구현이 가장 간단함 (추가 설정 거의 없음)

2. AWS 네이티브 서비스로 안정적

3. 별도의 디스커버리 서버 불필요

4. ECS Target Group과 자동 통합

5. 이미 ALB를 사용 중

등이 있습니다.

 

반면 단점으로는

1. 레이턴시 증가 (서비스간 통신 시 매번 Internal ALB를 거침)

예상 비용으로는 달에 고정비용(17.5 + 1.40) = 18.9USD 가 나옵니다.

---

3. AWS Cloud Map 기반

AWS의 네이티브 서비스 디스커버리 솔루션을 활용한 방식입니다.

아키텍처:

---

[외부 클라이언트]
    ↓
[GateWay]
    ↓
[Public ALB] → 각 마이크로서비스
    ↓
[Cloud Map] ← 서비스 등록/조회 (DNS 또는 API)
    ↓
서비스 간 직접 통신

---

 

장점으로는

1. ECS와 완벽한 통합 (체크박스 하나로 설정)

2. 서버리스 방식 (관리할 서버 없음)

3. 서비스 간 직접 통신으로 빠른 응답

4. 저렴한 비용 ($12/월)

5. DNS 기반 또는 API 기반 선택 가능

등이 있습니다.

 

반면에, 단점으로는

1. 인프라가 AWS 클라우드에 종속됨 (다른 클라우드로 이동 시 변경 필요)

2. Spring Cloud와의 통합이 Eureka만큼 자연스럽지 않음

3. 국내 참고 자료가 상대적으로 적음

 

예상 비용으로는 달에 11.8125USD 가 나옵니다.

---

저희가 ALB 방식을 선택한 이유

여러 방식을 비교 검토한 결과, 저희 팀은 2번 ALB 기반 방식을 선택했습니다. 그 이유로는,

 

✅ 구현 단순함 - application.yml 설정만으로 즉시 사용
✅ 팀 친숙도 - 모든 팀원이 ALB 사용 경험 보유
✅ 안정성 - AWS에서 검증된 서비스
✅ 1개월 프로젝트 - 레이턴시 5ms, 비용도 Eureka 서버를 관리하는것보다 적게 나오고 감당 가능한 수준

등이 있습니다.

---

마치며

이번 포스팅에서는 ECS Fargate 환경에서 MSA 서비스 디스커버리 방식을 비교하고, 저희 팀이 ALB 기반 방식을 선택한 이유를 공유했습니다.

 

물론, 정답은 없으며, 프로젝트 상황에 맞는 선택이 중요하고, 짧은 기간에는 단순함이 최고의 아키텍처라고 생각합니다. 비용뿐만 아니라 팀의 역량과 학습 곡선도 고려해야 합니다.

 

여러분의 프로젝트에서는 어떤 방식을 선택하시겠습니까? 댓글로 의견을 나눠주시면 감사하겠습니다!

---

참고 자료:

• AWS ECS Service Discovery 공식 문서
• Spring Cloud Netflix Eureka 공식 문서
• AWS Cloud Map 가격 정책