동기식 요청/응답 통신 REST, 메시지 브로커를 통한 비동기 통신

REST(Representational State Transfer)

REST는 HTTP로 소통하는 프로세스 간 통신 규약이다. REST API는 웹에서 사용되는 데이터나 자원을 HTTP URI로 표현하고 HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다.

현대 HTTP 메시지의 body는 JSON 형태로 다루는 것이 기본이다. (이 때 HTTP 헤더의 Content-Type 값은 application/json으로 설정)

REST의 장점

• curl 등의 도구로 간편하게 테스트 가능
• 요청/응답 통신 지원
• 시스템 아키텍처가 단순

REST의 단점

• 요청/응답만 지원
• 메시지를 주고받기 위해서 클라이언트와 서버가 실행되어야 함
• 요청 한번에 여러 리소스 조회는 어려움
• 메소로만으론 한번의 요청에 다양한 작업들을 하기 어려움

---

메시지 브로커를 이용한 비동기식 통신

프로세스 간 통신은 요청을 보내는 즉시 응답이 오길 기대하는 '동기식'이 있고, 요청을 보내놓고 수신자가 받을 때까지 보관했다가 처리하는 '비동기식'이 있다.

동기식은 REST(HTTP)가 대표적이며 비동기식은 메시지 브로커(메시지 큐)가 있다.

메시지 브로커가 필요한 이유

분산 어플리케이션은 프로세스 간 느슨한 결합을 제공하는 것이 큰 장점이다. 강하게 결합된 시스템은 시스템 하나의 장애가 다른 시스템에 영향을 주기 때문에 단점이 크다.

그러나 시스템 중간에 메시지 브로커가 있다면 한 시스템의 장애를 다른 시스템에 주는 영향을 줄일 수 있다. 즉 Server 2에 일시적인 장애가 발생해도 복구 기간동안 메시지 브로커가 메시지를 보관하기 떄문에 데이터는 유실되지 않는다.

* 생산자(Producer) : 메시지를 보내는 사람
* 소비자(Consumer) : 메시지를 받는 사람
* 발행(Publish) : 메시지를 보내는 것
* 소비(Consume) : 메시지를 받는 것

메시지 브로커의 특징

• 프로세스간 직접 연결이 없다. 소비자 혹은 생산자 프로세스가 죽어있어도 메시지를 보내거나 받는 것이 가능해진다.
• 메시지 브로커에 있는 메시지는 소비자(수신)가 꺼낼 때까지 안전하게 보관된다
• 통신이 이벤트에 의해서 구동된다.
• 확장에 용이하다.

메시지 브로커의 단점으로는 프로세스 간의 직접 연결에 비해 아키텍처가 조금 복잡하다는 것.

메시지 브로커 선택 기준

대표적으로 Apache Kafka, Amazon Kinesis, Amazon SQS 등이 있다. 선택 기준은 다음과 같다.

• 프로그래밍 언어 지원 여부
• 메시징 표준 지원 여부
• 메시지 순서 보장 여부
• 전달 보장 여부(어떤 종류의 전달을 보장하나?)
• 영속성(브로커에 문제가 발생해도 메시지가 디스크에 저장되나?)
• 내구성(소비자가 메시지 브로커에 다시 접속할 경우, 접속이 중단된 시간에 전달된 메시지를 받을 수 있나?)
• 확장성
• 지연시간