Wzorzec sygnatur wdrażania

Wzorzec sygnatury wdrożenia obejmuje aprowizowanie, zarządzanie i monitorowanie heterogenicznej grupy zasobów do hostowania i obsługi wielu obciążeń lub dzierżaw. Każda pojedyncza kopia jest nazywana sygnaturą, a czasami jednostką usługi, jednostką skalowania lub komórką. W środowisku wielodostępnym każda sygnatura lub jednostka skalowania może obsługiwać wstępnie zdefiniowaną liczbę dzierżaw. W celu niemal liniowego skalowania rozwiązania można wdrożyć wiele sygnatur i obsługiwać coraz większą liczbę dzierżaw. Takie podejście może poprawić skalowalność rozwiązania, umożliwić wdrażanie wystąpień w wielu regionach i oddzielenie danych klientów.

Kontekst i problem

Podczas hostowania aplikacji w chmurze należy wziąć pod uwagę wydajność i niezawodność aplikacji. W przypadku hostowania pojedynczego wystąpienia rozwiązania mogą być objęte następującymi ograniczeniami:

• Limity skalowania. Wdrożenie pojedynczego wystąpienia aplikacji może spowodować naturalne limity skalowania. Na przykład można użyć usług, które mają limity liczby połączeń przychodzących, nazw hostów, gniazd TCP lub innych zasobów.
• Nieliniowe skalowanie lub koszty. Niektóre składniki rozwiązania mogą nie być skalowane liniowo z liczbą żądań lub ilością danych. Zamiast tego może wystąpić nagły spadek wydajności lub wzrost kosztów po osiągnięciu progu. Na przykład możesz użyć bazy danych i odkryć, że marginalny koszt dodawania większej pojemności (skalowanie w górę) staje się zbyt uciążliwy, a skalowanie w górę jest bardziej opłacalną strategią.
• Separacja klientów. Może być konieczne pozostawienie danych niektórych klientów odizolowanych od danych innych klientów. Podobnie niektórzy klienci mogą wymagać większej ilości zasobów systemowych do obsługi niż inne i rozważyć grupowanie ich w różnych zestawach infrastruktury.
• Obsługa wystąpień jednodostępnych i wielodostępnych. Być może masz wielu klientów, którzy potrzebują własnych niezależnych wystąpień rozwiązania. Możesz również mieć pulę mniejszych klientów, którzy mogą współużytkować wdrożenie wielodostępne.
• Złożone wymagania dotyczące wdrażania. Może być konieczne wdrożenie aktualizacji w usłudze w kontrolowany sposób i wdrożenie ich w różnych podzestawach bazy klientów w różnym czasie.
• Częstotliwość aktualizacji. Niektórzy klienci mogą być odporni na częste aktualizacje systemu, podczas gdy inni mogą być niechętni i chcą rzadko aktualizować system, który obsługuje ich żądania. Może to mieć sens, aby ci klienci zostali wdrożeni w izolowanych środowiskach.
• Ograniczenia geograficzne lub geopolityczne. Aby utworzyć architekturę pod kątem małych opóźnień lub spełnić wymagania dotyczące niezależności danych, możesz wdrożyć niektórych klientów w określonych regionach.

Te ograniczenia są często stosowane do niezależnych dostawców oprogramowania (ISV), którzy tworzą oprogramowanie jako usługa (SaaS), które są często projektowane jako wielodostępne. Jednak te same ograniczenia mogą również dotyczyć innych scenariuszy.

Rozwiązanie

Aby uniknąć tych problemów, rozważ grupowanie zasobów w jednostkach skalowania i aprowizowanie wielu kopii sygnatur. Każda jednostka skalowania będzie hostować i obsługiwać podzbiór dzierżaw. Sygnatury działają niezależnie od siebie i można je wdrażać i aktualizować niezależnie. Pojedynczy region geograficzny może zawierać pojedynczą sygnaturę lub może zawierać wiele sygnatur, aby umożliwić skalowanie w poziomie w poziomie w obrębie regionu. Sygnatury zawierają podzbiór klientów.

Sygnatury wdrażania mogą mieć zastosowanie, czy rozwiązanie korzysta z składników infrastruktury jako usługi (IaaS), czy platformy jako usługi (PaaS), czy też obu tych składników. Zazwyczaj obciążenia IaaS wymagają większej interwencji w celu skalowania, więc wzorzec może być przydatny w przypadku obciążeń IaaS, aby umożliwić skalowanie w poziomie.

