マルチテナントアーキテクチャのコスト分析

SaaS on AWS を成功に導くためのポイントとは ? 第 8 回

2022-02-02
ビジネス x クラウド

青嶋 智久

こんにちは ! パートナーソリューションアーキテクトの青嶋です。
SaaS on AWS の連載も今回で 8 回目となり、2022 年最初の投稿となります !

今回はマルチテナントアーキテクチャのコスト分析について解説していきます。前回 はメトリクスの収集と可視化を解説しましたが、コスト分析はメトリクス活用における重要なテーマの一つになります。マルチテナントアーキテクチャの SaaS を展開するにあたり、テナントごとに掛かるコストを把握することは重要です。どのテナントにどれだけのコストが掛かるのかを把握することは、適切な顧客に適切なコストでサービスを提供することに繋がります。

マルチテナントアーキテクチャのコスト構造を把握するためには、抑えておくべきポイントがあります。マルチテナントアーキテクチャでは、複数のテナントが共通の AWS リソースを使用します。しかし AWS からの請求を確認しただけでは、各テナントにどれだけのコストが掛かっているのかを一概に判断することはできません。テナントごとのサービス使用状況と、AWS からの請求を関連付けることで、マルチテナントアーキテクチャーのコスト構造を定量的に把握することができるようになります。

本稿では、なぜテナントのコストを把握するべきなのか、どのようにマルチテナントアーキテクチャのコスト分析を実現するのかを説明します。

この連載記事のその他の記事はこちら

選択
  • 選択
  • 第 1 回 SaaS on AWS を成功に導くためのポイントとは ?
  • 第 2 回 SaaS ビジネスの成否を分けるテナント分離戦略
  • 第 3 回 動的なポリシー生成を使ったテナント分離
  • 第 4 回 SaaS on AWS における認証認可の実装パターンとは ?
  • 第 5 回 SaaS におけるオンボーディングとは ?
  • 第 6 回 SaaS におけるデータパーティショニング設計の勘所
  • 第 7 回 SaaS におけるメトリクスの取得と可視化
  • 第 8 回 マルチテナントアーキテクチャのコスト分析
  • 第 9 回 SaaS における料金プランとメータリング、ビリング
  • 最終回 AWS と始める SaaS 化への道

なぜテナントごとのコストを把握するべきなのか

複数のテナントが AWS リソースを共有するマルチテナントアーキテクチャでは、各テナントがどれだけの AWS リソースを使っているかを一概に判断することはできません。コンピュートやデータベース、ネットワークを複数のテナントで共有することがあります。マルチテナントアーキテクチャのコスト構造を「ブラックボックス」のままにしておくと、テナントごとにどれだけのコストが掛かっているか判断しづらいといった特徴があります。

またテナントごとのコストを把握できないということは、ティアのコスト構造を、定量的に判断できないといった課題もあります。ティアというのは、例えば利用頻度の高いテナントや基本機能のみを利用するテナントなど、テナントを階層化したグループに振り分けたものです。多くの SaaS の場合、各ティアで異なる契約プランを提供しています。例えば、制限付きの機能を無料で提供する Free ティア、基本的な機能を有料で提供する Standard ティア、より高付加価値な機能を提供する Professional ティアなどです。Free ティアを提供することで、導入までのハードルを下げて、Free ティアの投資を Standard ティアと Professional ティアの収入で回収する価格戦略になります。

このような価格戦略の場合、サービス全体としてティアごとにどれだけコストが掛かっているかを把握し、アーキテクチャの最適化をすることが必要です。例えば新しい機能の追加を検討する際に、コスト戦略の目線から Professional ティアのみに対して新機能を提供するといった議論ができます。また、アーキテクチャ改善を検討する際には、コスト削減効果の大きい、ティアを跨いだ共通の機能から優先して取り組もうといった議論が考えられます。

マルチテナントアーキテクチャのコスト分析を実現することで、このようなテナントごとのコストの把握や、アーキテクチャ改善の投資対効果を具体的に議論できるようになります。しかし、マルチテナントアーキテクチャのコスト分析を行うためには、2 つの課題があります。

1 つ目は、マルチテナントアーキテクチャを構成する AWS リソースのコストを、どのような方法で分けるかという点です。例えば EC2 インスタンスをサーバーとして利用する場合、リクエストを処理するために CPU、メモリ、I/O などの性能を複合的に消費します。また必ずしも EC2 インスタンスの性能全てを、リクエストの処理に用いているとも限りません。リクエストが少なければ1リクエストあたりのコストは相対的に高くなります。

2 つ目はテナントとの関連付けです。テナントごとの内訳は AWS からの請求に含まれていないため、各テナントが AWS リソースのコストをどれだけ消費するかを、何かしらの方法で関連付ける必要があります。


コスト分析のアプローチ

