BullMQ로 알림 시스템 운영하기 5편 - 큐는 순서를 보장하지 않는다, 그룹 발송의 동시성
1만 건이 넘는 같은 분류의 알림톡을 그룹 하나로 묶어 보내는 기능을 붙이자, batch 서버가 청크로 잘라 던진 job들이 비동기로 소비되기 시작했다. 그 위에서 그룹은 하나, 발송은 한 번을 지키는 waiting-children의 자리와, 경합 다섯을 하나씩 막고 불변식으로 검증한 과정을 정리했다.
redis
글 9편
BullMQ로 알림 시스템 운영하기 2편 - Rate Limit과 그에 따른 설계
발송 한도는 5초당 100건이었고 우리 평균은 20 req/s였다. 종이 위에서는 한도 이내인데 429가 산발적으로 터졌다. fixed-window 두 개의 시작 시각이 어긋나 있었던 것이 원인이었고, 여기에 다른 팀과 서드파티 계정을 공유하고 있다는 사실이 겹치면서 발송 경로 자체를 다시 설계하게 됐다.
BullMQ로 알림 시스템 운영하기 1편 - BullMQ란
알림톡, 이메일, 푸시처럼 사용자에게 메시지를 보내는 기능은 어느 서비스에나 있다. 그런데 알림 발송을 단순한 HTTP 호출로 구현하다 보면 금세 한계에 부딪힌다. 이 문제들 각각은 다른 도구로도 풀 수 있다. 발송 모듈을 하나로 모으고, 함수 안에 rate limit을 두고, 스케줄러로 시점 분기를 만들고, 발송…
Kubernetes가 내 Pod를 죽이는 이유: Health Probe
Kubernetes는 Pod의 상태를 판단하기 위해 두 종류의 probe를 제공한다. "이 컨테이너가 살아있는가"를 확인한다. kubelet이 주기적으로 지정된 엔드포인트를 호출하고, 응답이 없거나 실패하면 컨테이너를 재시작한다. 앱이 데드락에 빠지거나, 메모리 릭으로 응답 불능 상태가 됐을 때 자동으로 복구시키는…
이론상 10만 QPS를 처리할 수 있는 티켓팅 시스템
유명인의 내한으로 이벤트를 열게 되었다. 선착순 1,000명에게만 주어지는 기회다. 티켓팅 신청을 웹 애플리케이션으로 받으려고 계획 중이며, 요구사항은 아래와 같다. 분산 락을 통해 락을 걸었다고 해보자. 혹시 완벽하게 동시성을 제어했다고 안심하고 있는가?
Lettuce 분산 락의 오해와 진실 (feat. RedisLockRegistry)
이전 글인 "좋아요 기능으로 알아보는 비관적 락"에서 이어지는 글이다. "Lettuce는 SpinLock만 지원한다"는 잘못된 정보를 바로잡고, Spring RedisLockRegistry의 PubSub Lock 설정으로 Redisson 없이도 효율적인 분산 락을 구현하는 방법을 소개한다. 구글에 "Redis 분산…
좋아요 기능으로 알아보는 비관적 락
이 글에서는 좋아요 기능을 구현하면서 발생하는 동시성 문제를 DB 락으로 해결하는 과정을 다룬다. 비관적 락의 동작 원리와 함께, 넥스트 키 락(Next-Key Lock)으로 인한 성능 저하 문제까지 살펴본다. 리뷰에 좋아요를 눌렀는지 여부를 판단하기 위해 ReviewLike 엔티티를 설계해보자. 좋아요를 추가할…
UPDATE 한 줄로 끝내는 동시성 문제
선착순 이벤트 시스템을 설계한다고 가정해보자. 요구사항은 아래와 같다. 100개의 재고가 있을 때 동시에 1,000명이 요청하면 어떻게 정확히 100명에게만 제공할 수 있을까? 이때 일반적으로 제시되는 해결책들은 아래와 같다.
분산 캐시 동기화 문제, Redis Pub/Sub으로 해결하기
우리 팀은 외부 시스템과의 연동 프로젝트를 진행하게 되었다. 요구사항은 간단해 보였다. "해당 일자에 주문이 가능한지 외부 API를 통해 확인할 수 있어야 한다." 하지만 실제로 구현해보니, 고객에게 정확한 정보를 전달하기 위해선 한 화면에서 4060건의 날짜별 배송 계획을 한 번에 조회해야 했다. 병렬 처리를…