Study_note
[ETC/Tech] 양방향 통신 및 메세징 이해 (websocket, message broker) 본문
양방향 통신 방법
http vs websocket
http : Client의 요청이 있을 때만 서버가 응답하고 연결을 종료하는 단방향 통신
따라서 클라이언트가 서버에 접속해 콘텐츠를 요청하고 결과를 받아 소비하는 구조의 서비스에서 많이 사용된다.
하지만 HTTP을 통해 양방향 통신 하는 방법도 있는데 아래와 같다
Http Polling : 클라이언트가 지속적으로 서버로 request를 하여 이벤트를 수신하는 방식이다. 가장 간단한 방법이지만, 지속적으로 서버에 요청을 던지기 때문에 서버의 오버헤드를 고려할 수 밖에 없는 상황이다.
Http Long Polling: polling에 비해 클라이언트는 이벤트를 받기 전까지 다음 요청을 날리지 않는다. 하지만, 원하는 이벤트를 얻기 위해 지속적으로 요청해야한다는 점에서 서버의 부담은 여전히 증가된다.
Http Streaming: 서버는 클라이언트로부터 request를 받으면, response을 주고 연결을 끊지 않고. 이벤트가 발생함에 따라 클라이언트로 전송하는 방식인데 역시나 근본적인 원인인 해결하지 못한다.
쉽게 말하면, 내가 원하는 데이터에 비해 동반되는 데이터들이 너무 많고, 지속적으로 이 데이터를 포함해야 하며 맺고 끊는 연결을 계속하는 등 리소스의 낭비가 크다는 점이다.
이런 문제점으로 만들어진게 websocket 이다.
websocket : Server와 Client가 지속적으로 연결을 유지하고 양방향으로 통신
주로 채팅 같은 실시간성을 요구하는 서비스에서 많이 사용된다.
Websocket은 기존의 단방향 HTTP 프로토콜과 호환되어 양방향 통신을 제공하기 위해 개발된 프로토콜로
단일 tcp 연결을 통해 클라이언트와 서버 간의 전이중 양방향 통신을 제공하는 프로토콜이다.
HTTP와 다른 프로토콜이지만, 80(HTTP), 443(HTTPS) 포트를 사용하고, 기존 방화벽 규칙을 재사용할 수 있도록 HTTP를 기반으로 설계되었다
(TCP는 Binary 데이터만 주고 받을 수 있지만, Websocket은 Binary 데이터 뿐만 아니라 Text 데이터를 주고 받을 수 있다)
Pub/Sub 브로커
메시징 방식을 잘 정의한다면 websocket만으로도 충분히 좋은 서버/클라이언트 소켓 서버를 완성할 수 있다.
하지만 단순한 통신 구조로 인해 Websocket만을 이용해 채팅을 구현하면 해당 메시지가 (1)어떤 요청인지, (2)어떻게 처리해야 되는지에 따라 채팅룸과 세션을 일일이 구현하고 메시지 발송 부분을 관리하는 등 다채로운 모델링을 하기가 힘들다
Stomp
텍스트기반의 메세징 프로콜로 메세지전송을 효율적으로 하기 위해 나온 프로토콜이다
pub/sub 구조로 되어있어 메시지를 발송하고, 메시지를 받아 처리하는 부분이 확실히 명시 가능하다
-> 개발하는 입장에서 명확하게 인지하고 개발할 수 있는 이점을 가짐
Stomp를 이용하면 통신 메시지의 헤더에 값을 세팅할 수 있어 헤더 값을 기반으로 통신 시 인증처리를 구현하는 것도 가능
여기서 pub/sub란 메시지를 공급하는 주체와 소비하는 주체를 분리하여 제공하는 메시징 방법으로 채팅앱과 비교하면
다음과 같다.
- 채팅방을 생성한다– pub/sub 구현을 위한 Topic이 하나 생성된다.
- 채팅방에 입장한다 – Topic을 구독한다.
- 채팅방에서 메시지를 보내고 받는다 – 해당 Topic으로 메시지를 발송하거나(pub) 메시지를 받는다(sub)
브로커를 사용하여 메시지 Pub/Sub(발행 및 구독) 서비스를 이용할 수 있으며 장점으로는 3가지로 나누어 말할 수 있다.
1. 서비스간의 의존성 제거
송,수신 측 서버가 늘어나도 메시지 브로커의 주소만 알고 있으면 문제가 없다.
수신 서버 문제 시 -> Broker는 메시지를 받아 큐에 저장해놓고 수신 측이 받아가길 기다린다 (유지 시가 설정 가능)
2. 메시지 처리 시점
수신 측에서 원하는 시점에 메시지를 가져갈 수 있도록 (처리할 수 있도록) 지원하고 있습니다
이러한 기능을 '메시지 버퍼링'이라고 부르기도 합니다.
3. 다양하고 유연한 통신
또한 브로커는 메시지 브로커, 이벤트 브로커 2가지로 나뉠 수 있다.
이 둘을 간단히 설명하면 다음과 같다.
메시지 브로커는 이벤트 브로커의 역할을 할 수 없지만, 이벤트 브로커는 메시지 브로커의 역할을 할 수 있다.
메시지 브로커 (RabbitMQ, Redis ...)
대규모 메시지 기반 미들웨어 아키텍쳐에서 사용되어왔다.
메시지를 받아서 적절히 처리하면 짧은 시간내에 메시지가 삭제되는 특징이있다.
데이터 손실의 위험이 있다.
이벤트 브로커 (kafka, kinesis...)
이벤트 또는 메시지라고 불리는 정보를 하나만 보관하고 인덱스를 통해 개별 엑세스를 관리한다.
업무상 필요한 시간동안 이벤트를 관리한다.
메시지 브로커와 다르게 이벤트가 삭제되지 않는다는 특징이 있다.
그리고 서비스에서 발생하는 이벤트를 DB에 저장하듯이 이벤트 브로커의 큐에 저장한다.
이벤트를 저장함으로써 얻는 장점은 다음과 같다.
- 딱 한 번 일어난 이벤트 데이터를 브로커에 저장함으로써 모든 데이터 요소를 한 곳에서만 제어 또는 편집하도록 조직하는 관례(단일 진실 공급원)에 맞게 동작한다.
- 장애가 발생했을 때 장애가 일어난 지점부터 재처리할 수 있다.
- 많은 양의 실시간 스트림 데이터를 효과적으로 처리할 수 있다.
Kafka vs RabbitMQ
Kafka는 대용량의 분산 로그 트래픽을 처리한다는 점에서 유리하다면, RabbitMQ는 높은 처리량보다는 지정된 수신인에게 원하는 방식으로 메시징을 신뢰성 있게 전달하는데 초점이 맞춰져 있습니다.
참조
https://hyeo-noo.tistory.com/334
https://swiftymind.tistory.com/105
정리하며
채팅 앱을 요구하는 고객을 만나면서 관련된 자료를 정리하고, 직접 글을 쓰기 시작하니 생각이 많이 정리된 것 같다.
막연하게 websocket, kafka등 알고있었지 자세히 양방향 통신, 브로커를 알아가보니 왜 사용하는지 어떤 부분에서 필요한지 공부할 수 있었던것 같다.
* redis를 브로커로 사용할 수 있는것도 알고 코딩에 필요성도 확실히 느낀다