Sygnatury mogą służyć do implementowania pierścieni wdrażania. Jeśli różni klienci chcą otrzymywać aktualizacje usług o różnych częstotliwościach, mogą być grupowani na różne sygnatury, a każda sygnatura może mieć wdrożone aktualizacje w różnych okresach.

Ponieważ sygnatury działają niezależnie od siebie, dane są niejawnie podzielone na fragmenty. Ponadto pojedyncza sygnatura może wykorzystać dalsze fragmentowanie, aby umożliwić wewnętrzną skalowalność i elastyczność w sygnaturze.

Wzorzec sygnatury wdrożenia jest używany wewnętrznie przez wiele usług platformy Azure, w tym usług App Service, Azure Stack i Azure Storage.

Sygnatury wdrożenia są powiązane z geodami, ale różnią się od tych. W architekturze sygnatury wdrożenia wdraża się wiele niezależnych wystąpień systemu i zawiera podzbiór klientów i użytkowników. W geodach wszystkie wystąpienia mogą obsługiwać żądania od dowolnego użytkownika, ale ta architektura jest często bardziej skomplikowana do projektowania i kompilowania. Można również rozważyć mieszanie dwóch wzorców w jednym rozwiązaniu; podejście do routingu ruchu opisane w dalszej części tego artykułu jest przykładem takiego scenariusza hybrydowego.

Wdrożenie

Ze względu na złożoność związaną z wdrażaniem identycznych kopii tych samych składników dobre rozwiązania DevOps mają kluczowe znaczenie dla zapewnienia sukcesu podczas implementowania tego wzorca. Rozważ opisanie infrastruktury jako kodu, na przykład przy użyciu szablonów Bicep, JSON usługi Azure Resource Manager (szablonów usługi ARM), narzędzia Terraform i skryptów. Dzięki temu podejściu można upewnić się, że wdrożenie każdej sygnatury jest przewidywalne i powtarzalne. Zmniejsza również prawdopodobieństwo błędów ludzkich, takich jak przypadkowe niezgodności w konfiguracji między sygnaturami.

Aktualizacje można wdrażać automatycznie we wszystkich sygnaturach równolegle. W tym przypadku możesz rozważyć technologie takie jak szablony Bicep lub Resource Manager, aby koordynować wdrażanie infrastruktury i aplikacji. Alternatywnie możesz zdecydować się na stopniowe wprowadzanie aktualizacji do niektórych sygnatur, a następnie stopniowo do innych. Rozważ użycie narzędzia do zarządzania wydaniami, takiego jak usługa Azure Pipelines lub GitHub Actions , aby zorganizować wdrożenia do każdej sygnatury. Aby uzyskać więcej informacji, zobacz:

• Integrowanie rozwiązania Bicep z usługą Azure Pipelines
• Integrowanie szablonów usługi ARM JSON z usługą Azure Pipelines

Starannie rozważ topologię subskrypcji i grup zasobów platformy Azure dla wdrożeń:

• Zazwyczaj subskrypcja zawiera wszystkie zasoby dla jednego rozwiązania, więc ogólnie należy rozważyć użycie jednej subskrypcji dla wszystkich sygnatur. Jednak niektóre usługi platformy Azure nakładają limity przydziału dla całej subskrypcji, więc jeśli używasz tego wzorca, aby umożliwić wysoki stopień skalowania w poziomie, może być konieczne rozważenie wdrożenia sygnatur w różnych subskrypcjach.
• Grupy zasobów są zwykle używane do wdrażania składników z tym samym cyklem życia. Jeśli planujesz wdrożyć aktualizacje wszystkich sygnatur jednocześnie, rozważ użycie pojedynczej grupy zasobów, aby zawierać wszystkie składniki dla wszystkich sygnatur, oraz użyć konwencji nazewnictwa zasobów i tagów, aby zidentyfikować składniki, które należą do każdej sygnatury. Alternatywnie, jeśli planujesz niezależne wdrażanie aktualizacji dla każdej sygnatury, rozważ wdrożenie każdej sygnatury we własnej grupie zasobów.

Planowanie zdolności produkcyjnych

