스프링 부트 R소켓

학습 내용

요청(Request)-응답(Response) 클라이언트/서버를 구성하는 방법
양쪽 모두에서 트래픽을 발생시킬 수 있는 양방향 서비스 구성

이 책을 통해 배우고 있는 모든 것은 결국 현재 자원을 잘 활용해서 더 높은 확장성을 가진 리액티브 애플리케이션을 만드는 방법
- 그중, 배압(backpressure)은 리액티브 스트림의 근간을 이루는 핵심 개념이며, 이를 통해 확장성 있는 애플리케이션을 만들 수 있음
HTTP은 요청-응답 패러다임에 뿌리를 두고 있으며 리액티브 하지 않음
HTTP를 통해 단순한 요청-응답을 넘어서 터널로 연결하는 방법을 고민
- 고민의 첫 번째 해답: 롱 폴링
  - 클라이언트가 서버에게 요청을 보낸 후 즉각적인 대답을 기대하지 않고, 오래 기다리더라도 언제든 서버가 데이터를 보낼 준비가 됐을 때 서버로부터 응답을 받으면 응답을 처리하고 바로 새로운 요청을 서버에 보내서 또 오래 기다리는 식으로 연결 지속성을 확보하는 방식
  - 문제점: 기대한 대로 동작은 했지만 자원을 점유한다는 한계가 있음
  - 대안으로 웹소켓(WebSocket)의 등장을 앞당김
- 대안: 웹소켓
  - OSI 계층에 위치하며 2011년에 표준화된 최신 프로토콜
  - 요청-응답 방식의 HTTP와는 다르게 양방향임
  - 문제점: 하지만 배압 개념이 없어 리액티브 하지 않음
R소켓: 리액티브한 새로운 프로토콜이 필요하여 리액티브 스트림을 근간으로 하는 새로운 프로토콜

R소켓은 소켓을 전제로 함
소켓은 연결을 맺고, 데이터를 송수신하는 데 신뢰성이 입증된 방식
R소켓은 단순히 연결에 사용되는 채에 다른 API를 추가한 것이라고 이해할 수 있음
R소켓의 패러다임 종류
- 요청-응답(request-response) : 1개의 스트림
- 요청-스트림(request-stream) : 다수의 유한한 스트림
- 실행 후 망각(fire-and-forget) : 무응답
- 채널(channel) : 양방향

한 번의 요청을 보내고 스트림 형태로 응답을 계속 받을 수 있으므로 좀 더 효율적인 방식이라고 할 수 있음
롱 폴링이나 코멧은 응답을 받을 때마다 처리를 하고 응답을 받은 후에 다시 요청을 보내는 일을 반복해야 함
- 비슷한 처리 작업을 위해 요청-응답을 반복하는 것은 많은 오버헤드를 유발함
- 응답을 기다리면서 스레드가 점유되므로 트래픽이 많은 상황에서는 지연 발생의 주요 원인이 됨
R소켓은 채널을 열고 요청을 보낸 후에 스트레드를 점유하지 않고 스트림 형태로 응답을 받을 수 있음
- R소켓을 바탕으로 리액티브 프로그래밍을 사용하면 "다음 10개 정보를 보내줘" 같은 요청을 보낼 수 있음

요청을 보내고 나서 응답은 신경 쓰지 않는 방식
- 리액티브 스트림에서는 어떤 것도 스레드를 점유해서는 안 되기에 유의미한 방식
R소켓은 모든 요청이 응답 결과를 항상 필요로 하는 것은 아니라는 점을 충분히 활용하면 이전 패러다임에서 언급한 연관성 유지에 의해 발생하는 오버헤드를 제거할 수 있음

R소켓의 세 가지 패러다임에서는 요청을 보내는 클라이언트와 요청을 처리하는 서버가 등장함
클라이언트와 서버는 다음과 같은 세 가지 선택지를 가짐
- 응답 대기
- 응답 대기 안 함
- 무한 응답 대기
요청을 보내는 것은 클라이언트라는 사실은 변함이 없음
채널 패러다임은 이런 틀을 깨고 진정한 메시지 지향 양방향 통신 채널을 실현함
- 채널의 어느 쪽이든 상대방에게 메시지를 전송할 수 있고, 양쪽 모두 리액티브 메시지 리스너를 반드시 등록해야 함
- RabbitMQ와 다르게 설정이 필요 없으며 배압 기능도 포함되어 있음