Best Practices für Anfragelatenz und Fehlerbehandlung

Auf dieser Seite werden Best Practices zum Optimieren der Anfragelatenz und zum Umgang mit Fehlern in der Cloud Healthcare API beschrieben. Implementieren Sie diese Praktiken bei der Planung und dem Design Ihrer Systemarchitektur.

Google stellt ein Service Level Agreement (SLA) bereit, das die erwartete Ausfallzeit des Cloud Healthcare API-Dienstes und die Fehlerbehandlung 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. Achten Sie beim Festlegen der Zeitüberschreitung darauf, dass genügend 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.

Bei einigen Fehlern können Sie einen Wiederholungsversuch starten, bei anderen ist das nicht möglich und sie bleiben auch nach mehreren Versuchen bestehen. Wenn die Anfragedaten beispielsweise falsch formatiert sind, antwortet der Server mit dem Statuscode 400 Bad Request. Die Anfrage kann erst ausgeführt werden, wenn Sie die Daten korrigiert haben.

Für diese Situationen müssen Sie Endfehlerstatus planen.

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

Fehler auf mehreren Ebenen behandeln

Wenn die Middleware mit der Cloud Healthcare API interagiert, implementieren Sie Wiederholungslogik und Zeitüberschreitungen im Client und in der Middleware. Wenn ein Client nach dem Wiederhollimit Fehler auftritt, müssen Sie feststellen können, ob der Fehler beim Client, in der Middleware oder im zugrunde liegenden Cloud Healthcare API-Dienst aufgetreten ist. Das ist besonders wichtig, wenn Sie finale Fehlerstatus planen.

Stellen Sie sich folgendes Szenario vor:

  1. Die Middleware erhält beim Senden einer Anfrage einen 500 Internal Server Error-Fehler von der Cloud Healthcare API.
  2. Die Middleware-Ebene versucht, die Anfrage noch fünfmal zu wiederholen, erreicht das Limit und beendet dann die Wiederholungsversuche.
  3. Der Client erhält einen endgültigen 500 Internal Server Error-Fehler.

Der Fehler stammt nicht von der Middleware, sondern von der Cloud Healthcare API. Gib diese Informationen in dem Fehler zurück, der an den Client zurückgegeben wird, um die Fehlerbehebung zu vereinfachen.

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

Diagramm, in dem dargestellt ist, wo Fehler im Client-/Middleware-/Server-Stack behandelt werden
Abbildung 1: Die Schichten, in denen Sie Wiederholungslogik und Zeitüberschreitungen implementieren müssen, sind der Client und der 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 dem Proxy den Fehler 500 Internal Server Error zurück. Der Proxy versucht, die Anfrage noch fünfmal zu wiederholen, 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 genannten Empfehlungen können Sie den endgültigen Fehlerstatus beheben, indem der Proxy den folgenden Fehler an den Client zurückgibt: 

    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 das Limit für Wiederholungen erreicht wurde, und kann nicht noch einmal versuchen. In diesem Fall muss möglicherweise ein Mitarbeiter 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 noch einmal versuchen.

In einer direkten Client-zu-Server-Architektur kann sich ein Client, der einen 401 UNAUTHENTICATED-Fehler von der Cloud Healthcare API erhält, beispielsweise noch einmal authentifizieren und die Anfrage noch einmal versuchen.

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

Nachdem Sie die endgültigen Fehlerstatus analysiert haben, können Sie die Fehler, die Ihr Kunde noch einmal versucht, anhand Ihrer Ergebnisse anpassen.

Endgültige Fehlerstatus planen

Selbst 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 zurückgegeben wird, bevor die Wiederholungen und Zeitüberschreitungen aufgebraucht sind, ist der Endfehlerstatus. Bei Fehlern bei der Datenkonsistenz kann ein endgültiger Fehlerstatus angezeigt werden.

Manchmal ist für einen endgültigen Fehlerstatus menschliches Eingreifen erforderlich. Implementieren Sie eine Lösung, 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 der Fehlerbehandlung Folgendes:

  • Gibt an, ob Verarbeitungsabhängigkeiten angehalten werden müssen, wenn eine FHIR-Transaktion oder ein FHIR-Bundle nicht erfolgreich abgeschlossen werden kann.
  • Wenn viele VM-Instanzen dauerhaft ausfallen, muss ein Kunde die fehlgeschlagenen Anfragen melden. Nachdem das Problem behoben wurde, muss der Kunde die Anfragen noch einmal versuchen.
  • 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.

Höhere Latenz einplanen

Die Cloud Healthcare API ist ein skalierbarer und leistungsstarker Dienst. Die Anfragelatenz kann jedoch aus den folgenden Gründen variieren:

  • Auch kleine Unterschiede zwischen Anfragen, die auf den ersten Blick unerheblich erscheinen, können zu einer längeren Verarbeitungszeit führen.
  • Ähnliche Anfragen können unterschiedliche Latenzen haben. Beispielsweise können zwei ähnliche Anfragen, die dem Datenspeicher einen Datensatz hinzufügen, unterschiedliche Latenzen haben, wenn eine Anfrage einen Grenzwert überschreitet, der eine zusätzliche Aufgabe auslöst, z. B. die Zuweisung von mehr Speicherplatz.
  • Die Cloud Healthcare API verarbeitet viele Anfragen gleichzeitig. Der Zeitpunkt, zu dem ein Client eine Anfrage sendet, gemessen in Sekundenbruchteilen, fällt möglicherweise mit einer Zeit zusammen, in der die Cloud Healthcare API stärker ausgelastet ist als üblich.
  • Wenn eine physische Cloud Healthcare API-Ressource wie ein Laufwerk viele Anfragen verarbeitet, muss sie die anstehenden Aufgaben abschließen, bevor sie andere Anfragen verarbeitet.
  • Manchmal versucht die Cloud Healthcare API, Fehler auf der Serverseite noch einmal auszuführen, was die Latenz für Clients erhöhen kann.
  • Es kann mehrere Kopien von Daten in verschiedenen Rechenzentren an einem regionalen oder multiregionalen Standort geben. Wenn Ihre Anfragen über mehrere Rechenzentren geleitet werden, entweder bei der ursprünglichen Anfrage oder bei einem erneuten Versuch, kann die Latenz erhöht sein.

Planung mit Perzentillatenz

Sie können eine erhöhte Latenz einplanen, indem Sie die Percentillatenz Ihrer Anfragen analysieren. In den folgenden Beispielen wird 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 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 Perzentillatenz über ein Intervall analysieren, in dem die Cloud Healthcare API nur wenige Anfragen verarbeitet hat, ist sie möglicherweise nicht nützlich oder ein Indikator für die Gesamtleistung, da Ausreißer-Anfragen 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 basiert auf der einzelnen langsamsten Anfrage. Eine Latenzmessung mit einer einzelnen Anfrage reicht nicht aus, um festzustellen, ob Leistungsprobleme vorliegen.

Wenn Sie eine größere Anfragestichprobe über einen längeren Zeitraum erfassen, z. B. 24 Stunden, erhalten Sie mehr Informationen zum Gesamtverhalten Ihres Systems. Anhand dieser Samples können Sie feststellen, wie Ihr System auf einen hohen Traffic reagiert.