BullMQ로 알림 시스템 운영하기 3편 - 발송 이력을 어디에 쌓을 것인가
발송 이력을 어디에 저장할지에 대한 고민이다. 관계형 DB, RDB·S3 직렬·SNS fan-out·Firehose를 놓고 따진 트레이드오프를 정리했다.
블로그
BullMQ로 알림 시스템 운영하기 2편 - Rate Limit과 그에 따른 설계
발송 한도는 5초당 100건이었고 우리 평균은 20 req/s였다. 종이 위에서는 한도 이내인데 429가 산발적으로 터졌다. fixed-window 두 개의 시작 시각이 어긋나 있었던 것이 원인이었고, 여기에 다른 팀과 서드파티 계정을 공유하고 있다는 사실이 겹치면서 발송 경로 자체를 다시 설계하게 됐다.
RabbitMQ 이벤트로 리뷰 통계를 다시 집계한 이유
리뷰 변경 트랜잭션과 통계 계산을 분리하고 RabbitMQ 이벤트를 받은 Review Consumer가 처리 시점의 데이터를 다시 집계하도록 설계한 과정을 정리한다. 중복 이벤트에 증감값이 누적되지 않는 구조와 당시 남아 있던 유실 구간도 함께 살펴본다.
BullMQ로 알림 시스템 운영하기 1편 - BullMQ란
알림톡, 이메일, 푸시처럼 사용자에게 메시지를 보내는 기능은 어느 서비스에나 있다. 그런데 알림 발송을 단순한 HTTP 호출로 구현하다 보면 금세 한계에 부딪힌다. 이 문제들 각각은 다른 도구로도 풀 수 있다. 발송 모듈을 하나로 모으고, 함수 안에 rate limit을 두고, 스케줄러로 시점 분기를 만들고, 발송…
Kubernetes가 내 Pod를 죽이는 이유: Health Probe
Kubernetes는 Pod의 상태를 판단하기 위해 두 종류의 probe를 제공한다. "이 컨테이너가 살아있는가"를 확인한다. kubelet이 주기적으로 지정된 엔드포인트를 호출하고, 응답이 없거나 실패하면 컨테이너를 재시작한다. 앱이 데드락에 빠지거나, 메모리 릭으로 응답 불능 상태가 됐을 때 자동으로 복구시키는…