에이전트 시대를 위한 Workflows 제어 평면 재설계

기존 Workflows는 인간이 트리거하는 작업을 전제로 설계됐지만, 이제는 에이전트가 기계 속도로 워크플로를 생성하고 실행하는 시대가 됐다. 한 에이전트 세션이 수십 개의 워크플로를 동시에 띄우고, 여러 에이전트가 병렬로 움직이면 수 초 만에 수천 개 인스턴스가 만들어진다.

이에 따라 Cloudflare는 Workflows 제어 평면을 다시 설계해 다음 수준으로 확장했다.

• 50,000 concurrent instances
• 300 instances/second per account
• 2 million queued instances per workflow

V1에서는 계정 단위 Account Durable Object 하나가 모든 워크플로와 인스턴스의 등록, 생성, 갱신, 목록 조회를 담당했다. 이 구조는 간단했지만 고동시성 환경에서 병목이 됐고, 계정당 4,500 동시성 및 초당 100개 생성이라는 하드 캡으로 이어졌다.

V2의 핵심 원칙은 두 가지다. 첫째, 인스턴스의 존재 여부는 오직 개별 Engine이 진실의 원천이 되어야 한다. 둘째, Account는 최소한의 메타데이터만 보관하고, 동시에 처리할 수 있는 요청 수는 항상 제한 가능해야 한다.

이를 위해 두 개의 새 구성요소가 도입됐다. SousChef는 계정의 “2인자” 역할로, 특정 워크플로의 인스턴스 일부를 맡아 메타데이터와 생명주기를 분산 관리한다. Gatekeeper는 concurrency slot을 대여(lease) 방식으로 배분하는 장치로, 모든 SousChef가 계정의 슬롯을 효율적으로 나눠 쓰도록 만든다. 슬롯 요청은 1초 주기로 배치되어 Account로 가는 호출이 폭주하지 않으며, 오래된 인스턴스의 재개를 새 인스턴스보다 우선하는 공정성도 유지한다.

새로운 생성 경로는 더 단순해졌다. 제어 평면 버전을 확인하고, 캐시된 워크플로 정보가 없으면 Account에서 이름·고유 ID·버전을 가져와 저장한 뒤, 필요한 메타데이터만 Engine에 남긴다. 이후 백그라운드 작업과 Durable Object alarm이 인스턴스 시작을 보장해, hot-path는 빠르게 유지하면서도 at-least-once 모델로 신뢰성을 확보한다.

이 구조 덕분에 인스턴스 목록 조회는 cursor pagination과 맞아떨어질 만큼 일정한 성능을 보이고, 인스턴스 관련 작업은 Engine으로 직접 가서 네트워크 홉 1회로 끝난다. 또한 더 많은 인스턴스가 동시에 제시간에 동작하는지 감시하고, 늦어지면 바로 교정할 수 있게 됐다.

마이그레이션은 또 다른 난제였다. 이미 수백만 인스턴스와 수천 개 고객이 있었기 때문에, 무중단 전환이 필요했다. 결국 기존 AccountOld를 SousChef처럼 동작하게 만들어 상태를 유지한 채 새 아키텍처로 흡수했고, V1의 기술 부채로 인해 일부 queued instance에 Engine이 아직 없던 문제까지 함께 해결했다.

결과적으로 Workflows는 사람 중심의 제한된 동시성 모델에서, 에이전트와 자동화가 대량으로 생성하는 작업을 감당하는 분산 제어 평면으로 바뀌었다. Cloudflare가 말하는 핵심은 명확하다. 에이전트 시대의 워크플로는 더 이상 “적당히 늘어나는” 수준이 아니라, 수십만 개의 상태를 동시에 안전하게 조정하는 시스템이어야 한다.