3. Inter-Process Communication in a Microservices Architecture

Building Microservices: Inter-Process Communication in a Microservices Architecture

Inter-Process Communication in a Microservices Architecture에 대한 요약이다.

• Monolithic 어플리케이션에서는 언어레벨의 메소드나 함수를 호출 함으로써 다른 컴포넌트를 실행 할 수 있었다.
• MSA기반 어플리케이션은 분산환경에서 개별 프로세스로 동작하기 때문에, inter-process communication (IPC) mechanism이 필요하다.
  

Design시 고려사항

Interaction Styles

각 서비스들은 아래의 통신 스타일을 조합해서 사용하게 된다.

	One-to-One	One-to-Many
Synchronous	Request/response	—
Asynchronous	Notification	Publish/subscribe
	Request/async response	Publish/async responses

• Synchronous : 요청에대한 적절한 응답을 기대하고, 그때까지 기다리며 block.
• Asynchronous: 응답을 기다리며 block하지 않음.
• One-to-one: 각 요청이 한 서비스에서 실행됨
  • Request/response : 서비스에 요청을 하고, 응답을 기다린다.
    적당한 시간 내에 응답이 올것을 기대하며, block 된 상태로 기다린다.
  • Notification(one-way request): 서비스에 요청을 보내고, 응답을 받지 않는다.
  • Request/async response: 서비스에 요청을 보내고, 비동기로 응답을 받는다.
• One-to-many: 각 요청이 여러 서비스에서 실행됨
  • Publish/subscribe: 메시지를 발행(publish)하면, 관심있는 서비스들이 이를 소비(consume)한다.
  • Publish/async responses: 메시지를 publish하고, 이를 소비하는 서비스로 부터 응답을 기다린다.

Defining APIs

API는 서비스와 이를 사용하는 클라이언트 간의 일종의 계약(contract)이다.
그렇기 때문에 API를 상세하게 정의하는 것이 중요하다. (참고 : API-first Approach)
어떤 IPC 메카니즘을 사용하느냐에 따라 API를 정의하는 것이 달라질 것이다.

• messaging : message channels, message types
• HTTP : URLs, request/response formats

Evolving APIs

서비스의 API는 시간이 지남에 따라 변경된다.
모놀리틱 어플리케이션에서는 API를 변경하고, 이를 호출하는 부분을 수정하면 간단히 해결된다.
하지만, MSA기반 어플리케이션에서는 매우 어렵기 때문에 전략적인 접근이 필요하다.
어떻게 API 변경에 대처할 지는, 변경의 크기에 따라 다르다.

속성이 추가되는 것과 같이 변경이 작고 사소한 것이라면,
기본값을 주거나 새로운 속성을 무시하게 함로써 쉽게 변경 할 수 있다.

major하고 큰 변경이라면, 클라이언트에게 즉시 변경하도록 강요 할 수 없기 때문에
서비스는 일정기간동안 두 버전의 API를 지원해야 한다.

• 참조 : Deploying the Netflix API

Handling Partial Failure

분산 시스템에서는 partial failure 위험이 항상 존재한다.
장애가 났거나, 유지보수상 이유로, 혹은 시스템 부하로 인해 응답속도가 너무 느린경우 발생 할 수 있다.
응답을 무한정 기다리며 block상태에 있다면, 사용자에게 안좋은 UX를 제공할 뿐만 아니라,
block상태인 thread가 늘어나면서 결국 해당 서비스도 장애가 발생 할 수 있다.

• Network timeouts
• Limiting the number of outstanding requests
• Circuit breaker pattern
• Provide fallbacks: cached data, default value
• 참조 :
  Fault Tolerance in a High Volume, Distributed System
  Netflix Hystrix

IPC Technologies

Asynchronous, Message-Based Communication

• 메시지(Message) 기반 통신은 메시지를 비동기 로 주고 받는 것이다.
  
• 만약 응답을 받기 원한다면 별도의 메시지를 보내야 한다.
• 비동기로 통신하기 때문에 응답을 받기위해 block상태로 기다리지 않는다.
• 메시지는 헤더(header) 와 바디(message body) 로 구성된다.
• 메시지는 채널(Channel) 을 통해 주고받는다.
  • point‑to‑point 채널: 한 consumer에게 메시지를 전달. 1:1로 직접 통신시 사용
  • publish‑subscribe 채널: 여러 consumer에게 메시지를 전달. 1:N 통신시 사용
