Postgres에서 내구성 워크플로 구축하기

1 day ago 3

내구성(Durable) 워크플로는 실행 상태를 데이터베이스에 체크포인트해, 충돌 뒤 마지막 완료 단계부터 복구하게 함
Temporal, Airflow, AWS Step Functions식 외부 오케스트레이션은 중앙 오케스트레이터와 저장소를 추가해 복잡성이 커짐
Postgres 기반 구조는 애플리케이션 서버가 워크플로 테이블을 폴링하고 단계 출력을 직접 저장해 복구 가능하게 만듦
여러 서버는 잠금과 무결성 제약으로 중복 실행을 막고, 확장성·가용성·관측성 문제를 Postgres 해법으로 다룸
단일 Postgres는 초당 수만 개 워크플로까지 수직 확장 가능하며, 복제·멀티 AZ·SQL 분석을 그대로 활용할 수 있음

내구성 워크플로의 기본 모델

내구성 워크플로는 프로그램 실행 중 진행 상태를 데이터베이스에 주기적으로 체크포인트로 저장해, 충돌이나 실패 뒤 마지막 완료 단계부터 복구할 수 있게 하는 방식임
비디오 게임의 저장과 불러오기처럼, 프로그램 진행 상황을 정기적으로 “저장”하고 충돌 뒤 마지막 체크포인트에서 “불러오는” 모델로 볼 수 있음
일반적인 구현은 Temporal, Airflow, AWS Step Functions 같은 외부 오케스트레이션 시스템임
외부 오케스트레이션에서는 내구성 프로그램을 여러 단계로 구성된 워크플로로 작성하고, 중앙 오케스트레이터가 실행을 조율함

클라이언트가 워크플로를 제출하면 오케스트레이터가 데이터 저장소에 레코드를 만들고, 실행을 위해 워커에 디스패치함
워커가 각 단계를 완료할 때마다 결과를 오케스트레이터로 보내고, 오케스트레이터는 그 출력을 데이터 저장소에 체크포인트한 뒤 다음 단계를 디스패치함
워커가 충돌하거나 실패하면 오케스트레이터가 해당 워크플로를 다른 워커에 다시 디스패치하고, 마지막 체크포인트 단계부터 시작하게 함
이 구조는 워크플로 상태를 데이터베이스에 저장한다는 핵심 아이디어에 별도 오케스트레이터 서버를 더해 복잡성을 키움

내구성 워크플로의 핵심이 데이터베이스에 프로그램 상태를 체크포인트하는 것이라면, 별도 오케스트레이터 서버 없이 데이터베이스 자체를 오케스트레이터로 쓰는 편이 더 단순하고 효율적임
Postgres는 인기, 확장성, 풍부한 생태계 때문에 내구성 워크플로를 구축하기에 적합한 선택지임
Postgres 기반 내구성 워크플로 시스템에서는 애플리케이션 서버가 중앙 오케스트레이터를 거치지 않고 Postgres와 직접 통신해 워크플로를 실행함
클라이언트는 Postgres의 워크플로 테이블에 항목을 생성해 실행을 제출하고, 애플리케이션 서버는 해당 테이블을 폴링해 워크플로를 디큐하고 실행함
서버는 워크플로를 실행하는 동안 각 단계의 출력을 Postgres에 체크포인트하고, 실행 중인 서버가 충돌하거나 실패하면 다른 서버가 체크포인트에서 워크플로를 복구함

애플리케이션 서버들은 Postgres를 통해 조율할 수 있으므로 중앙 오케스트레이터가 워크플로를 워커에 디스패치할 필요가 없음
서버들은 Postgres 테이블에서 협력적으로 워크플로를 디큐하고, 잠금 절 같은 메커니즘으로 각 워크플로가 정확히 하나의 워커에 의해 디큐되도록 보장할 수 있음
단계 출력 체크포인트도 오케스트레이터가 아니라 워커가 직접 Postgres에 기록함
여러 워커가 같은 워크플로를 동시에 실행하려 하면, Postgres의 무결성 제약이 체크포인트 시점에 중복 작업을 감지해 물러나게 할 수 있음
중앙 오케스트레이터를 Postgres나 다른 데이터베이스로 대체하면 확장성, 가용성, 관측성, 보안 같은 문제를 잘 알려진 Postgres 네이티브 해법으로 다룰 수 있음

Postgres 기반 내구성 실행에서는 워크플로와 단계가 Postgres 테이블에 체크포인트되므로, 해당 체크포인트를 스캔해 워크플로를 실시간으로 모니터링하고 실행을 시각화할 수 있음
거의 모든 워크플로 관측성 질의를 SQL로 표현할 수 있다는 점에서 Postgres가 강점을 가짐
지난 한 달 동안 오류가 발생한 모든 워크플로를 찾는 질의처럼, 복잡한 필터링과 분석 작업을 SQL로 선언적으로 표현할 수 있음
이런 방식은 Postgres의 관계형 모델과 수십 년간의 질의 최적화 연구를 활용하기 때문에 가능함
인기 있는 외부 오케스트레이터가 사용하는 키-값 저장소처럼 더 단순한 데이터 모델을 가진 많은 시스템은 같은 수준의 SQL 기반 분석 지원을 제공하지 못함
워크플로와 단계 데이터를 Postgres 테이블에 저장하고 빠른 분석 질의를 위한 보조 인덱스를 추가하면, 내구성 실행에서 효율적인 관측성을 얻을 수 있음

외부 오케스트레이터를 사용하는 내구성 실행에서는 오케스트레이터와 그 데이터 저장소가 모두 단일 장애 지점이 됨
오케스트레이터와 데이터 저장소가 워크플로 실행을 직접 조율하므로, 둘 중 하나라도 다운되면 전체 애플리케이션을 사용할 수 없게 됨
이들은 워크플로와 단계 체크포인트를 처리하고 저장하므로 민감한 애플리케이션 데이터에 접근할 가능성이 있으며, 민감한 인프라처럼 강화, 접근 제어, 감사가 필요함
Postgres 기반 내구성 실행에서는 유일한 장애 지점이 Postgres 자체이며, 모든 워크플로 데이터가 Postgres에 직접 저장되고 다른 시스템을 통과하지 않음
애플리케이션이 이미 Postgres에 의존하고 있다면, 내구성 실행 도입은 새로운 장애 지점을 추가하지 않고 보호해야 할 새 공격 표면도 만들지 않음
데이터베이스는 이미 핵심 인프라이므로, 오케스트레이션을 위해 새 핵심 인프라를 추가하기보다 기존 데이터베이스를 재사용하는 편이 더 타당함