Teilen über

Entwerfen resilienter Anwendungen mit Azure Cosmos DB SDKs

  • Artikel

GILT FÜR: NoSQL

Beim Erstellen von Clientanwendungen, die über eines der SDKs mit Azure Cosmos DB interagieren, ist es wichtig, einige wichtige Grundlagen zu verstehen. Dieser Artikel ist ein Entwurfsleitfaden, der Ihnen hilft, diese Grundlagen zu verstehen und resiliente Anwendungen zu entwerfen.

Übersicht

Eine Übersicht über die in diesem Artikel erläuterten Konzepte als Video finden Sie unter:

Konnektivitätsmodi

Azure Cosmos DB SDKs können in zwei Konnektivitätsmodi eine Verbindung mit dem Dienst herstellen. Die .NET und Java SDKs können sowohl im Gateway- als auch im direkten Modus eine Verbindung mit dem Dienst herstellen, während die anderen nur im Gatewaymodus eine Verbindung herstellen können. Im Gatewaymodus wird das HTTP-Protokoll und im direkten Modus normalerweise das TCP-Protokoll verwendet.

Der Gatewaymodus wird immer verwendet, um Metadaten wie das Konto, den Container und Routinginformationen abzurufen, unabhängig davon, für welchen Modus das SDK konfiguriert ist. Diese Informationen werden im Arbeitsspeicher zwischengespeichert und zum Herstellen einer Verbindung mit den Dienstreplikaten verwendet.

Zusammenfassend lässt sich sagen, dass Sie bei SDKs im Gatewaymodus mit HTTP-Datenverkehr rechnen können, während Sie bei SDKs im direkten Modus unter verschiedenen Umständen (z. B. Initialisierung, Abrufen von Metadaten oder Routinginformationen) eine Kombination aus HTTP- und TCP-Datenverkehr erwarten können.

Clientinstanzen und -verbindungen

Unabhängig vom Konnektivitätsmodus ist es wichtig, eine Singleton-Instanz des SDK-Clients pro Konto und Anwendung zu verwalten. Verbindungen, sowohl HTTP als auch TCP, sind auf die Clientinstanz beschränkt. Die meisten Computeumgebungen weisen Einschränkungen hinsichtlich der Anzahl von Verbindungen auf, die gleichzeitig geöffnet werden können. Wenn diese Grenzen erreicht sind, wird die Konnektivität beeinträchtigt.

Verteilte Anwendungen und Netzwerke

Beim Entwerfen verteilter Anwendungen gibt es drei Hauptkomponenten:

  • Ihre Anwendung und die Umgebung, in der sie ausgeführt wird.
  • Das Netzwerk, das alle Komponenten zwischen Ihrer Anwendung und dem Azure Cosmos DB-Dienstendpunkt enthält.
  • Der Azure Cosmos DB-Dienstendpunkt.

Wenn Fehler auftreten, fallen sie häufig in einen dieser drei Bereiche, und es ist wichtig zu verstehen, dass es aufgrund der verteilten Natur des Systems unpraktikabel ist, eine 100%ige Verfügbarkeit für jede dieser Komponenten zu erwarten.

Azure Cosmos DB bietet einen umfassenden Satz von Verfügbarkeits-SLAs, aber keine davon beläuft sich auf 100 %. Die Netzwerkkomponenten, die Ihre Anwendung mit dem Dienstendpunkt verbinden, können vorübergehende Hardwareprobleme aufweisen und Pakete verlieren. Selbst die Computeumgebung, in der Ihre Anwendung ausgeführt wird, kann eine CPU-Spitze aufweisen, die sich auf Vorgänge auswirkt. Diese Fehlerbedingungen können sich auf die Vorgänge der SDKs auswirken und treten normalerweise als Fehler mit bestimmten Codes auf.

Ihre Anwendung sollte gegenüber einem bestimmten Maß an potenziellen Fehlern in diesen Komponenten resilient sein, indem Sie Wiederholungsrichtlinien für die von den SDKs bereitgestellten Antworten implementieren.

Sollte meine Anwendung bei Fehlern einen Wiederholungsversuch unternehmen?

Die kurze Antwort lautet ja. Aber nicht bei allen Fehlern ist es sinnvoll, einen Wiederholungsversuch zu unternehmen, da einige der Fehler- oder Statuscodes nicht vorübergehend sind. Diese sind in der nachstehenden Tabelle im Einzelnen beschrieben:

Statuscode Wiederholungsversuch hinzufügen Wiederholungsversuch für SDKs BESCHREIBUNG
400 Nein Nein Ungültige Anforderung
401 Nein Nein Nicht autorisiert
403 Optional Nein Verboten
404 Nein Nein Ressource nicht gefunden
408 Ja Ja Timeout bei der Anforderung
409 Nein Nein Ein Konflikt tritt auf, wenn die Identität (ID und Partitionsschlüssel), die für eine Ressource bei einem Schreibvorgang bereitgestellt wurde, bereits von einer vorhandenen Ressource verwendet wird, oder eine Einschränkung für eindeutige Schlüssel verletzt wird.
410 Ja Ja Frühere Ausnahmen (vorübergehender Fehler, der nicht gegen die SLA verstößt)
412 Nein Nein Fehler bei Vorbedingung: Bei dem Vorgang wurde ein ETag angegeben, das sich von der auf dem Server verfügbaren Version unterscheidet. Es liegt also ein Fehler mit optimistischer Nebenläufigkeit vor. Wiederholen Sie die Anforderung nach dem Lesen der neuesten Version der Ressource und dem Aktualisieren des eTag für die Anforderung.
413 Nein Nein Anforderungsentität zu groß
429 Ja Ja Bei einem Fehler vom Typ 429 kann der Vorgang sicher wiederholt werden. Lesen Sie den Leitfaden zur Problembehandlung für HTTP 429.
449 Ja Ja Vorübergehender Fehler, der nur bei Schreibvorgängen auftritt und bei dem der Vorgang sicher wiederholt werden kann. Dieser Fehler kann auf ein Entwurfsproblem hinweisen, bei dem zu viele gleichzeitige Vorgänge versuchen, dasselbe Objekt in Azure Cosmos DB zu aktualisieren.
500 Nein No Der Vorgang war aufgrund eines unerwarteten Dienstfehlers fehlerhaft. Senden Sie eine Azure-Supportanfrage, um den Support zu kontaktieren.
503 Ja Ja Dienst nicht verfügbar

In der obigen Tabelle sollten alle Statuscodes in der zweiten Spalte, die mit Ja gekennzeichnet sind, in Ihrer Anwendung bis zu einem gewissen Grad durch Wiederholungen abgedeckt sein.

HTTP 403

Die Azure Cosmos DB SDKs führen bei HTTP 403-Fehlern im Allgemeinen keine Wiederholungsversuche durch, doch gibt es bestimmte Fehler im Zusammenhang mit HTTP 403, auf die Ihre Anwendung möglicherweise reagiert. Wenn Sie beispielsweise eine Fehlermeldung erhalten, dass ein Partitionsschlüssel voll ist, können Sie den Partitionsschlüssel des Dokuments ändern, das Sie basierend auf einer Geschäftsregel zu schreiben versuchen.

HTTP 429

Die Azure Cosmos DB SDKs führen bei HTTP 429-Fehlern standardmäßig Wiederholungsversuche unter Beachtung der Clientkonfiguration und des Antwortheaders x-ms-retry-after-ms des Diensts durch, indem sie die angegebene Zeit warten und den Vorgang danach wiederholen.

Wenn die Anzahl der SDK-Wiederholungsversuche überschritten ist, wird der Fehler an Ihre Anwendung zurückgegeben. Im Idealfall kann die Überprüfung des Headers x-ms-retry-after-ms in der Antwort als Hinweis verwendet werden, um zu entscheiden, wie lange gewartet werden soll, bevor die Anforderung wiederholt wird. Eine andere Alternative wäre ein exponentieller Backoffalgorithmus oder das Konfigurieren des Clients für erweiterte Wiederholungsversuche bei HTTP 429.

HTTP 449

Die Azure Cosmos DB SDKs führen bei HTTP 449 zur Unterstützung der meisten Szenarien Wiederholungsversuche mit einem inkrementellen Backoff während eines festen Zeitraums durch.

Wenn die Anzahl der automatischen SDK-Wiederholungsversuche überschritten ist, wird der Fehler an Ihre Anwendung zurückgegeben. HTTP 449-Fehler können sicher wiederholt werden. Aufgrund der hohen Anzahl gleichzeitiger Schreibvorgänge ist es besser, einen zufälligen Backoffalgorithmus zu verwenden, um zu vermeiden, dass sich derselbe Grad an Parallelität nach einem festen Intervall wiederholt.

Netzwerktimeouts und Konnektivitätsfehler gehören zu den häufigsten Fehlern. Die Azure Cosmos DB SDKs sind selbst resilient und führen Wiederholungsversuche bei Timeouts und Konnektivitätsproblemen für alle HTTP- und TCP-Protokolle durch, wenn die Wiederholung möglich ist:

  • Bei Lesevorgängen führen die SDKs Wiederholungsversuche für alle Timeout- oder Verbindungsfehler durch.
  • Bei Schreibvorgängen führen die SDKs keine Wiederholungsversuche durch, da diese Vorgänge nicht idempotent sind. Wenn beim Warten auf die Antwort ein Timeout auftritt, ist es unmöglich zu wissen, ob die Anforderung den Dienst erreicht hat.

Wenn für das Konto mehrere Regionen verfügbar sind, unternehmen die SDKs auch einen regionsübergreifenden Wiederholungsversuch.

Aufgrund der Art von Timeouts und Konnektivitätsfehlern werden diese möglicherweise nicht in Ihren Kontometriken angezeigt, da sie nur dienstseitige Fehler abdecken.

Es wird empfohlen, dass Anwendungen über eine eigene Wiederholungsrichtlinie für diese Szenarien verfügen und das Beheben von Timeouts für Schreibvorgänge berücksichtigt wird. Ein Wiederholungsversuch bei einem Erstellungstimeout kann z. B. zu einem HTTP 409-Fehler (Konflikt) führen, wenn die vorherige Anforderung den Dienst erreicht hat. Im anderen Fall wäre dies jedoch erfolgreich.

Details zur sprachspezifischen Implementierung

Weitere Implementierungsdetails für eine bestimmte Sprache finden Sie unter:

Wirken sich Wiederholungen auf die Latenz aus?

Aus Clientsicht wirken sich alle Wiederholungen auf die End-to-End-Latenz eines Vorgangs aus. Wenn die P99-Latenz Ihrer Anwendung beeinträchtigt wird, ist es wichtig zu verstehen, welche Wiederholungen auftreten und wie damit umzugehen ist.

Azure Cosmos DB SDKs bieten ausführliche Informationen in ihren Protokollen und Diagnosen, mit denen Sie ermitteln können, welche Wiederholungen stattfinden. Weitere Informationen finden Sie unter Sammeln von .NET SDK-Diagnosen und Sammeln von Java SDK-Diagnosen.

Wie kann ich die Wiederholungslatenz verringern?

Abhängig von den Umständen leitet das SDK Anforderungen entweder an die lokale Region, die Schreibregion (in einem Schreibszenario mit einzelner Region) oder die erste Region in der Liste der bevorzugten Regionen weiter. Diese Priorisierung minimiert die Latenz in fehlerfreien Szenarios, indem in erster Linie eine Verbindung mit dem nächstgelegenen oder optimalsten Rechenzentrum hergestellt wird.

Diese Priorisierung bedeutet jedoch auch, dass Anforderungen, die zu einem Fehler führen, immer in einer bestimmten Region zuerst für ein bestimmtes Fehlerszenario versucht werden. Wenn ein Failover in eine andere Region in diesem Szenario bevorzugt wird, wird dies in der Regel auf der Infrastrukturebene (Datenverkehrs-Manager) und nicht auf SDK-Ebene behandelt. Die ordnungsgemäße Einrichtung und Konfiguration Ihrer Infrastruktur kann sicherstellen, dass der Datenverkehr während regionaler Ausfälle effizient umgeleitet wird, wodurch die Latenz, die mit regionsübergreifenden Wiederholungsversuchen in einem Ausfallszenario einhergehen kann, beeinträchtigt wird. Ausführlichere Informationen zum Einrichten eines Failovers auf Infrastrukturebene finden Sie in der Dokumentation zu Azure Traffic Manager. Einige SDKs unterstützen die Implementierung ähnlicher Failoverstrategien direkt auf SDK-Ebene. Weitere Informationen finden Sie z. B. unter Hochverfügbarkeit für Java SDK-.

Was ist mit regionalen Ausfällen?

Die Azure Cosmos DB SDKs decken die regionale Verfügbarkeit ab und können Wiederholungen in anderen Kontoregionen durchführen. Informationen dazu, bei welchen Szenarien andere Regionen einbezogen sind, finden Sie im Artikel zu Wiederholungsszenarien und Konfigurationen für Umgebungen mit mehreren Regionen.

Wann sollten Sie sich an den Kundensupport wenden?

Bevor Sie sich an den Kundensupport wenden, gehen Sie die folgenden Schritte durch:

  • Wie groß ist die Auswirkung gemessen an der Menge der betroffenen Vorgänge im Vergleich zu den erfolgreichen Vorgängen? Liegt dieser Wert innerhalb der Dienst-SLAs?
  • Ist die P99-Latenz betroffen?
  • Stehen die Fehler im Zusammenhang mit Fehlercodes, für die meine Anwendung Wiederholungsversuche durchführen sollte, und deckt die Anwendung solche Wiederholungen ab?
  • Betreffen die Fehler alle Ihre Anwendungsinstanzen oder nur einen Teil? Wenn sich das Problem auf einen Teil der Instanzen beschränkt, handelt es sich in der Regel um ein Problem, das mit diesen Instanzen in Zusammenhang steht.
  • Sind Sie die entsprechenden Dokumente zur Problembehandlung in der obigen Tabelle durchgegangen, um ein Problem in der Anwendungsumgebung auszuschließen?

Wenn alle Anwendungsinstanzen betroffen sind oder der Prozentsatz der betroffenen Vorgänge außerhalb der Dienst-SLAs liegt oder Ihre eigenen Anwendungs-SLAs und P99s beeinträchtigt, wenden Sie sich an den Kundensupport.

Nächste Schritte