MSA를 구축할 때 다음 세 가지를 일을 하여야 한다.
- 비즈니스 문제 분해
- 서비스 세분화의 확정
- 서비스 인터페이스 정의
⭐ 1. 비즈니스 문제 분해
✏️ 1. 비즈니스 문제를 기술하고 그 문제를 기술하는 데 사용된 명사에 주목할 것
문제를 기술하는 데 동일한 명사가 반복해서 사용된다면 핵심 비즈니스 영역과 마이크로서비스로 쪼갤 것을 고려하여야 한다.
✏️ 2. 동사에 주목할 것
예를 들어 "데스크톱 서비스 부서의 "마이크"는 새로운 PC를 설치할 때 소프트웨어 X의 라이선스 개수를 조회하고 여분이 있다면 설치한다. 그런 다음 장부에 라이선스 개수를 업데이트한다"에서 핵심 동사는 조회하다(looks)와 업데이트하다(updates)이다.
✏️ 3. 데이터 응집성을 찾아라
비즈니스 문제를 각 부분으로 분해할 때 서로 연관성이 높은 데이터 부분들을 찾는다. 마이크로서비스는 자기 데이터를 완전히 소유해야 한다. 따라서 만일 설계 도중 지금껏 설계한 내용과 근본적으로 다른 데이터를 CRUD 한다면 새로운 서비스를 하나 더 생성할 것을 고려해야 한다.
비즈니스 문제 분해 예시
⭐ 2. 서비스 세분화의 확정
비즈니스 문제에 따라 분해한 위 예시에서 데이터 모델을 자산(Assests), 계약(Contract), 라이선스(License), 조직(Organization) 으로 쪼갤 것 수 있다. 따라서 4개의 마이크로서비스를 고려할 수 있는데 중요한 것은 이러한 주요 기능을 가져와 서로 독립적으로 빌드하고 배포할 수 있는 자체 완비형 유닛 (Self-Contained unit)을 추출하는 것이다.
✔️ MSA를 구축할 때 다음 개념을 활용하여 올바른 세분화를 할 수 있다.
✏️ 1. 큰 마이크로서비스에서 시작해 작게 리팩토링하는 것이 더 낫다
문제 영역을 한 번에 너무 여러 개의 서비스로 분해하는 것은 마이크로서비스가 단지 데이터 서비스의 역할만 수행하고 너무 많아 복잡해질 수 있음.
✏️ 2. 서비스 간 교류하는 방식에 먼저 집중한다
서비스 간 교류하는 방식에 먼저 집중하는 것은 문제 영역에 대한 큰 단위의 인터페이스르 만드는 데 도움된다. -> 초반에 인터페이스 크게 만들고 점차 작게 리팩토링 할 것.
✏️ 3. 문제 영역에 대한 이해가 깊어짐에 따라 서비스 책임도 계속 변한다
마이크로서비스는 단일 서비스에서 시작해 여러 서비스로 분화되며 성장하는데, 원래 서비스는 새로운 서비스들을 오케스트레이션 (orchestration)하고 애플리케이션의 다른 부분에서 새 서비스들의 기능을 캡슐화한다.
오케스트레이션은 컴퓨터 시스템과 애플리케이션, 서비스의 자동화된 설정, 관리, 조정을 의미함
MSA는 처음부터 올바르게 설계하기 어렵기에 잘게 나뉜 서비스보다 굵게 나뉜 서비스에서 시작하는 것이 더 좋다. 너무 잘계 나뉘면 분리된 두 서비스 사이에 지나친 호출이 발생하기 때문에 데이터를 합치는 집합 (aggregation) 서비스를 별도로 만들거나 서비스 영역의 명확한 경계선이 없는 서비스에서 물리적 제약이 발생할 수 있다.
✔️ 지나치게 굵게 쪼개진 마이크로서비스의 특징
| 특징 | 설명 |
|---|---|
| 책임이 너무 많은 서비스 | 이 서비스에서 비즈니스 로직의 일반 흐름은 복잡하며 지나치게 다양한 종류의 비즈니스 규칙을 시행하게 된다 |
| 많은 테이블의 데이터를 관리하는 서비스 | 마이크로서비스는 3~5개 이내의 테이블을 소유하는 것이 적절하다 |
| 과다한 테스트 케이스 | 테스트 케이스가 많다는 것은 변경에 대한 위험성이 크다는 것을 의미한다. |
✔️ 지나치게 잘게 쪼개진 마이크로서비스의 특징
| 특징 | 설명 |
|---|---|
| 한 문제 영역 부분에 속한 마이크로서비스가 토끼처럼 번식함 | 작업 수행에 필요한 서비스 개수가 증가해서 비즈니스 로직을 만드는 것이 복잡하고 어려워짐, 애플리케이션에 수십 개의 마이크로서비스가 있고 각 서비스가 하나의 데이터베이스 테이블과 통신할 때 관리하기 어려워짐 |
| 지나치게 상호 의존적인 마이크로서비스 | 문제 영역의 한 부분에 있는 마이크로서비스는 하나의 사용자 요청을 완료하기 위해 각 서비스가 서로 계속 호출함 |
| 마이크로서비스가 단순 CRUD (Create, Read, Update, Delete) 집합이 됨 | 마이크로서비스는 비즈니스 로직의 표현이지 데이터 소스 (data sources)의 추상화 계층이 아님 |
⭐ 3. 서비스 인터페이스
서비스 인터페이스란 말 그대로 애플리케이션의 마이크로서비스가 대화하는 방식을 정의하는 것이다.
✏️ 1. REST 철학을 수용할 것
서비스에 대한 REST 방식은 서비스의 호출 프로토콜로 HTTP를 수용하고 표준 HTTP 동사 (GET, PUT, POST, DELETE)를 사용하는 것이 핵심이다. HTTP 동사를 기반으로 기본 행동 양식을 모델링한다.
✏️ 2. URI를 사용해도 의도(intent)를 전달할 것
서비스의 엔드포인트로 사용되는 URI는 문제 영역에 존재하는 다양한 자원을 기술하고 자원 관계에 대한 기본 메커니즘을 제공해야 한다
✏️ 3. 요청(request)과 응답(response)에 JSON을 사용할 것
JSON은 초경량 데이터 직렬화 프로토콜이며 XML보다 훨씬 사용하기 쉽다
✏️ 4. HTTP 상태 코드로 결과를 전달하라
HTTP 프로토콜에는 서비스의 성공과 실패를 명시하는 풍부한 표준 응답 코드가 있다. 상태 코드를 익히고 모든 서비스에 일관되게 사용하는 것이 매우 중요하다.
