※ MSA(Microservices Architecture)
하나의 큰 애플리케이션을 독립적인 여러 서비스로 분리하여 개발하고 운영하는 소프트웨어 아키텍처 방식
각 서비스는 고유한 기능을 담당하며, 독립적인 배포·확장·운영이 가능하도록 설계된다.
※ 왜 MSA를 사용할까?
기존의 모놀리식(Monolithic) 방식은 기능이 커지고 복잡해질수록 다음과 같은 문제가 발생한다.
· 한 부분의 변경이 전체 서비스에 영향을 줌
· 배포가 느리고 위험도가 큼
· 성능 확장 시 전체 시스템을 확장해야 함
반면 MSA는 기능 단위로 분리되어 있어,
· 필요한 서비스만 독립적으로 확장(Scale-out) 할 수 있고
· 서비스별로 다른 기술 스택 선택이 가능하며
· 기능 단위로 빠르게 배포 및 장애 대응할 수 있다.
특히, 클라우드 환경과 컨테이너 오케스트레이션(Kubernetes) 기술의 발전으로
MSA는 대규모 서비스 운영에 사실상 표준 구조가 되고 있다.
※ MSA 간단히 비유
모놀리식(Monolithic)
: 한 식당에서 모든 요리를 한 주방에서 처리
→ 한 주방이 복잡해지고 문제가 생기면 전체 운영이 중단될 가능성
MSA
: 메뉴마다 전문 주방(파스타 주방, 스테이크 주방, 디저트 주방)
→ 특정 주방만 증설하거나, 문제가 생겨도 나머지는 정상 운영 가능
※ 핵심 이슈
1. 세션 공유가 어려움
| 항목 | 내용 |
| 문제 | 사용자의 로그인 상태(세션)를 서버가 기억하기 어려움 |
| 이유 | 서비스/서버가 여러 개로 분산되어 있고 독립적으로 확장되기 때문 |
| 해결 방법 | JWT 기반 토큰 인증, OAuth2 + OIDC, API Gateway 인증, Redis는 보조 저장소 방식 |
2. 서비스 간 통신 복잡도 증가
| 항목 | 내용 |
| 문제 | 서비스가 늘어날수록 서비스 간 호출(REST/gRPC)이 폭발적으로 증가 |
| 이유 | 기능을 서비스별로 분리했기 때문 |
| 해결 방법 | API Gateway, Service Mesh(Istio, Linkerd), 비동기 메시징(Kafka) |
3. 트랜잭션 처리 어려움 (분산 트랜잭션)
| 항목 | 내용 |
| 문제 | 여러 서비스가 하나의 작업에 참여하면 데이터 정합성 유지가 어려움 |
| 이유 | 각 서비스가 별도 DB를 가짐(Loose Coupling) |
| 해결 방법 | Saga 패턴, Event Sourcing, 보상 트랜잭션(Compensation) |
<예시> 주문 → 결제 → 재고 차감 → 배송 (중간 실패 시 롤백이 아니라 보상 처리 방식 필요)
4. 장애 추적이 매우 어려움 (분산 환경)
| 항목 | 내용 |
| 문제 | 어디서 장애/지연 발생했는지 찾기 어려움 |
| 이유 | 요청이 여러 서비스/컨테이너를 통과 |
| 해결 방법 | Distributed Tracing (OpenTelemetry, Jaeger, Zipkin), APM(Datadog, New Relic), 중앙 로그 시스템(ELK, Loki) |
5. 로그가 여러 곳에 흩어짐
| 항목 | 내용 |
| 문제 | 마이크로서비스별 Log 파일이 따로 존재 |
| 이유 | 서버/컨테이너가 여러 개이기 때문 |
| 해결 방법 | 중앙 로그 수집(ELK Stack, EFK Stack, Datadog Log, Grafana Loki) |
6. 배포 및 버전 관리가 복잡
| 항목 | 내용 |
| 문제 | 여러 서비스가 각자 버전 유지 |
| 이유 | 독립 배포 원칙 |
| 해결 방법 | CI/CD 파이프라인 구축, GitOps(ArgoCD), Canary / Blue-Green Deploy |
7. 서킷 브레이커 필요
| 항목 | 내용 |
| 문제 | 하나의 서비스가 느려지면 다른 서비스도 연쇄적으로 느려짐 |
| 이유 | 서비스 간 네트워크 호출 체인 |
| 해결 방법 | Circuit Breaker 패턴, Resilience4j, Envoy |
8. 서비스 디스커버리 필요
| 항목 | 내용 |
| 문제 | 어떤 서비스가 어디 IP/Port에 있는지 모르게 됨 |
| 이유 | 컨테이너가 동적으로 생성/삭제됨 |
| 해결 방법 | Service Discovery 서버(Kubernetes DNS, Consul, Eureka) |
9. Config 관리 어려움
| 항목 | 내용 |
| 문제 | 각 서비스 환경변수를 따로 관리해야 함 |
| 이유 | 독립 실행 특성 |
| 해결 방법 | Config Server (Spring Config Server), Vault + Kubernetes Secrets |
10. 데이터 중복 & 데이터 동기화
| 항목 | 내용 |
| 문제 | 각 서비스 DB가 독립이기 때문에 데이터 중복 발생 |
| 이유 | Loose Coupling 원칙 |
| 해결 방법 | 이벤트 기반 데이터 동기화, CQRS, Event Sourcing |
※ 요약
| MSA 이슈 | 이유 | 해결 |
| 세션 공유 어려움 | 서버 분산 | JWT, OAuth2 |
| 통신 증가 | 서비스 분리 | API Gateway, Service Mesh |
| 트랜잭션 어려움 | DB 분리 | Saga, Event Sourcing |
| 장애 추적 어려움 | 분산 구조 | Distributed Tracing |
| 로그 분산 | 컨테이너 확장 | ELK, Datadog Logs |
| 배포 복잡 | 독립 배포 | CI/CD, GitOps |
| 장애 전파 | 서비스 연쇄 호출 | Circuit Breaker |
| 서비스 위치 모름 | 컨테이너 동적 변화 | Service Discovery |
| 환경 변수 분산 | 서비스 독립 | Config Server |
| 데이터 정합성 | DB 분리 | CQRS, 이벤트 설계 |