2024.11.11 - [Spring/WebSocket] - [Spring WebSocket] STOMP에서 Kafka 활용 Flow [Spring WebSocket] STOMP에서 Kafka 활용 Flow2024.11.10 - [Spring/WebSocket] - [Spring WebSocket] 채팅 서비스 프로젝트에 Kafka 적용 [Spring WebSocket] 채팅 서비스 프로젝트에 Kafka 적용채팅 서비스는 일반적인 `HTTP` 통신을 사용하는 `stateless` 서비스와는hdbstn3055.tistory.com 이전 포스팅에서 본것처럼 `STOMP`에 메시지 브로커인 `Kafka`를 활용해서 `Scale-Out` 상황에 대비했다. 그런데 이렇게 되면 발행되어야 할 메시지가 발행되지 않거..

2024.11.10 - [Spring/WebSocket] - [Spring WebSocket] 채팅 서비스 프로젝트에 Kafka 적용 [Spring WebSocket] 채팅 서비스 프로젝트에 Kafka 적용채팅 서비스는 일반적인 `HTTP` 통신을 사용하는 `stateless` 서비스와는 달리,`WebSocket`을 사용해 클라이언트와 상시 연결되어 있는 `stateful`한 특성을 가진다. 만약, 단일 인스턴스라면 해당 부분은hdbstn3055.tistory.com 우리는 위 포스트를 통해 `WebSocket`을 사용하는 서비스에서 `Kafka` 즉,`Message Broker`를 사용하는 이유에 관해 알아보았다. 그렇다면 실제로 어떤식으로 코드를 작성해야 할까? 코드를 설명하기에 앞서 간단하게 요약하..

우리가 `Spring`의 `HTTP` 작업에서 예외처리를 하는 경우`@RestControllerAdvice`와  `@ExceptionHandler`를 사용하면 아주 편하게 예외처리를 할 수 있다. 다행히(?)도 `STOMP`에도 `@ExceptionHandler`와 비슷한 기능을 지원하는 `@MessgeExceptionHandler`가 있다.(대단하다.. SpringBoot!!) 하지만, 그냥 바로 사용하면 몇가지 문제가 존재한다. 우선, 여러 클라이언트가 특정 경로를 구독하고 있다고 가정해보자. 이때 만약, 특정 클라이언트가 `STOMP` 메시지 처리 관련해서 예외를 발생시키면(없는 메시지 수정, 없는 `Normal` 접근 등등)해당 클라이언트에게만 예외 메시지를 전송해야 한다. 하지만, `STOMP`..

채팅 토이 프로젝트를 진행하면서 사용자 인증/인가를 위해 `Spring Security`도 사용을 하였다. 하지만, 채팅 서비스는 `WebSocket` 위에서 동작하기에커넥션이 맺어진 이후에는 `Security Filter`를 타지 않는다. 따라서, 이와 관련해서 `JWT` 검증을 다르게 동작시켜야만 한다.   우선, `Spring Security`를 이용해 `WebSocket` 연결을 보호할 때, 인증 및 인가가 이루어지는 순서를 살펴보자. 이 과정에서는 `HandShake`와 `WebSocket` 통신 두 가지 주요 단계가 있다. 각 단계에서 `Spring Security` 필터와 `ChanneInterceptor`가 어떻게 작동할까?  1. Handshake 단계`Handshake` 단계는 `TCP..

2024.11.10 - [Spring/WebSocket] - [Spring WebSocket] STOMP를 활용한 채팅 서비스 토이 프로젝트 [Spring WebSocket] STOMP를 활용한 채팅 서비스 토이 프로젝트`WebSocket`, `SockJS`, `STOMP`를 학습하고 직접 실습해보는 프로젝트를 구상을 했다.개념을 학습하는 것과 직접 코드로 구현하는 것은 완전히 다른 영역이기에 실습해보는 것이 중요하다고 생각한다.hdbstn3055.tistory.com 이전 포스팅에서 설명한 것처럼 나는 `MongoDB`를 사용하기로 결정했다. 유저와 일반 채팅 저장에서도..  `MongoDB`는 관계형 데이터베이스와 같이 네이티브 조인을 지원하지 않는다. 물론, 집계 파이프라인에서 `LeftOuterJ..

채팅 서비스는 일반적인 `HTTP` 통신을 사용하는 `stateless` 서비스와는 달리,`WebSocket`을 사용해 클라이언트와 상시 연결되어 있는 `stateful`한 특성을 가진다. 만약, 단일 인스턴스라면 해당 부분은 큰 문제가 되지 않을 것이다.(왜냐하면, 어차피 해당 인스턴스내에서 모든 작업이 일어나기 때문에 서버가 종료되면 마찬가지로 종료되기 때문) 하지만, 문제는 `Scale-Out`시에 발생한다. 왜 그런지 아래의 예시와 함께 살펴보자.  채팅 서비스 Scale Out시 문제점왜 `stateful` 하면 `Scale-Out`시 문제가 발생할까? 만약, 카카오톡과 같은 비슷한 코코아톡이라는 채팅 서비스가 현재 단일 인스턴스를 갖는다고 가정해보자.  이때, 코코아톡이라는 채팅 서비스에 민수..