Mit Lasttests für Ihren Cloud Run-Dienst können Sie feststellen, ob er bei der Nutzung in der Produktion erfolgreich skaliert. Mit Lasttests können Sie auch Engpässe erkennen, die die Skalierung Ihres Dienstes verhindern.
Tests, die vor dem Lasttest durchgeführt werden sollten
Identifizieren und beheben Sie Nebenläufigkeitsprobleme in einer Entwicklungs- oder kleinen Testumgebung, bevor Sie mit den Lasttests fortfahren. Messen Sie die Container-Nebenläufigkeit, bevor Sie einen Lasttest durchführen, und achten Sie darauf, dass Ihr Cloud Run-Dienst zuverlässig gestartet wird.
Konzentrieren Sie sich bei Ihren Containertests auf kleine inkrementelle Zählungen in manuell skalierten Ausführungen. Sie können die manuelle Skalierung in Cloud Run angleichen. Dazu setzen Sie maximale Instanzen auf den Wert, auf den Sie skalieren möchten.
Wenn Sie Ihr Container-Image erst kürzlich erstellt oder geändert haben, sollten Sie dies unabhängig voneinander testen, bevor Sie einen Lasttest durchführen.
Sie sollten auch andere Arten von Leistungsproblemen wie übermäßige Latenz und CPU-Auslastung prüfen, bevor Sie einen umfangreichen Lasttest ausführen.
max instances korrekt verwenden
Cloud Run erzwingt eine maximale Anzahl von Instanzen, um die Skalierung eines Dienstes zu begrenzen. Die standardmäßige maximale Anzahl von Instanzen beträgt 100. Wenn Sie davon ausgehen, dass Ihr Lasttest diesen Standardwert überschreitet, sollten Sie sich an Ihr Account-Management-Team bei Google wenden und einen neuen Höchstwert festlegen. Wenn Sie noch keine Geschäftsbeziehung zu einem Account-Management-Team haben, wenden Sie sich an den Google Cloud -Vertrieb.
Die maximale Anzahl der Instanzen, die Sie auswählen können, hängt von Ihren CPU- und Speicherlimits sowie von der Region ab, in der Sie die Bereitstellung vornehmen.
Diese Limits werden durch ein Kontingentlimit verwaltet und können durch einen Anfrage zur Erhöhung des Kontingentlimits erhöht werden.
Lasttest in der Region europe-west1
Die Region Google Cloud europe-west1 bietet ein hohes Kontingentlimit. Google empfiehlt daher, Lasttests in europe-west1 durchzuführen.
Stimmen Sie sich mit Ihrem Account-Management-Team ab und reichen Sie einen Supportfall mit Angaben zu Zeit und Umfang des Tests ein, wenn Sie sich den Kontingentlimits nähern wollen.
Testen Sie ein geeignetes CPU-Auslastungs- und Dienstinitialisierungsprofil.
Im Idealfall stellen Sie eine Testversion Ihres Dienstes in Cloud Run bereit und führen direkt einen Lasttest durch. In einigen Fällen können Sie jedoch möglicherweise keine Testversion Ihres Dienstes bereitstellen. Ihr Cloud Run-Dienst ist möglicherweise Teil eines komplexen Ökosystems, das sich in einer Testumgebung nur schwer replizieren lässt.
In diesen Fällen können Sie die Leistung Ihres Dienstes annähernd simulieren, indem Sie ihn mit einem einfacheren Dienst simulieren, der eine vergleichbare CPU-Auslastung und vergleichbare Initialisierungszeiten hat.
Die Initialisierungszeit ist besonders wichtig für eine schnelle Skalierung. Denken Sie daran, dass es auch problematisch ist, mit etwas zu Einfachem zu testen. Vermeiden Sie beispielsweise Tests mit einem einfachen hello world-Dienst, der empfangene Anfragen ohne Verarbeitung zurückgibt.
Mit einem Test-Harnisch Lasten generieren
Sie können Testlasten generieren, die einen kontrollierten Traffic-Anstieg verursachen, indem Sie einen Test-Harnisch nutzen (z. B. JMeter). Sie können die Anzahl der JMeter-Threadgruppen und die Verzögerung zwischen Anfragen im JMeter-Test verwenden, um die Last zu erhöhen.
Sie können auch einfache HTTP-Anfragen senden oder eine Browsersitzung mit JMeter aufzeichnen. Mit Cloud Run können Sie Ihren Dienst ohne Internetzugriff mithilfe der Entwicklerauthentifizierung testen. Dies ermöglicht den Zugriff von einem Test-Harnisch wie JMeter, der auf einer virtuellen Compute Engine-Maschine ausgeführt wird, die mit einer mit dem Projekt verbundenen Virtual Private Cloud (VPC) verbunden ist.
Generieren Sie keine Last mit Tools, bei denen die Rate und die Nebenläufigkeit nicht gesteuert werden können. Pub/Sub ist eine schlechte Wahl für die Generierung von Last, da Sie die Rate des Traffics und die Anzahl der Clients nicht steuern können. Wenn Sie die Rate und die Nebenläufigkeit nicht kennen, wissen Sie nicht, was Sie testen.
Detaillierte Loganalyse mit exportierten Logs verwenden
Sie benötigen eine sekundengenaue Analyse der Ereignisse, um zu verstehen, wie Ihr Cloud Run-Dienst auf schnelle Traffic-Spitzen reagiert. Dazu ist eine Logging-Analyse erforderlich, da die Granularität der Monitoring-Daten nicht fein genug ist. Mit der Loganalyse können Sie auch die Gründe für Anfragen mit hoher Latenz untersuchen.
Wenn Sie Logs schreiben, können Sie die Logging-Leistung verbessern, indem Sie direkt in stdout schreiben, anstatt eine Cloud Logging-Clientbibliothek zu verwenden.
Wenn Sie einen Logexport vor Beginn des Tests einrichten möchten, erstellen Sie eine Logsenke mit dem Ziel BigQuery und einem „Einschließen“-Filter, z. B.:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Falsche Kaltstarts vermeiden
Um die von Nutzern erlebten Kaltstarts zu minimieren, legen Sie die Mindestanzahl von Instanzen auf mindestens 1 fest.
Sicherstellen, dass Ihr Dienst horizontal skaliert
Wiederholen Sie den Test bei verschiedenen Lasten, damit Sie sicher sein können, dass Ihr Cloud Run-Dienst linear mit der Last horizontal skaliert und nicht bei einer Last, die geringer ist als die, die Sie in der Produktion erwarten, einen begrenzenden Engpass erreicht.
Ergebnisse in Colaboratory analysieren und visualisieren
Verwenden Sie die Zusammenfassungsdiagramme, um sich einen Überblick über die Ergebnisse zu verschaffen und die detaillierte Loganalyse mit exportierten Logs zu ergänzen.
Mithilfe der Monitoring-Diagramme können Sie Folgendes herausfinden:
- Wie schnell werden neue Instanzen auf die Sekunde genau erstellt und initialisiert?
- Wie gleichmäßig werden Anfragen auf verschiedene Instanzen verteilt?
- Wie schnell kann die Latenz bei verschiedenen Perzentilen auf einen stabilen Wert gesenkt werden?
Sie können die Benutzeroberfläche der Google Cloud Console für BigQuery verwenden, um das exportierte Logschema zu prüfen und eine Vorschau der Ergebnisse aufzurufen. Führen Sie die Abfragen aus und stellen Sie die Ergebnisse mit Colab dar, das bereits in BigQuery, Pandas und Matplotlab integriert ist. Colab lässt sich auch einfach in umfangreiche Datenvisualisierungstools wie Seaborn einbinden.
Engpässe finden
Mit Lasttests können Sie sowohl ineffizienten Code als auch Skalierungsengpässe erkennen. Ineffizienter Code führt zu höheren Kosten, da mehr Traffic verarbeitet werden muss, verhindert aber nicht unbedingt die Skalierung. So kann beispielsweise eine Abhängigkeit von einer Datenbankübersetzung mit Sperrung auf Tabellenebene einen Engpass darstellen, der eine Skalierung des Cloud Run-Dienstes verhindert, da nur eine Transaktion gleichzeitig ausgeführt werden kann.
Leistung prüfen, wie sie der Kunde erlebt
Sie können von JMeter erfasste Logs abfragen, wobei die Logs die am Client gemessenen Latenzen enthalten. Da Servertesttools wie JMeter nicht mit einem Browser oder mobilen Client identisch sind, können Sie auch einen Test mit einem browserbasierten Framework ausführen, wie z. B. Selenium Webdriver oder ein mobiles Testframework für Clients. Achten Sie auf übermäßige maximale Latenzen aufgrund der Initialisierung der TLS-Verbindung, die die Ergebnisse mit Ausreißern verfälschen können.
Zusammenfassung der Best Practices
Führen Sie einen Lasttest durch, um festzustellen, ob die Migration zu Cloud Run die richtige Wahl ist und ob Ihr Dienst auf den maximal erwarteten Traffic skaliert werden kann. Führen Sie den Test mit einem Harnisch wie JMeter aus. Logs zur detaillierten Analyse nach BigQuery exportieren.