[마이크로서비스] 03. API 디자인과 프로세스 간 통신

# 학습 내용

1.  API 디자인과 프로세스 간 통신

- 마이크로서비스는 하나의 프로세스 단위로 실행되므로 IPC간의 통신이라고 볼 수 있음

 

프로세스 간의 통신

- 서비스와 서비스간 통신을 위해서는 interface가 존재해야 하고, 인터페이스가 요구하는 방식대로 커뮤니케이션해야 함

(ex) 클라이언트/서버 아키텍처의 HTTP 프로토콜, HTTP 위에서 작동하는 메서드와 엔드포인트로 구성된 REST Application Programming Interface를 이용해 통신

 

동기/비동기

동기적 통신의 예

- HTTP 프로토콜의 경우 기본적으로 TCP(or UDP) 연결 생성 후 그 위에서 요청에 딷라 즉시 응답이 오는 형식으로 구현

서비스	작업
동기	요청/응답
비동기	비동기 요청/응답 단방향 알림(ex. 푸시 알림)

 

일대일 및 일대다 통신

- HTTP 프로토콜의 경우 요청/응답으로 이뤄진 한 번의 트랜잭션(transaction)에서 서버는 여러 클라이언트에게 동시에 응답을 전달하지 않음

- 서버가 여러 클라이언트를 상대할 수는 있으나 이는 여러 번의 1:1 커뮤니케이션이지, 동시에 여러 클라이언트를 상대하는 1대다 커뮤니케이션이 아니므로 일대일 통신

 

프로세스 간의 직접/간접 연결

- 클라이언트/서버 아키텍처의 경우 두 프로세스 간의 직접 연결을 구현

- but 중간에 메시지 브로커가 두 프로세스 사이에 위치해서 오고 가는 메시지 자체를 관리하는 형태의 연결 방식도 존재함

- 이 경우 비동기적인 처리는 물론이고, 설사 둘 중 하나의 프로세스가 실행 중이 아니더라도 서로 메시지를 주고받는 것 가능

 

2. 대표적인 데이터 교환 포맷 JSON

JSON

JSON의 탄생 배경

- JSON은 JavaScript Object Notation의 줄임말로, 데이터 교환을 위해 만들어진 객체 형태의 포맷

 

전송 가능한 조건

• 수신자(reciever)와 발신자(sender)가 같은 프로그램을 사용
• 문자열처럼 범용적으로 읽을 수 있어야 함

 

직렬화 : 객체를 JSON의 형태로 변환

- JSON.stringify : Object type을 JSON으로 변환

let transferableMessage = JSON.stringify(message)
console.log(transferableMessage)  // `{"sender":"시루","receiver":"의미","message":"안녕!","createdAt":"2021-01-12 10:10:10"}`
console.log(typeof(transferableMessage)) // `string`

 

역직렬화 :  JSON을 객체 형태로 변환하는 메서드

- JSON.parse : JSON을 Object type으로 변환

let packet = `{"sender":"시루","receiver":"의미","message":"안녕!","createdAt":"2021-01-12 10:10:10"}`
let obj = JSON.parse(packet)
console.log(obj)
/*
 * {
 * sender: "시루",
 * receiver: "의미",
 * message: "안녕!",
 * createdAt: "2021-01-12 10:10:10"
 * }
 */
 console.log(typeof(obj))
 // `object`

 

JSON의 기본 규칙

- JSON은 자바스크립트의 객체와는 미묘하게 다른 규칙 존재

-  JSON은 키와 값 사이, 그리고 키-값 쌍 사이에는 공백이 있어서는 안 됨

	자바스크립트 객체	JSON
키	키는 따옴표 없이 슬 수 있음	반드시 큰 따옴표를 붙여야 함
문자열 값	문자열 값은 어떠한 형태의 따옴표도 사용 가능	반드시 큰 따옴표로 감싸야 함

 

3. 동기식 요청/응답 통신 REST
REST

- REST는 HTTP로 소통하는 프로세스 간 통신 규약

- REST API는 웹에서 사용되는 데이터나 자원을 HTTP URI로 표현하고, HTTP 프로톸톨을 통해 요청/응답을 정의하는 방식

- 현대에는 보통 HTTP 메시지 body 부분을 JSON 형태로 다루며, 이 때 HTTP 헤더의 Content-Type의 값(MIME 타입)은 application/json으로 설정 

