Wdrażanie usługi Azure Spring Apps w wielu regionach

Ta architektura referencyjna opisuje podejście do uruchamiania wielu wystąpień usługi Azure Spring Apps w różnych regionach w konfiguracji aktywne-aktywne.

Ten projekt opiera się na architekturze bazowej usługi Azure Spring Apps. Punkt odniesienia wdraża aplikację Java Spring Boot w wielu strefach dostępności w jednym regionie. Obciążenie aplikacji w wielu strefach jest rozłożone między oddzielne lokalizacje, dzięki czemu obciążenie może tolerować lokalne awarie w regionie świadczenia usługi Azure.

Jeśli jednak cały region ulegnie awarii, punkt odniesienia stanie się niedostępny dla użytkownika. Celem tego projektu jest zbudowanie wysokiej dostępności, która może wytrzymać awarię regionalną.

Ta architektura jest przydatna do spełnienia następujących celów:

• Zwiększ ogólną odporność i cel poziomu usług (SLO) aplikacji.
• Włącz globalny zasięg dla aplikacji.
• Przybliż obciążenie do użytkownika końcowego i jak najmniejsze opóźnienie.
• Użyj regionu pomocniczego jako lokacji trybu failover dla regionu podstawowego i wybierz projekt aktywny-pasywny.

Aby zwiększyć odporność i niezawodność aplikacji, możesz wdrożyć aplikację w wielu regionach. W tym projekcie potrzebny jest router globalny do równoważenia obciążenia żądań do aplikacji w różnych regionach. Router globalny w tej architekturze odpowiada również innym celom.

Największym wyzwaniem w przypadku konfiguracji obejmującej wiele regionów jest replikowanie danych dla aplikacji między wieloma regionami. Ten problem nie jest problemem z konfiguracją wielostrefową. Strefy dostępności platformy Azure są połączone przez sieć o wysokiej wydajności z opóźnieniem rundy mniejszym niż 2 ms. Ten okres opóźnienia jest wystarczający dla większości aplikacji.

Architektura

Na poniższym diagramie przedstawiono architekturę dla tego podejścia:

Składniki

Składniki tej architektury są takie same jak architektura punktu odniesienia. Poniższa lista wyróżnia tylko zmiany w architekturze punktu odniesienia. Aby uzyskać dokumentację produktu dotyczącą usług platformy Azure, zobacz sekcję Powiązane zasoby .

• Usługa Azure Front Door działa jako globalny moduł równoważenia obciążenia. Ta usługa jest używana ze względu na jej możliwość zapewnienia wyższej dostępności z mniejszym opóźnieniem, większą skalą i buforowaniem na brzegu sieci.

Przepływ pracy

Architektura referencyjna implementuje następujący przepływ pracy:

1. Użytkownik wysyła żądanie do nazwy hosta HTTP aplikacji, na przykład www.contoso.com. Usługa Azure DNS rozpoznaje żądanie dla tej nazwy hosta w usłudze Azure Front Door.

2. Usługa Azure Front Door używa różnych konfiguracji równoważenia obciążenia do przekazywania żądań przychodzących do publicznego punktu końcowego usługi aplikacja systemu Azure Gateway w każdym regionie. Wystąpienia usługi Application Gateway są konfigurowane przy użyciu tej samej niestandardowej nazwy domeny i nazwy certyfikatu TLS co usługa Azure Front Door.

3. Usługa Application Gateway ze zintegrowaną zaporą aplikacji internetowej platformy Azure sprawdza żądanie. Zapora aplikacji internetowej zezwala na żądania przychodzące tylko z określonego profilu usługi Azure Front Door.

4. Usługa Application Gateway przekazuje dozwolony ruch do adresu IP modułu równoważenia obciążenia w aprowizowanych wystąpieniach aplikacji Spring Apps.

5. Wewnętrzny moduł równoważenia obciążenia kieruje ruch tylko z usługi Application Gateway do usług zaplecza. Te usługi są hostowane w wystąpieniu aplikacji Spring Apps wewnątrz sieci wirtualnej w każdym regionie.

6. W ramach przetwarzania żądania aplikacja komunikuje się z innymi usługami platformy Azure wewnątrz sieci wirtualnej. Przykłady obejmują aplikację komunikującą się z usługą Azure Key Vault na potrzeby wpisów tajnych i bazy danych na potrzeby przechowywania stanu.

Globalne rozproszenie

Jeśli projektujesz pod kątem wysokiej dostępności, możesz skonfigurować tę architekturę w trybie aktywne-aktywne,aktywne-pasywne z rezerwą gorącą lub aktywny-pasywny w trybie rezerwy zimnej.

Wybór zależy od wymagań dotyczących dostępności aplikacji. Ta architektura korzysta z wdrożenia aktywne-aktywne w dwóch regionach, ponieważ przykładowa organizacja chce mieć globalną obecność z umową SLA o wysokim czasie pracy (umowa dotycząca poziomu usług). Jeśli używasz aplikacji o znaczeniu krytycznym i chcesz uzyskać wyższą dostępność, musisz użyć więcej niż dwóch regionów.

Aktywne/aktywne

W trybie aktywny-aktywny wszystkie regiony przetwarzają żądania jednocześnie. Największym wyzwaniem w trybie aktywny-aktywny jest utrzymywanie synchronizacji danych między regionami. Ten tryb jest kosztownym podejściem, ponieważ płacisz dwa razy za prawie wszystkie składniki.

Aktywny-pasywny z gorącą rezerwą

W trybie aktywny-pasywny z rezerwą gorącą region pomocniczy nie odbiera żadnych żądań z usługi Azure Front Door, o ile region podstawowy jest aktywny. Upewnij się, że dane aplikacji są replikowane z regionu podstawowego do regionu pomocniczego. Jeśli wystąpi awaria w regionie podstawowym, musisz zmienić role baz danych zaplecza i przewrócić cały ruch przez usługę Azure Front Door do regionu pomocniczego.

W trybie aktywny-pasywny tryb failover powinien zająć trochę czasu, co ułatwia zapewnienie synchronizacji wszystkich danych. Jednak tryb aktywny-pasywny z rezerwą gorącą jest tak kosztowny, jak praca z trybem aktywny-aktywny.

Aktywny-pasywny z zimnym wstrzymaniem

W trybie aktywny-pasywny z rezerwą zimną region podstawowy ma wszystkie zasoby i obsługuje ruch. Region pomocniczy może mieć mniej składników lub składników z niższymi zasobami obliczeniowymi. Wybór technologii zależy od tego, ile przestojów jest akceptowalne zgodnie z wymaganiami biznesowymi. Zakres konfiguracji regionu pomocniczego również wpływa na koszty. Upewnij się, że co najmniej dane aplikacji znajdują się w regionie pomocniczym.

Jak wspomniano, tryb aktywny-pasywny obejmuje pewien czas pracy w trybie failover, więc łatwiej jest zachować wszystkie dane w synchronizacji. Tryb aktywny-pasywny z zimnym trybem wstrzymania jest najbardziej opłacalnym podejściem, ponieważ nie wdrażasz wszystkich zasobów w obu regionach.

Jeśli cała konfiguracja rozwiązania korzysta z szablonów, możesz łatwo wdrożyć zimny region pomocniczy rezerwowy, tworząc zasoby zgodnie z potrzebami. Można użyć szablonów programu Terraform, Bicep lub usługi Azure Resource Manager oraz zautomatyzować konfigurację infrastruktury w potoku ciągłej integracji/ciągłego wdrażania (CI/CD). Należy regularnie testować konfigurację, tworząc ponownie region pomocniczy, aby upewnić się, że szablony można wdrożyć w nagłych wypadkach.

Wzorzec sygnatur wdrażania jest zalecany, ponieważ można wdrożyć wiele niezależnych kopii aplikacji lub składnika z jednego szablonu do wielu regionów.

Porównanie trybu

Poniższa tabela zawiera podsumowanie nakładu pracy wymaganego do zsynchronizowania danych dla każdego trybu i porównania kosztów.

Routing między regionami

Ta architektura referencyjna używa węzłów geograficznych (geodezji), w których dowolny region może obsłużyć dowolne żądanie.

Usługa Azure Front Door jest skonfigurowana z równym routingiem między dwoma regionami wdrażania. Usługa Azure Front Door udostępnia również inne metody routingu ruchu do źródła. Jeśli chcesz kierować klientów do najbliższego źródła, routing oparty na opóźnieniach ma największe znaczenie. Jeśli projektujesz rozwiązanie aktywne-pasywne, routing oparty na priorytecie jest bardziej odpowiedni.

Przykład architektury referencyjnej używa reguły równoważenia obciążenia o równej wadze między dwoma regionami. Usługa Azure Front Door jest skonfigurowana przy użyciu:

• Domena niestandardowa i certyfikat zabezpieczeń warstwy transportu (TLS) o takiej samej nazwie jak nazwa hosta aplikacji, na przykład www.contoso.com.

• Jedno źródło na region, w którym jest wdrażana aplikacja, gdzie każde źródło jest wystąpieniem usługi aplikacja systemu Azure Gateway.

Układ grupy zasobów

Grupy zasobów platformy Azure umożliwiają zarządzanie zasobami wdrożonym w każdym regionie jako pojedynczą kolekcją. Rozważ umieszczenie regionu podstawowego, regionu pomocniczego i usługi Azure Front Door w oddzielnych grupach zasobów, jak pokazano na poniższym diagramie:

Na diagramie przedstawiono następującą konfigurację grup zasobów:

• Usługa Azure Front Door jest wdrażana w Application-shared grupie zasobów.
• Wszystkie zasoby hostowane w regionie Europa Zachodnia (weu) są wdrażane w Application-weu grupie zasobów.
• Zasoby hostowane w regionie Wschodnie stany USA (eus) są hostowane w Application-eus grupie zasobów.
• Zasoby hostowane w regionie Japonia Wschodnia (jae) są hostowane w Application-jae grupie zasobów.

Zasoby w tej samej grupie zasobów współużytkują ten sam cykl życia i można je łatwo tworzyć i usuwać razem. Każdy region ma własny zestaw zasobów w dedykowanej grupie zasobów, która jest zgodna z konwencją nazewnictwa na podstawie nazwy regionu. Usługa Azure Front Door znajduje się we własnej grupie zasobów, ponieważ musi istnieć, nawet jeśli inne regiony zostaną dodane lub usunięte.

Konfiguracja zwrotnego serwera proxy

Usługa Azure Front Door wykonuje globalne równoważenie obciążenia między regionami. Ten zwrotny serwer proxy pomaga dystrybuować ruch w przypadku wdrożenia obciążenia w wielu regionach. Alternatywnie możesz użyć usługi Azure Traffic Manager. Traffic Manager to oparty na systemie DNS moduł równoważenia obciążenia ruchu, który równoważy obciążenie tylko na poziomie domeny.

Usługa Azure Front Door ma zintegrowane sieci dostarczania zawartości (CDN), które dostarczają zawartość z globalnej sieci brzegowej firmy Microsoft z punktami obecności na całym świecie.

Bieżące rozwiązanie używa dwóch odwrotnych serwerów proxy w celu zachowania spójności z architekturą punktu odniesienia. Usługa Azure Front Door to router globalny. Usługa Application Gateway działa jako moduł równoważenia obciążenia na region. W większości przypadków ta konfiguracja nie jest wymagana. Jeśli spełniasz następujące wymagania, możesz usunąć usługę Application Gateway:

• Ponieważ zapora aplikacji internetowej platformy Azure jest dołączona do usługi Application Gateway, musisz dołączyć zaporę aplikacji internetowej do usługi Azure Front Door.
• Potrzebujesz sposobu, aby upewnić się, że połączenia przychodzące pochodzą tylko z wystąpienia usługi Azure Front Door. Możesz dodać X-Azure-FDID header sprawdzanie i zaewidencjonować zakresy adresów IP usługi Azure Front Door w aplikacji Spring Cloud Gateway. Aby uzyskać więcej informacji, zobacz Używanie usługi Azure Front Door jako zwrotnego serwera proxy z usługą Spring Cloud Gateway.

Aby uzyskać informacje o różnych scenariuszach zwrotnego serwera proxy, sposobie ich konfigurowania i zagadnieniach dotyczących zabezpieczeń, zobacz Uwidacznij usługę Azure Spring Apps za pośrednictwem zwrotnego serwera proxy.

Baza danych zaplecza

W przypadku wdrożenia w wielu regionach musisz mieć strategię replikacji danych. Gdy aplikacja jest dostępna w różnych regionach, dane powinny być synchronizowane, aby użytkownicy nie widzieli nieaktualnych danych.

Bieżąca architektura używa bazy danych MySQL dla bazy danych zaplecza, ale ta konfiguracja nie obsługuje synchronizacji danych. Po wybraniu technologii bazy danych sprawdź, jak najlepiej replikować i synchronizować dane między regionami. Jedną z opcji jest usługa Azure SQL Database, która ma aktywną funkcję replikacji geograficznej, która zapewnia stale synchronizowaną, czytelną pomocniczą bazę danych dla podstawowej bazy danych.

Tej funkcji można używać w następujących scenariuszach:

• Jeśli region pomocniczy jest zimnym stanem wstrzymania, który nie odbiera aktywnych żądań
• Aby przejść w tryb failover, jeśli region podstawowy ulegnie awarii
• Aby skonfigurować podstawowe i pomocnicze bazy danych z połączeniami łącza prywatnego z odpowiednimi regionami za pośrednictwem komunikacji równorzędnej sieci wirtualnej między dwoma regionami.

Innym podejściem jest użycie usługi Azure Cosmos DB. Ta usługa może globalnie dystrybuować dane przez przezroczyste replikowanie danych do wszystkich regionów na koncie usługi Azure Cosmos DB. Możesz również skonfigurować usługę Azure Cosmos DB z wieloma regionami zapisu. Aby uzyskać więcej informacji, zobacz Wzorzec geode.

Wdrożenie automatyczne

Automatyzowanie wdrażania infrastruktury i wdrożeń kodu aplikacji w jak największej ilości.

Automatyzacja wdrożeń infrastruktury gwarantuje, że infrastruktura jest skonfigurowana identycznie, co pomaga uniknąć dryfu konfiguracji, takiego jak między regionami. Automatyzacja infrastruktury może również testować operacje przełączania w tryb failover.

W przypadku wdrażania aplikacji upewnij się, że systemy wdrażania są przeznaczone dla wielu regionów, w których muszą zostać wdrożone. Można również użyć wielu regionów w strategii wdrażania niebieskiego lub kanarowego. Dzięki tym strategiom wdrażania wdrażasz nowe wersje aplikacji w jednym regionie na potrzeby testowania i do innych regionów po pomyślnym zakończeniu testowania.

Wydajność i skalowalność   

Ta architektura jest lepiej odpowiednia niż architektura bazowa, aby sprostać wymaganiom aplikacji, ponieważ rozkłada obciążenie między regionami. Jeśli skonfigurujesz usługę Azure Front Door do kierowania żądań na podstawie opóźnienia, użytkownicy będą otrzymywać lepsze czasy odpowiedzi, ponieważ żądania są kierowane do regionów najbliższych im.

W zależności od konfiguracji bazy danych może wystąpić dodatkowe opóźnienie, gdy dane muszą być synchronizowane między regionami. To opóźnienie można przezwyciężyć przy użyciu usługi Azure Cosmos DB z bardziej zrelaksowanym poziomem spójności.

Ta architektura referencyjna zawiera kilka składników, które mogą automatycznie skalować na podstawie metryk:

• Usługa Azure Front Door może automatycznie skalować na podstawie zapotrzebowania. Możesz użyć innych funkcji usługi Azure Front Door, takich jak przyspieszanie ruchu i buforowanie, aby przybliżyć zasoby do użytkowników końcowych.
• Usługa Application Gateway obsługuje skalowanie automatyczne. Aby uzyskać więcej informacji, zobacz Skalowanie usługi Application Gateway w wersji 2 i Zapora aplikacji internetowej w wersji 2.
• Usługa Azure Spring Apps obsługuje również skalowanie automatyczne. Aby uzyskać więcej informacji, zobacz Konfigurowanie automatycznego skalowania dla aplikacji.

Kwestie związane z kosztami

To rozwiązanie skutecznie podwaja szacunki kosztów architektury punktu odniesienia.

Głównymi przyczynami kosztów związanych z rozwiązaniem obejmującym wiele regionów są:

• Podstawowe i pomocnicze bazy danych muszą używać tej samej warstwy usługi; w przeciwnym razie pomocnicza baza danych może nie nadążać za zmianami replikacji.
• Znaczący ruch między regionami zwiększa koszty. Opłaty są naliczane za ruch sieciowy między regionami platformy Azure.

Aby zarządzać tymi kosztami, należy wziąć pod uwagę następujące zalecenia dotyczące implementacji:

• Używaj skalowanych w dół wersji zasobów, takich jak Azure Spring Apps i Application Gateway w regionie rezerwowym, i skaluj zasoby w górę tylko wtedy, gdy rezerwa stanie się aktywna.
• Jeśli scenariusze biznesowe są dozwolone, utwórz konfigurację aktywne-pasywne, aby zaoszczędzić na kosztach.
• Zaimplementuj konfigurację z wieloma strefami w jednym regionie, aby zaspokoić potrzeby biznesowe dotyczące dostępności i odporności. Ta opcja może być bardziej opłacalna, ponieważ płacisz tylko za większość zasobów raz.
• Wybierz alternatywną konfigurację, która używa tylko jednego zwrotnego serwera proxy, aby pomóc zaoszczędzić na kosztach. Należy pamiętać, że należy zastosować dodatkową konfigurację, aby zachować bezpieczeństwo tej alternatywy.

