Elixir의 Oban, 파이썬(Python)으로 이식! 데이터베이스 기반 작업 큐의 새로운 가능성?
Elixir의 Oban이 파이썬(Python)으로 이식되어, PostgreSQL 기반의 작업 큐(Job Queue)를 제공함
OSS 버전의 단일 스레드(Single-threaded) asyncio 실행 및 Pro 버전의 병렬 처리(Parallelism) 지원에 대한 논쟁이 있음
Celery, Sidekiq 등 기존 작업 큐 시스템과의 비교 및 PostgreSQL의 성능(Performance)에 대한 의문 제기
Pro 버전의 기능 제한(Feature Gating)에 대한 비판과 오픈소스(Open Source) 모델의 지속 가능성(Sustainability)에 대한 논의
Oban-py의 아키텍처 및 작동 방식
Oban-py는 PostgreSQL을 활용하여 작업 큐(Job Queue)를 관리하며, 데이터베이스 트랜잭션(Database Transaction)을 통해 작업의 원자성을 보장한다. 작업 삽입(Job Insertion) 시, `FOR UPDATE SKIP LOCKED` 구문을 사용하여 동시성(Concurrency)을 확보하고, `LISTEN/NOTIFY` 메커니즘을 통해 작업 처리 노드에 알림을 전송한다. 이러한 아키텍처는 외부 의존성을 최소화하고, 데이터베이스의 기능을 최대한 활용하는 설계로 평가받는다.
OSS vs Pro 버전의 기능 비교
Oban-py는 OSS(Open Source Software) 버전과 Pro 버전으로 나뉘며, Pro 버전은 병렬 처리(Parallelism), 벌크 작업(Bulk Operations), 스마트한 생존성 감지(Smarter Heartbeats) 등 다양한 기능을 제공한다. 특히, OSS 버전의 단일 스레드(Single-threaded) asyncio 실행은 CPU 바운드(CPU-bound) 작업에서 성능 병목 현상을 유발할 수 있다는 지적이 있다. 반면, Pro 버전은 이러한 제약을 해결하여 더 나은 성능을 제공한다.
PostgreSQL 기반 작업 큐의 장단점
Oban은 PostgreSQL을 작업 큐의 핵심으로 사용하며, 데이터베이스의 트랜잭션(Transaction) 기능을 활용하여 데이터 일관성을 보장한다. 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 작업과 관련된 데이터를 안전하게 관리할 수 있으며, 별도의 메시지 브로커(Message Broker) 없이 시스템을 구축할 수 있다는 장점이 있다. 하지만, PostgreSQL의 성능 한계와 쓰기 부하(Write Load)에 대한 우려도 존재하며, 대규모 작업 처리 환경에서는 성능 튜닝(Performance Tuning)이 필요할 수 있다.
Celery, Sidekiq 등 기존 솔루션과의 비교
Oban은 Celery, Sidekiq와 같은 기존 작업 큐 시스템과 비교되며, 특히 PostgreSQL을 활용하는 방식이 차별점으로 꼽힌다. Sidekiq의 개발자는 Oban의 파이썬 포팅을 축하하며, 언어별 전문성 확보의 어려움을 언급했다. Celery는 다양한 기능을 제공하지만, 설정 및 운영의 복잡성으로 인해 Oban의 단순함과 PostgreSQL 기반의 데이터 미저장 정책(Zero-Retention Policy)에 대한 매력을 느끼는 개발자도 있다.
