Platforma danych dla obciążeń o krytycznym znaczeniu na platformie Azure

W architekturze o znaczeniu krytycznym każdy stan musi być przechowywany poza obliczeniami możliwie jak najwięcej. Wybór technologii opiera się na następujących kluczowych cechach architektury:

Charakterystyki	Kwestie wymagające rozważenia
Wydajność	Ile mocy obliczeniowej jest wymagane?
Opóźnienie	Jaki będzie wpływ na odległość między użytkownikiem a magazynem danych w przypadku opóźnienia? Jaki jest żądany poziom spójności z kompromisem w zakresie opóźnień?
Responsywność	Czy magazyn danych musi być zawsze dostępny?
Skalowalność	Jaki jest schemat partycjonowania?
Trwałość	Czy dane mają trwać długo? Jakie są zasady przechowywania?
Odporność	Czy w przypadku awarii magazyn danych może automatycznie przełączyć się w tryb failover? Jakie miary obowiązują, aby skrócić czas pracy w trybie failover?
Zabezpieczenia	Czy dane są szyfrowane? Czy magazyn danych można uzyskać za pośrednictwem sieci publicznej?

W tej architekturze istnieją dwa magazyny danych:

• Baza danych

  Przechowuje powiązane z obciążeniem. Zaleca się, aby cały stan był przechowywany globalnie w bazie danych oddzielonej od sygnatur regionalnych. Tworzenie nadmiarowości przez wdrożenie bazy danych w różnych regionach. W przypadku obciążeń o znaczeniu krytycznym synchronizacja danych między regionami powinna być głównym problemem. Ponadto w przypadku awarii żądania zapisu w bazie danych powinny nadal działać.

  Replikacja danych w konfiguracji aktywne-aktywne jest zdecydowanie zalecana. Aplikacja powinna mieć możliwość natychmiastowego nawiązania połączenia z innym regionem. Wszystkie wystąpienia powinny mieć możliwość obsługi żądań odczytu i zapisu.

• Broker komunikatów

  Jedyną usługą stanową w sygnaturze regionalnej jest broker komunikatów, który przechowuje żądania przez krótki okres. Broker obsługuje potrzebę buforowania i niezawodnej obsługi komunikatów. Przetworzone żądania są utrwalane w globalnej bazie danych.

Aby zapoznać się z innymi zagadnieniami dotyczącymi danych, zobacz Misson-critical guidance in Well-architected Framework: Data platform considerations (Wskazówki dotyczące rozwiązania Misson-critical) w artykule Well-architected Framework: Data platform considerations (Zagadnienia dotyczące platformy danych).

baza danych

Ta architektura korzysta z usługi Azure Cosmos DB dla NoSQL. Ta opcja jest wybierana, ponieważ zapewnia najbardziej potrzebne funkcje w tym projekcie:

• Zapis w wielu regionach

  Zapis w wielu regionach jest włączony z replikami wdrożonym w każdym regionie, w którym wdrożono sygnaturę. Każda sygnatura może zapisywać lokalnie, a usługa Azure Cosmos DB obsługuje replikację danych i synchronizację między sygnaturami. Ta funkcja znacznie zmniejsza opóźnienie dla geograficznie rozproszonych użytkowników końcowych aplikacji. Implementacja referencyjna azure Mission-Critical używa technologii wielowzorcowej w celu zapewnienia maksymalnej odporności i dostępności.

  Nadmiarowość strefy jest również włączona w każdym zreplikowanym regionie.

  Aby uzyskać szczegółowe informacje na temat zapisów w wielu regionach, zobacz Konfigurowanie zapisów w wielu regionach w aplikacjach korzystających z usługi Azure Cosmos DB.

• Zarządzanie konfliktami

  Dzięki możliwości wykonywania zapisów w wielu regionach konieczne jest wdrożenie modelu zarządzania konfliktami, ponieważ jednoczesne zapisy mogą powodować konflikty rekordów. Ostatni zapis wygrywa jest domyślnym modelem i jest używany do projektowania o znaczeniu krytycznym. Ostatni zapis zdefiniowany przez skojarzone znaczniki czasu rekordów wygrywa konflikt. Usługa Azure Cosmos DB for NoSQL umożliwia również zdefiniowanie właściwości niestandardowej.

• Optymalizacja zapytań

  Ogólne zalecenie dotyczące wydajności zapytań dla kontenerów z dużą liczbą partycji z dużą liczbą partycji polega na dodaniu filtru równości z zidentyfikowanym identyfikatorem itemID. Szczegółowy przegląd zaleceń dotyczących optymalizacji zapytań można znaleźć w temacie Rozwiązywanie problemów z zapytaniami podczas korzystania z usługi Azure Cosmos DB.

• Funkcja tworzenia kopii zapasowej

  Zaleca się użycie natywnej funkcji tworzenia kopii zapasowej usługi Azure Cosmos DB na potrzeby ochrony danych. Funkcja tworzenia kopii zapasowej usługi Azure Cosmos DB obsługuje kopie zapasowe online i przywracanie danych na żądanie.

Uwaga

Większość obciążeń nie jest czysto OLTP. Istnieje rosnące zapotrzebowanie na raportowanie w czasie rzeczywistym, takie jak uruchamianie raportów względem systemu operacyjnego. Jest to również nazywane HTAP (hybrydowym przetwarzaniem transakcyjnym i analitycznym). Usługa Azure Cosmos DB obsługuje tę funkcję za pośrednictwem usługi Azure Synapse Link dla usługi Azure Cosmos DB.

Model danych dla obciążenia

Model danych powinien być zaprojektowany tak, aby funkcje oferowane przez tradycyjne relacyjne bazy danych nie są wymagane. Na przykład klucze obce, ścisły schemat wiersza/kolumny, widoki i inne.

Obciążenie ma następujące cechy dostępu do danych:

• Wzorzec odczytu:
  • Odczyty punktów — pobieranie pojedynczego rekordu. Identyfikator elementu i klucz partycji jest używany bezpośrednio do maksymalnej optymalizacji (1 RU na żądanie).
  • Odczyty listy — pobieranie elementów wykazu do wyświetlenia na liście. FeedIterator w przypadku użycia limitu liczby wyników.
• Wzorzec zapisu:
  • Małe zapisy — żądania zwykle wstawiają pojedynczą lub niewielką liczbę rekordów w transakcji.
• Zaprojektowano tak, aby obsługiwać duży ruch od użytkowników końcowych z możliwością skalowania w celu obsługi zapotrzebowania na ruch w kolejności milionów użytkowników.
• Mały ładunek lub rozmiar zestawu danych — zwykle w kolejności kb.
• Niski czas odpowiedzi (w milisekundach).
• Małe opóźnienie (w milisekundach).

Konfigurowanie

Usługa Azure Cosmos DB jest skonfigurowana w następujący sposób:

• Poziom spójności jest ustawiony na domyślną spójność sesji, ponieważ jest to najczęściej używany poziom dla pojedynczego regionu i aplikacji rozproszonych globalnie. Słabsza spójność z wyższą przepływnością nie jest potrzebna z powodu asynchronicznego charakteru przetwarzania zapisu i nie wymaga małego opóźnienia zapisu w bazie danych.

  Uwaga

  Poziom spójności sesji zapewnia rozsądny kompromis w zakresie opóźnień, dostępności i spójności dla tej konkretnej aplikacji. Ważne jest, aby zrozumieć, że wysoki poziom spójności nie jest dostępny dla wielowzorcowych baz danych zapisu.

• Klucz partycji jest ustawiony na /id wartość dla wszystkich kolekcji. Ta decyzja jest oparta na wzorcu użycia, który jest głównie "pisanie nowych dokumentów z identyfikatorem GUID jako identyfikatorem" i "odczytywanie szerokiego zakresu dokumentów według identyfikatorów". Dzięki zapewnieniu, że kod aplikacji zachowuje unikatowość identyfikatorów, nowe dane są równomiernie dystrybuowane do partycji przez usługę Azure Cosmos DB, umożliwiając nieskończoną skalę.

• Zasady indeksowania są konfigurowane w kolekcjach w celu optymalizacji zapytań. Aby zoptymalizować koszt i wydajność jednostek RU, są używane niestandardowe zasady indeksowania. Te zasady indeksują tylko właściwości, które są używane w predykatach zapytań. Na przykład aplikacja nie używa pola tekstowego komentarza jako filtru w zapytaniach. Został wykluczony z niestandardowych zasad indeksowania.

Oto przykład z implementacji, która pokazuje ustawienia zasad indeksowania przy użyciu narzędzia Terraform:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Aby uzyskać informacje o połączeniu z aplikacji do usługi Azure Cosmos DB w tej architekturze, zobacz Zagadnienia dotyczące platformy aplikacji dla obciążeń o znaczeniu krytycznym

Usługi obsługi wiadomości

