Projektowanie architektury aplikacji rozproszonej geograficznie
Kiedy nasze składniki sieciowe będą kierować żądania do wielu regionów w celu ograniczenia skutków awarii regionalnej, usługi aplikacji muszą być tak zaprojektowane, aby móc odpowiedzieć na te żądania zarówno w regionie podstawowym, jak i rezerwowym.
Jak wspomniano wcześniej, planujemy skonfigurować usługę Azure Front Door z priorytetowym przypisaniem zaplecza. Region Wschodnie stany USA jest przypisywany jako nasz region podstawowy, a region Zachodnie stany USA jako nasz region rezerwowy. W przypadku wystąpienia awarii regionalnej żądania są kierowane do usługi App Service w regionie niefajnym. W każdym regionie musimy skonfigurować zasoby na potrzeby przejścia w tryb failover. Dotyczy to dostępu użytkownika, zreplikowanego magazynu i kodu aplikacji.
W tym miejscu analizujemy usługi aplikacji w naszym rozwiązaniu i określamy, czy należy je zmodyfikować, aby działały w architekturze obejmującej wiele regionów. W szczególności przyjrzymy się usłudze Active Directory, magazynowi zawartości statycznej, aplikacjom internetowym, internetowym interfejsom API, kolejkom, funkcjom platformy Azure i pamięciom podręcznym danych.
Tożsamość Microsoft Entra
W naszym portalu śledzenia przesyłek użytkownicy mogą śledzić dostarczanie swoich zakupów, wprowadzając numer śledzenia. Jednak stali użytkownicy mogą zarejestrować się w celu uzyskania dostępu do funkcji zaawansowanych, takich jak informacje o dostarczeniu i inne dane statystyczne. Opracowaliśmy portal śledzenia do przechowywania kont użytkowników w usłudze Microsoft Entra ID.
Microsoft Entra ID jest domyślnie zaprojektowany jako system globalny. W związku z tym nie jest ona narażona na awarie regionalne i nie trzeba modyfikować tego składnika systemu.
Azure Blob Storage
Zawartość statyczna, na przykład obrazy i filmy wideo, jest przechowywana na kontach usługi Azure Storage w postaci dużych obiektów binarnych (BLOB) i jest udostępniana użytkownikom za pośrednictwem usługi Azure CDN.
W naszym oryginalnym projekcie konto magazynu znajduje się w jednym regionie, ponieważ chcemy skorzystać z magazynu lokalnie nadmiarowego (LRS). Nasze dane są replikowane tylko w obrębie jednego centrum danych w trybie LRS. W związku z tym w tej konfiguracji konto magazynu będzie niedostępne, jeśli wystąpi awaria regionalna. Każda zawartość statyczna, która jest już buforowana przez sieć CDN, pozostaje dostępna dla użytkowników.
Ta sama sytuacja wystąpi w przypadku magazynu strefowo nadmiarowego (ZRS). Mimo że w tej konfiguracji dane są replikowane do różnych centrów danych, wszystkie te centra danych znajdują się jednak w tym samym regionie. Awaria regionalna wpływa również na konto magazynu w tej konfiguracji.
Buforowanie zawartości statycznej jest w naszym projekcie oparte głównie na konfiguracji usługi CDN. Może zajść taka sytuacja, że w czasie awarii użytkownik zażąda pliku statycznego, który jeszcze nie znajduje się w pamięci podręcznej usługi CDN. Wyświetlenie żądanej grafiki lub filmu wideo byłoby w takim przypadku niemożliwe.
Jeśli wybierzemy opcję magazynu geograficznie nadmiarowego, możemy wyeliminować taką możliwość przez replikację konta magazynu do wielu regionów. Dostępna jest również opcja replikacji tylko do odczytu, aby zapobiec dodawaniu zawartości statycznej podczas regionalnej awarii.
W przypadku konieczności włączenia nadmiarowości geograficznej mamy do wyboru dwie opcje. Te opcje to magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GRS) i magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GZRS). Wybór, który robimy, zależy od naszego budżetu i procentu potrzebnego czasu.
Azure App Service i aplikacje funkcji platformy Azure
Nasz portal śledzenia przesyłek implementuje dwie usługi Azure App Services. Pierwsza usługa App Service hostuje aplikację internetową, która implementuje interfejs internetowy dostępny dla użytkownika, a drugi hostuje internetowy interfejs API używany przez aplikacje mobilne do śledzenia danych przesyłek. Wszystkie nasze zadania w tle działają jako aplikacje funkcji platformy Azure.
W naszym oryginalnym projekcie każda usługa Azure App Service znajduje się w jednym regionie świadczenia usługi Azure. Utworzymy drugą usługę App Service w regionie pomocniczym (Zachodnie stany USA) i wdrożymy tam projekt internetowy w celu obsługi nowej architektury obejmującej wiele regionów. Konfigurujemy tryb routingu priorytetowego usługi Azure Front Door tak, aby wysyłał żądania do naszego regionu pomocniczego, gdy region podstawowy jest niedostępny.
Aby zapewnić jak najbardziej bezproblemowe przejście w tryb failover, upewnij się, że aplikacja internetowa nie przechowuje w pamięci żadnych informacji o stanie sesji. Zmieniamy naszą witrynę internetową, aby upewnić się, że nie kończy się to utratą danych. Jeśli na przykład nasz kod przechowuje listę przesyłek użytkowników w pamięci, ta lista zostanie utracona w przypadku wystąpienia trybu failover.
Jeśli stan sesji nie jest przechowywany, poszczególne żądania internetowe nie będą miały na siebie wpływu. Jeśli w trakcie trwania sesji użytkownika nastąpi przełączenie w tryb failover, to takie zachowanie powinno być niewidoczne dla użytkownika.
Wprowadzimy podobną zmianę w aplikacjach funkcji platformy Azure. Tworzymy oddzielne wystąpienie funkcji platformy Azure w regionie pomocniczym i wdrażamy w nim ten sam kod niestandardowy, co przebiegi w regionie podstawowym.
Ważne
Pamiętaj, że jeśli wdrożysz aktualizację kodu niestandardowego usługi App Service lub aplikacji funkcji, konieczne będzie przekazanie tej aktualizacji do wszystkich wystąpień usługi App Service. Jeśli chcesz zautomatyzować ten proces, usługa Azure DevOps zawiera narzędzia, które mogą w tym pomóc.
Kolejki usługi Azure Storage
W naszej oryginalnej architekturze z obsługą jednego regionu użyto kolejki na koncie usługi Azure Storage do zarządzania komunikacją między usługą App Service a aplikacją funkcji. Gdy aplikacja internetowa lub internetowy interfejs API musi uruchomić zadanie w tle, umieszcza w kolejce komunikat ze wszystkimi wymaganymi informacjami. Aplikacja funkcji monitoruje kolejkę pod kątem nowych komunikatów i wykonuje zadanie w tle, uruchamiając wymagane zapytania względem magazynów danych.
Dzięki użyciu kolejki możemy w uporządkowany sposób zarządzać wysokim zapotrzebowaniem w żądaniach internetowych. Jeśli istnieje wiele zadań w tle do uruchomienia, kolejka może zostać skompilowana, ale zadania nie zostaną porzucone. Pozostają w kolejce do momentu ich przetworzenia. Aplikacje funkcji wykonują działania na kolejce i zmniejszają jej rozmiar, gdy zapotrzebowanie spada. Jeśli zapotrzebowanie będzie nadal występować, zwiększamy liczbę wystąpień aplikacji funkcji.
W wersji portalu śledzenia przesyłek z obsługą wielu regionów musimy mieć pewność, że elementy kolejki nie zostaną utracone w przypadku przełączenia w tryb failover. Nasza kolejka jest zdefiniowana w usłudze Azure Storage, dzięki czemu na potrzeby replikacji geograficznej możemy użyć opcji nadmiarowości.
Należy pamiętać, że nie możemy skorzystać z opcji nadmiarowości z dostępem do odczytu, ponieważ nasza kolejka obsługuje operacje odczytu i zapisu. Usługa App Service musi mieć możliwość dodawania elementów do kolejki, a aplikacja funkcji musi móc usuwać ukończone elementy z kolejki. Zamiast tego należy więc użyć magazynu geograficznie nadmiarowego (GRS) lub magazynu strefowo nadmiarowego (GZRS).
Azure Redis Cache
Usługa Azure Redis Cache umożliwia nam zmaksymalizowanie wydajności magazynu danych. Pamięć podręczna Redis Cache buforuje wszystkie wyniki zapytań generowane z naszych aplikacji, ponieważ żądają one danych z naszej bazy danych. Wszelkie dalsze zapytania dotyczące podobnych danych nie wymagają zapytania bazy danych i są pobierane z pamięci podręcznej Redis.
W przypadku architektury obejmującej wiele regionów tworzymy wystąpienie pamięci podręcznej Redis Cache zarówno w regionach podstawowych, jak i rezerwowych. Należy pamiętać, że w przypadku przełączenia w tryb failover, pamięć podręczna Redis Cache w regionie rezerwowym będzie prawdopodobnie pusta. Ta pusta pamięć podręczna nie powoduje żadnych błędów, ale wydajność może tymczasowo spaść, ponieważ dane wypełniają nową pamięć podręczną.