[아키텍처] 마이크로 서비스 아키텍처(MSA)

높은 응집력과 느슨한 결합력

"같은 이유로 변경되는 것을 함께 모아라. 다른 이유로 변경이 되는 것은 분리하라." -로버트 마틴의 단일 책임 원칙

---

 

마이크로 서비스의 2가지 기본 속성

1. 각 카이크로 서비스는 독립적으로 배포될 수 있다. 그렇지 않으면 마이크로 서비스 애플리케이션은 배포 시점에 여전히 모놀리식이 된다.

2. 마이크로서비스는 교체할 수 있다. 이 역량은 자연스럽게 마이크로서비스의 크기를 제한한다. 마찬가지로 이는 서비스의 책임 또는 역할을 이해하기 쉽게 만든다.

 

 

마이크로 서비스의 핵심 원칙

1. 자율성 : 각 서비스는 다른 서비스와 독립적으로 변경되고 운영된다.

2. 회복성 : 장애를 격리하는 자연스러운 매커니즘 → 한 부분에서 장애가 발생해도 다른 부분에는 장애가 발생하지 않음. 장애가 회복되었을 대, 기능을 실행하면 됨.

3. 투명성 : 언제 장애가 발생했는지 아는 것

4. 자동화 : 정확한 배포와 운영을 보장한다.

5. 동기화 : 개발팀이 같은 생각을 해야 한다.

 

SOA vs. MSA

SOA는 수평적인 분해, MSA는 수직적인 분해를 한다.

 

 

마이크로 서비스를 어디에서 도입했는가?

콘텐츠 배포 → 사운드 클라우드, 넷플릭스

운송 및 물류 → 우버, 헤일로

전자상거래 → 아마존, 길트, 잘란도

사회관계망 서비스 → 트위터

 

 

심플뱅크 예시로 MSA 설계 알아보기

심플뱅크(가상의 회사) : 자금의 규모에 상관 없이 모두에게 가능한 스마트 금융 투자를 제공하기를 원하는 가상의 금융 회사

→ 주식 구매, 펀드 매각, 통화 거래 등이 예금 계좌를 개설하는 것만큼 간단해야 한다

 

심플뱅크 계정에서 주식 매도 주문을 내는 절차

 

 

(1) 도메인 모델링을 통한 마이크로서비스 식별하기

소프트웨어 도메인에 대한 이해를 발전시켜야 한다. ← 제품 탐색(product discovery), 비지니스 분석(연구, 시안, 고객 인터뷰)

 

(위의 예시에서) 전달하고자 하는 가치가 무엇인가?

높은 수준 : 고객을 주문을 내기를 원함 → 주문의 상태를 저장 & 관리

 

그 다음부터는 애플리케이션이 제공해야 할 다른 기능을 식별해야 한다

✓ 매도 주문의 상태와 이력을 기록
✓ 고객에게 매도 주문의 수수료를 부과
✓ 고객 계정에 트랜잭션 기록
✓ 시장에 주문 제출
✓ 소유 주식의 가치를 제공하고 고객에게 주문

 

어떤 기능이 응집되는지 결정해서 함께 묶어야 한다.

 

애플리케이션의 기능과 심플뱅크 비지니스 역량간의 관계

 

(2) 서비스 간의 협업

· 점대점 방식(동기식)

· 이벤트 주도 방식(비동기식)

 

주문 서비스는 주문을 시장에 내놓기 위해 다른 여러 서비스와 조율한다.

 

서비스 계약(contracts)

각 서비스가 수신하고 응답하는 메시지는 서비스에 의존하는 상위 조율 서비스와 계약을 형성한다.

[예] 요청을 보내고 응답을 받을 때 에러 없이 진행되면 그 서비스는 해야 할 일을 하고 있는 것

1. 변경이 컨슈머에 장애를 일으키지 않아야 한다.

2. 서비스 간 의존성을 명확하게 식별하고 관리할 수 있어햐 한다.

 

서비스 책임

(위의 그림에서) 주문 서비스는 상당한 책임을 가진다. 주문 제출 처리 과정에서 모든 다른 서비스를 직접 조율한다.

 

 

(3) 서비스의 자율적 구성

마이크로 서비스 내에서 서비스는 자연스럽게 다른 수준의 책임을 가지지만, 자율적 구성과 조율의 균형을 맞추어야 한다.

자율적으로 구성된 시스템에서는 하나의 서비스가 다른 서비스의 활동을 직접 지시하거나 유발할 필요가 없다. 대신, 각 서비스는 다른 이벤트에 반응을 수행하는 독특한 책임을 가진다.

 

✓ 누군가 주문을 생성할 때, 시장이 개장하지 않았을 수 있다. → 주문의 상태를 생성됨 또는 제출됨으로 기록해야 함 : 주문 제출을 동기식으로 수행될 필요가 없음
✓ 주문이 제출되면 수수료만 부과됨 → 수수료 부과는 동기식으로 수행될 필요가 없음

 

이벤트를 통해 다른 서비스의 행동을 자율적으로 구성하고 주문 서비스의 조율 역할을 줄였다

 

위의 설계는 주문 서비스에서 다음의 책임을 제거했다.

 

✓ 수수료 부과하기 : 주문 서비스는 주문이 시장데 제출되면 수수료 부과에 대해 알 필요가 없다.
✓ 주문 제출하기 : 주문 서비스는 시장 서비스와 직접 협업하지 않는다. 그래서 주문 서비스 자체에 영향을 주지 않고 시장 서비스를 다른 구현으로 바꾸거나 심지어 시장별로 서비스를 구현할 수도 있다.

 

 

다음 장은 API 부터...