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

개요

채팅방 메세지 읽음 처리 기능은 사용자가 마지막으로 읽은 메세지를 추적하여, 읽지 않은 메세지의 개수를 확인하고 각 메세지에 대해 '읽지 않은 개수 (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에서 업데이트된 데이터만 각 클라이언트에 반영해 최신 상태를 유지하는 것입니다.

 

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

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

 

테스트는 1000명이 참여하는 채팅방에 999명이 각각 1000개의 안읽은 메세지를 읽는 시나리오를 기준으로 테스트를 진행해 보았습니다.

개선전

개선 전 구조에서는 전체 작업 완료 시간이 최대 45초에 달했으며, p90 지연 시간은 74.13ms, p95는 79.26ms로 측정되었습니다. 이때 MongoDB의 초당 처리 건수가 17.2k(17200)로 급격히 증가했으며, 데이터베이스 CPU 사용률은 최대 48%까지 상승해 시스템 자원 사용률이 높아지는 현상이 관측되었습니다. 

 

근본 원인은 사용자가 메세지를 읽을 때마다 해당 메세지 문서에 대해 개별적으로 update 연산을 수행하는 구조가 과도한 I/O와 CPU 부하를 유발하여 전체 처리 지연을 유발하고 있었기 때문입니다. 

개선 후

개선 후에는 전체 작업 완료 시간이 13.8초로 크게 단축되었으며, p90 지연 시간은 14.87ms, p95 지연 시간은 15.49로 응답 지연 시간이 대폭 줄어들었습니다. MongoDB 문서 처리량도 초당 17.4건 수준으로 안정화되었고, 프로세스 지표상 CPU 사용량은 4.3%, 메모리 사용량은 137MB로 시스템 자원을 훨씬 효율적으로 활용할 수 있게 되었습니다.

결론

사용자가 1000개의 채팅 메세지를 모두 읽음 처리 하려면 시스템이 매번 1000건의 레코드를 개별 업데이트해야 했습니다. 이런 방식은 데이터베이스에 큰 부하를 주었고, 처리 시간이 길어질 수 밖에 없었습니다. 그러나 이번 개선을 통해 한 레코드의 업데이트만으로 전체 메세지를  읽음 처리하도록 동작을 변경하였습니다. 

 

기존 로직은 채팅 메세지 필드에 메세지 상태를 저장하여서 수정이 필요할 때, 각 행을 하나씩 순회하면서 업데이트 했다면, 개선된 로직은 사용자별로 마지막 읽은 메세지 ID 하나만 저장합니다. 메세지 열람 여부를 확인할 때마다 각 메세지에 불필요하게 업데이트 하지않고, 마지막 읽음 위치만 갱신하도록 한 것입니다. 이를 통해 데이터베이스에 전달되는 쿼리 수가 줄어들게 되었고, 시스템 자원을 훨씬 효율적으로 활용할 수 있었습니다.

 

이번 사례는 새로운 기술을 도입하거나 인프라를 확장하지 않고도 얻을 수 있는 성능 향상의 좋은 예였습니다. 성능 문제를 해결하려면 단순히 새로운 기술을 적용하는 것보다, 시스템의 동작 원리와 데이트의 흐름을 이해하고 핵심 병목을 찾아내는 과정이 중요하다고 생각하게되었습니다.