브로커 비대화에 대한 반론
SQS, Kafka, RabbitMQ와 같은 전용 메시지 브로커는 상당한, 때로는 숨겨진 운영 오버헤드를 발생시킵니다. 별도의 인프라를 관리해야 하므로 프로비저닝, 배포, 모니터링 및 개별 서비스 확장에 따른 비용이 발생합니다. 이는 네트워크 지연 시간을 추가하고, 여러 분산 시스템을 통합하고 디버깅하는 개발자의 인지 부하를 결정적으로 증가시켜 스택에 불필요한 복잡성을 강요합니다.
기존 Postgres 데이터베이스는 브로커 비대화를 제거하는 강력하고 안정적인 대안을 제공합니다. ACID 준수와 검증된 트랜잭션 성능을 기반으로 하는 Postgres는 안정적인 큐잉을 위한 입증된 토대를 제공하며, 장애 시에도 데이터 무결성을 보장합니다. 수백만 개의 행과 초당 수천 건의 요청을 무리 없이 처리합니다. 예를 들어, 2개의 CPU와 2GB RAM 환경에서 테스트한 결과 9초 만에 100,000개의 메시지를 처리하여 초당 평균 11,100개의 메시지 처리 성능을 보였습니다.
PGMQ는 이 강력한 패턴을 경량의 단순한 확장 기능으로 공식화합니다. Postgres 내에서 직접 SQS와 유사한 API를 제공하여 큐 생성, 지연 옵션이 포함된 메시지 전송, 그리고 보장된 'exactly-once' 전달을 위한 가시성 제한 시간(VT) 기반의 메시지 소비를 가능하게 합니다. 즉, Rust, Python, TypeScript용 클라이언트 라이브러리를 갖춘 완벽한 기능의 메시지 큐를 스택에 새로운 서비스를 추가하지 않고도 사용할 수 있습니다.
5줄의 SQL로 큐 시작하기
순수 SQL로 큐를 생성하세요. pgmq.create('my_queue')를 호출하면 각 큐가 고유한 Postgres 테이블이 됩니다. pgmq.send('my_queue', '{"job_id": 123}')를 사용하여 메시지를 전송하세요. 이는 메시지를 JSON 형태로 Postgres 내에 직접 내장하여 데이터 모델을 단순화합니다.
pgmq.send()를 사용하여 예약 전송을 구현하세요. delay 매개변수(예: pgmq.send('my_queue', '{"task": "future"}', 30))를 추가하면 메시지가 큐에 들어가지만 30초 동안은 소비할 수 없는 상태로 유지되어, 외부 cron 서비스 없이도 고급 작업 스케줄링이 가능합니다.
pgmq.read('my_queue', 30, 1)을 통해 메시지를 소비하세요. 중요한 vt(visibility timeout, 가시성 제한 시간) 매개변수는 읽은 메시지를 지정된 시간(예: 30초) 동안 보이지 않게 만듭니다. 이는 exactly-once delivery를 보장합니다. 즉, 활성 창이 열려 있는 동안 다른 작업자가 동일한 메시지를 처리할 수 없습니다. VT 내에 처리되거나 삭제되지 않으면 메시지는 다시 큐에 나타납니다.
처리가 완료되면 메시지를 제거하세요. pgmq.delete('my_queue', message_id)를 사용하여 메시지를 영구적으로 삭제합니다. 또는 pgmq.archive('my_queue', message_id)를 사용하면 활성 큐에서 메시지를 삭제하고 전용 아카이브 테이블로 이동시켜, 감사나 재처리를 위한 기록 로그를 제공할 수 있습니다.
하지만 실제로 확장 가능한가요?
"하지만 확장성이 부족하지 않나요?"라고 반문할 수 있습니다. 이는 데이터베이스를 큐로 사용하는 것에 대한 흔한 비판입니다. 그러나 Postgres는 수백만 개의 행과 초당 수천 건의 요청을 무리 없이 처리합니다. PGMQ는 이러한 고유한 능력을 활용하여 분산 애플리케이션에서 인식되던 약점을 강점으로 전환합니다.
최근 스트레스 테스트를 통해 제한된 리소스 환경에서 PGMQ의 성능이 검증되었습니다. 연구진은 2개의 CPU와 2GB RAM만 할당된 Docker 컨테이너를 프로비저닝했습니다. 이후 PGMQ 큐에 100,000개의 메시지를 주입했습니다. 이 설정은 일반적인 라이브 서비스 환경을 반영하므로 결과의 신뢰도가 매우 높습니다.
100개의 동시 작업자가 단 9초 만에 100,000개의 메시지를 모두 처리했습니다. 각 작업자는 메시지를 배치 단위로 읽고, 기록하고, 삭제했습니다. 이는 초당 11,100개 이상의 메시지를 처리하는 통합 처리량을 의미합니다. 자세한 문서와 추가 예제는 공식 Postgres Message Queue (PGMQ) 저장소를 참조하세요.
이러한 성능은 사실상 모든 실제 애플리케이션에서 '확장성이 없다'는 통념을 확실하게 반증합니다. PGMQ는 Postgres가 메시지 큐로서 실행 가능할 뿐만 아니라 매우 뛰어난 성능을 발휘함을 입증하며, 대부분의 사용 사례에서 전용 브로커의 운영 오버헤드를 제거합니다. 인프라를 단순하게 유지하세요.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
애플리케이션에 PGMQ 통합하기
PGMQ를 애플리케이션 스택에 직접 통합하세요. 인기 있는 언어를 위한 강력한 클라이언트 라이브러리를 사용하여 원시 SQL을 넘어설 수 있습니다. 공식 지원을 통해 Python 및 Rust 통합이 가능하며, 관용적인 인터페이스를 제공합니다. 커뮤니티 주도 라이브러리는 PGMQ를 Ruby 및 Prisma와의 원활한 경험을 포함한 여러 TypeScript 버전으로 확장합니다.
최소한의 코드로 프로듀서를 구축하세요. Python 프로듀서는 큐 이름과 JSON 페이로드를 지정하여 간단한 send() 호출로 메시지를 보냅니다. 이는 pgmq.send() SQL 명령을 반영하여 데이터베이스 상호 작용을 추상화합니다.
작업자는 메시지를 효율적으로 소비합니다. 클라이언트 라이브러리의 read() 함수를 사용하여 가시성 제한 시간(VT)을 준수하면서 메시지 배치를 가져옵니다. 처리 후 delete() 또는 archive()를 호출하여 메시지를 제거함으로써 정확히 한 번 전달(exactly-once delivery)을 보장하고 재처리를 방지합니다. 이 패턴은 대용량 작업을 처리합니다.
Postgres 내에서 데이터 및 메시징 계층을 통합하면 인프라가 단순화됩니다. 별도의 메시지 브로커에 대한 운영 오버헤드를 제거하여 네트워크 지연 시간과 인지 부하를 줄입니다. 이러한 통합은 개발, 테스트 및 배포를 간소화하여 더욱 강력하고 유지 관리가 쉬운 시스템을 만듭니다.
자주 묻는 질문
PGMQ란 무엇인가요?
PGMQ (Postgres Message Queue)는 PostgreSQL을 위한 경량 확장 프로그램으로, 데이터베이스 내에서 직접 메시지 큐 기능을 활성화하여 AWS SQS, RabbitMQ 또는 Kafka와 같은 서비스의 대안을 제공합니다.
PGMQ는 어떻게 정확히 한 번 전달(exactly-once delivery)을 보장하나요?
PGMQ는 '가시성 제한 시간(visibility timeout)'을 사용합니다. 메시지를 읽으면 일정 기간 동안 다른 소비자가 볼 수 없게 됩니다. 소비자는 해당 시간 내에 메시지를 삭제하거나 보관해야 합니다. 실패할 경우, 메시지는 다른 소비자가 처리할 수 있도록 다시 나타나 데이터 손실을 방지합니다.
PGMQ가 프로덕션 수준의 트래픽을 처리할 수 있나요?
네. 벤치마크에 따르면 PGMQ는 저사양 하드웨어(예: 2-CPU 컨테이너)에서도 초당 11,000개 이상의 메시지를 처리할 수 있습니다. 이는 많은 대용량 분산 애플리케이션에 충분한 성능입니다.
Postgres를 메시지 큐로 사용할 때의 주요 이점은 무엇인가요?
주요 이점은 인프라 단순화입니다. 기존 데이터베이스를 활용함으로써 종속성을 줄이고, 운영 오버헤드를 낮추며, 대부분의 일반적인 사용 사례에서 성능 저하 없이 전체 기술 스택을 단순화할 수 있습니다.