Best Practices für Anfragelatenz und Fehlerbehandlung

Auf dieser Seite werden Best Practices zum Optimieren der Anfragelatenz und zum Behandeln von Fehlern in der Cloud Healthcare API beschrieben. Implementieren Sie diese Praktiken bei der Planung und Gestaltung Ihrer Systemarchitektur.

Google bietet ein Service Level Agreement (SLA), in dem die erwartete Betriebszeit des Cloud Healthcare API-Dienstes und die Vorgehensweise bei Fehlern definiert sind. Weitere Informationen finden Sie im Service Level Agreement (SLA) für Cloud Healthcare.

Wiederholungslogik und Zeitüberschreitungen implementieren

Um Verzögerungen und Fehler aufgrund fehlgeschlagener Anfragen zu vermeiden, sollten Sie eine geeignete Wiederholungslogik und Zeitüberschreitungen implementieren. Legen Sie die Zeitüberschreitungsdauer so fest, dass ausreichend Zeit für Folgendes bleibt:

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

Einige Fehler können wiederholt werden, andere nicht und bleiben auch nach mehreren Wiederholungsversuchen bestehen. Wenn die Anfragedaten beispielsweise falsch formatiert sind, antwortet der Server mit dem Statuscode 400 Bad Request. Die Anfrage kann erst bearbeitet werden, wenn Sie die Daten korrigiert haben.

Um diese 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 behandeln

Wenn Middleware mit der Cloud Healthcare API interagiert, implementieren Sie die Logik für Wiederholungsversuche und Zeitüberschreitungen im Client und in der Middleware. Wenn bei einem Client Fehler auftreten, die über das Wiederholungslimit hinausgehen, müssen Sie in der Lage sein, festzustellen, ob der Fehler im Client, in der Middleware oder im zugrunde liegenden Cloud Healthcare API-Dienst aufgetreten ist. Das ist besonders wichtig, wenn Sie die endgültigen Fehlerstatus planen.

Stellen Sie sich folgendes Szenario vor:

1. Die Middleware empfängt beim Senden einer Anfrage einen 500 Internal Server Error-Fehler von der Cloud Healthcare API.
2. Die Middleware-Ebene wiederholt die Anfrage fünf weitere Male, erreicht ihr Limit und beendet dann die Wiederholungsversuche.
3. Der Client erhält einen endgültigen 500 Internal Server Error-Fehler.

Es ist wichtig zu wissen, dass der Fehler in der Cloud Healthcare API und nicht in der Middleware aufgetreten ist. Um die Fehlersuche zu vereinfachen, sollten Sie diese Informationen in dem Fehler angeben, der an den Client zurückgegeben wird.

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

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

Abbildung 1 zeigt die folgenden Schritte:

1. Der Client sendet eine gültige Anfrage über einen Middleware-Proxy an die Cloud Healthcare API.
2. Der Proxy leitet die Anfrage an die Cloud Healthcare API weiter.
3. Die Cloud Healthcare API gibt einen 500 Internal Server Error-Fehler 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.

   Mithilfe der oben 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 Fehler hinzu, der von der Cloud Healthcare API zurückgegeben wurde.

Manchmal erhält der Client oder Proxy 500 Internal Server Error-Fehler, nachdem die Wiederholungsversuche ausgeschöpft sind, und kann es nicht noch einmal versuchen. In diesem Fall muss möglicherweise ein Mensch eingreifen, um zu diagnostizieren, ob der Fehler vom Proxy oder von der Cloud Healthcare API stammt.

Auswählen, welche Fehler wiederholt werden sollen

Je nach Architektur Ihres Systems können Sie bestimmte Fehler noch einmal versuchen und andere ignorieren. Im Folgenden finden Sie eine unvollständige Liste der Cloud Healthcare API-Fehlercodes, die wiederholt werden können:

• 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 in der Regel nicht mit derselben Häufigkeit auf und einige treten möglicherweise nie auf.

Auswirkungen der Systemarchitektur

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

In einer direkten Client-Server-Architektur kann ein Client, der einen 401 UNAUTHENTICATED-Fehler von der Cloud Healthcare API empfängt, sich beispielsweise neu authentifizieren und die Anfrage noch einmal senden.

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

Nachdem Sie die endgültigen Fehlerstatus analysiert haben, können Sie die Fehler anpassen, die Ihr Client basierend auf Ihren Ergebnissen noch einmal versucht.

