1. MSA 사용하는 이유
이유 | 설명 | 관련성 |
민첩한 확장(Agile) | 작은팀으로 개발하고 독립적으로 배포 가능 | 조직 |
Legacy를 효과적으로 다룰수 있음 | Monolith 구조의 Legacy를 점진적으로 Microservice로 변경 가능 | 배포 단위 |
지속가능한 개발 | ||
지속적인 배포(CD) | ||
견고함 | 장애를 단일 Microservice로 제한 가능 | 기술 |
독립적으로 확장 | ||
기술선택의 자유로움 |
2. Bounded Context
DDD로 식별된 단일 Bounded Context는 단일 Microservice로 분리될 수 있다.
Bounded Context관련 내용은 아래 2개의 글을 참고.
3. Migration
- 새로운 비지니스 또는 비지니스 환경 변화에 따라 Microservice 추가
- Monolith를 단계적으로 Microservice로 전환
4. External Systems
- 외부연계 시스템이 존재할 경우 단일 연계채널에 단일 Microservice로 분리
- 외부연계 시스템의 문제로인한 장애격리 가능
5. Technical Reasons
- CQRS : 조회와 명령 Microservice 분리
- 독립적 확장: 특정기능, 특정기간에 트래픽이 급격히 증가할 경우 해당기능만 Microservice로 분리하고 Auto Scale 가능하도록 함.
- 특정기능만 별도로 다른 Language로 구현되어야 할 경우 해당 기능만 Microservice로 분리
- 특정기능만 별도의 다른 Database 사용이 필요할 경우 해당 기능만 Microservice로 분리
6. Requirements
단일 요구사항은 단일 Microservice에서 구현 되도록 Microservice 분리
- 소프트웨어 응집도 증가
7. 결론
소프트웨어 설계는 원칙적으로 잘나눈 후에 현실과 타협해서 합치는 과정이다. 어떤분은 Core Domain은 분리하면 안된다는 전제를 두고 설계해야 한다는 분도 있지만 개인적으로는 합리적으로 잘 나눈뒤 현실적인 문제를 고려하여 득과실을 잘따져서 필요한 부분만 합쳐야 한다고 생각한다.
- 이상적인 설계는 1명의 개발자가 1개의 Microservice에 의존하고 1개의 조직만 영항받도록 설계일 것이다.
- 현실적인 설계는 1명의 개발자가 3개를 초과하는 Microservice에 의존하지 않고 단일 Microservice의 변경에 최소한의 조직만 영향받도록 하는 것이라고 생각한다.
위 내용은 아래 슬라이드를 인용한 내용이므로 좀 더 자세한 내용은 아래 Slide를 참조바랍니다.
https://www.slideshare.net/ewolff/how-to-split-your-system-into-microservices
