GN⁺: Postgres 큐 기술 선택
(adriano.fyi)- Postgres Queue가 좋지만 주류가 아닌 이유: 다른 큐 기술들이 더 큰 확장성을 제공한다는 일반적인 생각때문
- webapp.io와 같은 회사들은 운영의 단순성, 유지 보수성, 그리고 친숙함을 확장성보다 중요시하며 Postgres 큐를 선택했음
- Postgres 큐 기술의 구성 요소
- 새로운 작업을 알리고 듣는 것(pub/sub)과 상호 배제(row locks)
- 이 두 가지는 2016년에 출시된 Postgres 9.5부터 제공
- Postgres를 이런 방식으로 사용하는 것이 '해킹적'이라는 업계의 일반적인 생각에 대해 반박하며, Postgres가 하찮은 큐 기술이 아니라고 주장
- 오랜 시간 실행되는 작업을 처리하기 위한 큐 도구로 Redis, Apache Kafka, RabbitMQ, Amazon SQS 등이 선택되어 왔음
- 기술 업계의 '규모'에 대한 집착을 비판하며, 단순성, 유지 보수의 용이성, 개발자의 인지 부하 감소를 희생하는 것에 대해 비판
- 기술 결정을 할 때, 현재 사용하고 잘 이해하고 있는 기술을 고려해야 한다는 저자의 제안
- 이미 사용 중이고 잘 이해된 '지루한 기술'을 선택하는 것을 권장
- '탈출구를 만들어 가는' 개념 소개, 작업 처리를 위한 응용 프로그램 코드는 큐에 대해 무관해야 한다는 의미
- 저자는 Postgres 큐 기술을 고려하고 '지루한 기술'을 기본 선택으로 하도록 다른 사람들을 격려하는 결론을 내림
Hacker News 의견
- Kafka의 간결함, 지속성, 고장 허용성이 인정받지만, 분산된 특성은 대부분의 사용 사례에서 복잡성을 더할 수 있다.
- Postgres 큐는 Redis 큐를 대체할 수 있지만, SQS 큐를 대체할 수는 없다.
- Postgres는 시스템이 가동된 이후 4억 이상의 이벤트를 처리하며, 하루에 약 100만 개의 이벤트를 처리하는 데 사용되었다.
- 일반 테이블을 사용하여 SELECT FOR UPDATE SKIP LOCKED를 사용하는 것은 모든 ORM/Query DSL 프레임워크에서 작동하는 간단한 접근 방식이다.
- LISTEN/NOTIFY를 사용하여 PostgreSQL을 pub/sub 버스로 사용하는 주요 단점은 LISTEN이 세션 기능이므로, 문장 수준의 연결 풀링과 호환되지 않는다.
- Postgres를 애플리케이션 큐로 사용하는 것은 트랜잭션성의 이점이 있어, 예약된 비동기 작업이 이로부터 혜택을 받는다.
- Postgres는 큐를 위해 확장할 수 있지만, AWS, GCP, Azure에서 SQS 또는 다른 큐 스택을 설정하는 것이 더 간단하고 목적에 맞게 제작되었다.
- Postgres는 github CI 인스턴스에서 1200jobs/s로 벤치마크를 실행하며, 추가 작업자를 통해 5000jobs/s로 확장되었다.
- Elixir의 Oban을 사용한 Postgres는 백그라운드 작업 주변의 트랜잭션 의미론이 편리하게 증명된 수십만에서 수백만 개의 작업을 일일이 처리하는 데 사용되었다.
- 47M 작업이 처리된 구현은 VACUUM을 위한 SKIP LOCKED, 지연된 작업, 재시도, 상태 업데이트, "적어도 한 번"과 같은 비싼 패턴을 구현하기 위한 인덱스가 있는 내구성 있는 저장의 이점을 강조한다.