Postgres LISTEN/NOTIFY, 60K/s 달성 비결은?
by DD
2일 전
조회수 2
Postgres LISTEN/NOTIFY의 낮은 확장성(Poor Scalability)에 대한 통념을 반박하며 실제 최적화 사례를 제시함
글로벌 락(Global Lock) 병목 현상을 버퍼링 및 배치 트랜잭션(Buffering and Batching Transactions)으로 해결하여 초당 60,000건 쓰기 달성
커뮤니티에서는 '확장성'의 정의와 실제 적용 시 고려사항에 대한 논의가 활발함
Postgres LISTEN/NOTIFY의 글로벌 락(Global Lock) 병목
원문에서는 Postgres의 LISTEN/NOTIFY 기능이 트랜잭션 커밋 시 발생하는 전역 배타적 잠금(Global Exclusive Lock)으로 인해 초당 약 2.9K 쓰기 성능에 그친다고 지적합니다. 이 잠금은 알림 전송 순서를 보장하기 위해 필요하지만, 개별 쓰기 작업마다 잠금을 획득하고 해제하는 과정에서 동시성(Concurrency)을 심각하게 저해하여 실제 CPU나 IOPS 사용률은 낮으면서도 처리량이 제한되는 현상을 야기한다고 설명합니다.
버퍼링 및 배치 트랜잭션(Buffering and Batching)을 통한 최적화
성능 개선을 위해 알림을 메모리에 버퍼링했다가 주기적으로 일괄 처리(Batch Flush)하는 방식을 제안합니다. 이를 통해 개별 쓰기 작업 시 글로벌 락 경합을 최소화하고, 그룹 커밋(Group Commit)과 같은 Postgres의 최적화 기법을 활용하여 초당 60,000건의 쓰기 성능과 밀리초 단위의 지연 시간(Latency)을 달성했다고 밝힙니다. 다만, 이 방식은 데이터 미저장 정책(Zero-Retention Policy)으로 인해 프로세스 충돌 시 알림 누락 가능성이 있어 폴백(Fallback) 메커니즘이 필요하다고 덧붙입니다.
