PostgreSQL, DLQ로 부활?
이벤트 기반 시스템(Event-Driven Systems)에서 실패한 이벤트를 처리하기 위해 PostgreSQL을 DLQ로 활용하는 방법 제시
Kafka 대신 PostgreSQL을 DLQ로 사용함으로써 쿼리 및 재처리(Reprocessing)의 용이성을 확보
FOR UPDATE SKIP LOCKED 구문을 활용하여 동시성 문제를 해결하고, ShedLock을 통해 재시도(Retry) 메커니즘 구현
MySQL을 DLQ로 사용한 사례, PostgreSQL을 메시지 큐(Message Queue)로 활용하는 등 다양한 의견 제시
PostgreSQL DLQ 아키텍처의 핵심 요소
PostgreSQL을 DLQ로 활용하는 핵심은 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 실패한 이벤트를 안전하게 저장하고 관리하는 것이다. 특히, `JSONB` 타입으로 원시 이벤트 데이터를 저장하여 스키마 변경에 유연하게 대응하고, `status`, `retry_count`, `retry_after` 필드를 통해 이벤트의 생명주기를 명확하게 관리한다. 또한, `FOR UPDATE SKIP LOCKED` 구문을 활용하여 동시성 문제를 해결하고, ShedLock을 통해 재시도(Retry) 메커니즘을 구현하여 안정성을 확보했다.
FOR UPDATE SKIP LOCKED의 활용과 성능 고려 사항
PostgreSQL의 `FOR UPDATE SKIP LOCKED` 구문은 여러 인스턴스에서 동시에 DLQ 테이블에 접근하여 이벤트를 재처리할 때 경합 조건(Race Condition)을 방지하는 핵심 기술이다. 이 구문을 사용하면, 이미 다른 트랜잭션에 의해 잠긴 행을 건너뛰고, 잠금 대기 시간을 설정하여 재시도 폭주(Retry Storm)를 방지할 수 있다. 하지만, 과도한 잠금 대기 시간은 전체 시스템의 성능 저하를 유발할 수 있으므로, 적절한 튜닝이 필요하다.
DLQ 시스템의 장점과 단점
PostgreSQL을 DLQ로 사용하면, 기존 데이터베이스 인프라를 재활용하여 운영상의 복잡성을 줄이고, SQL 쿼리를 통해 실패 원인을 쉽게 파악할 수 있다는 장점이 있다. 하지만, DLQ 테이블이 과도하게 커지면 쿼리 성능 저하 및 데이터베이스 부하 증가를 야기할 수 있다. 따라서, 적절한 인덱싱 전략과 데이터 미저장 정책(Zero-Retention Policy)을 통해 DLQ 테이블의 크기를 관리하고, 모니터링 시스템을 구축하여 이상 징후를 조기에 감지해야 한다.
커뮤니티의 다양한 의견과 대안
커뮤니티에서는 MySQL을 DLQ로 사용한 사례, PostgreSQL을 메시지 큐(Message Queue)로 활용한 사례 등 다양한 의견이 제시되었다. 특히, Oban과 같은 PostgreSQL 기반의 메시지 큐 솔루션은 별도의 인프라 구성 없이 DLQ 기능을 제공하여, 시스템의 단순성을 유지할 수 있다는 장점이 있다. 하지만, 이러한 접근 방식은 특정 규모 이상의 트래픽에서는 성능상의 제약이 있을 수 있으며, 데이터 격리 아키텍처(Data Isolation Architecture)를 위한 추가적인 고려가 필요하다.
