TIL

3장 프로세스 간 통신

3.1 마이크로서비스 아키텍처 IPC 개요

서비스에 적용 가능한 IPC 기술은 많다.
- HTTP 기반 REST, gRPC 등의 동기 기반
- AMQP, STOM 등의 비동기 기반
메시지 포멧 역시 많다.
- JSON, XML 등의 텍스트 포맷
- 아브로나 프로토콜 버퍼 등의 이진 포맷

3.1.1 상호 작용 스타일

IPC 기술을 선택하기 전 클라이언트/서비스 간 상호 작용 스타일을 살펴봐야 한다.
상호 작용 스타일은 두 가지 기준으로 분류할 수 있다.
- 일대일/일대다 여부
- 동기/비동기 여부
일대일 상호 작용도 종류는 다양하다.
- 요청/응답: 클라이언트는 서비스에 요청을 하고 응답을 기다린다.
- 비동기 요청/응답: 클라이언트는 서비스에 요청을 하고 서비스는 비동기적으로 응답. 클라이언트는 블로킹하지 않는다.
- 단방향 알림: 클라이언트는 서비스에 일방적으로 요청하고 서비스는 응답을 보내지 않는다.
일대다 상호 작용도 몇 가지 종류가 있다.
- 발행/구독: 클라이언트는 알림 메시지를 발행하고 여기에 관심 있는 0개 이상의 서비스가 메시지를 소비
- 발행/비동기 응답: 클라이언트는 요청 메시지를 발행하고 주어진 시간 동안 관련 서비스가 응답하길 기다린다.

3.1.2 마이크로서비스 API 정의

API와 인터페이스는 소프트웨어 개발의 핵심이다.
- 각 모듈마다 자신의 클라이언트가 호출하는 인터페이스가 존재
- MSA에서도 API와 인터페이스는 똑같이 중요하다.
MSA에서 API는 단순한 프로그래밍 언어의 일부가 아니다.
- 함께 컴파일되지 않는다.
- 새 버전의 서비스가 호환되지 않는 API에 맞물려 배포되면 런타임에 실패한다.
어떤 IPC를 사용하든 서비스 API를 IDL(Interface Definition Language)로 정확하게 정의하라
- API를 정의, 명세서 작성 후 서비스를 구현
API는 어떤 IPC를 사용하느냐에 따라 내용이 결정된다.

3.1.3 API 발전시키기

모놀리식에선 API 변경이 어렵지 않다.
- 자바 같은 정적 타입 언어를 사용한다면 컴파일러를 통해 쉽게 변경부를 찾아갈 수 있다.
마이크로서비스 애플리케이션에선 서로 다른 서비스 팀 간 API를 변경하기가 무척 어렵다.
- 또 요즘은 무중단 배포를 하기 때문에 규칙적인 단계로 서비스를 업그레이드하며 신구 버전을 동시에 실행한다.

시멘틱 버저닝

시멘틱 버저닝 명세는 API 버저닝에 관한 유용한 지침서다.
- 버전 번호를 사용하고 증가시키는 규칙들이 명시되어 있다.
이 명세에 따르면 버전 번호를 세 파트로 구성하고 다음 규칙에 따라 증가시킨다.
- MAJOR: 하위 호환되지 않는 변경분을 API에 적용 시
- MINOR: 하위 호환되는 변경분을 API에 적용 시
- PATCH: 하위 호환되는 오류 수정 시
버전 번호 명시 방법
- REST API라면 URL 경로 첫 엘리먼트로 쓸 수 있다.
- 메시징 기반이라면 발행한 메시지에 넣을 수 있다.

하위 호환되는 소규모 변경

변경이 있더라도 가급적 하위 호환성을 보장하도록 해야 한다.
- 옵션 속성을 요청에 추가
- 속성을 응답에 추가
- 새 작업을 추가
이런 종류의 변경은 새 서비스에 적용해도 기존 클라이언트 역시 별 문제 없이 동작한다.
단 ‘견고성 원칙’을 지켜야 한다.
- “당신이 하는 일은 보수적으로, 다른 사람들이 하는 일은 관대하게 바라보라”
- ex) 요청 속성이 누락되어도 서비스는 기본값을 제공
- ex) 서비스가 필요한 것보다 더 많은 속성을 응답하더라도 클라이언트는 간단히 무시

중대한 대규모 변경

기존 버전과 호환이 안 되는 변경을 적용해야할 때가 있다.
일시에 클라이언트를 강제로 업그레이드하는 것은 불가능하기에 신구 버전 API를 모두 지원해야 한다.
- REST API의 경우 URL에 메이저 버전 번호를 삽입할 수 있다.
  - ex) /v1/posts/…
