Micro Service Architecture - 6. IPC 3

비동기 메시징 패턴 응용 통신

비동기 메시징은 메시지 브로커를 사용하는 경우 브로커 없이 서비스가 직접 하는 경우가 있다.

메시지

메시지는 Header와 Body 로 구성.
브로커를 사용하는 경우 메시지 채널을 통해서 교환 된다.

메시징 상호작용

클라이언트/서비스는 한 쌍의 메시지를 주고받는 비동기 요청/응답 스타일로 상호작용 한다.

클라이언트는 수행 작업과 매개변수를 메시징 요청 채널에 보내고
서비스는 요청 처리 후 메시지 응답 채널로 응답 한다.

클라이언트 → 요청 채널 → 서비스 → 응답 채널 → 클라이언트

구현 방법

1. 단방향 알림
   비동기 메시징을 이용하여 클라이언트만 서비스에 요청하고 서비스는 응답 하지 않음

2. 발행/구독
   메시징은 발행/구독 스타일을 기본 지원한다.
   클라이언트는 여러 Consumer가 읽는 발행/구독 채널에 발행하고 서비스는 요청에 대해 이벤트를 발행.
   이때 이벤트 발행한 서비스는 발행/구독 채널을 소유.

3. 발행/비동기 응답
   클라이언트는 응답 채널 헤더(CorrealtionId)를 포함한 메시지를 발행/구독 채널에 발행하고
   Consumer는 헤더를 확인 후 지정된 응답 채널에 응답 메시지 작성.
   응답을 받은 클라이언트는 요청과 응답의 CorrelationId를 비교

메시지 브로커

메시지 브로커는 서비스가 서로 통신할 수 있게 해주는 인프라 서비스.
브로커리스 아키텍쳐를 사용할 수도 있지만 일반적으로 브로커를 사용하는 것이 좋다.

브로커를 사용 했을때
장점

1. 클라이언트는 서비스에 위치를 몰라도 되며 요청만 하면 되서 가용성이 높음.
2. 전달 보장 등 신뢰성 기반 구현 가능.
3. 장애시 큐는 계속 요청을 계속 쌓아 놓는 버퍼링 기능.

단점

1. 송신자에서 수신자로 바로 가는것이 아니라 브로커를 거쳐 이동을 해 네트워크 트래픽과 지연시간이 보다 긺.
2. 브로커에 성능 병목점 혹은 Single Point of Failure(단일 장애)가 발생할 가능성.
3. 운영 복잡도가 보다 높음

브로커를 선택할 때는 다음 항목을 잘 검토 해야 한다.

• 프로그래밍 언어 지원
• 메시징 표준 지원
• 메시지 순서
• 전달 보장
• 영속화 : 장애시 메시지를 디스크에 저장 하는지
• 내구성
• 확장성
• 지연시간

메시징 기술

메시지를 처리하기 위해서 수평적 확장을 하는 것은 당연하다. 하지만 이런 경우에 순서를 유지하는 것은
더 중요하다.
예를 들어 주문자가 주문 생성, 주문 변경, 주문 취소 를 요청 했다고 가정,
메시징 처리는 주문자의 요청 순서에 따라서 처리가 되어야 한다는 것이다.

이런 처리를 위해서 메시지 브로커는 샤딩 채널을 이용.

1. 샤딩 채널은 복수의 샤드로 구성되며, 각 샤드는 채널처럼 작동.
2. 송신자는 메시지 헤더에 샤드키를 지정하고 메시지 브로커는 샤드 키별로 샤드/파티션에 배정.
3. 메시지 브로커는 여러 수신자 인스턴스들을 묶어 동일하게 취급하며, 갹 샤드를 하나의 수신자에게 배정.

중복 메시지 처리

메시지 브로커는 적어도 한번은 전달을 하겠다 를 보장하지만 클라이언트의 오류, 네트워크 등의 갖가지 오류에 발생시
어떻게 될지까지는 보장 하지 않는다. 따라서, 멱등한 메시지 핸들러 구현을 하고 메시지를 추적, 중복 방지를 해야한다.

소비자 신용카드를 승인하는 메시지 핸들러 가정, 주문별로 정확히 1회만 승인 해야한다.
컨슈머는 메시지 ID를 이용 DB 테이블에 저장을 하여 중복 확인을 하면 된다.
(중복시 INSERT Error 가 발생할 것 이랄까...)

DB 테이블로 메시징 큐 활용

OUTBOX 테이블을 임시 큐로 활용하는 방법.