Postgres LISTEN/NOTIFY 확장성 분석

Postgres LISTEN/NOTIFY는 초당 60,000개의 메시지를 처리할 수 있으며, 이 기능이 확장되지 않는다는 일반적인 산업 내러티브에 도전합니다. 종종 저용량 신호 도구로 간주되어 무시되지만, 적절한 하드웨어와 구성이 있다면 외부 메시지 브로커 없이 높은 처리량의 알림 시스템으로 작동할 수 있음을 벤치마크가 보여줍니다.

하드웨어 및 구성 의존성

LISTEN/NOTIFY의 고성능 벤치마크는 기본 인프라에 크게 의존합니다. 60k msg/s를 달성하려면 상당한 수직 확장이 필요합니다. 한 벤치마크에서는 96코어와 384GB RAM을 가진 데이터베이스 서버를 사용했으며, 이는 modeste 하드웨어에서의 기본 설정과 대표되지 않음을 보여줍니다.

중요한 성능 요소는 다음과 같습니다:

• Vertical Scaling: 높은 코어 수와 높은 RAM은 최대 처리량을 달성하기 위해 필요합니다.
• Connection Management: 요청을 하는 연결의 위치와 수는 전체 지연 시간에 큰 영향을 미칩니다.
• Batching: 클라이언트가 명령을 배치하여 요청당 비용을 상쇄할 때 처리량이 향상됩니다.

기술적 제약 및 제한

처리량 측면에서의 확장성에도 불구하고, LISTEN/NOTIFY는 특정 사용 사례에 부적합할 수 있는 내재된 아키텍처적 한계를 가지고 있습니다:

• Payload Size Limit: 알림 데이터에 대한 하드 한계는 8,000바이트입니다. 이보다 더 많은 데이터가 필요한 경우, 시스템은 데이터를 테이블에 저장하고 NOTIFY를 통해 행 ID만 전송해야 합니다.
• Disk Contention: LISTEN/NOTIFY를 사용하여 커스텀 큐를 구축하면 기본 테이블에서 심각한 디스크 경합과 문제 있는 vacuum 실행이 발생할 수 있으며, 특히 AWS RDS와 같은 관리형 서비스에서 그렇습니다.
• Operational Complexity: Postgres 내부 위에 복잡한 큐 시맨틱을 구현하는 것은 엔지니어링 팀에 의해 "scary" 또는 비표준으로 perceived될 수 있으며, SQS나 Redis와 같은 전용 도구를 사용하는 것보다 유지 관리와 소유가 더 어려워질 수 있습니다.

확장성에 대한 비교적 관점

"확장"에 대한 산업 관점은 다양하며, 일부는 확장이 이진이 아닌 연속체라고 주장합니다. 많은 애플리케이션에 대해 LISTEN/NOTIFY의 상한은 충분 이상이며, 주요 장점은 추가 서비스를 관리하는 'DevOps 세금'을 피하는 것입니다.

"LISTEN/NOTIFY의 상한은 충분히 작아서 주의를 기울여야 하지만, 많은 프로젝트에 여전히 충분하며, DB의 나머지와의 통합, 가용성, 또 다른 서비스를 devops해야 하는 것이 아니며, 이는 옵션으로 간단히 무시해서는 안 되는 무언가입니다.

반대로, 일부는 극도의 확장성이 필요한 시스템이나 트래픽의 massive bursts에 취약한 시스템에 대해, 관계형 데이터베이스의 알림 시스템의 내재적 한계가 전용 메시지 브로커에 비해 너무 위험하다고 주장합니다.

트레이드오프 요약

Feature	LISTEN/NOTIFY	Dedicated Message Broker (SQS/Redis)
Infrastructure	Postgres에 통합	별도 서비스
Consistency	DB 데이터와의 강한 일관성	일반적으로 eventual consistency
Complexity	초기 설정이 낮고, 커스텀 큐 복잡성이 높음	초기 설정이 높고, 큐에 대한 운영 복잡성이 낮음
Payload Limit	8,000 bytes	크게 큼
Scaling Path	수직 (더 큰 서버)	수평 (클러스터/분산)