- HTTP 컨텐츠 협상(content negotiation)을 이용하는 방법도 있다.
  - MIME 타입 내부에 버전 번호를 끼워 넣기
여러 API를 지원하려면 서비스 어댑터에 신구 버전을 올바르게 중계하는 로직이 있어야 한다.
- API 게이트웨이는 거의 반드시 버저닝된 API를 사용하고 심지어 구 버전 API도 여럿 지원해야 하는 경우도 있다.

3.1.4 메시지 포맷

IPC의 핵심은 메시지 교환
메시징이나 HTTP 프로토콜에선 메시징 포맷을 선택해야 한다.
gRPC는 메시지 포맷이 정해져 있다.
메시지 포맷은 크게 텍스트와 이진 포맷으로 분류된다.

텍스트 메시지 포맷

텍스트 기반 포맷은 사람이 읽을 수 있어 자기 서술적인 장점이 있다.
- JSON 메시지는 네임드 프로퍼티 구조
- XML 메시지는 네임드 엘리먼트와 그 값을 모아 놓은 구조
- 메시지 컨슈머는 관심 있는 값만 골라쓰고 나머지는 무시해도 되기에 하위 호환성이 쉽게 보장된다.
텍스트 메시지 포맷의 단점은 메시지가 다소 길다는 것
- 속성 값 이외에 속성명이 추가되는 오버헤드
- 덩치 큰 메시지는 파싱하는 오버헤드
- 효율/성능이 중요한 경우 이진 포맷을 고려할 수 있다.

이진 메시지 포맷

이진 포맷 종류 중 프로토콜 버퍼와 아브로가 유명
- 두 포맷 모두 메시지 구조 정의에 필요한 타입 IDL을 제공
- 컴파일러는 메시지 직렬화/역직렬화 코드를 생성
API 발전 측면에선 프로토콜 버퍼가 더 용이
- 아브로 컨슈머는 스키마를 알아야 메시지를 해석할 수 있기 때문

3.2 동기 RPI 패턴 응용 통신

RPI (Remote Procedure Invocation, 원격 프로시저 호출)
- 클라이언트가 서비스에 요청을 보내면 서비스가 처리 후 응답을 하는 회신 IPC
- 블로킹일 수도 논블로킹일 수도 있지만 메시징과 다르게 응답이 도착한다 가정

3.2.1 동기 RPI 패턴: REST

REST는 HTTP로 소통하는 IPC이고 현재 API 개발은 REST가 대세이다.
리소스는 REST의 핵심 개념
- HTTP 메서드를 사용해 URL에 참조되는 리소스를 가공
개발자는 대부분 REST한 API라고 설계하지만 로이 필딩의 글에 의하면 실제로 그렇지 않은 API도 많다.

REST 성숙도 모델

레너드 리처드슨은 REST가 얼마나 성숙한지 알 수 있는 성숙도 모델을 제시했다.
레벨 0
- 클라이언트는 서비스별 유일한 URL 엔드포인트에 POST 요청을 하여 서비스를 호출
- 요청할 때마다 어떤 액션을 어떤 대상에 수행할지 지정
- 필요한 매개변수도 함께 전달
레벨 1
- 서비스는 리소스 개념을 지원
- 클라이언트는 수행할 액션과 매개변수가 지정된 POST 요청
레벨 2
- 서비스는 HTTP 메서드로 액션을 수행 (GET: 조회, POST: 생성, PUT: 수정)
- 요청 쿼리 매개변수 및 바디 필요 시 매개변수 지정
- 덕분에 GET 요청을 캐싱하는 등 웹 인프라 활용 가능
레벨 3
- 서비스를 HATEOAS 원칙에 기반하여 설계
- HATEOAS는 GET 요청으로 반환된 리소스 표현형에 그 리소스에 대한 액션의 링크도 함께 태워 보내는 것
- ex) GET으로 주문 데이터를 조회하고 이 때 반환된 표현형 내부 링크를 이용해 해당 주문을 취소 가능
- HATEOAS를 사용하면 하드 코딩한 URL을 클라이언트 코드에 욱여 넣지 않아도 된다.

REST 장단점

장점
- 단순하고 익숙하다
- 포스트맨 등 플러그인이나 curl 등의 CLI 도구로 간편하게 테스트 가능
- 요청/응답 스타일의 통신을 직접 지원
- HTTP는 방화벽 친화적
- 중간 브로커가 필요하지 않아 시스템 아키텍처가 단순하다.
단점
- 요청/응답 스타일의 통신만 지원
- 가용성이 떨어진다.
  - 중간에서 메시지를 버퍼링하는 매개자 없이 클라/서비스가 직접 통신하기에 양쪽 다 실행 중이어야 함
- 서비스 인스턴스들의 위치(URL)를 클라이언트가 알고 있어야 한다.
- 요청 한 번으로 여러 리소스를 가져오기 어렵다.
  - REST는 비즈니스 객체 중심이기 때문
  - 데이터를 효율적으로 조회할 수 있게 설계된 GraphQL이나 넷플릭스 팔코 등 대체 API 기술이 존재
- 다중 업데이트 작업을 HTTP 동사에 매핑하기 어려울 때가 많다.
  - 수정할 때 PUT을 많이 쓰지만 데이터를 수정하는 시나리오는 다양하다.

3.2.2 동기 RPI 패턴: gRPC

gRPC
- 다양한 언어로 클라이언트/서버를 작성할 수 있는 프레임워크
- 이진 메시지 기반 프로토콜이므로 서비스를 API 우선 방식으로 설계할 수밖에 없다.
gRPC API는 하나 이상의 서비스와 요청/응답 메시지 데피니션으로 구성된다.
- 서비스 데피니션은 정적 타입 메서드를 모아 놓은 것으로 자바 인터페이스와 비슷하다.
- 단순 요청/응답 뿐 아니라 스트리밍 RPC도 지원
gRPC는 프로토콜 버퍼 메시지 포멧을 사용
- 프로토콜 버퍼: 간결하고 효율적인 이진 포멧으로 구조화 데이터를 직렬화하는 구글의 언어 중립적 메커니즘
- 프로토콜 버퍼 컴파일러로 클라이언트 쪽 스텁 및 서버 쪽 스켈레톤을 생성할 수 있다.
- 프로토콜 버퍼 메시지는 각 필드마다 번호가 매겨지고 타입 코드가 할당된다.
- 메시지 수신자는 필요한 필드만 추출하고 모르는 필드는 건너뛸 수 있어 하위 호환성이 유지된다.

// 주문 서비스 gRPC API 예시
service OrderService {
    rpc createOrder(CreateOrderRequest) returns (CreateORderReply) {}
    rpc cancelOrder(CancelOrderRequest) returns (CancelORderReply) {}
    rpc reviseOrder(ReviseOrderRequest) returns (ReviseOrderReply) {}
    ...
}

message CreateOrderRequest {
    int64 restaurantId = 1;
    int 64 consumerId = 2;
    repeated LineItem lineItems = 3;
    ...
}

message LineItem {
    string menuItemId = 1;
    int32 quantity = 2;
    ...
}

...

gRPC 장점
- 다양한 업데이트 작업이 포함된 API를 설계하기 쉽다.
- 특히 큰 메시지를 교환할 때 콤팩트하고 효율적인 IPC
- 양방향 스트리밍 덕분에 RPI, 메시징 두 통신 방식 모두 가능
- 다양한 언어로 작성된 클라이언트/서버 간 연동이 가능
gRPC 단점
- 자바스크립트 클라이언트가 하는 일이 REST 기반 API보다 더 많다.
- 구형 방화벽은 HTTP/2를 지원하지 않는다.
gRPC는 REST처럼 동기 통신 메커니즘이기에 부분 실패 문제는 풀어야할 숙제이다.

3.2.3 부분 실패 처리: 회로 차단기 패턴

분산 시스템은 서비스 간 동기 호출 시 부분 실패할 가능성이 항상 존재한다.
- 모두 개별 프로세스로 동작하기에 제 때 응답하지 못하거나 과부하로 인한 심한 지연도 존재
- 블로킹 기반이라면 서비스 실패는 클라이언트의 클라이언트로 거슬러 올라가며 전체 시스템 중단을 초래할 수도 있다.
회로 차단기 (circuit breaker)
- 연속 실패 횟수가 주어진 임계치를 초과하면 일정 시간 동안 호출을 즉시 거부하는 RPI 프록시
- 원격 서비스가 실패하면 어떻게 조치해야 할지 결정해야 한다.

견고한 RPI 프록시 설계

네트워크 타임아웃
- 응답 대기 중 무한정 블로킹하면 안 되고 항상 타임아웃을 걸어 둔다.
미처리 요청 개수 제한
- 클라이언트가 특정 서비스에 요청 가능한 미처리 요청 최대 개수를 설정한다.
- 이 개수에 이르면 더 이상의 요청은 무의미하므로 즉시 실패 처리를 하는 것이 타당
회로 차단기 패턴
- 성공/실패 요청 개수에서 에러율이 임계치를 초과하면 이후 시도는 바로 실패 처리
- 실패율이 높다는 것은 서비스가 불능상태라고 판단

넷플릭스 히스트릭스는 위와 같은 다양한 패턴이 구현된 오픈 소스 라이브러리이다. JVM 환경이라면 히스트릭스를 이용해 RPI 프록시를 구현해볼 수 있다.

불능 서비스 복구

히스트릭스는 부분적 솔루션에 불과하다.
무응답 서비스를 어떻게 북구할지는 상황에 맞게 판단해야 한다.
복구 및 대응 방법
- 클라이언트에 알기 쉽게 에러를 반환
- 실패 시 미리 정해진 기본값이나 캐시된 응답 등 대체 값을 반환
부분 실패 처리 이외에도 RPI에 해결해야할 이슈는 많다.
- 서비스가 타 서비스를 호출할 때 해당 서비스 인스턴스 네트워크 위치를 알아야 하는 것도 문제

3.2.4 서비스 디스커버리

서비스 간 통신할 때 각 서비스 네트워크 위치(IP)를 알아야 요청을 할 수 있다.
서비스 인스턴스 위치는 대부분 정적이지만 MSA 환경에선 네트워크 위치는 훨씬 동적이라 식별이 간단하지 않다.
클라이언트 코드는 서비스 디스커버리를 사용할 수밖에 없다.

서비스 디스커버리 개요

애플리케이션 서비스 인스턴스의 네트워크 위치를 DB화한 서비스 레지스트리
서비스 인스턴스가 시작/종료할 때마다 서비스 레지스트리가 업데이트
클라이언트가 서비스를 호출하면 우선 서비스 디스커버리가 레지스트리에서 가용 서비스 인스턴스 목록을 가져오고 그 중 한 서비스로 라우팅
서비스 디스커버리 구현
- 클라이언트/서비스가 직접 레지스트리와 상호작용
- 배포 인프라로 시비스 디스커버리를 처리

애플리케이션 수준의 서비스 디스커버리 패턴 적용

클라이언트/서비스가 서비스 레지스트리와 직접 통신하는 방법
- 서비스 인스턴스는 자신의 네트워크 위치를 서비스 레지스트리에 등록 (자가 등록 패턴)
- 클라이언트는 레지스트리에서 서비스 인스턴스 목록을 가져와 한 인스턴스로 라우팅 (클라이언트 쪽 디스커버리 패턴)
스프링 클라우드를 통해 디스커버리를 구현할수 있다.
- 넷플릭스의 유레카라는 고가용성 서비스 레지스트리 기반으로 구현됨
- 스프링 기반 서버가 아니라면 다른 디스커버리 프레임워크나 배포 인프라가 제공하는 디스커버리 메커니즘을 활용하는 것이 좋다.

플랫폼에 내장된 서비스 디스커버리 패턴 적용

도커나 쿠버네티스 등에는 대부분 서비스 레지스트리, 서비스 디스커버리가 탑재되어 있다.
배프 플랫폼은 DNS명, 가상 IP 주소, VIP 주소로 해석되는 DNS 명을 서비스마다 부여하고 알아서 그 중 하나로 라우팅한다.
서드파티 등록 패턴
- 서비스가 자신을 레지스트리에 등록하는 것이 아닌 배포 플랫폼의 등록기가 대행
서버 쪽 디스커버리 패턴
- 클라이언트가 서비스 레지스트리를 질의하지 않고 DNS명을 요청
- 서비스 레지스트리를 쿼리하고 요청을 부하 분산하는 요청 라우터로 해석

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

메시징은 서비스가 메시지를 비동기적으로 주고 받는 통신
메시징 기반 애플리케이션
- 서비스 간 중계 역할을 하는 메시지 브로커를 사용
- 브로커리스 아키텍처도 존재
비동기 통신을 하기에 클라이언트가 응답을 기다리며 블로킹하지 않는다.

3.3.1 메시징 개요

메시징 모델
- 송신자가 채널에 메시지를 쓰면 수신자는 메시지를 읽는다.
메시지
- 헤더와 본문(body)로 구성
- 텍스트 또는 이진 포맷
- 메시지 종류
  - 문서: 데이터만 포함한 제네릭한 메시지
  - 커맨드: RPC 요청과 동등한 메시지로 호출할 작업과 매개변수가 지정되어 있다.
  - 이벤트: 송신자에게 어떤 사건이 발생했음을 알리는 메시지. (도메인 객체의 상태 변화 등)