Planen Sie für endgültige Fehlerzustände.

Auch nach der Implementierung von Wiederholungslogik und Zeitüberschreitungen kann es sein, dass ein Client oder eine Middleware Fehler empfängt, bis die Wiederholungsversuche ausgeschöpft sind. Der letzte Fehler, der zurückgegeben wird, bevor Wiederholungen und Zeitüberschreitungen aufgebraucht sind, ist der endgültige Fehlerstatus. Bei Fehlern bei der Datenkonsistenz kann ein endgültiger Fehlerstatus auftreten.

Manchmal erfordert ein endgültiger Fehlerstatus 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 manuell überprüft werden kann.

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

• Ob es Verarbeitungsabhängigkeiten gibt, 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 noch einmal senden.
• Monitoring, Benachrichtigungssysteme und Service Level Objectives (SLOs) sind erforderlich, um die Stabilität Ihres Systems zu gewährleisten. Weitere Informationen finden Sie unter Testen und überwachen.

Mit erhöhter Latenz rechnen

Die Cloud Healthcare API ist ein skalierbarer und leistungsstarker Dienst, aber die Latenz von Anfragen kann aus den folgenden Gründen variieren:

• Kleine Unterschiede zwischen Anfragen, auch wenn sie unbedeutend erscheinen, können zu einer längeren Verarbeitungszeit führen.
• Ähnliche Anfragen können unterschiedliche Latenzen haben. Zwei ähnliche Anfragen, mit denen ein Datensatz dem Datenspeicher hinzugefügt wird, können beispielsweise unterschiedliche Latenzen aufweisen, wenn bei einer Anfrage ein Schwellenwert überschritten wird, der eine zusätzliche Aufgabe auslöst, z. B. die Zuweisung von mehr Speicherplatz.
• Die Cloud Healthcare API verarbeitet viele Anfragen gleichzeitig. Die Zeit, zu der ein Client eine Anfrage sendet, gemessen in Bruchteilen einer Sekunde, kann mit einer Zeit zusammenfallen, in der die Cloud Healthcare API stärker als gewöhnlich ausgelastet ist.
• Wenn eine physische Cloud Healthcare API-Ressource, z. B. eine Festplatte, viele Anfragen verarbeitet, muss sie die in der Warteschlange befindlichen Aufgaben abschließen, bevor sie andere Anfragen verarbeiten kann.
• Manchmal werden Fehler in der Cloud Healthcare API serverseitig noch einmal versucht, was die Latenz für Clients erhöhen kann.
• An einem regionalen oder multiregionalen Standort können mehrere Kopien von Daten in verschiedenen Rechenzentren vorhanden sein. Wenn Ihre Anfragen über mehrere Rechenzentren weitergeleitet werden, entweder bei der ursprünglichen Anfrage oder bei einem Wiederholungsversuch, kann es zu einer erhöhten Latenz kommen.

Planung anhand der Perzentillatenz

Sie können eine erhöhte Latenz einplanen, indem Sie die Latenz nach Perzentil Ihrer Anfragen analysieren. Die folgenden Beispiele beschreiben die Latenz des 50. Perzentils und die Latenz des 99. Perzentils:

• Die Latenz des 50. Perzentils ist die maximale Latenz in Sekunden für die schnellsten 50% der Anfragen. Wenn beispielsweise die Latenz des 50. Perzentils 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 „Medianlatenz“ bezeichnet.
• Die Latenz des 99. Perzentils ist die maximale Latenz in Sekunden für die schnellsten 99% der Anfragen. Wenn beispielsweise die Latenz des 99. Perzentils zwei Sekunden beträgt, hat die Cloud Healthcare API 99% der Anfragen innerhalb von zwei Sekunden verarbeitet.

Wenn Sie die Latenz des Perzentils über ein Intervall analysieren, in dem die Cloud Healthcare API nur wenige Anfragen verarbeitet hat, ist die Latenz des Perzentils möglicherweise nicht nützlich oder repräsentativ für die Gesamtleistung, 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 einzelnen Anfrage reicht nicht aus, um festzustellen, ob Leistungsprobleme vorliegen.

Wenn Sie über einen längeren Zeitraum, z. B. 24 Stunden, eine größere Stichprobe von Anfragen erfassen, können Sie das Gesamtverhalten Ihres Systems besser nachvollziehen. Anhand dieser Beispiele können Sie ermitteln, wie Ihr System auf starken Traffic reagiert.