Přístupy k architektuře pro výpočetní prostředky ve víceklientských řešeních

  • Článek

Většina cloudových řešení se skládá z výpočetních prostředků nějakého druhu, jako jsou webové a aplikační vrstvy, dávkové procesory, naplánované úlohy a dokonce i specializované prostředky, jako jsou GPU a vysokovýkonné výpočetní prostředí (HPC). Víceklientská řešení často využívají sdílené výpočetní prostředky, protože vyšší hustota tenantů do infrastruktury snižuje provozní náklady a správu. Měli byste zvážit požadavky na izolaci a důsledky sdílené infrastruktury.

Tento článek obsahuje pokyny týkající se důležitých aspektů a požadavků, které musí architekti řešení zvážit při plánování úrovně víceklientských výpočetních prostředků. To zahrnuje některé běžné vzory pro použití víceklientské architektury na výpočetní služby spolu s některými antipatterny, kterým je třeba se vyhnout.

Klíčové aspekty a požadavky

Víceklientská architektura a model izolace, který vyberete, ovlivňují škálování, výkon, správu stavu a zabezpečení výpočetních prostředků. V této části si projdeme některá klíčová rozhodnutí, která musíte udělat při plánování víceklientského výpočetního řešení.

Měřítko

Systémy musí mít odpovídající výkon při měnící se poptávce. S rostoucím počtem tenantů a objemem provozu možná budete muset zvýšit kapacitu vašich prostředků, abyste udrželi krok s rostoucím počtem tenantů a zachovali přijatelnou míru výkonu. Podobně platí, že když se sníží počet aktivních uživatelů nebo objem provozu, měli byste automaticky snížit výpočetní kapacitu, abyste snížili náklady, ale měli byste snížit kapacitu s minimálním dopadem na uživatele.

Pokud nasadíte vyhrazené prostředky pro každého tenanta, máte možnost škálovat prostředky každého tenanta nezávisle na sobě. Pokud v řešení, kde se výpočetní prostředky sdílí mezi několika tenanty, můžou všichni tito tenanti využívat nové škálování. Všechny ale také trpí, když škálování nebude stačit ke zvládnutí jejich celkového zatížení. Další informace najdete v tématu Problém s hlučnou sousedou.

Při sestavování cloudových řešení si můžete zvolit, jestli chcete škálovat horizontálně nebo svisle. Ve víceklientské řešení s rostoucím počtem tenantů vám horizontální škálování obvykle poskytuje větší flexibilitu a celkový strop škálování.

Problémy s výkonem často zůstávají nezjištěné, dokud nebude aplikace zatížena. Pomocí plně spravované služby, jako je Azure Load Testing, můžete zjistit, jak se vaše aplikace chová ve stresu.

Triggery škálování

Bez ohledu na to, jaký přístup ke škálování použijete, je obvykle potřeba naplánovat triggery, které způsobí škálování komponent. Pokud sdílíte komponenty, zvažte vzory úloh každého tenanta, který prostředky používá, abyste zajistili, že vaše zřízená kapacita dokáže splnit celkovou požadovanou kapacitu a minimalizovat riziko, že u tenanta dojde k problému s hlučným sousedem. Kapacitu škálování můžete také naplánovat s ohledem na počet tenantů. Pokud například změříte prostředky, které používáte ke službě 100 tenantů, můžete při nasazování dalších tenantů naplánovat škálování tak, aby se prostředky pro každých dalších 100 tenantů zdvojnásobily.

Stav

Výpočetní prostředky můžou být bezstavové nebo stavové. Bezstavové komponenty neudržuje žádná data mezi požadavky. Z hlediska škálovatelnosti se bezstavové komponenty často snadno škálují na více instancí, protože můžete rychle přidat nové pracovní procesy, instance nebo uzly a hned začít zpracovávat požadavky. Pokud to vaše architektura umožňuje, můžete také změnit účel instancí přiřazených k jednomu tenantovi a přidělit je jinému tenantovi.

Stavové prostředky je možné dále rozdělit na základě typu stavu, který udržují. Trvalý stav jsou data, která je potřeba trvale uložit. V cloudových řešeních byste se měli vyhnout ukládání trvalého stavu na úrovni výpočetních prostředků. Místo toho použijte služby úložiště, jako jsou databáze nebo účty úložiště. Přechodný stav jsou data, která jsou dočasně uložená a zahrnují mezipaměti v paměti jen pro čtení a ukládání dočasných souborů na místních discích.

Přechodný stav je často užitečný ke zlepšení výkonu aplikační vrstvy snížením počtu požadavků na služby back-endového úložiště. Pokud například používáte mezipaměť v paměti, můžete být schopni obsluhovat žádosti o čtení, aniž byste se připojili k databázi a aniž byste provedli náročný dotaz, který jste nedávno provedli, když jste obsloužili jiný požadavek.

V aplikacích citlivých na latenci můžou být náklady na hydrataci mezipaměti významné. Řešení s více tenanty může tento problém zhoršit, pokud každý tenant vyžaduje, aby se do mezipaměti ukládaly různá data. Pokud chcete tento problém zmírnit, některá řešení používají spřažení relací , aby se zajistilo, že všechny požadavky na konkrétního uživatele nebo tenanta zpracuje stejný výpočetní pracovní uzel. Přestože spřažení relací může zlepšit schopnost aplikační vrstvy efektivně používat mezipaměť, ztěžuje také škálování a vyrovnávání zatížení provozu mezi pracovními procesy. Tento kompromis je třeba pečlivě zvážit. U mnoha aplikací se spřažení relací nevyžaduje.

Data je také možné ukládat do externích mezipamětí, jako je Azure Cache for Redis. Externí mezipaměti jsou optimalizované pro načítání dat s nízkou latencí a současně udržují stav izolovaný od výpočetních prostředků, aby je bylo možné škálovat a spravovat samostatně. V mnoha řešeních umožňují externí mezipaměti zlepšit výkon aplikace, zatímco výpočetní úroveň zůstane bezstavová.

Důležité

Vyhněte se nevrácení dat mezi tenanty, když používáte mezipaměti v paměti nebo jiné komponenty, které udržují stav. Zvažte například předazení identifikátoru tenanta na všechny klíče mezipaměti, abyste zajistili, že data jsou pro každého tenanta oddělená.

Izolace

Při návrhu víceklientských výpočetních prostředků často máte mnoho možností, jak zvážit úroveň izolace mezi tenanty, včetně nasazení sdílených výpočetních prostředků, které mají používat všichni tenanti, vyhrazených výpočetních prostředků pro každého tenanta nebo něco mezi těmito extrémy. Každá možnost přináší kompromisy. Abyste se mohli rozhodnout, která možnost nejlépe vyhovuje vašemu řešení, zvažte své požadavky na izolaci.

Možná vás zajímá logická izolace tenantů a způsob oddělení odpovědností za správu nebo zásad, které se na každého tenanta vztahují. Alternativně můžete potřebovat nasadit různé konfigurace prostředků pro konkrétní tenanty, jako je například nasazení konkrétní skladové položky virtuálního počítače tak, aby vyhovovala úlohám tenanta.

Bez ohledu na to, který model izolace vyberete, ověřte, že data tenanta zůstávají vhodně izolovaná i v případě, že jsou součásti nedostupné nebo nefungují správně. Zvažte použití nástroje Azure Chaos Studio v rámci běžného automatizovaného testování, abyste záměrně zavedli chyby, které simulují skutečné výpadky a ověřují, že vaše řešení nedochází k úniku dat mezi tenanty a že funguje správně i pod tlakem.

Přístupy a vzory ke zvážení

Automatické škálování

Výpočetní služby Azure poskytují různé možnosti škálování úloh. Mnoho výpočetních služeb podporuje automatické škálování, což vyžaduje, abyste zvážili, kdy byste měli škálovat, a minimální a maximální úroveň škálování. Konkrétní dostupné možnosti škálování závisí na výpočetních službách, které používáte. Podívejte se na následující příklad služeb:

Model razítka nasazení

Další informace o tom, jak lze model razítka nasazení použít k podpoře víceklientského řešení, najdete v tématu Přehled.

Model konsolidace výpočtových prostředků

Model konsolidace výpočetních prostředků pomáhá dosáhnout vyšší hustoty tenantů pro výpočetní infrastrukturu díky sdílení základních výpočetních prostředků. Sdílením výpočetních prostředků můžete často snížit přímé náklady na tyto prostředky. Náklady na správu jsou navíc často nižší, protože je potřeba spravovat méně komponent.

