Serverové měření část 1 - jak rozjet server na Cloud Run

Nasadit serverové GTM jde více způsoby. Lze ho rozjet na vlastním fyzickém serveru nebo ve vámi preferovaném cloudu. Nejběžnější jsou dva přístupy - nastavit si manuálně sGTM v rámci služby *Cloud Run v Google Cloud Platform (GCP) nebo outsourcovat služby jiné firmy, která nasazení a provoz zařídí za vás, například Stape.

^{*”Cloud Run” je v kontextu serverového měření místo, kde běží serverové GTM - je dostupný na vaší vlastní doméně, spustí váš kód, když přijde request a zastaví ho, když není potřeba. Žádný server který "běží naprázdno", žádná fixní kapacita - platíte jen za skutečný provoz.}

‍

Varianta Stape

• běží také na Google Cloud infrastruktuře, ale data neprochází vaším GCP projektem. Při hodně přísných bezpečnostních firemních pravidlech by to mohl být problém i když STAPE má SOC 2 / ISO 27001 certifikaci a tedy vysokou důvěryhodnost
• bude levnější pro weby do 500 tis. requestů měsíčně s jednou doménou
• se Stape tomu nepotřebujete moc technicky rozumět - nastavení je na pár kliknutí
• cena je předem definovaná dle objemu eventů 
• Stape nabízí plno služeb navíc, ale nemůžete si flexibilně službu upravovat

Varianta vlastní Cloud Run

• vše běží pod vaší firmou - kam se data dostanou záleží čistě na vás - > vysoká míra bezpečnosti a lepší compliance
• pro normální velikost webů či ve chvíli, kdy máte více domén je cena stejná nebo dokonce výhodnější díky škálování (placení jen za výpočetní výkon, který využijete)
• vše si nastavíte sami - od zabezpečení po výkon
• Můžete využívat další služby v Google Cloud Platform například pro obohacení dat před odesláním do reklamních systémů

My samozřejmě preferujeme vlastní Cloud Run, protože tím snižujeme závislost na fungování a supportu třetích stran.

‍

Co budete k rozjetí serveru na vlastním Cloud Run potřebovat?

1. Přístup do GCP (Google Cloud Platform) a mít ho napojený na Billing account s platební kartou. V rámci GCP vám pak poběží další služby jako je BigQuery, Monitoring a právě Cloud Run
2. Admin práva do Google Tag Manageru - > potřebujete frontendové (klasické GTM) a server-side GTM
3. DNS pro nastavení nové serverové subdomény

‍

Jak to nastavit

Nastavení celého Cloud Run je technicky složitější a navíc cca každý rok vychází update, který celý proces občas změní. Nicméně podrobný postup najdete například u Simo Ahava (hlavně jeho kurz v Simmer) nebo na Analytics Mania. V tomto článku projdeme základní kroky a věnovat se budeme hlavně tipům a trickům.

‍

Krok 1: Vytvořte server GTM kontejner

Serverový kontejner se v GTM zakládá stejně jako webový, ale s důležitým rozdílem - vyžaduje admin práva a při zakládání získáte Container Configuration string, který bude potřeba při zakládání serveru v dalším kroku.

Jedno nebo více serverových GTM?

Můžete mít více frontendových GTM a jedno serverové. Pro ukázku - domena.cz a domena.sk mají každá své frontendové GTM. Protože jejich návštěvnost je nízká a rozdíly mezi weby nejsou velké, lze obě domény namapovat na jeden server, na kterém pojede jedno serverové GTM. 

Řešte to spíše s ohledem na organizaci práce - pokud jsou pro každou zemi oddělené týmy, oddělené budgety nebo velké rozdíly v mediálních tazích, volte 2 servery a 2 sGTM. Musíte pak ale počítat, že zaplatíte dvojnásobek nákladů jen za provoz 2 serverů.

‍

Krok 2: Založte dva servery v Cloud Run

Serverové GTM potřebuje dva oddělené servery - preview a produkci. 

Preview server slouží výhradně pro debugování. Nastavuje se na minimum (0–1 instance).

