Vzor geody

Azure Cosmos DB

Nasaďte kolekci back-endových služeb do sady geografickýchnodes, z nichž každá může obsluhovat jakoukoli žádost od libovolného klienta v libovolné oblasti. Tento přístup active-active rozkládá zpracování požadavků po celém světě, aby snížil latenci a zvýšil dostupnost.

Kontext a problém

Řada rozsáhlých služeb má specifické problémy související s geografickou dostupností a škálováním. Klasické návrhy často přenesou data do výpočetních prostředků uložením dat na vzdáleném SQL serveru, který slouží jako výpočetní úroveň pro tato data, a spoléhá na vertikální navýšení kapacity pro růst.

Klasický přístup může způsobit následující problémy:

• Problémy s latencí sítě pro uživatele přicházející z druhé strany světa pro připojení ke koncovému bodu hostování
• Správa provozu pro nárůsty poptávky, které můžou zahltit služby v jedné oblasti
• Nákladně prohibitivní složitost nasazení kopií infrastruktury aplikací do několika regionů pro službu 24x7

Moderní cloudová infrastruktura se vyvinula tak, aby umožňovala geografické vyrovnávání zatížení front-endových služeb a zároveň umožňovala geografickou replikaci back-endových služeb. Pro zvýšení dostupnosti a výkonu je dobré přiblížit data k uživateli. Pokud jsou data geograficky distribuovaná napříč dalekosáhlou uživatelskou základnou, měly by být úložiště geograficky distribuovaných dat také společné s výpočetními prostředky, které zpracovávají data. Mustr geode přináší výpočty k datům.

Řešení

Nasaďte službu do několika satelitních nasazení rozložených po celém světě, z nichž každá se nazývá geode. Geodový vzor využívá klíčové funkce Azure ke směrování provozu přes nejkratší cestu k blízkému uzlu geode, což zlepšuje latenci a výkonnost. Každá geode je za globálním vyrovnávačem zatížení a používá geograficky replikovanou službu pro čtení i zápis, jako je Azure Cosmos DB, k hostování datové vrstvy a zajištění konzistence dat napříč geodami. Služby replikace dat zajišťují, aby úložiště dat byla v různých geografických oblastech stejná, takže všechny požadavky je možné obsluhovat ze všech geografických des.

Klíčový rozdíl mezi nasazovacím razítkem a geodou je, že geody nikdy neexistují samostatně. V produkční platformě by vždy měly existovat více než jedna geoda.

Geody mají následující charakteristiky:

• Skládá se z kolekce různorodých typů prostředků, často definovaných v šabloně.
• Nemají žádné závislosti mimo rozsah systému Geode a jsou soběstačné. Žádná geode není závislá na jiné, aby fungovala, a pokud jedna zemře, ostatní budou dál fungovat.
• Jsou volně propojené přes hraniční síť a replikační backplane. Můžete například použít Azure Traffic Manager nebo Azure Front Door ke frontingu geod, zatímco Azure Cosmos DB může fungovat jako replikační základna. Geody nejsou stejné jako clustery, protože sdílejí replikaci na základním rámci, takže platforma se stará o problémy s kvorum.

Vzor geode se vyskytuje v architekturách big data, které ke zpracování dat společně umístěných na stejném počítači používají komoditní hardware a MapReduce ke konsolidaci výsledků mezi počítači. Další využití je výpočet u hrany sítě, který přibližuje výpočetní kapacity k inteligentnímu okraji sítě, aby se zkrátila doba odezvy.

Služby mohou tento vzor používat na desítkách nebo stovkách geod. Kromě toho se zvyšuje odolnost celého řešení s každou přidanou geodou, protože kteroukoliv z geod může převzít funkci, pokud regionální výpadek způsobí, že jedna nebo více geod může být offline.

Je také možné pomocí vzoru geode pro globální dostupnost rozšířit místní techniky dostupnosti, jako jsou zóny dostupnosti nebo párové oblasti. To zvyšuje složitost, ale je užitečné, pokud je vaše architektura založená na úložném enginu, jako je úložiště objektů blob, které lze replikovat pouze do párované oblasti. Geody můžete nasadit v rámci jedné zóny, do více zón nebo do regionálního nasazení s ohledem na regulační požadavky nebo omezení latence daná umístěním.

Problémy a důležité informace

K implementaci tohoto modelu použijte následující techniky a technologie:

• Moderní DevOps postupy a nástroje pro vytváření a rychlé nasazování identických geod napříč mnoha regiony nebo instancemi.
• Automatické škálování pro rozšíření výpočetních instancí a instancí propustnosti databáze v rámci geode. Každý geode se individuálně škáluje, s ohledem na společná omezení backplane.
• Front-endová služba, jako je Azure Front Door, která dělá dynamickou akceleraci obsahu, směrování přes optimální bod přítomnosti a rozdělení TCP.
• Replikace úložiště dat, jako je Azure Cosmos DB, za účelem řízení konzistence dat.
• Bezserverové technologie, pokud je to možné, aby se snížily náklady na stálé nasazení, zejména když se zatížení často přerozděluje po celém světě. Tato strategie umožňuje nasazení mnoha geodů při minimálním dalším investování. Bezserverové technologie a fakturace na základě spotřeby snižují plýtvání a náklady z nadbytečných geograficky distribuovaných nasazení.
• Služba API Management není nutná k implementaci vzoru návrhu, ale může být přidána ke každému geode, který předchází Azure Function aplikaci dané oblasti, aby poskytovala robustnější vrstvu API, což umožňuje například implementaci dalších funkcionalit, jako je omezení rychlosti.

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Zvolte, jestli chcete zpracovávat data místně v jednotlivých oblastech, nebo distribuovat agregace v jedné geografické oblasti a replikovat výsledek po celém světě. Procesor kanálu změn Azure Cosmos DB nabízí tento podrobný ovládací prvek pomocí konceptu lease kontejneru a leasecollectionprefix v odpovídající vazbě Azure Functions. Každý přístup má odlišné výhody a nevýhody.
• Geodes může pracovat společně s využitím kanálu změn služby Azure Cosmos DB a komunikační platformy v reálném čase, jako je SignalR. Geody můžou komunikovat se vzdálenými uživateli prostřednictvím jiných geod ve vzoru mesh sítě, aniž by věděly nebo záleželo, kde se vzdálený uživatel nachází.
• Tento vzor návrhu implicitně odděluje všechno, což vede k vysoce distribuované a oddělené architektuře. Zvažte, jak sledovat různé komponenty stejného požadavku, které se můžou spouštět asynchronně v různých instancích. Důležitá je správná strategie monitorování. Služba Azure Front Door i Azure Cosmos DB je možné snadno integrovat se službou Log Analytics a Služba Azure Functions by měly být nasazeny společně s Application Insights, aby poskytovaly robustní monitorovací systém v každé komponentě architektury.
• Distribuovaná nasazení mají větší počet tajemství a vstupních bodů, které vyžadují odpovídající bezpečnostní opatření. Key Vault poskytuje zabezpečenou vrstvu pro správu tajných kódů a každá vrstva v architektuře rozhraní API by měla být správně zabezpečená, takže jediným bodem příchozího přenosu dat pro rozhraní API je front-endová služba, jako je Azure Front Door. Azure Cosmos DB by měla omezit provoz mezi Azure Function Apps a Azure Front Door pomocí Microsoft Entra ID nebo postupů, jako je omezení IP adres.
• Výkon je výrazně ovlivněn počtem nasazených geod a konkrétními App Service Plans aplikovanými na API technologii v každé geodě. Nasazení dalších uzlů nebo přechod na úrovně Premium přináší zvýšené náklady na další paměť a výpočetní prostředky, avšak tyto náklady nejsou účtovány na základě jednotlivých transakcí. Zvažte zátěžové testování architektury API po nasazení a porovnání zvýšení počtu uzlů se zvýšením cenové úrovně, aby byl použit nejefektivnější model pro vaše potřeby.
• Určete požadavky na dostupnost vašich dat. Azure Cosmos DB má volitelné příznaky pro povolení zápisu do více oblastí, zón dostupnosti a dalších. Tím se zvýší dostupnost instance Služby Azure Cosmos DB a vytvoří odolnější datovou vrstvu, ale s dalšími náklady.
• Azure nabízí různé nástroje pro vyrovnávání zatížení, které poskytují různé funkce pro distribuci provozu. Rozhodovací strom vám pomůže vybrat správnou možnost pro front-end vašeho rozhraní API.

Kdy se má tento model použít

Použijte tento model:

• Pokud chcete implementovat vysoce škálovanou platformu, která má uživatele distribuované v široké oblasti.
• Pro všechny služby, které vyžadují extrémní charakteristiky dostupnosti a odolnosti, protože služby založené na vzoru geode mohou přežít ztrátu více oblastí služeb najednou.

Tento vzor nemusí být vhodný pro

• Architektury, které mají omezení, takže všechny geody nemohou být stejné pro ukládání dat. Mohou existovat například požadavky na rezidenci dat, aplikace, která musí udržovat dočasný stav pro určitou relaci, nebo výrazný nápor požadavků na jediný region. V takovém případě zvažte použití kolků nasazení v kombinaci s globální rovinou směrování, která zná umístění dat uživatele, například komponenta směrování provozu popsaná ve vzoru kolků nasazení.
• Situace, kdy není potřeba žádné geografické rozdělení. Místo toho zvažte zóny dostupnosti a spárované oblasti pro clustering.
• Situace, kdy je potřeba zpětně namontovat starší platformu. Tento model funguje jenom pro vývoj nativní pro cloud a může být obtížné ho zpětně přizpůsobit.
• Jednoduché architektury a požadavky, kdy geografická redundance a geografická distribuce nejsou povinné ani výhodné.

Návrh úloh

Architekt by měl vyhodnotit způsob použití vzoru Geode v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Tento model využívá replikaci dat k podpoře ideálu, že libovolný klient se může připojit k libovolné geografické instanci, a tím může vaše zatížení odolat jednomu nebo několika oblastním výpadkům. - RE:05 Návrh s vysokou dostupností ve více oblastech - RE:05 Oblasti a zóny dostupnosti
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento model můžete použít k poskytování aplikace z oblasti, která je nejblíže vaší distribuované uživatelské bázi. Tím se snižuje latence tím, že eliminujete vzdálený provoz a protože sdílíte infrastrukturu pouze mezi uživateli, kteří aktuálně používají stejnou geode. - PE:03 Výběr služeb

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklady

• Windows služba Active Directory implementuje ranou variantu tohoto modelu. Replikace s více primárními rolemi znamená, že všechny aktualizace a požadavky mohou být v teorii obslouženy ze všech obsluhovatelných uzlů, ale role FSMO (Flexible Single Master Operation) znamenají, že všechny uzly nejsou stejné.

Nasaďte kolekci back-endových služeb do sady geografickýchnodes, z nichž každá může obsluhovat jakoukoli žádost od libovolného klienta v libovolné oblasti. Tento přístup active-active rozkládá zpracování požadavků po celém světě, aby snížil latenci a zvýšil dostupnost.

Kontext a problém

Řada rozsáhlých služeb má specifické problémy související s geografickou dostupností a škálováním. Klasické návrhy často přenesou data do výpočetních prostředků uložením dat na vzdáleném SQL serveru, který slouží jako výpočetní úroveň pro tato data, a spoléhá na vertikální navýšení kapacity pro růst.

Klasický přístup může způsobit následující problémy:

• Problémy s latencí sítě pro uživatele přicházející z druhé strany světa pro připojení ke koncovému bodu hostování
• Správa provozu pro nárůsty poptávky, které můžou zahltit služby v jedné oblasti
• Nákladně prohibitivní složitost nasazení kopií infrastruktury aplikací do několika regionů pro službu 24x7

Moderní cloudová infrastruktura se vyvinula tak, aby umožňovala geografické vyrovnávání zatížení front-endových služeb a zároveň umožňovala geografickou replikaci back-endových služeb. Pro zvýšení dostupnosti a výkonu je dobré přiblížit data k uživateli. Pokud jsou data geograficky distribuovaná napříč dalekosáhlou uživatelskou základnou, měly by být úložiště geograficky distribuovaných dat také společné s výpočetními prostředky, které zpracovávají data. Mustr geode přináší výpočty k datům.

Řešení

Nasaďte službu do několika satelitních nasazení rozložených po celém světě, z nichž každá se nazývá geode. Geodový vzor využívá klíčové funkce Azure ke směrování provozu přes nejkratší cestu k blízkému uzlu geode, což zlepšuje latenci a výkonnost. Každá geode je za globálním vyrovnávačem zatížení a používá geograficky replikovanou službu pro čtení i zápis, jako je Azure Cosmos DB, k hostování datové vrstvy a zajištění konzistence dat napříč geodami. Služby replikace dat zajišťují, aby úložiště dat byla v různých geografických oblastech stejná, takže všechny požadavky je možné obsluhovat ze všech geografických des.

