Sdílet prostřednictvím

Přístupy architektury 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ů určité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ých řešení často využívají sdílené výpočetní prostředky, protože vyšší hustota tenantů pro infrastrukturu 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 k aspektům a požadavkům, které jsou nezbytné pro architekty řešení, které je potřeba vzít v úvahu při plánování víceklientských výpočetních úrovní. 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 se chcete vyhnout.

Klíčové aspekty a požadavky

Víceklientská architektura a vámi vybraný model izolace 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 provést při plánování víceklientských výpočetních řešení.

Měřítko

Systémy musí provádět adekvátně pod měnící se poptávkou. 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ě když počet aktivních uživatelů nebo množství provozu klesne, 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 nezávisle škálovat prostředky jednotlivých tenantů. V řešení, kde se výpočetní prostředky sdílejí mezi více tenanty, pokud tyto prostředky škálujete, můžou všichni tito tenanti využívat nové škálování. Všechny však budou trpět také v případě, že škálování není dostatečné ke zvládnutí jejich celkového zatížení. Další informace naleznete v problém hlučného souseda.

Při vytváření cloudových řešení se můžete rozhodnout, jestli se má š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 vyšší celkový strop škálování.

Problémy s výkonem často zůstávají nezjištěné, dokud se aplikace nenačte. Pokud chcete zjistit, jak se vaše aplikace chová pod stresem, můžete použít plně spravovanou službu, jako je například Zátěžové testování Azure.

Triggery škálování

Bez ohledu na to, jaký přístup ke škálování použijete, obvykle potřebujete naplánovat triggery, které způsobí škálování komponent. Pokud máte sdílené komponenty, zvažte vzory úloh každého tenanta, který prostředky používá, aby vaše zřízená kapacita mohla splňovat celkovou požadovanou kapacitu a minimalizovat pravděpodobnost, že u tenanta dochází k problému s hlučným sousedem. Kapacitu škálování můžete také naplánovat zvážením počtu tenantů. Pokud například změříte prostředky, které používáte ke službě 100 tenantů, můžete při připojování dalších tenantů naplánovat škálování tak, aby se prostředky zdvojnásobily pro každých dalších 100 tenantů.

Stav

Výpočetní prostředky můžou být bezstavové nebo můžou být stavové. Bezstavové komponenty neudržuje žádná data mezi požadavky. Z hlediska škálovatelnosti jsou bezstavové komponenty často snadno škálovatelné, protože můžete rychle přidávat nové pracovní procesy, instance nebo uzly a okamžitě začít zpracovávat požadavky. Pokud to vaše architektura umožňuje, můžete také změnit účel instancí přiřazených 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 je data, která je potřeba trvale uložit. V cloudovýchřešeních Místo toho používejte služby úložiště, jako jsou databáze nebo účty úložiště. Přechodný stav je data, která jsou dočasně uložená a zahrnují mezipaměti v paměti jen pro čtení a úložiště 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 back-endové služby ú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 při obsluhování jiného požadavku.

V aplikacích citlivých na latenci se můžou stát významné náklady na hydraci mezipaměti. Víceklientové řešení může tento problém zhoršit, pokud každý tenant vyžaduje, aby se jiná data ukládaly do mezipaměti. 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 zpracovávají stejný výpočetní pracovní uzel. I když spřažení relací může zlepšit schopnost aplikační vrstvy efektivně používat svou mezipaměť, je také obtížnější škálovat a vyrovnávat zatížení provozu mezi pracovními procesy. Tento kompromis je potřeba pečlivě zvážit. U mnoha aplikací není potřeba spřažení relací.

Je také možné ukládat data 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 úniku dat mezi tenanty, kdykoli používáte mezipaměti v paměti nebo jiné komponenty, které udržují stav. Zvažte například předsazení identifikátoru tenanta pro všechny klíče mezipaměti, abyste zajistili, že jsou data oddělená pro každého tenanta.

Izolace

Při návrhu víceklientských výpočetních úrovní máte často mnoho možností zvážit úroveň izolace mezi tenanty, včetně nasazení sdílených výpočetních prostředků, které budou používat všichni tenanti, vyhrazené výpočetní prostředky pro každého tenanta nebo něco mezi těmito extrémními hodnotami. Každá možnost má 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í nebo zásad správy, které se vztahují na každého tenanta. Případně můžete potřebovat nasadit jedinečné konfigurace prostředků pro konkrétní tenanty, například nasadit skladovou položku konkrétního virtuálního počítače tak, aby vyhovovala úloze tenanta.

Bez ohledu na to, který model izolace vyberete, ověřte, že data tenanta zůstanou správně izolovaná i v případě, že komponenty nejsou dostupné nebo nefungují správně. Zvažte použití nástroje Azure Chaos Studio jako součást vašeho běžného procesu automatizovaného testování, abyste záměrně zavedli chyby, které simulují výpadky reálného světa a ověřují, že vaše řešení neprovádí data mezi tenanty a funguje správně i pod tlakem.

Přístupy a vzory, které je potřeba zvážit

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í, které vyžaduje, abyste zvážili, kdy byste měli škálovat, a minimální a maximální úrovně škálování. Konkrétní možnosti dostupné pro škálování závisí na výpočetních službách, které používáte. Podívejte se na následující ukázkové služby:

  • Aplikace Azure Služba: Zadejte pravidla automatického škálování, která škálují infrastrukturu na základě vašich požadavků.
  • Azure Functions: Vyberte si z několika možností škálování, včetně modelu škálování řízeného událostmi, který se automaticky škáluje na základě práce, kterou vaše funkce provádějí.
  • Azure Container Apps: Použití automatického škálování řízeného událostmi ke škálování aplikace na základě práce, kterou provádí, a podle aktuálního zatížení.
  • Azure Kubernetes Service (AKS): Pokud chcete držet krok s požadavky vaší aplikace, možná budete muset upravit počet uzlů, na kterých běží vaše úlohy. Kromě toho můžete k rychlému škálování aplikačních úloh v clusteru AKS použít virtuální uzly.
  • Virtuální počítače: Škálovací sada virtuálních počítačů může automaticky zvýšit nebo snížit počet instancí virtuálních počítačů, na kterých běží vaše aplikace.

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ů vám pomůže dosáhnout vyšší hustoty tenantů výpočetní infrastruktury sdílením 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 ke správě existuje méně komponent.

Konsolidace výpočetních prostředků ale zvyšuje pravděpodobnost problému hlučného souseda. Každá úloha tenanta může spotřebovávat nepřiměřeně velkou 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žijete ovládací prvky, jako jsou kvóty a limity rozhraní API, abyste se vyhnuli tenantům, kteří spotřebovávají více než jejich spravedlivý podíl na kapacitě.

Tento model se dosahuje různými způsoby v závislosti na používané výpočetní službě. Podívejte se na následující ukázkové služby:

  • Aplikace Azure Service a Azure Functions: Nasaďte sdílené plány služby 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 víceklientské aplikace.
  • Virtuální počítače: Nasaďte jednu sadu virtuálních počítačů, aby je mohli 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 sniž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 jednotlivých tenantů 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:

  • Aplikace Azure Service a Azure Functions: Nasaďte samostatné plány služby App Service pro každého tenanta.
  • 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.

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

Azure Container Apps umožňuje nasadit do sdíleného prostředí více aplikací a pak používat Dapr a další nástroje ke konfiguraci jednotlivých aplikací samostatně.

Azure Kubernetes Service (AKS) a Kubernetes obecněji poskytují celou řadu možností pro víceklientské prostředí, včetně následujících:

  • Obory názvů specifické pro tenanty pro logickou izolaci prostředků specifických pro tenanty, které jsou nasazené do sdílených clusterů a fondů uzlů.
  • Uzly nebo fondy uzlů pro konkrétní tenanty ve sdíleném clusteru.
  • Pody specifické pro tenanty, 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í pro správu prostředků ve službě 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 architekturou. Server rozhraní API Kubernetes je například sdílená služba, která se používá v celém clusteru. I když poskytujete fondy uzlů specifické pro tenanty pro izolaci aplikačních úloh tenantů, může u serveru rozhraní API docházet k kolizím z velkého počtu požadavků napříč tenanty.

Antipatterny, aby se zabránilo

Antipattern hlučný soused

Pokaždé, když nasadíte komponenty sdílené mezi tenanty, představuje problém s hlučným sousedem potenciální riziko. Ujistěte se, že zahrnete zásady správného řízení a monitorování prostředků, abyste snížili riziko ovlivnění výpočetní úlohy tenanta aktivitou jiných tenantů.

Únik dat mezi tenanty

Úrovně výpočetních prostředků můžou podléhat úniku dat mezi tenanty, pokud nejsou správně zpracovány. To obecně není něco, co je potřeba vzít v úvahu, když používáte víceklientovou službu v Azure, protože Microsoft poskytuje ochranu ve vrstvě platformy. Při vývoji vlastní víceklientové aplikace ale zvažte, jestli některé sdílené prostředky (například mezipaměti místních disků, paměti RAM a externí mezipaměti) můžou obsahovat data, která může neúmyslně zobrazit nebo upravit jiný tenant.

Antipattern zaneprázdněného front-endu

Abyste se vyhnuli antipatternu zaneprázdněného front-endu, vyhněte se front-endové vrstvě, která by mohla být zpracována jinými komponentami nebo vrstvami vaší architektury. Tento antipattern je zvláště 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í pomocí front nebo jiných služeb zasílání zpráv. Tento přístup vám také umožňuje použít kontroly kvality služeb (QoS) pro různé tenanty na základě jejich požadavků. Například všichni tenanti můžou sdílet společnou front-endovou úroveň, 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ě.

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

Víceklientská řešení se často řídí vzory nárazového škálování. Sdílené komponenty jsou zvláště náchylné k tomuto problému, protože rozsah 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 vertikální š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á pod různými úrovněmi zatížení. Ujistěte se, že zahrnete objemy zatížení, které se očekávají v produkčním prostředí, a očekávaný růst. Pokud chcete zjistit, jak se vaše aplikace chová pod stresem, můžete použít plně spravovanou službu, jako je například Zátěžové testování Azure.

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 rekomputuje informace, které je možné znovu použít napříč požadavky. Pokud máte data, která je možné sdílet mezi tenanty nebo mezi uživateli v rámci jednoho tenanta, je pravděpodobné, že je vhodné je uložit do mezipaměti, aby se snížilo zatížení back-endové nebo databázové vrstvy.

Nepotřebná stavivost

Součástí antipatternu Bez ukládání do mezipaměti je, že byste se také měli vyhnout ukládání nepotřebného stavu ve vaší výpočetní vrstvě. Buďte explicitní o tom, kde udržujete stav a proč. Stavové front-endové vrstvy 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 schopnost efektivně vyrovnávat zatížení provozu mezi pracovními procesy nebo uzly.

Zvažte kompromisy pro každý stav, který udržujete ve výpočetní vrstvě, a to, jestli ovlivňuje 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, jako je Azure Cache for Redis.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

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

Další přispěvatelé:

Další kroky

Projděte si pokyny specifické pro službu pro vaše výpočetní služby: