Cloud Run: Kosteneinsparungen für serverside Google Tag Manager

Der serverside Google Tag Manager (sGTM) läuft üblicherweise über Coud Infrastruktur wie Cloud Run, oder App Engine. Die Kosten für die Nutzung setzen sich aus zwei wesentlichen Teilen zusammen:

  • Cloud Run Instanzen & Anfragen: Die Konfiguration & Auslastung der Cloud Run Services
  • Cloud Logging: Logs für Requests & Standardausgabe (stdout)

Da Dienste wie Cloud Run serverless sind, skalieren diese bei Bedarf auf mehrere Instanzen hoch, um alle Anfragen zu bearbeiten. Sowohl das Minimum als auch das Maximum von Instanzen kann im Tab YAML angepasst werden:

spec:
  template:
    metadata:
      name: server-side-tagging-00001-gic
      annotations:
        run.googleapis.com/client-name: cloud-console 
        autoscaling.knative.dev/minScale: '2'
        autoscaling.knative.dev/maxScale: '10'

Achtung: Die Einstellung für eine mindestens Anzahl von Instanzen sorgt für dauerhafte Kosten, auch wenn keine Anfragen bearbeitet werden.

Standardmäßig werden im Docker Image vom sGTM keine Mindestanzahl von Instanzen gesetzt. Für gewöhnlich ergibt es wenig Sinn, hier einen Wert nachträglich zu setzen. Ausnahmen bestätigen die Regel.

Cloud Logging

Cloud Logging ist die Logverwaltung für die Google Cloud Platform und deckt Cloud Run und andere Services wie App Engine, oder BigQuery ab. Standardmäßig werden alle Requests und die Standardausgaben protokolliert. Bei kleineren Websites spielt das keine große Rolle, aber bei größeren Plattformen können die Logs schnell zu einer großen Kostenstelle für den Betrieb des serverseitigen Google Tag Managers werden.

Cloud Run Log Typen – Requests, Stdout

Um dies zu verhindern ist es sinnvoll Logs, die nicht benötigt werden, auszuschließen. Dafür können Logs Exclusions genutzt werden. Logs, die so ausgeschlossen werden, verursachen keine Kosten, fehlen aber dann im Zweifelsfall auch zu Debugzwecken.

Logs Exclusion

Cloud Logging arbeitet mit Sinks, was im Prinzip nichts anderes ist als Auffangbehälter, in denen Logs gesammelt werden. Der Default Sink ist _Default. Hierfür können wir eine Log Exculsion anlegen, um das Aufzeichnen von Cloud Run Logs zu verhindern.

Bevor eine Filter aktiviert wird, ist sehr empfehlenswert, die Filterregeln vorher zu testen:

Logs Explorer – Cloud Logging

Der oben gezeigte Filter, welcher von Google empfohlen wird, schließt alle Requests von Cloud Run, unabhängig von der Schwere des Logs aus. Übrig bleiben würden dann in einem Inclusion Filter die stdout Logs, oder in einem Exclusion Filter das Gegenteil, alles was nicht stdout Logs sind.

Aus meiner Erfahrung ist es einfacher zu bestimmen, was man herausfiltern möchte, also eher eine Filterregel zu schreiben, die Logs bestimmt, die ausgeschlossen werden sollen. Diese lassen sich ebenfalls einfacher im Logs Explorer testen.

Ein Filterregel für den Ausschluss von allen Logs von Cloud Run, welche nicht vom Typ DEFAULT, oder Typ INFO sind könnte so aussehen.

resource.type="cloud_run_revision" AND
severity=DEFAULT OR severity=INFO

Dieser kann dann im Logs Router bei dem _Default Sink als Logs Exclusion Filter angelegt werden.

Cloud Run Logs Exclusion Filter – _Default Sink

Committed Use Discounts

Bei der GCP gibt es die Möglichkeit, Ressourcen für vordefinierte Zeiträume zu erwerben. Für App Engine gibt es diese Möglichkeit nicht, aber für fully managed Cloud Run Services kann bereits bei einer Laufzeit von einem Jahr 17 % an Kosten eingespart werden.

Committed Use Discounts – Cloud Run (fully managed)

Dieser Rabatt war bei meinem Tests aktuell fest bei 17 % und hat sich auch nicht für niedrigere oder höhere Commitments verändert. Die Stichproben für unterschiedliche Regionen ergaben ebenfalls keinen Unterschiede im Rabatt.

Fazit

Committed Use Discounts sind neben dem Filtern von Cloud Logs ein sinnvoller Ansatz, um Kosten bei der Betreibung eines sGTM einzusparen. Ebenfalls ist mit einer Mindestlaufzeit von einem Jahr die Dauer der Verpflichtung überschaubar. Achtung: Auch wenn die reservierten Ressourcen nicht abgerufen werden, müssen diese dennoch bezahlt werden. Vor dem Erwerb eines CUD ist es also sinnvoll, die Auslastung des sGTM über einen Zeitraum zu beobachten, um dann ein passendes Kontingent an Laufzeit Stunden zu erwerben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert