Anfragelatenz und Best Practices für Fehlerbehandlung

Auf dieser Seite werden Best Practices zur Optimierung der Anfragelatenz und des Umgangs mit Fehlern in der Cloud Healthcare API beschrieben. Implementieren Sie diese Praktiken beim Planen und Entwerfen Ihrer Systemarchitektur.

Google stellt ein Service Level Agreement (SLA) zur Verfügung, das die erwartete Betriebszeit des Cloud Healthcare API-Dienstes und die Fehlerbehebung für Kunden definiert. Weitere Informationen finden Sie im Service Level Agreement (SLA) für Cloud Healthcare.

Wiederholungslogik und Zeitüberschreitungen implementieren

Implementieren Sie eine geeignete Wiederholungslogik und Zeitüberschreitungen, um Verzögerungen und Fehler zu beheben, die durch fehlgeschlagene Anfragen verursacht werden. Lassen Sie beim Festlegen des Zeitlimits genügend Zeit, um Folgendes zu tun:

• Lassen Sie die Anfrage von der Cloud Healthcare API verarbeiten.
• Ermitteln Sie, ob der Fehler vom Dienst oder vom Client stammt.

Einige Fehler können wiederholt werden. Andere sind nicht wiederholbar und bleiben über mehrere Wiederholungsversuche hinweg bestehen. Wenn die Anfragedaten beispielsweise falsch formatiert sind, antwortet der Server mit dem Statuscode 400 Bad Request. Die Anfrage ist erst erfolgreich, wenn Sie die Daten korrigiert haben.

Um solche Situationen zu bewältigen, müssen Sie endgültige Fehlerstatus einplanen.

Weitere Informationen zur Wiederholungslogik und zu Zeitüberschreitungen finden Sie unter Fehlgeschlagene Anfragen wiederholen.

Fehler auf mehreren Ebenen verarbeiten

Wenn Middleware mit der Cloud Healthcare API interagiert, implementieren Sie die Wiederholungslogik und Zeitüberschreitungen im Client und in der Middleware. Wenn bei einem Client Fehler auftreten, die sein Wiederholungslimit überschreiten, müssen Sie feststellen können, ob der Fehler im Client, in der Middleware oder im zugrunde liegenden Cloud Healthcare API-Dienst aufgetreten ist. Das ist besonders wichtig bei der Planung endgültiger Fehlerzustände.

Stellen Sie sich folgendes Szenario vor:

1. Die Middleware erhält beim Senden einer Anfrage von der Cloud Healthcare API den Fehler 500 Internal Server Error.
2. Die Middleware-Ebene wiederholt die Anfrage fünf weitere Male, bis das Limit erreicht ist, und beendet dann den erneuten Versuch.
3. Der Client erhält den letzten Fehler 500 Internal Server Error.

Es ist wichtig zu verstehen, dass der Fehler in der Cloud Healthcare API und nicht in der Middleware verursacht wurde. Geben Sie diese Informationen in der an den Client zurückgegebenen Fehler an, um die Fehlerbehebung zu vereinfachen.

Das folgende Diagramm zeigt ein Szenario, in dem ein Middleware-Proxy beim Weiterleiten einer Anfrage von einem Client an die Cloud Healthcare API 500 Internal Server Error-Fehler empfängt. Sowohl der Client als auch der Proxy implementieren Fehlerbehandlung und Wiederholungsversuche.

Abbildung 1: Die Ebenen, auf denen Sie die Wiederholungslogik und Zeitüberschreitungen implementieren müssen, sind der Client und der Proxy.

Abbildung 1 zeigt die folgenden Schritte:

1. Der Client sendet über einen Middleware-Proxy eine gültige Anfrage an die Cloud Healthcare API.
2. Der Proxy leitet die Anfrage an die Cloud Healthcare API weiter.
3. Die Cloud Healthcare API gibt den Fehler 500 Internal Server Error an den Proxy zurück. Der Proxy wiederholt die Anfrage fünf weitere Male, bis das Wiederholungslimit erreicht ist.

4. Der Proxy gibt den endgültigen Fehlerstatus 500 Internal Server Error an den Client zurück.

   Mit den zuvor gezeigten Empfehlungen können Sie den endgültigen Fehlerstatus beheben, indem Sie den Proxy den folgenden Fehler an den Client zurückgeben lassen:

   Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

   Fügen Sie weitere Informationen zum von der Cloud Healthcare API zurückgegebenen Fehler hinzu.

Manchmal erhält der Client oder Proxy 500 Internal Server Error-Fehler, nachdem sie ihr Wiederholungslimit überschritten haben und können den Vorgang nicht wiederholen. In diesem Fall muss möglicherweise ein Mensch eingreifen, um festzustellen, ob der Fehler vom Proxy oder der Cloud Healthcare API stammt.

Fehler auswählen, die noch einmal versucht werden sollen

Je nach Systemarchitektur können Sie bestimmte Fehler wiederholen und andere ignorieren. Im Folgenden finden Sie eine unvollständige Liste von wiederholbaren Cloud Healthcare API-Fehlercodes:

• 408 Request Timeout
• 425 Too Early
• 429 Too Many Requests
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

Diese Fehler treten normalerweise nicht in der gleichen Häufigkeit auf und einige treten vielleicht nie auf.

Effekte der Systemarchitektur

Die Architektur Ihres Systems beeinflusst, wie und wann Sie Fehler wiederholen.

Beispielsweise kann sich in einer direkten Client-zu-Server-Architektur ein Client, der den Fehler 401 UNAUTHENTICATED von der Cloud Healthcare API erhält, noch einmal authentifizieren und seine Anfrage wiederholen.

Angenommen, ein System hat eine Middleware-Ebene zwischen dem Client und der Cloud Healthcare API. Wenn der Client korrekt authentifiziert wurde und ein abgelaufenes Authentifizierungstoken das Problem verursacht hat, muss die Middleware das Token aktualisieren und die Anfrage wiederholen.

Nach der Analyse der endgültigen Fehlerstatus können Sie die Fehler, die Ihr Client wiederholt, basierend auf den Ergebnissen anpassen.

Endgültige Fehlerstatus planen

Auch nach der Implementierung von Wiederholungslogik und Zeitüberschreitungen kann ein Client oder eine Middleware Fehler erhalten, bis die Wiederholungen aufgebraucht sind. Der letzte Fehler, der vor Erreichen von Wiederholungsversuchen und Zeitüberschreitungen zurückgegeben wird, ist der endgültige Fehlerstatus. Bei Datenkonsistenzfehlern kann ein endgültiger Fehlerstatus auftreten.

Manchmal erfordert ein endgültiger Fehlerstatus ein menschliches Eingreifen. Versuchen Sie, eine Lösung zu implementieren, um den endgültigen Fehlerstatus für eine Anfrage zu beheben. Andernfalls protokollieren Sie den endgültigen Fehlerstatus, damit er von einem Mitarbeiter überprüft werden kann.

Berücksichtigen Sie bei der Planung des Umgangs mit endgültigen Fehlerstatus Folgendes:

• Gibt an, ob Verarbeitungsabhängigkeiten vorhanden sind, die beendet werden müssen, wenn eine FHIR-Transaktion oder ein FHIR-Bundle nicht erfolgreich abgeschlossen werden kann.
• Wenn viele VM-Instanzen dauerhaft fehlschlagen, muss ein Client die fehlgeschlagenen Anfragen melden. Nachdem das Problem behoben wurde, muss der Client die Anfragen wiederholen.
• Monitoring, Benachrichtigungssysteme und Service Level Objectives (SLOs) sind erforderlich, um die Stabilität Ihres Systems sicherzustellen. Weitere Informationen finden Sie unter Testen und überwachen.