REST의 장점	REST의 단점
포스트맨, curl 등의 도구를 사용해 간편하게 테스트 가능 요청/응답 통신을 직접 지원 시스템 아키텍처가 단순	요청/응답만 지원 메시지를 주고받기 위해서는 클라이언트와 서버 프로세스가 둘 다 실행 중이어야만 함 요청 한 번으로 여러 리소스를 조회하기 어려움 메서드만으로는 한 번의 요청을 통해 이루어지는 다양한 작업들을 대표하기 어려움

 

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

Review: 프로세스 간 통신

동기적 방법

- 요청을 보내는 즉시 수신자로부터 응답이 오길 기대

- 클라이언트-서버 아키텍처의 REST(HTTP)가 대표적

비동기적 방법

- 요청을 일단 보내놓고 수신자가 받을 때까지 보관했다가 처리

- 수신자가 받기 전에 누군가 메시지 보관할 필요 존재, 메시지 브로커(메시지 큐)

 

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

- 분산 애플리케이션에서 프로세스 간의 느슨한 결합(약결합, loosely coupled)을 제공하는 것이 가장 큰 장점

- 강결합의 단점? 서로 연결된 시스템 중 한 곳에 장애가 발생하면 그 장애가 연결된 다른 시스템들에게도 영향이 감

 

주요 용어

• 생산자: 메시지 송신자
• 소비자: 메시지 수신자
• 발행: 메시지 송신
• 소비: 메시지 수신

 

메시지 브로커의 특징

1. 프로그램 간의 직접 연결이 없음 : Less Dependency, Fault Tolerant

- 소비자 프로세스가 죽어도 생산자는 메시지 송신 가능

- 생산자 프로세스가 죽어도 소비자는 메시지 수신 가능

2. 메시지 브로커에 있는 메시지는 소비자(수신자)가 꺼낼 때까지 안전하게 보관됨 : Durability

- 프로세스가 죽어도 메시지는 소비하기 전까지 사라지지 않음

- 즉, 프로그램 간 통신은 시간과 독립적

3. 통신이 이벤트에 의해 구동 가능

- 큐 상태에 따라 프로그램 제어 가능 

(ex) 메시지가 큐에 도착하는 즉시 프로그램이 시작되도록 설정 가능 

(ex) 큐에서 특정 우선 순위 이상의 메시지가 10개가 되거나 임의의 우선 순위 메시지가 10개가 될 때까지 프로그램이 시작되지 않도록 지정 가능

4. 확장에 용이함

- 메시지 브로커는 여러 큐를 만들거나 수평적으로 확장해 메시지 부하 증가 처리 가능

 

메시지 브로커의 단점

- 프로세스 간 직접 연결에 비해 아키텍처가 복잡

 

메시지 브로커 선택의 기준

메시지 브로커 종류

1. Apache Kafka
   • 실시간 데이터 파이프라인 및 스트리밍 애플리케이션 구축에 사용되는 오픈소스 메시지 브로커 프로젝트
   • 실시간으로 대량의 데이터 피드를 관리하도록 설계
   • 짧은 대기시간, 높은 처리량 및 내결함성 메시징 제공
   • 여러 생산자와 여러 소비자가 구독할 수 있는 주제에 데이터 게시할 수 있도록 하는 pub/sub 메시징 모델 지원
   • 복제, 내결함성, 확장성 기능 제공
2. Amazon SQS
   
   • 아마존 심플 Queue 서비스
   • 메시지를 pull형으로 처리
   • 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분리, 확장할 수 있는 완전 관리형 메시지 대기열 서비스
   • 각 구성 요소를 동시에 사용할 필요 없이 분산 응용 프로그램 구성 요소 간 메시지 교환 가능
   • SQS는 짧은 시간동안 메시지를 버퍼링하는 기능과 함께 안정적이고 확장 가능한 메시지 대기열 제공
   • FIFO 대기열: 선입선출로 처리되도록 제공, TPS 제한이 있는 대신 메시지 전달이 ecactly once로 보장되며 메시지 순서 보장
   • standard 대기열: 최선의 순서 제공, scale out이 무한대로 가능하나 exactly once 방식 메시지 전달이 아닌 at least once 방식이며 메시지 순서 보장되지 않음
3. Amazon Kinesis
   
   • kafka의 AWS 버전
   • 스트리밍 데이터를 대규모로 수집, 처리, 분석할 수 있는 완전 관리형 실시간 데이터 스트리밍 서비스
   • 대량 데이터를 처리하도록 설계
   • pub/sub 모델 특징으로 데이터의 consume 여부와 관계 없이 지정한 retention tme만큼 데이터 저장
   • 동시에 여러 consumer가 메시지를 소비 가능
   • 컨슈머 측에서 offset 관리를 해야함 (어떤 데이터까지 소비했으며 다음에 어떤 데이터를 소비해야하는 지 등)

메시지 브로커 선택 기준

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

 

메시지 브로커의 두 가지 방식

Queue 방식

- 로드밸런서 방식

- 하나의 메시지가 하나의 소비자에게 전송됨

- 만약 그 시점에 메시지를 수신할 수 있는 소비자가 없다면 그 소비자가 메시지를 소비할 수 있을 때까지 보관됨

- 만약 소비자가 메시지를 수신하고 연결을 종료하기 전까지 인지하지 않을 경우 메시지는 다른 소비자에게 전달됨

- 큐에는 가용 상태의 소비자 간 메시지간 로드밸러서된 많은 소비자가 존재 가능

- 메시지 큐에 있는 메시지를 한번 소비하면 queu에서 삭제되며 point-to-point 방식이라고도 불림

Topic 방식

- publish / subscribe로 이루어짐

- 메시지를 publish하면 관계있는 모든 subscribers에게 메시지가 전송

- 0명 이상의 subscribers가 메시지의 복사본을 수신하게 됨

- 브로커가 메시지를 받은 당시 구독이 활성화되어있는 구독자만이 메시지 복사본을 수신할 수 있음

- 생산자가 메시지를 publish한 이후 그 데이터를 누가 얼마나 사용하는지 상관 없으며 많은 consumer가 동시에 해당 데이터 소비 가능

 

웹 서비스에서 메시지 브로커(메시지 큐)를 이용해 비동기적인 방법이 활용되는 사례

웹소켓

이메일 발송

- 웹 서비스에서 이메일을 발송하는 경우, 메시지 브로커를 이용해 비동기적으로 이메일을 발송 가능

- 이메일 발송 요청을 메시지 큐에 넣고, 이메일 발송 서비스가 메시지 큐에서 요청을 가져와 이메일을 발송하는 방식으로 구현

알림 기능

- 웹 서비스에서 알림 기능을 구현할 때 메시지 브로커를 이용해 비동기적으로 처리 가능

- (ex) 푸시 알림을 보내는 경우, 알림을 보내는 요청을 메시지 큐에 넣고, 알림을 보내는 서비스가 메시지 큐에서 요청을 가져와 알림을 보내는 방식으로 구현 

주문 처리

- 웹 서비스에서 주문 처리를 비동기적으로 처리 가능

- 주문 처리 요청을 메시지 큐에 넣고, 주문 처리 서비스가 메시지 큐에서 요청을 가져와 주문을 처리하는 방식으로 구현

데이터 처리

- 웹 서비스에서 대용량 데이터 처리를 비동기적으로 처리 가능

- 데이터 처리 요청을 메시지 큐에 넣고, 데이터 처리 서비스가 메시지 큐에서 요청을 가져와 데이터 처리를 수행하는 방식으로 구현 

배치 처리

- 웹 서비스에서 정기적인 배치 처리를 비동기적으로 처리 가능

- 배치 처리 요청을 메시지 큐에 넣고, 배치 처리 서비스가 메시지 큐에서 요청을 가져와 배치 처리를 수행하는 방식으로 구현

 

# References

챗 gpt

https://ko.wikipedia.org/wiki/%EB%A9%94%EC%8B%9C%EC%A7%80_%EB%B8%8C%EB%A1%9C%EC%BB%A4

메시지 브로커 - 위키백과, 우리 모두의 백과사전

 

https://www.ibm.com/kr-ko/topics/message-brokers

메시지 브로커란? | IBM

 

https://stackoverflow.com/questions/37853810/difference-between-topic-queue-for-simplemessagebroker-in-spring-websocket

Difference between /topic, /queue for SimpleMessageBroker in Spring Websocket + SockJS

https://activemq.apache.org/how-does-a-queue-compare-to-a-topic

ActiveMQ

https://docs.oracle.com/cd/E19435-01/819-2222/concepts.html

https://docs.oracle.com/cd/E19435-01/819-2222/concepts.html

https://tigercoin.tistory.com/242

Kafka vs Kinesis vs SQS, Uber의 메시지 브로커 활용사례

https://jaemunbro.medium.com/aws-%EB%A9%94%EC%8B%9C%EC%A7%95%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%B9%84%EA%B5%90-kinesis-sqs-sns-ab397a07cb1d

[AWS] 메시징서비스 비교 : Kinesis, SQS, SNS