[쇼핑몰 프로젝트] WebSocket

대원·2024년 6월 18일

쇼핑몰

목록 보기
2/13

WebSocket과 Stomp

배경

쇼핑몰 기반의 토이 프로젝트를 만들고 있다. 프로젝트를 진행하는 것이지만, 학습을 병행하며 진도를 나가는 중이다.

쇼핑몰에서 판매자와 구매자 간의 상품에 관해 문의를 할 수 있는 기능을 상정하고 실시간 채팅기능을 구현하는 것을 목표로 삼았다.

채팅을 구현해보자하면, 주요 키워드로 '웹소켓'이 나오는 것을 흔히 확인할 수 있다.

그렇다면 웹소켓은 무엇일까?

Polling, Long Polling, WebSocket

웹소켓을 설명하기에 앞서, 클라이언트와 서버를 상상해보자.

지금 내가 구현하고자 하는 것은 실시간 채팅이지만, 여기서 말하는 채팅이라는 어떤 비즈니스 요구사안에 앞서
더 중요한 기술적 포인트는 '실시간'이라고 생각한다.

클라이언트가 서버에 어떠한 정보를 요청한다고 생각해보자.

반드시 채팅이 아니어도 주식가격정보 혹은 코인가격정보와 또는 지금은 대부분의 브라우저에서 사라졌지만,
실시간 검색 순위와 같은 '실시간성'이 중요한 것들은 어떻게 구현할까?

방법은 아래와 (전통적으로) 크게 3가지가 있다.

1. Polling

  • Client -> Server에 지속적 Request 수행

    • Request 증가

    • Latency 증가

2. Long Polling

  • Polling과 유사하지만 약간은 다르다.

  • Tiemout 시간을 설정하고 Timeout이 되면 Server가 Client에 해당 내용 통지
    Timeout 사실을 안 Client는 Server에 Request 수행
    Timeout 전에 타 클라이언트에게 메시지가 오면 Server가 Client에게 해당 메시지 전달

    • Request가 Polling보단 적지만 그래도 Request 많음
    • Latency 문제 여전히 유효
  • 서버 부담 증가

3. WebSocket

  • Client와 Server사이에 Open Connection 유효

  • 해당 커넥션이 열려있는 동안에는 양방향 소통이 가능

  • HTTP에 비해 상대적으로 Header의 크기가 작고 오버헤드가 적으므로 효율적 통신이 가능

    • 프로토콜의 성격 상 초기에 한 번만 HTTP connection이 맺어지므로,
      그 이후에는 WebSocket 자체 프레임을 통해 통신

    • 해당 프레임의 크기는 Http 프로토콜에 비해 크기가 매우 작다.

  • Spring에서는 Text, Binary Type의 Handler를 지원

  • 메시지 브로커, 보안, 인증, 인가 등의 내용이 미포함되어있으므로 직접 구현 필요

위와 같은 이유로 근래에는 Polling, Long Polling보다는 WebSocket이 사용됨을 짐작할 수 있다.

그런데, 추가적으로 중요하게 나오는 키워드가 바로 'STOMP'이다.

4. STOMP

  • WebSocket만을 위해 존재하지 않지만, WebSocket 위에 얹어서 사용할 수 있는 하위 프로토콜

    • 텍스트 기반 프로토콜
  • spring-websocket 내에 spring-messaging에서 지원

  • 메시지 브로커를 활용하여 쉽게 메시지를 주고받을 수 있는 프로토콜

    • 초기 설정 및 관리가 조금 어려울 수 잇다.
  • 프레임 단위의 프로토콜

    • 커맨드

    • 헤더

    • 바디

이를 통해 짐작해볼 수 있는 부분은, STOMP가 마치 Spring Security가 보안 등의 많은 영역을 자동화해주고 편리하게 사용할수 있게 해주듯이 텍스트 기반의 메시지를 브로커 등을 이용해 조금 더 효율적으로 편하게 사용하게끔 도와주는 프로토콜임을 알 수 있다.

WebSocket을 선택한 이유

나는 채팅기능을 구현하기 위해 WebSocket을 선택했다.

메시지 그 자체만을 집중하고 조금 더 들어가고자 한다면 STOMP를 선택하는 것이 올바를 수 있다. 또한 외부 메시징 큐, 브로커(카프카와 같은) 것을 붙이지 않아도 스프링 내부에서 제공하는 메시징 큐도 존재한다.다만 해당 개념이 아직 학습곡선이 다소 높아보였고, 현재 프로젝트의 단계가 완성도 높은 프로덕트를 만드는 것이 아니라 일단 구현 그 자체에 목적이 있었다. 일단 구현을 하고 추후 부하 테스트와 같은 스트레스 테스트에서 병목 지점이 보이거나 메시징 큐 자체에 대한 이해도가 높아져서 도입의 필요성이 생기면 그 때 다시 돌아와서 웹소켓 부분을 STOMP로 마이그레이션 할 생각이다.

profile
고민하고 공부하는 사람

0개의 댓글