Höhere Latenz planen

Die Cloud Healthcare API ist ein skalierbarer und leistungsfähiger Dienst. Die Latenz von Anfragen kann jedoch aus folgenden Gründen variieren:

• Kleine Unterschiede zwischen den Anfragen können zu zusätzlicher Verarbeitungszeit führen, auch wenn sie unbedeutend erscheinen.
• Ähnliche Anfragen können unterschiedliche Latenzen haben. Beispiel: Zwei ähnliche Anfragen, mit denen dem Datenspeicher ein Datensatz hinzugefügt wird, können unterschiedliche Latenzen haben, wenn eine Anfrage einen Schwellenwert überschreitet, der eine zusätzliche Aufgabe auslöst, z. B. das Zuweisen von mehr Speicher.
• Die Cloud Healthcare API verarbeitet viele Anfragen gleichzeitig. Die Zeit, in der ein Client eine Anfrage sendet, gemessen in Sekundenbruchteilen, kann mit einer Zeit überlappen, in der die Cloud Healthcare API stärker ausgelastet ist als üblich.
• Wenn eine physische Ressource der Cloud Healthcare API, z. B. ein Laufwerk, viele Anfragen verarbeitet, muss sie die in die Warteschlange gestellten Aufgaben abschließen, bevor andere Anfragen verarbeitet werden können.
• Manchmal wiederholt die Cloud Healthcare API Fehler auf der Serverseite, was die Latenz für Clients erhöhen kann.
• Es können mehrere Kopien von Daten in verschiedenen Rechenzentren an einem regionalen oder multiregionalen Standort vorhanden sein. Wenn Ihre Anfragen entweder bei der ursprünglichen Anfrage oder bei einem Wiederholungsversuch über mehrere Rechenzentren weitergeleitet werden, kann sich die Latenz erhöhen.

Mit Perzentillatenz planen

Sie können eine erhöhte Latenz planen, indem Sie die Perzentillatenz Ihrer Anfragen analysieren. In den folgenden Beispielen werden die Latenz des 50. Perzentils und die Latenz des 99. Perzentils beschrieben:

• Die Latenz des 50. Perzentils ist die maximale Latenz in Sekunden für die schnellsten 50% der Anfragen. Wenn die Latenz für das 50. Perzentil beispielsweise 0,5 Sekunden beträgt, hat die Cloud Healthcare API 50% der Anfragen innerhalb von 0,5 Sekunden verarbeitet. Die Latenz des 50. Perzentils wird auch als "mittlere Latenz" bezeichnet.
• Die Latenz des 99. Perzentils ist die maximale Latenz in Sekunden für die schnellsten 99% der Anfragen. Wenn die Latenz des 99. Perzentils beispielsweise zwei Sekunden beträgt, verarbeitete die Cloud Healthcare API 99% der Anfragen innerhalb von zwei Sekunden.

Wenn Sie die Perzentillatenz über ein Intervall analysieren, in dem die Cloud Healthcare API nur wenige Anfragen verarbeitet hat, ist die Perzentillatenz möglicherweise nicht nützlich oder gibt die Gesamtleistung nicht aus, da Ausreißeranfragen einen großen Einfluss haben können.

Angenommen, ein Prozess in der Cloud Healthcare API verarbeitet 100 Anfragen in 100 Minuten. Die Latenz des 99. Perzentils für die 100 Minuten würde auf der einzelnen langsamsten Anfrage basieren. Eine Latenzmessung mit einer einzigen Anfrage reicht nicht aus, um festzustellen, ob Leistungsprobleme vorliegen.

Wenn Sie eine größere Anfragestichprobe über einen längeren Zeitraum wie 24 Stunden erfassen, erhalten Sie einen besseren Einblick in das Gesamtverhalten Ihres Systems. Anhand dieser Beispiele können Sie ermitteln, wie Ihr System auf starken Traffic reagiert.