메리와 FTGO 팀원들은 여느 개발자처럼 IPC를 경험한 바 있습니다. FTGO 애플리케이션은 모바일 앱과 웹 브라우저 자바스크립트가 호출하는 REST API를 제공하며, 트윌리오 메시징 서비스, 스트라이프 지불 서비스 등 클라우드 서비스도 함께 운용 중입니다. 그러나 모놀리식 애플리케이션은 대부분의 모듈이 언어 수준의 메서드나 함수를 통해 서로 호출하기 때문에 REST API나 클라우드 서비스 연계 모듈을 작성하지 않는 이상 IPC는 크게 신경 쓸 필요가 없었습니다.

이와 달리 마이크로서비스 아키텍처는 애플리케이션을 여러 개의 서비스로 구성하며(2장), 서비스는 대부분 요청을 처리하기 위해 서로 협동합니다. 서비스 인스턴스는 여러 머신에서 실행되는 프로세스 형태이므로 반드시 IPC를 통해 상호 작용해야 합니다. 따라서 IPC는 모놀리식 아키텍처보다 마이크로서비스 아키텍처에서 차지하는 비중이 더 큽니다. FTGO 개발 팀은 마이크로서비스 애플리케이션으로 전환하면서 IPC에 많은 시간을 쏟게 될 것입니다.

IPC 기술은 옵션이 다양합니다. 요즘은 (JSON을 주고받는) REST가 대세이지만, 모든 경우를 만족하는 만병통치약은 없으므로 여러 가지 옵션을 잘 검토해야 합니다. 이 장에서는 REST, 메시징 등 다양한 IPC 옵션과 그 트레이드오프를 설명합니다.

IPC는 애플리케이션 가용성에 영향을 미치는 아주 중요한 아키텍처 의사 결정 항목이고 트랜잭션 관리와도 맞물려 있습니다(3~4장). 필자는 비동기 메시징으로 서로 통신하는 느슨하게 결합된 서비스로 구성된 아키텍처를 선호합니다. REST 같은 동기 프로토콜은 대부분 다른 애플리케이션과 통신할 때 사용하죠.

이 장은 먼저 마이크로서비스 아키텍처의 프로세스 간 통신을 개괄합니다. 먼저 REST가 가장 널리 사용되는 원격 프로시저 호출 방식의 IPC를 설명하고, 서비스 디스커버리 및 부분 실패(partial failure) 처리 등의 중요한 토픽을 다룹니다. 그런 다음 비동기 메시징 IPC로 화제를 돌려 메시지 순서가 유지된 상태로 소비자를 확장하고, 중복 메시지를 정확히 걸러내고, 메시징에 트랜잭션을 거는 방법을 설명합니다. 끝으로 타 서비스와 통신하지 않고 비동기 요청을 처리하는 자기 완비형 서비스로 가용성을 높이는 방안까지 소개합니다.