Wzorzec geode

Wdróż kolekcję usług zaplecza w zestawie węzłów geograficznych, z których każdy może obsłużyć dowolne żądanie od dowolnego klienta w dowolnym regionie. To podejście active-active rozkłada obsługę żądań na całym świecie, aby zmniejszyć opóźnienia i zwiększyć dostępność.

Osiem geod jest rozmieszczonych na mapie świata: dwie w Ameryce Północnej, dwie w Azji i po jednej w Ameryce Południowej, Europie, południowej Afryce i Australii. Legenda odróżnia strefy geograficzne od centrów danych, pokazanych jako niebieskie kropki, oraz lokalizacje brzegowe, wyświetlane jako pomarańczowe kropki. Kropkowane linie sieciowe łączą lokalizacje na kontynentach i oceanach, tworząc globalną sieć wokół geod.

Kontekst i problem

Wiele usług na dużą skalę stoi przed wyzwaniami dotyczącymi dostępności geograficznej i skali. Klasyczne projekty często przenoszą dane do zasobów obliczeniowych, przechowując dane na zdalnym serwerze SQL, który również przetwarza dane. Polegają one na skalowaniu w górę w celu obsługi wzrostu.

Podejście klasyczne może powodować następujące problemy:

• Użytkownicy w odległych regionach mogą doświadczyć opóźnienia sieci podczas nawiązywania połączenia z punktem końcowym usługi hostingowej.
• Wzrost zapotrzebowania może przeciążać usługi w jednym regionie.
• Wdrażanie kopii infrastruktury aplikacji w wielu regionach dla całodobowej usługi może zwiększyć złożoność i koszt.

Infrastruktura chmury obsługuje globalny routing i replikację danych geograficznych. Aby zmniejszyć opóźnienia dla geograficznie rozproszonej bazy użytkowników, umieść zasoby obliczeniowe razem z regionalnymi replikami danych, które przetwarzają. Wzorzec geode umożliwia przenieść obliczenia tam, gdzie są dane.

Solution

Wdróż usługę w wielu lokalizacjach geograficznych. Każde wdrożenie jest nazywane geodą. Użyj globalnej usługi routingu, aby dystrybuować żądania zgodnie z zasadami routingu i sprawdzaniem kondycji. Każda geoda uzyskuje dostęp do magazynu danych replikowanego geograficznie.

Skonfiguruj warstwę danych, aby każdy geode mógł obsługiwać te same operacje aplikacji zgodnie z wymaganiami obciążenia dotyczącymi modelu eventual consistency. Geody mogą obserwować różne wersje elementu, gdy trwa replikacja. Aplikacja musi uwzględniać opóźnienie replikacji i współbieżne zapisy, szczególnie w przypadku przenoszenia żądań między geode’ami.

Na przykład konto Azure Cosmos DB dla interfejsu NoSQL skonfigurowane z wieloma regionami zapisu może obsługiwać odczyty i zapisy w regionie każdego geodu. Azure Cosmos DB zapisy w wielu regionach są replikowane asynchronicznie.

W architekturze stempla wdrożeniowego każdy stempel obsługuje przypisany podzbiór użytkowników lub dzierżawców. W architekturze Geode każdy Geode może obsługiwać te same operacje aplikacji dla dowolnego użytkownika i uzyskiwać dostęp do danych potrzebnych do tych operacji. Oba wzorce używają wielu wdrożeń; wybierz między nimi na podstawie tego, czy żądanie się kwalifikuje, oraz umieszczania danych.

Każda geoda zawiera komponent wejściowy wskazujący na stos komponentów przetwarzania. Strzałki łączą stos przetwarzania z trzema składnikami pomocniczymi i bazą danych. Połączenia między przetwarzaniem a bazą danych są dwukierunkowe w Geode B, C i D i są skierowane w stronę bazy danych w Geode A. Gruba szara płaszczyzna tylna replikacji biegnie wzdłuż dołu, ze strzałkami skierowanymi w górę do każdej bazy danych i strzałką powrotną z Geode A. Symbole łańcucha oznaczają Geode A i B jako sparowane, a Geode C i D jako sparowane.

Geody mają następujące cechy:

• Każda geoda składa się z kolekcji typów zasobów, często zdefiniowanych w szablonie wdrożenia.
• Każdy geod zawiera zasoby regionalne potrzebne do obsługi żądań bez zależności od warstwy aplikacji innego geodu. Współużytkowane usługi routingu i danych nadal mogą istnieć w architekturze.
• Geody są luźno powiązane za pośrednictwem globalnego routingu i magistrali replikacji. Warstwa routingu kieruje żądania do dostępnych geodów, a warstwa danych replikuje aktualizacje między nimi. Aplikacja nadal potrzebuje odpowiedniego modelu spójności i strategii obsługi konfliktów.

Wzorzec geode występuje w architekturach big data, które używają powszechnie dostępnego sprzętu do przetwarzania danych kolokowanych na tej samej maszynie i MapReduce w celu skonsolidowania wyników między maszynami. Innym zastosowaniem jest przetwarzanie near-edge, które przybliża obliczenia do krawędzi sieci, aby skrócić czas odpowiedzi.

