서버리스

Cloud Run의 Temporal 서버리스 작업자: 수요에 앞서 작업자 확장

2026년 10월 22일

Sagar Randive

Product Manager

Aniruddh Chaturvedi

Engineering Manager

지금 Gemini 을 사용해 보세요

비즈니스 현장에서 Google AI를 만나기 위한 첫걸음

지금 시작하기

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

오픈소스 Temporal 실행 플랫폼은 최신 소프트웨어 인프라의 기반 레이어로 빠르게 자리 잡고 있으며, 특히 분산 시스템과 AI 에이전트 워크로드의 조정에 많이 사용되고 있습니다. 하지만 Temporal에서 작업자를 배포하고 확장하는 데는 고유한 어려움이 따릅니다. 작업자는 요청을 처리하는 대신 작업을 폴링하므로 요청 기반 서버리스 플랫폼과 잘 맞지 않을 수 있습니다. 이로 인해 Kubernetes 또는 VM에서 작업자 Fleet을 실행해야 하는 경우가 많으며, 이는 지속적 관리와 비용 지불을 필요로 합니다. 측정항목 파이프라인을 빌드하고 자동 확장 트리거를 조정해도 측정항목 지연으로 인해 확장이 버스트를 따라가지 못합니다. 배포할 때마다 업그레이드와 버전을 관리해야 하며, 큐에 작업이 있든 없든 컴퓨팅 비용을 지불해야 합니다.

Google Cloud는 바로 이러한 풀 기반 작업을 위해 Cloud Run 작업자 풀을 빌드했습니다. 인스턴스가 큐 또는 스트림에 연결하고 다음 항목을 가져와 처리합니다. 오늘부터 Temporal 오픈소스 플랫폼의 완전 관리형 버전인 Temporal Cloud가 이를 대신 확장해 드립니다. 현재 프리뷰 버전으로 제공되는 Cloud Run의 Temporal 서버리스 작업자를 사용하면 작업자를 작업자 풀로 배포할 수 있으며, Temporal은 태스크 큐의 작업에 맞게 풀의 크기를 조정합니다. 작업이 없을 때는 풀을 0으로 축소할 수 있습니다. 실행할 클러스터나 자동 확장 처리가 없으며, 작업자 코드는 동일하게 유지됩니다.

Cloud Run 작업자 풀이 Temporal과 연동되는 방식

작업자 풀은 지속적인 백그라운드 작업을 위한 Cloud Run의 리소스입니다. 공개 엔드포인트가 없으며 각 인스턴스에는 전체 수명 기간에 걸쳐 CPU가 할당되므로 Temporal 작업자가 실행되는 방식과 일치합니다. Temporal은 다음과 같이 Cloud Run 작업자 풀을 관리합니다.

Temporal 작업자는 프로젝트에서 Cloud Run 작업자 풀 인스턴스로 실행되며 Temporal Cloud에서 작업을 폴링합니다.
Temporal Cloud는 태스크 큐를 추적하고 사용자가 부여한 IAM 권한을 사용하여 Cloud Run Admin API를 통해 작업자 풀의 인스턴스 수를 설정합니다. Temporal은 어떤 경우에도 인스턴스에 대한 연결을 열지 않으므로 포트를 열거나 방화벽 규칙을 추가할 필요가 없습니다.
각 빌드 버전을 자체 Cloud Run 작업자 풀로 실행합니다. 이전 빌드의 작업자 풀은 해당 빌드에서 시작된 워크플로에 다시 필요할 때까지 인스턴스 없이 유지될 수 있습니다.

Temporal 작업자는 프로젝트, 서비스 계정, 네트워크에서 실행되며, 실행할 작업자 수는 Temporal이 결정합니다.

Temporal 서버리스 작업자로 빌드할 수 있는 항목

Cloud Run 작업자 풀과 Temporal 서버리스 작업자를 결합하면 다음과 같은 다양한 흥미로운 사용 사례를 실현할 수 있습니다.

