Měření spotřeby jednotlivých tenantů

  • Článek
  • 5 min ke čtení

Jako poskytovatel řešení je důležité měřit spotřebu jednotlivých tenantů ve vícetenantových řešeních. Měřením spotřeby jednotlivých tenantů můžete zajistit, že náklady na prodané zboží (COGS) pro doručení služby každému tenantovi jsou ziskové.

Existují dvě hlavní obavy, které řídí potřebu měření spotřeby jednotlivých tenantů:

  • Abyste každého tenanta obsloužili, musíte změřit skutečné náklady. To je důležité k monitorování ziskovosti řešení pro každého tenanta.
  • Pokud používáte ceny založené na spotřebě, musíte určit, jaké množství se má tenantovi účtovat.

Měření skutečných prostředků používaných tenantem ve vícetenantových řešeních ale může být obtížné. Většina služeb, které je možné použít jako součást více tenantů, automaticky nerozlišuje ani nerozlišuje využití na základě toho, čím tenanta definujete. Představte si například službu, která ukládá data pro všechny tenanty do jedné relační databáze. Je obtížné přesně určit, kolik místa každý tenant používá pro tuto relační databázi, a to buď z hlediska úložiště, nebo výpočetní kapacity, která je nutná ke zpracování dotazů a požadavků.

Naproti tomu u řešení s jedním tenantem můžete použít Azure Cost Management v rámci Azure Portal a získat úplný rozpis nákladů pro všechny prostředky Azure spotřebované tímto tenantem.

Proto je při řešení těchto výzev důležité zvážit, jak měřit spotřebu.

Poznámka

V některých případech je komerčně přijatelné způsobit ztrátu při doručování služby tenantovi, například při vstupu na nový trh nebo do oblasti. Jedná se o komerční volbu. I v těchto situacích je stále vhodné měřit spotřebu jednotlivých tenantů, abyste mohli naplánovat budoucnost.

Indikativní metriky spotřeby

Moderní aplikace (vytvořené pro cloud) jsou obvykle tvořené mnoha různými službami, z nichž každá má různé míry využití. Účet úložiště například měří spotřebu na základě množství uložených dat, přenášených dat a počtu transakcí. Spotřeba Azure App Service se ale měří podle množství výpočetních prostředků přidělených v průběhu času. Pokud máte řešení, které zahrnuje účet úložiště a prostředky App Service, může být zkombinováním všech těchto měření dohromady vypočítat skutečné náklady na cogs (náklady na prodané zboží) velmi obtížný úkol. Často je jednodušší použít jedno určující měření, které představuje spotřebu v řešení.

Například v případě vícetenantového řešení, které sdílí jednu relační databázi, můžete určit, že uložená data jsou dobrou indikující metrikou spotřeby.

Poznámka

I když jako indikativní míru spotřeby použijete objem dat uložených tenantem, nemusí to být skutečné vyjádření spotřeby pro každého tenanta. Pokud například konkrétní tenant dělá mnohem více čtení nebo spouští více sestav z řešení, ale nezapisuje velké množství dat, může použít mnohem více výpočetních prostředků, než by naznačly požadavky na úložiště.

Je důležité občas změřit a zkontrolovat skutečnou spotřebu napříč tenanty, abyste zjistili, jestli jsou předpoklady pro vaše indikativní metriky správné.

Transakční metriky

Alternativním způsobem měření spotřeby je identifikace klíčové transakce, která reprezentují COGS pro řešení. Například v řešení pro správu dokumentů to může být počet vytvořených dokumentů. To může být užitečné, pokud je v rámci transakčního systému základní funkce nebo funkce a lze ji snadno měřit.

Tato metoda je obvykle snadná a nákladově efektivní, protože ve vaší aplikaci obvykle existuje pouze jeden bod, který potřebuje zaznamenat počet transakcí, ke kterým dojde.

Metriky pro každý požadavek

V řešeních, která jsou primárně založená na rozhraní API, může být smyslusné použít metriku spotřeby založenou na počtu požadavků rozhraní API, které se do řešení prochytá. Často může být implementace poměrně jednoduchá, ale vyžaduje použití rozhraní API jako primárního rozhraní systému. Vzhledem k tomu, že je potřeba zaznamenávat využití požadavků (pro účely auditování a fakturace), budou se zvyšovat provozní náklady na implementaci metriky pro požadavky, zejména u služeb s vysokým objemem dat.

Poznámka

Uživatelská řešení, která se skládají z jedno stránkové aplikace (SPA) nebo mobilní aplikace, která používá rozhraní API, nemusí být pro metriku jednotlivých žádostí vhodná. Je to proto, že koncový uživatel moc neřešuje vztah mezi používáním aplikace a spotřebou rozhraní API. Vaše aplikace může být chatrná (provádí mnoho požadavků rozhraní API) nebo bloky dat (provádí příliš málo požadavků rozhraní API) a uživatel si nevšimne žádného rozdílu.

Upozornění

Ujistěte se, že metriky požadavků ukládáte do spolehlivého úložiště dat navrženého pro tento účel. I když služba Azure Application Přehledy může například sledovat požadavky a dokonce sledovat ID tenantů (pomocí vlastností), není služba Application Přehledy navržená k ukládání všech telemetrických dat. Odebere data jako součást vzorkování. Pro účely fakturace a měření zvolte úložiště dat, které vám poskytne vysokou úroveň přesnosti.

Odhad spotřeby

Při měření spotřeby tenanta může být snazší odhadnout spotřebu tenanta, místo abyste se pokoušeli vypočítat přesnou spotřebu. Například u vícetenantového řešení, které obsluhující mnoho tisíc tenantů v jednom nasazení, je rozumné odhadovat, že náklady na obsluhu tenanta jsou jen procentem nákladů na prostředky Azure.

V následujících případech můžete zvážit odhad coGS pro tenanta:

  • Nevyužíváte ceny založené na spotřebě.
  • Vzory využití a náklady na každého tenanta jsou podobné bez ohledu na velikost.
  • Každý tenant spotřebovává nízké procento (například <2 %) celkových prostředků v nasazení.
  • Náklady na tenanta jsou nízké.

Můžete se také rozhodnout odhadnout spotřebu v kombinaci s indikativními metrikami spotřeby,transakčními metrikami nebo metrikami pro každý požadavek. Například pro aplikaci, která primárně spravuje dokumenty, procento celkového úložiště používaného tenantem k ukládání dokumentů poskytuje dostatečně blízkou reprezentaci skutečného COGS. To může být užitečný přístup, pokud je měření COGS obtížné nebo kdy by to aplikaci příliš ztěžuje.

Účtování nákladů

V některých řešeních můžete zákazníkům jednoduše účtovat poplatky za prostředky jejich tenanta podle COGS. Značky prostředků Azure můžete například použít k přidělování fakturovatelných prostředků Azure tenantům. Pak můžete určit náklady na jednotlivé tenanty pro sadu prostředků, které jsou pro ně vyhrazené, a marži pro zisk a provoz.

Poznámka

Některé služby Azure nepodporují značky. U těchto služeb budete muset připsat náklady tenantovi na základě názvu prostředku, skupiny prostředků nebo předplatného.

Pomocí analýzy nákladů Azure můžete analyzovat náklady na prostředky Azure u řešení s jedním tenantem, která k atributování nákladů používají značky, skupiny prostředků nebo předplatná.

Ve většině moderních více tenantů se to ale stává příliš složitým vzhledem k úkolu přesného určení přesné služby COGS pro jednoho tenanta. Tuto metodu je třeba zvážit pouze pro velmi jednoduchá řešení, řešení, která mají nasazení prostředků s jedním tenantem, nebo vlastní funkce doplňku specifické pro tenanta v rámci většího řešení.

Některé služby Azure poskytují funkce, které umožňují jiné metody přisuzování nákladů ve vícetenantém prostředí. Například aplikace Azure Kubernetes Service vícefondů uzlů, kde je každému tenantovi přidělen fond uzlů se značkami fondu uzlů ,které se používají k atributování nákladů.

Další kroky

Vezměte v úvahu model nasazení aktualizací, který budete používat.