この記事について
AWSクラウドでマルチテナントのサービスとしてのソフトウェア（SaaS）アプリケーションのワークロードを設計、デプロイ、アーキテクトする方法に焦点を当てて解説されているものを読んだ備忘録。このドキュメントを読むと、SaaSアプリケーションのアーキテクチャを設計するときに使用するAWSのベストプラクティスと戦略を理解できる模様。AWS Well-Architected Framework の一種、その中の一部にフォーカスあてて解説するのが XXXX Lens シリーズぽい。
内容
できるようにしたいこと
マルチテナントの SaaS 事業者が テナントごとのリソース消費を測定し、アクティビティをインフラストラクチャコストと相関させること
unit metric
システムの効率を最もよく反映および測定する主要業績評価指標（KPI）を表す。システムの利用料増加が、システムの価値の増加によるものなのか、そうでないのものか(非効率な利用)がわかるようにする。
unit metric は2つの解釈ができる
- AWS 利用料 / 需要
- AWS リソース利用分 / 需要
これらは、デマンドドライバーの活動によって増減する。
デマンドドライバーはAWSの支出またはAWSのリソース消費に相関する要因。消費されるAWSリソースの量とそれらのリソースを利用するコストは、デマンドドライバーの増減によって直接影響を受ける。そのため、システムのデマンドドライバーが増えれば、AWS利用料は増えるのはの一定正しい。デマンドドライバーが一定なのにAWS利用料が増えるのは何か無駄なものを使っているかもしれない。
デマンドドライバーのコストの例として、Eコマースの cost / transaction が挙げられていた。
十分に機能する unit metric は、エンジニアリング、セールス、マーケティング、価格設定、および製品の各チームに共通の参照ポイントを提供し、IT運用に関連する粗利益が維持されるようにしてくれる
SaaS環境でのテナントコストの計算
-
コンピューティング使用量の計算
- API リクエストのログを集計してテナントごとの割合を算出する
-
ストレージの計算
- データのサイズとIOPSの両方が特定のテナントのコストにどのように影響するかを考慮する
- S3, RedShift など