Użyj testów obciążeniowych i wydajnościowych, aby określić przybliżone obciążenie, które może pomieścić dana sygnatura. Metryki obciążenia mogą być oparte na liczbie klientów/dzierżaw, które mogą pomieścić pojedyncza sygnatura, lub metryki z usług emitujących przez składniki w ramach sygnatury. Upewnij się, że masz wystarczającą instrumentację do mierzenia, gdy dana sygnatura zbliża się do jego pojemności, oraz możliwość szybkiego wdrażania nowych sygnatur w celu reagowania na zapotrzebowanie.

Routing ruchu

Wzorzec sygnatury wdrożenia działa prawidłowo, jeśli każda sygnatura jest niezależnie skierowana. Jeśli na przykład firma Contoso wdraża tę samą aplikację interfejsu API na wielu sygnaturach, może rozważyć użycie systemu DNS do kierowania ruchu do odpowiedniej sygnatury:

• unit1.aus.myapi.contoso.com kieruje ruch do sygnatury unit1 w regionie Australii.
• unit2.aus.myapi.contoso.com kieruje ruch do sygnatury unit2 w regionie Australii.
• unit1.eu.myapi.contoso.com kieruje ruch do sygnatury unit1 w regionie europejskim.

Klienci są wówczas odpowiedzialni za nawiązywanie połączenia z poprawną sygnaturą.

Jeśli wymagany jest pojedynczy punkt wejścia dla całego ruchu, usługa routingu ruchu może służyć do rozpoznawania sygnatury dla danego żądania, klienta lub dzierżawy. Usługa routingu ruchu kieruje klienta do odpowiedniego adresu URL sygnatury (na przykład przy użyciu kodu stanu odpowiedzi HTTP 302) lub może działać jako zwrotny serwer proxy i przekazywać ruch do odpowiedniej sygnatury, bez świadomości klienta.

Scentralizowana usługa routingu ruchu może być złożonym składnikiem do projektowania, zwłaszcza gdy rozwiązanie działa w wielu regionach. Rozważ wdrożenie usługi routingu ruchu w wielu regionach (potencjalnie w tym każdego regionu, w którym są wdrażane sygnatury), a następnie upewnienie się, że magazyn danych (mapowanie dzierżaw na sygnatury) jest zsynchronizowany. Składnik routingu ruchu może być wystąpieniem wzorca geode.

Na przykład usługę Azure API Management można wdrożyć w celu działania w roli usługi routingu ruchu. Może określić odpowiednią sygnaturę dla żądania, wyszukując dane w kolekcji usługi Azure Cosmos DB przechowując mapowanie między dzierżawami i sygnaturami. Usługa API Management może następnie dynamicznie ustawiać adres URL zaplecza na usługę interfejsu API odpowiedniej sygnatury.

Aby umożliwić geograficzną dystrybucję żądań i nadmiarowość geograficzną usługi routingu ruchu, usługę API Management można wdrożyć w wielu regionach lub za pomocą usługi Azure Front Door można kierować ruch do najbliższego wystąpienia. Usługę Front Door można skonfigurować przy użyciu puli zaplecza, umożliwiając kierowanie żądań do najbliższego dostępnego wystąpienia usługi API Management. Jeśli aplikacja nie jest uwidoczniona za pośrednictwem protokołu HTTP/S, możesz użyć usługi Azure Load Balancer w wielu regionach do dystrybuowania wywołań przychodzących do regionalnych usług Azure Load Balancers. Funkcja globalnej dystrybucji usługi Azure Cosmos DB może służyć do aktualizowania informacji o mapowaniu w każdym regionie.

Jeśli usługa routingu ruchu jest uwzględniona w rozwiązaniu, rozważ, czy działa jako brama i w związku z tym może wykonywać odciążanie bramy dla innych usług, takich jak walidacja tokenu, ograniczanie przepustowości i autoryzacja.

Przykładowa architektura routingu ruchu

Rozważmy następującą przykładową architekturę routingu ruchu, która korzysta z usług Azure Front Door, Azure API Management i Azure Cosmos DB na potrzeby routingu ruchu globalnego, a następnie serii sygnatur specyficznych dla regionu:

Załóżmy, że użytkownik zwykle mieszka w Nowym Jorku. Ich dane są przechowywane w sygnaturze 3 w regionie Wschodnie stany USA.