메시지 채널
- 메시지는 채널을 통해 교환된다.
- 송신자의 비즈니스 로직은 송신자 어댑터로 구현한 송신 포트 인터페이스를 호출
- 전달된 메시지는 수신자 핸들러 어댑터가 호출되어 처리되고 수신자 비즈니스 로직인 수신 포트 인터페이스가 호출된다.
- 채널의 종류
  - 점대점 채널: 채널을 읽는 컨슈머 중 딱 하나만 지정하여 메시지를 전달
  - 발행-구독 채널: 같은 채널을 바라보는 모든 컨슈머에게 메시지를 전달

3.3.2 메시징 상호 작용 스타일 구현

요청/응답 및 비동기 요청/응답
- 이 방식은 모두 클라이언트가 요청을 보내면 서비스가 응답한다.
- 메시징은 원래 비동기적이기에 비동기적인 응답을 제공한다.
- 클라이언트는 요청 채널에 요청 메시지를 발행하고 서비스는 요청을 처리한 뒤 응답 채널에 응답 메시지를 발행, 클라이언트가 이를 수신한다.
- 요청과 응답의 짝이 맞아야하기에 MessageId 등을 활용하여 메시지를 식별한다.
단방향 알림
- 단방향 알림은 비동기 메시징을 이용하여 지관적으로 구현할 수 있다.
- 단방향이므로 서비스는 응답을 반환하지 않는다.
발행/구독
- 클라이언트는 여러 컨슈머가 읽는 채널에 메시지를 발행
- 채널을 구독한 컨슈머는 이벤트를 수신해 로직을 처리
발행/비동기 응답
- 발행/구독과 요청/응답 엘리먼트를 조합한 고수준 상호 작용 스타일
- 클라이언트는 응답 채널 헤더가 명시된 메시지를 채널에 발행하고 컨슈머는 CorrelationId가 포함된 응답 메시지를 지정된 응답 채널에 쓴다.
- 클라이언트는 CorrelationId로 취합하여 요청을 맞추어 본다.

3.3.3 메시징 기반 서비스의 API 명세 작성

메시지 채널명, 각 채널을 통해 교환되는 메시지 타입과 포맷을 명시하면 된다.
- 메시지 포맷은 JSON, XML, 프로토콜 버퍼 등 표준 포맷으로 기술
- 정해진 문서화 표준이 없어 자유롭게 기술하면 된다.
서비스 비동기 API 종류
- 클라이언트가 호출하는 작업(커맨드)
- 서비스에 의해 발행되는 이벤트
비동기 작업 문서화
- 요청/비동기 응답 스타일 API: 서비스의 커맨드 메시지 채널, 서비스가 받는 커맨드 메시지 타입과 포맷, 서비스가 반환하는 응답 메시지 포맷으로 구성
- 단방향 알림 스타일 API: 서비스의 커맨드 메시지 채널, 서비스가 받는 커맨드 메시지 타입과 포맷
발행 이벤트 문서화
- 이벤트 채널, 서비스가 채널에 발행하는 이벤트 메시지 타입과 포맷으로 구성

3.3.4 메시지 브로커

메시지 브로커
- 서비스가 서로 통신할 수 있게 해주는 인프라 서비스
- 메시징 기반 애플리케이션은 대부분 메시지 브로커를 사용
- 브로커리스 기반 메시징 아키텍처도 존재하나 일반적으로 브로코 기반이 더 낫다.

브로커리스 메시징

브로커리스 아키텍처 서비스는 메시지를 서로 직접 교환한다.
- ex) ZeroMQ
브로커리스 아키텍처 장점
- 송신자에서 수신자로 직접 전달되므로 네트워크 트래픽이 가볍고 지연이 짧다.
- 메시지 브로커가 성능 병목점이거나 SPOF가 될 일이 없다.
- 메시지 브로커를 설정/관리할 필요가 없어 운영 복잡도가 낮다.
브로커리스 아키텍처 단점
- 서비스가 서로의 위치를 알아야해서 서비스 디스커버리 메커니즘 사용 필요
- 메시지 교환 시 송/수신자 모두 실행 중이어야 하므로 낮은 가용성
- 전달 보장 메커니즘 구현이 어렵다.

브로커 기반 메시징 개요

메시지 브로커
- 모든 메시지가 지나가는 중간 지점
- 송신자가 브로커에 메시지를 쓰면 수신자에 전달
- 가장 큰 장점은 송신자가 수신자 네트워크 위치를 몰라도 된다.
- 컨슈머가 메시지를 처리할 수 있을 때까지 브로커에 메시지를 버퍼링할 수도 있다.
메시지 브로커 제품
- ActiveMQ, RabbitMQ, 아파치 카프카
- AWS 키네시스, AWS SQS 등의 클라우드 메시징 시스템도 존재
메시지 브로커 선택 시 검토 사항
- 프로그래밍 언어 지원 여부
- 메시징 포준 지원 여부
  - AMQP나 STOMP 등 표준 프로토콜을 지원하는지
- 메시지 순서가 유지 여부
- 전달 보장
- 영속화
  - 메시지를 디스크에 저장하는지
- 내구성
  - 컨슈머가 브로커에 재접속할 경우 중단 시간에 받은 메시지를 처리할 수 있는지
- 확장성이 좋은지
- 종단 간 지연 시간
- 경쟁사 컨슈머 지원 여부

메시지 브로커로 메시지 채널 구현

메시지 채널은 브로커마다 구현 방식이 조금씩 다르다.

메시지 브로커	점대점 채널	발행-구독 채널
JMS	큐	토픽
아파치 카프카	토픽	토픽
AMQP 브로커 (RabbitMQ)	익스체인지 + 큐	팬아웃 익스체인지, 컨슈머 개별 큐
AWS 키네시스	스트림	스트림
AWS SQS	큐	-

브로커 기반 메시징의 장단점

장점
- 느슨한 결합
  - 클라이언트는 서비스 인스턴스를 몰라도 되기에 디스커버리 메커니즘이 필요 없다.
- 메시지 버퍼링
  - 브로커는 처리 가능한 시점까지 메시지를 버퍼링한다.
- 유연한 통신
  - 지금까지 설명한 모든 상호 작용 스타일을 지원한다.
- 명시적 IPC
  - RPC 메커니즘은 원격 서비스가 마치 자신의 로컬 서비스인 양 호출을 시도하지만 부분 실패 가능성이 있기에 사실 서비스와는 완전히 다르다.
단점
- 성능 병목 가능성
  - 브로커가 병목점이 될 위험
  - 요즘 브로커는 대부분 확장이 잘 된다.
- 단일 장애점 가능성
  - 브로커는 가용성이 높아야한다.
  - 요즘 브로커는 대부분 고가용성
- 운영 복잡도 부가
  3.3.5 수신자 경합과 메시지 순서 유지
일반적으로 메시지를 동시 처리하려면 인스턴스를 여럿 두어야 하지만 메시지 순서를 유지한 채 수평확장해야 한다.
아파치 카프카, AWS 키네시스 등의 브로커는 샤딩된(파티셔닝된) 채널을 이용한다.
1. 샤딩된 채널은 복수의 샤드로 구성되며 각 샤드는 채널처럼 작동한다.
2. 송신자는 메시지 헤더에 샤드 키를 지정하고 브로커는 샤드 키별로 샤드에 배정한다.
3. 브로커는 여러 수신자 인스턴스를 묶어 마치 동일한 논리 수신자처럼 취급한다. (카프카의 컨슈머 그룹)
샤딩/파티셔닝을 통해 같은 샤드 키 (파티션 키)에 해당하는 그룹 내에서는 순서를 보장할 수 있다.
- 여러 샤드에 걸친 메시지에 대해서는 보장하지 않는다.
- ex) orderId가 샤드 키인 경우 각 주문 별 이벤트의 순서는 보장할 수 있다.

3.3.6 중복 메시지 처리

비용 문제 때문에 메시지 브로커는 보통 적어도 한 번 이상 메시지 전달을 보장한다.
- 하지만 이 경우 네트워크 등의 문제로 인해 같은 메시지를 여러 번 보낼 수도 있다.
중복 메시지 처리 방법
- 멱등한 메시지 핸들러를 작성
- 메시지를 추적하고 중복을 솎아 내기

멱등한 메시지 핸들러 작성

동일한 입력 값을 반복 호출해도 아무런 부수 효과가 없을 때 멱등하다(idempotent)고 말한다.
- ex) 취소된 주문을 다시 취소하더라도 결과는 똑같다.
그러나 멱등한 로직은 실제로 별로 없다.

메시지 추적과 중복 메시지 솎아 내기

중목 메시지로 인해 로직이 여러 번 실행되면 안되는 경우엔 메시지 핸들러가 중복을 걸러야 한다.
메시지 ID를 이용하여 처리 여부를 추적하면 해결할 수 있다.