Klíčový rozdíl mezi nasazovacím razítkem a geodou je, že geody nikdy neexistují samostatně. V produkční platformě by vždy měly existovat více než jedna geoda.

Geody mají následující charakteristiky:

• Skládá se z kolekce různorodých typů prostředků, často definovaných v šabloně.
• Nemají žádné závislosti mimo rozsah systému Geode a jsou soběstačné. Žádná geode není závislá na jiné, aby fungovala, a pokud jedna zemře, ostatní budou dál fungovat.
• Jsou volně propojené přes hraniční síť a replikační backplane. Můžete například použít Azure Traffic Manager nebo Azure Front Door ke frontingu geod, zatímco Azure Cosmos DB může fungovat jako replikační základna. Geody nejsou stejné jako clustery, protože sdílejí replikaci na základním rámci, takže platforma se stará o problémy s kvorum.

Vzor geode se vyskytuje v architekturách big data, které ke zpracování dat společně umístěných na stejném počítači používají komoditní hardware a MapReduce ke konsolidaci výsledků mezi počítači. Další využití je výpočet u hrany sítě, který přibližuje výpočetní kapacity k inteligentnímu okraji sítě, aby se zkrátila doba odezvy.

Služby mohou tento vzor používat na desítkách nebo stovkách geod. Kromě toho se zvyšuje odolnost celého řešení s každou přidanou geodou, protože kteroukoliv z geod může převzít funkci, pokud regionální výpadek způsobí, že jedna nebo více geod může být offline.

Je také možné pomocí vzoru geode pro globální dostupnost rozšířit místní techniky dostupnosti, jako jsou zóny dostupnosti nebo párové oblasti. To zvyšuje složitost, ale je užitečné, pokud je vaše architektura založená na úložném enginu, jako je úložiště objektů blob, které lze replikovat pouze do párované oblasti. Geody můžete nasadit v rámci jedné zóny, do více zón nebo do regionálního nasazení s ohledem na regulační požadavky nebo omezení latence daná umístěním.

Problémy a důležité informace

K implementaci tohoto modelu použijte následující techniky a technologie:

• Moderní DevOps postupy a nástroje pro vytváření a rychlé nasazování identických geod napříč mnoha regiony nebo instancemi.
• Automatické škálování pro rozšíření výpočetních instancí a instancí propustnosti databáze v rámci geode. Každý geode se individuálně škáluje, s ohledem na společná omezení backplane.
• Front-endová služba, jako je Azure Front Door, která dělá dynamickou akceleraci obsahu, směrování přes optimální bod přítomnosti a rozdělení TCP.
• Replikace úložiště dat, jako je Azure Cosmos DB, za účelem řízení konzistence dat.
• Bezserverové technologie, pokud je to možné, aby se snížily náklady na stálé nasazení, zejména když se zatížení často přerozděluje po celém světě. Tato strategie umožňuje nasazení mnoha geodů při minimálním dalším investování. Bezserverové technologie a fakturace na základě spotřeby snižují plýtvání a náklady z nadbytečných geograficky distribuovaných nasazení.
• Služba API Management není nutná k implementaci vzoru návrhu, ale může být přidána ke každému geode, který předchází Azure Function aplikaci dané oblasti, aby poskytovala robustnější vrstvu API, což umožňuje například implementaci dalších funkcionalit, jako je omezení rychlosti.

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Zvolte, jestli chcete zpracovávat data místně v jednotlivých oblastech, nebo distribuovat agregace v jedné geografické oblasti a replikovat výsledek po celém světě. Procesor kanálu změn Azure Cosmos DB nabízí tento podrobný ovládací prvek pomocí konceptu lease kontejneru a leasecollectionprefix v odpovídající vazbě Azure Functions. Každý přístup má odlišné výhody a nevýhody.
• Geodes může pracovat společně s využitím kanálu změn služby Azure Cosmos DB a komunikační platformy v reálném čase, jako je SignalR. Geody můžou komunikovat se vzdálenými uživateli prostřednictvím jiných geod ve vzoru mesh sítě, aniž by věděly nebo záleželo, kde se vzdálený uživatel nachází.
• Tento vzor návrhu implicitně odděluje všechno, což vede k vysoce distribuované a oddělené architektuře. Zvažte, jak sledovat různé komponenty stejného požadavku, které se můžou spouštět asynchronně v různých instancích. Důležitá je správná strategie monitorování. Služba Azure Front Door i Azure Cosmos DB je možné snadno integrovat se službou Log Analytics a Služba Azure Functions by měly být nasazeny společně s Application Insights, aby poskytovaly robustní monitorovací systém v každé komponentě architektury.
• Distribuovaná nasazení mají větší počet tajemství a vstupních bodů, které vyžadují odpovídající bezpečnostní opatření. Key Vault poskytuje zabezpečenou vrstvu pro správu tajných kódů a každá vrstva v architektuře rozhraní API by měla být správně zabezpečená, takže jediným bodem příchozího přenosu dat pro rozhraní API je front-endová služba, jako je Azure Front Door. Azure Cosmos DB by měla omezit provoz mezi Azure Function Apps a Azure Front Door pomocí Microsoft Entra ID nebo postupů, jako je omezení IP adres.
• Výkon je výrazně ovlivněn počtem nasazených geod a konkrétními App Service Plans aplikovanými na API technologii v každé geodě. Nasazení dalších uzlů nebo přechod na úrovně Premium přináší zvýšené náklady na další paměť a výpočetní prostředky, avšak tyto náklady nejsou účtovány na základě jednotlivých transakcí. Zvažte zátěžové testování architektury API po nasazení a porovnání zvýšení počtu uzlů se zvýšením cenové úrovně, aby byl použit nejefektivnější model pro vaše potřeby.
• Určete požadavky na dostupnost vašich dat. Azure Cosmos DB má volitelné příznaky pro povolení zápisu do více oblastí, zón dostupnosti a dalších. Tím se zvýší dostupnost instance Služby Azure Cosmos DB a vytvoří odolnější datovou vrstvu, ale s dalšími náklady.
• Azure nabízí různé nástroje pro vyrovnávání zatížení, které poskytují různé funkce pro distribuci provozu. Rozhodovací strom vám pomůže vybrat správnou možnost pro front-end vašeho rozhraní API.