Jeśli użytkownik podróżuje do Kalifornii, a następnie uzyskuje dostęp do systemu, połączenie będzie prawdopodobnie kierowane przez region Zachodnie stany USA 2, ponieważ jest to najbliżej lokalizacji geograficznej, gdy wysyła żądanie. Jednak żądanie musi zostać ostatecznie obsłużone przez sygnaturę 3, ponieważ w tym miejscu są przechowywane ich dane. System routingu ruchu gwarantuje, że żądanie jest kierowane do poprawnej sygnatury.

Problemy i kwestie do rozważenia

Podczas podejmowania decyzji o sposobie wdrażania tego wzorca należy rozważyć następujące kwestie:

• Proces wdrażania. Podczas wdrażania wielu sygnatur zdecydowanie zaleca się posiadanie zautomatyzowanych i w pełni powtarzalnych procesów wdrażania. Rozważ użycie szablonów Bicep, JSON ARM lub modułów terraform w celu deklaratywnego zdefiniowania sygnatur i zachowania spójności definicji.
• Operacje krzyżowe. Jeśli rozwiązanie jest wdrażane niezależnie na wielu sygnaturach, pytania takie jak "ilu klientów mamy we wszystkich naszych sygnaturach?", mogą stać się bardziej złożone, aby odpowiedzieć. Zapytania mogą być wykonywane względem każdej sygnatury i zagregowanych wyników. Alternatywnie rozważ opublikowanie danych przez wszystkie sygnatury w scentralizowanym magazynie danych na potrzeby skonsolidowanego raportowania.
• Określanie zasad skalowania w poziomie. Sygnatury mają ograniczoną pojemność, którą można zdefiniować przy użyciu metryki serwera proxy, takiej jak liczba dzierżaw, które można wdrożyć w sygnaturze. Ważne jest, aby monitorować dostępną pojemność i używać pojemności dla każdej sygnatury oraz proaktywnie wdrażać dodatkowe sygnatury, aby umożliwić kierowanie do nich nowych dzierżaw.
• Minimalna liczba sygnatur. W przypadku korzystania ze wzorca sygnatury wdrożenia zaleca się wdrożenie co najmniej dwóch sygnatur rozwiązania. W przypadku wdrażania tylko pojedynczej sygnatury można łatwo przypadkowo zastosować założenia dotyczące kodu w kodzie lub konfiguracji, które nie będą stosowane podczas skalowania w poziomie.
• Koszt Wzorzec sygnatury wdrożenia obejmuje wdrożenie wielu kopii składnika infrastruktury, co prawdopodobnie będzie wiązać się ze znacznym wzrostem kosztów obsługi rozwiązania.
• Przenoszenie między sygnaturami. Każda sygnatura jest wdrażana i obsługiwana niezależnie, więc przenoszenie dzierżaw między sygnaturami może być trudne. Aplikacja wymagałaby logiki niestandardowej, aby przekazać informacje o danym kliencie do innej sygnatury, a następnie usunąć informacje dzierżawy z oryginalnej sygnatury. Ten proces może wymagać płaszczyzny wstecznej komunikacji między sygnaturami, co jeszcze bardziej zwiększa złożoność ogólnego rozwiązania.
• Routing ruchu. Zgodnie z opisem we wcześniejszej części tego artykułu kierowanie ruchu do poprawnej sygnatury dla danego żądania może wymagać dodatkowego składnika w celu rozpoznawania dzierżaw do sygnatur. Z kolei ten składnik może wymagać udostępnienia wysokiej dostępności.
• Składniki udostępnione. Może istnieć kilka składników, które mogą być współużytkowane przez sygnatury. Jeśli na przykład masz udostępnioną jednostronicową aplikację dla wszystkich dzierżaw, rozważ wdrożenie tej aplikacji w jednym regionie i użycie usługi Azure CDN do replikacji globalnej.

Kiedy używać tego wzorca

Ten wzorzec jest przydatny w następujących przypadkach:

• Naturalne limity skalowalności. Jeśli na przykład niektóre składniki nie mogą lub nie powinny być skalowane poza określoną liczbę klientów lub żądań, rozważ skalowanie w poziomie przy użyciu sygnatur.
• Wymóg oddzielenia niektórych dzierżaw od innych. Jeśli masz klientów, których nie można wdrożyć w wielodostępnej sygnaturze z innymi klientami ze względu na obawy dotyczące zabezpieczeń, można je wdrożyć na własnej izolowanej sygnaturze.
• Musisz mieć kilka dzierżaw w różnych wersjach rozwiązania w tym samym czasie.
• Aplikacje z wieloma regionami, w których dane i ruch poszczególnych dzierżawców powinny być kierowane do określonego regionu.
• Chęć osiągnięcia odporności podczas przestojów. Ponieważ sygnatury są niezależne od siebie, jeśli awaria wpłynie na pojedynczą sygnaturę, dzierżawy wdrożone w innych sygnaturach nie powinny mieć wpływu. Ta izolacja pomaga zawierać "promień wybuchu" zdarzenia lub awarii.

Ten wzorzec nie jest odpowiedni dla:

• Proste rozwiązania, które nie muszą być skalowane do wysokiego stopnia.
• Systemy, które można łatwo skalować w poziomie lub w górę w jednym wystąpieniu, takie jak zwiększenie rozmiaru warstwy aplikacji lub zwiększenie pojemności zarezerwowanej baz danych i warstwy magazynowania.
• Rozwiązania, w których dane powinny być replikowane we wszystkich wdrożonych wystąpieniach. Rozważ wzorzec geode w tym scenariuszu.
• Rozwiązania, w których należy skalować tylko niektóre składniki, ale nie inne. Rozważmy na przykład, czy rozwiązanie można skalować, fragmentując magazyn danych zamiast wdrażać nową kopię wszystkich składników rozwiązania.
• Rozwiązania składające się wyłącznie z zawartości statycznej, takiej jak aplikacja JavaScript frontonu. Rozważ przechowywanie takiej zawartości na koncie magazynu i korzystanie z usługi Azure CDN.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec sygnatur wdrożenia może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym 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.

Technologie pomocnicze

• Infrastruktura jako kod. Na przykład Bicep, szablony usługi Resource Manager, interfejs wiersza polecenia platformy Azure, terraform, program PowerShell, powłoka Bash.
• Usługa Azure Front Door, która może kierować ruch do określonej sygnatury lub do usługi routingu ruchu.

Przykład

W poniższym przykładzie wdrożono wiele sygnatur prostego rozwiązania PaaS z usługą app Service i bazą danych SQL Database w każdej sygnaturze. Mimo że sygnatury można skonfigurować w dowolnym regionie obsługującym usługi wdrożone w szablonie, na potrzeby ilustracji ten szablon wdraża dwa sygnatury w regionie Zachodnie stany USA 2 i dalszą sygnaturę w regionie Europa Zachodnia. W ramach sygnatury usługa app service otrzymuje własną publiczną nazwę hosta DNS i może odbierać połączenia niezależnie od wszystkich innych sygnatur.

Kliknij poniższy link, aby wdrożyć rozwiązanie.

Przykładowe podejście do routingu ruchu

Poniższy przykład wdraża implementację rozwiązania do routingu ruchu, które może być używane z zestawem sygnatur wdrożenia dla hipotetycznej aplikacji interfejsu API. Aby umożliwić geograficzną dystrybucję żądań przychodzących, usługa Front Door jest wdrażana wraz z wieloma wystąpieniami usługi API Management w warstwie zużycia. Każde wystąpienie usługi API Management odczytuje identyfikator dzierżawy z adresu URL żądania, a następnie wyszukuje odpowiedni sygnaturę dla żądania z rozproszonego geograficznie magazynu danych usługi Azure Cosmos DB. Żądanie jest następnie przekazywane do odpowiedniej sygnatury zaplecza.

Kliknij poniższy link, aby wdrożyć rozwiązanie.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• John Downs | Główny menedżer programu

Inni współautorzy:

• Daniel Larsen | Główny inżynier klienta, fasttrack dla platformy Azure
• Angel Lopez | Starszy inżynier oprogramowania, wzorce i praktyki platformy Azure
• Paolo Salvatori | Główny inżynier klienta, fasttrack dla platformy Azure
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure

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

Powiązane zasoby

• Fragmentowanie może służyć jako inne, prostsze podejście do skalowania w poziomie warstwy danych. Sygnatury niejawnie fragmentują swoje dane, ale fragmentowanie nie wymaga sygnatury wdrożenia. Aby uzyskać więcej informacji, zobacz Sharding pattern (Wzorzec fragmentowania).
• Jeśli usługa routingu ruchu jest wdrożona, wzorce routingu bramy i odciążania bramy mogą być używane razem, aby jak najlepiej wykorzystać ten składnik.