Valkey Pub/Sub 선택 근거와 크기 계산

선택 근거

서비스는 1:1 채팅만 제공하며, 방당 평균 10건의 메시지를 주고받는다고 가정한다. 두 채팅 서버가 같은 채널을 구독하면 발신 서버는 수신자가 어느 서버에 접속했는지 알 필요가 없다. 두 서버는 이벤트를 받은 뒤 각자의 로컬 연결만 검사한다. ElastiCache Pub/Sub 사용 사례

Valkey Pub/Sub은 온라인 알림 경로이고 RDS는 메시지 원본이다. RDS에 메시지를 저장한 뒤 이벤트를 발행한다. 발신자의 재전송에는 클라이언트 요청 ID를 사용해 중복 저장을 막고, 발신자에게 주는 저장 완료 응답과 상대방의 전달·읽음 상태를 구분한다. Pub/Sub은 최대 1회 전달이므로 재구독 및 앱 복귀 때 RDS에서 누락분을 조회한다. DB 저장 후 이벤트 발행 전의 장애까지 일정 시간 안에 복구해야 한다면 트랜잭셔널 아웃박스 등을 추가로 검토한다. Valkey Pub/Sub, AWS 트랜잭셔널 아웃박스

메시지량

월간 사용자 42만 명이 각각 평균 15.6개 채팅방에 참여하고, 1:1 방의 두 참여자를 각각 센 값이라고 가정한다. 월 고유 채팅방은 420,000 × 15.6 ÷ 2 = 3,276,000개다. 방당 10건이면 월 메시지 수는 3,276,000 × 10 = 32,760,000건, 30일 평균은 12.64건/초다. 하루 신규 고유 방은 평균 109,200개다.

오후 8~10시에 사용자 45%가 앱을 사용한다는 수치만으로 메시지의 45%가 해당 시간에 발송된다고 단정할 수 없다. 메시지 45%가 그 시간대에 집중된다는 추가 가정을 둘 경우 약 68.25건/초는 그 2시간의 평균이며 순간 피크는 아니다. 순간 피크는 실제 분당·초당 메시지 지표로 검증한다.

브로커와 캐시 크기 분리

용도	계산 기준	현재 추정
Pub/Sub 브로커	메시지 장기 보관 없음. 구독 연결, 일시적 출력 버퍼, CPU·네트워크 부하를 측정	저장 메시지 용량을 산입하지 않음
최근 메시지 캐시	실제 상주 방 수 × 방당 직렬화된 최근 10건 크기	건당 130B를 가정하면 방당 원시 데이터 1,300B
접속 정보	Valkey에 별도로 저장하는 경우에만 계산	128,000 × 200B = 25.6MB 원시 데이터

캐시 예시로 하루 신규 고유 방 109,200개가 모두 상주하고 방당 1,300B를 쓴다면 약 142MB다. 이틀치 신규 방을 모두 보관하면 약 284MB다. 이는 실제 캐시 상주 방 수가 아니라 가정에 따른 예시다. 캐시 TTL, 이전 방의 재방문, 이미지 메시지 메타데이터, 키·자료구조·직렬화 오버헤드를 측정해야 한다. WebSocket 세션을 채팅 서버에만 보관한다면 위 25.6MB는 Valkey 메모리에서 제외한다.

ElastiCache 구성

다른 AZ에 기본 노드 1대와 복제 노드 1대, 총 cache.t4g.small 2대를 둔다. Multi-AZ 자동 장애 조치는 기본 노드 장애 시 복제 노드를 승격하지만, 끊긴 Pub/Sub 구독의 이벤트를 복구하지는 않는다. 애플리케이션은 재연결·재구독과 RDS 누락 조회를 수행한다. 복제 노드는 같은 데이터를 보관하므로 노드 메모리를 두 배로 합산해 사용 가능 용량으로 보지 않는다. AWS Multi-AZ

cache.t4g.small의 표시 메모리는 노드당 1.37GiB다. 예약 메모리와 실제 키 오버헤드를 제외해야 하므로, 이 유형은 최종 확정값이 아니라 부하 테스트 대상이다. CPU 크레딧, 메모리, 연결 수, 출력 버퍼, 장애 조치 중 알림 지연을 확인한 뒤 확정한다. AWS 노드 사양, 예약 메모리 지침