Systemy o znaczeniu krytycznym często wykorzystują usługi obsługi komunikatów do przetwarzania komunikatów lub zdarzeń. Usługi te promują luźne sprzęganie i działają jako bufor, który izoluje system przed nieoczekiwanymi skokami zapotrzebowania.

• Usługa Azure Service Bus jest zalecana w przypadku obciążeń opartych na komunikatach podczas obsługi komunikatów o wysokiej wartości.
• Usługa Azure Event Hubs jest zalecana w przypadku systemów opartych na zdarzeniach, które przetwarzają duże ilości zdarzeń lub telemetrii.

Poniżej przedstawiono zagadnienia dotyczące projektowania i zalecenia dotyczące usługi Azure Service Bus w warstwie Premium i usługi Azure Event Hubs w architekturze o znaczeniu krytycznym.

Obsługa obciążenia

System obsługi komunikatów musi mieć możliwość obsługi wymaganej przepływności (jak w MB na sekundę). Rozważ następujące źródła:

• Wymagania niefunkcjonalne (NFR) systemu powinny określać średni rozmiar komunikatu, a maksymalna liczba komunikatów/sekund musi obsługiwać każda sygnatura. Te informacje mogą służyć do obliczania wymaganego szczytowego MB/sekundy na sygnaturę.
• Wpływ przejścia w tryb failover należy rozważyć podczas obliczania wymaganego szczytowego MB/sekundy na sygnaturę.
• W przypadku usługi Azure Service Bus NFRs należy określić wszystkie zaawansowane funkcje usługi Service Bus, takie jak sesje i komunikaty usuwania zrzutów. Te funkcje będą mieć wpływ na przepływność usługi Service Bus.
• Przepływność usługi Service Bus z wymaganymi funkcjami powinna być obliczana przez testowanie jako MB/sekundę na jednostkę obsługi komunikatów (MU). Aby uzyskać więcej informacji na temat tego tematu, zobacz Warstwy obsługi komunikatów w warstwie Premium i Standardowa usługi Service Bus.
• Przepływność usługi Azure Event Hubs powinna być obliczana przez testowanie jako MB/sekundę na jednostkę przepływności (TU) dla warstwy Standardowa lub jednostki przetwarzania (PU) dla warstwy Premium. Aby uzyskać więcej informacji na temat tego tematu, zobacz Scaling with Event Hubs (Skalowanie za pomocą usługi Event Hubs).
• Powyższe obliczenia mogą służyć do sprawdzania, czy usługa obsługi komunikatów może obsłużyć wymagane obciążenie na sygnaturę oraz wymaganą liczbę jednostek skalowania wymaganych do spełnienia tego obciążenia.
• W sekcji operacje omówiono skalowanie automatyczne.

Każdy komunikat musi być przetwarzany

Warstwa Premium usługi Azure Service Bus jest zalecanym rozwiązaniem dla komunikatów o wysokiej wartości, dla których przetwarzanie musi być gwarantowane. Poniżej przedstawiono szczegółowe informacje dotyczące tego wymagania w przypadku korzystania z usługi Azure Service Bus w wersji Premium:

• Aby upewnić się, że komunikaty są prawidłowo przesyłane i akceptowane przez brokera, producenci komunikatów powinni używać jednego z obsługiwanych klientów interfejsu API usługi Service Bus. Obsługiwane interfejsy API będą zwracać pomyślnie tylko z operacji wysyłania, jeśli komunikat został utrwalone w kolejce/temacie.

• Aby upewnić się, że komunikaty w magistrali są przetwarzane, należy użyć trybu odbierania PeekLock. Ten tryb umożliwia co najmniej jednokrotne przetwarzanie. Poniżej przedstawiono proces:

  • Odbiorca komunikatu odbiera komunikat do przetworzenia.
  • Użytkownik otrzymuje wyłączną blokadę komunikatu dla danego czasu.
  • Jeśli odbiorca pomyślnie przetworzy komunikat, wysyła potwierdzenie z powrotem do brokera, a komunikat zostanie usunięty z kolejki.
  • Jeśli potwierdzenie nie zostanie odebrane przez brokera w wyznaczonym okresie lub program obsługi jawnie porzuci komunikat, zostanie zwolniona blokada wyłączna. Komunikat jest następnie dostępny dla innych odbiorców do przetworzenia komunikatu.
  • Jeśli komunikat nie został pomyślnie przetworzony przez konfigurowalną liczbę razy lub program obsługi przekazuje komunikat do kolejki utraconych komunikatów.
    • Aby upewnić się, że komunikaty wysyłane do kolejki utraconych komunikatów są na bieżąco, kolejka utraconych komunikatów powinna być monitorowana i należy ustawić alerty.
    • System powinien mieć narzędzia dla operatorów, aby móc sprawdzać, poprawiać i ponownie przesyłać komunikaty.

