Açık kaynak Temporal çalıştırma platformu, özellikle dağıtık sistemlerde ve AI agent iş yüklerinde orkestrasyon için modern yazılım altyapısının temel katmanlarından biri haline geliyor. Ancak Temporal’da worker’ları deploy etmek ve ölçeklemek kendine özgü zorluklar içeriyor. Worker’lar istek karşılamak yerine görev için polling yapıyor; bu yüzden istek tabanlı serverless platformlar pek uygun düşmüyor. Sonuç genelde sürekli yönetilip ücreti ödenen Kubernetes ya da VM üzerindeki worker filoları oluyor. Bir metrik hattı kuruluyor, autoscaling tetikleyicileri ayarlanıyor, ama metrik gecikmesi yüzünden ölçekleme ani yük artışlarının gerisinde kalıyor. Kuyrukta iş olsa da olmasa da compute ücreti ödeniyor.
Google, Cloud Run worker pools‘u tam da bu tür pull tabanlı işler için geliştirmişti: instance’lar bir kuyruğa ya da stream’e bağlanıyor, sıradaki öğeyi alıp işliyor. Artık Temporal’ın tamamen yönetilen sürümü Temporal Cloud bu havuzları sizin yerinize ölçekleyebiliyor. Preview aşamasındaki Temporal Serverless Workers ile worker’lar bir Cloud Run worker pool olarak deploy ediliyor ve Temporal havuzu task queue’lardaki işe göre boyutlandırıyor. İş olmadığında havuzu sıfıra indirebiliyor. Çalıştırılacak bir cluster ya da autoscaler yok, worker kodu da aynı kalıyor.
Cloud Run worker pools ve Temporal nasıl birlikte çalışıyor
Worker pool, Cloud Run’ın sürekli arka plan işleri için sunduğu kaynak. Public bir endpoint’i yok ve her instance’a ömrü boyunca CPU ayrılıyor; bu da bir Temporal worker’ının çalışma şekline uyuyor. Temporal, Cloud Run worker pool’larını şöyle yönetiyor:
- Temporal worker’larınız projenizde Cloud Run worker pool instance’ları olarak çalışıyor ve görevler için Temporal Cloud’a polling yapıyor.
- Temporal Cloud task queue’ları takip ediyor ve verdiğiniz IAM izinleriyle Cloud Run Admin API üzerinden havuzun instance sayısını ayarlıyor. Temporal instance’larınıza hiçbir zaman bağlantı açmıyor; port açmanız ya da firewall kuralı eklemeniz gerekmiyor.
- Her build sürümü kendi Cloud Run worker pool’u olarak çalışıyor. Eski bir build’in havuzu, o sürümde başlamış bir workflow ona tekrar ihtiyaç duyana kadar sıfır instance’ta bekleyebiliyor.
Kısacası worker’lar sizin projenizde, sizin service account’unuzla ve sizin network’ünüzde çalışıyor; kaç tanesinin çalışacağına Temporal karar veriyor.
Neler yapılabilir
Otomatik ölçeklenen agentic worker’lar. AI agent’lar çok adımlı LLM akıl yürütme ve tool çağrı zincirleri çalıştırıyor. Temporal worker’ları LLM adımları, embedding’ler ya da API çağrılarındaki ani yükler için anında ayağa kalkıyor ve kuyruk boşalınca sıfıra iniyor. Worker’lar Google Cloud AI API’lerine anahtarsız erişebiliyor; inference için GPU da eklenebiliyor ve GPU’lu worker’lar da sıfıra inebiliyor. Temporal her model ve tool çağrısını dayanıklı (durable) bir activity olarak çalıştırıyor; bir worker adım ortasında kaybolursa activity başka bir worker’da yeniden deneniyor ve workflow devam ediyor.
Uzun süren workflow’lar. Temporal Workflow‘ları süresiz çalışabiliyor ve gerçek dünyadaki kaynakların durumunu uzun süre takip eden uygulamalar kurmayı sağlıyor (“Entity Pattern”). Bu workflow’ların compute ihtiyacı tutarlı değil: bazı adımlar kısa, bazıları uzun, bazen de workflow bir insandan ya da başka bir sistemden girdi bekleyerek uyuyor. Worker pool’lar adımların gerektiği kadar sürmesine izin veriyor ve iş olmadığında Temporal havuzu küçültüyor.
Ani batch işleri. Worker pool’lar sadece instance’lar çalışırken ücretlendiriliyor; batch’ler arasında sıfırda bekleyen bir havuz hiçbir maliyet oluşturmuyor. Fatura çalıştırmaları ya da medya dönüştürme gibi işlerde Temporal havuzu batch’ler geldikçe büyütüyor, kuyruk boşalınca küçültüyor. Maksimum instance sayısı ödeyeceğiniz instance sayısını sınırlıyor; kapasiteyi aşan görevler düşürülmüyor, kuyrukta bekliyor.
Neden Cloud Run services değil de worker pools
Daha önce Temporal worker’larını Cloud Run services üzerinde çalıştırmak bazı geçici çözümler gerektiriyordu: servisler container’ın bir port dinlemesini beklediği için bir HTTP listener, worker’ların istekler arasında CPU’yu koruması için instance tabanlı faturalama ve servisin sıfıra inmemesi için minimum instance. Worker pool’larda bunlara gerek kalmıyor:
- Yönetilecek endpoint yok: Kilitlenecek public URL ya da load balancer, uygulanacak health-check portu yok.
- Daha düşük fiyata sabit CPU: Instance’lar boşta beklemiyor ya da kısılmıyor. Cloud Run instance’ları boşta göründükleri için kaldırmıyor, havuzun ne zaman küçüleceğine sadece Temporal karar veriyor. Worker pool’ların liste fiyatı, instance tabanlı faturalanan Cloud Run servislerine göre vCPU-saat ve GB-saat başına yaklaşık yüzde 40 daha düşük.
- Revision karmaşası olmadan ölçekleme: Instance sayısını değiştirmek yeni bir revision oluşturmuyor; Temporal havuzu yük değiştikçe istediği sıklıkta yeniden boyutlandırabiliyor.
Temporal ölçeklemeyi ve sürümlemeyi nasıl yönetiyor
Temporal kapasite ekleme kararını tek bir ana sinyale bakarak veriyor: bir görevin task queue birikimine düşmesiyle bir worker tarafından alınması arasındaki gecikme. Bu gecikme artıyorsa mevcut worker’lar doymuş demektir. Temporal sunucusu bu gecikmeyi her task queue için takip ediyor, eşik aşıldığında worker controller’a push bildirimi gönderiyor ve controller havuza kapasite ekliyor. Yeni instance’ların başlayıp bağlanması zaman aldığı için kapasite sinyalin biraz gerisinden geliyor; Temporal yedek kapasite tuttuğu için havuz görevler birikmeden, talepten önce büyüyor.
Küçültme daha temkinli. Temporal, bir görevin müsait worker bulamadığı son andan sonra bir stabilizasyon süresi bekliyor (varsayılan 90 saniye) ve ardışık küçültmeler arasında duraklıyor. Cloud Run’ın yapılandırılabilir graceful shutdown özelliği kapanma süresini 10 saniyeden 10 dakikaya kadar uzatıyor; böylece SIGTERM’i dikkate alan worker’lar işlerini bitirmek ya da checkpoint almak için zaman buluyor. Instance sayısı belirlediğiniz minimum ve maksimum arasında kalıyor. Boşta geçen bir sürenin ardından gelen ilk görev bir instance’ın başlamasını bekleyemiyorsa minimumu sıfırın üzerine ayarlamak gerekiyor.
Çalışan yürütmeleri bozmadan yeni workflow kodu deploy etmek zor; Temporal workflow’ları durumlu ve deterministik olduğu için kod çalışma ortasında değişirse non-determinism hataları oluşuyor. Cloud Run’daki Serverless Workers bunu Temporal Worker Versioning’i zorunlu tutarak çözüyor. Kodu koşullu dallarla yamamak yerine her Worker Deployment Version, bir deploymentName ve buildId ile tanımlanan kendi worker pool’u olarak deploy ediliyor. Bir sürümde başlayan workflow’lar o sürümde tamamlanıyor; her sürüm ayrı ayrı ölçeklenip boşaltılıyor ve eski sürümün havuzu, workflow’ları bitince otomatik olarak sıfıra iniyor.
Her workflow türü için ya da worker düzeyinde varsayılan olarak bir sürümleme davranışı seçiliyor:
- PINNED: Workflow başladığı worker sürümünde (Build ID) kalıp orada bitiyor. Kısa süren workflow’lar, sipariş işleme ve çok adımlı API’ler için uygun.
- AUTO_UPGRADE: Workflow, yeni sürüm yayıldıkça yeni “Current” ya da “Target” Worker Deployment Version’a geçiyor. Abonelik faturalama ya da haftalarca süren görevler gibi uzun workflow’lar için uygun.
Ayrıntılar için worker versioning dokümantasyonuna bakabilirsiniz.
Nasıl başlanır
Kurulum üç adımdan oluşuyor:
- Temporal worker’ınızı container’a alıp Build ID’yi havuz adına ekleyerek Cloud Run worker pool olarak deploy edin. Temporal API anahtarı gibi kimlik bilgilerini Secret Manager’da tutun.
- Temporal Cloud’a worker pool’u yönetme izni vererek Temporal’ı havuza bağlayın.
- Temporal’da havuzun projesini, bölgesini ve adını gösteren bir Worker Deployment Version oluşturun.
Temporal Serverless Workers on Cloud Run preview aşamasında; API’ler ve yapılandırma kararlı sürümden önce değişebilir. Başlamak için Serverless Workers on Cloud Run dokümanını, kurulum kılavuzunu ve CPU, bellek, GPU ve network seçenekleri için Cloud Run worker pools sayfasını inceleyebilirsiniz.
Temporal worker’larını serverless çalıştırmak bugüne kadar hep biraz zorlamaydı; port dinleyen sahte bir HTTP listener ve sıfıra inmeyen minimum instance’lar bunun en bilinen işaretleriydi. Bu entegrasyon iki sorunu birden çözüyor: ölçekleme kararını metrik gecikmesi olan bir autoscaler yerine kuyruğu en iyi bilen Temporal’a bırakıyor ve sürümleme sorununu her build’e ayrı havuz vererek zarif şekilde ele alıyor. Yüzde 40’a yakın daha düşük birim fiyat ve sıfıra inebilme, özellikle ani yük alan AI agent iş yükleri için cazip. Preview olduğu ve sadece Temporal Cloud ile çalıştığı, kendi barındırdığınız Temporal sunucusu için geçerli olmadığı da unutulmamalı.