Konsolidace výpočetních prostředků ale zvyšuje pravděpodobnost problému hlučného souseda. Úlohy libovolného tenanta můžou spotřebovávat nepřiměřenou výpočetní kapacitu, která je k dispozici. Toto riziko můžete často zmírnit tím, že zajistíte správné škálování vašeho řešení a použitím kontrolních mechanismů, jako jsou kvóty a limity rozhraní API, abyste se vyhnuli tenantům, kteří spotřebovávají více, než je jejich spravedlivý podíl na kapacitě.

Tento model se dosahuje různými způsoby v závislosti na výpočetní službě, kterou používáte. Podívejte se na následující příklad služeb:

  • Azure App Service a Azure Functions: Nasaďte sdílené plány App Service, které představují infrastrukturu hostitelského serveru.
  • Azure Container Apps: Nasaďte sdílená prostředí.
  • Azure Kubernetes Service (AKS): Nasaďte sdílené pody s aplikací s podporou víceklientské architektury.
  • Virtuální počítače: Nasaďte jednu sadu virtuálních počítačů, které budou používat všichni tenanti.

Vyhrazené výpočetní prostředky na tenanta

Můžete také nasadit vyhrazené výpočetní prostředky pro každého tenanta. Vyhrazené prostředky zmírňují riziko problému hlučného souseda tím, že zajišťují izolaci výpočetních prostředků pro každého tenanta od ostatních. Umožňuje také nasadit odlišnou konfiguraci pro prostředky každého tenanta na základě jejich požadavků. Vyhrazené prostředky ale obvykle mají vyšší náklady, protože máte nižší hustotu tenantů k prostředkům.

V závislosti na výpočetních službách Azure, které používáte, je potřeba nasadit různé vyhrazené prostředky následujícím způsobem:

  • Azure App Service a Azure Functions: Pro každého tenanta nasaďte samostatné plány App Service.
  • Azure Container Apps: Nasaďte samostatná prostředí pro každého tenanta.
  • Azure Kubernetes Service (AKS): Nasaďte vyhrazené clustery pro každého tenanta.
  • Virtuální počítače: Nasaďte vyhrazené virtuální počítače pro každého tenanta.

Částečně izolované výpočetní prostředky

Částečně izolované přístupy vyžadují, abyste nasadili aspekty řešení v izolované konfiguraci, zatímco ostatní komponenty sdílíte.

Když pracujete s App Service a Azure Functions, můžete pro každého tenanta nasadit samostatné aplikace a můžete je hostovat ve sdílených plánech App Service. Tento přístup snižuje náklady na úroveň výpočetních prostředků, protože App Service plány představují jednotku fakturace. Umožňuje také použít odlišnou konfiguraci a zásady pro každou aplikaci. Tento přístup ale představuje riziko problému hlučného souseda.

Azure Container Apps umožňuje nasadit více aplikací do sdíleného prostředí a pak pomocí Dapr a dalších nástrojů nakonfigurovat každou aplikaci samostatně.

Azure Kubernetes Service (AKS) a Kubernetes obecněji poskytují různé možnosti pro víceklientské architektury, včetně následujících:

  • Obory názvů specifické pro tenanta pro logickou izolaci prostředků specifických pro tenanta, které se nasazují do sdílených clusterů a fondů uzlů.
  • Uzly nebo fondy uzlů specifické pro tenanta ve sdíleném clusteru.
  • Pody specifické pro tenanta, které můžou používat stejný fond uzlů.

AKS také umožňuje použít zásady správného řízení na úrovni podů a zmírnit tak problém s hlučným sousedem. Další informace najdete v tématu Osvědčené postupy pro vývojáře aplikací při správě prostředků v Azure Kubernetes Service (AKS).

Je také důležité vědět o sdílených komponentách v clusteru Kubernetes a o tom, jak mohou být tyto komponenty ovlivněny víceklientskou instancí. Například server rozhraní API Kubernetes je sdílená služba, která se používá v celém clusteru. I když poskytnete fondy uzlů specifické pro tenanta k izolaci aplikačních úloh tenantů, může server rozhraní API zaznamenat kolize z velkého počtu požadavků napříč tenanty.

Antipatterny, kterým je třeba se vyhnout

Antipattern hlučný soused

Pokaždé, když nasadíte komponenty, které jsou sdílené mezi tenanty, představuje problém s hlučným sousedem potenciální riziko. Nezapomeňte zahrnout zásady správného řízení a monitorování prostředků, abyste zmírnili riziko, že výpočetní úloha tenanta bude ovlivněna aktivitou jiných tenantů.