자동 확장되는 에이전트 작업자: AI 에이전트는 LLM 추론 및 도구 호출의 다단계 체인을 실행합니다. 여기서 Temporal의 내구성 있는 실행과 Cloud Run 작업자 풀이 함께 작동합니다. Temporal 작업자는 즉시 가동되어 LLM 단계, 임베딩 또는 API 호출의 급증을 처리한 다음 큐가 비면 0으로 축소됩니다. 작업자는 키 없이 Google Cloud AI API에 액세스할 수 있습니다. 추론을 위해 GPU를 연결할 수도 있으며, GPU에 연결된 작업자 역시 0으로 확장됩니다. Temporal은 각 모델 및 도구 호출을 내구성 있는 활동으로 실행합니다. 작업자가 단계 중간에 사라지면 활동이 다른 작업자에서 재시도되고 워크플로는 계속됩니다.

장기 실행 워크플로: Temporal 워크플로는 무기한 실행될 수 있으므로 장기간에 걸쳐 실제 리소스의 상태를 추적하는 애플리케이션을 빌드할 수 있습니다. 이 패턴은 일반적으로 '항목 패턴'이라고 합니다. 워크플로가 일부 항목의 상태를 나타내기 때문입니다. 하지만 이러한 장기 실행 워크플로는 일반적으로 일관된 컴퓨팅 요구사항이 없습니다. 개별 단계 중 일부는 짧고 일부는 길며, 워크플로가 절전 모드 상태에서 사람이나 다른 시스템과 같은 외부 입력을 기다리는 경우도 있습니다. Cloud Run 작업자 풀은 이 패턴을 지원하는 유연한 컴퓨팅을 제공합니다. 개별 단계는 필요한 시간만큼 실행될 수 있으며, Temporal은 수행할 작업이 없을 때 작업자 풀을 자동으로 축소합니다.

버스트 일괄 작업: 작업자 풀은 인스턴스가 실행되는 동안에만 비용을 청구하므로 일괄 실행 사이에 유휴 상태인 작업자 풀은 인스턴스가 0개인 동안 비용이 발생하지 않습니다. 결제 실행이나 미디어 트랜스코딩과 같은 작업의 경우, Temporal은 배치가 도착하면 풀을 확장하고 큐가 비워지면 다시 축소합니다. 최대 인스턴스 수는 비용을 지불하는 인스턴스 수를 제한합니다. 이 용량을 초과하는 작업은 삭제되지 않고 큐에서 대기합니다.

Temporal 작업자에 Cloud Run 작업자 풀을 사용해야 하는 이유

이전에는 Cloud Run 서비스에서 Temporal 작업자를 실행하려면 몇 가지 우회적 방법을 사용해야 했습니다.

컨테이너가 포트에서 리슨할 것으로 서비스가 예상하기 때문에 HTTP 리스너 필요
인스턴스 기반 결제 방식으로 작업자가 요청 간에 CPU를 유지
최소 인스턴스 수가 필요해 서비스가 0으로 축소되지 않음

Cloud Run 작업자 풀에서 Temporal 작업자를 실행하면 더 이상 이러한 우회적 방법이 필요하지 않으며 다음과 같은 이점을 누릴 수 있습니다.

관리할 엔드포인트가 없습니다. 잠글 공개 URL이나 부하 분산기가 없으며 구현할 상태 점검 포트도 없습니다.
더 저렴한 가격으로 안정적인 CPU 사용량을 확보할 수 있습니다. 인스턴스가 유휴 상태가 되거나 제한되지 않습니다. Cloud Run은 인스턴스가 유휴 상태로 보인다고 해서 인스턴스를 삭제하지 않으므로 Temporal이 단독으로 풀 축소 시점을 결정합니다. 작업자 풀은 인스턴스 기반 결제 방식의 Cloud Run 서비스보다 vCPU 시간 및 GB 시간당 약 40% 저렴합니다.
버전 변동 없이 확장할 수 있습니다. 인스턴스 수를 변경해도 새 버전이 생성되지 않으므로 Temporal은 부하가 변경될 때마다 풀의 크기를 조절할 수 있습니다.

Temporal이 작업자 풀의 확장 및 버전 관리를 처리하는 방식

Temporal은 작업이 태스크 큐 백로그에 도착하는 시점과 작업자가 이를 처리하기 시작하는 시점 사이의 지연이라는 하나의 주요 신호를 사용하여 용량 추가 시점을 결정합니다. 이 지연 시간이 늘어나면 사용 가능한 작업자가 포화 상태에 이른 것입니다. 확장은 다음과 같이 이루어집니다.

