MSA란?

애플리케이션을 작고 자율적인 서비스 단위로 나누고, 이들 각각이 독립적으로 배포되고 운영될 수 있도록 설계하는 아키텍처 스타일

🧱 특징

항목설명

서비스 분리	각 기능을 하나의 마이크로서비스로 나눔 (예: 사용자 서비스, 주문 서비스, 결제 서비스 등)
독립 배포	서비스 단위로 빌드/배포 가능. 전체 시스템 재배포 없이 수정 가능
독립 데이터 저장소	각 서비스는 자체 DB를 가짐 (DB 공유 지양)
경량 통신	보통 REST API, gRPC, 메시징(Kafka 등)으로 통신
폴리글랏 개발	각 서비스는 서로 다른 언어/프레임워크/DB를 사용할 수 있음
장애 격리	하나의 서비스 오류가 전체 시스템에 영향을 주지 않도록 설계

📦 구성 요소 예시

• API Gateway: 외부 요청을 마이크로서비스에 라우팅
• Service Discovery: 동적으로 서비스 위치를 찾음 (예: Eureka, Consul)
• Load Balancer: 트래픽 분산
• Config Server: 설정 중앙 관리 (예: Spring Cloud Config)
• Monitoring / Logging: Prometheus, Grafana, ELK, Zipkin 등
• CI/CD 파이프라인: 서비스별 자동 빌드, 배포 지원

⚙️ MSA와 DevOps의 관계

• DevOps는 CI/CD 자동화와 운영 효율화를 지향
• MSA는 DevOps가 잘 작동하기 위한 기술적 기반
• 둘 다 "작은 단위의 반복적 배포와 빠른 피드백"을 목표로 함

✅ 장점

• 빠른 개발 및 배포 주기
• 장애 격리 가능 (시스템 안정성 ↑)
• 기술 스택 유연성
• 팀 단위 책임 구조 (서비스 오너십 강화)

⚠️ 단점

• 시스템 복잡도 증가 (서비스 수가 많아짐)
• 분산 시스템의 어려움 (통신, 트랜잭션 관리 등)
• 데이터 일관성 보장 어려움
• 모니터링, 로깅, 장애 추적 등 운영 부담 ↑

📌 언제 MSA를 쓰면 좋은가?

• 규모가 큰 프로젝트 또는 빠르게 성장 중인 서비스
• 팀이 여러 개로 나눠져 있어 서비스별로 나눠 개발이 필요한 경우
• 독립적인 배포와 서비스 확장이 중요한 경우