Punkt odniesienia o krytycznym znaczeniu w usłudze App Service

W tym artykule opisano sposób wdrażania aplikacji internetowych o krytycznym znaczeniu przy użyciu usługi Azure App Service. Architektura używa niezawodnego wzorca aplikacji internetowej jako punktu wyjścia. Użyj tej architektury, jeśli masz starsze obciążenie i chcesz wdrożyć usługi typu platforma jako usługa (PaaS).

niezawodny wzorzec aplikacji internetowej dla platformy .NET zawiera wskazówki dotyczące aktualizowania lub ponownego tworzenia aplikacji internetowych, które są przenoszone do chmury. Takie podejście pomaga zminimalizować wymagane zmiany kodu i kierować cel poziomu usług (SLO) 99,9%. Obciążenia o krytycznym znaczeniu mają wymagania dotyczące wysokiej niezawodności i dostępności. Aby osiągnąć cel slo 99,95%, 99,99%lub nowszy, należy zastosować dodatkowe wzorce projektowe o krytycznym znaczeniu i rigor operacyjny. W tym artykule opisano kluczowe obszary techniczne oraz sposób wprowadzania i wdrażania rozwiązań projektowych o znaczeniu krytycznym.

W poniższych sekcjach opisano, jak:

• Przejrzyj istniejące obciążenie, aby zrozumieć jego składniki, przepływy użytkownika i system oraz wymagania dotyczące dostępności i skalowalności.
• Opracowywanie i implementowanie architektury jednostek skalowania w celu zoptymalizowania kompleksowej skalowalności poprzez przedziały i standaryzacji procesu dodawania i usuwania pojemności.
• Zaimplementuj bezstanowe, efemeryczne jednostki skalowania lub sygnatury wdrożenia, aby umożliwić skalowanie i wdrożenia bez przestojów.
• Określ, czy obciążenie można podzielić na składniki, aby przygotować się do skalowalności. Poszczególne składniki są wymagane do skalowania i oddzielenia przepływów.
• Przygotuj się do globalnej dystrybucji, wdrażając obciążenie w więcej niż jednym regionie świadczenia usługi Azure, aby zwiększyć bliskość klienta i przygotować się do potencjalnych awarii regionalnych.
• Rozdziel składniki i zaimplementuj architekturę opartą na zdarzeniach.

Architektura

Na poniższym diagramie opisano poprzednie zagadnienia dotyczące niezawodnego wzorca aplikacji internetowej.

pobierz plik programu Visio tej architektury.

Czerwone pole reprezentuje jednostkę skalowania z usługami, które skalują się razem. Aby efektywnie skalować je razem, zoptymalizuj rozmiar usługi, jednostkę SKU i dostępne adresy IP. Na przykład maksymalna liczba żądań, które usługa Azure App Configuration obsługuje, jest skorelowana z liczbą żądań na sekundę zapewnianą przez jednostkę skalowania. Po dodaniu większej pojemności w regionie należy również dodać więcej pojedynczych jednostek skalowania.

Te poszczególne jednostki skalowania nie mają żadnych zależności od siebie i komunikują się tylko z usługami udostępnionymi poza jednostką skalowania indywidualnego. Te jednostki skalowania można używać w wdrożenia niebieskiego, wdrażając nowe jednostki skalowania, sprawdzając, czy działają prawidłowo, i stopniowo przenosząc na nie ruch produkcyjny.

W tym scenariuszu uważamy jednostki skalowania za tymczasowe, co optymalizuje procesy wdrażania i zapewnia skalowalność w obrębie regionów i między nimi. W przypadku tego podejścia należy przechowywać dane tylko w bazie danych, ponieważ baza danych jest replikowana do regionu pomocniczego. Jeśli musisz przechowywać dane w jednostce skalowania, rozważ użycie usługi Azure Cache for Redis do magazynowania w jednostce skalowania. Jeśli jednostka skalowania musi zostać porzucona, ponowne wypełnienie pamięci podręcznej może zwiększyć opóźnienie, ale nie powoduje awarii.

Usługa Application Insights jest wykluczona z jednostki skalowania. Wyklucz usługi, które przechowują lub monitorują dane. Rozdziel je na własną grupę zasobów przy użyciu własnego cyklu życia.

Po zastąpieniu jednostki skalowania lub wdrożeniu nowej zachowaj dane historyczne i użyj jednego wystąpienia dla każdego regionu.

Aby uzyskać więcej informacji, zobacz Projektowanie aplikacji obciążeń o znaczeniu krytycznym w usłudze Azure.

Składniki

Ta architektura używa następujących składników.

