그외 대안 비교

RDS 주기 조회

브로커 없이 각 채팅 서버나 클라이언트가 RDS를 주기적으로 조회할 수는 있다. 예를 들어서 조회 간격이 동시 접속자 12.8만 명을 모두 5분마다 조회하는 구성이라면 평균 427조회/초를 추가하는 방식이다. 동시 접속자를 전부 5분마다 조회하는 것만 해도 평균 약 420조회/초가 RDS에 기본 부하로 들어간다. 또한 5분마다 조회하면 최악의 경우 메시지가 온 지 5분 뒤에야 알게 되기 때문에 실시간 채팅에는 맞지 않고 지연을 줄이려고 간격을 더 좁히면 기본 부하는 더 늘어난다.

Amazon SQS

SQS는 하나의 큐를 여러 서버가 나눠 갖는 구조라 이벤트 하나가 한 서버한테만 간다. 두 서버가 같은 알림을 다 받게 하려면 SNS같은 별도의 서비스로 받아서 서버마다 큐를 따로 두는 팬아웃 구성을 추가해야한다. 우리는 두 서버가 같은 Valkey 채널을 구독하면 팬아웃이 자동적으로 만족되기 때문에 SNS + SQS 조합은 사용하지 않았다.(https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html), SNS·SQS 팬아웃

Apache Kafka

Kafka를 사용이 가능하긴 하지만 같은 소비자 그룹에 속한 서버는 메시지 하나를 한 서버만 나눠 받으므 두 서버 모두 받으려면 서버마다 별도의 그룹이 있어여 한다. 채팅 메시지는 이미 RDS에 저장하고 있으므로 Kafka에 이벤트를 따로 저장하고 관리할 필요가 없다. 그래서 현재는 설정이 간단한 Valkey Pub/Sub을 선택했다.Apache Kafka 소비자 문서

Redis OSS

Redis OSS도 Pub/Sub을 지원 하지만 현재 서비스에는 Redis OSS에만 필요한 기능이나 기존 Redis 전용 의존성이 없다. Valkey는 Redis와 호환되는 Pub/Sub 기능을 제공하므로 현재 구현 방식을 그대로 사용할 수 있고 AWS 기준 동일 조건에서 Redis OSS보다 노드 비용도 20% 낮아 Valkey Pub/Sub을 선택했다.

Transactional Outbox 문제 고려

문제 )DB와 메시지 브로커는 서로 다른 시스템이므로 일반적인 DB 트랜잭션 하나로 두 작업을 함께 커밋하거나 롤백할 수 없음.

Application
   ├─ Database에 UPDATE
   └─ Message Broker에 PUBLISH
   
   - 메세지브로커와 DB는 서로 독립적으로 실행됨.
   - DB를 먼저 update 경우
   - 메세지를 먼저 보내는 경우 , 두 작업을 동시에 실행해도 원자성은 생기지 않음

원본 테이블과 Outbox 테이블에 같은 트랜잭션으로 저장한 뒤 Relay가 Outbox 데이터를 읽어 이미 존재하는 메시지 브로커에 이벤트를 발행.

현재 도입하지 않는 이유

발행이 유실되더라도 메시지 원본은 RDS에 저장되어 있고 사용자가 재접속할 때 마지막 수신 이후를 RDS에서 조회해 복구한다. 저장은 됐으나 발행이 실패한 메시지도 이 복구 조회가 채운다. Outbox 테이블과 polling이나 로그방식으로 outbox에서 read처리하는 것이 추가 관리 포인트이기 때문에 이미 RDS 복구 경로가 제공하는데 굳이 사용할 필요는 없다고 판단했다