多くの場合、マルチテナント ソリューションでコストを測定して割り当てるとき、およびコストを最適化するときには、特別な考慮が必要です。 このページでは、マルチテナント アプリケーションのコストの測定、割り当て、および最適化について検討するソリューション アーキテクト向けの重要なガイダンスについて説明します。
主な考慮事項と要件
ソリューションの使用量を測定するための要件を考慮してください。 詳細については、「各テナントの使用量を測定するを参照してください。
測定の目的
目標を決定することが重要です。 目標の例を次に示します。
- テナントごとに販売した商品の概算コストを計算する。 たとえば、かなりの数の共有リソースをデプロイする場合、各テナントにかかるコストの大まかな概算だけに関心がある場合があります。
- 各テナントで発生する正確なコストを計算する。 たとえば、発生した実際の消費量に対してテナントに課金する場合は、各テナントのリソースのコストに関する正確な情報が必要です。
- 他よりもコストが非常に高い外れ値テナントを特定する。 たとえば、 定額料金モデルを提供する場合、フェアユース ポリシーを適用できるように、プロビジョニング容量を他と比べて過剰に消費しているテナントがあるかどうかを判断する必要があります。 多くの場合、このユース ケースでは、正確なコストを測定する必要はありません。
- ソリューションの全体的な Azure コストを削減する。 たとえば、すべてのコンポーネントのコストを調べてから、ワークロードに対して過剰にプロビジョニングしているかどうかを判断することができます。
テナントの使用量を測定する目標を理解することで、コストの割り当てを概算にするか、非常に正確にする必要があるかどうかを判断できます。これは、使用可能な特定のツールや、実行できるプラクティスに影響します。
共有コンポーネント
テナントを共有インフラストラクチャに移行することで、マルチテナント ソリューションのコストを削減できる可能性があります。 ただし、リソースを共有することによる影響、たとえば、テナントで うるさい隣人問題が発生しないかなどを慎重に検討する必要があります。
また、共有コンポーネントのコストを測定して割り当てる方法についても考慮する必要があります。 たとえば、共有コンポーネントを使用する各テナント間で、コストを均等に分割することができます。 または、各テナントの使用状況を計測して、それらの共有コンポーネントの使用量をより正確に測定することもできます。
考慮すべきアプローチとパターン
リソース タグを使用したコストの割り当て
Azure を使用すると、 リソースにタグを適用できます。 タグはキーと値のペアです。 カスタム メタデータを追加するには、タグを使用します。 タグは多くの管理操作に役立ち、Azure の消費コストを分析する場合にも役立ちます。 タグを適用すると、 各タグに関連するコストを算出できます。
マルチテナント ソリューションでタグを使用する方法は、アーキテクチャによって異なる可能性があります。
ソリューションによっては、テナントごとに専用のリソースをデプロイすることがあります。たとえば、テナントごとに専用のデプロイ スタンプをデプロイする場合などです。 このような状況では、これらのリソースの Azure の消費量をそのテナントに割り当てる必要があることは明らかなため、Azure リソースにそのテナント ID をタグ付けすることができます。
他の状況では、共有リソースのセットがある場合があります。 たとえば、 シャーディング パターンを適用すると、複数のデータベースをデプロイし、それらにテナントを分散させることができます。 リソースにテナントの "グループ" の識別子をタグ付けすることを検討してください。 単一のテナントにコストを簡単に割り当てることができない場合がありますが、このアプローチを使用すると、少なくともテナントのセットにコストを絞り込むことができます。 また、特定のシャードで他よりも高いコストが発生していることに気づいた場合は、消費情報を使用してシャード全体でテナントのバランス調整をすることもできます。
注意
リソースに適用できる タグ数の制限 があります。 共有リソースを使用する場合は、リソースを共有するすべてのテナントにタグを追加しないことをお勧めします。 代わりに、シャード ID を持つタグを追加するか、テナントのグループを識別する別の方法を検討してください。
デプロイ スタンプ パターン と 垂直方向にパーティション分割されたテナント モデルを使用して構築されたマルチテナント ソリューションの例を考えてみましょう。 各デプロイ スタンプには、共有 Web サーバーとシャード化されたデータベースが含まれています。 タグは、次の図に示すように、各 Azure コンポーネントに適用できます。
ここで使用するタグ付け方法は次のとおりです。
- すべてのリソースに
stamp-idタグを付ける。 - すべてのシャード化されたデータベースに
shard-idタグを付ける。 - 特定のテナント専用のすべてのリソースに
tenant-idタグを付ける。
このタグ付け方法を使用すると、コスト情報を 1 つのスタンプに簡単にフィルター処理できます。 テナント C のデータベースの総コストなど、テナント固有のリソースのコストも簡単に見つけることができます。共有コンポーネントには tenant-id タグはありませんが、スタンプの共有コンポーネントのコストは、そのスタンプまたはシャードを使用するように割り当てられたテナント間で分割できます。
アプリケーションをインストルメント化する
Azure リソースとテナントの間に直接のリレーションシップがない場合は、テレメトリを収集するようにアプリケーションをインストルメント化することを検討してください。
アプリケーション層では、測定に関する次のような質問に答えるのに役立つログとメトリックが既に収集されている場合があります。
- テナントあたりとの API 要求のおおよその数は?
- 特定のテナントが最もビジーになるのは 1 日のうちどの時間帯か?
- テナント A の使用パターンとテナント B の使用パターンを比較するにはどうすればよいか?
Azure では、これらのメトリックは多くの場合 Application Insights によってキャプチャされます。 テレメトリ初期化子を使用すると、Application Insights によってキャプチャされたテレメトリをエンリッチし、テナント識別子またはその他のカスタム データを含めることができます。
ただし、Application Insights やその他のログおよび監視ソリューションは、正確なコスト測定や測定目的には適していません。 Application Insights は、特にアプリケーションに大量の要求がある場合に データをサンプリングするように設計されています。 テレメトリのすべての部分をキャプチャするとコストが高くなることが多いため、サンプリングはソリューションの監視コストを削減することを目的としています。
課金目的で消費量または使用量に関する正確な詳細を追跡する必要がある場合は、代わりに、必要なデータを記録するカスタム パイプラインを作成する必要があります。 その後、要件に基づいてデータを集計する必要があります。 この目的に役立つ Azure サービスには、大量のテレメトリをキャプチャする Event Hubs や、それをリアルタイムで処理する Stream Analytics などがあります。
Azure 予約と Azure 節約プランを使用してコストを削減する
Azure Reservations: Azure Reservations を使用すると、特定のレベルの支出を事前に約束することで、Azure のコストを削減できます。 予約は、多数の Azure リソースの種類に適用されます。
予約はマルチテナント ソリューションで効果的に使用できます。 次の考慮事項に注意してください。
- 共有リソースを含むマルチテナント ソリューションをデプロイする場合は、ワークロードに必要な使用量のベースライン レベルを検討してください。 そのベースライン消費量に対する予約を検討してください。予測不可能なピーク時に増えた消費量に対して、標準料金を支払うことになります。
- 各テナントにリソースをデプロイする場合は、特定のテナントまたはテナントのポートフォリオ全体のリソース消費量に事前にコミットできるかどうかを検討してください。
Azure Reservations を使用すると、 予約にスコープを設定 して、リソース グループ、サブスクリプション、またはサブスクリプションのセットに適用できます。 これは、複数のサブスクリプション間でワークロードをシャードする場合でも、予約を利用できることを意味します。
予約スコープは、予測できないワークロードを持つテナントがある場合にも役立ちます。 たとえば、テナント A が特定のリソースのインスタンスを 1 つだけ必要とし、テナント B と C がそれぞれ 2 つ必要とするソリューションを考えてみます。 その後、テナント B のビジー状態が減ったため、インスタンス数を減らし、テナント A がビジー状態になったため、インスタンス数を増やします。 予約がそれを必要とするテナントに適用されます。
コンピューティング用の Azure 節約プラン: コンピューティング用の Azure 節約プランは、従量課金制の料金よりも大幅に節約できる柔軟なコスト節約プランです。 1 年または 3 年契約に同意して、対象となるコンピューティング サービスの割引を受けられます。 これらのサービスには、仮想マシン、専用ホスト、コンテナー インスタンス、Azure Premium 関数、Azure アプリ サービスが含まれます。 リージョン、インスタンス サイズ、オペレーティング システムに関係なく、これらのコンピューティング サービスに節約が適用されます。 詳細については、 Azure 節約プランの概要 のページと Azure 節約プランのドキュメントを参照してください。
予約と節約プランの組み合わせ: コストと柔軟性をさらに最適化するために、Azure 節約プランを Azure 予約と組み合わせることができます。
回避すべきアンチパターン
- コストをまったく追跡しない。 少なくとも、発生しているコストと、各テナントがソリューションの提供コストにどのように影響するかについて、おおよその知識を持っていることが重要です。 そうしないと、時間の経過と共にコストが変化した場合に、比較するベースラインがありません。 また、テナントの増加がコストと収益性にどのような影響を与えるかを予測できない場合もあります。
- 想定または推測を行う。 実際の情報に基づいてコスト測定を行うようにしてください。 高レベルの精度は必要ないかもしれませんが、見積もりでも実際の測定値で行う必要があります。
- 不要な精度。 すべてのテナントに発生するすべてのコストの詳細な会計情報は必要がない場合があります。 不必要に正確なコスト測定および最適化プロセスを作成すると、エンジニアリングの複雑さが増し、不安定なプロセスとなるため、逆効果になるおそれがあります。
- リアルタイム測定。 ほとんどのソリューションには、最新のコスト測定は必要ありません。 計測と消費のデータは処理が複雑になる可能性があるため、必要なデータをログしてから、後で非同期でデータを集計して処理する必要があります。
- 課金用の監視ツールの使用。 「アプリケーションをインストルメント化する」で説明されているように、コストの監視と測定用に設計されたツールを使用するようにしてください。 アプリケーション監視ソリューションは、通常、この種類のデータには適していません。特に高い精度が必要な場合には適していません。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- John Downs | プリンシパル ソフトウェア エンジニア
その他の共同作成者:
- Sherri Babylon | FastTrack for Azure のシニア カスタマー エンジニア
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。