Server-Side GTM na GCP Cloud Run: Architektura, Auto-Scaling i optymalizacja kosztów

Server-side Google Tag Manager (ssGTM) odbiera żądania pomiarowe i przekazuje skonfigurowane zdarzenia do wybranych systemów. Cloud Run zapewnia infrastrukturę kontenerową i dostosowuje liczbę instancji do obciążenia. Niezawodność zależy również od tagów, reguł zgody, zasobów i monitorowania. Poprawna odpowiedź dla przeglądarki nie potwierdza dostarczenia zdarzenia do każdego odbiorcy.

Najpierw architektura

Instrukcja Google dla Cloud Run rozdziela serwer podglądu od serwera tagowania obsługującego ruch produkcyjny. Oficjalna procedura obejmuje oba zadania. Ręcznie utworzona usługa tagowania wymaga rzeczywistej wartości CONTAINER_CONFIG z GTM oraz poprawnego PREVIEW_SERVER_URL. Wymyślony ciąg Base64 nie stanowi działającej konfiguracji. Publiczna dostępność, własna domena i ustawienia transportu w kontenerze internetowym również wymagają sprawdzenia.

Opublikowany kontener serwerowy określa klientów przejmujących żądania oraz uruchamiane tagi. Przekazywanie danych do GA4, Meta i TikTok wymaga osobnych konfiguracji oraz odpowiednich reguł zgody. Cloud Run nie dodaje takich integracji automatycznie. Znacznik stable oficjalnego obrazu może wskazać nową wersję; aktualizacja wymaga wdrożenia i weryfikacji. Samo przesunięcie znacznika nie aktualizuje obrazu działających instancji.

Gotowa pojemność i granice skalowania

Minimalna liczba instancji utrzymuje gotowe zasoby i ogranicza opóźnienia uruchamiania. Dodatkowe instancje podczas skoku ruchu, instancje zastępcze i nowe rewizje nadal mogą wymagać zimnego startu. Ustawienie minimum na jeden nie gwarantuje konkretnego czasu startu ani odpowiedzi poniżej 50 ms. Instrukcja ssGTM zaleca co najmniej dwie instancje w celu ograniczenia ryzyka awarii; właściwa pojemność zależy od wymagań dostępności i zmierzonego ruchu.

Maksymalna liczba instancji ogranicza skalowanie, lecz nie stanowi twardego limitu wydatków. Możliwe są chwilowe przekroczenia, a limit rewizji różni się od limitu całej usługi. Zbyt niskie maksimum podczas skoku ruchu może powodować oczekiwanie lub błędy żądań. Plan eksploatacji powinien uwzględniać ograniczenia ruchu, limity systemów docelowych i alert budżetowy. Sam alert nie zatrzymuje naliczania opłat.

CPU, pamięć i współbieżność

Instrukcja ssGTM opisuje konfigurację początkową z jednym vCPU i około 0,5 GB pamięci na instancję oraz przydziałem CPU poza aktywnymi żądaniami. Odpowiadające ustawienie --no-cpu-throttling wybiera rozliczanie instancji: czas bezczynności także jest płatny. Dostępność CPU w tle nie zapewnia trwałości żądań wychodzących podczas wyłączenia instancji ani skutecznego dostarczenia do odbiorcy.

Współbieżność ogranicza liczbę równocześnie obsługiwanych żądań na instancję. Wartość 80 jest maksimum, a nie obietnicą rozpoczęcia skalowania dopiero przy żądaniu 81. Skalowanie zależy zarówno od wykorzystania CPU, jak i współbieżności. Wyższa współbieżność może poprawić wykorzystanie zasobów, ale duże ładunki, kosztowne tagi i wolne API odbiorców mogą zwiększać zużycie pamięci oraz opóźnienia. Bez pomiarów nie wiadomo, czy przy 512 MiB pierwszym ograniczeniem będzie CPU, czy pamięć.

Praktyczny cykl weryfikacji

1. Zapisać obraz, rewizję, model rozliczeń, granice liczby instancji, CPU, pamięć i współbieżność. Oddzielnie uwzględnić zasoby podglądu i tagowania produkcyjnego.
2. Przeprowadzić kontrolowane testy z typowymi ładunkami i tagami, wolnym odbiorcą oraz realistycznym skokiem ruchu. Sztuczne zakupy nie powinny trafiać do raportów produkcyjnych.
3. Porównać wysokie percentyle czasu odpowiedzi, odsetek błędów, CPU, pamięć, liczbę instancji i potwierdzenia odbiorców. Zakończenie instancji po przekroczeniu pamięci jest błędem infrastruktury wymagającym analizy.
4. Zmienić jeden parametr, powtórzyć test i porównać łączne koszty. Uwzględnić logowanie, sieć, podgląd i ewentualny load balancer. Zachować sprawdzoną poprzednią rewizję na potrzeby wycofania zmiany.