마이크로서비스 아키텍처란?
정의
MSA는 애플리케이션을 작고 자율적인 서비스들로 나누고,
이들 서비스를 독립적으로 배포, 운영, 확장할 수 있게 만드는 아키텍처 스타일입니다.
MSA vs 모놀리식 비교
| 항목 |
모놀리식(Monolith) |
마이크로서비스(MSA) |
| 구조 |
하나의 큰 애플리케이션 |
작고 독립적인 서비스들의 조합 |
| 배포 |
전체 재배포 |
서비스 단위 배포 가능 |
| 개발 |
협업 어려움 (코드 충돌↑) |
팀별 서비스 담당 가능 |
| 장애 영향 |
전체 다운 가능성 ↑ |
서비스 격리로 영향 ↓ |
| 확장성 |
수직 확장 |
수평 확장 가능 |
예시 시스템 구성
예: 쇼핑몰 시스템을 MSA로 설계 시
마이크로서비스
|
역할 |
| 회원 서비스 |
회원 가입, 로그인 |
| 상품 서비스 |
상품 등록, 조회 |
| 주문 서비스 |
주문 생성, 결제 처리 |
| 배송 서비스 |
배송 상태 관리 |
| 알림 서비스 |
이메일, 문자 발송 |
| API Gateway |
프론트엔드 진입점 |
스프링 부트 기반 MSA 필수 기술
기술
|
설명 |
| Spring Boot |
각 서비스의 기본 개발 프레임워크 |
| Spring Cloud |
마이크로서비스 인프라 지원 (등록, 라우팅, 구성 등) |
| Eureka |
서비스 등록/탐색(Discovery Service) |
| Spring Cloud Gateway |
API 게이트웨이 역할 |
| Feign Client |
서비스 간 통신 (내부 HTTP 호출 추상화) |
| Config Server |
중앙화된 환경 설정 관리 |
| Circuit Breaker |
장애 격리 (Resilience4j 등) |
| RabbitMQ/Kafka |
비동기 메시지 처리 |
| JWT + OAuth2 |
인증 및 보안 관리 |
서비스 간 통신 방식
방식
|
설명 |
장단점 |
| HTTP REST + Feign |
단순하고 직관적 |
실시간 의존도 ↑ |
| Message Queue (Kafka 등) |
비동기 통신 |
복잡하지만 확장성 ↑ |
마이크로서비스 개발 흐름 예시
- 각 서비스는 별도 프로젝트 또는 멀티모듈로 나눔
- 공통 설정은 Config Server에서 관리
- 서비스는 Eureka에 등록
- API 요청은 Gateway를 통해 라우팅
- 서비스 간 데이터 공유는 Feign or MQ
- 인증은 OAuth2 + JWT (or Keycloak 등)
프로젝트 구조 예시
msa-project/
├── discovery-service/ ← Eureka 서버
├── config-service/ ← 설정 서버
├── api-gateway/ ← Spring Cloud Gateway
├── user-service/ ← 회원 서비스
├── product-service/ ← 상품 서비스
├── order-service/ ← 주문 서비스
└── common-library/ ← 공통 DTO, Util
MSA 도입 시 장단점
| 장점 |
단점 |
| 독립 배포 가능 |
초기 설계 복잡도 ↑ |
| 장애 격리 |
서비스 간 통신 비용 ↑ |
| 팀별 병렬 개발 |
테스트/운영 환경 구성 복잡 |
| 유연한 확장성 |
CI/CD, 모니터링 시스템 필수 |
입문 단계 추천 학습 순서
- 스프링 부트 단일 서비스 개발 익히기
- RESTful API 설계 → Feign Client 학습
- Eureka & Config Server 설정
- Gateway를 통한 라우팅 적용
- OAuth2 or JWT 기반 보안 학습
- Kafka or RabbitMQ로 비동기 이벤트 처리
마무리 요약
| 항목 |
설명 |
| 핵심 개념 |
서비스별 분리, 독립 배포, 확장 가능 |
| 스택 |
Spring Boot + Spring Cloud + Gateway + Eureka + JWT |
| 구성 추천 |
서비스/게이트웨이/설정/인증 모듈 분리 |
| 실무 팁 |
먼저 단일 서비스 → 점진적 MSA로 이전하는 방식 추천 |