Únik dat mezi tenanty

U úrovní výpočetních prostředků může docházet k úniku dat mezi tenanty, pokud se s nimi správně nezpracuje. To obecně není potřeba při používání víceklientských služeb v Azure brát v úvahu, protože Microsoft poskytuje ochranu ve vrstvě platformy. Při vývoji vlastní aplikace s více tenanty ale zvažte, jestli některé sdílené prostředky (jako jsou místní diskové mezipaměti, paměť RAM a externí mezipaměti) můžou obsahovat data, která může nechtěně zobrazit nebo upravit jiný tenant.

Antipattern zaneprázdněného front-endu

Pokud se chcete vyhnout antipatternu Busy Front End, vyhněte se tomu, aby front-endová vrstva prováděla spoustu práce, kterou by mohly zvládnout jiné komponenty nebo vrstvy vaší architektury. Tento antipattern je zvlášť důležitý při vytváření sdílených front-endů pro víceklientské řešení, protože zaneprázdněný front-end sníží prostředí pro všechny tenanty.

Místo toho zvažte použití asynchronního zpracování s využitím front nebo jiných služeb zasílání zpráv. Tento přístup také umožňuje použít ovládací prvky QoS (Quality of Service ) pro různé tenanty na základě jejich požadavků. Například všichni tenanti můžou sdílet společnou front-endovou vrstvu, ale tenanti, kteří platí za vyšší úroveň služby , můžou mít vyšší sadu vyhrazených prostředků pro zpracování práce ze zpráv ve frontě.

Neelastické nebo nedostatečné škálování

Víceklientská řešení často podléhají vzorům nárazového škálování. K tomuto problému jsou náchylné zejména sdílené komponenty, protože rozsah shlukového nárůstu je vyšší a dopad je větší, pokud máte více tenantů s odlišnými vzory použití.

Ujistěte se, že dobře využíváte elasticitu a škálování cloudu. Zvažte, jestli byste měli použít horizontální nebo svislé škálování a použít automatické škálování k automatickému zpracování špiček v zatížení. Otestujte své řešení, abyste pochopili, jak se chová při různých úrovních zatížení. Nezapomeňte zahrnout objemy zatížení očekávané v produkčním prostředí a očekávaný růst. Pomocí plně spravované služby, jako je Azure Load Testing, můžete zjistit, jak se vaše aplikace chová ve stresu.

Antipattern neexistujícího ukládání do mezipaměti

Antipattern Bez ukládání do mezipaměti je v případě, že výkon vašeho řešení trpí, protože aplikační vrstva opakovaně požaduje nebo přepočítává informace, které by se mohly opakovaně používat napříč požadavky. Pokud máte data, která je možné sdílet mezi tenanty nebo mezi uživateli v rámci jednoho tenanta, pravděpodobně stojí za to je uložit do mezipaměti, aby se snížilo zatížení vaší back-endové nebo databázové vrstvy.

Zbytečná stavovost

Důsledkem antipatternu Bez ukládání do mezipaměti je, že byste se také měli vyhnout ukládání nepotřebného stavu na úrovni výpočetních prostředků. Explicitní informace o tom, kde a proč udržujete stav. Stavové front-endové nebo aplikační vrstvy můžou snížit vaši schopnost škálování. Stavové úrovně výpočetních prostředků obvykle také vyžadují spřažení relací, což může snížit vaši schopnost efektivně vyrovnávat zatížení provozu mezi pracovními procesy nebo uzly.

Zvažte kompromisy pro každou část stavu, kterou udržujete na úrovni výpočetních prostředků, a to, jestli to má vliv na vaši schopnost škálovat nebo růst s tím, jak se mění vzory úloh vašich tenantů. Stav můžete také uložit do externí mezipaměti, například Azure Cache for Redis.

Přispěvatelé

Tento článek spravuje Microsoft. Původně ji napsali následující přispěvatelé.

Hlavní autoři:

  • Dixit Arora | Vedoucí zákaznický inženýr, FastTrack pro Azure
  • John Downs | Hlavní zákaznický inženýr FastTrack for Azure

Další přispěvatelé:

Další kroky

Projděte si doprovodné materiály ke konkrétním službám pro vaše výpočetní služby: