Spring messging, Stomp를 활용한 메세지 관리 + 다중 세션 관리 구현

0. 해결해야 하는(구현해야 하는) 문제(요구 사항)

- 사이트에 실시간으로 접속한 사람의 목록과 해당 사용자들이 현재 어떤 페이지, 탭에 접속해있는지를 확인해보고자 했다

 

- http, rest API를 통한 구현도 가능하겠지만, 이는 진정한 "실시간"을 의미하는 것이 아니며, 조금이라도 연결이 끊어지기 때문에 웹소켓(WebSocket) 프로토콜을 통한 접근을 시작했다

 

- 현재 프로젝트 환경에서는 스프링을 사용하고 있고, 스프링에서 웹소켓 프로토콜을 활용할 때 순수 웹소켓을 사용해도 되지만, Stomp 프로토콜을 사용해 더욱 간편한 구현이 가능하므로, 이 개발을 진행했다

-> 사용한 기슬 스펙

1) stomp

2) spring messing

3) event Listener

4) ConcurrentHashMap

1. 구현 간 trade - off

1) 순수 웹소켓 vs stomp

- 웹소켓은 기초적인 프로토콜이기 때문에, 실시간 통신에 필요한 메세지 라우팅, 메세지의 세션 관리, 브로드 캐스팅에 대한 기능 구현을 모두 해야한다.

stomp에서는 해당 기능을 보다 간편하게 구현할 수 있도록 메세지 브로커를 지원하며,

또한 메세지에 대해 헤더와 바디를 명확하게 구분하고 있어 메세지 송수신이 보다 간편하고 명확하게 진행이 가능하다

 

2) 메세지 브로커 : spring messging, rabbitMQ, kafka

- spring messging은 독립적인 메세지 브로커의 개념이 아니라, 스프링에서 제공하는 메세지 브로커 추상화 라이브러리로 다양한 메세지 브로커를 코드의 변경이 거의 없이 자유롭게 변경이 가능하다는 장점을 제공한다. 메세지 템플릿으로 messagingTemplate 인스턴스를 제공하며, 이 대신 spring - rabbit 또는 spring - kafka 라이브러리를 활용할 수 있다.

+ 현재 프로젝트에서 rabbitMQ와 kafka를 통한 메세징 구현은 오버스펙이어서,(트래픽이 높지 않다) 해당 기술을 활용한 개발은 아쉽지만, 러닝커브를 고려해 다음 기회로 미뤘다

 

3) 동시성 관리를 위한 concurrentHashMap 자료구조 사용

- spring messging 템플릿만을 이용해 메세징 관리를 하기 때문에, 사용자 추적 방식을

구현할 때 어떤 방식으로 해야하는 지 고민을 많이 했다.

 

기본적으로 사용자를 특정할 때 많이 사용하는 세션으로 사용자를 특정하려고 하면 메세지 부분에서 세션이 메세지마다 각각 새로 생성되는 것을 알게 되었다. 따라서 같은 브라우저 내라도 다른 탭 등으로 메세지를 클라이언트에서 송신하는 경우 다른 사용자로 인식하기 때문에 해당 문제 해결이 필요했다

(추후 IP를 통한 관리로 리팩토링이 가능할지 분석해야한다)

 

그래서 사용자 정보를 담은 Dto를 생성하고, 이를 concurentHashMap으로 감싼 접속자 목록, 해당 사용자의 세션을 관리하는 목록을 마찬가지로 concurrentHashMap으로 구현했다. 해당 사용자 목록에 대해서는 여러 스레드에서 동시에 접근하기 때문에, 스레드 안전 및 동시성 보장이 매우 중요했다.

 

concurrentHashMap은, 먼저 내부 데이터에 각각 독립적인 락을 사용한다. 따라서 여러 스레드가 동시에 접근해도 락 경쟁이 발생할 가능성이 낮아진다. 또한 스레드가 증가해도 성능 저하에 영향이 최소화되도록 설계된 자료구조기 때문에 일반적인 hashMap 보다 훨씬 나은 점이 많았다

(추후 클러스터 환경이 도입된다면, 이 부분에 대해 redis 등의 수단을 통해 사용자 목록 관리를 고도화할 수 있을 것이다)

 