マルチテナントアーキテクチャのコスト分析でよく用いられるアプローチは、テナントごとのコストを、間接的な指標から計算することです。間接的な指標から各テナントのサービスの使用率を求め、テナントごとにサービスをどれだけの割合で使用したかを推測します。そして各テナントのサービスの使用率を用いて、サービスを構成する AWS リソースのコストを各テナントに按分します。

ではこのサービスの使用率ですが、何を元にサービスの使用率を推測するのが良いでしょうか。ポイントは、サービスの特性やコストへの影響を考慮し、手間になり過ぎない妥当な指標を選択することです。

こちらの図は、クライアントからリクエストを受け取った Compute サービスが、Database サービスのデータを参照するアーキテクチャを単純化したものです。

このアーキテクチャは、複数のテナントで Compute サービスと Database サービスを共有しています。Compute サービスではリクエストを処理する CPU の負荷が、Database サービスではデータのリクエスト単位の増加が、コスト増加の主要な要因です。このようなケースの場合、Compute サービスではリクエスト/レスポンスの処理時間を、Database サービスではデータの読み込み/書き込み量を、間接的な指標として使うことで、テナントごとのサービスの使用率を推測することができます。もし妥当だと考えられる代わりの指標 (リクエスト数など) があれば、そちらを使っていただいても問題ありません。

テナントごとのサービスの使用率を推測できたら、次に各テナントが負担するコストを計算していきます。

こちらの表は、テナントごとの Compute サービスと Database サービスの使用率と、AWS からの請求から、各テナントのコストを計算する例です。

推測したテナントのサービスの使用率と、AWS からの請求を関連付けることで、各テナントのコストを計算します。例えば Compute サービスで考えてみましょう。Tenant A の Compute サービスの使用率は 36% です。そのため AWS から請求された Compute サービスのコスト 300,000 円のうち、36% にあたる 108,000 円が Tenant A の Compute サービスのコストになります。一方の Database サービスのコストに関しても同様に、各サービスに対して各テナントのサービスの使用率を掛け合わせることで計算が可能です。

各テナントのコストは、計算したサービスのコストを合計することで求めることができます。上表から Tenant A に割り当てられるコストは、Compute サービスのコスト 108,000 円と、Database サービスのコスト 23,000 円を合計した 131,000 円 になります。

抑えておきたいポイントとしては、このテナントごとのコストをそのまま課金モデルに紐付けないことです。例えばそのテナントはどのティアに属するのか、そのティアのコスト戦略は何なのかでコストの受け止め方は変わってきます。また Free ティアであれば、顧客獲得の投資として、Free ティア単独で回収しなくてよいコストと解釈することができます。一方で Standard ティアや Professional ティアであれば、利益を生み出すためのコストとして、Standard ティアや Professional ティアの利益が、Free ティアを含むサービス全体のコストをカバーできているか考慮する必要があります。


コスト分析を実現する例

次に、マルチテナントアーキテクチャのコスト分析を実現する例を紹介します。

こちらの図は、メトリクスを通じて、サービスの使用率を推測する元となる指標を取得する例です。

Compute サービスのリクエスト/レスポンスの処理時間を使って、Compute サービスの使用率を推測してみます。Compute サービスは Amazon EC2、Database サービスは Amazon DynamoDB で構成されています。このとき必要になるメトリクスは、どのテナントが、どの AWS リソースに対して、どれだけの処理時間を消費したかです。上の図では Amazon EC2 から、TenantId, ResouceId, StartTime, EndTime をメトリクスとして発行しています。メトリクスでは、各テナントがどれだけ Compute サービスを使用したかを関連付けることで、各テナントの Compute サービスの使用率を計算できるようにしています。メトリクスの収集に関しては、前回 の連載をご参考ください。

メトリクスを収集したところで、次に Compute サービスの使用率を AWS からの請求と結び付け、各テナントの Compute サービスのコストがいくらかを計算します。ここでは、AWS Application Cost Profiler を使う例を紹介したいと思います。Application Cost Profiler は、メトリクスからAWSリソースの使用率を計算し、テナントごとのコストをレポートとして出力できるマネージドサービスです。

下の図は、Application Cost Profiler を使って、取得したメトリクスからコストのレポートを出力する例です。

メトリクスのデータを CSV ファイルで Amazon S3 に配置し、配置した CSV ファイルを Application Cost Profiler で分析することで、コストのレポートを Amazon S3 に出力します。例えば Compute サービスなら、Application Cost Profiler は、Compute サービスのリクエスト/レスポンスの処理時間に応じて、Compute サービスの使用率を計算し、テナントごとの Compute サービスのコストを計算します。

下の CSV 出力は Application Cost Profiler から Amazon S3 に出力されるレポートの例です。 

