Cloud Run: Rulează Task-uri Background Eficient cu Cron-Pull

Pe Cloud Run, costurile extrem de reduse vin la pachet cu un model agresiv de scalare până la zero. Este un comportament ideal pentru servicii web, dar o adevărată provocare dacă vrei să rulezi task-uri în fundal (background jobs). Cum poți executa aceste sarcini eficient, fără să plătești inutil pentru instanțe „always-on”? Răspunsul nu stă în abordarea clasică „fire-and-forget”, ci într-un tipar diferit: „cron-pull”.

Capcana „Fire-and-Forget” pe Cloud Run Services

Săptămâna aceasta, în timp ce lucram la un motor de conținut, primul meu instinct a fost să portez un pattern familiar dintr-un proiect anterior: workeri asincroni in-process cu execuție „fire-and-forget” după trimiterea răspunsului HTTP. Pe acea platformă mai veche (un serviciu de fact-checking), soluția funcționează impecabil de peste un an. Lansam task-urile cu asyncio.create_task și le lăsam să ruleze în fundal după ce clientul își primea răspunsul.

La review-ul de arhitectură am realizat însă o diferență critică: în vechiul proiect, serviciul rula cu min-instances=1, ceea ce însemna că aveam mereu o instanță activă cu CPU alocat. Pe Cloud Run, în schimb, modelul clasic de facturare la cerere (scale-to-zero) schimbă complet regulile jocului. Imediat ce serviciul trimite răspunsul HTTP, CPU-ul instanței este aproape imediat "throlled" spre zero. Drept urmare, task-urile asincrone îngheață la jumătatea execuției și sunt distruse când instanța este reciclată. În cazul nostru, asta a însemnat bugete irosite pe apeluri LLM eșuate și date rămase într-o stare inconsistentă.

Lecția a fost dură: soluția mea anterioară nu era neapărat corectă, ci doar „norocoasă” datorită instanței mereu active. Pe un serviciu Cloud Run cu scalare la zero, unde resursele pot fi terminate rapid dacă nu sunt necesare, modelul „fire-and-forget” este o rețetă sigură pentru eșec. Desigur, poți folosi opțiunea --no-cpu-throttling (CPU „always-on”), însă aceasta te trece la [facturare bazată pe instanță](https://cloud.google.com/blog/topics/developers-practitioners/use-cloud-run-always-cpu-allocation-background-work "Use Cloud Run "always-on" CPU allocation for background work."), nu pe cerere, crescând semnificativ costurile.

Cloud Run Jobs: Soluția dedicată pentru task-uri la finalizare

Google Cloud oferă Cloud Run Jobs ca soluție nativă exact pentru acest tip de scenarii. Spre deosebire de un serviciu web clasic care așteaptă și deservește cereri HTTP, un Cloud Run Job rulează doar task-urile sale și se încheie la finalizare. Este formatul ideal pentru procesări batch, generare de rapoarte sau migrări de date.

Un astfel de job poate rula până la 24 de ore și poate fi declanșat la cerere, pe bază de evenimente sau programat folosind Cloud Scheduler – aceasta fiind metoda recomandată și robustă pentru sarcini recurente pe Cloud Run.

Alternativa mea: Pattern-ul "Cron-Pull" pentru Cloud Run Services

Deși Cloud Run Jobs reprezintă standardul, pentru proiectul meu am preferat un model „cron-pull” implementat direct pe serviciul web existent, evitând complexitatea unei migrări. Soluția folosește serviciul nostru configurat cu scalare la zero, apelat periodic de Cloud Scheduler.

Iată cum funcționează mecanismul:

• Declanșarea: Cloud Scheduler trimite un request către un endpoint intern al serviciului la intervale regulate (de exemplu, la câteva minute).
• Execuția: Toată procesarea se desfășoară în interiorul request-ului HTTP generat de scheduler. Astfel, CPU-ul rămâne activ și garantat pe toată durata execuției.
• Procesarea în tranșe (Batching): La fiecare apel („tick”), serviciul preia un batch mic (la noi, maximum 3 joburi) și execută un singur pas din pipeline pentru fiecare.
• Persistența stării: După fiecare etapă parcursă, starea este salvată în PostgreSQL. Dacă execuția eșuează, nu pierdem tot progresul, ci putem relua exact de unde am rămas.
• Timp și costuri: Cloud Scheduler are o limită de timeout de 30 de minute pentru apelurile HTTP, în timp ce Cloud Run suportă până la 60 de minute. Pașii noștri sunt proiectați să se încadreze lejer sub limita de 30 de minute. Din punct de vedere financiar, cele aproximativ 25 de rulări lunare ne costă sub 1 EUR. Prin comparație, o instanță permanent activă (prin --no-cpu-throttling sau min-instances=1) ar fi ridicat costurile la 10-20 EUR pe lună – de peste 20 de ori mai mult pentru același volum de muncă.

Fiabilitate și Idempotență cu "Cron-Pull"

Principala provocare a acestui pattern este evitarea procesării duble în cazul în care Scheduler-ul declanșează instanțe concurente. Am rezolvat această problemă printr-un mecanism de rezervare (claim) atomic direct în baza de date:

• Folosim un singur UPDATE atomic cu clauză WHERE (verificăm dacă claimed_by IS NULL sau dacă ultimul heartbeat a expirat de mai mult de 15 minute).
• Returnăm jobul rezervat folosind instrucțiunea RETURNING.
• Această abordare elimină nevoia de SELECT FOR UPDATE SKIP LOCKED, facilitând testarea automată cu SQLite în pipeline-ul de CI.

În timpul execuției, actualizăm periodic un heartbeat pentru a semnala că jobul este activ. Eliberarea resursei (release) se face într-un bloc finally. Dacă un task eșuează brutal, acesta va rămâne blocat doar temporar: următorul „tick” al Scheduler-ului îl va prelua automat după ce depășește pragul de inactivitate de 15 minute. Pentru ca acest sistem să funcționeze corect, este obligatoriu ca sarcinile să fie idempotente (să producă același rezultat indiferent de câte ori sunt rulate).

Lecția fundamentală: Modelul de billing dictează arhitectura

Marea lecție din spatele acestei arhitecturi este că deciziile de design tehnic nu pot fi separate de modelul de billing. Pattern-urile de background work nu se portează copy-paste de la o platformă la alta; ele trebuie recalibrate în funcție de modul în care ești taxat. Pe serverless, întrebarea esențială nu este „cum rulez asta în fundal?”, ci „cine plătește pentru CPU după ce s-a trimis răspunsul HTTP?”.

Fie că alegi Cloud Run Jobs pentru procesări izolate, fie că mergi pe un tipar „cron-pull” integrat pe un serviciu existent, înțelegerea fină a alocării resurselor este singura cale de a construi sisteme robuste, scalabile și, mai ales, extrem de rentabile.