Micro Service Architecture
1. Loosely coupled (느슨한 결합) & High-cohesion (높은 응집력)
2. Bounded context (결정 경계)
Loosely Coupled (느슨한 결합)
- 하나의 서비스가 변경될 때 다른 서비스가 변경되는 일이 없음
- 시스템의 그 어떤 부분도 추가 변경할 필요 없이 특정 서비스를 변경 및 배포 가능
- 강한 결합은 변경이 어렵고 testablility(시험 가능성)을 지연 시킴
High-cohesion (높은 응집력)
- 단일 책임 원칙(Single Responsible)을 따라 하나의 Micro Service 안에는 함께 변경되는 것들을 같은 곳에 모음.
- 설계 시 주의할 점은 업무 도메인을 정의 하고, 해당 업무 도메인 안에서 변경을 고려해 서비스를 분리해야 함.
Bounded Context (결정 경계)
- 도메인은 다수의 경계가 있는 Context로 구성됨.
- Bounded Context는 명료한 경계에 의해 강제된 구체적인 책임을 구분.
MSA의 특징
작고 한가지 일을 잘 하도록 설계
1. 자율성 (Autonomous)
2. 기술 이기종성 (Tech Heterogeneity)
3. 회복성 (Resilience)
4. 확장성 (Scaling)
5. 배포 용이성 (Easy of Deployment)
1. 기술 이기종성(Hetrogeneous)
- 각각의 서비스가 다른 기술을 사용해 구현 가능.
- 서비스에 맞는 기술을 채택 가능 (성능, 데이터 모델, 구현 용이성 등)
- 너무 많은 기술 스택은 오히려 부담
2. 회복성 (Resilience)
- 하나의 서비스 장애가 다른 서비스로 전이 되지 않음
- 전체 장애를 차단, 기능은 저하
- 분산 기술에 대한 높은 이해도 요구
3. 확장성 (Scaling)
- 프로세스를 독립적으로 확장 가능.
- 현재 부족한 성능을 나타내는 서비스만 별도로 확장 가능.
- 비용 효율적.
4. 배포 용이성 (Easy Deployment)
- 전체 빌드 (build)가 아닌 서비스 단위의 빌드 및 배포.
- 테스트 코드 또는 TDD 필요.
- 컨테이너 환경에 매우 적합
- 다같이 야근 안해도 된다!
MSA의 단점
- 업무 도메인 구분이 어렵다 (경험 부족)
- 업무 도메인을 구분해 잘게 분리하는 것이 생각보다 경험을 필요로 함.
- 초기 스타트업에서는 MSA 권장 X. (어떤 업무가 어떻게 나뉘게 될 지 모름)
- 개발 인력의 기본적인 능력이 매우 중요
- 운영하기 어렵다
- 작은 서비스들이 흩어져 있어 모니터링이 쉽지 않음.
- 산재된 로그를 분석하기 어려움..
- 운영자가 마이크로 서비스를 구성하는 컴포넌트에 대해 정말 잘 알아야 함 (장애 대처 중요)
→ Docker와 같은 컨테이너 기술 & 컨테이너 오케스트레이션의 K8S가 대안!
Netfilx OSS vs K8S
Cloud/DevOps & Network Virtualization에 관심 있는 Engineer입니다. 🐳⚓️👨✈️