DBOS 주장: Durable Workflow, 오케스트레이터 말고 Postgres로 충분하다

• DBOS의 주장은 꽤 직설적이다. Durable workflow의 본질이 데이터베이스에 진행 상태를 저장하는 거라면, 굳이 별도 오케스트레이터 서버를 둘 필요가 있냐는 것

  • Durable workflow는 프로그램이 실행되는 동안 중간중간 진행 상황을 데이터베이스에 체크포인트로 남기는 방식
  • 서버가 죽거나 작업이 실패하면 마지막으로 완료된 단계부터 다시 이어갈 수 있음
  • 글에서는 게임 저장에 비유한다. 죽으면 처음부터가 아니라 마지막 저장 지점에서 다시 시작하는 느낌

• 기존 방식은 Temporal, Airflow, AWS Step Functions처럼 외부 오케스트레이터가 중앙에서 실행을 조율한다

  • 클라이언트가 워크플로우를 제출하면 오케스트레이터가 저장소에 레코드를 만들고 워커에 작업을 보냄
  • 워커가 한 단계를 끝낼 때마다 결과를 오케스트레이터로 돌려보냄
  • 오케스트레이터는 그 결과를 저장하고 다음 단계를 다시 워커에 배정
  • 워커가 죽으면 다른 워커에게 마지막 체크포인트부터 다시 실행하게 함

• DBOS는 이 구조가 근본적으로 과하게 복잡하다고 본다

  • 어차피 핵심은 단계 결과를 데이터베이스에 저장하는 것
  • 그렇다면 애플리케이션 서버가 Postgres와 직접 통신하면서 워크플로우를 실행하면 된다는 논리
  • 중앙 오케스트레이터를 하나 더 운영하는 대신, Postgres 테이블을 작업 큐와 상태 저장소처럼 쓰자는 얘기다

sequenceDiagram
    participant 클라이언트
    participant 애플리케이션서버
    participant 포스트그레스
    participant 다른서버
    클라이언트->>포스트그레스: 워크플로우 레코드 생성
    애플리케이션서버->>포스트그레스: 잠금으로 작업 가져오기
    애플리케이션서버->>포스트그레스: 단계 결과 체크포인트 저장
    애플리케이션서버--x포스트그레스: 실행 중 장애 발생
    다른서버->>포스트그레스: 마지막 체크포인트 조회
    다른서버->>포스트그레스: 남은 단계 실행 후 결과 저장

• Postgres 기반 durable workflow에서는 서버들이 Postgres를 통해 서로 조율한다
  • 클라이언트는 워크플로우 테이블에 실행할 작업을 추가
  • 애플리케이션 서버들은 그 테이블을 폴링하면서 가져갈 작업을 찾음
  • 잠금 구문을 써서 하나의 워크플로우가 정확히 하나의 워커에게만 잡히도록 제어
  • 여러 워커가 같은 워크플로우를 동시에 실행하려 하면 Postgres 무결성 제약으로 중복 체크포인트를 감지하고 물러남

• 확장성과 가용성도 Postgres 운영 문제로 환원된다

  • 워커 서버는 수평으로 더 붙이면 됨
  • 최대 처리량은 결국 데이터베이스가 워크플로우를 얼마나 빨리 처리하느냐에 달림
  • 글에서는 단일 Postgres 서버도 초당 수만 개 워크플로우를 처리하도록 수직 확장할 수 있다고 설명
  • 더 크게 가려면 CockroachDB 같은 분산 Postgres 계열이나 샤딩된 Postgres를 고려할 수 있음

• 가용성 측면에서도 “워커는 교체 가능하고, 상태는 Postgres에 있다”는 게 핵심이다

  • 특정 워커가 죽어도 다른 워커가 체크포인트를 읽고 이어받을 수 있음
  • 시스템 전체 가용성은 기본적으로 Postgres 가용성에 달림
  • Postgres는 스트리밍 복제, 자동 장애 조치, 관리형 서비스의 다중 가용 영역 배포 같은 해법이 이미 성숙해 있음

• 관측성은 꽤 강한 장점으로 나온다. 워크플로우와 단계 데이터가 테이블에 있으니 SQL로 바로 물어볼 수 있기 때문

  • 예를 들어 최근 한 달 동안 에러가 난 워크플로우를 찾는 쿼리를 SQL로 작성할 수 있음
  • 복잡한 필터링과 분석도 관계형 모델과 쿼리 최적화의 이점을 그대로 받음
  • 키-값 저장소 기반 오케스트레이터에서는 이런 분석 질의를 만들기 훨씬 까다로울 수 있다는 게 글의 주장

• 보안과 장애 지점 관점에서도 별도 오케스트레이터를 줄이는 게 이득이라는 논리다

  • 외부 오케스트레이터 방식에서는 오케스트레이터와 그 저장소가 둘 다 중요한 장애 지점이 됨
  • 오케스트레이터는 워크플로우와 단계 체크포인트를 처리하므로 민감한 애플리케이션 데이터에 접근할 가능성이 큼
  • 이미 애플리케이션이 Postgres에 의존하고 있다면, durable execution 도입을 위해 새 민감 인프라를 추가하지 않아도 된다는 게 장점

• 결론은 “Postgres 하나로 다 하자”라기보다 “이미 Postgres가 핵심 인프라라면 오케스트레이션도 거기에 얹을 수 있다”에 가깝다
  • 별도 오케스트레이터를 쓰면 제품 기능은 얻지만 운영할 시스템도 하나 늘어남
  • Postgres 기반 접근은 기존 데이터베이스의 확장성, 보안, 관측성, 운영 패턴을 재사용함
  • 백엔드 팀 입장에선 워크플로우 엔진 도입 전에 꼭 한 번 따져볼 만한 설계 선택지다

기술 맥락

• 여기서 선택한 건 워크플로우 실행 상태를 별도 오케스트레이터가 아니라 Postgres 테이블에 직접 저장하는 방식이에요. 왜냐하면 durable workflow의 핵심 데이터가 어차피 체크포인트라면, 그 체크포인트를 가장 잘 다루는 시스템이 데이터베이스이기 때문이에요.

• Temporal이나 AWS Step Functions 같은 외부 오케스트레이터는 워커 배정, 상태 저장, 재시도를 제품 기능으로 제공해요. 대신 오케스트레이터와 저장소를 새로 운영해야 하고, 그 시스템도 장애와 보안 감사의 대상이 되거든요.

• Postgres 방식은 애플리케이션 서버들이 같은 테이블을 보면서 작업을 가져가고, 잠금과 무결성 제약으로 중복 실행을 막는 쪽이에요. 왜 이게 가능하냐면 Postgres가 단순 파일 저장소가 아니라 트랜잭션, 잠금, 인덱스, SQL 분석을 이미 갖춘 조정 시스템이기 때문이에요.

• 이 설계가 특히 매력적인 팀은 이미 Postgres를 핵심 인프라로 운영하는 팀이에요. 새 플랫폼을 붙이는 대신 기존 백업, 복제, 장애 조치, 접근 제어 체계를 재사용할 수 있어서 운영 복잡도가 덜 늘어나요.

• 다만 워크플로우 처리량이 커질수록 병목은 Postgres로 모여요. 그래서 이 접근을 고를 때는 작업 테이블 인덱스, 폴링 패턴, 잠금 경합, 체크포인트 데이터 크기를 같이 설계해야 해요.