RSocket 살펴보기

RSocket 이란

RSocket은 Reactive Stream 인터페이스를 구현한 통신 프로토콜로 TCP, WebSocket 같은 바이트 스트림 전송에 사용된다.

현재 우리가 사용중인 HTTP 1.1은 하나의 TCP 커넥션에 Request와 Response를 주고 받고 연결을 끊는 형태이다.
하나의 커넥션에 하나의 요청과 응답 이 HTTP 1.1의 단점이다.
이를 해결하기 위해 파이프 라이닝 기법 이 생겼다
파이프 라이닝 기법은 하나의 커넥션에 여러 요청을 한번에 보내고, 받는 방식이다.
문제는 HOLB (Head Of Line Blocking)이 발생한다는 것이다.
- HOLB 문제는 결국에 응답은 순차적으로 받기 때문에, 첫번째 요청이 지연이 생기면 뒤쪽 요청들까지 함께 지연되는 것이다.
- 간단한 예로, 첫 요청이 이미지를 받고, 뒤에는 Script를 받는 것을 파이프 라이닝으로 요청했다고 해보자.
- 이미지를 받는데 2초가 필요하고, script를 받는데 0.1초가 걸린다고 해보자.
- 응답을 다 받을 때까지 총 시간은 결국 2.1초가 필요하다. 그렇기에 파이프라이닝은 큰 효과는 없다.
또한 HTTP 는 무거운 헤더 구조가 단점이다.
다양한 헤더들이 추가되면서 헤더 구조가 무거워졌고, 이는 결국 네트워크 트래픽에도 영향을 미친다.
물론 HTTP 1.1의 한계를 개선하기 위해 HTTP 2가 헤더 압축과 멀티플렉스드 한 방식, 양방향 통신을 달고 나왔지만, 그래도 Header 구조가 무거운 것은 사실이다.

HTTP 프로토콜을 개발할 당시는 요청과 응답에 HTML을 주고받는 시대였다.
하지만, 현재 2019년 기준으로 프론트 엔드의 기술이 발전하며, 가상 DOM을 이용한 SPA 방식의 클라이언트 사이드 렌더링이 사용되고있다.
한때는 하나의 웹 서버에서 페이지 렌더링을 함께 처리하였다면, 현재는 Rest API의 설계 원칙에 따라서 Json으로 데이터를 주고 받으며 파싱하여 데이터를 렌더링 하는 것이 흔한 방식이다.
그렇다면, 여기서 드는 의문은 굳이 HTTP 스펙을 지키면서 애플리케이션을 개발할 필요가 있을까?

과거와 달리 현재는 다양한 서비스들이 생겨나고 있다.
'요청'과 '응답' 뿐만이 아니라, 실시간 채팅 서비스, 데이터 적재 서비스 등..
이런 다양한 요구에 유연하게 대처하기 위한 프로토콜이 필요하다.
어쩌면 일부 서비스들은 '요청'과 '응답'으로 해결할 수 없는 모델에 사용하고 있는 경우도 있을 수 있다.
이를테면, 유저 노티피케이션 서비스가 있다고 해보자.
HTTP 를 이용하여 노티피케이션 서비스를 유저에게 제공하기 위해서는 polling을 통해서 노티피케이션이 발생하였는지 일정 시간 간격으로 확인을 해주어야 한다.
그리고 노티피케이션이 발생하면 그때 클라이언트 사이드에서 비즈니스 로직을 실행시키는 것이다.
만약 노티피케이션이 10초간격이라고 생각해보면, 유저가 해당 노티를 실시간으로 받지 못하고 최악의 경우 10초 후에 받을 수도 있다.

1. Request And Response : 하나의 요청과 응답으로 가장 기본적으로 많이 사용되는 모델이다.
2. Fire And Forgot (no response): 요청을 보내고 바로 응답을 기다리지 않고 커넥션을 끊는다. 그렇기 때문에 응답이 필요없는 경우에 사용하면 최적화를 기대할 수 있다.
3. Request Stream (multi-response, finite): 스트림으로 데이터를 받는다. 예를 들어 List 데이터를 받는다면, 각각의 엘리먼트들을 하나의 single response로 하여 여러번 스트림을 통해 내보낸다.
4. channel (bi-directional) : 양방향 통신을 한다.

RSocket이 현재 Spring boot 2.2 릴리즈에도 추가되어 어플리케이션 레벨에서 좀 더 쉽게 사용할 수 있도록 릴리즈 되었다.
C++, 코틀린, 자바스크립트, go 등 다양한 언어들 또한 지원한다.
현재는 RSocket이 초기 단계이기 때문에 상용에 직접 사용하기에는 무리가 있어보이지만, 추후에 gRPC와 함께 MSA 플랫폼에서 서비스간 통신 레이어를 책임질 프로토콜이 되지 않을까 싶은 생각이든다.