📚 목차
1. MSA란 무엇인가? 왜 필요한가?
1.1 MSA(Microservice Architecture)란?
MSA는 하나의 애플리케이션을 여러 개의 독립적인 소규모 서비스로 분리하여 개발, 배포, 운영하는 아키텍처 스타일이다.
각 서비스는 자신의 데이터베이스와 비즈니스 로직을 가지고 있으며, 다른 서비스와는 네트워크를 통해 통신한다.
MSA의 핵심 특징
- 독립 배포: 서비스 단위로 개발 및 배포가 가능하다.
- 장애 격리: 특정 서비스에 장애가 발생해도 전체 시스템에는 영향을 최소화할 수 있다.
- 확장성: 필요한 서비스만 선택적으로 확장할 수 있어 리소스 최적화가 가능하다.
- 기술 스택 다양성: 서비스마다 다른 언어나 프레임워크를 사용할 수 있다.
1.2 Monolith와 MSA 비교
| 항목 | Monolith Architecture | Microservice Architecture |
|---|---|---|
| 개발 규모 | 하나의 거대한 애플리케이션 | 작은 서비스들의 집합 |
| 배포 방식 | 전체 재배포 | 개별 서비스만 배포 가능 |
| 장애 영향 범위 | 전체 시스템 다운 가능성 | 부분 장애로 격리 가능 |
| 확장 방법 | 수직 확장(Scale-up) | 수평 확장(Scale-out) |
| 기술 선택 자유도 | 제한적 | 유연함 |
1.3 왜 MSA를 도입하는가?
- 시스템이 복잡해지고, 여러 팀이 동시에 개발해야 할 경우 Monolith는 생산성과 유지보수성의 한계에 부딪힌다.
- 빠른 시장 대응, 독립적인 서비스 개선이 필요한 경우 MSA 구조가 효과적이다.
- 특히 클라우드 환경(AWS, GCP 등)에서는 수평 확장이 필수인데, 이를 위해서는 자연스럽게 MSA가 필요해진다.
요약
MSA는 복잡하고 관리할 것이 많지만,
확장성, 장애 대응성, 개발 속도 면에서 현대 애플리케이션에 매우 적합한 아키텍처이다.
2. MSA에서 기반 인프라 컴포넌트의 역할
2.1 MSA에서는 왜 인프라 컴포넌트가 필요한가?
MSA 구조에서는 애플리케이션을 여러 개의 독립적인 서비스로 나눈다.
각 서비스가 독립적으로 동작하려면, 서비스 간 연결과 설정을 지원하는 기반 인프라가 필수적이다.
즉,
"서비스만 쪼개면 MSA 완성"이 아니다.
서비스를 서로 이어주고, 관리하는 인프라 레이어가 반드시 필요하다.
2.2 인프라 컴포넌트 구성 요소
(1) Eureka Server - 서비스 디스커버리
- Netflix OSS 프로젝트의 일부로, Spring Cloud에서 자주 사용되는 서비스 디스커버리 구현체이다.
- 서비스들은 고정 IP가 아니라 동적으로 할당되는 IP/포트를 사용할 수 있다.
- 각각의 서비스가 자신을 Eureka Server에 등록한다.
- 다른 서비스들은 Eureka를 통해 서비스 이름 기반으로 통신한다.
💡 대안 솔루션
Eureka 외에도 Consul, etcd, Zookeeper 등 다양한 서비스 디스커버리 솔루션이 있으며, 프로젝트 요구사항에 따라 선택할 수 있다.
Eureka는 MSA의 핵심 연결고리다.
(2) Config Server - 설정 중앙 집중화
- 수십 개의 서비스가 각자
application.yml을 들고 있으면 관리가 지옥이 된다. - Config Server를 두고, 모든 서비스는 설정을 Config Server로부터 받아온다.
- 운영 환경에서는 Git 저장소 기반
- 설정 변경 이력 관리 가능
- 환경별(dev, prod 등) 설정 분리 용이
- 설정 변경 시 실시간 적용 가능 (Spring Cloud Bus 연동 시)
- 개발/테스트 환경에서는 native 모드
- Git을 안 쓰고, 서버 로컬 디렉토리에서 설정을 읽는다.
- 빠른 개발/테스트 단계에서는 매우 효율적이다.
Config Server 없이?
서비스별 설정 불일치, 복잡성 증가, 배포마다 설정 수동 수정 → 관리 힘들다
Config Server는 서비스 설정 통제의 중심이다.
(3) API Gateway - 요청 통합 및 라우팅
- 클라이언트가 모든 서비스를 직접 호출하면 네트워크 복잡성 폭발
- Gateway가 모든 외부 요청을 받아서
- 어떤 요청을 어떤 서비스로 라우팅할지 결정
- 인증/인가, 로깅, 필터링 등을 사전 처리한다.
Gateway 없이?
클라이언트가 10개의 서비스를 각각 알아야 한다 → 관리 불가능
Gateway는 시스템의 '진입점'이다.
2.3 인프라 컴포넌트 관계 그림
[Client]
↓
[API Gateway]
↓
[MSA Services] ⟷ [MSA Services] ⟷ [MSA Services]
↑ ↑ ↑
⟷ ⟷ ⟷ ⟷ ⟷ [Eureka Server] ⟷ ⟷ ⟷ ⟷ ⟷
↑
[Config Server]- 클라이언트는 Gateway만 알고 있다.
- Gateway는 Eureka를 통해 서비스 위치를 찾는다.
- 서비스들은 Config Server에서 설정을 받아 동작한다.
- 서비스들은 서로 직접 통신하거나 Eureka를 통해 다른 서비스를 찾아 통신한다.
2.4 인프라 컴포넌트 구축 순서
- Config Server를 가장 먼저 띄운다. (서비스 설정 관리)
- Eureka Server를 띄운다. (서비스 디스커버리 준비)
- API Gateway를 띄운다. (외부 요청을 받을 준비)
- 각 서비스들은 Config를 받아 초기화 → Eureka에 등록 → Gateway를 통해 접근 가능