PayerAccountId UsageAccountId LineItemType UsageStartTime UsageEndTime ApplicationIdentifier TenantIdentifier TenantDescription ProductCode UsageType Operation ResourceId ScaleFactor TenantAttributionPercent UsageAmount CurrencyCode Rate TenantCost Region
123456789,123456789,Usage,2021-02-01T00:30:00.000Z,2021-02-01T01:00:00.000Z,Canary,100,ExampleApp,AmazonEC2,BoxUsage:c5.large,RunInstances,i-0123abcd456efab12,1,0.5,0.5,USD,0.085,0.0425,us-east-1
123456789,123456789,Usage,2021-02-01T01:00:00.000Z,2021-02-01T02:00:00.000Z,Canary,103,ExampleApp,AmazonEC2,BoxUsage:c5.large,RunInstances,i-0123abcd456efab12,0.25,1,0.25,USD,0.085,0.02125,us-east-1
123456789,123456789,Usage,2021-02-01T01:00:00.000Z,2021-02-01T02:00:00.000Z,Canary,102,ExampleApp,AmazonEC2,BoxUsage:c5.large,RunInstances,i-0123abcd456efab12,0.25,1,0.25,USD,0.085,0.02125,us-east-1
123456789,123456789,Usage,2021-02-01T01:00:00.000Z,2021-02-01T02:00:00.000Z,Canary,101,ExampleApp,AmazonEC2,BoxUsage:c5.large,RunInstances,i-0123abcd456efab12,0.25,1,0.25,USD,0.085,0.02125,us-east-1
123456789,123456789,Usage,2021-02-01T01:00:00.000Z,2021-02-01T02:00:00.000Z,Canary,100,ExampleApp,AmazonEC2,BoxUsage:c5.large,RunInstances,i-0123abcd456efab12,0.25,1,0.25,USD,0.085,0.02125,us-east-1

どのテナント (TnantIdentifier) の、どの AWS リソース (ResourceId) で、どれだけのコスト(TenantCost) が掛かっているかが出力されているのが確認できます。2 行目を見ると、TenantIdentifier 103 で、ResourceIdi-0123abcd456efab12TenantCost$ 0.02125 と計算結果が出力されています。

また Application Cost Profiler のレポートは CSV ファイルで出力されるため、Amazon AthenaAmazon QuickSight などの分析ツールを使って可視化することができます。

こちらの図は、Application Cost Profiler により出力されたレポートから QuickSight を使って可視化した例です。

マルチテナントアーキテクチャ全体のコスト (Total Cost) や、テナントごとのコスト (Tenant by Cost) が表示されているのが見て取れます。

簡単にコスト分析を始めたい場合には、Application Cost Profiler と QuickSight を使って可視化をするのがオススメです。そしてビジネスの成長に合わせて、サービスの使用率の集計や、コストのレポートをカスマイズする形で、より多元的で細かい可視化を検討していただければと思います。


まとめ

最後まで読んでいただき、ありがとうございます !
今回はマルチテナントアーキテクチャのコスト分析の必要性から、実現のポイントまでを解説しました。

SaaS 事業者は顧客に価値を届け続けるためにも、ビジネスを成長させ、サービスの改善を続けていく必要があります。マルチテナントアーキテクチャのコスト構造の把握は、新機能の検討や、アーキテクチャの改善を議論する際に、コスト面から効果を判断できる重要な材料となります。重要なのはコスト分析を実現する手間と、コスト分析から得られる価値のバランスを考慮することです。自分たちの目的に合った粒度でコストを把握することが大事ですので、厳密に分析しすぎる必要はありません。まずは小さく始めていただき、コスト分析の実証を繰り返すことで、自社の SaaS ビジネスに合ったコスト分析の戦略を見つけていきましょう。

それでは次回の連載もお楽しみに !

この連載記事のその他の記事はこちら

選択
  • 選択
  • 第 1 回 SaaS on AWS を成功に導くためのポイントとは ?
  • 第 2 回 SaaS ビジネスの成否を分けるテナント分離戦略
  • 第 3 回 動的なポリシー生成を使ったテナント分離
  • 第 4 回 SaaS on AWS における認証認可の実装パターンとは ?
  • 第 5 回 SaaS におけるオンボーディングとは ?
  • 第 6 回 SaaS におけるデータパーティショニング設計の勘所
  • 第 7 回 SaaS におけるメトリクスの取得と可視化
  • 第 8 回 マルチテナントアーキテクチャのコスト分析
  • 第 9 回 SaaS における料金プランとメータリング、ビリング
  • 最終回 AWS と始める SaaS 化への道

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

プロフィール

青嶋 智久
アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクト

モバイルアプリケーションエンジニアとしてキャリアをスタートする。その後、ウェブアプリケーション、Mobile Backend as a Service (MBaaS)、DevOps システムに携わり 2021 年にアマゾン ウェブ サービス ジャパン合同会社に入社。
現在は SaaS 担当のパートナーソリューションアーキテクトとして、主に ISV のお客様を支援。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する