Wybierz liczbę i rozmieszczenie geodów w zależności od awarii regionalnych, które musi tolerować obciążenie. Dostępność zależy od współużytkowanych zależności w dobrej kondycji oraz wystarczającej pojemności obliczeniowej i pojemności bazy danych w ocalałych geodach do obsługi przekierowywanego ruchu.

Problemy i zagadnienia

Aby zaimplementować ten wzorzec, użyj następujących technik i technologii:

• Skorzystaj z praktyk i narzędzi DevOps, aby tworzyć i wdrażać identyczne geodes w różnych regionach lub wystąpieniach.
• Skalowanie automatyczne umożliwia skalowanie w poziomie zasobów obliczeniowych i przepływności bazy danych w obrębie każdego geodu, z zastrzeżeniem ograniczeń współdzielonej magistrali wewnętrznej.
• W przypadku implementacji interfejsu API HTTP Azure Front Door zapewnia przyspieszenie ruchu przez sieć brzegową i podział połączeń TCP.
• Użyj magazynu danych replikowanego geograficznie, aby kontrolować spójność danych. W przypadku przykładu zapisu w wielu regionach usługi Cosmos DB skonfiguruj routing regionalny zestawu SDK, aby każda geoda odczytywała i zapisywała dane do lokalnego regionu bazy danych oraz mogła używać skonfigurowanych regionów rezerwowych.
• Rozważ obliczenia rozliczane według użycia, aby zmniejszyć koszty bezczynności pojemności podczas przenoszenia obciążenia między geodes. Ta strategia może umożliwić wdrożenie wielu geod przy minimalnych dodatkowych inwestycjach. Oszczędności zależą od obciążenia i planu hostingu.
• Azure API Management jest opcjonalne. Umieść ją przed każdą aplikacją funkcji geode, gdy potrzebujesz możliwości zarządzania interfejsem API, takich jak ograniczanie szybkości.

Podczas podejmowania decyzji o sposobie implementacji tego wzorca należy wziąć pod uwagę następujące kwestie:

• Wybierz poziom spójności spełniający wymagania odczytu podczas przenoszenia żądań między geodami.

  W przypadku spójności sesji w Azure Cosmos DB zwróć token sesji do klienta, a klient powinien dołączać go do kolejnych żądań odczytu, aby zagwarantować, że gwarancje odczytu własnych zapisów zostaną zachowane podczas routingu do innego Geode. W przypadku kont z zapisem wieloregionowym użyj tych udostępnionych tokenów tylko w przypadku żądań odczytu.

  Wybierz zasadę rozwiązywania konfliktów dla współbieżnych zapisów.

• Zdefiniuj scenariusze awarii, które obciążenie musi tolerować, w tym awarie regionalne i awarie współdzielonych zależności. Określ rozmiar geodes przy przekierowanym obciążeniu szczytowym.

• Przetestuj regionalny tryb failover i odzyskiwanie pod reprezentatywnym obciążeniem w kontrolowanym środowisku. Uwzględnij błędy współużytkowanych zależności i failback.

• Określ, czy dane mają być przetwarzane lokalnie w każdym regionie, czy obliczać agregacje w jednym geode i replikować wyniki globalnie. Procesor źródła zmian usługi Azure Cosmos DB oferuje tę szczegółową kontrolę przy użyciu koncepcji kontenera dzierżaw oraz LeaseContainerPrefix w odpowiednim powiązaniu funkcji Azure Functions. Każde podejście ma różne zalety i wady.

• Geody mogą współpracować przy użyciu kanału informacyjnego o zmianach usługi Azure Cosmos DB i platformy komunikacji w czasie rzeczywistym, takiej jak SignalR. Mogą komunikować się ze zdalnymi użytkownikami za pośrednictwem innych geod w topologii siatki, nie znając ani nie przejmując się lokalizacją tych użytkowników.

• Śledź komponenty tego żądania, które są wykonywane asynchronicznie na różnych wystąpieniach lub geodach. Monitoruj współużytkowane zależności, a także zasoby regionalne, aby można było zidentyfikować skorelowane błędy. Zarówno Azure Front Door, jak i Azure Cosmos DB mogą być zintegrowane z Log Analytics, a Azure Functions mogą używać usługi Application Insights do monitorowania aplikacji.

• Zabezpiecz punkty wejścia w każdej warstwie wdrożenia rozproszonego.

  • Ogranicz dostęp do usługi Azure Cosmos DB dla aplikacji funkcji.
  • W przypadku publicznych źródeł aplikacji funkcji za Azure Front Door skonfiguruj ograniczenia dostępu, które łączą AzureFrontDoor.Backend tag usługi i filtr nagłówka X-Azure-FDID pasujący do identyfikatora profilu usługi Front Door w tej samej regule zezwalania. Odrzucaj niedopasowane żądania.

  Zachowaj uwierzytelnianie klienta wywołującego interfejs API niezależnie od tych mechanizmów kontroli dostępu do źródła.

• Upewnij się, że każdy geode może uzyskiwać dostęp do sekretów, których wymaga z usługi Key Vault, oraz koordynować obsługę aprowizacji i rotację udostępnionych sekretów.

