BigQuery Autoscaling Public Preview im Überblick (DoiT Edition)

Hier ein kurzer Überblick über die in diesem Artikel verwendeten Begriffe. Wer mit BigQuery vertraut ist, kennt das meiste davon – allen anderen liefert dieser Abschnitt den nötigen Einstieg.

• Job Ein Job ist eine Aktion, die in BigQuery ausgeführt wird – etwa Abfragen, das Laden oder Kopieren von Daten. Der häufigste Job-Typ ist eine Query; beide Begriffe werden oft synonym verwendet.
• Slot Die grundlegende Recheneinheit, mit der BigQuery die Arbeit für einen Job erledigt. Stellen Sie sich einen Slot wie eine "Mini-Virtual-Machine" vor, die mit vielen weiteren zusammenarbeitet, um die eigentliche Arbeit für einen Job zu verrichten.
• Reservation Eine Einheit, die eine bestimmte Anzahl an Slots reserviert, die von null oder mehr darin enthaltenen Projekten genutzt werden kann.
• Commitment Eine feste Anzahl an Slots, die für eine vereinbarte Laufzeit – meist ein Monat oder ein Jahr – reserviert wird, im Gegenzug für einen günstigeren Preis.
• Admin Project Ein Projekt, das als "Manager" der BigQuery-Reservations und -Commitments fungiert. In der Regel hat eine Organisation genau eines (oder einige wenige) davon, um eine zentrale Übersicht ("Single Pane of Glass") für die Verwaltung der BigQuery-Ressourcen zu schaffen. Bei Flat-Rate- und Autoscaling-Projekten werden die Reservation-Billing-SKUs der gesamten Organisation diesem Projekt zugeordnet.
• Flex Slots Slots, die einer Reservation für kurzfristige Lastspitzen hinzugefügt werden können. Sie werden sekundengenau abgerechnet, mit einer Mindestabrechnungsdauer von 60 Sekunden.
• Idle Slot Ein Slot, der aktuell von keinem Job genutzt wird.
• Workloads Ein Workload ist eine Reihe von Jobs, die innerhalb eines einzelnen Projekts ausgeführt werden.
• Slot/Stunde Die grundlegende Abrechnungseinheit für BigQuery-Autoscaling-Projekte. Definiert als ein einzelner Slot, der eine Stunde lang in einem Job genutzt wird.
• Autoscaling Slots Neues Konstrukt, das die Anzahl der Slots ausgehend von einem Baseline-Wert bis zu einem Maximalwert dynamisch nach Bedarf des laufenden Workloads skaliert.
• Baseline Slots Die Mindestanzahl an Slots, die in einem BigQuery-Autoscaling-Projekt "warm" und einsatzbereit gehalten werden. Sie werden zuerst genutzt, bevor Autoscaling einsetzt, und werden abgerechnet, solange die Reservation aktiv ist.

Google hat soeben ein lange erwartetes Feature in die Public Preview überführt: BigQuery Slot Autoscaling für Fälle, in denen Workloads mehr Slots benötigen, als die gekaufte Kapazität bereitstellt.

Vereinfacht gesagt kann BigQuery damit die für Workloads benötigten Slots automatisch hoch- und herunterskalieren – ohne manuelle Eingriffe wie etwa eine Cloud Function, die eine Flex-Slots-Reservation anpasst, sobald bestimmte Schwellenwerte erreicht sind.

Da das Abrechnungsmodell von BigQuery weit über zehn Jahre alt ist und im Kern auf den Prinzipien "Pay-for-Data-Scanned" und "Pay-for-Capacity" basiert, harmoniert es nicht besonders gut mit dem Autoscaling von Rechenkapazität. Um dem Rechnung zu tragen, hat Google für dieses neue Feature ein moderneres Abrechnungsmodell nach dem Prinzip "Pay-for-What-You-Use" eingeführt.

Das Feature ist genau das, was der Name verspricht: Autoscaling von Slots. Sobald ein Workload zusätzliche Slots benötigt, skaliert BigQuery die Anzahl der Slots innerhalb der Reservation nun automatisch nach oben oder unten – je nach Bedarf der laufenden Jobs.

Damit einher geht, wie oben erwähnt, ein neues Abrechnungsmodell auf Basis der Einheit "Slot/Stunde" – also der Preis für die Nutzung eines einzelnen Slots über eine Stunde, sekundengenau abgerechnet.

* Beachten Sie, dass diese Änderung nur die Compute- bzw. Analyse-Seite des BigQuery-Pricings betrifft, nicht die Speicherkosten. Storage ist davon in keiner Weise betroffen. Behalten Sie das beim weiteren Lesen im Hinterkopf.

Das ist enorm leistungsfähig, wenn Sie aktuell Flat-Rate-Abrechnung nutzen und mehr Slots benötigen, als reserviert sind. Flex Slots boten zwar einen Weg zu mehr Slots, waren aber nicht automatisch und erforderten zusätzliches Tooling – meist in Form einer Cloud Function, die in einem festen Intervall die Slot-Auslastung prüfte und Flex Slots bei Bedarf einer Reservation hinzufügte oder wieder entfernte. Ein gutes Beispiel finden Sie hier (nicht mit DoiT verbunden). Wurden Slots jedoch sofort benötigt, hatten Sie Pech – es sei denn, Sie haben dafür zusätzliche Infrastruktur gebaut und bezahlt.

Eine wichtige Anmerkung vorab: Das neue Abrechnungsmodell lässt sich auf eine einzelne Reservation anwenden, die null oder mehr Projekte enthalten kann. Sie können On-Demand, Flat-Rate und Autoscaling also über Reservations und Projekte hinweg beliebig kombinieren, um Nutzung und Kosten zu optimieren.

In der Praxis nutzen alle Jobs in einem Projekt mit gesetztem Baseline-Wert zunächst die Baseline Slots und beginnen erst zu skalieren, sobald diese ausgeschöpft sind. Beachten Sie, dass es sich um einen geteilten Slot-Pool über alle Jobs der Projekte einer Reservation handelt – wie bei einer Flat-Rate-Reservation. Werden die Slots nicht mehr benötigt, werden sie wieder herunterskaliert, sodass dafür keine Kosten anfallen. Genau das ist der entscheidende Unterschied zu Flex Slots, die so lange abgerechnet werden, bis sie entfernt werden.

Allerdings gibt es ein 60-Sekunden-Fenster, innerhalb dessen BigQuery entscheidet, wie skaliert wird. So wird verhindert, dass kurzlaufende Queries auf Ihren Maximalwert hochskalieren und Ihnen Slots in Rechnung gestellt werden, die gar nicht benötigt waren.

Wie leider viel zu oft in der Cloud-Welt lautet die Antwort: Es kommt darauf an. Diese Antwort ist unbefriedigend – schauen wir uns daher einige Szenarien an, in denen das neue Autoscaling-Modell ideal ist:

Angenommen, Sie haben einen Workload, der nur einige Male am Tag und jeweils kurz läuft, dabei aber sehr viele Slots verbraucht (denken Sie an einige tausend Slots). Flex Slots wären hier zwar einsetzbar, doch oft läuft so ein Job in unter einer Minute – Sie zahlen also für die Mindestabrechnungsdauer von 60 Sekunden drauf, in der die Flex Slots gar nicht mehr genutzt werden.

Und wenn Ihre Workloads sehr viele Slots verbrauchen (mehr als 2k, um die On-Demand-Slot-Anzahl zu erreichen) und sehr leselastig sind – sodass On-Demand-Abrechnung wirtschaftlich keinen Sinn ergibt –, sind sie der perfekte Kandidat für Autoscaling. Häufig werden solche Workloads zudem durch eine Kundenaktion ausgelöst, sodass schlicht keine Zeit bleibt, vorher eine Flex-Slots-Reservation für die Ausführung anzulegen.

