Wenn Sie Pub/Sub-Messwerte als Signal für das automatische Skalieren Ihrer Pipeline verwenden, finden Sie hier einige Empfehlungen.
Mehr als ein Signal zum automatischen Skalieren Ihrer Pipeline verwenden
Verwenden Sie nicht nur Pub/Sub-Messwerte, um Ihre Pipeline automatisch zu skalieren. Dies kann zu Szenarien führen, in denen Sie einen Single Point of Failure für Ihre Autoscaling-Entscheidungen haben. Verwenden Sie stattdessen eine Kombination von Signalen, um das Autoscaling auszulösen. Ein Beispiel für ein zusätzliches Signal ist die CPU-Auslastung des Clients. Dieses Signal kann angeben, ob die Clientaufgaben Arbeit verarbeiten und ob durch Skalieren mehr Arbeit verarbeitet werden kann. Hier sind einige Beispiele für Signale aus anderen Cloud-Produkten, die Sie für Ihre Pipeline verwenden können:
Compute Engine unterstützt das Autoscaling basierend auf Signalen wie der CPU-Auslastung und Monitoring-Messwerten. Compute Engine unterstützt auch mehrere Messwerte und Signale, um die Zuverlässigkeit zu erhöhen.
Weitere Informationen zur Skalierung mit Monitoring-Messwerten finden Sie unter Anhand von Monitoring-Messwerten skalieren. Weitere Informationen zum Skalieren anhand der CPU-Auslastung finden Sie unter Anhand der CPU-Auslastung skalieren.
Das horizontale Pod-Autoscaling (HPA) von Google Kubernetes Engine unterstützt das Autoscaling basierend auf der Ressourcennutzung wie CPU- und Arbeitsspeicherauslastung, benutzerdefinierten Kubernetes-Messwerten und externen Messwerten wie Monitoring-Messwerten für Pub/Sub. Außerdem werden mehrere Signale unterstützt.
Weitere Informationen finden Sie unter Horizontales Pod-Autoscaling.
Regionale Versionen der Messwerte anstelle von globalen Versionen verwenden
Pub/Sub bietet zwei Versionen der einzelnen Messwerte, die normalerweise für das Autoscaling verwendet werden. Verwenden Sie die Versionen mit dem Suffix by_region:
Verwenden Sie nicht die globalen Versionen dieser Messwerte, wenn Ihr Autoscaling gegen Ausfälle in einzelnen Regionen resistent sein soll. Für die globale Version dieser Messwerte muss der Rückstand in allen Regionen berechnet werden, in denen Nachrichten vorhanden sind. Das bedeutet, dass die Nichtverfügbarkeit in einer einzelnen Region zu einer Datenlücke führt. Bei den by_region-Versionen der Messwerte wird der Backlog dagegen auf regionaler Basis berechnet und gemeldet. Wenn der Backlog für eine einzelne Region nicht berechnet werden kann, werden für die anderen Regionen trotzdem Werte für den Messwert ausgegeben.
Durchsatzmesswerte auf Abonnentenseite nicht für das automatische Skalieren von Abonnenten verwenden
Vermeiden Sie die Verwendung von Durchsatzmesswerten auf Abonnentenseite wie subscription/ack_message_count für das automatische Skalieren von Abonnentenclients. Verwenden Sie stattdessen Messwerte, die den Rückstand von Nachrichten, die auf die Verarbeitung warten, direkt widerspiegeln, z. B. die oben genannten subscription/num_unacked_messages oder subscription/oldest_unacked_message_age.
Probleme bei der Verwendung von Durchsatzmesswerten auf Abonnentenseite für das Autoscaling
Die Verwendung dieser Messwerte kann zu Problemen führen, da sie die Menge des Traffics zwischen Pub/Sub und Abonnenten darstellen. Die Skalierung auf Grundlage eines solchen Messwerts kann zu einer selbstbezüglichen Schleife führen, in der eine Abnahme der zugestellten oder bestätigten Nachrichten zu einer Herunterskalierung der Clients führt. Das kann beispielsweise passieren, wenn es einen vorübergehenden Rückgang des Traffics gibt oder ein Problem mit einem deiner Abonnenten vorliegt.
Wenn Ihre Clients auf null oder fast null skaliert werden, kann der gesamte laufende Abonnenten-Traffic gestoppt werden. Abonnenten können dann möglicherweise keine Nachrichten mehr verarbeiten, auch wenn neue Nachrichten eingehen. Dies kann zu einer erheblichen Verzögerung bei der Aufnahme führen und einen nicht wiederherstellbaren Zustand für Ihre Abonnentenclients verursachen.
Mit Messwertlücken umgehen
Gehen Sie nicht davon aus, dass das Fehlen von Messwerten bedeutet, dass keine Nachrichten verarbeitet werden müssen. Wenn Sie beispielsweise als Reaktion auf fehlende Messwerte die Verarbeitungsvorgänge auf null reduzieren, werden Nachrichten, die sich bereits im Backlog befinden oder in dieser Zeit veröffentlicht werden, möglicherweise nicht verarbeitet. Dadurch erhöht sich die End-to-End-Latenz. Um die Latenz zu minimieren, legen Sie eine Mindestanzahl von Aufgaben fest, die größer als null ist. So sind Sie immer darauf vorbereitet, veröffentlichte Nachrichten zu verarbeiten, auch wenn die aktuellen Pub/Sub-Messwerte eine leere Warteschlange anzeigen.
Sowohl Compute Engine-Autoscaler als auch Google Kubernetes Engine-HPAs sind so konzipiert, dass die aktuelle Anzahl von Replikaten beibehalten wird, wenn keine Messwerte verfügbar sind. So haben Sie ein Sicherheitsnetz, falls keine Messwerte verfügbar sind.
Sie können auch Pub/Sub-Ablaufsteuerungsmechanismen implementieren, um zu verhindern, dass Aufgaben überlastet werden, wenn sie aufgrund fehlender Messwerte unbeabsichtigt herunterskaliert werden.