3.3.7 트랜잭셔널 메시징

애플리케이션에서 메시지를 확실하게 발행하려면 어떻게 해야 할까
- 서비스는 보통 DB를 업데이트하며 메시지를 발행
- DB 업데이트와 메시지 발행을 한 트랜잭션으로 묶어야 한다.
- DB 업데이트 후 메시지 발행이 되지 않는 경우가 생기면 시스템이 완전하지 않게 된다.

DB 테이블을 메시지 큐로 활용

트랜잭셔널 아웃박스 패턴
- RDBMS를 이용 중이라면 DB 테이블을 임시 메시지 큐로 이용하는 방법을 사용 가능
- 비즈니스 객체를 생성 또는 변경하는 것과 동시에 OUTBOX라는 DB 테이블도 함께 삽입하여 원자성 보장
- OUTBOX 테이블은 임시 메시지 큐 역할을 하고 메시지 브로커에 결국 전달되도록 로직을 구현 (메시지 릴레이)
미세지 릴레이 방법은 두 가지 있다.

이벤트 발행: 폴링 발행기 패턴

OUTBOX 테이블 내용을 메시지로 발행하는 간단한 방법은 테이블을 폴링해서 미발행 메시지를 조회하는 것
- 조회한 메시지를 브로커에 발행하고 OUTBOX 테이블에서 삭제
DB 폴링은 규모가 작을 경우 사용할 수 있는 단순한 방법
- DB를 자주 폴링하면 비용이 유발되기 때문

이벤트 발행: 트랜잭션 로그 테일링 패턴

메시지 릴레이로 DB 트랜잭션 로그(커밋 로그)를 테일링하는 방법
트랜잭션 로그 마이너로 트랜잭션 로그를 읽어 변경분을 하나씩 메시지 브로커에 발행
응용 사례
- 디비지움(Devezium): DB 변경분을 카프카 브로커에 발행하는 오픈 소스 프로젝트
- 링크드인 데이터버스: 오라클 트랜잭션 로그를 마이닝하여 변경분을 이벤트로 발행하는 오픈 소스 프로젝트
- DynamoDB 스트림즈: 최근 24시간 동안 DynamoDB 테이블 아이템에 적용된 변경분을 시간 순으로 정렬한 데이터를 갖고 있기에 읽은 뒤 이벤트로 발행 가능
- 이벤추에이트 트램(Eventuate Tram): 오픈 소스 트랜잭션 메시징 라이브러리. MySQL 빈로그 프로토콜, Postgres WAL, 폴링을 응용해 OUTBOX 테이블 변경분을 카프카로 발행
잘 작동하지만 문제는 개발 공수가 제법 소요된다.
- DB를 읽는 저수준 코드를 직접 작성하거나 오픈 소스 프레임워크를 사용

3.3.8 메시징 라이브러리/프레임워크

서비스가 메시지를 주고 받으려면 라이브러리가 필요한데 직접 사용하면 다음과 같은 문제가 있다.
- 메시지 브로커 API에 메시지를 발행하는 비즈니스 로직이 클라이언트 라이브러리와 결합
- 라이브러리는 대부분 저수준이기에 저수준 코드가 많아지게 된다.
- 라이브러리가 기본적인 메시지 소통 기능을 제공하기에 고수준 상호 작용 스타일은 지원하지 않는다.
따라서 고수준 상호 작용 스타일을 직접 지원하는 고수준 라이브러리 또는 프레임워크가 필요하다.
- ex)이벤추에이트 트램 프레임워크
  - 트랜잭셔널 메시징과 중복 메시지 감지를 구현하고 있음

3.4 비동기 메시징으로 가용성 개선

타 서비스와 동기 통신을 하게 되면 가용성이 떨어진다.

3.4.1 동기 통신으로 인한 가용성 저하

REST는 대중적인 IPC이지만 동기 프로토콜이라는 문제점이 있다.
- 요청이 정상 처리되려면 REST로 연결된 모든 서비스가 작동 중이어야 한다.
- REST 뿐 아니라 동기 응답 구조라면 가용성은 떨어질 수밖에 없다.

3.4.2 동기 상호 작용 제거

비동기 API만 사용할 순 있겠지만 퍼블릭 API는 대개 REST형이라 동기 API가 필요한 경우가 많다.

비동기 상호 작용 스타일

