이전 포스트 까지 개발한 내용을 정리하면 다음과 같다.
서버는 Redis를 통해서 예약 정보를 저장함으로써 동시에 접속한 사용자 클라이언트에서 같은 예약 정보가 선택되는 것 자체를 막는다.
여기서 한발 더 나아가서, 사용자 A가 예약을 성공적으로 완료한 경우, 사용자 A가 예약한 예약 정보를 실시간으로 사용자 B가 접속한 클라이언트 페이지에 반영하는 기능을 구현하고 싶었다.
공연이나 스포츠 경기를 예매하는 시스템에 접속했을때 좌석이 실시간으로 사라지는 모습을 보고싶었는데, 그런 느낌을 줄 수 있을 것이라고 생각한다.
관건 중 하나는 어떻게 서버가 예약 페이지에 접속한 모든 클라이언트들에 메시지를 전파하는가 이다.
HTTP 프로토콜 통신은 단방향으로만 이루어진다. 클라이언트는 웹 서버에 요청을 보내고 웹 서버는 HTML, CSS, JSON 등 형식에 맞는 데이터를 포함한 응답을 클라이언트에 전달한다.
이러한 방식은 클라이언트가 항상 서버에 요청을 해야만 정보를 받을 수 있기 때문에 실시간 데이터 업데이트가 불가능하다. 예를 들어, 여러 사용자가 동시에 예약 페이지에 접속해 있을 때 한 사용자가 예약을 완료하더라도 다른 사용자는 이를 즉시 알 수 없고, 수동으로 페이지를 새로 고쳐야만 최신 정보를 확인할 수 있다.
HTTP 프로토콜의 문제점을 보완하고 요구사항을 구현 하기 위한 기술을 찾아봤더니 내가 모르는 많은 종류의 기술들이 있었다.
1. 폴링 (Polling)
폴링은 클라이언트가 주기적으로 서버에 요청을 보내서 업데이트된 데이터를 가져오는 방식이다. 예를 들어, 클라이언트가 5초에 한번씩 서버에 예약 정보를 확인하는 요청을 보내는 것이다. 이 방법은 구현도 간단하고 별도의 기술을 사용하지 않지만 서버에 전송되는 불필요한 요청 때문에 비효율적이고 자원도 낭비될 것 같다.
2. 웹 소켓
웹 소켓 프로토콜은 단방향 통신만을 지원하는 HTTP 프로토콜과는 달리 클라이언트와 서버 간의 지속적인 연결을 유지하여 양방향 통신을 가능하도록 한다. 즉, 서버는 클라이언트가 요청을 보내지 않아도 언제든지 메시지를 전송할 수 있으며, 클라이언트는 이를 실시간으로 수신할 수 있다.
3. 메시징 시스템
메시징 시스템은 이벤트 기반 아키텍처를 지원하며, 고성능의 메시지 큐를 제공하여 서버와 클라이언트 간의 통신을 더욱 효율적으로 처리할 수 있다. 예를 들어, 예약이 완료되면 서버는 Kafka 또는 RabbitMQ를 통해 해당 예약 정보를 메시지로 발행하고, 이를 구독하고 있는 모든 클라이언트가 즉시 해당 메시지를 수신하여 컴포넌트를 업데이트 할 수 있다.
4. 서버 센트 이벤트 (Server-Sent Events, SSE)
서버 센트 이벤트는 서버가 클라이언트에 실시간으로 이벤트를 전송하는 기술이다. 클라이언트는 서버와의 연결을 유지하고 서버는 클라이언트에게 데이터가 있을 때마다 자동으로 전송한다. SSE는 HTTP 기반으로 작동하며 브라우저가 지원하는 경우 실시간 데이터 전송을 쉽게 구현할 수 있다는 장점이 있다. 다만, 이 방법은 클라이언트에서만 데이터를 수신할 수 있으며 클라이언트가 서버에 데이터를 전송할 경우 기존 HTTP 프로토콜을 이용하는 등 다른 방법을 이용해야 한다.
여러 기술들 중에서 웹 소켓을 이용하여 기능을 구현하기로 결정했다.
이전에 FastAPI를 이용한 개인 프로젝트에서 웹 소켓 기능을 이용한 채팅 시스템을 구현한 경험이 있었기 때문에, 웹 소켓의 동작 방식과 장점에 대한 기본적인 이해가 있었다. 이번 프로젝트에서 웹 소켓을 통해 실시간 예약 시스템을 구현하면서 이전 경험을 바탕으로 스프링에서 웹 소켓의 설계 방법과 구현 패턴에 대해 깊이 있게 공부하고 싶었다.
