채팅 메세지 읽음 처리 기능 구조 개선기

개요

채팅방 메세지 읽음 처리 기능은 사용자가 마지막으로 읽은 메세지를 추적하여, 읽지 않은 메세지의 개수를 확인하고 각 메세지에 대해 '읽지 않은 개수 (Unread Count)'를 표시합니다. 

 

기존의 메세지 읽음 처리 구조는 각 메세지마다 해당 메세지를 읽은 유저의 ID 리스트를 기록하고, 읽은 유저 ID 배열의 길이를 통해 '읽지 않은 개수 (Unread Count)'를 계산했습니다. 하지만 사용자가 많은 채팅방은 사용자가 적은 채팅방에 비해 더 많은 메세지가 오가므로, 수정해야할 데이터의 개수가 기하급수적으로 늘어나게 됩니다. 이를 해결하기 위해 메세지 읽음 처리 로직을 개선해보겠습니다. 

 

기존의 메세지 읽음 처리 로직

먼저, 기존의 채팅 시스템의 메세지 읽음 처리 로직을 살펴보겠습니다. 

 

앞서 설명한 것처럼, 기존 시스템은 각 메세지마다 읽은 사용자들의 정보를 개별적으로 저장하고, 이를 바탕으로 메세지의 '읽은 메세지의 개수 (Unread Count)'를 계산했습니다. 

개별 채팅마다 읽은 사용자의 ID를 저장하고 있음

'오사카 먹방 투어방' 이라는 채팅방에 10명의 사용자가 있다고 가정해보겠습니다. 

 

이때 누군가가 '안녕하세요'라는 메세지를 보냅니다. 그러면 '안녕하세요' 메세지를 읽은 사용자와 읽지 않은 사용자가 나뉘게 됩니다. 메세지를 읽은 사용자 정보는 개별적으로 저장되며, 이를 바탕으로 '읽지 않은 개수 (Unread Count)'가 계산됩니다. 

 

이 구조는 위 이미지처럼 각 메세지마다 읽은 유저 정보를 저장하기 때문에, 메세지가 쌓일수록 데이터 양이 증가하게 됩니다. 이로인해 메모리 사용량이 늘어나고, 메세지 처리 속도가 느려질 수 있습니다. 

 

또 하나의 문제는 과도한 수정이 발생한다는 점입니다. 사용자가 채팅방을 보지 않는 동안에 새로운 메세지가 100개가 왔다고 가정해보겠습니다. 

 

메세지 하나하나에 정보를 기록하는 기존의 방식을 따르면, 100개의 메세지 읽음 처리를 위해서는 100개의 채팅 데이터를 수정해야 하는 상황이 발생합니다. 사용자가 1명일 경우에도 과도한 수정이 일어나며, 여러 사용자가 동시에 메세지를 읽을 때는 더 많은 수정이 이루어집니다. 예를 들어, 10명의 사용자가 100개의 메세지를 읽음 처리하면, DB는 100개의 채팅 데이터에 10번 수정해야합니다. 이 과정은 추후 DB에 큰 부담을 주는 무거운 작업이 될 수 있습니다. 

 

개선된 메세지 읽음 처리 로직

개선된 메세지 읽음 처리 로직에서는 각 채팅방마다 별도의 '마지막 읽은 메세지 (LastReadMessage)'를 저장하도록 하였습니다. 

 

이제 개별 메세지에 정보를 기록하는 대신, 각 채팅방에 사용자별 마지막 읽은 메세지 ID를 저장합니다. 

 

개선된 메세지 읽음 처리과정은 아래와 같습니다. 

1. 해당 채팅방의 LastMessage 데이터를 가져옴
2. 가져온 데이터를 통해 각 메세지의 Unread Count를 계산
3. 사용자가 채팅방에서 이탈할 경우 현재 채팅방에서 가장 마지막에 도착한 메세지 ID로 해당 사용자의 Last Read Message ID 업데이트
4. 이후 사용자가 채팅방에 재접속하는 경우, Last Read Mesage ID 업데이트

사용자가 채팅방에 들어와서 메세지를 확인하는 동안, 그 사용자의 '마지막 읽은 메세지 (Last Read Message)'는 '-1'로 업데이트됩니다. 이로 인해 사용자가 채팅방에 있는 동안에는 그 사람이 모든 메세지를 읽었다고 간주하여, 메세지를 모두 읽은 상태로 처리합니다. 이렇게 처리되면, 새로운 메세지가 도착해도 그 메세지는 이미 읽은 것으로 자동 처리됩니다. 

 

이 상태에서는 사용자가 더 이상 새로운 메세지를 읽었다는 업데이트를 하지 않아도, 시스템은 그 사람을 모든 메세지를 읽었다고 판단하게 되어 불필요한 데이터베이스 업데이트를 막을 수 있습니다. 

 

메세지 읽음 처리 로직 예시

위 그림은 유저별 마지막으로 읽은 메세지 ID를 관리하는 테이블이며, 해당 테이블에서는 가로는 사용자, 세로는 각 채팅을 의미합니다. 

 

해당 채팅방의 사용자는 총 6명, 메세지는 총 9개이며 이 중 보라색으로 칠해진 사용자는 현재 채팅방을 실시간으로 확인하고 있는 사용자를 의미합니다. 각 사용자가 마지막으로 읽은 메세지는 'O'로 나타내고 실시간으로 확인하고 있는 사용자는 '-1'로 나타냈습니다. 

 

이를 바탕으로 Unread Count를 계산해보겠습니다. 

