마이크로서비스 아키텍처(MSA, Microservices Architecture)란?
마이크로서비스 아키텍처(MSA)는 애플리케이션을 여러 개의 독립적인 서비스(마이크로서비스)로 나누어 개발하는 방식이야.
1. 전통적인 모놀리식 아키텍처 vs. 마이크로서비스 아키텍처
| 비교 항목 | 모놀리식 아키텍처 | 마이크로서비스 아키텍처(MSA) |
|---|---|---|
| 구조 | 하나의 커다란 애플리케이션 | 독립적인 작은 서비스 여러 개로 구성 |
| 개발팀 구성 | 모든 팀이 하나의 코드베이스를 관리 | 도메인별로 나눠서 독립적으로 개발 |
| 배포 방식 | 전체 시스템을 한 번에 배포 | 서비스별로 개별 배포 가능 |
| 장점 | 유지보수가 단순, 한 곳에서 관리 | 확장성 좋음, 유연한 기술 선택 가능 |
| 단점 | 서비스 규모가 커지면 유지보수 어려움 | 서비스 간 데이터 동기화(싱크)가 어려움 |
2. MSA의 특징
✔ 서비스별 데이터베이스가 분리됨
- 예를 들어 배송팀, 구매팀, 상품팀이 각각 독립적인 DB를 사용.
- 서로 다른 프로그래밍 언어 사용 가능 (Polyglot, 폴리글랏 프로그래밍).
- 팀마다 가장 적합한 기술을 선택해서 개발 가능.
✔ 비동기(Message Queue) & 동기(HTTP API) 통신
MSA에서는 여러 서비스가 협력해야 하는데, 통신 방식이 중요해.
| 통신 방식 | 설명 | 예시 |
|---|---|---|
| 비동기(Message Queue, 메시지 큐) | 메시지를 보내두고 응답을 기다리지 않음. 빠르고 효율적이지만 순서 보장이 어려울 수 있음. | Kafka, RabbitMQ |
| 동기(HTTP API, REST API, gRPC) | 서비스 간 요청-응답 방식으로 직접 호출. 요청 후 응답을 기다려야 함. | REST API, gRPC |
- 🚀 비동기(메시지 큐) → 이벤트 기반. 대량의 트래픽 처리 가능, 서비스 독립성 유지.
- 🔄 동기(HTTP API) → 요청이 즉시 처리되어야 하는 경우 사용. 지연(Latency) 문제가 발생할 수도 있음.
3. 데이터 정합성 문제 (데이터 중복 최소화 vs. 정합성)
"한 테이블에 다 넣으면 정합성 문제가 생긴다?"
- 데이터베이스를 하나로 합치면 중복은 줄어들지만, MSA에서는 각 서비스가 독립적인 DB를 가지므로 데이터 동기화가 어렵다.
- 예를 들어 "배송 서비스"에서 고객 정보를 가져와야 할 때 문제가 생길 수 있음.
- 해결 방법:
- 조인(JOIN) 대신 서비스 간 API 호출 → 데이터 일관성을 유지.
- CQRS(Query Command Responsibility Segregation) → 읽기 전용 DB 따로 운영.
4. MSA를 위한 클라우드 서비스
- 마이크로서비스는 클라우드 환경에서 실행하면 더 효율적이야.
AWS Lambda,Kubernetes,Docker같은 기술을 활용하면 자동 확장, 배포 관리가 쉬워짐.
5. 마이크로서비스 아키텍처(MSA)의 장단점
| 장점 | 단점 |
|---|---|
| 각 팀이 독립적으로 개발 및 배포 가능 | 서비스 간 데이터 일관성 유지가 어려움 |
| 장애 발생 시 일부 서비스만 영향받음 | 네트워크 통신 비용 증가 (API 호출 많아짐) |
| 클라우드 환경에서 유연하게 확장 가능 | 트랜잭션 관리가 복잡 (분산 트랜잭션 문제) |
6. 정리 (한눈에 보기)
✅ 모놀리식 아키텍처: 하나의 시스템에 모든 기능 포함 → 관리 쉬움, 확장 어려움
✅ 마이크로서비스 아키텍처(MSA): 여러 개의 독립적인 서비스 → 확장성 좋음, 동기화 어려움
✅ 데이터 정합성 문제: 한 DB에 넣으면 정합성 문제가 생김 → API 호출 & 이벤트 큐 사용
✅ 비동기 메시지 큐 (Kafka, RabbitMQ) vs. 동기 HTTP API (REST, gRPC)
✅ 클라우드 서비스 활용 → AWS Lambda, Kubernetes로 자동 확장
💡 결론:
✔ 대규모 서비스(배달의민족, 쿠팡 등)에서는 MSA가 유리하지만,
✔ 작은 프로젝트에서는 모놀리식이 더 관리하기 쉬움!
이제 이해됐지? 😊
@mgkick