• Ponieważ komunikaty mogą być potencjalnie przetwarzane więcej niż jeden raz, programy obsługi komunikatów powinny być idempotentne.

Idempotentne przetwarzanie komunikatów

W RFC 7231 protokół transferu hipertekstowego stwierdza: "A ... metoda jest uważana za idempotentną , jeśli zamierzony wpływ na serwer wielu identycznych żądań z tą metodą jest taki sam jak efekt pojedynczego takiego żądania".

Jedną z typowych technik tworzenia idempotentności obsługi komunikatów jest sprawdzenie magazynu trwałego, takiego jak baza danych, jeśli komunikat został już przetworzony. Jeśli została przetworzona, logika nie zostanie uruchomiona, aby ją ponownie przetworzyć.

• Mogą wystąpić sytuacje, w których przetwarzanie komunikatu obejmuje operacje bazy danych, w szczególności wstawianie nowych rekordów z identyfikatorami wygenerowanymi przez bazę danych. Nowe komunikaty mogą być emitowane do brokera, który zawiera te identyfikatory. Ponieważ nie ma transakcji rozproszonych obejmujących zarówno bazę danych, jak i brokera komunikatów, może wystąpić szereg komplikacji, które mogą wystąpić, jeśli proces uruchamiania kodu kończy się niepowodzeniem. Zobacz następujące przykładowe sytuacje:
  • Kod emitujący komunikaty może być uruchamiany przed zatwierdzeniu transakcji bazy danych, czyli liczby deweloperów korzystających ze wzorca Unit of Work. Te komunikaty mogą uciec, jeśli wystąpi błąd między wywołaniem brokera i prośbą o zatwierdzeniu transakcji bazy danych. W miarę wycofywania transakcji te identyfikatory generowane przez bazę danych również są cofane, co pozostawia je dostępne dla innego kodu, który może być uruchomiony w tym samym czasie. Może to spowodować, że adresaci komunikatów ucieczki przetwarzają nieprawidłowe wpisy bazy danych, co boli ogólną spójność i poprawność systemu.
  • Jeśli deweloperzy umieścić kod, który emituje komunikat po zakończeniu transakcji bazy danych, proces nadal może zakończyć się niepowodzeniem między tymi operacjami (transakcja zatwierdzona — wysłany komunikat). W takim przypadku komunikat przejdzie ponownie przez przetwarzanie, ale tym razem klauzula idempotence guard zobaczy, że została już przetworzona (na podstawie danych przechowywanych w bazie danych). Klauzula pominie komunikat emitujący kod, wierząc, że wszystko zostało wykonane pomyślnie po raz ostatni. Systemy podrzędne, które spodziewały się otrzymywać powiadomienia o ukończonym procesie, nie otrzymują niczego. Ta sytuacja ponownie powoduje ogólny stan niespójności.
• Rozwiązanie powyższych problemów polega na użyciu wzorca transakcyjnej skrzynki odbiorczej, gdzie wychodzące komunikaty są przechowywane po stronie, w tym samym magazynie transakcyjnym co dane biznesowe. Komunikaty są następnie przesyłane do brokera komunikatów po pomyślnym przetworzeniu początkowej wiadomości.
• Ponieważ wielu deweloperów nie jest znanych z tych problemów lub ich rozwiązań, w celu zagwarantowania, że te techniki są stosowane spójnie w systemie o krytycznym znaczeniu, sugerujemy, że masz funkcjonalność skrzynki odbiorczej i interakcji z brokerem komunikatów opakowanym w jakąś bibliotekę. Wszystkie operacje przetwarzania kodu i wysyłania komunikatów znaczących transakcyjnie powinny korzystać z tej biblioteki, a nie bezpośrednio wchodzić w interakcje z brokerem komunikatów.
  • Biblioteki implementujące tę funkcję na platformie .NET obejmują NServiceBus i MassTransit.

Wysoka dostępność i odzyskiwanie po awarii

Broker komunikatów musi być dostępny dla producentów, aby wysyłać wiadomości i odbiorców, aby je otrzymywać. Poniżej przedstawiono szczegółowe informacje dotyczące tego wymagania:

• Aby zapewnić najwyższą dostępność w usłudze Service Bus, użyj warstwy Premium, która obsługuje strefy dostępności w regionach pomocniczych. W przypadku stref dostępności komunikaty i metadane są replikowane w trzech różnych centrach danych w tym samym regionie.
• Użyj obsługiwanych zestawów SDK usługi Service Bus lub Event Hubs, aby automatycznie ponowić próbę niepowodzenia odczytu lub zapisu.
• Rozważ aktywną-aktywną replikację lub wzorce replikacji aktywne-pasywne, aby odizolować się od regionalnych awarii.

Uwaga

Odzyskiwanie po awarii geograficznej usługi Azure Service Bus replikuje tylko metadane między regionami. Ta funkcja nie replikuje komunikatów.

Monitorowanie

System obsługi komunikatów działa jako bufor między producentami komunikatów a konsumentami. Istnieją kluczowe typy wskaźników, które należy monitorować w systemie o znaczeniu krytycznym, które zapewniają cenne szczegółowe informacje opisane poniżej:

• Ograniczanie przepustowości — ograniczanie wskazuje, że system nie ma wymaganych zasobów do przetworzenia żądania. Zarówno usługa Service Bus, jak i usługa Event Hubs obsługują monitorowanie żądań ograniczonych. Powinien zostać wyświetlony alert dotyczący tego wskaźnika.
• Głębokość kolejki — rosnąca głębokość kolejki może wskazywać, że procesory komunikatów nie działają lub nie ma wystarczającej liczby procesorów do obsługi bieżącego obciążenia. Głębokość kolejki może służyć do informowania logiki automatycznego skalowania procedur obsługi.
  • W przypadku usługi Service Bus głębokość kolejki jest uwidoczniona jako liczba komunikatów
  • W przypadku usługi Event Hubs konsumenci muszą obliczyć głębokość kolejki na partycję i wypchnąć metryki do oprogramowania do monitorowania. Dla każdego odczytu odbiorca pobiera numer sekwencji bieżącego zdarzenia i właściwości zdarzenia ostatniego w kolejce. Odbiorca może obliczyć przesunięcie.
• Kolejka utraconych komunikatów — komunikaty w kolejce utraconych komunikatów reprezentują komunikaty, których nie można przetworzyć. Te komunikaty zwykle wymagają interwencji ręcznej. Alerty powinny być ustawiane w kolejce utraconych komunikatów.
  • Usługa Service Bus ma kolejkę utraconych komunikatów i metrykę DeadLetteredMessages.
  • W przypadku usługi Event Hubs ta funkcja musi być niestandardową logiką wbudowaną w odbiorcę.
• Użycie procesora CPU/pamięci — należy monitorować procesor i pamięć, aby upewnić się, że system obsługi komunikatów ma wystarczającą ilość zasobów do przetworzenia bieżącego obciążenia. Zarówno usługa Service Bus Premium, jak i usługa Event Hubs w warstwie Premium uwidacznia użycie procesora CPU i pamięci.
  • Jednostki obsługi komunikatów (MU) są używane w usłudze Service Bus do izolowania zasobów, takich jak procesor CPU i pamięć dla przestrzeni nazw. Procesor CPU i pamięć rośnie powyżej progu mogą wskazywać, że nie skonfigurowano wystarczającej liczby jednostek MU, a spadek poniżej innych progów może wskazywać, że skonfigurowano zbyt wiele jednostek MU. Te wskaźniki mogą służyć do automatycznego skalowania jednostek MU.
  • Warstwa Premium usługi Event Hubs używa jednostek przetwarzania (PU) do izolowania zasobów, podczas gdy warstwa Standardowa używa jednostek przepływności (TU). Te warstwy nie wymagają interakcji z procesorem CPU/pamięcią, aby automatycznie zawyżać jednostki PU lub jednostki TU.

Sprawdzanie kondycji

Kondycja systemu obsługi komunikatów musi być brana pod uwagę w kontroli kondycji aplikacji o znaczeniu krytycznym. Rozważmy następujący czynniki:

• System obsługi komunikatów działa jako bufor między producentami komunikatów a konsumentami. Sygnatura może być postrzegana jako zdrowa, jeśli producenci mogą pomyślnie wysyłać komunikaty do brokera i czy konsumenci mogą pomyślnie przetwarzać komunikaty z brokera.
• Kontrola kondycji powinna upewnić się, że komunikaty mogą być wysyłane do systemu komunikatów.

Następne kroki

Wdróż implementację referencyjną, aby uzyskać pełną wiedzę na temat zasobów i ich konfiguracji używanej w tej architekturze.

Implementacja: Mission-Critical Online