• 표준 프로토콜: AMQP, STOMP
• 오픈소스: RabbitMQ, Apache Kafka, Apache ActiveMQ, NSQ

메지징 사용의 장점

• 서비스와 클라이언트간 의존성을 줄임. 서비스의 위치를 몰라도 됨.
• 메시지 버퍼링. consumer에의해 메시지가 소비될때까지 큐에 보관함.
• 1:1, 1:N 등 모든 통신 스타일을 지원함

메지징 사용의 단점

• 운영복잡도 증가: 메시징 시스템도 설치하고, 설정하고, 운영해야되는 시스템이다.
• request/response기반 통신 구현시 복잡함. 응답을 받기위해 추가작업 필요.(correlation ID)

Synchronous, Request/Response IPC

• Request/Response 기반 통신은 클라이언트에서 서비스로 요청을 동기 로 보내는 것이다.
• 응답을 받기위해 클라이언트의 thread는 block상태로 기다린다.
• client code에 Futures, Rx.. 를 사용하여 asynchronous, event-driven하게 처리할 수도 있다.

REST

• RESTful스타일의 API 개발 방법
• HTTP를 사용하는 IPC 메카니즘
• 비지니스 객체(object)같은 자원(resources)을 표현(represent)하는 것이 주요 컨셉이다.
• GET, POST, PUT, DELETE..같은 HTTP 용어와 URL을 사용하여 자원을 조작한다.
• HTTP-based API가 RESTful 한 것은 아니다. (참고: REST 성숙도 모델)
• RAML이나 Swagger를 사용하여 RESTful API를 디자인 할 수 있다.
• 장점 :
  • HTTP 는 단순하고 친숙하다.
  • HTTP API는 browser나 curl을 사용하여 테스트하기 쉽다.
  • request/response 스타일 통신을 지원한다.
  • HTTP는 방화벽에 친화적이다.
  • 메시지 브로커 같은 중간 매개체가 필요없어 시스템 아키텍쳐가 단순하다.
• 단점 :
  • request/response 스타일 통신만 지원한다.
    notification(one-way)을 HTTP로 구현하더라도 응답을 받아야한다.
  • 클라이언트와 서비스가 직접 통신하기 때문에 반드시 둘 다 동작 중이어야 한다.
  • 클라이언트는 서비스들의 위치를 알고있어야 한다.

Thrift

• 다른 언어로 개발된 서비스들간 RPC통신을 위한 프레임워크
• 클라이언트의 stub코드와 서비스의 skeleton코드를 생성(generate)해준다.
• request/response 스타일 통신과 one-way 스타일의 통신 모두 가능하다.
• C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml, Delphi…
• JSON, binary, compact binary 등의 메시지 포멧을 지원.
• TCP, HTTP 프로토콜 지원.

Message Formats

서비스들이 여러 언어로 개발되어 있는 경우, 통신시 사용할 메시지 포멧을 결정하는 것이 중요하다.

텍스트 기반 포멧(text-based format)

• JSON: 키(name)와 값(value)의 쌍으로 속성을 표현. XML Schema
• XML: 요소(element)와 값(value)으로 속성을 표현. JSON Schema
• 장점 :
  • 사람이 이해하기 쉽고, 그 자체로 설명가능(self-describing) 하다.
  • 관심있는 값만 보고 나머지는 무시한다. 속성 변경에 대처하기 쉽다.
• 단점 :
  • 메시지가 너무 크고 정보가 많다. 특히 XML..
  • 텍스트 파싱(parsing)에 대한 오버해드가 있다.

바이너리 포멧(binary format)

• Thrift RPC
• Apache Avro: schema
• Protocol Buffers: tagged fields
• 참고: Thrift vs Protocol Buffers vs Avro - Biased Comparison

결론

Microservices는 IPC 메카니즘을 사용하여 통신해야 한다.
설계시 고려할 사항으로는 서비스간 어떻게 통신할지, API를 어떻게 정의할지,
API 변경에 어떻게 대응할지, 부분장애(partial failure)에 어떻게 대응할지등이 있다.
IPC 메카니즘으로는 메시지기반의 비동기 방식과 request/response기반의 동기 방식이 있다.