Projektowanie architektury rozproszonej geograficznie
Platforma Azure jest systemem globalnym. Projektując architekturę, która jest obecna w więcej niż jednym regionie świadczenia usługi Azure, możemy utworzyć aplikację, która jest odporna na awarie obejmujące nawet cały region.
Twój portal śledzenia przesyłek jest skalowalny, ponieważ został utworzony przy użyciu różnych zasobów platformy Azure, które można skalować. Jest również odporny na wiele awarii, ponieważ jego składniki mogą mieć wiele wystąpień. Jednak zarząd zaniepokoił się, że awaria na dużą skalę może spowodować przerwę, ponieważ portal jest całkowicie zawarty w regionie świadczenia usługi Azure Wschodnie stany USA. Chcesz zaproponować zmodyfikowaną architekturę, która będzie mogła działać w trybie pracy awaryjnej w drugim regionie, jeśli region Wschodnie stany USA ulegnie awarii.
Tutaj dowiesz się, jak dostosować architekturę aplikacji do obsługi aplikacji rozproszonej geograficznie. Widzimy również, dlaczego taka architektura jest korzystna dla aplikacji o znaczeniu krytycznym dla działania firmy.
Oryginalna architektura aplikacji internetowej
Przyjrzyjmy się projektowi architektury portalu śledzenia oraz składnikom używanym w rozwiązaniu. Po zrozumieniu, jak używamy wszystkich części, możemy zbadać, jak obsługiwać każdy z tych składników w scenariuszach nadmiarowości geograficznej.
Projekt portalu śledzenia jest oparty na architekturze referencyjnej pokazanej na poniższym diagramie.
Zwróć uwagę, jak nasza aplikacja korzysta z jednej grupy zasobów platformy Azure. Ta grupa zasobów umożliwia nam logiczne grupowanie wszystkich zasobów i zarządzanie nimi oraz upraszcza zarządzanie nimi. Wybieramy wdrożenie tej grupy zasobów w regionie Wschodnie stany USA. Mimo że grupa zasobów nie wymusza korzystania z tego samego regionu świadczenia usługi Azure na potrzeby dołączonych zasobów, zdecydowaliśmy, że wszystkie zasoby wdrożone w naszej aplikacji będą się znajdowały w regionie Wschodnie stany USA.
Nasza aplikacja używa trzech kategorii zasobów platformy Azure. Przyjrzyjmy się każdej kategorii i zobaczmy, które zasoby są używane.
Składniki sieci
Portal śledzenia używa następujących usług sieciowych.
| Usługa | opis |
|---|---|
| Usługa DNS platformy Azure | Skonfigurowaliśmy usługę Azure DNS do hostowania naszych rekordów DNS na platformie Azure. Usługa Azure DNS umożliwia zarządzanie rekordami DNS przy użyciu poświadczeń platformy Azure w witrynie Azure Portal. |
| Application Gateway | Skonfigurowaliśmy moduł równoważenia obciążenia usługi Application Gateway, aby zrównoważyć ruch między wieloma wystąpieniami frontonu internetowego. Ta usługa jest zlokalizowana w jednym regionie świadczenia usługi Azure. |
| Azure CDN | Skonfigurowaliśmy usługę Azure CDN w celu zmaksymalizowania wydajności dostarczania niezabezpieczonej zawartości statycznej, na przykład grafiki dotyczącej zawartości witryny internetowej. Ta globalna usługa buforuje zawartość statyczną w punktach obecności na całym świecie. |
Składniki aplikacji
Portal śledzenia używa następujących usług do obsługi kodu, pamięci podręcznej i wymagań dotyczących magazynu pośredniego.
| Usługa | opis |
|---|---|
| Tożsamość Microsoft Entra | Użytkownicy uzyskują dostęp do portalu śledzenia przy użyciu kont Microsoft Entra. Katalog i konto są automatycznie replikowane globalnie. |
| Azure App Service | Portal śledzenia używa dwóch usług Azure App Service. Pierwszy uruchamia zestaw dynamicznych stron internetowych, a drugi internetowy interfejs API. |
| Aplikacje funkcji platformy Azure | Portal śledzenia używa aplikacji funkcji platformy Azure do uruchamiania wszystkich zadań w tle. Niektóre z tych zadań działają zgodnie z harmonogramem, a inne w oparciu o komunikaty umieszczane w kolejce. |
| Kolejki usługi Azure Storage | Portal śledzenia używa kolejek usługi Azure Storage z aplikacjami funkcji platformy Azure. Portal śledzenia umieszcza wygenerowane komunikaty w kolejce, z której są one pobierane do przetwarzania przez aplikacje funkcji. |
| Redis Cache | Portal śledzenia korzysta z usługi Redis Cache jako pamięci pośredniczącej między usługą aplikacji frontonu i systemami magazynu danych w celu zmaksymalizowania wydajności zapytań. |
| Azure Blob Storage | Zawartość statyczna, taka jak grafiki i pliki wideo, są przechowywane jako obiekty binarne (obiekty blob) na koncie usługi Azure Storage i są dostarczane za pośrednictwem usługi Azure CDN. |
| Azure Search | W portalu śledzenia włączyliśmy usługę Azure Search. Usługa Azure Search umożliwia nam wyszukiwanie całej zawartości oraz udostępnianie sugestii wyszukiwania i rozmyte wyniki wyszukiwania naszym użytkownikom. |
Składniki magazynu danych
W portalu śledzenia są używane następujące utrwalone usługi magazynu.
| Usługa | opis |
|---|---|
| Azure SQL Database | Dane relacyjne, takie jak informacje o zamówieniach i klientach, przechowujemy w usłudze Azure SQL Database. |
| Cosmos DB | Dane częściowo ustrukturyzowane, w tym nasz katalog produktów, przechowujemy w usłudze Cosmos DB. |
Problemy związane z oryginalną architekturą
Istniejąca architektura portalu śledzenia została zaprojektowana w celu zapewnienia skalowalności i dostępności.
Jeśli na przykład zapotrzebowanie jest wysokie, a odpowiedzi na żądania internetowe użytkownika są powolne, możesz rozważyć dodanie większej liczby wystąpień aplikacji internetowej frontonu w usłudze App Service. W takim przypadku usługa Application Gateway może kierować żądania do nowo utworzonych wystąpień.
Istnieją jednak scenariusze, w których nasz projekt architektoniczny ma trudności z pokonaniem, a nawet niepowodzeniem. Przyjrzyjmy się poszczególnym scenariuszom, aby lepiej zrozumieć ich wpływ na działanie portalu śledzenia.
Awarie regionalne
Niektóre istotne zdarzenia mogą potencjalnie przerwać działanie całego regionu świadczenia usługi Azure. Centra danych platformy Azure zostały zaprojektowane tak, aby były wysoce odporne, ale ogromne zdarzenie pogodowe, takie jak huragan lub powódź, może zakłócić obsługę z regionu.
Takie zdarzenia są rzadkimi zjawiskami, dlatego wiele firm przyjmuje takie ryzyko. Niemniej jednak konsekwencje wystąpienia awarii regionalnej powodującej wyłączenie portalu śledzenia są tak poważne, że zarząd firmy zdecydował, że należy wyeliminować to ryzyko.
Umowy dotyczące poziomu usług (SLA)
Większość usług platformy Azure oferuje Umowy dotyczące poziomu usług (SLA) lub gwarancje czasu pracy. Projektując architekturę aplikacji składającą się z wielu usług platformy Azure, obliczamy ogólną umowę SLA dla aplikacji jako umowę złożoną ze wszystkich umów SLA innych usług.
Ta umowa SLA jest obliczana przez pomnożenie umów SLA usług składowych. Załóżmy na przykład, że nasza aplikacja składa się z usługi aplikacja systemu Azure Service (umowa SLA na 99,95%) i umowa SLA firmy Microsoft Entra (99,9%). Końcowy obliczony poziom umowy SLA wynosi 99,85%.
Jeśli taki procentowy współczynnik czasu działania nie jest wystarczający dla naszej aplikacji, możemy skonfigurować aplikację, aby przełączała się w tryb pracy awaryjnej w innym regionie.
Składniki globalne, regionalne i konfigurowalne
W naszym projekcie niektóre składniki są domyślnie globalne i nie są narażone na awarie regionalne.
Niektóre składniki są ograniczone do jednego regionu, na przykład usługa Application Gateway. Musimy wybrać alternatywną usługę dla tych typów składników.
Niektóre składniki można skonfigurować pod kątem obsługi wielu regionów. Można na przykład użyć opcji magazynu geograficznie nadmiarowego (GRS) na koncie usługi Azure Storage, które przechowuje zawartość statyczną. Magazyn GRS zreplikuje obiekty blob do innego regionu.
W poniższej tabeli przedstawiono składniki globalne, regionalne i konfigurowalne.
| Składnik | Obsługa wielu regionów | Komentarze |
|---|---|---|
| Usługa DNS platformy Azure | Globalnie | Nie są wymagane żadne zmiany. |
| Application Gateway | Regionalne | Każde wystąpienie usługi Application Gateway znajduje się w jednym regionie. |
| Azure CDN | Globalnie | Żadne zmiany nie są niezbędne, zawartość jest domyślnie buforowana globalnie. |
| Tożsamość Microsoft Entra | Globalnie | Nie są wymagane żadne zmiany. |
| Azure App Service | Regionalne | Każde wystąpienie aplikacji znajduje się w jednym regionie. |
| Aplikacje funkcji platformy Azure | Regionalne | Każde wystąpienie aplikacji funkcji znajduje się w jednym regionie. |
| Kolejki usługi Azure Storage | Konfigurowalny | Możesz wybrać replikację konta usługi Azure Storage do wielu regionów. |
| Azure Redis Cache | Regionalne | Każde wystąpienie pamięci podręcznej znajduje się w jednym regionie. |
| Azure Blob Storage | Konfigurowalny | Możesz wybrać replikację konta usługi Azure Storage do wielu regionów. |
| Azure Search | Regionalne | Każde wystąpienie usługi wyszukiwania znajduje się w jednym regionie. |
| Azure SQL Database | Konfigurowalny | Replikacja geograficzna umożliwia synchronizowanie danych z wieloma regionami. |
| Azure Cosmos DB | Konfigurowalny | Replikacja geograficzna umożliwia synchronizowanie danych z wieloma regionami. |
Proponowana architektura rozproszona
Po zbadaniu proponujesz architekturę, jak pokazano na poniższym diagramie.
W tym projekcie występuje region aktywny (Wschodnie stany USA) i region rezerwowy (Zachodnie stany USA). Region Wschodnie stany USA obsługuje wszystkie żądania wysyłane przez składniki w normalnych warunkach. Jeśli klęska żywiołowa spowoduje awarię regionalną, aplikacja zostanie przełączona w tryb pracy awaryjnej do regionu Zachodnie stany USA.
Sprawdźmy pobieżnie, jak zmieniono oryginalną architekturę. Bardziej szczegółowo zapoznamy się z tymi zmianami w kolejnych lekcjach.
Sieć
Usługi Azure DNS i Azure CDN są domyślnie systemami globalnymi, dlatego są odporne na awarie regionalne. Pozostawiamy je na miejscu.
Podczas tworzenia usługi Azure Application Gateway przypisujemy ją do jednego regionu. Usuwamy tę lukę w zabezpieczeniach, zastępując tę usługę usługą usługą Azure Front Door. Usługa Front Door może sondować wiele usług App Services i obsługiwać tryb failover usługi App Service z regionu Wschodnie stany USA do regionu Zachodnie stany USA.
Usługi aplikacji
Microsoft Entra ID to system globalny i nie wymaga żadnych modyfikacji.
Konta usługi Azure Storage można skonfigurować w taki sposób, aby replikować zawartość do wielu regionów. Do zmiany konfiguracji używamy jednej z opcji magazynu geograficznie nadmiarowego.
Inne składniki, takie jak App Service, aplikacje funkcji, pamięć podręczna Redis Cache i Azure Search, są regionalne. Tworzymy zduplikowane wystąpienia tych składników w regionie Zachodnie stany USA w naszym nowym projekcie architektury. W tym projekcie nowy region może przejąć obsługę, kiedy nastąpi przejście w tryb failover.
Magazyn danych
Usługi Azure SQL Database i Azure Cosmos DB obsługują replikację geograficzną danych do innych regionów. Skonfigurujemy te usługi tak, aby replikować dane wschodnie stany USA do równoważnych usług w regionie Zachodnie stany USA.
Pary regionalne
Region świadczenia usługi Azure to obszar położony w jednej lokalizacji geograficznej, który zawiera co najmniej jedno centrum danych platformy Azure. Wszystkie regiony tworzą pary z innymi regionami w tej samej lokalizacji geograficznej. W ramach tych par aktualizacje i planowane konserwacje są jednocześnie wykonywane tylko w jednym regionie. Jeśli wystąpi awaria mająca wpływ na wiele regionów, co najmniej jeden region z każdej pary będzie miał priorytet szybkiego odzyskiwania.
Najlepszym rozwiązaniem jest wdrożenie dwuregionowej architektury aplikacji w dwóch regionach tworzących parę regionalną. Na przykład region Wschodnie stany USA tworzy parę z regionem Zachodnie stany USA. Proponowany projekt używa regionu Wschodnie stany USA dla swojego aktywnego regionu, a zachodnie stany USA dla regionu rezerwowego.