technologytutorial
Cloud Run — szerverless konténerek
Mit tanulsz
- cloud-runBevezető
01 — Bevezetés
Mi a Cloud Run?
A Cloud Run egy szerverless konténer-futtató. Te megírsz egy webszervert (Node.js, Python, Go, Java, .NET, Rust, bármi), Docker-konténerbe csomagolod, telepíted — a Google ad neki egy publikus URL-t, kezeli az autoskálázást, az HTTPS-tanúsítványt, a hibakezelést. Ha senki sem használja, nullára áll, és nem fizetsz semmit. Ha jönnek a kérések, magától indul új példány.
Az alapfilozófia
A klasszikus szerveres modellben üzemelteted a gépet — frissítések, OS-patchek, terheléselosztó konfiguráció, autoskálázási csoportok, monitoring. Ez sok munka, és sokszor felesleges, mert a forgalom egyenetlen. A szerverless világ ezt veszi át: te csak a kódot adod, a platform mindent mást.
A Cloud Run szerverless megközelítése három alapelven áll:
- Konténer mint egység — bármilyen nyelv, bármilyen futtatókörnyezet, ami tudja a HTTP-t és figyel egy porton. Nincs vendor-lock futtatókörnyezetbe (mint az AWS Lambdánál a Node 20 vagy Python 3.12), bármit becsomagolhatsz Docker-be.
- Scale-to-zero — ha nincs forgalom, nincs futó példány, nem fizetsz semmit. Ezt nem mindegyik szerverless platform tudja, és pont ez teszi a Cloud Run-t alkalmassá kis-közepes projektekre is.
- Per-másodperc számlázás — 100 ms-os pontossággal mérik a futási időt, és csak azt kell fizetni. Egy ritkán hívott háttérfeladat lehet 0 forint havonta.
Mit ad a dobozból?
- HTTPS-végpont — a Cloud Run-tól kapott URL automatikusan HTTPS, érvényes tanúsítvánnyal. Saját domainnel könnyen összekötheted.
- Autoskálázás — 0-tól ezerig, magától. Ezt nem te konfigurálod, nem te írod a HPA-szabályokat — egyszerűen működik.
- Verziózás és traffic splitting — minden telepítés egy új revízió, és a forgalmat százalékosan oszthatod el a régi és az új között. Tökéletes a canary deploy-hoz.
- Beépített IAM — a Google IAM rendszerébe integrált, finom-szemcsés jogosultságkezeléssel.
- Logging és monitoring — a Google Cloud Logging-ba és Monitoring-ba magától integrálódik, semmit nem kell beállítanod.
- Több régiós telepítés — egyetlen paranccsal több régióba telepíthetsz, és a forgalmat globális load balancer osztja szét.
A Knative örökség
A Cloud Run a Knative nyílt szabványra épül, ami a Kubernetes-en futó szerverless workload-okat definiálja. Ez gyakorlati előny: ha egyszer szeretnéd lehozni a Cloud Run-ról saját üzemeltetésű Kubernetes-re (vagy felfelé az Anthos-ra), a kódod és a config-od jelentős része átvihető. Vendor-lock kisebb, mint az AWS Lambdánál.
Mit tanulsz
- cloud-runKözéphaladó
02 — Négy futási modell
Services, jobs, worker pools, instances
A Cloud Run nem egy egyetlen funkció: négy különböző futási modell van alatta, és mindegyik más-más feladatkörre van kihegyezve. A megfelelő választás a probléma természetén múlik, nem a divaton.
Cloud Run services — a HTTP-szerver
Ez az eredeti és leggyakoribb modell. Egy webszerver fut, ami HTTP-kéréseket fogad, és válaszol. A Cloud Run a forgalom alapján skáláz, nullától felfelé. Egy példány több párhuzamos kérést is kezelhet (alapból 80, akár 1000 is). A számlázás kérés-alapú: csak akkor fizetsz, amikor egy kérés ténylegesen fut.
- Tipikus felhasználás: REST API, GraphQL szerver, weboldal-backend, webhook-fogadó, Next.js / Nuxt SSR, NestJS API.
- Maximális futási idő: 60 perc kérésenként.
- Skálázás: 0-tól tetszőleges példányszámig (alapból max 100).
Cloud Run jobs — a batch-feladat
A jobs egy másik modell: nem fogad HTTP-kérést, hanem egyszer lefut és véget ér. Cron-feladatra, adat-átalakításra, e-mail-batch küldésre, ML-modell fine-tunolásra való. Egy job-nak több taska lehet, amik párhuzamosan futhatnak.
- Tipikus felhasználás: napi statisztika-számolás, adatbázis-migráció, batch ML-inferencia, video-átkódolás, riport-generálás, archiválás.
- Maximális futási idő: 24 óra taskonként.
- Skálázás: task-szintű párhuzamosság (akár 10 ezer párhuzamos task).
Cloud Run worker pools — a sor-feldolgozó
2024-ben jelent meg, és a tartós háttér-feldolgozásra való. Itt nincs HTTP-trigger — a konténer „mindig fut", és magától olvas Pub/Sub-ból, Cloud Tasks-ből, vagy bármilyen más sorból. Mint egy worker process, ami sosem kerül leállításra.
- Tipikus felhasználás: e-mail-küldő-szolgáltatás, video-feldolgozási sor, hosszan futó ML-feladatok, big tömeges üzenet-feldolgozás.
- Számlázás: instance-alapú — a teljes futási idő alatt fizetsz, nem csak a kérésnél.
- Skálázás: állandó példányszám, magad konfigurálod.
Cloud Run instances — az egyedi konténer
A 2026-os Next '26 konferencián jelentették be: hozzáférés a Cloud Run alapprimitívjéhez. Egy konkrét konténert futtatsz egyetlen paranccsal, és a Cloud Run kezeli az életciklust. Tartós háttér-ügynökökhöz tervezve (pl. AI-agentek), ahol az állapot a lemezen tárolódik (Cloud Storage volume mount). Jelenleg preview.
Egy összevető táblázat
| Modell | Trigger | Számlázás | Tipikus eset |
|---|---|---|---|
| services | HTTP-kérés | kérés + futási idő | API, weboldal-backend |
| jobs | kézi indítás vagy cron | teljes futási idő | batch, riport |
| worker pools | (nincs — magától fut) | instance-óra | sor-feldolgozás, async munka |
| instances (preview) | kézi indítás | instance-óra | AI-agent, long-running |
Mit tanulsz
- cloud-runKözéphaladó
03 — Telepítés
Telepítés — forráskódból vagy Dockerfile-ból
A Cloud Run-ra kétféleképpen lehet telepíteni: vagy közvetlenül a forráskódból (a platform magától épít belőle konténert), vagy a saját Dockerfile alapján. Az első kényelmes, a második rugalmas — mindkettőnek megvan a helye.
Telepítés forráskódból (buildpacks)
Ha nincs Dockerfile-od, a Cloud Run a Google Cloud Buildpacks-szel maga csomagolja a kódot. Felismeri a nyelvet (
package.json → Node.js, requirements.txt → Python, stb.), és magától felépíti a megfelelő konténert. Nem tökéletes minden esetre, de egyszerű projekteknél nagyon gyors.terminalbash
# Deploy a NestJS app from source
$ gcloud run deploy my-api \
--source . \
--region europe-west1 \
--allow-unauthenticated
# Output: Service URL: https://my-api-abc123.run.app
Telepítés Dockerfile-ból
Ha precízen kontrollálni akarod a konténer tartalmát (specifikus base-image, többlépcsős build, system-csomagok), Dockerfile-t írsz, és a Cloud Build vagy a helyi Docker felépíti. Ezt egy parancs telepíti:
terminalbash
# Build and push to Artifact Registry
$ gcloud builds submit --tag europe-west1-docker.pkg.dev/PROJECT/repo/my-api
# Deploy from the built image
$ gcloud run deploy my-api \
--image europe-west1-docker.pkg.dev/PROJECT/repo/my-api \
--region europe-west1 \
--memory 512Mi \
--cpu 1 \
--concurrency 80
Egy egyszerű Dockerfile
Dockerfileplaintext
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:22-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
# Cloud Run tells you which port to listen on via PORT
ENV PORT=8080
CMD ["node", "dist/main.js"]
A PORT változó
A Cloud Run egy környezeti változón keresztül adja meg, melyik porton kell figyelni — alapból 8080. Mindig olvasd ki a
process.env.PORT-ot a kódodban, ne hardkódolj. Ha a portod nem stimmel, az app indul, de a Cloud Run nem tudja átirányítani hozzá a forgalmat, és időtúllépés lesz.CI/CD Cloud Build-del
A Google Cloud Build a Cloud Run testvérszolgáltatása: egy
cloudbuild.yaml-t adsz, és minden git-push-ra magától épít, tesztel, telepít. GitHub-os projekt is köthető hozzá pár kattintással. Egy átlagos pipeline lefut 2-4 perc alatt, és nincs külön CI-server-üzemeltetés.Mit tanulsz
- cloud-runKözéphaladó
04 — Skálázás
Autoskálázás és párhuzamosság
A Cloud Run autoskálázása az egyik legfontosabb tulajdonsága. A platform magától indít új példányokat, ha nő a forgalom, és magától le is állítja őket, ha csökken. Két beállítás határozza meg a viselkedést: a párhuzamosság és a min/max példányszám.
Hogy működik a skálázás?
A Cloud Run egy egyszerű elven működik: minden példány egyszerre n párhuzamos kérést kezelhet. Ha jön egy új kérés, és minden meglévő példány tele van, akkor új példány indul. Ha egy példány egy időre üresen marad, leállítják.
| Beállítás | Mit jelent | Alapérték |
|---|---|---|
--concurrency | Egy példány hány kérést kezelhet egyszerre | 80 |
--min-instances | Minimum példány, akkor is, ha nincs forgalom | 0 |
--max-instances | Maximum példány csúcsforgalomban | 100 |
--cpu-throttling | Ha kérés nincs, a CPU lecsökken (alapból be) | be |
Párhuzamosság — mire figyelj
Az alapértelmezett 80 párhuzamos kérés a legtöbb stateless webszervernek elég. Néhány esetben érdemes alacsonyabbra állítani:
- Memóriaintenzív kérés — ha minden kérés sok memóriát fogyaszt (pl. nagy fájlt tölt be), 80 párhuzamossal együtt kifuthatsz a memória-keretből. Ekkor 10-20 párhuzamossal jobban jársz.
- CPU-intenzív kérés — ha minden kérés sokat számol, akkor 80 párhuzamos kérés egy 1 vCPU-s gépen rosszabb teljesítményt ad, mint 4 párhuzamos. A throughput jobb lesz, ha minden kérés gyorsabban végez.
- Adatbázis-kapcsolat-pool — ha az app pl. PostgreSQL-hez kapcsolódik, és a kapcsolat-pool max 10, akkor 80 párhuzamos kérés egy részénél időtúllépés lesz.
Min instances — a hideg indulás ellenszere
Ha azt akarod, hogy a Cloud Run sose induljon hidegen, állítsd be
--min-instances 1-re. Egy 512 MiB-os példány havi költsége kb. 11-12 USD ($0.5/nap). Egy felhasználó-szembesülő API-nál sokszor megéri a látható UX-javulásért. Egy belső admin-funkciónál (amit napi 5-ször használnak) felesleges.Mit tanulsz
- cloud-runKözéphaladó
05 — Hideg indulás
Hideg indulás — az eltűnő szerver ára
Minden szerverless platform legfontosabb gyengesége. Ha senki sem használja az appot, a platform leállítja a példányt, és a következő kérésnél új példány indul — ennek az indulási ideje a hideg indulás. A Cloud Run-nál ez relatív gyors (0.5-2 másodperc), de szükségtelenül lassítható.
Mi történik egy hideg indulásnál?
- Konténer-példány készítés — a Google létrehoz egy új konténert.
- Konténer indítás — a base-image betöltődik, az ENTRYPOINT lefut.
- Az alkalmazás indul — Node.js, Python, JVM, .NET CLR feláll, dependenciák betöltődnek.
- A HTTP-szerver figyelni kezd a porton — a Cloud Run ekkor küldi az első kérést.
A klasszikus optimalizációk
- Kicsi base-image —
node:alpine~50 MB,nodeteljes ~1 GB. Az alpine gyorsabban töltődik be. - Karcsú dependenciák — minden import a fájl tetején lassítja az indulást. Csak amit tényleg kell.
- Lazy loading — egy ritkán használt nehéz könyvtárat (pl. PDF-generáló, Sharp) dynamic import-tal töltsd be.
- JVM-optimalizáció — Java appoknál a hideg indulás jelentős. AOT-fordítás GraalVM-mel vagy a Spring Boot 3 native image-szel sokszor 5x-ös gyorsulás.
- Min instances — egyszerűen 1 (vagy több), ha az UX kritikus.
Konkrét számok
Egy Node.js app (NestJS, ~80 dependeniával) hideg indulása a Cloud Run-on 1.0-2.5 másodperc között szokott lenni. Egy Java Spring Boot app 8-15 másodperc — itt a JVM lassú indulása dominál. Egy Go app 100-300 ms, mert a binary önmagában elindul. Egy GPU-s konténer (NVIDIA L4) 5 másodperc, beleértve a driver-betöltést.
Az „instance-based billing" mód
Egy újabb opció: a Cloud Run service-eket beállíthatod úgy, hogy ne kérés-alapon, hanem instance-alapon számlázzanak. Ez azt jelenti, hogy egy példány a teljes életciklusa alatt számláz (akkor is, ha nincs kérés), de cserébe sosem áll le (CPU is mindig elérhető, nem throttled). Ez WebSocket-szerű hosszú kapcsolatokra való.
Mit tanulsz
- cloud-runHaladó
06 — GPU és disk
GPU támogatás és ephemeral disk
2025 közepétől a Cloud Run-on NVIDIA L4 GPU is elérhető (GA), 2026-ban pedig az NVIDIA RTX PRO 6000 Blackwell is — a 70 milliárd paraméteres LLM-ek inferencia-szintű futtatásához. A 2026-os Next-en bejelentett ephemeral disk pedig a memóriánál nagyobb átmeneti tárhelyet ad.
GPU a Cloud Run-on
A klasszikus megoldás GPU-hoz egy állandóan futó VM volt — még akkor is fizetted, ha senki sem használta a modelled. A Cloud Run megfordította ezt: GPU-t per-másodpercen fizetsz, és ha senki sem hívja az AI-modelled, a példány nullára áll.
| GPU | VRAM | Min CPU/RAM | Ár (Tier 1) |
|---|---|---|---|
| NVIDIA L4 | 24 GB | 4 vCPU / 16 GiB | ~$0.67/óra |
| NVIDIA RTX PRO 6000 Blackwell | 96 GB | 20 vCPU / 80 GiB | magasabb (kérésre) |
Mire jó GPU a Cloud Run-on?
- LLM-inferencia — Llama, Mistral, Gemma modellek futtatása valós idejű chatre. A 70B+ paraméteres modellek a Blackwell-en futnak.
- Stable Diffusion-szerű kép-generálás — bursty forgalom, nullára skálázás.
- Embedding-generálás — szöveget vektorokká alakítás, RAG-rendszerekhez.
- Video-feldolgozás — átkódolás, thumbnail-generálás, GPU-gyorsított stream-elés.
- Fine-tuning — egy modell saját adaton való finomhangolása (Cloud Run jobs-szal, nem szervizzel).
Ephemeral disk (preview, 2026)
Eddig a Cloud Run konténerek csak a memóriában tudtak átmeneti adatot tárolni — ami egy kép-feldolgozó szolgáltatásnál (Sharp, FFmpeg) hamar kifuthatott a keretből. A 2026 áprilisában bejelentett ephemeral disk per-példány átmeneti lemezt ad, ami a példány élete alatt létezik, és magától eltűnik a leállás után. Nem perzisztens (ahhoz Cloud Storage kell), de pl. egy 5 GB-os MP4 átkódolásához tökéletes.
Cloud Storage volume mount
A persistent fájlrendszer-szerű hozzáférés a Cloud Run-on a Cloud Storage volume mount-on keresztül lehetséges (FUSE). Ezt egy parancs beállítja, és onnan a konténer egy bucket tartalmát úgy látja, mint egy mappát. Streaming-szerű hozzáférés, néhány korláttal — de jól illeszkedik a hosszan futó AI-agentekhez, amik a Cloud Run instances modellben futnak.
Mit tanulsz
- cloud-runKözéphaladó
07 — Költség
Költség — hogyan számláz?
A Cloud Run árazása transzparens, de több dimenzióból áll össze. CPU-másodperc, memória-másodperc, kérés-szám, és (ha van) GPU. Egy kis app havi költsége nulla lehet, egy közepes pár dollár, egy nagy is csak akkor drágul, ha tényleg sokat dolgozik.
Az ingyenes keret
A Cloud Run havi ingyenes szabad-keretet ad minden számlázási fiókra:
- 2 millió kérés havi.
- 360 ezer GiB-másodperc memória.
- 180 ezer vCPU-másodperc CPU-idő.
- 1 GiB egress hálózati kimenő forgalom.
Egy átlagos KKV-s API ezen belül marad. Egy átlagos JAMstack-blog backendje, ami napi 10 ezer kérést kap, valószínűleg ingyenes lesz örökre.
A számlázás dimenziói
| Dimenzió | Egységár (Tier 1, kb.) |
|---|---|
| vCPU-másodperc | $0.000024 |
| GiB-másodperc memória | $0.0000025 |
| Kérés (1 millióra) | $0.40 |
| NVIDIA L4 GPU másodperc | $0.000187 |
Konkrét számolás
A Google saját kalkulátora alapján: egy 1 vCPU + 512 MiB-os service Belgium régióban, havi 10 millió kéréssel, átlag 400 ms-os válaszidővel — ez kb. $13.69 / hó (az ingyenes kerettel együtt). Ugyanez ingyenes keret nélkül $18.91 lenne.
Egy másik példa: egy óránkénti batch-job, ami 1 percig fut, 1 vCPU-val és 512 MiB-tal — havi költsége $0.00, mert teljesen az ingyenes keretben marad. Ingyenes keret nélkül havi $0.45 lenne.
Régiós eltérések
Az ingyenes keret csak a Tier 1 régiókban érvényes (us-central1, us-east1, us-west1). EU-s régiókban (europe-west1, europe-west3) az ár valamivel magasabb, és az ingyenes keret nem mindig alkalmazódik. Ezt érdemes ismerni: ha az adatkezelés szigorúan EU-s, akkor az ingyenes keret nélküli árral érdemes számolni.
Committed Use Discounts
Ha az app forgalma stabil és előre jósolható (pl. mindig fut 2 vCPU-nyi háttér-folyamat), érdemes 1 vagy 3 éves elköteleződésre váltani. Az 1 éves kb. 17%, a 3 éves 30%+ kedvezményt ad. Ezek a CUD-k automatikusan alkalmazódnak a Cloud Run-on, GKE-n és Compute Engine-en is — egy nagy ügyfélnél jó megtakarítást jelentenek.
08 — vs. Cloud Functions
Cloud Run vs. Cloud Functions
A két szolgáltatás sok tekintetben átfedi egymást — sőt, a Cloud Functions v2 a háttérben Cloud Run-on fut. A különbség mégis fontos: a Cloud Functions a kis, fókuszált függvényekre van élezve, a Cloud Run a teljes konténerekre.
A két modell
| Szempont | Cloud Functions v2 | Cloud Run services |
|---|---|---|
| Egység | Egy függvény | Egy konténer (akármilyen webszerver) |
| Indítók | HTTP, Firestore, Storage, Pub/Sub, Auth, Schedule | HTTP (Pub/Sub, Schedule mellé Eventarc) |
| Nyelv-támogatás | Node.js, Python, Java, Go, .NET, Ruby, PHP | Bármi, ami Docker-be csomagolható |
| Maximum futási idő | 9 perc esemény / 60 perc HTTP | 60 perc |
| Maximum memória | 32 GB | 32 GB |
| GPU | nincs | NVIDIA L4, RTX PRO 6000 Blackwell |
| Indítási sebesség | ~0.5-1.5 mp (v2) | ~0.5-2 mp |
| Kódolási élmény | Egyszerű függvény-szignatúra | Saját webszerver (Express, Fastify, NestJS, …) |
Mikor melyik?
Választás
Cloud Functions vagy Cloud Run?
Cloud Functions
Egy konkrét eseményre reagáló kis logika: Firestore-trigger, Storage-trigger, webhook-fogadó. Ahol a kód lényege egyetlen függvény, és a többit a Firebase ökoszisztémával együtt használod.
Cloud Run
Egy nagyobb backend: REST API, GraphQL szerver, web-app, ML-szolgáltatás. Ahol szerver-keretrendszert használsz (NestJS, Express, FastAPI), és kontrollt akarsz a teljes konténer felett.
Egy gyakorlati hibrid
Sok projektben a kettő együtt él: a fő API egy Cloud Run service (REST, GraphQL, NestJS, akármi), a Firestore-trigger-ek pedig Cloud Functions-ben. Az ok egyszerű: a Cloud Functions Firestore-integrációja közvetlenebb és egyszerűbb, viszont a Cloud Run-on építhetsz egy klasszikus webszerver-architektúrát szabványos eszközökkel.
Megjegyzés a Firebase-fejlesztőknek
Aki a Firebase ökoszisztémában dolgozik, a Cloud Functions sokáig az alapértelmezett választás volt minden szerveroldali kódra. A Cloud Run-ra váltás akkor érdemes, ha (a) hosszabb futási idő kell, (b) GPU-t akarsz használni, (c) nem-támogatott nyelven írsz, vagy (d) kifejezetten egy klasszikus REST API-t építesz, ahol a NestJS / Express adta absztrakciók kényelmesebbek. A két szolgáltatás egy projekten belül szabadon vegyíthető.
09 — vs. App Engine és GKE
A Google Cloud egyéb opciói: App Engine és GKE
A Google Cloud-on belül három fő alkalmazás-futtató réteg van: a Cloud Run (és Cloud Functions), az App Engine, és a Google Kubernetes Engine. Mindegyik más absztrakciós szinten ül, és más csapatra való.
App Engine — a klasszikus PaaS
A Google Cloud egyik legrégebbi szolgáltatása (2008 óta). A logikai modell: te megírod az appot egy támogatott nyelven, az App Engine futtatja. Két változata van: Standard (gyorsabb skálázódás, nyelvi korlátok) és Flexible (Docker-konténer, lassabb skálázódás).
A 2010-es években népszerű volt, ma azonban a Cloud Run szinte minden szempontból jobb választás. A Standard environment lassabban skáláz nullára, a Flexible drágább, és a fejlesztői élmény elavultabb. Új projekteknél az App Engine-t ritkán érdemes választani — Cloud Run minden szempontból kényelmesebb.
Google Kubernetes Engine (GKE)
A klasszikus, teljes Kubernetes platform. Ha tényleg teljes kontrollt akarsz a konténerek felett — saját pod-konfigok, sidecar-ok, networking-szabályok, custom Helm chart-ok, service mesh —, akkor a GKE az út. De ezzel együtt jár a teljes ops-felelősség: cluster-menedzsment, frissítések, biztonsági patchek, autoscaling-konfiguráció.
A GKE Autopilot mód az „útmenti megoldás": a Google kezeli a node-okat, te csak a workload-okat. Ez közelebb hozza a GKE-t a szerverless világhoz, de még mindig drágább és bonyolultabb, mint a Cloud Run egy egyszerű API-hoz.
A három réteg viszonya
| Szolgáltatás | Mit kell csinálnod | Mikor választanád |
|---|---|---|
| Cloud Run | Konténert csomagolsz, a többit a platform | HTTP-szolgáltatások, API-k, batch-feladatok, scale-to-zero |
| App Engine | Kódot adsz, a platform futtatja (Standard) vagy konténert (Flexible) | Régi projektek karbantartása, migrációs útpont |
| GKE Autopilot | Pod-okat definiálsz, a Google futtatja | Több service együtt, sidecar-ok, mesh, finom konfiguráció |
| GKE Standard | Cluster-t üzemeltetsz | Teljes kontroll, hibrid környezet, on-prem integráció |
Egy gyakorlati elv
Egy új projektnél kezdj Cloud Run-on. Ha valamiért szükséged lesz fix Kubernetes-jellemzőkre (pl. StatefulSet, PersistentVolume, custom ingress), akkor migrálj GKE-re — addigra már tudni fogod, mi kell. Az App Engine-re ma már új projektet ritkán érdemes telepíteni.
10 — vs. AWS
AWS-megfelelők — Lambda és Fargate
Az AWS-en két szolgáltatás állítható párba a Cloud Run-nal: a Lambda (függvényalapú) és a Fargate (konténer-alapú, ECS vagy EKS mögött). Mindkettő jó saját jogon, de a fejlesztői élmény és a szabványossági szint különbözik.
AWS Lambda
A Lambda az iparág legrégebbi szerverless platformja (2014). A Cloud Functions-höz hasonlóan függvényalapú: adsz egy kódot, az AWS futtatja eseményekre vagy HTTP-kérésekre. Sok mindenben pionír volt, de van néhány különbség a Cloud Run-hoz képest:
- Korlátozott futtatókörnyezet — Node.js, Python, Java, .NET, Go, Ruby, és „custom runtime" (de nem teljes Docker-konténer, hanem egy speciális layer-rendszer). 2020 óta van „container image" mód is, ami közelebb áll a Cloud Run-hoz, de méretkorlát van (10 GB).
- Maximum futási idő — 15 perc. A Cloud Run-on 60 perc kérésenként, vagy 24 óra job-onként.
- Hideg indulás — több bejelentés alapján a Lambda hideg indulása lassabb, főleg a Java esetében. A Provisioned Concurrency a megoldás (ami lényegében min instances).
- Nincs natív HTTP-szerver — egy Lambda függvény egy esemény-objektumot kap, nem HTTP-kérést. Ha klasszikus webszerver-stílusban akarsz dolgozni (Express, Fastify, FastAPI), az AWS API Gateway + Lambda + adapter-csomagok kombinációja kell. A Cloud Run-on ez közvetlen.
AWS Fargate
Az AWS Fargate az ECS vagy EKS alatt fut, és lehetővé teszi, hogy konténereket futtass szerver-üzemeltetés nélkül. Közelebb áll a Cloud Run-hoz a konténer-szempontjából, de van pár különbség:
- Nincs natív scale-to-zero — a Fargate-on legalább 1 task fut mindig (kivéve specifikus konfigurációkkal). A Cloud Run alapból scale-to-zero.
- Per-perc számlázás a Fargate-en (per-másodperc a Cloud Run-on). Kis terhelésnél a Cloud Run kedvezőbb.
- Több konfiguráció — VPC, security groups, ALB, target groups. A Cloud Run egy parancs.
Egy összehasonlító táblázat
| Szempont | Cloud Run | AWS Lambda | AWS Fargate |
|---|---|---|---|
| Egység | Konténer | Függvény (vagy konténer 10 GB-ig) | Konténer |
| Maximum futási idő | 60 perc | 15 perc | nincs korlát |
| Scale-to-zero | igen | igen | nem (alapból) |
| Számlázás | per másodperc | per millisec | per perc |
| GPU | L4, RTX PRO 6000 | nincs | nincs (Fargate-en) |
| HTTP-natív | igen | nem (API Gateway kell) | igen |
Migrációs lehetőség
A Cloud Run a Knative-ra épül, ami nyílt szabvány. Ez azt jelenti, hogy egy Cloud Run service-t (minimális módosításokkal) átvihetsz Knative-támogatású Kubernetes-re — beleértve az AWS EKS-t is. Az AWS Lambda esetében ez sokkal nehezebb, mert a Lambda-specifikus event-modell és a Lambda Runtime API mind egyedi. Vendor-lock szempontjából a Cloud Run kedvezőbb.
11 — vs. Vercel és Render
A „developer experience" platformok — Vercel, Render, Fly.io
Az utóbbi években megjelent egy új platform-kategória: az olyan szolgáltatások, amik a fejlesztői élményre koncentrálnak. Vercel a Next.js-szel összenőve, Render mint általános PaaS, Fly.io a globális edge-deploy-jal. Sok egymást átfedő funkció, és fontos, hogy hol jobb a Cloud Run.
Vercel
A Vercel a Next.js mögötti cég platformja, és a Next.js-t kifejezetten erre a környezetre optimalizálták. Ha Next.js-t használsz, a Vercel egy git-push-ra mindent megold: SSR, ISR, képek-optimalizálás, edge-functions, preview-deploy. A fejlesztői élmény kiváló.
De van pár megfontolnivaló:
- Drágább nagy forgalomra — a Vercel a felhasználói élményre számláz (function-execution + bandwidth), és ez gyors növekedésnél tud meglepő lenni. Cloud Run-on a CPU-/memória-percek kiszámíthatóbbak.
- Nem-Next.js workload-ok — egy NestJS API vagy egy Python-ML-szolgáltatás Vercel-re tehető, de a platform Next.js-re van élezve. Cloud Run univerzálisabb.
- Edge-funkciók korlátai — a Vercel Edge Runtime a V8 Isolate-on fut, nem a teljes Node.js-en — pár csomag nem működik. A Cloud Run teljes Node.js-t ad.
Render
A Render egy Heroku-szerű PaaS, ami a fejlesztői élményre épít. Web service-ek, háttér-workerek, statikus oldalak, PostgreSQL — mind egy felületen, egyszerű árazással. Egy startupnak szuper kezdés, és a Cloud Run-hoz hasonlóan szabványos konténereket vagy buildpack-elt forráskódot futtat.
De Render-nél nincs scale-to-zero (csak fizetős plánok), és a globális kiszolgálás is bővebb infrastruktúrát igényel. A Cloud Run a Google globális hálózatára épül, és a globális load balancing alapból működik.
Fly.io
A Fly.io egy érdekes alternatíva: a fő érték az, hogy az appodat globálisan, sok edge-régióban telepíti, és a felhasználó a hozzá legközelebbihez kapcsolódik. Ez különösen jó valós idejű appokra (chat, játékok), ahol a hálózati késleltetés kritikus. A Cloud Run-on ez is megoldható (több régiós deploy + globális LB), de a Fly.io fejlesztői élménye erre van élezve.
Egy összehasonlító táblázat
| Szempont | Cloud Run | Vercel | Render | Fly.io |
|---|---|---|---|---|
| Fókusz | Konténerek általában | Next.js, frontend | PaaS, full-stack | Edge, globális |
| Scale-to-zero | igen | igen (function-ök) | nem (alap) | igen |
| Konténer-szabványos | igen (Knative) | nem | igen | igen |
| Fejlesztői élmény | jó | kiváló (Next.js-szel) | kiváló | jó |
| GPU | L4, Blackwell | nincs | nincs | elérhető |
| Globális LB alapból | igen | igen | korlátozottan | igen |
| Költség kis forgalmon | $0 (free tier) | $0 (Hobby) | ~$7/mo (Standard) | ~$5/mo (per app) |
12 — Mikor érdemes
Mikor érdemes Cloud Run-t választani?
A Cloud Run sok szempontból a Google Cloud egyik legjobb szolgáltatása — és gyakran a legjobb választás kis-közepes alkalmazásokra. Itt jelek, hogy mikor érdemes választani, és mikor nem.
Akkor jó választás, ha…
- Konténerben gondolkodsz — már van Dockerfile-od, vagy kényelmes ezt fejleszteni.
- Egyenetlen forgalmú az alkalmazás — sok pillanat 0 forgalom, alkalmanként csúcsok. Itt a scale-to-zero komoly költségmegtakarítás.
- Standard webszerver-keretrendszerben írsz — Express, NestJS, FastAPI, Flask, Spring Boot. A Cloud Run egy klasszikus szerver fut, semmi különös API-modell.
- EU-s ügyfélkör, GDPR-fontos — a Cloud Run-on könnyen tartható az adat EU-ban (europe-west1, europe-west3).
- AI-/ML-inferencia bursty forgalommal — a GPU-támogatás scale-to-zero-val nagyon kedvező az on-demand modellekre.
- Vendor-lock minimalizálása fontos — a Knative-szabvány miatt elvileg átköltözhető más Kubernetes-re.
Mikor nem ideális
- WebSocket-szerű hosszú kapcsolatok dominálnak — bár a Cloud Run támogatja a WebSocket-et (60 percig), a klasszikus mintában az instance-billing modell jobb. Nagy forgalomnál egy állandó GKE-cluster olcsóbb.
- Több service együtt, közös belső networking-gel — a Cloud Run service-ek könnyen kommunikálnak, de bonyolult mesh-konfigurációhoz GKE Autopilot előnyösebb.
- StatefulSet-szerű viselkedés kell — egy adott példánynak adott nevet, állandó adatkönyvtárat. A Cloud Run instances modell részben megoldja, de teljes StatefulSet-funkció nincs.
- Nagy állandó terhelés — ha az app 24/7 magas terhelésen fut, egy committed GKE-cluster vagy Compute Engine olcsóbb lehet (per-óra árban).
Tervezési checklist Cloud Run-ra váltás előtt
- ☐Az appom konténerizálható, és van vagy lesz Dockerfile-om vagy buildpacks-támogatott szerkezetem?
- ☐A környezeti változók (API-kulcsok, DB-konnekciók) a Secret Manager-be kerülnek, nem a kódba?
- ☐A PORT változót a kódom a környezetből olvassa, nem hardkódolva?
- ☐Az állapotom (session, cache) külön szolgáltatásban van (Redis, Firestore, DB), nem a memóriában?
- ☐A párhuzamosság beállításait átgondoltam (alapból 80, memória- vagy DB-pool-korlátok mentén csökkentve)?
- ☐Eldöntöttem, kell-e
min-instances 1a hideg indulás ellen? - ☐Az EU-s adatkezeléshez europe-west1 vagy europe-west3 régiót választottam?
- ☐A CI/CD beállítva, hogy git-push-ra magától épít és telepít (Cloud Build, GitHub Actions)?
- ☐A logging strukturált (JSON), nem szabad szöveges?
- ☐A GPU-szükséglet egyértelmű, és nem felesleges (sok use-case CPU-n is jól megy)?
- ☐A költség-becslést megcsináltam a Pricing Calculator-ral, és a havi várt költség elfogadható?
- ☐Nincs olyan funkcióm, ami Cloud Functions-ben jobban megoldható (pl. Firestore-trigger)?
A Cloud Run nem csodaszer, de a 2020-as évek közepén egy új projektnél a legtöbb szerveres workload-ra ez a kiindulási pont. Egyszerű, rugalmas, kompetitív áron, és nem zár vendor-be. Akkor érdemes mást választani, ha a project-igények ezt indokolják — nem fordítva.
A Firebase ökoszisztémában a Cloud Run-nak egyre nagyobb szerepe van: a Firebase Hosting már natívan tudja routolni a forgalmat Cloud Run-ra (a rewrites szakaszon keresztül), így egy Angular SPA + Cloud Run backend kombináció ma már a klasszikus választás. A korábbi cikkben tárgyalt Cloud Functions továbbra is jó az esemény-trigger-ek és a kicsi, fókuszált backend-műveletek esetére, viszont egy klasszikus REST API vagy GraphQL szerver építéséhez a Cloud Run kényelmesebb.