프로세스 간 통신(Inter-process communication, IPC)
서비스와 서비스가 통신하기 위해서는 인터페이스가(interface)가 존재해야 하고 인터페이스가 요구하는 방식대로 커뮤니케이션해야 한다.
마이크로서비스를 설계한다는 것은 나뉘어진 프로세스간의 통신을 통해 하나의 서비스로서 동작하는 것을 설계하는 것이다.
따라서 마이크로서비스를 설계할때에는 내가 구축하고자 하는 서비스의 필요에 따라
- 프로세스 간의 통신을 동기적 또는 비동기적으로 설계해야 한다.
- 통신의 관계를 설계한다.(1:1 인가 1:N 인가)
- 프로세스간의 연결을 직접 혹은 간접적으로 연결할지 정한다.
동기(Synchronous)와 비동기(Asynchronous)
동기(Synchronous)의 핵심 : 요청을 하면 시간이 얼마나 걸리던지 요청한 자리에서 결과가 주어져야 한다.
비동기(Asynchronous)의 핵심 : 요청한 결과는 동시에 일어나지 않을거라는 약속으로 요청한 결과가 수행되어지지 않더라도 응답을 할 수 있다.
| 동기 | 비동기 |
|---|---|
| 요청/응답 | 비동기 요청/응답, 단방향 알림(푸쉬 알림 등) |
이에 대한 예로서 통신의 관점에서의 HTTP는 동기라고 할 수 있다.
클라이언트는 서버가 제 때 응답을 줄 것으로 기대하고 요청을 하기 때문이다.
데이터를 교환하는 대표적인 포맷 JSON
메시지라는 객체를 전송 가능하려면 아래의 조건을 충족해야 한다.
- 수신자(reciever)와 발신자(sender)가 같은 프로그램을 사용한다.
- 또는, 문자열처럼 범용적으로 읽을 수 있어야 한다.
이러한 요소를 충분히 충족한 덕에 JSON이 서로 다른 프로그램 사이에서 데이터를 교환하는 대표적인 포맷이 되었다.
직렬화(serialize)와 역직렬화(deserialize)를 통해 데이터를 객체화 하기도 객체를 데이터화하기도 할 수 있다.
JSON.stringify : Object type을 JSON으로 변환합니다. (직렬화)
JSON.parse : JSON을 Object type으로 변환합니다. (역직렬화)
JSON의 기본 규칙
| - | 자바스크립트 객체 | JSON |
|---|---|---|
| 키 | 키는 따옴표 없이 쓸 수 있음 | 반드시 큰따옴표를 붙여야 함 |
| 문자열 값 | 문자열 값은 어떠한 형태의 따옴표도 사용 가능 | 반드시 큰따옴표로 감싸야 함 |
| 키와 값 사이 그리고 키-값 쌍 사이에는 공백이 있어서는 안된다. |
동기식 요청/응답의 통신 설계
동기식 요청 응답의 통신는 REST API를 대표적으로 사용합니다.
위에 설명한 JSON의 형태로 HTTP 메시지의 body를 다루는 것이 보통이고 MIME 타입을 application/json으로 설정합니다.
■ REST의 장점
- 포스트맨, curl 등의 도구를 사용해 간편하게 테스트가 가능합니다.
- 요청/응답 통신을 직접 지원합니다.
- 시스템 아키텍처가 단순합니다.
■ REST의 단점
- 요청/응답만 지원합니다.
- 메시지를 주고받기 위해서는 클라이언트와 서버 프로세스가 둘 다 실행 중이어야만 합니다.
- 요청 한 번으로 여러 리소스를 조회하기 어렵습니다.
- 메소드만으로는 한번의 요청을 통해 이루어지는 다양한 작업들을 대표하기 어렵습니다.
비동기식 통신 설계
동기식 통신을 설계할때에는 REST를 주로 사용했다면 비동기식 통신을 설계할때 자주 등장하게 되는 "메시지 브로커"에 주목할 필요가 있습니다.
메시지 브로커의 필요 이유?
장애 대응에서 가지는 장점
메시지 브로커가 중간에 위치한 다면 시스템 장애가 발생해도 복구 기간 동안 메시지 브로커가 메시지를 보관해 놓기 때문에 데이터가 유실되지 않는다.
■ 메시지 브로커의 특징
- 메시지를 보내는 사람이 생산자(producer), 메시지를 받는 사람이 소비자(consumer)
- 메시지를 보내는 것을 발행(publish), 메시지를 받는 것을 소비(consume)
▶ 프로그램 간의 직접 연결 없음: less dependency, fault tolerant
- 소비자 프로세스가 죽어있어도 생산자는 메시지를 보낼 수 있음
- 생산자 프로세스가 죽어있어도 소비자는 메시지를 수신할 수 있음
▶ 메시지 브로커에 있는 메시지는 소비자(수신자)가 꺼낼 때까지 안전하게 보관됨: durability
- (프로세스가 죽어 있어도) 메시지는 소비하기 전까지는 사라지지 않음
- 따라서, 프로그램 간 통신은 시간과 독립적임
▶ 통신이 이벤트에 의해 구동될 수 있음
- 큐의 상태에 따라 프로그램을 제어할 수 있습니다. 예를 들어 메시지가 큐에 도착하는 즉시 프로그램이 시작되도록
설정할 수 있습니다. 또는 예를 들어 큐에서 특정 우선 순위 이상의 메시지가 10개가 되거나
임의의 우선 순위의 메시지가 10개가 될 때까지 프로그램이 시작되지 않도록 지정할 수 있습니다.
▶ 확장에 용이함
- 메시지 브로커는 여러 큐를 만들거나, 수평적으로 확장하여 메시지 부하 증가를 처리할 수 있습니다.
■ 메시지 브로커의 단점
▶ 프로세스 간의 직접 연결에 비해 아키텍처가 복잡합니다.
■ 메시지 브로커 선택의 기준
- 프로그래밍 언어 지원 여부
- 메시징 표준 지원 여부
- 메시지 순서 보장 여부
- 전달 보장 여부: 어떤 종류의 전달을 보장하는가?
- 영속성: 브로커가 고장나도 문제가 없도록 메시지가 디스크에 저장되는가?
- 내구성: 소비자가 메시지 브로커에 다시 접속할 경우,
- 접속이 중단된 시간에 전달된 메시지를 받을 수 있는가?
