[Microservices Pattern] Inter-Processing Communication

개요

IPC 기술의 폭은 매우 넓다. HTTP기반 REST나 gRPC 등 요청/응답 방식의 동기적 통신 매커니즘이 있고, AMQP, STOMP와 같이 비동기 메시지 기반의 통신 메커니즘도 있다. 메시지 포맷 역시 JSON, XML처럼 가독성 높은 텍스트 포맷부터 Avro, Protocol Buffer처럼 효율이 우수한 이진 포맷이 있다.

IPC를 어떻게 선택하느냐에 대한 고민을 거듭할수록 전체 어플리케이션 가용성에 영향이 가고, 적절한 통합 테스트 환경을 수립하는데에도 도움이 된다.

상호 작용 스타일

일대일, 일대다 여부
- 일대일: 각 클라이언트 요청은 정확히 한 서비스가 처리
- 일대다: 각 클라이언트 요청을 여러 서비스가 협동하여 처리
동기, 비동기 여부
- 동기: 클라이언트는 서비스가 제시간에 응답하리라 기대하고 대기 도중 블로킹 할 수 있다.
- 비동기: 클라이언트가 블로킹하지 않고 응답은 즉시 전송될 필요가 없다

마이크로서비스 API 정의 및 발전시키기

어떤 IPC를 선택하든 서비스 API를 IDL로 정의하는 것은 중요하다. 서비스 API는 클라이언트 간의 약속이다. 클라이언트가 호출 가능한 작업과 서비스가 발행하는 잊벤트로 구성되고 이름, 매개변수, 반환형등이 약속된다. 메시지 채널에 발행되는 이벤트는 타입과 필드가 약속된다.

API는 대게 견고성 원칙을 따른다. "당신이 하는 일은 보수적으로, 다른 사람들이 하는 일은 관대하게 바라보라". 요청 속성이 누락되어도 서비스는 기본값을 제공하고, 응답 속성이 많아도 클라이언트는 필요한 것만 취하고 버려야해야한다.

API는 새로운 기능을 추가하거나 기존 기능을 삭제/변경 하면서 계속 진화한다. 모놀리식 어플리케이션 같은경우는 사용 클라이언트가 많지 않기 때문에 API를 변경하는 일이 그다지 어렵지 않다. 하지만 마이크로서비스 어플리케이션은 클라이언트를 다른 서비스팀이 개발한 경우가 대부분이기 때문에 API를 변경하기 무척 어렵다. 따라서 마이크로서비스 어플리케이션에서는 어떻게 API를 변경할건지에 대한 전략을 잘 세워야한다.

시멘틱 버저닝 명세(semvers)은 원래 소프트웨어 패키지 버저닝에 주로 쓰였지만, 분산 시스템의 API 버저닝에도 사용할 수 있다. 이 명세에 따르면 버전 번호를 MAJOR.MINOR.PATCH 세 개로 구분한다.

MAJOR: 하위 호환되지 않는 변경분을 API에 적용 시
MINOR: 하위 호환되는 변경분을 API에 적용 시
PATCH: 하위 호환되는 오류 수정 시

이러한 버저닝 정보를 REST API라면 URL경로 첫번째 엘리먼트로(GET /api/v3.2.1/user/1), 메시징 기반 서비스라면 발행한 메시지에 버전 번호를 넣을 수 있다. HTTP 컨텐트 협상을 이용해 MIME type 내부에 버전 번호를 끼워 넣는 방법도 있다.

GET /users/123 HTTP/1.1
Accept: application/json; version=1;