• app service to platforma hostingu aplikacji.
• żądań pamięci podręcznej usługi Azure Cache for Redis.
• App Configuration przechowuje ustawienia konfiguracji.
• usługi Azure SQL jest bazą danych zaplecza.
• application insights pobiera dane telemetryczne z aplikacji.

Alternatywy

W niezawodnym wzorcu aplikacji internetowej można wykonywać następujące czynności:

• użyć usługi Azure Kubernetes Service (AKS) zamiast usługi App Service. Ta opcja dobrze sprawdza się w przypadku złożonych obciążeń, które mają dużą liczbę mikrousług. Usługa AKS zapewnia większą kontrolę nad podstawową infrastrukturą i umożliwia złożone konfiguracje wielowarstwowe.
• Konteneryzowanie obciążenia. Usługa App Service obsługuje konteneryzację, ale w tym przykładzie obciążenie nie jest konteneryzowane. Użyj kontenerów, aby zwiększyć niezawodność i przenośność.

Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące platformy aplikacji dotyczące obciążeń o znaczeniu krytycznym w usłudze Azure.

Zagadnienia dotyczące wysokiej dostępności

Niezależnie od wybranej platformy aplikacji zalecamy określanie priorytetów użycia stref dostępności dla obciążeń produkcyjnych.

zestawów dostępności rozmieszczania wdrożeń w wielu domenach błędów i aktualizacji w centrum danych. strefy dostępności rozmieszczania wdrożeń w poszczególnych centrach danych w regionie świadczenia usługi Azure. Strefy dostępności są często priorytetowe, ale używana strategia zależy od obciążenia. Na przykład obciążenia wrażliwe na opóźnienia lub czatty mogą korzystać z określania priorytetów zestawów dostępności. W przypadku rozłożenia obciążenia między strefy dostępności może zwiększyć opóźnienie i koszt ruchu między strefami. W przypadku korzystania ze stref dostępności upewnij się, że wszystkie usługi w jednostce skalowania obsługują je. Wszystkie usługi we wzorcu niezawodnej aplikacji internetowej obsługują strefy dostępności.

Wybieranie platformy danych

Wybrana platforma bazy danych ma wpływ na ogólną architekturę obciążenia, zwłaszcza obsługę konfiguracji aktywne-aktywne lub aktywne-pasywne platformy. Niezawodny wzorzec aplikacji internetowej korzysta z usługi Azure SQL, która nie obsługuje natywnie wdrożeń aktywnych-aktywnych, które mają operacje zapisu w więcej niż jednym wystąpieniu. W tej konfiguracji platforma danych jest ograniczona do strategii aktywne-pasywne. (częściowa) strategia aktywne-aktywne na poziomie aplikacji jest możliwa, jeśli istnieją repliki tylko do odczytu we wszystkich regionach i zapisujesz tylko w jednym regionie.

Wiele baz danych jest często spotykanych w złożonych architekturach, takich jak architektury mikrousług, które mają bazę danych dla każdej usługi. Wiele baz danych umożliwia wdrożenie wielu podstawowych baz danych zapisu, takich jak Usługa Azure Cosmos DB, co zwiększa wysoką dostępność i małe opóźnienia. Opóźnienie między regionami może powodować ograniczenia. Ważne jest, aby wziąć pod uwagę niefunkcjonalne wymagania i czynniki, takie jak spójność, funkcjonalność, koszt i złożoność. Umożliwianie poszczególnym usługom używania oddzielnych magazynów danych i wyspecjalizowanych technologii danych w celu spełnienia ich unikatowych wymagań. Aby uzyskać więcej informacji, zobacz zagadnienia dotyczące platformy danych dotyczące obciążeń o znaczeniu krytycznym na platformie Azure.

Definiowanie modelu kondycji

W złożonych wielowarstwowych obciążeniach rozmieszczonych w wielu centrach danych i regionach geograficznych należy zdefiniować model kondycji.

Aby zdefiniować model kondycji:

• Definiowanie przepływów użytkownika i systemu
• Określanie i zrozumienie zależności między usługami
• Zrozumienie wpływu awarii lub obniżenia wydajności jednej z usług na ogólne obciążenie
• Monitorowanie i wizualizowanie środowiska klienta w celu umożliwienia odpowiedniego monitorowania i ulepszania ręcznych i zautomatyzowanych akcji.

Na poprzednim diagramie pokazano, jak awaria lub spadek pojedynczego składnika, takiego jak App Configuration, może spowodować potencjalne obniżenie wydajności klienta. Po rozdzieleniu składników na jednostki skalowania można zatrzymać wysyłanie ruchu do objętej części aplikacji, takiej jak jednostka skalowania, której dotyczy problem, lub cały region.

