Master + Replica vs 단일 — BullMQ 발송 시스템 패턴 분석

1. Lock + Stalled job race condition — failover 동안 bull:*:stalled-check lock 이 끊김 → 두 worker 가 같은 job 처리 → 이메일 중복 발송 위험 (멱등성 강제 필수)
2. evalsha script cache loss — replica → master promote 시 script SHA 사라짐 → NOSCRIPT 에러 + 재로드 overhead
3. AOF rewrite + replica sync 충돌 — AOF rewrite 중 replica sync 가 delay → 일시적 lag
4. 오늘 발생한 OOM 은 HA 와 무관 — 메모리 한도 자체가 부족했던 것 (4G → 8G 해결). Sentinel 이 막아주지 않음.

Redis 공식 + BullMQ 공식 가이드 종합:

✅ 단일 Redis 인스턴스
   --appendonly yes
   --appendfsync everysec       # 1초 데이터 유실 허용
   --maxmemory 8gb              # 또는 워크로드 기반
   --maxmemory-policy noeviction
   --save 900 1                 # 보조 RDB snapshot
   restart: always              # docker restart on OOM
   oom_score_adj: -900          # OOM killer 보호
   mem_swappiness: 0            # swap I/O 절대 금지
   memswap_limit == mem_limit   # swap 영역 0

✅ EBS gp3 snapshot 1시간 cron    # 디스크 레벨 backup
✅ BullMQ idempotent job design    # at-least-once 보장
✅ Worker auto-reconnect            # Redis restart 동안 재연결

P0 단기 현재 변경 안정화

• 적용 완료: maxmemory 4G → 8G, 컨테이너 5G → 10G, mem_swappiness: 0, memswap_limit == mem_limit
• 1-2일 모니터 — OOM 재발 없는지, 메모리 추세 확인

P1 중기 (별도 PR)

• alpha 의 redis-replica + Sentinel x3 제거 → beta 와 같은 single 구조로 통일
• BullMQ retention 강화 — sequence-email completed 1000 → 100, repeatable scheduler pruning 확대 (현재 796개 stale)
• 다중 SES 계정 라운드로빈 fix — pool 확장 후 기존 enrollment 재할당 로직 추가. 현재 56만 delayed jobs 적체의 근본 원인.

P2 장기

• ElastiCache 또는 Dragonfly 검토 — 운영 부담 ↓ + 성능 ↑
• BullMQ → 분산 큐 (Kafka / SQS) 마이그레이션 검토 (트래픽 10배 시)

배포 실패 원인은 우리 PR 과 무관 — Redis 가 며칠 동안 100% full 상태였고, zero-downtime deploy 의 새 worker 시동 시 BullMQ Lua script enqueue 가 OOM 거부 → worker error → healthcheck 240s timeout.