416-AWS SAP AWS 「理論・実践・一問道場」RCU/WCU

type

status

date

slug

summary

理論

1. マルチテナント環境

マルチテナントとは、1つのシステムやアプリケーションインスタンスが複数の顧客（テナント）によって共有される設計モデルです。SaaS（Software as a Service）などで一般的に使われます。

各テナントは独立したデータを持ちながらも、同一のインフラを共有します。このため、リソースやコストの分配方法が重要です。

2. リソース消費の追跡とコスト配分

リソース消費の追跡: 各テナントが使用したリソース（ストレージ、コンピューティング、APIリクエストなど）を追跡することは、コスト管理に欠かせません。これを実現する方法として、リソースごとのメトリクス（例: RCU/WCU）やタグ付け、ログの記録が使われます。

コスト配分タグ: AWSでは、リソースごとにコスト配分タグを設定することで、サービスの使用に基づくコストを細かく分けて追跡することができます。これにより、特定のテナントや部門ごとのコスト分析が可能になります。

3. AWSのコスト管理ツール

AWS Cost and Usage Report (CUR): AWSアカウント内で使用されているすべてのサービスとリソースの使用状況やコストを詳細に把握できるレポートです。これを使用することで、テナントごとのコストを分けることが可能になります。

AWS Lambda: イベント駆動型のコンピューティングサービスで、APIリクエストなどに応じて動的にコードを実行できます。Lambdaを使ってリソース消費の追跡を実装し、他のサービスとの連携を簡素化できます。

Amazon CloudWatch: サーバーレスアーキテクチャの監視とログ管理のためのサービスで、リソース使用状況やメトリクスの監視に役立ちます。CloudWatchを活用して、リソース使用量（例: RCU/WCU）を詳細に記録し、リアルタイムで監視できます。

AWS Cost Explorer: コスト分析と予測のためのツールで、AWSリソースの使用状況に基づいて、どのサービスやリソースが最もコストを発生させているかを視覚的に表示します。

4. 自動化の重要性

コスト管理とリソース追跡のプロセスを自動化することが、運用コストの削減やエラー防止に繋がります。例えば、Amazon EventBridgeを使用して定期的にLambda関数を実行し、コスト計算を自動化する方法があります。

サーバーレスアーキテクチャ（Lambdaなど）は、従来のインフラ管理を軽減し、リソース消費の計測やコスト計算を効率化する手段となります。

5. コスト計算のアプローチ

テナントごとのリソース消費を追跡する際、キャパシティユニット（RCU/WCU）やデータトランザクション、ストレージ使用量を基にコストを分配します。

複雑な計算を実現するためには、適切なツールを使用して、リソースごとの詳細な分析を行う必要があります。

このような知識を基に、SaaS企業でのコスト管理を最適化し、テナントごとのコストを正確に追跡することができます。

実践

略

一問道場

質問 #416

ソフトウェア・アズ・ア・サービス（SaaS）企業がマルチテナント環境を開発しました。同社は、ストレージ層としてテナントが共有するAmazon DynamoDBテーブルを使用しています。また、アプリケーションサービスにはAWS Lambda関数を使用しています。

同社は、各テナントのリソース消費量に基づいた階層型サブスクリプションモデルを提供したいと考えています。各テナントは、Lambda関数への各リクエストの一部として送信される一意のテナントIDによって識別されます。同社はAWSアカウントでAWSコストと使用状況レポート（AWS CUR）を作成しました。また、DynamoDBのコストを各テナントのリソース消費量に応じて割り当てたいと考えています。

どのソリューションが最小の運用コストで、各テナントごとのDynamoDBコストを詳細に把握できるようにしますか？

選択肢

A. DynamoDBの各テーブルに「tenant ID」という名前の新しいタグを関連付けます。このタグをAWS課金とコスト管理コンソールでコスト配分タグとして有効化します。テナントIDをAmazon CloudWatch Logsに記録するように新しいLambda関数コードをデプロイします。AWS CURを使用して、各テナントIDのDynamoDB消費コストを分離します。

B. Lambda関数を設定して、DynamoDBから各トランザクションで消費されたRCU（読み取りキャパシティユニット）とWCU（書き込みキャパシティユニット）およびテナントIDをAmazon CloudWatch Logsに記録します。記録されたキャパシティユニットとAWS Cost Explorer APIの全体のDynamoDBコストを使用してテナントコストを計算する別のLambda関数をデプロイします。Amazon EventBridgeルールを作成し、この計算用Lambda関数を定期的に起動します。

C. DynamoDBアイテムを個々のテナントと関連付ける新しいパーティションキーを作成します。各トランザクションの一部として新しい列を入力するLambda関数をデプロイします。また、Amazon Athenaを使用してDynamoDBからテナントアイテム数を計算し、AWS CURの全体的なDynamoDBコストを使用してテナントコストを計算する別のLambda関数をデプロイします。Amazon EventBridgeルールを作成し、この計算用Lambda関数を定期的に起動します。

D. Lambda関数をデプロイして、テナントID、各レスポンスのサイズ、およびトランザクション呼び出しの期間をカスタムメトリクスとしてAmazon CloudWatch Logsに記録します。CloudWatch Logs Insightsを使用して、各テナントのカスタムメトリクスをクエリします。AWS Pricing Calculatorを使用してDynamoDB全体のコストを取得し、テナントコストを計算します。

解説

選択肢Bが適切な理由について詳しく説明します。

理由:

選択肢Bでは、DynamoDBから消費されたRCU/WCU（読み取りキャパシティユニット/書き込みキャパシティユニット）とテナントIDをCloudWatch Logsに記録し、それをもとに別のLambda関数でテナントごとのコストを計算するというアプローチです。この方法は、以下の点で優れています：

リソース消費の正確な追跡: DynamoDBのキャパシティユニット（RCU/WCU）の消費をCloudWatchに記録することで、リソース消費量に基づく正確なコスト計算が可能になります。これにより、テナントごとのリソース使用量を詳細に把握できます。

自動化: 計算を自動化するために、Amazon EventBridgeルールを使って定期的にLambda関数を実行する設定が可能です。これにより、手動で計算を行う必要がなく、運用の手間が大幅に削減されます。

AWS Cost Explorerとの統合: AWS Cost Explorer APIを使用して、DynamoDB全体のコストを取得し、それを基にテナントごとのコストを計算します。このように、コストデータを統合的に使用することで、全体的なコスト管理と分析が効率化されます。

他の選択肢との比較:

選択肢Aも有効ですが、タグ付けとAWS CURの使用だけでは、テナントごとの詳細なリソース消費を反映することはできません。リソース消費に基づく詳細な計算が難しく、テナント別のコスト分析には不十分な場合があります。

選択肢Cや選択肢Dは、AthenaやCloudWatch Logs Insightsなどを使用するため、計算やデータ処理の手間が増える可能性があり、運用コストが高くなる可能性があります。

したがって、選択肢Bは、最小の運用コストで、かつテナントごとのDynamoDBコストを詳細に把握する最適な方法と言えます。