[WebFlux]RSocket 튜토리얼

RSocket

 

RSocket은 넷플릭스에 의해 개발된, 리액티브 스트림을 지원하는 프로토콜이다.

 

당연하게도 양방향, 비동기로 메시지를 주고받는 프로토콜로서

 

TCP, 웹소켓 등의 전송 프로토콜 위에서 작동하고, 오버헤드가 적어 마이크로서비스 간의 통신에 적합하다.

 

물론 리액티브 스트림과 프로젝트 리액터를 구현한 WebFlux에서도 편하게 사용할 수 있으며,

 

일단 커넥션이 맺어지면 클라이언트/서버의 구분은 사라지고 양쪽 모두 아래의 비동기 패턴 중 하나로 통신을 시작할 수 있다.

 

• Request-Response 요청-응답 패턴
  클라이언트가 서버에게 요청을 보내면 서버가 처리 후 응답 메시지를 보내는 비동기 패턴.
  한 번에 하나의 요청과 응답을 처리할 수 있으며, 이 덕분에 여러 개의 요청을 처리할 때 동시성 문제를 방지할 수 있다.
  양방향 소통이기 때문에 클라이언트도 서버로 언제든 메시지를 보낼 수 있기 때문에 분산 아키텍처에서 유리하다. 
  
  
  • 동시성 문제 - 서로 다른 스레드가 하나의 임계영역에 접근할 때 예상치 못한 영향을 미치는 문제. 
• Request-Stream 요청 스트림
  클라이언트가 서버로 하나의 메시지를 보내면 서버가 응답하고, 이후로도 지속적으로 응답 메시지를 전송하는 패턴이다.
  이 과정에서 RSocket이 동시성 보장과 함께 고성능과 짧은 대기시간을 보장하기 때문에 대용량 데이터 스트리밍에
  유리하며, 데이터를 여러 번에 걸쳐 보낼 필요 없이 스트림 형태로 전송할 수 있게 한다.
  IoT센서, 로그 분석, 동영상 스트리밍, 주식시장 데이터 처리 등에 주로 쓰인다.
• Channel 채널: 양방향 스트림
  채널은 서버와 클라이언트가 서로 스트림으로 데이터를 주고받는 것을 가리킨다. 이 모드에서는 요청 스트림과 다르게
  서버가 요청을 보내면 해당 요청을 받고 응답한 서버가 클라이언트에게 추가적인 요청을 보낼 수 있다.
  역시 대용량 데이터 병렬처리에 특화되어 있으며, 고성능과 많은 처리량을 보장하는 동시에 백프레셔를 적용해
  데이터 전송 속도를 제어하는 것도 가능하다.
• Fire-and-Forget 단방향, 단건 메시지 전송
  클라이언트는 서버로 메시지를 보내고, 서버는 처리 후 응답을 보내지 않는 패턴이다. 따라서 요청과 응답을 기다리는데
  드는 시간을 줄일 수 있으나, 클라이언트가 요청의 성공 여부를 확인할 수 없다는 단점이 있다.
  주로 로그 데이터 전송 등에 사용된다.

전체적으로 요약하면 대용량, 대규모 분산 시스템에서 비동기/논블로킹 특유의 고성능과 짧은 대기시간 및

 

높은 처리량을 보장하고 있으며 백프레셔와 같은 방식으로 네트워크 트래픽을 최소화해 스트림이 끊기지 않도록 지원한다.

 

또한 도입부에 RSocket은 웹소켓 위에서 작동한다고 적었고 실제로도 그렇지만,

 

웹소켓과 RSocket은 전혀 다른 프로토콜인 것도 확인할 수 있다.

 

조금 정확하게 말하자면(그리고 내가 제대로 읽은 게 맞다면) RSocket은 웹소켓을 개선하기 위해 만들어졌고

또 웹소켓을 사용할 수도 있지만, 그러지 않아도 되는 독자적인 프로토콜이라고 한다.

 

이야기가 나온 김에 웹소켓과 RSocket의 차이에 대해 알아보고 가자.

 

	WebSocket	RSocket
메시지 형식 및 구현방식	연결 후 양방향 메시지 전송 가능 이진 데이터와 텍스트 형식 메시지 프레임워크 미지원 HTTP(TCP) 기반	Request-Response, Request-Stream 등 다양한 메시지 전송 패턴 지원 메시지 프레임워크 지원 (웹소켓을 포함한)독자적인 프로토콜
목적	브라우저-서버 실시간/양방향 통신	분산 시스템간의 비동기 메시지 전송 다양한 언어와 프레임워크 간의 상호 운용
연결	지속적인 연결 유지	필요에 따른 연결과 종료
장애 처리	재연결 시도	패턴에 따라 다양한 전략 보유
성능	대량의 데이터 처리시 성능 저하	대량의 데이터 처리에 특화
장점	HTTP 기반이기 때문에 방화벽 통과 웹 브라우저에서 지원 →클라이언트 구현이 매우 편함 포트 관리(80, 443)이 편하다	양방향/요청-응답/스트리밍/일회성 전송 등 다양한 메시지 패턴을 지원한다. 프로토콜 수준에서 동시성 문제를 예방한다. 채널당 병렬/동시 처리가 가능하다 로드 밸런싱을 지원해 부하 분산이 가능하다
단점	양방향 통신만 가능 서버→클라이언트 전송이 불가능하다 HTTP 헤더를 포함한 오버헤드가 크다. 대량 데이터 처리가 어렵다.	아직 브라우저에서 기본적으로 지원하지 않는다. →클라이언트 측 구현이 어렵다. 별도의 포트 관리(7000번대)가 필요하다. 웹소켓에 비해 라이브러리가 무겁다.

 

진행 중인 개인 프로젝트에서 구현을 한 번 시도해 봐야겠다.

 

RSocket 튜토리얼, 끝!