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

推測したテナントのサービスの使用率と、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 に出力されるレポートの例です。 

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

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

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

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

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

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

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

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