🚀 MSA (Microservice Architecture)
MSA는 하나의 큰 애플리케이션을 여러 개의 작은 독립적인 서비스(마이크로 서비스)로 분리해서 개발, 배포, 우녕하는 아키텍처 스타일 이다.
🎈 MSA 의 사용 이유
기존의 모놀리식(Monolithic) 아키텍쳐는 모든 기능이 하나의 애플리케이션 안에 포함되어있다.
- 작은 팀일 때는 단순하고 효율적
- 서비스 규모가 커지면 개발/배포/확장/유지보수 가 어렵다.
🎈 MSA의 핵심 특징
| 특징 | 설명 |
|---|---|
| 독립성 | 각 서비스는 독립적으로 배포되고 실행 |
| 작은 단위 | 각 서비스는 특정 도메인(비즈니스 기능)을 책임짐 |
| 자율성 | 각 팀이 독립적으로 개발하고 기술 스택을 선택할 수 있음 |
| 통신 | 서비스 간은 HTTP/REST API, gRPC, 메시지 브로커 등으로 통신 |
| 장애 격리 | 하나의 서비스가 장애나도 전체 시스템에 영향 최소화 |
🎈 MSA의 장점
- 빠른 배포/롤백 : 작은 단위라 빠르게 배포하고 문제 시 롤백 가능
- 유지보수 용이 : 코드베이스가 작아져 이해하기 쉬움
- 확장성 : 병목 서비스만 따로 확장 가능
- 조직 분리 : 팀 간 독립적으로 작업 가능
🎈 MSA의 단점
- 복잡한 서비스 간 통신 : 네트워크 통신이 많아짐 -> API Gateway, Service Mesh 필요
- 데이터 일관성 어려움 : 서비스 간 DB 분리 -> 분산 트랜잭션 문제
- 보안 관리 : 서비스 간 인증/인가 복잡
- 운영/모니터링 복잡성 : 배포 자동화, 모니터링, 로깅 시스템 필요
🎈 MSA 핵심 기술 스택 예시
| 레이어 | 주요 역할 | 예시 도구 |
|---|---|---|
| 🧑💻 클라이언트 | 사용자 요청 (웹, 앱) | React, Vue, Flutter 등 |
| 🚪 API Gateway | 인증, 라우팅, 로드밸런싱, 트래픽 제어 | NGINX, Kong, Spring Cloud Gateway |
| 🧩 Microservices | 도메인별 독립 서비스 | 주문, 결제, 배송, 알림 |
| 💬 메시지 브로커 | 서비스 간 비동기 이벤트 전달 | Kafka, RabbitMQ |
| 🗄️ DB | 서비스별 데이터 저장소 (분리) | MySQL, PostgreSQL, Redis, MongoDB |
| 🗂️ Service Registry | 서비스 디스커버리 | Eureka, Consul |
| 🔗 Config Server | 설정 중앙 관리 | Spring Cloud Config |
| 🔒 API Security | 인증/인가 | OAuth2, JWT, Keycloak |
| 🚦 Circuit Breaker | 장애 전파 방지 | Hystrix, Resilience4j |
| ⚙️ 컨테이너 & 배포 | 빌드, 배포, 스케일링 | Docker, Kubernetes, Helm |
| 🛠️ CI/CD | 자동화 빌드/배포 | Jenkins, GitHub Actions, ArgoCD |
| 📊 모니터링 & 로깅 | 장애 감지/로깅/분석 | Prometheus, Grafana, ELK, Jaeger, Zipkin |
📢 Q&A
Q. MSA가 무엇인가요?
MSA는 Microservice Architecture(마이크로서비스 아키텍처)의 약자입니다.
하나의 큰 애플리케이션을 작은 도메인별 서비스로 쪼개서 각각 독립적으로 개발·배포·운영하는 구조입니다.
각 서비스는 자기 DB를 갖고, 다른 서비스와는 API 호출이나 메시지 브로커로 통신합니다.
Q. MSA를 왜 사용하나요?
서비스 규모가 커지면 모놀리식 아키텍처는 배포·확장·장애 관리가 어려워집니다.
MSA는 서비스를 작게 나눠서 빠른 배포, 유지보수 용이성, 스케일 아웃, 장애 격리가 가능합니다.
팀별로 독립적으로 개발하고 다양한 기술 스택을 선택할 수 있어 개발 효율성이 높아집니다.
Q. MSA의 특징은 무엇인가요?
✅ 도메인별 서비스 경계 (Bounded Context)
✅ 각 서비스는 독립 배포, 독립 스케일링 가능
✅ 서비스 간 데이터베이스 분리
✅ API Gateway를 통해 진입점 단일화
✅ 장애 격리, 느슨한 결합을 위해 메시지 브로커 사용 (Kafka 등)
Q. Monolithic과 MSA의 차이점은?
항목 Monolithic MSA 구조 하나의 큰 앱 여러 독립 서비스 배포 전체 빌드/배포 서비스별 독립 배포 장애 영향 전체 다운 가능성 ↑ 장애 격리 쉬움 데이터베이스 하나 서비스별 분리 스케일링 전체 확장 필요한 서비스만 확장
Q. MSA의 단점은 뭐가 있을까요?
서비스가 많아지면 분산 시스템 복잡성이 커집니다.
데이터 일관성을 유지하기 위해 Saga 패턴, 이벤트 소싱 등 추가 설계 필요.
네트워크 통신량 증가 → API Gateway, Service Mesh, 로깅/모니터링 필수.
CI/CD, 인프라 자동화가 필수적이지만 초기 구축 비용과 운영 난이도가 높습니다.
Q. MSA에서 서비스별로 DB를 분리하는 이유는?
각 서비스가 독립적으로 배포되고 확장되기 위해서는 데이터까지 독립해야 합니다.
공유 DB를 쓰면 스키마 변경 충돌, 서비스 간 의존성이 높아지고 장애 전파 가능성이 커집니다.
대신 데이터 일관성을 유지하기 위해 분산 트랜잭션 대신 이벤트 소싱, Saga 패턴을 사용합니다.
Q. MSA에서 장애 전파를 막는 방법은?
Circuit Breaker 패턴: 연쇄 장애를 방지 (Resilience4j, Hystrix)
Timeout/Retry 설정으로 재시도 시도
메시지 브로커로 비동기 처리 → 장애 발생 시 데이터 유실 방지
API Gateway에서 Rate Limit 적용
Q. MSA에서 API Gateway는 왜 필요합니까?
클라이언트 요청의 단일 진입점
요청을 각 마이크로서비스로 라우팅
인증/인가, 로드밸런싱, 트래픽 관리
장애 시 fallback 처리
클라이언트별 응답 포맷(API Aggregation) 관리
Q. MSA에서 Kafka는 왜 필요합니까?
MSA에서 Kafka는 서비스 간 데이터를 비동기로 전달하는 이벤트 브로커 역할을 합니다.
덕분에 서비스 간 결합도를 낮추고, 장애 시에도 메시지를 안전하게 저장해 나중에 재처리가 가능합니다.
여러 서비스가 동시에 같은 이벤트를 구독할 수 있어 확장성이 좋습니다.
Q. MSA 도입 시 무엇에 주의해야 하나요?
모든 프로젝트에 MSA가 정답은 아닙니다. 서비스가 작다면 오히려 오버엔지니어링이 될 수 있습니다.
도메인 설계(DDD)부터 잘해야 서비스 경계가 명확해집니다.
자동화 파이프라인(CI/CD), 컨테이너화(Docker/Kubernetes)가 준비되어야 합니다.
분산 로그/모니터링/트레이싱(ELK, Zipkin, Prometheus)을 필수로 갖춰야 장애 원인을 찾기 쉽습니다.
⭐ 요약 ⭐
✔️ “MSA의 핵심은 작게 쪼갠다 → 느슨하게 연결한다 → 독립적으로 운영한다”
✔️ “분산 시스템이라 생기는 문제를 메시지 브로커, API Gateway, Circuit Breaker, 모니터링으로 풀어야 한다.”
✔️ “데이터 일관성은 동기+비동기 혼합 + Saga 패턴으로 보완한다.”
🚀 Apache Kafka
- 카프카는 대용량 데이터 처리에 최적화된 분산 메시징 시스템 (이벤트 스트리밍 플랜폼)
- 데이터를 모아서, 빠르게 저장하고, 필요한 시스템에 흘려 보내는 파이프라인 역할
예시
- 여러 서버에서 발생하는 로그를 모아서 실시간으로 저장
- 주문 서비스에서 결제 완료 이벤트를 발생 -> 배송/알림 서비스가 구독해서 처리
- IoT 센서 데이터가 계속 들어오면, 실시간으로 저장 + 분석 시스템으로 전송
🎈 Kafka를 사용하는 이유
-
실시간 로그 수집 시스템
서버 로그를 카프카로 모아 ELK(ElasticSearch + Logstash + Kibana)로 시각화 -
MSA 이벤트 브로커
주문, 결제, 배송 등 도메인 이벤트를 비동기 방식으로 마이크로서비스 간 전달 -
스트리밍 데이터 처리
IoT 데이터, 사용자 행동 데이터 등 실시간 분석 -
분산 시스템 데이터 파이프라인
데이터 레이크, DW 등으로 실시간 ETL 처리
🎈 REST API나 DB만 사용하면 안되나?
| 방법 | 특징 | 문제점 |
|---|---|---|
| REST API | 실시간 요청-응답 | 서버 죽으면 실패. 동기 방식이라 장애 전파됨 |
| DB | 데이터 저장 | 저장은 되지만, 실시간 데이터 흐름/다중 구독 불편. 다시 꺼내 쓰는 로직 복잡 |
| Kafka | 실시간 스트림 + 안전한 저장 | 대량의 데이터 흐름을 장애없이, 재처리 가능하게, 동시에 여러 서비스에 분배 |
🎈 비슷한 역할을 하는 친구들
- RabbitMQ, ActiveMQ : 메시지 브로커
- Redis Pub/sub : 단순 Pub/sub
- SQS, SNS, AWS 서비스
- Flink, Storm : 스트리밍 처리
Kafka vs RabbitMQ
| 상황 | 추천 |
|---|---|
| 실시간 대용량 이벤트 로그 | Kafka |
| IoT 센서 스트림 | Kafka |
| MSA의 도메인 이벤트 브로커 | Kafka |
| 복잡한 조건에 따라 메시지 라우팅 | RabbitMQ |
| 단순 작업 큐(알림, 메일) | RabbitMQ |
| 요청-응답 RPC 패턴 | RabbitMQ |
요약
👉 Kafka는 "대량의 데이터를 로그처럼 쌓아두고, 실시간 스트리밍으로 동시에 여러 시스템에 흘려 보내는 데 특화"
👉 RabbitMQ는 "메시지를 복잡하게 분기하고, 작업 큐나 알림 같은 비교적 소규모 비동기 처리에 특화"
📢 Q&A
Q. Kafka는 무엇인가요?
Kafka는 분산 메시지 브로커이자 실시간 스트리밍 플랫폼입니다.
대용량 데이터를 안전하게 저장하고, 복수의 시스템에 동시에 전달할 수 있는 Publish-Subscribe 시스템입니다.
디스크에 로그로 저장해서 장애 시 데이터 유실을 최소화하고, 오프셋 기반으로 데이터 재처리도 가능합니다.
Q. Kafka와 RabbitMQ의 차이점은?
Kafka는 대용량 실시간 이벤트 스트림 처리에 특화되어 있고 디스크 로그 저장을 기본으로 합니다.
파티션과 오프셋 기반으로 장애 복구와 데이터 재처리가 용이합니다.
RabbitMQ는 큐 기반의 전통적인 메시지 브로커로 복잡한 메시지 라우팅이나 RPC 패턴에 강점이 있습니다.
하지만 대용량 스트림 처리나 이벤트 로그 저장에는 Kafka가 더 적합합니다.
Q. Kafka는 메시지를 어떻게 유실 없이 전달하나요?
Kafka는 메시지를 디스크에 로그 형태로 저장하고, 복제(Replication Factor) 설정으로 브로커 장애에도 데이터 유실을 최소화합니다.
오프셋(Offset) 개념으로 Consumer는 어디까지 읽었는지 관리합니다.
기본은 At least once(최소 1번 전달) 보장이고, 트랜잭션이나 idempotent producer 설정으로 Exactly once(정확히 1번) 처리도 가능합니다.
Q. 서비스 간 데이터 전달에 Kafka를 쓰는 이유는?
REST API만으로 서비스 간 동기 통신을 하면,
장애 시 전체 트랜잭션이 실패할 수 있고
대량 데이터 실시간 처리가 어렵고
데이터 재처리가 불가능합니다.
Kafka는 이벤트를 안전하게 디스크에 저장해서 장애 격리, 실시간 스트리밍, 재처리가 가능합니다.
특히 MSA 환경에서 서비스 간 결합도를 낮추고 대량 데이터를 안정적으로 처리할 수 있기 때문에 Kafka를 사용합니다.
Q. Kafka의 Topic과 Partition이 뭐에요?
- Topic은 메시지를 논리적으로 구분하는 단위입니다.
예: OrderPlaced, PaymentCompleted 같은 이벤트.- Partition은 Topic을 물리적으로 분할해서 병렬 처리와 확장성을 높이는 단위입니다.
하나의 Partition은 메시지의 순서를 보장합니다.
Q. Kafka에서 데이터 유실을 방지하려면 어떻게 설정하나요?
Replication Factor: 각 Partition의 데이터를 여러 브로커에 복제.
ACK 설정: Producer가 메시지 전송 시 acks=all로 설정해 리더와 팔로워 모두에게 쓰기 완료 확인.
Min ISR(In-Sync Replica): 충분한 복제본이 동기화되지 않으면 쓰기 거부.
Consumer는 오프셋을 커밋해두어 재시작 시에도 이어서 읽을 수 있음.
Q. Kafka의 단점이나 고려사항은?
Kafka는 운영 복잡도가 높습니다 (브로커/파티션/오프셋 관리).
분산 시스템이라 장애 분석과 모니터링이 중요합니다.
실시간성이 있지만, ‘완전한 실시간’은 아니고 약간의 지연이 있을 수 있습니다.
데이터 일관성을 맞추기 위해서 Saga 패턴, 보상 트랜잭션 설계가 필요할 수 있습니다.
⭐ 핵심 키워드 ⭐
- “분산 로그 저장소”
- “실시간 데이터 스트리밍”
- “복제/장애 복구”
- “Eventually Consistent / Event-Driven Architecture”
- “MSA의 느슨한 결합을 가능하게 함”
✨ 요약 ✨
- Kafka는 대용량 데이터를 안전하게 저장/분배하는 분산 로그 시스템이다.
- MSA에서 서비스 간 데이터 흐름을 느슨하게 연결하고 장애 복구를 쉽게 만든다.
- Kafka의 핵심은 Topic, Partition, Offset, Replication으로 장애 복원력과 재처리가 가능하다.