채팅 ID	읽은 사용자 ID	Unread Count
1	[1, 2, 3, 4, 5, 6]	0
2	[1, 2, 3, 4, 5]	1
3	[1, 2, 3, 4, 5]	1
4	[1, 2, 3, 4]	2
5	[1, 2, 3]	3
6	[1, 2, 3]	3
7	[1, 2]	4
8	[1, 2]	4
9	[1, 2]	4

이런식으로 각 메세지의 Unread Count를 구할 수 있습니다. 

 

유의할 점은 Last Read Message를 활용하기 위해서는 계산의 정확성을 위해 적절한 상황에 제때 업데이트가 되어야 한다는 것입니다. 

 

마지막 읽은 메세지 업데이트

마지막 읽은 메세지를 업데이트해야 하는 상황은 2가지의 경우가 있습니다. 

1. 사용자가 특정 채팅방에 접속한 경우
2. 채팅방에 접속해있는 사용자가 접속을 해제한 경우

첫 번째 경우는 해당 사용자의 마지막 읽은 채팅 ID를 '-1'로 수정하고 수정된 것을 해당 채팅방에 참여하고 있는 사용자들에게 이벤트를 전달하는 것으로 해결할 수 있습니다. 

 

두 번째 경우는 해당 사용자가 연결을 해제한 시간을 기준으로 마지막 채팅 ID를 수정하고 해당 채팅 ID와 사용자 ID를 해당 채팅방에 참여하고 있는 사용자들에게 이벤트를 전달하는 것으로 해결할 수 있습니다. 

 

이렇게 구성하면 각 클라이언트는 처음으로 해당 채팅방의 마지막 읽은 메세지 데이터를 가져온 후, 이후부터는 사용자가 접속/해제 될때마다 발생하는 이벤트 메세지를 통해 실시간으로 업데이트 합니다. 즉, 한번의 조회후에는 DB에서 업데이트된 데이터만 각 클라이언트에 반영해 최신 상태를 유지하는 것입니다.

 

채팅 시스템 메세지 읽음 기능 개선 효과

개선 전과 개선 후의 차이를 알아보기 위해 테스트를 진행하였습니다. 

개선전

@Test  
@DisplayName("사용자 B가 10000개의 채팅을 읽지 않은 상태에서 접속하는 경우 - 개선 전")  
public void addOnlineUserWhenUserBConnectsWithUnreadMessagesBefore() {  
    // given  
    Long userAId = 1L;  
    Long userBId = 2L;  
    Long chatRoomId = 100L;  
  
    onlineChatRoomRepository.save(chatRoomId, userAId);  
  
    // when  
    chatUserStatusService.addOnlineUser(userBId, chatRoomId);  
  
    // then  
    Optional<Chat> findLastChat = chatRepository.findLastChatByChatRoomId(chatRoomId, LocalDateTime.now());  
  
    assertThat(findLastChat).isPresent().get()  
            .extracting(Chat::getReadUserIds)  
            .isEqualTo(Set.of(userAId, userBId));  
}

개선 후

@Test
@DisplayName("사용가 B가 10000개의 채팅을 읽지 않은 상태에서 접속하는 경우 - 개선")
public void addOnlineUserWhenUserBConnectsWithUnreadMessages() {
	// given
	Long userAId = 1L;
	Long userBId = 2L;
	Long chatRoomId = 100L;
	
	Chat lastChat = chatRepository.findChatByChatRoomId(chatRoomId, LocalDateTime.now())
		.orElseThrow(() -> new IllegalArgumentException("해당 채팅이 존재하지 않습니다."));
	
	LastReadMessage lastReadMessageByA = LastReadMessage.of(userAId, lastChat.getId());
	LastReadMessage lastReadMessageByB = LastReadMessage.of(userBId, null);
	
	ChatRoomStatus chatRoomStatus = chatRoomStatusRepository.save(
		ChatRoomStatus.create(
			LastReads.of(Last.of(lastReadMessageByA, lastReadMessageByB))
		)
	);
	
	// when 
	chatUserStatusService.addOnlineUser(userBId, chatRoomStatus.getChatRoomId());
	
	// then
	Optional<OnlineUser> findOnlineUserB = onlineUserRepository.findById(userBId);
	Optional<ChatRoomStatus> findChatRoomStatus = chatRoomStatusRepository.findById(chatRoomId);
	
	assertThat(findOnlineUserB).isNotEmpty();
	assertThat(findChatRoomStatus).isNotEmpty();
	assertThat(findChatRoomStatus.get().getLastReadMessages())
		.extracting("userId", "chatId")
		.containsExactly(
			tuple(userAId, lastChat.getId()),
			tuple(userBId, "-1")
		);
}

585ms > 370ms (36.8% 성능 향상)

이번 시스템 개선을 통해, 메세지 읽음 처리의 성능이 36.8% 향상 되었고, 동시에 DB 부하를 크게 줄이는 성과를 얻었습니다. 이를 통해 채팅 시스템의 처리 속도와 효율성을 개선할 수 있었습니다. 

 

결론

개선 전에는 사용자가 100개의 채팅을 읽음 처리하기 위해, 시스템은 100개의 채팅 데이터를 각각 업데이트해야 했습니다. 이는 DB에 큰 부하를 주고, 처리 속도에 영향을 미칠 수 있습니다. 하지만 이번 개선을 통해, 단 1개의 행만 업데이트하면 전체 메세지 읽음 처리가 가능해졌습니다.