Produkční server je ten, který skutečně zpracovává data. Nastavuje se s vyšším auto-scalingem (1–10 instancí) a má environment proměnnou PREVIEW_SERVER_URL ukazující na preview server.

Oba dva servery se propojí přes Container Config se serverovým GTM.

Vysvětlivky a tipy:

Při nastavování narazíte na pojmy, které nemusí být na první dobrou jasné. Níže je několik z nich.

Název serveru - název projektu/ klienta + rozlišení na preview/production a pokud je to důležité, tak region, kde si server od Google pronajímáte. V Cloud Run mohou běžet i další služby, tak ať se v tom potom vyznáte. Například server-side-tagging-europe-west1-nazev_projektu-production a server-side-tagging-europe-west1-nazev_projektu-preview.

‍

Region - pokud sbíráte data, která jsou primárně z Čech, je potřeba vybrat region, nabízející serverovou infrastrukturu nejblíže nám, tedy europe-west3 = Frankfurt nebo europe-central2 = Varšava. Pro soulad s regulacemi o ochraně dat je potřeba umístění Evropa a pro minimalizaci nákladů za transport dat ideálně region co nejblíže ČR.

‍

Instance  = alokovaná výpočetní kapacita. Kolik požadavků jedna instance zpracuje závisí na dostupné kapacitě CPU.  Kolik instancí a jak dlouho běží je to, za co zaplatíte. 

‍

Autoscaling - pro většinu webů máme nastaveno 1-10 instancí a bohatě to stačí. Minimálně 1 instance znamená, že 1 instance je vždy připravena a nemusí se startovat . Pokud nastavíte minimum na 0, pak není připravena žádná instance a první request čeká na cold start  - pokud vám hodně kolísá návštěvnost, a potřebujete rychle reagovat, toto řešení pro vás není ideální. Pokud mám vyšší návštěvnost a potřebuji rychle odbavovat více požadavků, je dobré mít připraveny 2 instance (min 2 instance). Nicméně to znamená, že platím vždy za 2 instance. Autoscaling neboli škálování znamená, že si server může nastartovat další instance podle potřeby, do max 10 instancí. Z druhé strany - pokud by na vás zaútočil spam traffic, neutratíte více než za provoz 10 instancí. I to však může být drahé, a je dobré mít na toto nastavený alerting. Tomu se budeme věnovat v některém z dalších dílů. 

‍

Instance-based vs request-based billing

 - při request-based billing platíte pouze za dobu, kdy instance aktivně zpracovává request . Mezi requesty instance 'spí' - CPU nic nedělá a neúčtuje se. Platíte pouze za paměť alokovaných instancí a za CPU jen po dobu aktivního zpracování requestu. Při minimu 2 instances jsou 2 instance připravené a relativně rychle se nastartují, ale pokud by přišla návštěvnost vyžadující více instancí, bude potřeba více času k probuzení než u instance-based a může docházet ke zpoždění odbavování požadavků (request latency) a v extrémním případě zahlcení serveru.

 - při instance-based billing platíte za alokované instance, jsou vždy připravené a dokáží rychle reagovat na požadavky z webu.

Pokud je výkon vyšší a neustálý, je výhodnější mít instance neustále připravené (instance-based), pokud návštěvnost kolísá, je výhodnější platit za requesty.

Při instance-based billing stojí při minimum 1 instance cca 45 Kč/den (berte to jen jako orientační údaj), minimum 2 instances stojí 90 Kč - > za měsíc to pak dělá mezi 1 350 Kč - 2 700 Kč. Za to máte relativní jistotu, že váš web zvládne výkyvy návštěv a requesty budou spolehlivě zpracovány.

Při request-based billing můžete v minimu jít na cca 300 Kč, ale při rychlých změnách požadavků na server nemusí tento vždy stíhat.  

‍

Debugging - sGTM nemá izolované prostředí jako u frontendového měření, preview requesty fyzicky tečou přes produkční infrastrukturu. Když debugujete, prohlížeč pošle request na váš produkční sGTM endpoint. Request obsahuje hlavičku X-Gtm-Server-Preview - a produkční server podle té hlavičky pozná, že jde o preview request a přepošle ho na preview Cloud Run instanci.

