Wzorzec geode

Wzorzec geode obejmuje wdrożenie kolekcji usług zaplecza w zestawie geographical nodes, z których każde może obsłużyć dowolne żądanie dla dowolnego klienta w dowolnym regionie. Ten wzorzec umożliwia obsługę żądań w stylu aktywny-aktywny , poprawę opóźnienia i zwiększenie dostępności przez dystrybucję przetwarzania żądań na całym świecie.

Kontekst i problem

Wiele usług na dużą skalę ma szczególne wyzwania związane z dostępnością i skalą geograficzną. Klasyczne projekty często przynoszą dane do obliczeń , przechowując dane na zdalnym serwerze SQL, który służy jako warstwa obliczeniowa dla tych danych, opierając się na skalowaniu w górę na potrzeby wzrostu.

Podejście klasyczne może stanowić szereg wyzwań:

• Problemy z opóźnieniami sieci dla użytkowników pochodzących z drugiej strony świata w celu nawiązania połączenia z punktem końcowym hostingu
• Zarządzanie ruchem w przypadku wzrostów zapotrzebowania, które mogą przeciążać usługi w jednym regionie
• Zbyt kosztowna złożoność wdrażania kopii infrastruktury aplikacji w wielu regionach dla usługi 24x7

Nowoczesna infrastruktura chmury ewoluowała, aby umożliwić geograficzne równoważenie obciążenia usług frontonu, umożliwiając jednocześnie replikację geograficzną usług zaplecza. Aby zapewnić dostępność i wydajność, uzyskanie danych bliżej użytkownika jest dobre. Gdy dane są rozproszone geograficznie w dalekiej bazie użytkowników, rozproszone geograficznie magazyny danych powinny być również kolokowane z zasobami obliczeniowymi, które przetwarzają dane. Wzorzec geode powoduje przeniesienie obliczeń do danych.

Rozwiązanie

Wdróż usługę w wielu wdrożeniach satelitarnych rozmieszczonych na całym świecie, z których każda jest nazywana geodeą. Wzorzec geode wykorzystuje kluczowe funkcje platformy Azure do kierowania ruchu przez najkrótszą ścieżkę do pobliskiego geode, co zwiększa opóźnienia i wydajność. Każdy geode znajduje się za globalnym modułem równoważenia obciążenia i używa usługi geograficznie replikowanej do odczytu i zapisu, takiej jak Usługa Azure Cosmos DB do hostowania płaszczyzny danych, zapewniając spójność danych między geode. Usługi replikacji danych zapewniają, że magazyny danych są identyczne w obrębie geod, dzięki czemu wszystkie żądania mogą być obsługiwane ze wszystkich geod.

Kluczową różnicą między sygnaturą wdrożenia a geode jest to, że geody nigdy nie istnieją w izolacji. Zawsze powinno istnieć więcej niż jeden geode na platformie produkcyjnej.

Geody mają następujące cechy:

• Składa się z kolekcji różnych typów zasobów, często zdefiniowanych w szablonie.
• Nie mają żadnych zależności poza obszarem geograficznym i są samodzielne. Żaden geode nie jest zależny od innego do działania, a jeśli jeden z nich umrze, pozostałe nadal działają.
• Są luźno powiązane za pośrednictwem sieci brzegowej i płaszczyzny wstecznej replikacji. Możesz na przykład użyć usługi Azure Traffic Manager lub usługi Azure Front Door do obsługi frontonów geograficznych, podczas gdy usługa Azure Cosmos DB może działać jako płaszczyzna wsteczna replikacji. Geody nie są takie same jak klastry, ponieważ współużytkują płaszczyznę wsteczną replikacji, więc platforma zajmuje się problemami z kworum.

Wzorzec geode występuje w architekturach danych big data, które używają sprzętu towarowego do przetwarzania danych kolokowanych na tej samej maszynie, i MapReduce w celu skonsolidowania wyników między maszynami. Innym użyciem jest niemal brzegowe obliczenia, które przybliża obliczenia do inteligentnej krawędzi sieci, aby skrócić czas odpowiedzi.