서버 측 감지: Temporal 서버는 각 태스크 큐의 백로그-작업자 지연 시간을 추적합니다.
푸시 알림: 지연 시간이 트리거 조건을 초과하면 서버가 작업자 컨트롤러 인스턴스에 푸시 알림을 보냅니다.
프로비저닝: 작업자 컨트롤러가 작업자 풀에 용량을 추가합니다. 새 인스턴스는 작업을 폴링하기 전에 시작하고 연결하는 데 시간이 걸리므로 용량이 신호보다 지연됩니다.

Temporal은 여유 용량을 유지하므로 작업이 쌓인 후가 아니라 수요가 발생하기 전에 한발 앞서 풀이 확장됩니다. 수평 축소는 좀 더 보수적입니다. Temporal은 마지막으로 작업에서 사용 가능한 작업자를 찾지 못한 시점 이후 안정화 기간(기본값: 90초) 동안 대기하며, 연속적인 축소 사이에 일시중지합니다. Cloud Run의 구성 가능한 단계적 종료는 종료 시간을 10초에서 10분으로 연장합니다. 이렇게 하면 SIGTERM 인식 작업자가 작업을 완료하거나 체크포인트를 생성할 시간을 확보할 수 있습니다. 인스턴스 수는 사용자가 설정한 최솟값과 최댓값 사이로 유지됩니다. 유휴 기간 후 첫 번째 작업이 인스턴스가 시작될 때까지 기다릴 수 없는 경우 최솟값을 0보다 크게 설정합니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Tu66Q25.max-1800x1800.png

실행 중인 작업을 중단하지 않고 새로운 워크플로 코드를 배포하는 것은 어려운 일입니다. Temporal 워크플로는 스테이트풀(Stateful)이며 결정론적이기 때문에 실행 중에 코드를 교체하면 비결정론적 오류가 발생합니다. Cloud Run의 서버리스 작업자는 Temporal 작업자 버전 관리를 필수 적용하여 이 문제를 해결합니다. 조건부 분기를 사용하여 코드를 패치해서는 안 됩니다. 대신 각 작업자 배포 버전을 deploymentName 및 buildId로 식별되는 자체 작업자 풀 배포로 배포합니다. 별도의 작업자 풀을 사용하면 두 가지 문제가 해결됩니다.

특정 작업자 배포 버전에서 시작된 워크플로는 해당 버전에서 계속 실행되고 완료됩니다.
각 작업자 배포 버전은 개별적으로 확장 및 소모되어 컴퓨팅 지출과 사용률을 애플리케이션의 요구사항에 맞게 조정합니다. 기존 워크플로가 이전 작업자 배포 버전에서 완료되고 소모되면 기본 작업자 풀은 결국 자동으로 0으로 축소됩니다.

각 워크플로 유형에 대한 버전 관리 동작을 설정하거나 작업자 수준 기본값을 설정하세요.

PINNED: 워크플로가 시작된 작업자 버전(빌드 ID)을 유지하고 해당 버전에서 완료됩니다. 단기 실행 워크플로, 주문 처리, 다단계 API에 가장 적합합니다.
AUTO_UPGRADE: 워크플로를 출시하면 새로운 '현재' 또는 '대상' 작업자 배포 버전으로 이동합니다. 구독 결제 또는 몇 주에 걸쳐 실행되는 작업과 같은 장기 실행 워크플로에 가장 적합합니다.

작업자 버전 관리 구성에 대해 자세히 알아보려면 여기를 참고하세요.

시작하기

설정은 세 단계로 진행됩니다.

Temporal 작업자를 컨테이너화하고 컨테이너를 Cloud Run 작업자 풀로 배포합니다. 이때 풀 이름에 빌드 ID를 포함합니다. Temporal API 키와 같은 사용자 인증 정보를 Secret Manager에 보관합니다.
Temporal Cloud에 작업자 풀을 관리할 수 있는 권한을 부여하여 Temporal을 작업자 풀에 연결하면 작업자 풀을 확장할 수 있습니다.
Temporal에서 풀의 프로젝트, 리전, 이름을 가리키는 작업자 배포 버전을 만듭니다.