Tedy produkční server request přijme, vyhodnotí hlavičku a přepošle - to znamená že produkční server je vždy minimálně trochu zatížen. Zjistíte to hlavně ve chvíli, kdy zapomenete zavřít debuggovací okno a přijdou vám alerty, že se výrazně zhoršila request latency, tedy rychlost odbavování požadavků serverem.

‍

Application Load balancer - ano nebo ne?

Load balancer vstupní brána na server, je to taková recepce ve firmě. Bez něj firma (rozuměj server) funguje, ale když přijde návštěvník (request) nemáte jak předat informace, co je to za firmu, navést návštěvníka určitým směrem, nebo třeba kam umístit ostrahu v podobě Cloud Armor.

Správně, technicky, je to reverzní proxy - sedí před serverem a přijímá veškerý příchozí provoz. Prohlížeč se připojí na load balancer, který request zpracuje a přepošle dál na správný server. "Reverzní" proto, že na rozdíl od klasické proxy, která chrání uživatele, tato vrstva chrání a řídí přístup k serveru.

Nastavení load balanceru je technicky složitější a stojí nějaké stokoruny měsíčně navíc, ale bez něj přijdete o plno výhod, které serverové měření nabízí. Jedna z nich třeba je, že z frontendu data nepotečou na vaši doménu (ta se ideálně mapuje právě na load balancer), ale na doménu automaticky vygenerovanou při zakládání produkčního serveru - něco ala *.run.app. Pak přicházíte o 1st party context, data jsou snadným cílem pro adblockery a třeba safari prohlížeč zkrátí životnost cookies na max 7 dní.

Tedy dá se žít i bez něj, ale za nás rozhodně lépe s ním.

Krok 3: Vytvořte load balancer a namapujte na něj vlastní doménu

Postup v kostce:

1. Rezervujte statickou IPv4 adresu v GCP IP addresses (VPC Network)
2. Vystavte SSL certifikát přes Certificate Manager
3. Vytvořte Load Balancer v Network services
4. Nastavte frontend a backend
5. Přidejte routing rule pro tvou vlastní subdoménu
6. Pošlete DNS záznamy vývojářům klienta (“je potřeba upravit A záznamy pro novou subdoménu - IP viz výše)

Podrobný postup, jak bylo zmíněno výše, Simo Ahava (hlavně jeho kurz v Simmer) nebo Analytics Mania.

Serverová subdoména:

Ideální je vytvořit subdoménu, která není ničím nápadná, tedy ne “tracking.vasedomena.cz” ale třeba “hub” nebo náhodný string. Pokud máte třeba klientskou zónu, která sedí na jiné doméně, je potřeba vytvořit subdomény pro obě vlastní domény, protože hlavní cíl je zachovat 1st party kontext, tedy data z webu posílat na stejnou doménu. Obě pak můžete namapovat na jeden server a spojit jedním serverovým GTM. Ušetříte tím náklady za provoz i nastavení.

‍

Kdy CloudRun nastavit? 

Pokud chcete spustit serverové měření teď, potvrďte si serverovou subdoménu a projděte celým procesem výše.

Někdy se může stát, že zároveň upravujete vlastní měření, řešíte s vývojem nastavení DL pushů, nebo čekáte na jiné akce, a ostré serverové měření se spustí třeba až za měsíc. Za rezervaci statické IP adresy a vytvoření load balanceru se platí poplatek cca 400 Kč/měsíčně, bez ohledu na to, zda už jste spustili měření nebo ne. Pozor, ať zbytečně neplatíte náklady na Cloud Run moc brzy. 

‍

Krok 4: Otestujte, že vše funguje správně

Test 1 - Ověřte, že doména funguje a SSL certifikát je aktivní

Do prohlížeče zadejte: https://hub.tvadomena.cz/healthy

Pokud vrátí ok - server běží, SSL funguje, load balancer routuje správně.

Pokud vrátí chybu nebo SSL warning - certifikát se ještě provisionuje (může trvat až 24 hodin po nastavení DNS).

‍

Test 2 - Ověřte, že preview server funguje

https://hub.tvadomena.cz/gtm/preview

Mělo by vrátit nějakou odpověď - ne 404.