• Wydajność zależy od liczby geode i modelu hostingu obliczeniowego używanego dla interfejsu API poszczególnych geode. Należy ocenić różnicę kosztów między dodawaniem geod a zwiększeniem pojemności poszczególnych geod.

• Użyj zasobów strefowo nadmiarowych, w których są obsługiwane, aby zmniejszyć wpływ awarii strefy dostępności w obrębie regionu każdej geody. Wybierz regiony na podstawie opóźnień, rezydencji danych, dostępności usługi i wymagań dotyczących odzyskiwania.

• Użyj drzewa decyzyjnego równoważenia obciążenia , aby wybrać fronton dla interfejsu API.

• W przypadku usługi Front Door skonfiguruj wybór źródła pochodzenia, aby był zgodny z projektem aktywne-aktywne. Nadaj jednocześnie aktywnym geodom ten sam priorytet, a następnie skonfiguruj czułość opóźnienia i wagi.

Kiedy należy używać tego wzorca

Tego wzorca należy używać w następujących scenariuszach:

• Potrzebujesz platformy o dużej skali dla użytkowników rozmieszczonych w szerokim obszarze geograficznym.
• Obciążenie robocze musi nadal obsługiwać żądania krytyczne podczas regionalnych awarii uwzględnionych w modelu awarii.

Ten wzorzec może nie być odpowiedni w następujących scenariuszach:

• Twoja architektura ogranicza dane lub użytkowników do określonych wdrożeń, na przykład w celu spełnienia regionalnych wymagań dotyczących lokalizacji danych. Rozważ stemple wdrożenia z routingiem uwzględniającym dane, gdy tylko niektóre wdrożenia mogą obsługiwać danego użytkownika.
• Obciążenie robocze może spełniać wymagania w jednym regionie. Rozważ wdrożenia strefowo nadmiarowe tam, gdzie są obsługiwane, i osobno oceń regionalne odzyskiwanie po awarii.
• Stan sesji lub zależności danych aplikacji wiążą żądania z jednym regionem. Istniejące aplikacje mogą wymagać zmian w zarządzaniu stanem, replikacji danych i automatyzacji wdrażania, zanim ich wdrożenia w regionach będą mogły obsługiwać te same operacje.
• Wymagania dotyczące dostępności i opóźnień nie uzasadniają dystrybucji geograficznej, na przykład gdy większość użytkowników i danych znajduje się w jednym regionie.

Projektowanie obciążenia pracy

Architekt powinien ocenić, jak wzorzec Geode może być wykorzystany w projektowaniu obciążenia, aby sprostać celom i zasadom omówionym w filarach Azure Well-Architected Framework. Na przykład:

Filar	Jak ten wzorzec obsługuje cele filaru
Decyzje projektowe dotyczące niezawodności pomagają obciążeniu stać się odporne na awarię i zapewnić, że zostanie przywrócony do w pełni funkcjonalnego stanu po wystąpieniu awarii.	Wdrożenia regionalne i replikacja danych mogą pomóc obciążeniu roboczemu tolerować co najmniej jedną awarię regionalną. - RE:05 Redundancja - Regiony i strefy dostępności
Efektywność wydajności pomaga wydajnie sprostać wymaganiom dzięki optymalizacjom skalowania, danych i kodu.	Lokalne przetwarzanie i dostęp do danych mogą zmniejszyć opóźnienie żądań dla rozproszonej geograficznie grupy użytkowników. Zmniejsza to opóźnienie, eliminując ruch długodystansowy i dlatego, że udostępniasz infrastrukturę tylko użytkownikom, którzy obecnie korzystają z tej samej geode. - PE:03 Wybieranie usług

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Examples

• Active Directory Domain Services (AD DS) w Windows Server ilustruje częściowy wariant tego wzorca. Kontrolery domeny z możliwością zapisu używają replikacji wielowzorcowej dla partycji katalogu, które obsługują. Niektóre operacje wymagają wyznaczonego właściciela roli FSMO, dlatego kontrolery domeny nie są zamienne we wszystkich operacjach.

• Następujące usługi Azure ilustrują zamienność obsługi żądań między regionami:

  • Azure Cosmos DB for NoSQL: po włączeniu zapisu w wielu regionach każdy skonfigurowany region zawiera wszystkie partycje danych kontenera i może obsługiwać odczyty i zapisy. Te regionalne wdrożenia obsługujące dane ilustrują geodes dla tego konta.
  • Azure Managed Redis: przy aktywnej replikacji geograficznej każde połączone wystąpienie regionalne może akceptować odczyty i zapisy w tej samej pamięci podręcznej logicznej.
  • Azure Front Door: każdy punkt obecności usługi Front Door może obsłużyć dowolne żądanie. Te lokalizacje brzegowe pokazują geograficznie zamienne moduły obsługi żądań HTTP.

Następny krok

Zapoznaj się z linią bazową usługi AKS dla klastrów wieloregionowych, aby uzyskać powiązane wskazówki dotyczące regionalnych zasobów obliczeniowych w konfiguracji aktywna-aktywna i routingu globalnego.