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

  • Artykuł

DOTYCZY: NoSQL

Podczas tworzenia aplikacji klienckich korzystających z usługi Azure Cosmos DB za pomocą dowolnego zestawu SDK ważne jest zrozumienie kilku kluczowych podstaw. Ten artykuł jest przewodnikiem projektowym, który ułatwia zrozumienie tych podstawowych zagadnień i projektowanie 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 .NET i Java SDK mogą łączyć się z usługą zarówno w trybie bramy, jak i bezpośredniego, 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 dotyczące routingu, niezależnie od tego, który tryb SDK jest skonfigurowany do użycia. Te informacje są buforowane w pamięci i służą do nawiązywania połączenia z replikami usługi.

Podsumowując, w przypadku zestawów SDK w trybie bramy można oczekiwać ruchu HTTP, podczas gdy w przypadku zestawów SDK w trybie bezpośrednim można oczekiwać kombinacji ruchu HTTP i TCP w różnych okolicznościach (takich jak inicjowanie lub pobieranie metadanych lub informacje dotyczące 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 gdy te limity zostaną osiągnięte, będzie to miało wpływ na łączność.

Aplikacje rozproszone i sieci

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

  • Aplikacja i środowisko, w 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 należą one do jednego 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 któregokolwiek 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ć gwałtowny wzrost wpływu na operacje procesora CPU. 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 Ponów próbę zestawów SDK Opis
400 Nie Nie Nieprawidłowe żądanie
401 Nie Nie Brak autoryzacji
403 Opcjonalne Nie Zabronione
404 Nie Nie Nie można odnaleźć zasobu
408 Tak Tak Upłynął limit czasu żądania
409 Nie Nie Błąd powodujący konflikt występuje, gdy tożsamość (identyfikator i klucz partycji) podana dla zasobu w operacji zapisu została przejęta przez istniejący zasób lub gdy zostało naruszone ograniczenie unikatowego klucza .
410 Tak Tak Wyjątki zniknęły (błąd przejściowy, który nie powinien naruszać umowy SLA)
412 Nie Nie Niepowodzenie warunku wstępnego 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 Błąd przejściowy, który występuje tylko w przypadku operacji 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 podjąć decyzję. 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 ponawiane próby po błędach HTTP 429 po konfiguracji klienta i honorowaniu nagłówka odpowiedzi x-ms-retry-after-ms usługi, czekając na wskazany czas i ponawiając próbę 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 wycofywania wykładniczego lub skonfigurowanie klienta w celu rozszerzenia ponownych prób na http 429.

HTTP 449

Zestawy SDK usługi Azure Cosmos DB ponowią próbę przy użyciu protokołu HTTP 449 z przyrostowym wycofywaniem w stałym okresie czasu, 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.

Wśród najczęściej występujących błędów występują przekroczenia limitu czasu sieci i błędy łączności. 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ę 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ę ponownego uruchomienia między regionami.

Ze względu na charakter przekroczenia limitu czasu i awarii łą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ę, gdyby nie.

Szczegóły implementacji specyficzne dla języka

Aby uzyskać szczegółowe informacje o implementacji języka, zobacz:

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

Z perspektywy 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 sposób ich rozwiązywania jest ważne.

Zestawy SDK usługi Azure Cosmos DB zawierają szczegółowe informacje w dziennikach i diagnostyki, które mogą pomóc w zidentyfikowaniu, które ponawianie prób ma miejsce. Aby uzyskać więcej informacji, zobacz , jak zbierać diagnostykę zestawu SDK platformy .NET i jak zbierać diagnostykę 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 w środowiskach wieloregionowych , aby zrozumieć, które scenariusze obejmują inne regiony.

Kiedy skontaktować się z pomocą techniczną klienta

Przed skontaktowaniem się z pomocą techniczną klienta 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 znajduje się 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 aplikacja powinna ponowić i czy aplikacja obejmuje takie próby?
  • 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 ma wpływ na własne umowy SLA aplikacji i P99s, skontaktuj się z pomocą techniczną.

Następne kroki