次の方法で共有

各テナントの使用量を測定する

  • [アーティクル]

ソリューション プロバイダーにとっては、マルチテナント ソリューションにおける各テナントの使用量を測定することが重要です。 各テナントの使用量を測定することで、(各テナントにサービスを提供するための) 売却済商品の原価 (COGS) が収益になるようにすることができます。 このページでは、使用量を測定する際の重要性、およびテナントの消費を測定するために考慮するアプローチと、関連するトレードオフについて、技術的な意思決定者向けのガイダンスを提供します。

次の 2 つの主な懸念事項によって、各テナントの使用量を測定する必要が生じます。

  • 各テナントに提供する実際のコストを測定する必要があります。 これは、各テナントに対するソリューションの収益性を監視するために重要です。
  • 使用量ベースの価格を使用している場合は、テナントに請求する料金を決定する必要があります。

しかし、マルチテナント ソリューションでは、テナントによって使用される実際のリソースを測定することが困難になる場合があります。 マルチテナント ソリューションの一部として使用できるほとんどのサービスでは、テナントをどのように定義しても、使用量が自動的に区別または分割されることはありません。 たとえば、すべてのテナントのデータを 1 つのリレーショナル データベースに格納するサービスを考えてみます。 各テナントがそのリレーショナル データベースの領域をどの程度使用するかを正確に特定するのは、ストレージの観点からみても、またクエリと要求を処理するために必要なコンピューティング容量の観点からみても、困難です。

対照的に、シングルテナント ソリューションの場合は、Azure portal 内で Microsoft Cost Management を使用して、そのテナントによって消費されるすべての Azure リソースの完全なコストの内訳を取得できます。

そのため、これらの課題に直面した場合は、使用量を測定する方法を検討することが重要です。

Note

場合によっては、テナントへのサービス提供において損失を被ることを商業的に容認できることがあります。たとえば、新しい市場や地域に参入する場合です。 これは商業的な選択です。 このような状況でも、将来的な計画を立てられるように各テナントの使用量を測定することをお勧めします。

指標となる使用量メトリック

通常、(クラウド向けに構築された) 最新のアプリケーションは多くの異なるサービスで構成されており、それぞれ使用量の測定方法が異なります。 たとえば、ストレージ アカウントでは格納データの量、転送されたデータ、およびトランザクションの数に基づいて使用量が測定されます。 しかし、Azure App Service の使用量は、時間の経過と共に割り当てられたコンピューティング リソースの量によって測定されます。 ストレージ アカウントと App Service リソースを含むソリューションがある場合、これらすべての測定値を組み合わせて実際の COGS (売却済商品の原価) を計算することは、非常に困難な作業になる可能性があります。 多くの場合、1 つの指標となる測定値を使用してソリューションの使用量を表す方が簡単です。

たとえば、1 つのリレーショナル データベースを共有するマルチテナント ソリューションの場合は、テナントが格納するデータが適切な指標となる使用量メトリックと見なされる場合があります。

Note

テナントによる格納データの量を指標となる使用量の測定方法として使用しても、すべてのテナントの使用量が本当に表されるとは限りません。 たとえば、特定のテナントで、読み込みやソリューションからのレポート作成の実行がかなり多く、書き込むデータがそれほど多くない場合は、ストレージ要件によって示されるよりもはるかに多くのコンピューティング容量が使用される可能性があります。

指標となるメトリックについての想定が正しいかどうかを判断するために、テナント全体で実際の使用量をときどき測定および確認することが重要です。

トランザクション メトリック

使用量を測定する別の方法として、ソリューションの COGS を表すキー トランザクションを識別する方法があります。 たとえば、ドキュメント管理ソリューションの場合は、作成されたドキュメントの数を使用できます。 これは、システム内にトランザクションとしてのコア関数または機能があり、それを簡単に測定できる場合に便利です。

通常、この方法は実装が簡単でコスト効率が高くなります。発生したトランザクションの数を記録する必要があるポイントは、通常はアプリケーション内に 1 つしか存在しないためです。

要求ごとのメトリック