Usługi mogą używać tego wzorca w dziesiątkach lub setkach geod. Ponadto odporność całego rozwiązania zwiększa się wraz z każdym dodanym geode, ponieważ wszystkie geody mogą przejąć, jeśli regionalna awaria przejmie co najmniej jedną geodę w trybie offline.

Istnieje również możliwość rozszerzenia lokalnych technik dostępności, takich jak strefy dostępności lub sparowane regiony, ze wzorcem geode na potrzeby dostępności globalnej. Zwiększa to złożoność, ale jest przydatna, jeśli architektura jest podstawą aparatu magazynu, takiego jak magazyn obiektów blob, który może być replikowany tylko do sparowanego regionu. Geody można wdrażać w strefie wewnątrz strefy, strefy lub w regionie, z myślą o ograniczeniach regulacyjnych lub opóźnieniach w lokalizacji.

Problemy i kwestie do rozważenia

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

• Nowoczesne metodyki DevOps i narzędzia do tworzenia i szybkiego wdrażania identycznych geod w wielu regionach lub wystąpieniach.
• Skalowanie automatyczne w celu skalowania w poziomie wystąpień obliczeniowych i przepływności bazy danych w ramach geode. Każda geode indywidualnie skaluje się w poziomie w ramach typowych ograniczeń płaszczyzny wstecznej.
• Usługa frontonu, taka jak Azure Front Door, która wykonuje dynamiczne przyspieszanie zawartości, dzielenie protokołu TCP i routingu emisji dowolnej.
• Replikujący magazyn danych, taki jak Azure Cosmos DB, do kontrolowania spójności danych.
• Technologie bezserwerowe tam, gdzie to możliwe, aby zmniejszyć koszty wdrażania zawsze włączone, szczególnie w przypadku częstego ponownego równoważenia obciążenia na całym świecie. Ta strategia umożliwia wdrożenie wielu geod z minimalnymi dodatkowymi inwestycjami. Technologie rozliczeń bezserwerowe i oparte na użyciu zmniejszają straty i koszty zduplikowanych wdrożeń rozproszonych geograficznie.
• Usługa API Management nie jest wymagana do zaimplementowania wzorca projektu, ale można dodać do każdego geode, który jest frontonem aplikacji funkcji platformy Azure w regionie, aby zapewnić bardziej niezawodną warstwę interfejsu API, umożliwiając implementację dodatkowych funkcji, takich jak ograniczanie szybkości, na przykład.

Podczas podejmowania decyzji o sposobie wdrożenia tego wzorca należy rozważyć następujące punkty:

• Określ, czy dane mają być przetwarzane lokalnie w każdym regionie, czy też dystrybuować agregacje w jednym geode i replikować wynik na całym świecie. Procesor zestawienia zmian usługi Azure Cosmos DB oferuje tę szczegółową kontrolę przy użyciu koncepcji kontenera dzierżawy oraz prefiks dzierżawy w odpowiednim powiązaniu usługi Azure Functions. Każde podejście ma różne zalety i wady.
• Geody mogą działać razem przy użyciu zestawienia zmian usługi Azure Cosmos DB i platformy komunikacji w czasie rzeczywistym, takiej jak SignalR. Geody mogą komunikować się z użytkownikami zdalnymi za pośrednictwem innych geod we wzorcu siatki, nie wiedząc ani nie dbając o to, gdzie znajduje się użytkownik zdalny.
• Ten wzorzec projektowy niejawnie rozdziela wszystko, co powoduje bardzo wysoce rozproszoną i oddzieloną architekturę. Rozważ, jak śledzić różne składniki tego samego żądania, co mogą być wykonywane asynchronicznie na różnych wystąpieniach. Odpowiednia strategia monitorowania ma kluczowe znaczenie. Zarówno usługi Azure Front Door, jak i Azure Cosmos DB można łatwo zintegrować z usługą Log Analytics, a usługa Azure Functions powinna zostać wdrożona wraz z usługą Application Insights, aby zapewnić niezawodny system monitorowania w każdym składniku architektury.
• Wdrożenia rozproszone mają większą liczbę wpisów tajnych i punktów ruchu przychodzącego, które wymagają środków zabezpieczeń właściwości. Usługa Key Vault zapewnia bezpieczną warstwę do zarządzania wpisami tajnymi, a każda warstwa w ramach architektury interfejsu API powinna być prawidłowo zabezpieczona, tak aby jedynym punktem ruchu przychodzącego dla interfejsu API był usługa frontonu, taka jak Azure Front Door. Usługa Azure Cosmos DB powinna ograniczyć ruch do aplikacji funkcji platformy Azure, a aplikacje funkcji do usługi Azure Front Door przy użyciu identyfikatora Entra firmy Microsoft lub praktyk, takich jak ograniczenie adresu IP.
• Wydajność jest znacząco dotknięta liczbą wdrożonych geod i określonymi planami usługi App Service zastosowanymi do technologii interfejsu API w każdym geode. Wdrożenie dodatkowych geod lub przemieszczania się w warstwach Premium ma zwiększone koszty dodatkowej pamięci i mocy obliczeniowej, ale nie należy tego robić na podstawie transakcji. Rozważ przetestowanie obciążenia architektury interfejsu API po wdrożeniu i kontrastowanie z zwiększeniem liczby geod z zwiększeniem warstwy cenowej, tak aby najbardziej ekonomiczny model był używany do Twoich potrzeb.
• Określ wymagania dotyczące dostępności danych. Usługa Azure Cosmos DB ma opcjonalne flagi umożliwiające zapisywanie w wielu regionach, strefy dostępności i nie tylko. Zwiększają one dostępność wystąpienia usługi Azure Cosmos DB i tworzą bardziej odporną warstwę danych, ale wiążą się z dodatkowymi kosztami.
• Platforma Azure oferuje różne moduły równoważenia obciążenia, które zapewniają różne funkcje dystrybucji ruchu. Użyj drzewa decyzyjnego, aby wybrać odpowiednią opcję frontonu interfejsu API.

Kiedy używać tego wzorca

Użyj tego wzorca, aby:

• Aby zaimplementować platformę o dużej skali, która ma użytkowników rozproszonych w szerokim obszarze.
• W przypadku każdej usługi wymagającej charakterystyki skrajnej dostępności i odporności, ponieważ usługi oparte na wzorcu geode mogą przetrwać utratę wielu regionów usług jednocześnie.

Ten wzorzec może nie być odpowiedni dla

• Architektury, które mają ograniczenia, dzięki czemu wszystkie geody nie mogą być równe dla magazynu danych. Na przykład mogą istnieć wymagania dotyczące rezydencji danych, aplikacja, która musi utrzymywać stan tymczasowy dla określonej sesji lub duże obciążenie żądań w jednym regionie. W takim przypadku rozważ użycie sygnatur wdrożenia w połączeniu z globalną płaszczyzną routingu, która jest świadoma miejsca, w którym znajdują się dane użytkownika, na przykład składnika routingu ruchu opisanego we wzorcu sygnatur wdrożenia.
• Sytuacje, w których nie jest wymagany rozkład geograficzny. Zamiast tego rozważ strefy dostępności i sparowane regiony na potrzeby klastrowania.
• Sytuacje, w których starsza platforma musi zostać zmodernizowana. Ten wzorzec działa tylko w przypadku tworzenia aplikacji natywnych dla chmury i może być trudny do modernizacji.
• Proste architektury i wymagania, w których nadmiarowość geograficzna i dystrybucja geograficzna nie są wymagane ani korzystne.

Projekt obciążenia

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

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.

Przykłady

• Usługa Windows Active Directory implementuje wczesny wariant tego wzorca. Replikacja wielodostępna oznacza, że wszystkie aktualizacje i żądania mogą być obsługiwane z wszystkich węzłów z możliwością obsługi, ale role elastycznej pojedynczej operacji master (FSMO) oznaczają, że wszystkie geody nie są równe.
• Akcelerator wzorca geode w usłudze GitHub prezentuje ten wzorzec projektowania w praktyce i jest przeznaczony do ułatwiania deweloperom implementowania go za pomocą rzeczywistych interfejsów API.