Kdy se má tento model použít

Použijte tento model:

• Pokud chcete implementovat vysoce škálovanou platformu, která má uživatele distribuované v široké oblasti.
• Pro všechny služby, které vyžadují extrémní charakteristiky dostupnosti a odolnosti, protože služby založené na vzoru geode mohou přežít ztrátu více oblastí služeb najednou.

Tento vzor nemusí být vhodný pro

• Architektury, které mají omezení, takže všechny geody nemohou být stejné pro ukládání dat. Mohou existovat například požadavky na rezidenci dat, aplikace, která musí udržovat dočasný stav pro určitou relaci, nebo výrazný nápor požadavků na jediný region. V takovém případě zvažte použití kolků nasazení v kombinaci s globální rovinou směrování, která zná umístění dat uživatele, například komponenta směrování provozu popsaná ve vzoru kolků nasazení.
• Situace, kdy není potřeba žádné geografické rozdělení. Místo toho zvažte zóny dostupnosti a spárované oblasti pro clustering.
• Situace, kdy je potřeba zpětně namontovat starší platformu. Tento model funguje jenom pro vývoj nativní pro cloud a může být obtížné ho zpětně přizpůsobit.
• Jednoduché architektury a požadavky, kdy geografická redundance a geografická distribuce nejsou povinné ani výhodné.

Návrh úloh

Architekt by měl vyhodnotit způsob použití vzoru Geode v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Tento model využívá replikaci dat k podpoře ideálu, že libovolný klient se může připojit k libovolné geografické instanci, a tím může vaše zatížení odolat jednomu nebo několika oblastním výpadkům. - RE:05 Návrh s vysokou dostupností ve více oblastech - RE:05 Oblasti a zóny dostupnosti
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento model můžete použít k poskytování aplikace z oblasti, která je nejblíže vaší distribuované uživatelské bázi. Tím se snižuje latence tím, že eliminujete vzdálený provoz a protože sdílíte infrastrukturu pouze mezi uživateli, kteří aktuálně používají stejnou geode. - PE:03 Výběr služeb

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklady

• Windows služba Active Directory implementuje ranou variantu tohoto modelu. Replikace s více primárními rolemi znamená, že všechny aktualizace a požadavky mohou být v teorii obslouženy ze všech obsluhovatelných uzlů, ale role FSMO (Flexible Single Master Operation) znamenají, že všechny uzly nejsou stejné.