MSA에 대한 기본개념 - 2. 동기 비동기 호출

Micro Service Architecture 설계의 발전

 

1. Rest API 방식의 설계 (동기호출)

- Code Coupling 해소. 그러나 Time Coupling 잔존

- 서비스 Blocking 가능성 내제

- 장애전파 우려

- Point to Point 연결에 따른 복잡한 스파게티 네트워크

Request-Response 모델의 데이타 보호

장애전파를 방지하기 위해 필요한것이 서킷브레이커 패턴. 하나의 트랜젝션이 가능한 블로킹이 발생하지 않도록 미리 차단 → Fail-Fast 전략 메모리 사용 폭주 막음

 

장애 감지시 차단기 작동

▶

일시 동안 Failback으로 서비스 대체

▶

일부 트래픽으로 서비스 정상여부 확인

▶

정상 확인 시 차단기 해제

 

 

Rest방식 MSA 에서도 모놀리식의 2단계 커밋을 구현(TCC, Saga)

• 커밋단계에서 하나의 Mircro Service이 다른 트랜젝션을 Roll Back할 수 있는 메카니즘이 없음
• 관련된 서비스는 가장 늦게 Confirmation이 완료되는 시점까지 모두 기다려야함. 이는 리소스가 다른서비스의 이슈에 따른 Lock이 발생한다고 할 수 있음
• 2단계 커밋은 트랜젝션 관리자가 디자인함에 따라 느려질수 있어 확장성 이슈, 롤백시나리오 등에서 문제가 발생할 수 있다.

이를 극복하기 위해 TCC패턴을 사용한다.

Confirm이라는 알고리즘을 추가하여 원자성을 구현

TCC패턴

또는 Saga 패턴을 개발하기도 한다. Saga패턴은 TCC와 2단계 커밋과 다르게 각 트랜젝션이 개별로 완료된다. 즉 트랜젝션의 Commit을 관리하기 보다 트랜젝션 처리 프로세스 알고리즘을 개발하여 극복하는 것이다. 아래 예시를 보면 트랜젝션 처리와 Rollback 발생이슈에 대한 모든 경우의 수를 고려해서 알고리즘을 작성하였다. 

Saga 패턴 예시

Saga패턴의 Rollback시나리오

2. Pub-Sub 방식의 설계 (비동기호출)

• 상대의 수신을 기다리지 않는 비동기식 메시지 사용.(=Subscriber가 본인의 Pace에 맞추어 메시지 소비)
• 메시지 처리는 Queue 방식의 Append만 있을뿐 수정, 삭제가 없다
• Event Driven Architecture 구현에 적합(=Saga패턴도 Rollback 이벤트로 구현)

 

 

Pub-Sub방식 MSA 에서도 모놀리식의 2단계 커밋을 구현(Saga)

모든 통신을 담당하는 중앙 오케스트레이터가 올바른 순서로 서비스를 제공하고 문제가 발생하면 서비스마다 보상 트랜잭션을 취한다.

중앙 오케스트레이터는 서비스를 호출하지만 서비스는 오케스트레이터를 호출하지 않기 때문에 종속성을 방지할 수 있다. 또한 중앙 집중적으로 관리할 수 있어 크고 복잡한 마이크로 서비스에 알맞는 패턴이다.

3. 동기 vs 비동기 선택의 기로

• 내 서비스에서 데이터 불일치가 얼마나 Mission Critical 한가?
• 만약 Criticla 하다면 내 서비스의 성능, 확장성의 가치와 비교한다면 더 큰 가치를 상실할 수 있나?
• 성능과 확장성 보다 크리티컬 하다면, 성능과 확장성을 포기할 수 있는가?
• 성공한 경쟁자들은 무엇을 포기했는가?

---

Integration Pattern/Tool	Database(Schema per Service)	UI	Req-Resp	Pub-Sub
Reading(Query)	View	UI Composition + HATEOAS	API Composition HTTP Request + Circuit Breaker	CORS
Writing	Trigger	Not Recommended	TCC, Saga	Saga(Event Consistency)