Wenn Sie Pub/Sub-Messwerte als Signal für die automatische Skalierung Ihrer Pipeline verwenden, finden Sie hier einige Empfehlungen.
Mehr als ein Signal für das Autoscaling der Pipeline verwenden
Verwenden Sie zum Autoscaling der Pipeline nicht nur Pub/Sub-Messwerte. 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 der CPU-Auslastungsgrad des Clients. Dieses Signal kann darauf hinweisen, ob die Clientaufgaben Arbeit verarbeiten und ob das Hochskalieren den Clientaufgaben mehr Arbeit ermöglichen kann. Im Folgenden finden Sie einige Beispiele für Signale von anderen Cloud-Produkten, die Sie für Ihre Pipeline verwenden können:
Compute Engine unterstützt Autoscaling auf der Grundlage von Signalen wie 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 zur Skalierung mit CPU-Auslastung finden Sie unter Basierend auf der CPU-Auslastung skalieren.
Horizontales Pod-Autoscaling (HPA) von Google Kubernetes Engine unterstützt das Autoscaling auf Basis der Ressourcennutzung wie CPU- und Arbeitsspeichernutzung, 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.
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 Verarbeitungsaufgaben auf null herunterskalieren, werden Nachrichten, die sich bereits im Rückstand befinden oder während dieser Zeit veröffentlicht wurden, möglicherweise nicht verbraucht. Dadurch wird die End-to-End-Latenz erhöht. Um die Latenz zu minimieren, legen Sie eine minimale Aufgabenanzahl größer als null fest, damit Sie immer auf die Verarbeitung veröffentlichter Nachrichten vorbereitet sind, auch wenn die aktuellen Pub/Sub-Messwerte auf eine leere Warteschlange hinweisen.
Sowohl Compute Engine-Autoscaling als auch Google Kubernetes Engine-HPAs sind darauf ausgelegt, die aktuelle Anzahl von Replikaten beizubehalten, wenn keine Messwerte verfügbar sind. Dies bietet ein Sicherheitsnetz, wenn keine Messwerte verfügbar sind.
Sie können auch Pub/Sub-Ablaufsteuerung implementieren, um zu verhindern, dass Aufgaben überlastet werden, wenn sie aufgrund fehlender Messwerte unbeabsichtigt herunterskaliert werden.
Regionale Version der Messwerte verwenden
Pub/Sub bietet zwei Versionen jedes Messwerts, der normalerweise für Autoscaling verwendet wird. Achten Sie darauf, die Versionen mit dem Suffix by_region zu verwenden:
Verwenden Sie nicht die globalen Versionen dieser Messwerte, wenn das Autoscaling für Ausfälle einzelner Regionen resistent sein soll. Die globale Version dieser Messwerte erfordert die Berechnung des Rückstands für alle Regionen, die bekanntermaßen Nachrichten haben. Dies bedeutet, dass die Nichtverfügbarkeit in einer einzelnen Region zu einer Datenlücke führt. Im Gegensatz dazu berechnen die by_region-Versionen der Messwerte den Rückstand pro Region und melden ihn. Wenn der Rückstand für eine einzelne Region nicht berechnet werden kann, gibt der Messwert dennoch Werte für die anderen Regionen zurück.