Měření spotřeby jednotlivých tenantů
Jako poskytovatel řešení je důležité měřit spotřebu každého tenanta ve víceklientském řešení. Měřením spotřeby každého tenanta můžete zajistit, aby náklady na prodané zboží (COGS) pro dodání služby každému tenantovi byly ziskové. Na této stránce poskytujeme pokyny pro pracovníky technického rozhodování o důležitosti měření spotřeby a přístupy, které můžete zvážit při měření spotřeby tenanta a také kompromisy, které se týkají.
Při měření spotřeby jednotlivých tenantů existují dvě hlavní aspekty:
- Potřebujete změřit skutečné náklady pro obsluhu každého tenanta. To je důležité ke sledování ziskovosti řešení pro každého tenanta.
- Při používání cen založených na spotřebě musíte určit částku, která se má účtovat tenantovi.
Může ale být obtížné měřit skutečné prostředky používané tenantem ve víceklientských řešeních. Většina služeb, které je možné použít jako součást víceklientských řešení, nerozlišují ani nerozlišují využití automaticky na základě toho, co definujete tenanta. Představte si například službu, která ukládá data pro všechny tenanty v jedné relační databázi. Je obtížné přesně určit, jakou kapacitu každý tenant používá v dané relační databázi z hlediska úložiště dat nebo výpočetních prostředků potřebných ke službě jakýchkoli dotazů a požadavků.
Naproti tomu u řešení s jedním tenantem můžete pomocí služby Microsoft Cost Management na webu Azure Portal získat úplný rozpis nákladů pro všechny prostředky Azure, které tento tenant spotřebuje.
Proto při řešení těchto problémů je důležité zvážit, jak měřit spotřebu.
Poznámka:
V některých případech je komerčně přijatelné vzít ztrátu při poskytování služeb klientovi, například při vstupu na nový trh nebo oblast. Jedná se o komerční volbu. I v těchto situacích je stále vhodné měřit spotřebu jednotlivých tenantů, abyste si mohli naplánovat budoucnost.
Metriky orientační spotřeby
Moderní aplikace (vytvořené pro cloud) se obvykle skládají z mnoha různých služeb, z nichž každá má různou míru spotřeby. Například účet úložiště měří spotřebu na základě množství uložených dat, přenášených dat a počtu transakcí. Naproti tomu spotřeba služby Aplikace Azure měří 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 služby App Service, může být velmi obtížné zkombinovat všechna tato měření a vypočítat skutečné COGS (náklady na prodané zboží).
Často je jednodušší použít jedno orientační měření, které představuje spotřebu v řešení. Pokud například víceklientové řešení sdílí jednu relační databázi, můžou být data uložená tenantem dobrou indikační metrikou spotřeby.
I když jako orientační míru spotřeby používáte objem dat uložených tenantem, nemusí se jednat o skutečnou reprezentaci spotřeby pro každého tenanta. Pokud konkrétní tenant provádí mnohem více čtení nebo spouští více sestav z řešení, ale nezapisuje velké množství dat, může tento tenant použít mnohem více výpočetních prostředků, než by to značilo požadavky na úložiště.
Tip
Občas byste měli měřit a kontrolovat skutečnou spotřebu napříč tenanty, abyste vytvořili základní model. Tento model vám pomůže určit, jestli jsou předpoklady, které děláte, ohledně orientačních metrik správné.
Transakční metriky
Alternativní způsob měření spotřeby spočívá v identifikaci klíčové transakce, která je reprezentativní pro COGS pro řešení. Například v řešení pro správu dokumentů může být počet vytvořených dokumentů. To může být užitečné, pokud existuje základní funkce nebo funkce v systému, který je transakční, a pokud je možné ji snadno měřit.
Tato metoda je obvykle snadná a nákladově efektivní, protože v aplikaci je obvykle jen jeden bod, který potřebuje zaznamenat počet transakcí, ke kterým dochází.
Metriky pro jednotlivé požadavky
V řešeních, která jsou primárně založená na rozhraní API, může být vhodné použít metriku spotřeby, která je založená na počtu požadavků rozhraní API provedených v řešení. Tato implementace může být často poměrně jednoduchá, ale vyžaduje, abyste jako primární rozhraní systému používali rozhraní API. Kvůli nutnosti zaznamenávat využití požadavků (pro účely auditu a fakturace) se zvýší provozní náklady na implementaci metriky pro jednotlivé požadavky, zejména u velkých objemů služeb.
Uživatelská řešení, která se skládají z jednostránkové aplikace (SPA) nebo mobilní aplikace využívající rozhraní API, nemusí být vhodná pro metriku jednotlivých požadavků. Je to proto, že koncový uživatel vztahu mezi používáním aplikace a spotřebou rozhraní API příliš nerozumí. Vaše aplikace může být chatty (dělá mnoho požadavků rozhraní API) nebo chunky (dělá příliš málo požadavků rozhraní API) a uživatel si nevšimne rozdílu. Pokud ale potřebujete jenom přibližnou představu o spotřebě jednotlivých tenantů, může být stále rozumnou volbou.
Upozorňující
Ujistěte se, že ukládáte metriky požadavků do spolehlivého úložiště dat navrženého pro tento účel. I když Aplikace Azure lication Insights může například sledovat požadavky a dokonce i sledovat ID tenanta (pomocí vlastností), Application Insights není navržený tak, aby ukládaly každou část telemetrie. Odebere data v rámci svého chování při 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 pro tenanta může být snazší poskytnout odhad spotřeby pro tenanta, a nemusíte se pokoušet vypočítat přesné množství spotřeby. Například u víceklientského řešení, které v jednom nasazení obsluhuje mnoho tisíc tenantů, je vhodné odhadnout, ž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:
- Nepoužíváte ceny založené na spotřebě.
- Vzorce využití a náklady pro každého tenanta jsou podobné bez ohledu na velikost.
- Každý tenant spotřebuje 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 metrikami orientační spotřeby, metrikami transakcí nebo metrikami podle požadavků. Například pro aplikaci, která primárně spravuje dokumenty, procento celkového úložiště používaného tenantem, k ukládání svých dokumentů, poskytuje dostatečně blízkou reprezentaci skutečného COGS. To může být užitečný přístup při měření COGS je obtížné nebo kdy by aplikace přidala příliš mnoho složitosti.
Účtování nákladů
V některých řešeních můžete zákazníkům účtovat poplatky za prostředky jejich tenanta. Značky prostředků Azure můžete například použít k přidělení fakturovatelných prostředků Azure tenantům. Pak můžete určit náklady na každého tenanta pro sadu prostředků, které jsou pro ně vyhrazené, a navíc marži pro zisk a provoz.
Poznámka:
Některé služby Azure nepodporují značky. U těchto služeb je potřeba přiřadit náklady tenantovi na základě jiných charakteristik, jako je název prostředku, skupina prostředků nebo předplatné.
Analýzu nákladů azure je možné použít k analýze nákladů na prostředky Azure pro řešení s jedním tenantem, která k přiřazení nákladů používají značky, skupiny prostředků nebo předplatná.
Ve většině moderních víceklientských řešení se to ale stává příliš složitým vzhledem k tomu, že je potřeba přesně určit přesnou společnost COGS, která bude sloužit jednomu tenantovi. Tuto metodu byste měli zvážit pouze u velmi jednoduchých řešení, řešení, která mají nasazení prostředků s jedním tenantem nebo vlastní funkce doplňku specifické pro tenanty 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íceklientských prostředích. Azure Kubernetes Service například podporuje více fondů uzlů, kde je každému tenantovi přidělen fond uzlů se značkami fondu uzlů, které se používají k přiřazení nákladů.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- Daniel Scott-Raynsford | Partner Technology Strategist
Další přispěvatelé:
- John Downs | Hlavní softwarový inženýr
- Chad Kittel | Hlavní softwarový inženýr
- Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.