BullMQ로 알림 시스템 운영하기 5편 - 큐는 순서를 보장하지 않는다, 그룹 발송의 동시성
같은 분류 알림 1만 건 이상을 그룹 하나로 보내자 청크 job이 비동기로 섞였다. waiting-children으로 그룹은 하나, 발송은 한 번을 지키고, 경합 다섯을 막아 불변식으로 검증했다.
redis
글 9편
BullMQ로 알림 시스템 운영하기 2편 - Rate Limit과 그에 따른 설계
발송 한도는 5초당 100건, 평균은 20 req/s로 종이 위에는 한도 안이었다. 그런데 429가 났고, 시작이 어긋난 fixed-window와 계정 공유가 겹치며 발송 경로를 다시 설계했다.
BullMQ로 알림 시스템 운영하기 1편 - BullMQ란
알림톡, 이메일, 푸시를 HTTP 호출로만 보내면 금세 한계에 부딪힌다. 1편에서는 발송 모듈, rate limit, 스케줄, 이력 저장을 BullMQ 하나에 맡기는 이유를 정리한다.
Kubernetes가 내 Pod를 죽이는 이유: Health Probe
Kubernetes는 liveness와 readiness 두 probe로 Pod 상태를 판단한다. 각 probe가 언제 컨테이너를 재시작하고 트래픽을 막는지 살피고, 스프링과 NestJS에서 설정하는 방법과 주의할 점을 정리했다.
이론상 10만 QPS를 처리할 수 있는 티켓팅 시스템
유명인의 내한으로 이벤트를 열게 되었다. 선착순 1,000명에게만 주어지는 기회다. 티켓팅 신청을 웹 애플리케이션으로 받으려고 계획 중이며, 요구사항은 아래와 같다. 분산 락을 통해 락을 걸었다고 해보자. 혹시 완벽하게 동시성을 제어했다고 안심하고 있는가?
Lettuce 분산 락의 오해와 진실 (feat. RedisLockRegistry)
"Lettuce는 SpinLock만 지원한다"는 잘못된 정보를 바로잡는다. Spring RedisLockRegistry의 PubSub Lock 설정으로 Redisson 없이도 효율적인 분산 락을 구현하는 방법을 소개한다.
좋아요 기능으로 알아보는 비관적 락
좋아요를 저장할 때의 동시성 문제를 비관적 락으로 푸는 과정이다. 락의 동작과, 없는 행 때문에 넥스트 키 락이 성능을 떨어뜨리는 지점까지 살펴본다.
UPDATE 한 줄로 끝내는 동시성 문제
선착순 이벤트 시스템을 설계한다고 가정해보자. 요구사항은 아래와 같다. 100개의 재고가 있을 때 동시에 1,000명이 요청하면 어떻게 정확히 100명에게만 제공할 수 있을까? 이때 일반적으로 제시되는 해결책들은 아래와 같다.
분산 캐시 동기화 문제, Redis Pub/Sub으로 해결하기
한 화면에 날짜별 배송 계획 40~60건을 외부 API로 불러와야 해서 응답이 느렸다. Redis 캐시와 로컬 캐시로 50~100배 빨라졌지만, 서버마다 어긋나는 로컬 캐시는 Redis Pub/Sub으로 맞췄다.