Wenn Sie Pub/Sub-Messwerte als Signal für das Autoscaling Ihrer Pipeline verwenden, finden Sie hier einige Empfehlungen.
Mehr als ein Signal für das Autoscaling Ihrer Pipeline verwenden
Verwenden Sie nicht nur Pub/Sub-Messwerte für das Autoscaling Ihrer Pipeline. 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 das Hochskalieren dazu führen kann, dass die Clientaufgaben mehr Arbeit verarbeiten. Einige Beispiele für Signale aus anderen Cloud-Produkten, die Sie für Ihre Pipeline verwenden können, sind:
Compute Engine unterstützt das Autoscaling basierend auf Signalen wie der CPU-Auslastung und Monitoring-Messwerten. Compute Engine unterstützt auch mehrere Messwerte und mehrere Signale für eine bessere Zuverlässigkeit.
Weitere Informationen zum Skalieren mit Monitoring-Messwerten finden Sie unter Basierend auf Monitoring-Messwerten skalieren. Weitere Informationen zum Skalieren mit der CPU-Auslastung finden Sie unter Basierend auf der CPU-Auslastung skalieren.
Das horizontale Pod-Autoscaling (Horizontal Pod Autoscaling, HPA) von Google Kubernetes Engine unterstützt das Autoscaling basierend auf der Ressourcennutzung wie CPU- und Arbeitsspeichernutzung, benutzerdefinierten Kubernetes-Messwerten und externen Messwerten wie Monitoring-Messwerten für Pub/Sub. Es unterstützt auch mehrere Signale.
Weitere Informationen finden Sie unter Horizontales Pod-Autoscaling.
Regionale Version der Messwerte anstelle von globalen Versionen verwenden
Pub/Sub bietet zwei Versionen jedes Messwerts, der normalerweise mit dem Autoscaling verwendet wird. Verwenden Sie die Versionen mit dem Suffix by_region:
Verwenden Sie nicht die globalen Versionen dieser Messwerte, wenn Ihr Autoscaling widerstandsfähig gegen Ausfälle in einzelnen Regionen 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. Im Gegensatz dazu werden bei den by_region-Versionen der Messwerte der Rückstand pro Region berechnet und gemeldet. Wenn der Rückstand für eine einzelne Region nicht berechnet werden kann, werden für die anderen Regionen trotzdem Werte gemeldet.
Durchsatzmesswerte auf Abonnentenseite nicht für das Autoscaling von Abonnenten verwenden
Verwenden Sie keine Durchsatzmesswerte auf Abonnentenseite wie subscription/ack_message_count für das Autoscaling von Abonnenten-Clients. Verwenden Sie stattdessen Messwerte, die den Rückstand von Nachrichten widerspiegeln, die noch verarbeitet werden müssen, 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. Das Skalieren basierend auf solchen Messwerten kann zu einer selbstbezüglichen Schleife führen, bei der eine Abnahme der zugestellten oder bestätigten Nachrichten zu einer Herunterskalierung der Clients führt. Dies kann beispielsweise auftreten, wenn es einen vorübergehenden Rückgang des Traffics gibt oder ein Problem mit einem Ihrer Abonnenten vorliegt.
Wenn Ihre Clients auf null oder fast null herunterskaliert werden, kann der gesamte laufende Abonnenten-Traffic eingestellt werden und Abonnenten können möglicherweise keine Nachrichten verarbeiten, auch wenn neue Nachrichten eingehen. Dies kann zu einer erheblichen Verzögerung bei der Aufnahme und zu einem nicht wiederherstellbaren Zustand für Ihre Abonnenten-Clients führen.
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 Verarbeitungsaufgaben auf null herunterskalieren, werden Nachrichten, die sich bereits im Rückstand befinden oder die während 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, damit Sie immer bereit sind, 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 der Replikate beibehalten wird, wenn keine Messwerte verfügbar sind. Dies bietet ein Sicherheitsnetz, wenn 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.