主に API をベースとするソリューションでは、ソリューションに対する API 要求の数に基づく使用量メトリックを使用することが理にかなっている場合があります。 これは多くの場合、非常に簡単に実装できますが、システムに対するプライマリ インターフェイスとして API を使用する必要があります。 (監査および課金のために) 要求の使用状況を記録する必要があるため、特にボリュームの大きいサービスでは、要求ごとのメトリックを実装する運用コストが高くなります。

注意

シングルページ アプリケーション (SPA) またはその API を使用するモバイル アプリケーションで構成されているユーザー向けソリューションは、要求ごとのメトリックに適していない場合があります。 これは、アプリケーションの使用と API の使用の間の関係がエンド ユーザーによってほとんど理解されないためです。 アプリケーションで多くの API 要求が行われても、または API 要求が少ししか行われなくても、ユーザーが違いを気にすることはありません。

警告

要求メトリックは、この目的のために設計された信頼性の高いデータ ストアに格納してください。 たとえば、Azure Application Insights では要求を追跡したり、(プロパティを使用して) テナント ID を追跡したりすることもできますが、Application Insights はテレメトリのすべての部分を格納するようには設計されていません。 サンプリング動作の一環としてデータが削除されます。 課金と使用状況の測定のために、高レベルの精度を備えたデータ ストアを選択してください。

使用量を見積もる

テナントの使用量を測定する場合、正確な使用量を計算しようとする代わりに、そのテナントの使用量の見積もりを提供する方が簡単なことがあります。 たとえば、1 つのデプロイで何千ものテナントにサービスを提供するマルチテナント ソリューションの場合、テナントにサービスを提供するコストを単に Azure リソースのコストの割合として概算することは理にかなっています。

次の場合は、テナントの COGS を見積もることを検討してください。

  • 使用量ベースの価格を使用していない。
  • すべてのテナントの使用パターンとコストが、サイズに関係なく似ている。
  • デプロイ内のリソース全体のうち、各テナントによって使用される割合が低い (たとえば <2%)。
  • テナントごとのコストが低い。

また、使用量の見積もりを、 指標となる使用量メトリック、 トランザクション メトリック、または 要求ごとのメトリックと組み合わせて使うこともできます。 たとえば、主にドキュメントを管理するアプリケーションの場合は、テナントによって (ドキュメントを格納するために) 使用されるストレージ全体の割合によって、実際の COGS に十分に近いデータを表すことができます。 これは、COGS の測定が困難な場合や、それによりアプリケーションが複雑になりすぎる場合に便利な方法です。

コストの請求について

一部のソリューションでは、テナントのリソースの COGS を顧客に請求することができます。 たとえば、 Azure リソース タグ を使用して、課金対象の Azure リソースをテナントに割り当てることができます。 次に、各テナントに対して、専用のリソースのセットに対するコストと、利益と運用のためのマージンを決定できます。

注意

一部の Azure サービスではタグがサポートされていません。 これらのサービスについては、リソース名、リソース グループ、またはサブスクリプションに基づいて、そのコストをテナントに帰属させる必要があります。

Azure のコスト分析 を使用すると、コストの帰属にタグ、リソース グループ、またはサブスクリプションを使用するシングル テナント ソリューションの Azure リソースのコストを分析できます。

ただし、これは、ほとんどの最新マルチテナント ソリューションでは非常に複雑になります。1 つのテナントにサービスを提供するための COGS を正確に特定することが困難であるためです。 この方法は、非常にシンプルなソリューションや、シングルテナントのリソース デプロイを持つソリューション、またはより大きなソリューション内のテナント固有のカスタム アドオン機能に対してのみ検討してください。

一部の Azure サービスには、マルチテナント環境でのコストの帰属について他の方法を可能にする機能が用意されています。 たとえば、Azure Kubernetes Service では 複数のノード プールがサポートされており、 ノード プール タグを使用して各テナントにノード プールが割り当てられます。これは、コストの帰属に使用されます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

その他の共同作成者:

  • John Downs | プリンシパル ソフトウェア エンジニア
  • Chad Kittel | プリンシパル ソフトウェア エンジニア
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

使用する更新プログラムのデプロイ モデルについて検討します。