Write-Behind + Cache-Aside 전략

💡 기존 문제점

 메시지 전송 ->  ChatMessageController.sendMessage()  
 							↓
                     [Kafka Producer]  
                     		↓
                     [Kafka Topic]
                            ↓
                     [Kafka Consumer]
                            ↓
                      ① DB INSERT (메시지 저장)       ← Oracle 동기 대기
                            ↓
                      ② DB SELECT (발신자 이름 조회)   ← Oracle 동기 대기
                      ③ DB SELECT (전송 시각 조회)     ← Oracle 동기 대기
                            ↓
                     [Redis Publish]
                            ↓
                     [RedisSubscriber]                         
                            ↓
                     [WebSocket 전송] → [상대방 화면]

위와 같은 구조로 메시지를 여러번 계속 전송하면 DB 응답을 기다리는 동안
WebSocket 전송이 블로킹이 되어, 사용자 입장에서는 메시지 딜레이가 생겼다.

이를 해결하기 위해서
Kafka 토픽에서 두 그룹으로 나눴다.

 chat-messages 토픽
          ↓
    ┌─────┴──────────────┐
    ↓                  ↓
  chat-group        chat-db-writer
  (화면 전송 담당)    (DB 저장 담당)

다음 사진처럼 각 그룹 조회해보면, LAG 이 0으로 나오는데, 이 숫자가 있으면 처리하지 못한 메시지 의 수를 의미한것으로 현재는 메시지 지연없이 잘 처리된 모습이다.

chat-group 부분에서는 기존에 DB 조회 및 업데이트를 처리했지만
Cache-Aside 방식으로 저장해놓은 Redis 캐시에서 데이터를 조회하고, 없으면 디비에서 조회한 후 캐시에 넣는 방식으로 구현

chat-db-writer 부분에서는 기존에 로직안에서 DB INSERT 작업을 진행했지만
Kafka 토픽 그룹 아이디를 하나 더 만들어서, 독립적으로 별도 스레드에서 DB INSERT를 진행
즉 쉽게말해서 chat-group 부분에서 로직이 실행되는동안 DB 대기를 할 필요가 없다.

채팅방에 입장했을 때 (메시지 읽음 처리) 는 기존에는 DB UPDATE 로 읽음처리 = 'Y' 로 변경했지만
1분마다 스케줄러를 통해서 자동으로 DB UPDATE 처리되도록 변경하였다.

Write-Behind : 데이터 저장 요청 시 캐시에만 기록하고, 일정한 시간 간격으로 배치 작업(batch)을 통해 데이터베이스에 기록하는 방식