샘 뉴먼 님의 "마이크로서비스 아키텍처 구축" 책을 정리한 포스팅 입니다.
1. 뮤직코프 소개
- 최첨단 온라인 소매업체
- 오프라인 위주로 판매를 해왔지만 온라인 판매에 더욱 집중하기로 결정함
2. 올바른 마이크로서비스 경계를 만드는 것은 무엇인가?
- 마이크로서비스가 독립적인 방식으로 변경되거나 배포되 사용자에게 릴리즈되길 바람
- ➡️ 다른 마이크로서비스와 별개로 변경할 수 있는 능력이 중요
정보 은닉
- 모듈 내부의 구현 세부 사항을 외부에서 보지 못하게 감추는 원칙
- ✅ 내부 로직이 바뀌어도 외부에 영향을 최소화할 수 있음
- ✅ 모듈 경계를 정의하는 기준으로 사용함
이점
| 이점 | 설명 | 효과 |
| 개발 시간 단축 | 다른 서비스는 인터페이스를 통해 기능을 사용 |
- 서비스 간 독립 개발 가능
- 여러 작업을 병렬로 처리 가능 |
| 이해도 | - 각 모듈을 독립된 블랙박스처럼 다룸 - 내부 구현이 복잡해도 외부는 인터페이스만 참조 |
- 각 모듈을 개별적으로 이해 가능
- 전체 동작 이해가 쉬워짐 |
| 유연성 | - 모듈이 다른 모듈의 내부 구조에 의존하지 않음 - 내부 변경이 외부에 영향 없음 |
- 모듈별 독립적 변경 가능
- 다른 모듈 수정 없이 기능 변경 가능 |
응집력
- 경계 내부에 있는 오브젝트간 밀접도
- ✅ 하나의 모듈 안에 있는 구성 요소들이 얼마나 밀접하게 연관되어 있는지 의미함
- ✅ 비즈니스 기능을 쉽게 변경할 수 있도록 최적화하는 마이크로서비스의 목적에 부합함
- ➡️ 가능한 한 적은 장소에서 변경할 수 있는 방식으로 기능을 그룹핑하기
결합도
- 경계 건너에 있는 오브젝트 간의 밀접도
- ✅ 서로 다른 모듈들이 얼마나 서로를 의존하는지 나타냄
- ✅ 결합도가 높을수록 하나의 변경이 다른 모듈에 영향을 미침
- ➡️ 서비스가 느슨하게 결합됐다면 한 서비스를 변경할 떄 다른 서비스를 변경할 필요 없음
3. 결합 유형
도메인 결합
- 한 마이크로서비스가 다른 마이크로서비스에서 제공하는 기능을 사용해야 하는 경우 발생하는 결합
- 많은 하위 마이크로서비스와의 통신은 너무 많은 로직이 집중되도록 만듬
- ➡️ 서비스 간 의존도가 높아짐
시간적 결합
- 하나의 마이크로서비스가 작업을 완료하기 위해 동시간에 어떤 작업을 수행하는 다른 마이크로서비스가 필요한 상황
- 두 서비스가 시간적으로 묶임
- 동기식 블로킹 네트워크 호출이 대표적인 예
예) CD 주문
더보기
주문 서비스
- 창고 서비스 (재고 예약)
- 결제 서비스 (지불)
통과 결합
- 다른 하위 마이크로서비스에 데이터를 전달하는 상황
- 결합을 구현하는 데 문제를 유발함
- ⚠️ 호출자는 요청하는 마이크로서비스가 다른 마이크로서비스를 호출하는 것을 알고 있어야 함
- ⚠️ 호출자는 간접적으로 다른 마이크로서비스가 어떻게 동작하는 지 알아야 함 (데이터 포맷, 응답 시간, 에러 처리 등)
- ➡️ 장애 전파 경로 확대, 변경 영향 범위 확산, 테스트 복잡도 증가
해결 방법
| 방법 | 장점 | 단점 |
| 하위 서비스와 직접 통신 | - 중간 서비스의 결합 제거 - 호출자가 원하는 데이터 형식으로 직접 수신 가능 |
- 기존에 중간 서비스가 숨기던 로직 복잡성이 호출자에 집중됨
|
| 중계 서비스는 스키마가 강하지 않은 타입으로 전달 | - 중계 서비스는 스키마 변화에 영향 최소화 - 하위 서비스 변경 시 호출자만 수정 |
- 호출자와 하위 서비스 간 숨은 결합 발생(스키마 의존성 존재)
|
예) CD 주문
더보기
주문 서비스
- 창고 서비스 (재고 예약)
- 배송 서비스 (재고 배송)
공통 결합
- 둘 이상의 마이크로서비스가 공통 데이터 집합을 사용할 때 발생 (데이터베이스, 메모리, 파일 시스템 등)
- ✅ 데이터 구조를 변경하면 한 번에 여러 마이크로서비스에 영향을 미침
- ➡️ 유한 상태 기계를 만들어 상태가 올바른 방식으로 변경됐는지 확인하기
유한 상태 기계) CD 주문
더보기
- ❌ 창고 서비스와 주문 처리기가 상태 기계를 관리하는 책임을 공유함
- ➡️ 하나의 마이크로서비스가 주문 상태를 관리하게 하는 것
아키텍처) CD 주문
더보기
주문 서비스
- 주문 애그리거트와 관련돼 가능한 상태 전환을 관리함
- 주문에 대한 진실의 원천 (내부에서만 동작하는 도메인 전담 서비스. 외부 API ❌)
- 창고 서비스나 주문 처리기는 주문 서비스에 상태 업데이트 요청을 보내도록 하기 (유효하지 않은 요청은 거절할 수 있음)
내용 결합
- 상위 서비스가 하위 서비스의 내부까지 도달해 서비스의 내부 상태를 변경하는 상황
- ✅ 외부 서비스가 다른 마이크로서비스의 데이터베이스에 액세스해 직접 변경
- ⚠️ 소유권 경계가 무너짐
- ⚠️ 무결성 손상 (캡슐화 붕괴로 인해 내부 규칙이 깨짐)
- ⚠️ 정보 은닉 손상 (데이터 스키마 노출됨)
4. 딱 도메인 주도 설계만큼
5. 마이크로서비스를 위한 도메인 주도 설계 사례
정보 은닉
- 경계 컨텍스트가 정보 은닉에 명시적으로 사용됨
- ➡️ 시스템의 다른 부분에 영향을 주지 않고 변경할 수 있는 내부의 복잡성을 숨기면서도 더 넓은 시스템에 명확한 경계를 제시
보편 언어
- 공통적인 보편 언어를 정의하는 데 중점을 두는 것은 마이크로서비스 엔드포인트를 정의할 때 큰 도움이 됨
- ✅ API와 이벤트 포맷을 만들 때 참고할 공유 언어를 제공할 수 있음
6. 비즈니스 도메인 경계에 대한 대안
변동성
- 시스템에서 빈번하게 변경되는 부분을 식별한 다음 해당 기능을 자체 서비스로 추출
데이터
- ex) 민감 정보를 다루는 서비스일 경우, 높은 보안 수준의 요구사항을 만족해야 함
- 해당 민감 정보만 두는 서비스로 경계를 구분