Kryteria określania kondycji jednostki skalowania są definiowane w modelu kondycji. Ten model jest następnie połączony z punktem końcowym kondycji jednostki skalowania, która umożliwia globalnemu modułowi równoważenia obciążenia wykonywanie zapytań dotyczących kondycji jednostki skalowania i używanie tych informacji do podejmowania decyzji dotyczących routingu.

Aby uzyskać więcej informacji, zobacz Modelowanie kondycji i obserwowanie obciążeń o znaczeniu krytycznym na platformie Azure.

Zabezpieczenia i sieć

Obciążenia o znaczeniu krytycznym mają ścisłe wymagania dotyczące sieci i zabezpieczeń. Zastosuj staranność szczególnie w przypadku obciążeń migrowanych ze środowiska lokalnego, ponieważ nie wszystkie ustanowione lokalne rozwiązania zabezpieczeń przekładają się na środowisko chmury. Zalecamy ponowne ewaluowanie wymagań dotyczących zabezpieczeń podczas migracji aplikacji.

Tożsamość jest często podstawowym obwodem zabezpieczeń dla wzorców natywnych dla chmury. Klienci korporacyjni mogą potrzebować bardziej znaczących środków zabezpieczeń. Aby spełnić wymagania dotyczące zabezpieczeń sieci, usługi Azure PaaS mogą używać usługi Azure Private Link do implementowania sieci jako obwodu zabezpieczeń. Usługa Private Link pomaga zagwarantować, że usługi są dostępne tylko z poziomu sieci wirtualnej. Wszystkie usługi są następnie dostępne tylko za pośrednictwem prywatnych punktów końcowych. Na poniższym diagramie pokazano, jak jedynym publicznym punktem końcowym dostępnym z Internetu jest usługa Azure Front Door.

Aby wzorzec niezawodnej aplikacji internetowej skonfigurować sieć jako obwód zabezpieczeń, musi być używany:

• Usługa Private Link dla wszystkich usług, które go obsługują.
• Usługa Azure Front Door Premium jako jedyny publiczny punkt końcowy dostępny z Internetu.
• Szybkie pola dostępu do usług za pośrednictwem usługi Azure Bastion.
• Własnych agentów kompilacji, którzy mogą uzyskiwać dostęp do usług.

Innym typowym wymaganiem sieciowym dla aplikacji o krytycznym znaczeniu jest ograniczenie ruchu wychodzącego w celu zapobiegania eksfiltracji danych. Ograniczanie ruchu wychodzącego przez kierowanie zapory platformy Azure przez odpowiednie urządzenie zapory. Następnie przefiltruj ruch przy użyciu urządzenia. Architektura punktu odniesienia o krytycznym znaczeniu dla platformy Azure z kontrolkami sieciowymi, używa zapory i usługi Private Link.

Wdrażanie i testowanie

Przestój spowodowany błędnym wydaniem lub błędem ludzkim może być problemem dla obciążenia, które musi być zawsze dostępne. Oto kilka kluczowych obszarów, które należy wziąć pod uwagę:

• Wdrożenia bez przestojów
• Wdrożenia efemeryczne niebiesko-zielone
• Analiza cyklu życia poszczególnych i grupowanych składników
• Ciągła walidacja

wdrożenia bez przestojów są kluczowe dla obciążeń o znaczeniu krytycznym. Obciążenie, które musi być zawsze uruchomione, nie może mieć okna obsługi do wdrożenia nowszych wersji. Aby obejść to ograniczenie, architektura platformy Azure o znaczeniu krytycznym jest zgodna ze wzorcem wdrożeń bez przestojów. Zmiany są wdrażane jako nowe jednostki skalowania lub sygnatury, które są testowane na końcu przed przyrostowym kierowaniem ruchu do nich. Po skierowaniu całego ruchu do nowej sygnatury stare sygnatury są wyłączone i usuwane.

Aby uzyskać więcej informacji, zobacz Wdrażanie i testowanie obciążeń o znaczeniu krytycznym na platformie Azure.

Następne kroki

• ścieżka szkoleniowa : Tworzenie obciążeń o znaczeniu krytycznym na platformie Azure
• projekt Challenge: Projektowanie aplikacji internetowej o krytycznym znaczeniu
• Learn module: Projektowanie modelu kondycji dla obciążenia o krytycznym znaczeniu

Powiązane zasoby

• architektura punktu odniesienia o znaczeniu krytycznym na platformie Azure
• architektura punktu odniesienia o znaczeniu krytycznym z kontrolą sieci
• architektura punktu odniesienia o krytycznym znaczeniu w strefie docelowej platformy Azure
• ciągłą walidację przy użyciu usług Azure Load Testing i Azure Chaos Studio