pg_durable이 보여준 Postgres 내부 오케스트레이션, 재시도와 병렬 실행을 SQL로 다루는 방법

무엇을 제공하는 확장인가

pg_durable은 PostgreSQL 내부에서 재시도, 스케줄링, 병렬 fan-out, 조건 분기를 작은 SQL DSL로 표현하게 해 주는 확장으로 소개됐다. 핵심은 외부 메시지 브로커나 별도 오케스트레이션 서비스를 붙이지 않고도 Postgres와 백그라운드 워커만으로 작업 흐름을 지속 가능하게 관리한다는 점이다. 각 단계의 상태가 데이터베이스 안에 체크포인트로 기록되기 때문에 프로세스가 죽거나 연결이 끊겨도 중단 지점부터 다시 이어 갈 수 있다. 기사에서는 이를 crash-proof durable function이라는 표현으로 설명한다.

직접 구현할 때 드는 비용

같은 기능을 직접 만들면 생각보다 많은 부품이 필요하다. 기사에 따르면 병렬 집계를 수행한 뒤 결과를 모아 대시보드를 갱신하는 예시만 해도 300줄이 넘는 보일러플레이트가 들어간다. 큐 설정, 워커 폴링, 메시지 처리, 상태 추적, 에러 처리, 재시도, 단계 조정, 변수 전달, 정리 함수까지 모두 별도 코드와 테이블로 관리해야 한다. next_run 계산을 위해 외부 cron 파서까지 붙여야 하는 경우도 있다. 결국 애플리케이션이 비즈니스 로직보다 작업 제어 코드를 더 많이 떠안게 되는 구조다.

pg_durable이 줄이는 복잡성

이 확장을 쓰면 동일한 병렬 집계와 후속 작업을 단일 DSL 호출로 표현할 수 있다고 기사에서는 설명한다. 여러 작업을 fan-out으로 동시에 실행하고, 모두 끝난 뒤 후속 단계를 이어 붙이며, 실패 시 재시도와 복구를 엔진이 맡는다. 상태가 모두 Postgres에 남기 때문에 운영자는 별도 분산 시스템 로그를 맞춰 보지 않고도 현재 어디까지 실행됐는지 확인할 수 있다. 이미 트랜잭션과 데이터 일관성을 Postgres에 의존하는 팀이라면 실행 상태까지 같은 시스템 안에서 다룰 수 있다는 점이 큰 장점이다.

도입 판단에서 볼 포인트

물론 모든 워크플로를 데이터베이스 안으로 밀어 넣는 것이 정답은 아니다. 매우 복잡한 장기 워크플로나 서비스 간 대규모 이벤트 처리에는 전용 엔진이 더 적합할 수 있다. 그럼에도 기사에서 강조하는 메시지는 분명하다. 상당수 내부 배치와 데이터 파이프라인은 굳이 별도 인프라를 늘리지 않아도 Postgres 내부 기능만으로 안정적으로 운영할 수 있으며, 그 과정에서 직접 짜야 하는 제어 코드와 장애 복구 코드를 크게 줄일 수 있다는 것이다. 데이터베이스를 단순 저장소가 아니라 실행 상태를 보존하는 조정 계층으로 활용하려는 팀에게 흥미로운 선택지가 될 수 있다.

원문 보기

출처: GeekNews 원문 링크