Oszacowaliśmy koszt usług w tej architekturze za pomocą kalkulatora cen platformy Azure przy użyciu rozsądnych wartości domyślnych dla aplikacji o małej skali. Możesz zaktualizować to oszacowanie na podstawie oczekiwanych wartości przepływności dla aplikacji.

Inne uwagi

Zagadnienia dotyczące projektowania architektury linii bazowej obejmującej wiele stref mają zastosowanie również do rozwiązania z wieloma regionami opisanymi w tym artykule. Przejrzyj następujące kwestie w kontekście architektury obejmującej wiele regionów:

• Zabezpieczenia sieci. Ważne jest, aby kontrolować komunikację za pośrednictwem sieci. To rozwiązanie umożliwia tylko wywołania przychodzące z usługi Azure Front Door, gdzie wywołania są kierowane do usługi Application Gateway w każdym regionie. W usłudze Application Gateway wywołania są kierowane do usługi Azure Spring Apps zaplecza. Komunikacja z usługi Azure Spring Apps do usług pomocniczych, takich jak Key Vault, jest również kontrolowana przy użyciu prywatnych punktów końcowych. Aby uzyskać więcej informacji, zobacz Architektura punktu odniesienia: zabezpieczenia sieci.

• Zarządzanie tożsamościami i dostępem. Zaimplementuj bardziej bezpieczny dostęp przy użyciu tożsamości zarządzanych w celu nawiązania połączenia między różnymi składnikami. Przykładem jest sposób, w jaki usługa Azure Spring Apps używa tożsamości zarządzanej do nawiązywania połączenia z usługą Key Vault. Aby uzyskać więcej informacji, zobacz Architektura punktu odniesienia: zarządzanie tożsamościami i dostępem.

• Monitorowanie. Możesz dodać instrumentację i włączyć śledzenie rozproszone w celu zbierania danych z aplikacji. Połącz to źródło danych z diagnostyką platformy, aby uzyskać kompleksowe informacje o aplikacji. Aby uzyskać więcej informacji, zobacz Architektura linii bazowej: Monitorowanie.

• Zarządzanie wpisami tajnymi. Rozwiązanie z wieloma regionami przechowuje wpisy tajne i certyfikaty aplikacji w jednym magazynie kluczy. Aby uzyskać więcej informacji, zobacz Architektura punktu odniesienia: zarządzanie wpisami tajnymi.

Wdrożenie scenariusza

Wdrożenie tej architektury referencyjnej jest dostępne w temacie Architektura referencyjna usługi Azure Spring Apps w wielu regionach w witrynie GitHub. Wdrożenie korzysta z szablonów programu Terraform.

Aby wdrożyć architekturę, postępuj zgodnie z instrukcjami krok po kroku.

Współautorzy

Firma Microsoft utrzymuje tę zawartość. Następujący współautor opracował oryginalną zawartość.

Główny autor:

• Gitte Vermeiren | Rozwiązanie FastTrack dla inżyniera platformy Azure

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Aby zintegrować to obciążenie z usługami udostępnionymi zarządzanymi przez centralne zespoły w organizacji, wdróż je w strefie docelowej aplikacji platformy Azure.

Powiązane zasoby

Aby uzyskać dokumentację dotyczącą usług i funkcji platformy Azure używanych w tej architekturze, zobacz następujące artykuły:

• Azure Spring Apps
• Azure Front Door
• aplikacja systemu Azure Gateway w wersji 2
• Azure Database for MySQL
• Azure Key Vault
• Usługa DNS platformy Azure
• Zapora aplikacji internetowej platformy Azure
• Link prywatny platformy Azure
• Tożsamości zarządzane usługi Microsoft Entra dla zasobów platformy Azure

Zalecamy następujące przewodniki, aby lepiej zrozumieć opcje konfiguracji związane z tą architekturą:

• Uwidacznianie usługi Azure Spring Apps za pośrednictwem zwrotnego serwera proxy
• Niebieskie/zielone wdrożenie aplikacji o wysokiej dostępności
• Zachowaj oryginalną nazwę hosta HTTP między zwrotnym serwerem proxy i jego aplikacją internetową zaplecza

Ta architektura została zaprojektowana zgodnie z filarami platformy Microsoft Azure Well-Architected Framework. Zalecamy przejrzenie zasad projektowania dla każdego filaru.