3.5 KiB
3.5 KiB
id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit
| id | title | category | status | canonical_id | aliases | duplicate_of | source_trust_level | confidence_score | tags | raw_sources | last_reinforced | github_commit | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| P-REINFORCE-WIKI-ARCH-MICROSERVICES | 마이크로서비스 아키텍처 (Microservices Architecture, MSA) | 10_Wiki/🏗️ Topics_Arch | verified |
|
A | 1.0 |
|
|
2026-05-02 |
마이크로서비스 아키텍처 (Microservices Architecture, MSA)
1. 개요
마이크로서비스 아키텍처(MSA)는 거대한 단일 애플리케이션(Monolith)을 독립적으로 배포 및 확장 가능한 작은 서비스 단위들로 분할하여 구축하는 시스템 설계 방식이다. 각 서비스는 특정 비즈니스 기능(Bounded Context)에 집중하며, 가벼운 통신 프로토콜(HTTP/REST, gRPC, 메시지 큐 등)을 통해 상호작용한다.
2. 핵심 특징
- 독립적 배포 및 확장: 전체 시스템을 중단하지 않고 특정 서비스만 개별적으로 업데이트하거나, 트래픽에 맞춰 특정 모듈만 수평 확장(Scale-out) 가능.
- 기술 자율성 (Polyglot): 각 마이크로서비스의 특성에 따라 서로 다른 프로그래밍 언어, 데이터베이스, 프레임워크를 선택할 수 있는 유연성 제공.
- 격리된 실패 (Fault Isolation): 특정 서비스에 장애가 발생하더라도 서킷 브레이커 등을 통해 전체 시스템으로의 장애 전파를 차단하여 가용성 유지.
- 조직 정렬 (Conway's Law): 비즈니스 도메인 단위로 팀을 구성하고, 팀별로 독립적인 서비스 소유권을 부여하여 개발 민첩성 극대화.
3. 실전 아키텍처 결합
- 클라우드 네이티브와 서버리스: AWS Lambda, Kubernetes 등 클라우드 인프라를 활용하여 마이크로서비스의 배포와 운영 자동화.
- 헥사고날 아키텍처의 확장: 각 마이크로서비스 내부를 헥사고날 아키텍처로 설계하여 비즈니스 로직의 순수성을 지키고 외부 기술과의 결합도 최소화.
- API 게이트웨이: 수많은 마이크로서비스의 엔드포인트를 단일 창구로 통합하고 인증, 로깅, 라우팅을 중앙 집중적으로 관리.
4. 트레이드오프 및 주의사항
- 분산 시스템의 복잡성: 네트워크 지연, 분산 트랜잭션 처리(Saga 패턴 등), 데이터 일관성 유지(Eventual Consistency) 등 고난도의 기술적 과제 수반.
- 운영 오버헤드: 서비스 수가 늘어남에 따라 모니터링, 로깅, 배포 파이프라인 관리의 난이도가 급격히 상승함.
- 분산 모놀리스 (Anti-pattern): 서비스 간의 의존성이 너무 강해 결국 함께 배포해야 하는 상황이 발생하지 않도록 바운디드 컨텍스트 설계를 정교하게 해야 함.
5. 지식 연결 (Related)
- Hexagonal_Architecture: 마이크로서비스 내부를 설계하는 기반 패턴.
- Event_Driven_Architecture: 서비스 간 느슨한 결합을 구현하기 위한 핵심 통신 방식.
- Bounded_Context: 마이크로서비스를 나누는 논리적/비즈니스적 기준.
🧪 검증 상태 (Validation)
- 정보 상태: 검증 완료 (Verified)
- 출처 신뢰도: A
- 검토 이유: 대규모 트래픽과 복잡한 비즈니스 요구사항을 탄력적으로 수용하기 위한 현대적 아키텍처의 표준 명세 정립.