프로젝트를 진행할 때 웹소켓을 이용하면서 생긴 문제점

STOMP 프로토콜을 사용한 이유가 있을까요?
웹소켓은 통신 채널을 제공해주지만 메시지에 대한 규약이 존재하지 않는다
STOMP 프로토콜을 사용하면 정형화된 메시지 프레임을 사용할 수 있어 좀 더 체계적인 데이터 관리가 가능하다

웹소켓 설정에서

.setAllowedOriginPatterns("*")

 이 설정을 전부 허용한 이유가 있을까요?
개발 단계에서 서버와 클라이언트 연결을 테스트 할때 origin이 달라 발생하는 cors 문제를 빠르게 해결하고 기능 구현에 집중하기 위해서 전부 허용하였다. 이렇게 설정하면 보안상 어느 클라이언트 에서도 접근이 가능하게 되어 보안상 취약하다는 점도 인지하고 있다.

웹소켓에 연결한 클라이언트들을 어떻게 관리했나요?
작성한 기능이 관리자와 항상 연결된 상태에서 이벤트 생성 시 메시지를 보내는 기능이라 세션관리는 추가적으로 하지 않았다.
하지만 WebSocketSession을 사용해 단일 서버 환경에서는 ConcurrentHashMap, 스케일 아웃하는 서버 환경에서는 레디스를 활용해 세션을 관리하는 방법을 찾아보며 학습 중이다

왜 웹소켓을 사용했나요?
완성된 기능을 기준으로 볼 때 기술 선택이 다소 아쉬웠다고 생각한다
초기에는 제품을 구독한 사용자에게 실시간으로 통신을 하는 방식을 생각해 웹소켓을 사용하였지만 변경된 기능을 보았을 때 서버에서 클라이언트로 데이터를 푸시하기만 하면 되는 기능이 되었고 이는 SSE를 사용하는 것이 더 적합한 기술 이였다고 생각한다. 그리고 항상 연결 상태를 유지 해야하기 때문에 브라우저가 자동으로 재연결을 시도한다는 장점도 있어 더더욱 좋았을 듯 하다

성능상의 문제는 없나요?
현재는 특정 관리자와 1:1 연결 방식을 사용하므로 연결 리소스 자체의 부담은 적다.
하지만 단시간에 대량의 이벤트가 생성될 경우 성능 개선 방법을 파악하고 있다
예를 들어 10000개의 제품이 이벤트가 등록되었을 때 서버에서는 일일히 이벤트를 발생 시키고 DB도 각각 Insert해야 하는 상황이 생기므로 큰 부하를 줄 수 있다. 또한 클라이언트에서는 갑작스럽게 대량의 메시지를 수신 받아 브라우저가 느려지는 현상도 발생할 수 있다
이를 해결하기 위해 배치처리를 생각하고 있고 insert는 bulk 방식을 사용해 해결할 수 있을 것 같다