2. 코드

1) 연결 해제 시,

@EventListener
    public void handleWebSocketDisconnectListener(SessionDisconnectEvent event) {
        StompHeaderAccessor accessor = StompHeaderAccessor.wrap(event.getMessage());
        String sessionId = accessor.getSessionId(); // 연결 해제된 세션 ID 추출

        if (sessionId != null) {
            String email = userSessions.get(sessionId) != null ? userSessions.get(sessionId).get("email") : null;

            if (email == null) {
                logger.warn("No email found for sessionId: {}", sessionId);
                return;
            }

            removeUserSession(sessionId, email);

            sendClientListOnline();
        }
    }

- 메세지 해제 이벤트 발생 핸들러를 통해 다음과 같은 로직 구현

- userSessions는 동일 사용자의 다중 메세지 세션 관리를 위한 map으로 사용자를 특정하기 위해 여기서는 이메일을 사용했다

- 이벤트의 세션 아이디를 가진 이메일(사용자)를 찾고 그 사용자를 접속자 목록에서 제거한 후, 브로드 캐스팅으로 해당 변경 사항을 반영한다

 

2) 다중 세션에서 최신 세션의 정보로 업데이트 하기 위한 최신 세션 찾기

 private ConcurrentHashMap<String, String> findLatestUserInfo(String targetEmail) {
        return userSessions.entrySet().stream()
                .filter(entry -> targetEmail.equals(entry.getValue().get("email")))
                .max(Comparator.comparing(entry -> {
                    String timeStamp = entry.getValue().get("timestamp");
                    return timeStamp != null ? timeStamp : "";
                }))
                .map(Map.Entry::getValue)
                .orElse(null);
    }

-다중 세션을 단순히 저장하기만 하는 것이 아니라, 세션에서 메세지를 보낸 시간을 timestamp로 기록해 가장 최신의 세션으로 현재 사용자가 어느 페이지에 있는지를 확인할 수 있는 로직이다

- 또한 사용자가 세션을 종료할 경우, 동일 사용자의 가장 최신 세션을 찾기위해서도 활용된다

 

3) 사용자 추적 로직

public void trackingUserInfo(ConcurrentHashMap<String, String> userInfo) {
        String email = userInfo.get("email");

        if (email == null) {
            logger.warn("Email is null, skipping user tracking");
            return;
        }

        if (!connectedUsers.containsKey(email)) {
           logger.debug("Adding user with email: {}", email);
        }

        makeUserSession(userInfo);

        ConcurrentHashMap<String, String> latestUserInfo = findLatestUserInfo(email);

        if (latestUserInfo != null) {
            connectedUsers.put(email, userInfo); // 사용자 정보 업데이트
        }

        sendClientListOnline();
    }

 

- 클라이언트에서 보내준 정보에서 이메일을 찾아 해당 정보와 현재 페이지 등을 바탕으로 한 유저 세션 리스트에 등록한다. 그리고 그 세션을 바탕으로 접속자 목록을 업데이트하고 브로드 캐스팅을 통해 클라이언트로 반환한다

 

4) 세션 제거 로직

- 연결 해제 이벤트 발생 시, 2)의 최신 정보 찾기 로직을 통해 먼저 남아있는 세션이 있는지를 파악한다. 없는 경우에 해당 사용자를 사용자 목록에서 제거한다. 그렇지 않은 경우에는 3)을 앞에서 찾은 최신 유저 세션을 가지고 재 호출하여 해당 사용자의 정보를 업데이트한다

3. 소감

- 만들면서 상당히 재밌었다. 설계 부분에서 오버스펙이 되지 않기 위해 고민을 했고, 혼자 구현하기 때문에 일정에도 부담이 없어야 했다. 그런 점에서 상당히 깔끔하고 논리적으로도 완성도 있는 기능을 구현한 듯 하여 보람있었다

- 추후 설계를 통해 얼마든지 확장할 수 있는 확장성있는 코드와 재사용성이 충분한 코드를 구현한 점이 매우 좋았고, 동시성을 고려한 점도 매우 뜻있는 코드였다