Udostępnij za pośrednictwem

Projektowanie odpornych aplikacji przy użyciu zestawów SDK usługi Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL

Podczas tworzenia aplikacji klienckich, które wchodzą w interakcje z usługą Azure Cosmos DB za pomocą dowolnego zestawu SDK, ważne jest, aby zrozumieć kilka kluczowych podstaw. Ten artykuł jest przewodnikiem projektowym, który ułatwia zrozumienie tych podstaw i projektowania odpornych aplikacji.

Omówienie

Aby zapoznać się z omówieniem pojęć omówionych w tym artykule, zobacz:

Tryby łączności

Zestawy SDK usługi Azure Cosmos DB mogą łączyć się z usługą w dwóch trybach łączności. Zestawy SDK platformy .NET i Java mogą łączyć się z usługą zarówno w trybie bramy, jak i w trybie bezpośrednim, podczas gdy inne mogą łączyć się tylko w trybie bramy. Tryb bramy używa protokołu HTTP i trybu bezpośredniego zwykle używa protokołu TCP.

Tryb bramy jest zawsze używany do pobierania metadanych, takich jak konto, kontener i informacje o routingu, niezależnie od tego, który tryb SDK jest skonfigurowany do użycia. Te informacje są buforowane w pamięci i są używane do łączenia się z replikami usługi.

Podsumowując, w przypadku zestawów SDK w trybie bramy można oczekiwać ruchu HTTP, natomiast w przypadku zestawów SDK w trybie bezpośrednim można oczekiwać kombinacji ruchu HTTP i TCP w różnych okolicznościach (na przykład inicjowania lub pobierania metadanych lub informacji o routingu).

Wystąpienia i połączenia klienta

Niezależnie od trybu łączności ważne jest zachowanie pojedynczego wystąpienia klienta zestawu SDK na konto na aplikację. Połączenia, zarówno HTTP, jak i TCP, są ograniczone do wystąpienia klienta. Większość środowisk obliczeniowych ma ograniczenia dotyczące liczby połączeń, które mogą być otwarte w tym samym czasie, a po osiągnięciu tych limitów łączność będzie miała wpływ.

Aplikacje i sieci rozproszone

Podczas projektowania aplikacji rozproszonych istnieją trzy kluczowe składniki:

  • Aplikacja i środowisko, na których działa.
  • Sieć, która obejmuje dowolny składnik między aplikacją a punktem końcowym usługi Azure Cosmos DB.
  • Punkt końcowy usługi Azure Cosmos DB.

Gdy wystąpią awarie, często wchodzą one w jeden z tych trzech obszarów i ważne jest, aby zrozumieć, że ze względu na rozproszony charakter systemu, niepraktyczne jest oczekiwać 100% dostępności dla dowolnego z tych składników.

Usługa Azure Cosmos DB ma kompleksowy zestaw umów SLA dotyczących dostępności, ale żaden z nich nie ma 100%. Składniki sieciowe łączące aplikację z punktem końcowym usługi mogą mieć przejściowe problemy sprzętowe i utracić pakiety. Nawet środowisko obliczeniowe, w którym działa aplikacja, może mieć skok użycia procesora CPU wpływający na operacje. Te warunki awarii mogą mieć wpływ na operacje zestawów SDK i zwykle występują jako błędy z określonymi kodami.

Aplikacja powinna być odporna na określony stopień potencjalnych awarii w tych składnikach przez zaimplementowanie zasad ponawiania prób w odpowiedziach dostarczonych przez zestawy SDK.

Czy moja aplikacja powinna ponowić próbę w przypadku błędów?

Krótka odpowiedź brzmi tak. Ale nie wszystkie błędy mają sens, aby ponowić próbę, niektóre kody błędów lub stanu nie są przejściowe. W poniższej tabeli opisano je szczegółowo:

Kod stanu Należy dodać ponawianie próby Zestawy SDK ponawiają próbę opis
400 Nie Nie. Nieprawidłowe żądanie
401 Nie Nie. Brak autoryzacji
403 Opcjonalnie Nie. Zabronione
404 Nie Nie. Nie można odnaleźć zasobu
408 Tak Tak Upłynął limit czasu żądania
409 Nie Nie. Awaria konfliktu polega na tym, że tożsamość (identyfikator i klucz partycji) podana dla zasobu w operacji zapisu została podjęta przez istniejący zasób lub gdy naruszono ograniczenie unikatowego klucza .
410 Tak Tak Wyjątki zniknęły (błędy przejściowe, które nie powinny naruszać umowy SLA)
412 Nie Nie. Niepowodzenie warunków wstępnych polega na tym, że operacja określała element eTag, który różni się od wersji dostępnej na serwerze. Jest to optymistyczny błąd współbieżności . Ponów żądanie po odczytaniu najnowszej wersji zasobu i zaktualizowaniu elementu eTag dla żądania.
413 Nie Nie. Zbyt duża jednostka żądania
429 Tak Tak Można bezpiecznie ponowić próbę na 429. Zapoznaj się z przewodnikiem rozwiązywania problemów z protokołem HTTP 429.
449 Tak Tak Przejściowy błąd, który występuje tylko w operacjach zapisu i jest bezpieczny do ponowienia próby. Może to wskazywać na problem projektowy polegający na tym, że zbyt wiele współbieżnych operacji próbuje zaktualizować ten sam obiekt w usłudze Azure Cosmos DB.
500 Nie Nie. Operacja nie powiodła się z powodu nieoczekiwanego błędu usługi. Skontaktuj się z pomocą techniczną, zgłaszając problem z pomoc techniczna platformy Azure.
503 Tak Tak Usługa niedostępna

W powyższej tabeli wszystkie kody stanu oznaczone wartością Tak w drugiej kolumnie powinny mieć pewien stopień pokrycia ponawiania prób w aplikacji.

HTTP 403

Zestawy SDK usługi Azure Cosmos DB nie ponawiają próby w przypadku błędów HTTP 403, ale występują pewne błędy związane z protokołem HTTP 403, na które aplikacja może zdecydować się zareagować. Jeśli na przykład zostanie wyświetlony błąd wskazujący, że klucz partycji jest pełny, możesz zdecydować się na zmianę klucza partycji dokumentu, który próbujesz zapisać na podstawie niektórych reguł biznesowych.

HTTP 429

Zestawy SDK usługi Azure Cosmos DB będą domyślnie ponawiać próby po błędach HTTP 429 po konfiguracji klienta i honorowaniu nagłówka odpowiedzi x-ms-retry-after-ms usługi przez oczekiwanie wskazanego czasu i ponowienie próby po.

Po przekroczeniu ponownych prób zestawu SDK zostanie zwrócony błąd do aplikacji. Najlepiej sprawdzić x-ms-retry-after-ms nagłówek w odpowiedzi może służyć jako wskazówka, aby zdecydować, jak długo czekać przed ponowieniu próby żądania. Inną alternatywą jest algorytm wykładniczego wycofywania lub skonfigurowanie klienta w celu rozszerzenia ponawiania prób w protokole HTTP 429.

HTTP 449

Zestawy SDK usługi Azure Cosmos DB ponawiają próbę przy użyciu protokołu HTTP 449 z przyrostowym wycofywaniem w określonym czasie, aby uwzględnić większość scenariuszy.

Po przekroczeniu liczby automatycznych prób zestawu SDK zostanie zwrócony błąd do aplikacji. Błędy HTTP 449 można bezpiecznie ponowić. Ze względu na wysoce współbieżny charakter operacji zapisu zaleca się, aby mieć losowy algorytm wycofywania w celu uniknięcia powtarzania tego samego stopnia współbieżności po stałym interwale.

Limity czasu sieci i błędy łączności są jednymi z najczęstszych błędów. Zestawy SDK usługi Azure Cosmos DB są odporne i ponawiają próby przekroczenia limitu czasu i problemów z łącznością między protokołami HTTP i TCP, jeśli ponawianie próby jest możliwe:

  • W przypadku operacji odczytu zestawy SDK ponowi próbę każdego przekroczenia limitu czasu lub błędu związanego z łącznością.
  • W przypadku operacji zapisu zestawy SDK nie będą ponawiane, ponieważ te operacje nie są idempotentne. Gdy wystąpi przekroczenie limitu czasu oczekiwania na odpowiedź, nie można sprawdzić, czy żądanie dotarło do usługi.

Jeśli konto ma wiele dostępnych regionów, zestawy SDK również spróbują ponowić próbę między regionami.

Ze względu na charakter limitów czasu i błędów łączności mogą one nie być wyświetlane w metrykach konta, ponieważ obejmują one tylko błędy występujące po stronie usługi.

Zaleca się, aby aplikacje miały własne zasady ponawiania prób dla tych scenariuszy i wziąć pod uwagę sposób rozwiązywania limitów czasu zapisu. Na przykład ponawianie próby w przypadku przekroczenia limitu czasu tworzenia może spowodować wystąpienie błędu HTTP 409 (konflikt), jeśli poprzednie żądanie dotarło do usługi, ale powiedzie się, jeśli tak się nie stanie.

Szczegóły implementacji specyficzne dla języka

Aby uzyskać więcej szczegółów implementacji dotyczących języka, zobacz:

Czy ponawianie prób wpływa na moje opóźnienie?

Z punktu widzenia klienta wszelkie ponawianie prób będzie miało wpływ na końcowe opóźnienie operacji. Gdy ma to wpływ na opóźnienie aplikacji P99, zrozumienie ponownych prób i sposobu ich rozwiązywania jest ważne.

Zestawy SDK usługi Azure Cosmos DB zawierają szczegółowe informacje w dziennikach i diagnostyce, które mogą pomóc w zidentyfikowaniu ponownych prób. Aby uzyskać więcej informacji, zobacz , jak zbierać diagnostykę zestawu SDK platformy .NET i jak zbierać diagnostykę zestawu JAVA SDK.

Jak rozwiązać problem z opóźnieniem ponawiania prób?

W zależności od okoliczności zestaw SDK będzie kierować żądania do regionu lokalnego, regionu zapisu (w scenariuszu zapisu w jednym regionie) lub pierwszego regionu na liście preferowanych regionów . Ta priorytetyzacja minimalizuje opóźnienia w scenariuszach w dobrej kondycji, łącząc się głównie z najbliższym lub najbardziej optymalnym centrum danych.

Jednak ta priorytetyzacja oznacza również, że żądania, które spowodują niepowodzenie, zawsze będą sprawdzane w jednym konkretnym regionie jako pierwszy w danym scenariuszu błędu. Jeśli w tym scenariuszu preferowane jest przejście w tryb failover do innego regionu, zwykle jest to obsługiwane w warstwie infrastruktury (usługi Traffic Manager), a nie na poziomie zestawu SDK. Właściwa konfiguracja i konfiguracja infrastruktury może zapewnić efektywne przekierowywanie ruchu podczas awarii regionalnych, co zmniejsza opóźnienie, które może zawierać ponawianie prób między regionami w scenariuszu awarii. Aby uzyskać bardziej szczegółowe informacje na temat konfigurowania trybu failover na poziomie infrastruktury, zapoznaj się z dokumentacją usługi Azure Traffic Manager. Niektóre zestawy SDK obsługują implementowanie podobnych strategii trybu failover bezpośrednio na poziomie zestawu SDK. Zobacz na przykład wysoką dostępność zestawu Java SDK.

Co z awariami regionalnymi?

Zestawy SDK usługi Azure Cosmos DB obejmują dostępność regionalną i mogą wykonywać ponowne próby w innych regionach konta. Zapoznaj się z artykułem dotyczącym scenariuszy i konfiguracji ponawiania prób w środowiskach wieloregionowych, aby dowiedzieć się, które scenariusze obejmują inne regiony.

Kiedy skontaktować się z pomocą techniczną

Przed skontaktowaniem się z pomocą techniczną wykonaj następujące kroki:

  • Jaki jest wpływ mierzony w ilości operacji, których dotyczy problem, w porównaniu z operacjami, które zakończyły się powodzeniem? Czy jest ona w ramach umów SLA usługi?
  • Czy ma to wpływ na opóźnienie P99?
  • Czy błędy związane z kodami błędów, które moja aplikacja powinna ponowić i czy aplikacja obejmuje takie ponawianie prób?
  • Czy awarie wpływają na wszystkie wystąpienia aplikacji, czy tylko na ich podzestaw? Gdy problem zostanie zredukowany do podzestawu wystąpień, często jest to problem związany z tymi wystąpieniami.
  • Czy w powyższej tabeli przedstawiono powiązane dokumenty dotyczące rozwiązywania problemów, aby wykluczyć problem w środowisku aplikacji?

Jeśli dotyczy to wszystkich wystąpień aplikacji lub procent operacji, których dotyczy problem, jest poza umowami SLA usług lub wpływa na własne umowy SLA aplikacji i P99s, skontaktuj się z pomocą techniczną.

Następne kroki