Falls Ihre Workloads sehr lastspitzenintensiv sind, können Sie deren Slot-Nutzung in unserem BigQuery Autoscaling Slots Calculator mit Ihrem aktuellen Setup vergleichen und prüfen, ob Autoscaling besser passt.

Reservations unter dem neuen Autoscaling-Modell sind weitgehend identisch mit den bisherigen Reservations für die Flat-Rate-Abrechnung – allerdings kommen einige neue Konzepte und ein paar Unterschiede hinzu.

Sie werden weiterhin innerhalb eines Management-Projekts angelegt, und jede Reservation enthält null oder mehr Projekte, denen Slots zur Nutzung zugewiesen werden.

Da das Konzept der Skalierung neu hinzukommt, gibt es nun einen minimalen Skalierungswert namens "Baseline Slots" und einen maximalen Skalierungswert namens "maximum reservation size" bzw. "max slots".

Der Max-Slots-Wert ist definiert als die Summe aus dem Baseline-Slots-Wert und der Anzahl der Autoscaling-Slots, die für die gesamte Reservation festgelegt sind.

Standardmäßig kann ein Job (oder eine Reihe von Jobs), der den Max-Autoscaling-Wert seiner Reservation überschreitet, Slots aus anderen Reservations desselben Management-Projekts ausleihen. Im Bildschirm "Create Reservation" gibt es eine Checkbox namens "Ignore idle slots", über die sich dieses Verhalten deaktivieren lässt:

Das Pricing unterscheidet sich grundlegend von den traditionellen Preismodellen, die BigQuery seit Längerem hatte. Das neue Modell basiert auf dem Konzept der Slot/Stunde – einer Gebühr pro Slot für eine Stunde Nutzung, sekundengenau abgerechnet.

Autoscaling rechnet Ihre Nutzung danach ab, wie lange Sie einen Slot tatsächlich verwenden. Die Abrechnung erfolgt sekundengenau, nutzt aber die Stunde als praktischen Bezugspunkt. Wenn Sie also einen einzelnen Slot 900 Sekunden lang nutzen (eine Viertelstunde in Sekunden), werden Ihnen 0,25 Slot/Stunden berechnet. Bei 3.600 Sekunden (eine Stunde) sind es 1,0 Slot/Stunden. Da Sie für einen Job in der Regel mehr als einen einzelnen Slot nutzen, multiplizieren Sie diesen Wert mit der Anzahl der genutzten Slots, um die abgerechneten Slot/Stunden zu erhalten.

Was zur Preisberechnung noch fehlt, sind die Kosten pro Slot/Stunde – diese liegen für die Public Preview bei 0,06 USD pro Slot/Stunde. Beachten Sie, dass sich dieser Wert ändern kann, da das Feature noch in der Preview ist.

Die Gesamtformel zur Bestimmung der Kosten eines Jobs lautet:

Preis = 0,06 * (<genutzte Slots> * (<genutzte Sekunden>/3600))

Auf den ersten Blick nicht ganz einfach – im Kern multiplizieren Sie die genutzten Slots mit den Stunden der Nutzung (genutzte Sekunden / 3600 Sekunden). Es sieht komplizierter aus, als es ist.

Genau dafür haben wir einen Rechner erstellt, mit dem Sie Preise einfacher bestimmen und vergleichen können. Hinweis: Der Rechner ist schreibgeschützt – legen Sie also zunächst eine Kopie in Ihrer Workspace-Umgebung an, um optimal damit arbeiten zu können.

Da es sich um ein neues Feature von Google handelt, gibt es passende neue Pricing-SKUs, mit denen Sie Ihre Ausgaben in der DoiT Console (vormals Cloud Management Platform bzw. CMP) nachverfolgen können.

Die Slot/Stunde-Kosten werden über eine SKU mit folgendem Namen abgerechnet:

BigQuery Autoscale Preview for US (multi-region)

Die ID dieser SKU lautet: B8BE-01DC-0ECF

Annual Commitments (siehe unten) werden über eine SKU mit folgendem Namen abgerechnet:

BigQuery Autoscale Preview 1 Year for US (multi-region)

Die ID hierfür lautet: C0F6–38AB-6629

Region bzw. Multi-Region unterscheiden sich in den SKU-Namen, das Format bleibt jedoch über alle Regionen hinweg gleich.

Wie beim Flat-Rate-Pricing gibt es auch bei Autoscaling ein Commitment-Feature: Sie können sich für einen festgelegten Zeitraum auf eine bestimmte Slot-Anzahl (in 100er-Schritten) festlegen und erhalten dafür einen günstigeren Preis. Sie funktionieren wie Flat-Rate-Commitments, allerdings sind bei Autoscaling nur jährliche Commitments möglich. Sie gelten – wie bei Flat-Rate-Commitments – pro Region oder pro Multi-Region. Sie müssen sie also genau in der Region oder Multi-Region nutzen, in der sie erworben wurden, um die Einsparungen zu realisieren.

*Hinweis: Beim Abschluss eines Commitments wird Ihnen der gesamte Commit-Wert berechnet – analog zu einem Flat-Rate-Commitment. Die Abrechnung erfolgt genauso wie bei Flat-Rate-Commitments.

Der Preis für ein jährliches Commitment beträgt 0,05 USD pro Slot/Stunde, gekauft in 100er-Schritten. Das entspricht etwa 3.504 USD pro Monat für 100 Slots, gegenüber rund 4.380 USD pro Monat für 100 Slots im Dauerbetrieb über einen ganzen Monat (bei angenommenen 730 Stunden pro Monat) ohne Commitment.

Der einfachste Weg vom Flat-Rate-Billing zu Autoscaling ist, die Reservation einfach von Flat-Rate auf Autoscaling umzustellen. Google hat den Wechsel sehr unkompliziert gestaltet – Reservations müssen nicht gelöscht und neu angelegt werden.

Der Wechsel von On-Demand zu Autoscaling (oder Flat-Rate) ist etwas aufwendiger. Ich empfehle dringend, vorab Googles Dokumentation zum Thema hier zu lesen und anschließend den Schritten zur Erstellung einer Reservation zu folgen – mit dem Unterschied, dass Sie im Menü Autoscaling statt Flat-Rate auswählen.

Diese Frage stellen sich vermutlich viele BigQuery-Nutzer, weil sie es schlicht nicht wissen. Keine Sorge – wir haben passende Werkzeuge für Sie!

In einer früheren Artikelserie zur BigQuery-Kostenoptimierung habe ich in einem GitHub-Repository mehrere BigQuery-Abfragen veröffentlicht, die genau dabei helfen. Achten Sie vor der Ausführung von Abfragen aus diesem Repository auf das gescannte Datenvolumen – einige davon können problemlos riesige Datenmengen verarbeiten (>2 TB bei manchen unserer internen Datasets).

Da das Thema sehr umfangreich ist und weit über den Rahmen dieses Artikels hinausgeht, empfehle ich, die folgenden Abfragen auszuführen:

• Slots by Minute Diese Abfrage erstellt eine Zeitreihe über den gewählten Zeitraum und zeigt die Anzahl der in der jeweiligen Minute genutzten Slots.
• Top Complex Queries Diese Abfrage liefert die komplexesten Queries (in diesem Fall definiert über die meisten genutzten Slots) im angegebenen Zeitraum zurück.
• Job Information Diese Abfrage liefert Statistiken zu einer Job-ID zurück, einschließlich der Slot-Informationen. Sehr nützlich, wenn Sie feststellen, dass ein Job Performance-Probleme hat, und prüfen möchten, ob er für eine schnellere Ausführung zusätzliche Slots benötigt.