모든 트랜잭션은 비동기 상호 작용 스타일하는 것이 가장 좋다.
- ex) 주문 생성을 한다고 할 때 주문 서비스는 다른 서비스와 비동기 방식으로 메시지를 교환하고 최종적으로 클라이언트에 응답
클라이언트/서비스는 메시징 채널을 통해 서로 비동기 통신을 한다.
이러한 아키텍처는 메시지 소비 시점까지 브로커가 메시지를 버퍼링하기에 매우 탄력적이다.

데이터 복제

서비스 요청 처리에 필요한 데이터의 레플리카를 유지하는 방법
- 서비스에 동기 API가 있는 경우 데이터를 복제하면 가용성을 높일 수 있다.
데이터 레플리카는 데이터를 소유한 서비스가 발행하는 이벤트를 구독해서 최신 데이터를 유지할 수 있다.
데이터 레플리카를 가지게 되면 다른 서비스와 상호 작용할 필요가 없다.
- ex) 주문 서비스는 주문을 할 때 소비자 서비스와 음식점 서비스와 소통할 필요 없이 이벤트 스트림을 통해 전달 받은 소비자, 음식점 데이터를 자신의 DB에서 바로 조회할 수도 있을 것이다.
하지만 대용량 데이터 레플리카는 대단히 비효율적이다.

응답 반환 후 마무리

요청 처리 도중 동기 통신을 제거하려면 다음 방법을 사용할 수 있다.
1. 로컬에서 가용한 데이터만 갖고 요청을 검증
2. 메시지를 OUTBOX 테이블에 삽입하며 DB를 업데이트
3. 클라이언트에 응답을 반환
위 방법을 통해 서비스는 다른 서비스와 동기적 상호 작용을 하지 않는다.
- 대신 메시지를 비동기로 전송
ex) 주문 서비스 예시
1. 주문 서비스는 주문을 PENDING 상태로 생성
2. 주문 서비스는 주무 ID가 포함된 응답을 클라이언트에 반환
3. 주문 서비스는 ValidateConsumerInfo 메시지를 소비자 서비스에 전송
4. 주문 서비스는 ValidateOrderDetails 메시지를 음식점 서비스에 전송
5. 소비자 서비스는 주문 가능한 소비자인지 확인 후 주문 서비스에 응답
6. 음식점 서비스는 올바른 메뉴 항목이지, 배달이 가능한 배달지인지 확인 후 주문 서비스에 응답
7. 주문 서비스는 응답들을 받고 주문 상태를 변경
8. …
위 방법이라면 한 서비스가 다운되더라도 주문 서비스는 계속 주문을 생성할 수 있다.

TIL

3장 프로세스 간 통신

3.1 마이크로서비스 아키텍처 IPC 개요

3.1.1 상호 작용 스타일

3.1.2 마이크로서비스 API 정의

3.1.3 API 발전시키기

시멘틱 버저닝

하위 호환되는 소규모 변경

중대한 대규모 변경

3.1.4 메시지 포맷

텍스트 메시지 포맷

이진 메시지 포맷

3.2 동기 RPI 패턴 응용 통신

3.2.1 동기 RPI 패턴: REST

REST 성숙도 모델

REST 장단점

3.2.2 동기 RPI 패턴: gRPC

3.2.3 부분 실패 처리: 회로 차단기 패턴

견고한 RPI 프록시 설계

불능 서비스 복구

3.2.4 서비스 디스커버리

서비스 디스커버리 개요

애플리케이션 수준의 서비스 디스커버리 패턴 적용

플랫폼에 내장된 서비스 디스커버리 패턴 적용

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

3.3.1 메시징 개요

3.3.2 메시징 상호 작용 스타일 구현

3.3.3 메시징 기반 서비스의 API 명세 작성

3.3.4 메시지 브로커

브로커리스 메시징

브로커 기반 메시징 개요

메시지 브로커로 메시지 채널 구현

브로커 기반 메시징의 장단점

3.3.5 수신자 경합과 메시지 순서 유지

3.3.6 중복 메시지 처리

멱등한 메시지 핸들러 작성

메시지 추적과 중복 메시지 솎아 내기

3.3.7 트랜잭셔널 메시징

DB 테이블을 메시지 큐로 활용

이벤트 발행: 폴링 발행기 패턴

이벤트 발행: 트랜잭션 로그 테일링 패턴

3.3.8 메시징 라이브러리/프레임워크

3.4 비동기 메시징으로 가용성 개선

3.4.1 동기 통신으로 인한 가용성 저하

3.4.2 동기 상호 작용 제거

비동기 상호 작용 스타일

데이터 복제

응답 반환 후 마무리