AWS Well-Architected FrameworkのSaaS Lensを1ページで眺められるようにまとめた

AWS Well-Architected FrameworkのSaaS Lensを1ページで眺められるようにまとめた

#AWS Well-Architected Framework
#AWS Well-Architected Tool
#SaaS
#AWS
hayashi.masaya

hayashi.masaya

facebook logohatena logotwitter logo
Clock Icon2022.05.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは。大阪オフィスの林です。

AWS Well-Architected Frameworkで用意されているSaaS Lensを眺める機会があったのですが、各設問の内容を見る際に何度もページを行き来したり、リファレンスを行き来しているうちに現在地が分からず少々混乱してしまうことがありました。
どうしても1つのページで「全ての設問」「ベストプラクティス」「改善計画」を眺められるようなページが欲しかったのでサマってみました。

サマる前に

先に全体のボリュームがどの程度か把握しておきたいと思います。
結論、AWS Well-Architected Frameworkで用意されているSaaS Lensの設問数としては全部で「14個」です。（ちょっと頑張ればギリギリ読めそうなボリューム感）
各柱で用意されている設問数は下記の通りです。

柱 設問数
運用上の優秀性の柱 4個
セキュリティの柱 2個
信頼性の柱 3個
パフォーマンス効率の柱 3個
コスト最適化の柱 2個
持続可能性の柱 0個
合計 14個（執筆時点）

サマってみた（設問のみ版）

どんな設問が用意されているかのみ把握したい場合はココだけ読んでください。
より詳細な概要、ベストプラクティス、改善計画を確認したい場合は後半の詳細版も見ていただければと思います。

運用上の優秀性の柱

  • SaaS OPS 1
    • マルチテナント環境の運用状態をどのように効果的にモニタリングおよび管理していますか?
  • SaaS OPS 2
    • 個々のテナントの使用状況と消費傾向の分析に使用できるメトリクスデータをどのように取得し、特定していますか?
  • SaaS OPS 3
    • 新しいテナントはどのようにシステムにオンボードされますか?
  • SaaS OPS 4
    • テナント固有のカスタマイズのニーズにどのように対応しますか?

セキュリティの柱

  • SaaS SEC 1
    • テナントコンテキストをどのようにユーザーに関連付け、そのコンテキストを SaaS アーキテクチャ内で適用していますか?
  • SaaS SEC 2
    • テナントリソースがクロステナントアクセスから保護されることをどのように確認していますか?

信頼性の柱

  • SaaS 信頼性 1
    • 個々のテナントがシステム内の他のテナントの可用性に影響を与える可能性がある負荷をかけることをどのように制限しますか?
  • SaaS 信頼性 2
    • テナントの健全性をどのように積極的に検知および維持しますか?
  • SaaS 信頼性 3
    • SaaS アプリケーションのマルチテナント機能をどのようにテストしていますか?

パフォーマンス効率の柱

  • SaaS PERF 1
    • あるテナントが別のテナントの体験に悪影響を与えることを防ぐにはどうすればいいのでしょうか?
  • SaaS PERF 2
    • インフラストラクチャリソースの消費とテナントのアクティビティやワークロードを調整するにはどうしたらよいですか?
  • SaaS PERF 3
    • テナントの階層やプランによって異なるパフォーマンスレベルを可能にするにはどうすればよいですか？

コスト最適化の柱

  • SaaS COST 1
    • 個々のテナントのリソース消費はどのように測定されますか?
  • SaaS COST 2
    • テナントの消費とインフラストラクチャのコストはどのように関連付けられますか?

サマってみた（詳細版）

ここからはSaaS Lensで用意されている各設問の概要、ベストプラクティス、ベストプラクティスに近付けるための改善計画をサマっていきます。

SaaS OPS 1: マルチテナント環境の運用状態をどのように効果的にモニタリングおよび管理していますか?

  • 概要
    • マルチテナント環境では、テナントを意識したシステムの全体的なアクティビティと状態の把握が可能な堅牢な運用ツールが必要です。
    • SaaSチームは、テナントの消費量、アクティビティ、稼働状況の傾向をシステムの運用経験に加えることで、テナントとテナント層の状況をより効果的に把握、分析、評価できるようになります。
  • ベストプラクティス
    • アプリケーションログにテナントコンテキストを含めます。
      • 運用ツールはログアクティビティを集約し、運用チームがシステム、個々のテナント、テナント層の健全性とアクティビティを検査できるようにします。
    • テナントに関する詳細な情報を収集します。
      • SaaSアプリケーションにインスツルメンテーションを追加し、テナントのアクティビティ、健全性、および消費傾向の詳細な運用分析を可能にする、詳細なテナントインサイトのコレクションを出力できるようにします。
    • 運用チームは、ビジネスインテリジェンス（BI）ツールを使用して、テナント情報を含むデータを分析します。
      • テナントのワークロードをプロアクティブに管理できるように、テナントを意識した専用のツールを使用します。
      • テナントの詳細な運用データを提供するツールを使用することで、運用チームはテナントや階層に応じたアクティビティ、消費量、健全性を分析、評価できるようになります。
      • これらのツールにより、プロアクティブなポリシーとアラームの実装が可能になります。
  • 改善計画
    • アプリケーションログにテナントコンテキストを含めます。
      • ログ記録フレームワークにラッパーを導入し、テナントコンテキストを取得し、このコンテキストを各ログメッセージに挿入する。運用コンテキストに重要なテナント属性があれば、それを埋め込みます。
      • ログメッセージにテナント識別子と、可能であればユーザーフレンドリーなテナント名を含めることで、運用チームがログエントリを特定のテナントと容易に関連付けることができるようにします。
      • このテナントコンテキストを利用して、管理者がログ分析ツールでテナントコンテキストを使用してログを分析できるようにし、運用体験を効率化します。 Amazon Elasticsearch Service (Amazon ES)/Kibana または Amazon Athena などのソリューションを活用して、ログデータを探索し、テナントの傾向を分析し、テナントに関する詳細なインサイトを収集します。
    • テナントワークロードの運用ビューを強化するインサイトを発行します。
      • テナントのアクティビティ、使用状況、および消費に関する詳細なメトリクスをアプリケーションに組み込み、運用の俊敏性と効率性を形成します。
      • 管理者がマルチテナントのワークロードを効果的に分析および管理できるように、テナントのレイテンシー、潜在的なボトルネック、および機能の消費を表示するメトリクスを追加します。
      • テナントのカスタムメトリクスをAWSのメトリクスで補強し、オペレータがテナントとシステムのアクティビティを統一的に把握できるようにします。
      • テナント・メトリクスの情報を集約して、トレンドの履歴分析を可能にし、将来のアーキテクチャと運用戦略を形成するための洞察を提供します。 テナントを意識した専用ツールを使用して、テナントのワークロードをプロアクティブに管理することができます。
    • テナントを意識した専用ツールを使用し、テナントのワークロードをプロアクティブに管理可能にします。
      • マルチテナント対応ダッシュボードを作成します。
        • Amazon QuickSightまたはサードパーティのBIツールを使用して、マルチテナント対応のカスタムダッシュボードを作成し、運用チームがテナントのアクティビティ、トレンド、消費量、エラーなどのビューを簡単に作成できるようにします。テナントとテナント属性を運用エクスペリエンスにおける第一級オブジェクトとします。
        • 運用エクスペリエンスに分析を組み込むことで、テナントのインサイトと、階層や役割などの主要なテナント属性に基づいて、テナントのワークロードを動的に分析できるようになります。
      • 運用によるテナントアラートとアラームの設定を可能にします。
      • テナントの消費量、アクティビティ、SLA メトリクスの特定のパターンを特定し、それらを組み合わせてテナントの健全性に関する問題をプロアクティブに特定できます。
      • テナントが特定の稼働状態または性能上の閾値に達したときにトリガーされるアラートおよびアラームを設定します。
  • リファレンス

SaaS OPS 2: 個々のテナントの使用状況と消費傾向の分析に使用できるメトリクスデータをどのように取得し、特定していますか?

  • 概要
    • SaaS環境からテナント対応のメトリックデータを公開および集約して、SaaS組織内のさまざまな役割の人で利用できるようにします。
    • これにより、ビジネスチームと技術チームの両方にとって不可欠な、主要な使用状況とアクティビティのトレンドに即座にアクセスできるようになります。
    • このデータは、アーキテクチャ戦略、価格設定モデル、製品ロードマップ、および運用効率の改善に使用されます。
  • ベストプラクティス
    • 忠実度の低いテナントアクティビティメトリクスをキャプチャします。
      • 最小限の設定で、すぐに利用できるアプリケーションとシステムの情報を取得し、表示することができるパッケージ化されたフレームワークとツールを使用し、可能であればテナントのコンテキストを挿入します。
    • テナントを意識したメトリクスを使用して、システムの重要度の高いワークフローを測定します。
      • システムの価値の高い箇所を対象に、ワークフローとユースケースに関するインサイトを提供するメトリクスを設定し、価値の高い対象者の顧客体験と消費パターンを理解するために不可欠なインサイトを提供します。
      • 分析ツールを使用して、運用上重要なデータを分析し、可視化します。
    • テナントの消費に関する完全なビューを作成します。
      • SaaSアプリケーションは、テナントのアクティビティ、機能の使用状況、リソースの消費状況など、さまざまなイベントを把握するための指標を完全に備えています。
      • これらのメトリクスにより、プロダクトマネージャー、アーキテクト、運用チームは、このデータの分析ビューを構築し、技術的およびビジネス的な意思決定を行うことができます。
  • 改善計画
    • 忠実度の低いテナントアクティビティメトリクスを取得します。
      • ウェブアプリケーションにWeb解析を導入し、テナントのアクティビティデータを取得することで、SaaSアプリケーションの機能へのアクセスや消費のパターンを分析することができます。
      • AWS X-Rayまたはobservabilityフレームワークを使用して、テナントのコンテキストでリクエストアクティビティをキャプチャして公開します。
      • Web解析のリクエスト追跡データを集計し、テナントがフロントエンドとバックエンドのサービスをどのように消費しているかを示すビューを作成します。
      • 集計されたメトリックデータをウェアハウス（Amazon RedshiftまたはAmazon S3など）に保存し、プロダクトマネージャー、運用チーム、アーキテクト、ビジネスリーダーがBIツール（Amazon QuickSightなど）を活用して、ビジネス戦略や技術戦略に役立つトレンドを分析できるようにします。
    • テナントを意識したメトリクスでシステムの価値の高いワークフローを構築します。
      • テナントアクティビティと消費メトリクスの計測を導入することで、情報を収集し、主要なビジネス戦略または技術戦略に反映させることができます。
      • すべてのテナント・メトリクス・データの統一ビューを収容する単一のリポジトリで、詳細なメトリクスを公開します。これらのメトリクスを使用して、テナント・アクティビティの充実したビューを構築します。
      • AWSによるデータ集計では、Amazon Kinesis Data Firehoseを使用して、Amazon RedshiftまたはAmazon S3にメトリクスを配信することができます。
    • テナント消費に関する完全なビューを作成します。
      • アプリケーションのサービスとエクスペリエンスの全領域をカバーするメトリクスを公開します。メトリクスを導入し、それらを使用して、テナントが消費しているリソースとサービスの詳細なプロファイルを構築し、エンドツーエンドのエクスペリエンスを要約するパフォーマンス・データを提供します。
      • ドメインの構成要素に相関する複合メトリクスを公開する。このためには、一般的なメトリクス・データ（ストレージ、コンピュート、レイテンシーなど）を組み合わせて、ビジネスにとってより意味のある単一のメトリクスを作成する必要があるかもしれません。
      • SaaS 環境からビジネスメトリクスを発行し、組織のアジリティ、イノベーション、および運用の成功に不可欠なトレンドに関する情報を得ることができます。
      • ビジネス全体のアジリティを反映するデータを取得し、公開します。メトリクスは、テナントに関するものよりも、運用のトレンドに関するものです。
      • 一般的に収集すべき指標には、サイクルタイム、可用性、リリース頻度、平均検出時間（MTTD）、平均回復時間（MTTR）、不具合脱出率などがあります。
      • オンボーディングされたテナント数、新しいテナント環境のプロビジョニング時間など、テナントオンボーディングの効率性を測定できるデータを収集します。
      • 新規テナントのTime to Valueに関する情報や、アクティビティのレベルが低い更新候補を特定するメトリクスなど、カスタマーサクセスエクスペリエンスを促進するためのデータを取得します。
      • ビジネスイベントによって引き起こされることの多いテナントの状態の変化に関するデータを公開します（特に、テナントの状態（アクティブ/非アクティブ）やティアの変更時）。
      • 詳細な測定基準を単一のリポジトリに集約し、すべてのテナント測定基準データを統一的に表示する。ビジネスチームと技術チームがBIツールを使用して、それぞれのニーズに最も適したデータの分析ビューを作成できるようにします。
      • AWSによるデータ集計では、Amazon Kinesis Data Firehoseを使用して、Amazon RedshiftまたはAmazon S3にメトリクスを配信することができます。
  • リファレンス

SaaS OPS 3: 新しいテナントはどのようにシステムにオンボードされますか?

  • 概要
    • 新しいテナントをシステムに導入する際には、自動化された再現性のあるプロセスを使用します。
    • このプロセスには、インフラストラクチャ、テナント、ユーザーID、隔離ポリシー、課金、テナント設定など、新しいテナントを導入するために必要なすべての手順が含まれます。
    • ここでの負担を軽減することで、運用の効率化と組織の俊敏性を高めることができます。
  • ベストプラクティス
    • 手動で起動するスクリプトを使用してテナントをプロビジョニングします。
      • 新しいテナントの導入に必要なすべてのステップは、テナントフットプリントのすべての要素（インフラストラクチャ、テナント、管理ユーザーなど）をプロビジョニングする1つまたは複数の自動化スクリプトによって実行されます。
    • 単一の自動化されたプロセスを使用してテナントをオンボーディングします。
      • 新しいテナントのオンボーディングは、手動による介入なしにエンドツーエンドで実行される単一の自動化プロセスによってトリガーされ、実行されます。
    • テナントプロビジョニングの設定と実行を完全に自動化した、セルフサービス型のユーザーエクスペリエンスを提供します。
      • ユーザー（社内または顧客）は、オンボーディングプロセスを開始する前に、すべての設定データを収集して登録フォームに記入します。このプロセスでは、新しいテナントをシステムに導入するために必要なオンボーディングステップを実行します。
  • 改善計画
    • テナントのプロビジョニングに手動でトリガーしたスクリプトを使用します。
      • 運用チームは、ランブックと1つまたは複数のスクリプトを使用して、新しいテナントをプロビジョニングします。
        • 各テナントに必要なインフラリソースのプロビジョニングには、自動化が使用されます。
        • 自動化は、新しいテナントの作成と構成に使用されます。
        • 自動化は、テナントの管理ユーザーを導入するために使用されます。
        • 自動化により、各テナントに必要な隔離ポリシーが構成されます。
        • 課金システムが統合されている場合は、課金システムに新しいアカウントをプロビジョニングするために自動化が使用されます。
        • スクリプトとスモークテストを使用して、プロビジョニングプロセスの終了時にテナントが健全な状態であることを検証します。
        • 単一の自動化されたプロセスを使用してテナントをオンボードします。
    • 運用チームは、新しいテナントに必要なすべての設定データを収集します。
      • オペレーションチームは、新しいテナントをシステムに導入するために必要なすべてのコンストラクトを構成し、プロビジョニングするために、単一のスクリプトを起動します。
      • オンボーディングスクリプトの最後には検証ステップが実行され、オンボーディングプロセスによってテナントが正常に動作する状態になったことが確認されます。
      • オンボーディングスクリプトは、オンボーディングに関する問題の分析とトラブルシューティングに使用できるテナントを意識したログを発行します。
      • テナントプロビジョニングの設定と実行を完全に自動化した、セルフサービス型のユーザーエクスペリエンスを提供します。
    • ユーザー（社内外）には、新しいテナントのオンボーディングに必要なすべてのデータと設定オプションを収集するガイド付きのユーザーエクスペリエンスを提供します。
      • オンボーディングサービスは、新規テナントの受け入れに関するすべての可動部を調整し、プロビジョニングプロセスの各ステップを追跡して、操作体験の一部として表示可能な進捗データを表示します。
      • 課金システムの場合、課金アカウントをプロビジョニングするためのフォールトトレラントなプロセスがサポートされます。このプロセスが失敗しても、オンボーディングプロセス全体が失敗するわけではありません。その代わり、再試行により最終的に課金アカウントが作成されます。
      • オンボーディングプロセスによってメトリクスが表示され、オンボーディング体験の全体的なパフォーマンスと信頼性に対する洞察を提供します。
  • リファレンス

SaaS OPS 4: テナント固有のカスタマイズのニーズにどのように対応しますか?

  • 概要
    • SaaSビジネスは、単一の画面を通してすべての顧客を管理・運用することによる業務効率化を重要視しています。
    • 俊敏性と効率性を維持するために、SaaS企業はすべてのテナントが利用できる共通の仕組みを通じてすべてのカスタマイズを導入し、テナントごとに個別の環境やバージョンを展開・管理する必要性を省きます。
  • ベストプラクティス
    • テナントのバリエーションを管理するために機能フラグを使用します。
      • テナントごとに有効・無効となるフラグを導入することで、機能バリエーションを提供します。
    • 共有アプリケーションのカスタマイズにより、テナント固有の要件を提供します。
      • テナント構成プロセスの一部として構成される一般的なアプリケーションカスタマイズ構造を導入することで、バリエーションの要求に対応します。
  • 改善計画
    • テナントのバリエーションを管理するための機能フラグを使用します。
      • アプリケーションの設計に機能フラグを導入することで、テナントごとに個別の機能を実行できるようになります。
      • 機能フラグをテナントに関連付けるための一元的な仕組みを提供し、1つのプロセスで機能を有効化および無効化できるようにします。
        • テナント管理機能の一部として機能フラグを保存し（Amazon DynamoDBを使用）、これらのフラグをIDプロバイダーに伝達し、カスタムクレームとして保存します。
        • アプリケーションサービスに提供されるトークンに組み込まれた機能フラグを使用することで、フラグ取得のために別のサービスを呼び出すことに関連するオーバーヘッドを発生させずに、サービスが機能フラグにアクセスし適用することができます。
    • 共有アプリケーションのカスタマイズによるテナント固有の要件をサポートします。
      • すべてのテナントカスタマイズをコアアプリケーションの拡張機能として導入し、カスタマイズをすべてのテナントに提供できるようにします（たとえそれが1つのテナントにしか必要ない場合でも）。
      • すべてのテナントに対して1つのデプロイメントをサポートし、設定、ビルド、デプロイの各プロセスで、1つのテナントに必要なカスタマイズ・オプションを適用します。
      • テナントのカスタマイズを管理するために使用される一元的な構造を作成します。
      • カスタマイズとテナントが購入できるサブスクリプションまたはプランの間に相関関係がある場合、これらのオプションを購入すると、所定のプランに関連付けられるようにします。
  • リファレンス

SaaS SEC 1: テナントコンテキストをどのようにユーザーに関連付け、そのコンテキストを SaaS アーキテクチャ内で適用していますか?

  • 概要
    • SaaSアーキテクチャは、ユーザーのアイデンティティとテナントのアイデンティティを適切に関連付ける必要があります。
      • このSaaSアイデンティティは、SaaS環境でのユーザーのすべてのやり取りに対して関連付けられている必要があります。
      • システムのパフォーマンスを損なう可能性のあるオーバーヘッドを導入することなく、アプリケーションのすべてのサービスにわたってこのコンテキストを解決する必要があります。
  • ベストプラクティス
    • アプリケーションサービスを使用して、統一されたSaaSアイデンティティを生成します。
      • SaaSアプリケーション・サービスは、ユーザーをテナントにマッピングし、後方のサービスに渡すことができるユーザー/テナント・アイデンティティの単一の表現を生成します。
    • IDプロバイダーを使用して、ユーザーとテナントを関連付けます。
      • IDプロバイダーは、ユーザーとテナントの両方のデータを管理し、これら2つの要素を含む単一の認証情報を返します。
      • この統一された情報がすべてのサービスに伝達されるため、個別のサービスを通じてテナントのコンテキストを解決する必要がなくなります。
    • 開発者の目に触れないところでテナントコンテキストを適用するライブラリやフレームワークを作成します。
      • 各サービスに渡されるテナントコンテキストの抽出と適用を担当するライブラリやフレームワークを導入することで、テナントコンテキストの詳細を開発者の目に触れないようにすることができます。
  • 改善計画
    • アプリケーションサービスを使用して統一されたSaaSアイデンティティを生成します。
      • ユーザーとは別にテナントを管理および設定します。
        • テナントの設定とステータスを管理する一元的なサービスを用意し、ユーザーとは別のテナントを明確に定義してカプセル化した情報を提供します。
        • 内部で管理される一意の識別子を各テナントに関連付け、システム全体でリソースを参照し、特定のテナントに関連付けるために使用します。
        • 各テナントには、ユーザにとって使いやすい名称を設定できるようにし、テナント状態の管理・運営を簡素化します。
        • 各テナントに、そのテナントがアクティブか非アクティブかを示すステータスを関連付けます。このステータスを参照し、システムへのアクセスを有効または無効にします。
        • テナントの現在の課金モデルを表すティアまたはプランの概念をテナントに関連付けます。
      • テナントとユーザーの間の関連付けを作成します。
        • アプリケーションの認証フローを拡張し、認証後のステップを追加して、後続の処理のためにトークンを生成します。
        • ユーザーIDを使用して、ユーザーを対応するテナントに解決します。このマッピングは、サービスを介して取得することも、ユーザーのドメインに依存してテナントを特定することもできます。
        • テナントが複数のテナントにマッピングされるシナリオを許容し、ユーザーがターゲットテナントを選択する必要がある追加のステップを導入します。
      • テナントの主要な属性とユーザーデータを単一の形式でパッケージ化します。
        • テナント属性を、テナントにとって必須のカスタムクレームに配置します。その際、機能や特徴へのアクセスを管理するために使用される、大量の承認コンストラクトを持ち込む必要はありません。
        • このトークンの内容を保護するために、キーを使用して署名します。
        • このトークンを、システムとの後続すべてのインタラクションのためのトークンに注入します。
      • テナントの主要な属性とユーザーデータを単一の表現でパッケージ化します。
      • 特徴や機能へのアクセスを管理するために使用される大量の認証構造を持ち込むことなく、テナントにとって必要不可欠なカスタムクレームにテナント属性を配置します。
      • このトークンの内容を保護するために、キーを使用して署名します。
      • このトークンを、システムとの下流でのすべてのインタラクション用のトークンに注入します。
    • IDプロバイダを使用してユーザーをテナントに関連付けます。
      • テナント属性にIDプロバイダーのカスタムクレームを使用します。
      • IDプロバイダー（Amazon Cognito、Okta、Ping、Auth0など）が設定されている場合、テナント属性を追跡するためにユーザーIDに追加するカスタム属性を定義します。
      • 最低でも、システムのテナント識別子がIDプロバイダーのカスタムクレームに保存されていることを確認します。
      • Amazon Cognito を連携 ID プロバイダーと共に使用してテナントコンテキストを導入します。
        • ユーザーのアイデンティティが外部で管理されているアイデンティティプロバイダーによって管理されているシナリオでは、アイデンティティプロバイダーの外部でカスタムクレームを管理または導入する必要がある場合があります。
        • このシナリオでのクレームの導入は、Amazon Cognitoがカスタム属性を所有し、外部のユーザーIDとAmazon Cognitoからの属性を結合するトークンを生成するフェデレーションによって実現されます。
      • IDプロバイダーから返されたトークンを、システムとの後段のすべてのインタラクションのためにBearerトークンに注入します。
      • 署名とトークンのライフサイクルの処理をIDプロバイダに依存させます。
    • 開発者の見えないところでテナントコンテキストを適用するライブラリやフレームワークを作成します。
      • テナントコンテキストを取得するための一元的なヘルパーを用意します。
      • ライブラリを使用して、テナントのコンテキストをメトリクスとログに注入します。
        • すべてのログメッセージをテナントを意識したログ収集wrapperで送信し、すべてのログファイルにテナントコンテキストを抽出および挿入します。
        • すべてのメトリクスと消費に関するイベントを、公開前にテナント・コンテキストを抽出してメトリクスイベントに注入し、メトリクスwrapperを介して送信します。
      • データアクセスライブラリを使用してテナントとの依存関係をカプセル化します。
        • コードでデータにアクセスする場合、そのデータがどこにどのように格納されているかを判断するために、いくつかのテナントコンテキストが必要です。このマッピングは、データアクセスライブラリによって行われ、データにアクセスする際にテナントコンテキストを取得して適用する必要があります。
        • これらの同じデータアクセスライブラリを使用して、テナント分離の情報を隠します。このライブラリで（可能であれば）スコープ付きのクレデンシャルを取得し、データアクセスを現在のテナントにスコープします。
      • 分離を強制するために規約を使用します。
        • テナントコンテキストを使って現在のテナントを特定し、このコンテキストを使って開発者の目に触れないようにアイソレーションポリシーを適用します。
        • アイソレーションコンプライアンスをオプションとして扱うことができないよう、アイソレーションポリシーを制御し適用するために言語構造に依存させます。
  • リファレンス

SaaS SEC 2: テナントリソースがクロステナントアクセスから保護されることをどのように確認していますか?

  • 概要
    • システムのテナント間に隔離境界を作成し、テナントが他のテナントのリソースにアクセスできないようにします。
    • AWSアカウント、ネットワーク構成、マイクロサービス分解、およびポリシーを使用して、これらの境界を定義し、強制します。
  • ベストプラクティス
    • アカウントやVPCなどの細かい構造を使用するか、アプリケーションによって強制されるポリシーを使用するか、またはその両方を使用します。
      • アプリケーションによっては、アカウントやVPCなど、より細かい構造を使用してテナントリソースを分離する場合があります。よりきめ細かいインフラストラクチャ・リソースや共有リソースへのアクセスは、アプリケーションによって強制されるポリシーによって制御されます。
    • IAMとアプリケーション強制のポリシーを組み合わせて適用します。
      • AWS Identity and Access Management（IAM）ポリシーは、IAMロールおよびポリシーによって分離できるテナントリソースへのアクセスを制限するために使用されます。
      • アプリケーション強制ポリシーは、IAMポリシーで対応できないリソースを保護します。
  • 改善計画
    • アカウントやVPCなどの細かい構造を使用するか、アプリケーションによって強制されるポリシーを使用するか、またはその両方を使用します。
      • 分離要件が厳しいリソースには、サイロ分離モデルを使用します。
        • スタック全体の分離のために、各テナントはテナントリソースを完全に分離する別々のAWSコンストラクトに配置され、クロステナントのアクセスを防止することができます。
        • このモデルは、特定のドメインまたは規制要件を満たすことができる分離モデルと、いくつかのコストと運用効率をトレードします。
          • 各テナントを個別のAWSアカウントに配置することで、テナントリソースを分離します。各テナントのリソースの管理と運用を可能にするために、クロスアカウントアクセスを使用します。
          • 各テナントごとに独立したVPCにテナントリソースを配置し、テナントリソースを分離する。AWS PrivateLinkやVPCピアリングを利用し、各テナントのリソースの管理・運用を可能にします。
      • コンピュート・リソースを分離するためには、テナントが専用のコンピュート・リソースを持つ必要があります。
      • ストレージの分離のために、テナントのデータは、それぞれが個別のストレージ・リソースを持つようにパーティション化されます。
        • このパーティショニングは、Amazon RDSではテナントごとに別々のデータベース、DynamoDBでは別々のテーブル、S3では別々のバケット/キー、といった具合に実現されます。
        • このモデルでは、テナントのデータが混在することはありません。各ストレージサービスは、それぞれ独自の分離の概念を持つことができます。
        • SaaS Storage Strategies whitepaper
      • Amazon SQSによるメッセージ処理では、テナントはメッセージ処理を行う専用のキューを持ち、メッセージ処理を分離します。
      • アプリケーションで強制されるポリシーを使用して、テナントの分離境界を強制します。
        • プールされたコンピュート・リソースの場合、テナント・リソースにアクセスしようとするたびに、リクエストがテナント境界を越えていないことを検証するポリシーが適用されます。
        • ポリシーは、あらゆる種類の隔離に適用され、プールされたリソースやサイロ化されたリソースへのアクセスが、テナント境界を越えようとするあらゆるシナリオで適用・実施されることを保証します。
        • ポリシーの記述、管理、実行はすべてIAMの外部で管理されます。これは、言語固有のセキュリティフレームワークやサードパーティのアクセス制御ライブラリなど、さまざまなメカニズムによって対処できます。
    • IAMとアプリケーション強制のポリシーを組み合わせて適用します。
      • IAMは、テナント分離ポリシーの設定と適用に使用されます。
        • ポリシーは、各テナントに（動的または静的に）関連付けられ、そのテナントがアクセスできる各リソースに対してテナント隔離がどのように定義されるかを表現します。
        • 各リクエストには、そのテナントに関連するリソースにアクセスするために使用されるテナント・スコープのクレデンシャルを取得するために使用されるテナント・コンテキストが付属しています。
        • サイロ化されたパーティショニングモデルの場合、ポリシーは単にリソース（VPC、データベース、キューなど）全体が特定のテナントにアクセス可能かどうかを記述する場合があります。プールされた（共有）テナント・リソースの場合、きめ細かいポリシーによって、リソースのどの部分が特定のテナント（DynamoDBのリーディング・キーなど）に対してアクセス可能であるかが記述されます。
        • Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB
      • IAMによるアプリケーション強制ポリシーを追加します。
  • リファレンス

SaaS 信頼性 1: 個々のテナントがシステム内の他のテナントの可用性に影響を与える可能性がある負荷をかけることをどのように制限しますか?

  • 概要
    • システムの全体的な安定性と可用性を損なう可能性のある速度でリソースを消費しているテナントを特定します。
    • このデータとスケーリングポリシーを使用して、これらのテナントがシステムに与える負荷を制限し、システムのすべてのテナントに連鎖する可能性のある大規模な停止を防止します。
  • ベストプラクティス
    • スロットリングポリシーを使用して、ノイズの多いテナントがシステムに与える影響を制限します。
      • システムに過剰な負荷を与えているテナントを捕捉し、特定するための戦略を定義します。
      • このようなノイズの多いテナントが、システムの他のテナントの可用性に影響を与えないように、スロットリングポリシーを適用します。
    • 各テナントの階層ごとにSLAを定義します。
      • システムでサポートするテナント層ごとに設定されたSLAを導入し、低階層のテナントの影響範囲を限定します。
      • SLAをスロットリング戦略の一部として使用し、テナントがシステムに与えるアクティビティと負荷のレベルを厳密に制御します。
    • テナント負荷のパーティショニングによる影響範囲を限定します。
      • テナント負荷を効果的に分散または分離できるパーティショニング戦略を特定し、リソース（コンピューティング、ストレージなど）が効果的にアクセス制限、拡張、およびスパイク状のテナント負荷の分散を行えるようにします。
  • 改善計画
    • スロットリング・ポリシーにより、ノイズの多いテナントがシステムに与える影響を制限します。
      • スケーリングポリシーを使用して、テナントの急増を予測して容量を追加します。
        • コンピュートインテンシブなリソースの場合、クラスタ容量を追加して、高アクティブまたはバーストするテナントが利用可能なリソースを飽和させて可用性に影響を与えるのを防ぎます。
        • Amazon EC2上で動作するプールされたコンピュート・リソースの場合、1つのテナントから発生する可能性のあるスパイクによってリソースが最大化されないように、自動スケーリング・ポリシーを定義します。
        • コンテナ・リソースでは、テナント・クラスタに追加容量を設け、テナントがシステムに過剰な負荷をかける可能性があるシナリオをサポートするようにします。
        • AWS LambdaベースのSaaS環境では、ノイジーネイバー状態でもテナントがリソースを利用できるようにするために、同時プロビジョニング戦略を検討します。
      • システムの可用性に影響を与えるような負荷を発生させているテナントを検出してスロットルを実装します。
        • Amazon API Gatewayを使用するシステムでは、テナントの消費量を評価し、当社システムの可用性に影響を与える可能性のあるリクエスト負荷を発生させている可能性のあるテナントを特定する利用計画を導入します。API Gatewayのスロットリング機能を使用して、このテナントがシステム上で行えるリクエスト数を制限します。
        • アプリケーションのサービスに対して、スタックのリクエスト処理メカニズムまたはサードパーティツールのスロットリング機能を使用して、アプリケーションによる強制的なスロットリングを実装します。
    • 各テナント層のSLAを定義します。
      • テナント層とそのアプリケーションSLAへのマッピングを定義します。
        • システムでサポートするテナント層ごとに明示的なSLAポリシーを定義し、システムの一部であるさまざまな体験やワークフローにおいて、これらのSLAがどのように変化するかを定義します。
        • APIを含むシステムの場合、アプリケーションの各階層でこのAPIがサポートできるリクエスト数の概要を示します。
      • これらのSLAを管理・実施するための仕組みを導入します。
        • API Gatewayを利用したシステムの場合、対応するテナント層ごとに利用計画を策定します。
        • システムでSLAが満たされない場合、イベントを発行して、潜在的なテナント負荷の問題を事前に発見できるようにします。
      • 運用の一環としてSLAの潜在的な問題を顕在化させます。
        • AWSの運用ツールや、Datadog、New Relic、AppDynamicsなどのAPNパートナーのソリューションを使用して、SLAの洞察を提供します。
        • 社内で構築した運用ダッシュボードにSLAと負荷の課題を表示します。
      • テナント層に対して個別のリザーブコンカレンシー構成を使用し、テナントの消費量が特定の層のターゲット消費プロファイルを超えないようにすることができます。
    • テナントの負荷をパーティション化して影響範囲を限定します。
      • マルチテナントのマイクロサービスを設計し、可用性に影響を与える可能性のあるテナントのボトルネックを防止します。
        • マイクロサービスの設計と粒度は、目標とするマルチテナントの可用性とスケーリングのフットプリントに直接影響されます。より効果的に信頼性を確保するために、より幅広いテナント・パーティショニング戦略を提供する粒度の高いサービスを作成します。
        • アプリケーションの可用性とスケーリングプロファイルに基づいて、サイロ型とプール型のパーティショニングモデルを組み合わせて使用します。
        • 上位層のテナントの可用性を最大限に高めるため、主要なサービスをサイロ化して配置するモデルをサポートすることを検討します。
      • 最もアクティブなテナントまたは上位層に最適化します。
        • システムの主要なワークフローを強化するために、スケーリングとパフォーマンスの最適化を行い、システムにかかる負荷を軽減します。
        • 例えば、アクティブ度の高いテナントに対してデータキャッシングを提供し、システムにかかる負荷を軽減することも一つの方法です。
        • Designing for failure: Architecting for resilient systems on AWS
  • リファレンス

SaaS 信頼性 2: テナントの健全性をどのように積極的に検知および維持しますか?

  • 概要
    • SaaS環境の信頼性を管理するには、個々のテナントの可用性やエクスペリエンスに影響を与える可能性のある問題を検出できる運用ツールが必要です。
    • 弾力性のあるSaaS環境は、テナントとシステムの健全性に関する問題を事前に検出し解決できるような、テナントを意識した運用をサポートします。
  • ベストプラクティス
    • アプリケーションログにテナントコンテキストを追加して、テナントの健全性を積極的に管理します。
      • ログファイルにテナントのコンテキストを追加して運用チームが分析し、信頼性の問題を即座に特定してトラブルシューティングを行うことができます。
      • テナントコンテキストを使用して、システムまたはテナントの安定性や可用性の問題の原因となっている可能性がある特定のテナントアクティビティを特定します。
    • テナントに関する詳細な情報を収集し、ヘルスフォレンジックを強化します。
      • テナントのアクティビティ、消費量、パフォーマンス、エラーの詳細データを一元管理されたリポジトリに公開し、信頼性に影響を与えるヘルス問題の分析に使用できるようにします。
      • このデータを使用して、マルチテナントの信頼性に関わる困難な事象を特定します。
    • ポリシーとアラームを使用してテナントの問題をプロアクティブに特定します。
      • テナントに関するさまざまな情報とポリシーを組み合わせて、環境の安定性や可用性に影響が及ぶ前に、テナントの問題をプロアクティブに特定します。
      • これらのポリシーは、個々のテナントの自己修復ストラテジーを呼び出したり、アラートやアラームを表示したりすることができます。
  • 改善計画
    • アプリケーションログにテナントコンテキストを追加し、テナントの健全性を積極的に管理します。
      • アプリケーション・ログ・ファイルへのテナントコンテキストを挿入します。
        • テナントコンテキストを取得し、このコンテキストを各ログメッセージに挿入できる、ログ記録フレームワークのラッパーを導入する。テナントのアクティビティを分析するのに役立つテナント属性も含めます。
      • ログ分析ツールと注入されたテナントコンテキストを使用して、テナントのアクティビティと消費傾向を分析します。
        • これらの洞察を使用して、テナントまたは階層に影響を及ぼしている可能性のある安定性と信頼性の問題をトラブルシュートします。
        • CloudWatch LogsまたはAmazon Elasticsearch Service（Amazon ES）を使用して、テナントの問題を調査および分析し、特定のテナントまたはビューに制約されるアクティビティのビューを作成します。
    • ヘルスフォレンジックを強化するための詳細なテナントインサイトを導入します。
      • テナントアクティビティの可視性を高めるインサイトを公開します。
        • テナントまたはテナントの層が遭遇している問題に対する情報を可視化し、詳細な信頼性メトリクスのインストルメンテーションを導入します。
        • テナントのレイテンシー、潜在的なボトルネック、および機能消費を表示するメトリクスを追加し、運用チームがパフォーマンスやエラーの状態を特定のテナント ワークフローと容易に関連付けることができるようにします。
          • テナントのカスタムメトリクスをAWSメトリクスで補強し、テナントの健全性に関する全体的なビューを作成することができます。
        • 運用方法の一部としてテナントの信頼性メトリックを含めます。
          • 運用ユーザがツールを使って信頼性の問題を簡単に検出し、トラブルシューティングできるようにする。この機能は、AWSサービス（Amazon ES、Amazon QuickSightなど）またはクラウドメトリクスの分析に使用されるサードパーティツールで実現できます。
    • ポリシーとアラームでテナントの問題をプロアクティブに特定します。
      • 運用担当者によるテナントアラートとアラームの設定を可能にします。
        • テナントの消費量、アクティビティ、SLA指標の特定のパターンを特定し、それらを組み合わせて、テナントの健全性に関する問題をプロアクティブに特定するために使用することができます。
        • テナントが特定のヘルス状態またはパフォーマンスのしきい値に達したときにトリガーされるアラートとアラームを設定し、信頼性問題の前兆となる可能性を把握します。
      • テナントの信頼性に対処するための自己回復戦略の適用します。
        • 自動化により、テナントやシステムに影響が及ぶ前に、信頼性と安定性の問題に対処するための変更を適用します。
  • リファレンス

SaaS 信頼性 3: SaaS アプリケーションのマルチテナント機能をどのようにテストしていますか?

  • 概要
    • マルチテナントのワークロードに固有のユースケースを演習し、検証する自動化されたテストを導入してください。
    • マルチテナント・アーキテクチャの安定性に不可欠な、テナントのワークロードとユーザー体験のシミュレーションに重点を置いてください。
  • ベストプラクティス
    • ノイジー・ネイバーのスケールと可用性を検証します。
      • さまざまなノイジー・ネイバー条件をテストし、テナントのサブセットがシステムに不相応な負荷をかけるシナリオを特定し、それに対応するシステムの能力を評価します。
      • さまざまなテナント階層とプロファイルに対して、スケーリング、スロットリング、階層化ポリシーを適用するシステムの能力を評価するテストスイートを開発します。
    • マルチテナントの負荷がかかった状態で、主要なワークフローをテストします。
      • 顧客にとって重要なワークフローを特定し、マルチテナント負荷時のSLAをサポートするシステムの能力を検証するテストを実施します。
      • テナントのアクティビティレベルに応じた負荷の組み合わせで、システムの安定性を評価します。
    • テナントオンボーディングの規模および再現性を検証します。
      • テナントオンボーディングが、さまざまなパターンと構成のテナントに対して、信頼性と再現性をもってオンボーディングできることを確認します。
      • オンボーディングプロセスが目標のSLAを継続的に満たしていることを検証します。
    • テナント設定の変更が正常に反映されることを確認します。
      • システムがテナントの課金アカウントに正しく変更を適用し、伝達していることを確認します。
      • ステータスやティアなどのアカウント状態への変更は、課金システムとSaaS環境の間で共有される必要があります。
      • テストでは、この状態の同期が正常に処理されることを検証する必要があります。
    • テナントの分離を検証します。
      • テナント分離のポリシーと実装が正しく適用されていることを確認するために、システムとのインタラクションをシミュレートします。
      • 開発者のマルチテナント・コードが意図せずにテナント境界を越える可能性があるシナリオを検証するテストも含めてください。
  • 改善計画
    • ノイジー・ネイバーのスケールと可用性の検証を行います。
      • さまざまなテナント・ペルソナのノイジー・ネイバー・テナント・シナリオをシミュレートするテストを作成し、可用性ポリシーが異なるテナント・プロファイルと階層に正常に適用されることを検証します。
      • ノイジー・ネイバー・テストでは、システムのスロットリングおよびスケーリング・ポリシーを行使し、個々のテナントがシステムの可用性に影響を与えないことを確認します。
      • テナント階層に関連するSLAが、システムのSLAおよびスケーリングポリシーによって実施されることを検証します。
      • 公開APIを持つシステムでは、テナントがAPIを飽和させてシステムの可用性に影響を与えることがないことを検証します。
    • マルチテナントの負荷時に主なワークフローをテストします。
      • システムの主要なワークフローが、マルチテナント環境の継続的に変化する負荷プロファイルに効果的に対応できることを検証するためのテストを作成します。
      • 主要なシステムのワークフローについて、マルチテナントの負荷パターンをシミュレートし、異なるスケーリング状態においてテナントの使用感とSLAに影響がないことを確認します。
      • マルチテナントの負荷の変化に応じてシステムがスケールアップまたはスケールダウンしても、SLAが満たされ続けていることを検証します。
      • システムの負荷に見合ったテナント数で、システムの可用性を検証します。
      • 課金統合を含むシステムの場合、課金プロビジョニングエクスペリエンスと、課金システムで新規課金アカウントを正常にプロビジョニングする能力を検証するテストを作成します。
      • オンボーディングの一部として構成されるサードパーティ統合に依存するシステムについては、プロビジョニングエクスペリエンスがこれらの統合を正常に構成しプロビジョニングすることを検証するテ ストを作成します。
    • テナントオンボーディングの規模および再現性を検証します。
      • テナントアラートとアラームを構成するための運用を可能にします。
      • オンボーディングの自動化が、適切なインフラストラクチャ、構成、分離ポリシー、ID フットプリントなどを使用して新しいテナントを正常にプロビジョニングしていることを検証するためのテストを作成します。
      • 特定のオンボーディングSLAを持つシステムの場合、さまざまなテナント構成のオンボーディングが目標のオンボーディングSLA要件を満たすことを検証するテストを導入します。
      • オンボーディングの一環としてテナントの検証を必要とするシステムでは、この検証プロセスを実行するテストを作成し、メッセージングとテナントの初期設定が要求通りに機能することを確認します。
    • テナント設定の変更が正常に反映されることを確認します。
      • テナントの状態における変更が実行中のシステムに適切に適用されることを検証するためのテストを作成します。
      • テナントがシステムにアクセスしようとしたときに、テナントの無効化と再有効化が正常に実行されることを検証します。
      • テナントの階層に対する変更が正しく検出され、システムに適用され、階層の境界に関連する機能へのアクセスが有効または無効になることを検証します。
      • 各テナント層に関連する制限とポリシーがシステムによって実施されていることを確認するためのテストを導入します。
      • 削除されたテナントがシステムによって正しく処理されていることを検証します（退役、データのアーカイブ化など）。
    • テナントの分離を検証します
      • アプリケーションがシステムのテナント分離ポリシーを実行していることを確認するためのテストを作成します。これらのテストでは、隔離モデルを破壊する潜在的な危険を調査し、悪さをしたユーザーがテナントの境界を越えられないようにします。
      • SaaSのIDをシミュレートしようとするテナント・トークンを注入します。
      • 共有ライブラリやフレームワークを使用してシステム全体の分離を実施しているアプリケーションでは、これらのフレームワークを実行するテストを導入し、テナント分離ポリシーが正確に適用されることを検証します。
      • 新しいテナント識別子を注入してテナントコンテキストを変更しようとするテストを作成します。この注入がテナント境界を越えてブロックされることを検証します。
  • リファレンス

SaaS PERF 1: あるテナントが別のテナントの体験に悪影響を与えることを防ぐにはどうすればいいのでしょうか?

  • 概要
    • スケーリングとスロットリングの仕組みを導入し、1つのテナントが他のテナントのパフォーマンスとエクスペリエンスに影響を与えるような方法でシステムに負荷をかけることがないようにします。
  • ベストプラクティス
    • 需要の高いテナントリソースをサイロ化します。
      • システム内のボトルネックになりそうなものを特定し、それらを別のサイロに分散させます。
      • この分離は、コンピュート、ストレージ、メッセージングなど、アーキテクチャの各層で行うことができます。
      • サイロは、エクスペリエンスのボトルネックとなるレイヤーにのみ導入する必要があります。
    • テナントの急増に対応するために、テナントを意識したポリシーと追加容量を組み合わせます。
      • テナントを意識したポリシーを使用して、パフォーマンスに悪影響を及ぼす可能性のあるテナントのアクティビティの急増を特定します。
      • これらのポリシーは、スケーリングの「クッション」を追加するキャパシティ戦略と組み合わせることで、スケーリングの遅延がテナントのパフォーマンスに影響を与えないようにすることができます。
    • スロットリングポリシーを使用して、個々のテナントがシステムに過剰な負荷をかけることを防止します。
      • 個々のテナントのアクティビティ傾向を評価するスロットリングポリシーを導入し、SLAとそのティアおよびプランを使用して、システム内の1つまたは複数のエクスペリエンスの飽和を防止します。
      • 低ティアのテナントが高ティアのテナントのパフォーマンスに影響を与えないようにします。
    • テナントの負荷と期待されるパフォーマンスを一致させるパターンで、サービスを分解して展開します。
      • SaaSシステムの設計では、一般的な使用シナリオを考慮し、潜在的なボトルネックを調査して、負荷が効果的に分散されるようにリソースを分割しています。また、スケーリング動作とテナントの消費状況を一致させます。
  • 改善計画
    • 需要の高いテナントリソースをサイロ化します。
      • 個々のテナントの負荷が過剰なリソースを消費し、他のテナントのエクスペリエンスに影響を与える可能性があるワークフローを特定します。これらの領域ごとに、各テナントに専用のリソースを割り当てるサイロを作成します。
        • マイクロサービスベースのアーキテクチャでは、パフォーマンスのボトルネックとなり得るサービスをサイロモデルで展開し、各テナントに専用のエクスペリエンスを提供することができます。
        • ストレージが主なボトルネックになっている場合は、テナントごとにストレージを分離し、コンピュートとデータを混在させないようにします。
      • Amazon SNS、Amazon SQS、Amazon EventBridgeなどのメッセージング・コンストラクトは、各テナントの負荷に影響されることがあります。このような場合、一部またはすべてのテナントに専用のメッセージ処理リソースを提供することができます。
      • Amazon EC2ベースのソリューションの場合、一部またはすべてのテナントに専用のコンピュート・リソースを提供することができます。
      • ボトルネックがテナントエクスペリエンス全体（計算、ストレージ、メッセージングなど）に及ぶ可能性がある場合、特定のテナントに対してスタック全体にまたがるサイロを用意することを検討します。
      • サーバーレスSaaS環境では、予約された同時実行を使用して特定のテナント層のエクスペリエンスをサイロ化し、プレミアム層により大きな同時実行機能のプールを提供します。
    • テナントを意識したポリシーと追加容量の組み合わせで、テナントの急増に対応します。
      • テナントの消費に関する情報を利用して、個々のテナントがシステムに大きな負荷をかけるシナリオに反応し、対応するポリシーを定義します。
        • テナントのアクティビティを追跡するメトリクスをアプリケーションに組み込み、このアクティビティと負荷を関連付けることで、ノイジーネイバーの状態を特定します。
        • テナントの消費プロファイルに基づいてスケーリングポリシーを定義し、スケーリングによって個々のテナントに起因するスパイクに効果的に対処できるようにします。
      • ベースライン環境に容量を追加し、個々のテナントからのアクティビティのバーストを相殺するために使用できるスケーリングバッファを追加します。
    • スロットルポリシーを使用して、個々のテナントがシステムに過剰な負荷をかけるのを防止します。
      • システムに過剰な負荷を与えているテナントを検出し、スロットルを実装します。
      • アプリケーションのサービスに対して、スタックのリクエスト処理メカニズムまたはサードパーティツールのスロットリング機能を使用して、アプリケーションによるスロットリングを実装します。
    • テナントの負荷と期待されるパフォーマンスを一致させるパターンでサービスを分解して展開します。
      • マルチテナントのマイクロサービスを設計し、スケーリングプロファイルを分散して最適化します。
        • マイクロサービスの設計と粒度は、目標とするマルチテナントのスケーリングフットプリントに直接影響されます。より効果的なスケーリングとノイジーネイバーコンディションを実現する幅広いテナントパーティショニング戦略を提供する、より粒度の細かいサービスを作成します。
        • サイロ型とプール型のパーティショニング・モデルを組み合わせて使用し、テナントが主要なサービスやリソースのボトルネックになるのを抑制します。
        • ハイエンド層では、主要なサービスをサイロ化して展開し、ノイジーネイバーへの影響を最小限に抑えるモデルをサポートします。
      • 最もアクティブなテナントまたはハイエンド層に対して最適化します。
        • スケーリングとパフォーマンスの最適化の導入により、システムの主要なワークフローを強化し、システムにかかる負荷を軽減します。
        • 例えば、アクティブ度の高いテナントに対してデータキャッシングを提供し、システムにかかる負荷を軽減することができます。
        • AWS re:Invent 2016: Optimizing SaaS Solutions for AWS (ARC408)
  • リファレンス

SaaS PERF 2: インフラストラクチャリソースの消費とテナントのアクティビティやワークロードを調整するにはどうしたらよいですか?

  • 概要
    • SaaSアプリケーションのインフラストラクチャーフットプリントが、継続的に進化するテナントのプロファイルとテナントのワークロードを正確に反映するスケーリング戦略を構築します。
    • SaaSビジネスにとって重要な、リソースを過剰にプロビジョニングすることなく効率的に拡張するスケーリングモデルを構築するには、テナントのアクティビティと消費パターンに関する豊富なインサイトが必要です。
  • ベストプラクティス
    • テナントプロファイルデータを使用して、静的なスケーリングポリシーを構成します。
      • ログとプロファイリングデータを使用してテナントの負荷を分析し、過去の消費傾向に基づいてインフラストラクチャのスケーリングポリシーを定期的に構成します。
    • 標準的なAWSメトリックに基づいた動的なテナント・スケーリング・ポリシーを構築します。
      • すぐにアクセス可能なAWSインフラストラクチャのメトリクスを利用して、テナントの消費活動を推定する一連のポリシーを定義します。これらのメトリクスを使用して、テナントのアクティビティとリソースの消費を一致させるようにポリシーを構築します。
    • アプリケーションで生成されたテナントインサイトに基づいてスケーリングします。
      • SaaS 固有のメトリクスデータを取得、集計し、他のメトリクスとともに使用して、堅牢なマルチテナント スケーリング戦略を構築します。
  • 改善計画
    • テナントプロファイルデータを使用して静的スケーリングポリシーを構成します。
      • ログとアプリケーションのプロファイルデータを定期的に分析して、テナントによるリソースの消費状況を把握し、その消費状況がアプリケーションのマルチテナントスケーリングプロファイルにどのような影響を及ぼしているのかを評価します。
      • テナントに関する情報を利用して静的スケーリングポリシーを策定および調整し、リソースの消費量と実際のテナントのアクティビティをより一致させることを目指します。
      • サーバーレス環境では、AWS Lambda関数の負荷をテナント階層とプロファイルで最適化するスケーリング構造を導入します。
        • 特定のテナントのワークフローが事前にウォームアップされた状態でSLAを満たさないシナリオでのみ、プロビジョニングされたコンカレンシーを使用します。
        • テナント層に対して個別のリザーブドコンカレンシー構成を使用し、テナントの消費量が特定の層のターゲット消費プロファイルを超えないようにします。
    • 標準的なAWSメトリックに基づいた動的なテナントスケーリングポリシーを構築します。
    • アプリケーションで生成されたテナントインサイトに基づく拡張性を実現します。
      • アプリケーションに詳細なメトリックを組み込んで、テナントのアクティビティと消費データを取得、表示し、リアルタイムで分析します。
      • テナントに関する詳細な情報を利用してスケーリングポリシーを構築し、テナントの実際のアクティビティ傾向やパターンに基づいてシステムを確実に拡張します。
  • リファレンス

SaaS PERF 3: テナントの階層やプランによって異なるパフォーマンスレベルを可能にするにはどうすればよいですか？

  • 概要
    • 割り当てられたティアとプランに基づいてテナントに異なるパフォーマンス体験を提供し、プレミアムティアのテナントにはより高いレベルのパフォーマンスを提供します。
    • これは、単一の共有マルチテナント環境内でさまざまなレベルのパフォーマンスを可能にするアーキテクチャ戦略を導入することを意味します。
  • ベストプラクティス
    • 低ティアのテナントにはスロットリングを適用します。
      • プレミアムティアのテナントのパフォーマンスとエクスペリエンスを向上させるために、低ティアのテナントのパフォーマンスが制限されます。
      • このような制約があると、システムの主要な機能面でより良いパフォーマンスを得るために、テナントが上位ティアに移動する動機になる場合があります。
    • ポリシーを使用してテナント層ごとにアプリケーションのパフォーマンスを形成します。
      • アプリケーションの主要なワークフローとユースケースにわたって層ベースのパフォーマンスポリシーを管理および適用するためのコンストラクトを導入します。
      • これらのポリシーは、各SaaS層およびプランのエクスペリエンスを定義するために使用される、より内部および外部のパフォーマンスSLAを定義します。
    • 異なるテナント層に対してエクスペリエンスを最適化します。
      • アプリケーションのサービスを階層ごとに分解して展開し、高負荷や最適なスループットを必要とするワークフローに対して、サイロ化または最適化されたエクスペリエンスを提供します。
  • 改善計画
    • 低ティアのテナントへのスロットリングを適用します。
      • 低ティアのテナントがプレミアムテナントのワークロードに影響を与えないように、この階層のテナントの影響を制限する、より粗い粒度のアプローチとして、スロットリングポリシーを使用します。
      • アプリケーションによる強制的なスロットルでは、言語固有のフレームワークとツールを使用して、サービスのエントリポイントにスロットル構造を導入します。
    • 各テナント層のアプリケーション・パフォーマンスを形成するためのポリシーを使用します。
      • テナント層のポリシーとそのアプリケーションSLAへのマッピングを定義します。
        • システムでサポートされるテナント層ごとに、アプリケーション・ワークフローに対する特定のパフォーマンス基準の概要を示す明示的なSLAポリシーを定義します。
        • APIを含むシステムの場合、各APIエントリ・ポイントに関連するパフォーマンス基準の概要を示します。
      • システムのパフォーマンス経験階層を変化させる仕組みを導入します。
        • API Gatewayを利用するシステムの場合、システムがサポートするテナント層ごとに利用プランを定義します。
        • フレームワークまたはサードパーティー・ソリューションを使用してAPIエントリ・ポイントを管理しているシステムでは、フィルターを導入してテナントのアクティビティを制御し、各テナント層が目標のSLAを達成できるようにします。
    • 異なるテナント層に対するエクスペリエンスの最適化をおこないます。
      • サイロ化されたリソースを使用して、よりパフォーマンスの高いエクスペリエンスをテナント層に提供します。
        • マイクロサービスの設計と粒度は、テナント層のパフォーマンスプロファイルに影響される可能性があります。マイクロサービスの設計と粒度は、テナント層のパフォーマンスプロファイルに影響されます。消費パターンと潜在的なボトルネックを特定し、このデータを使用してマイクロサービスの分解を通知します。
        • 共有インフラストラクチャでは対応しにくいパフォーマンス要件を持つ上位ティアのテナントには、選択したテナントサービスとストレージ構造をサイロモデルで展開します。
      • 高ティアへの最適化を提供します。
        • 最適化技術により、上位ティアのテナントのパフォーマンスを向上させます。
          • プレミアムティアのテナントのエクスペリエンスを豊かにするために、キャッシングを使用します。
          • サイロ化したインフラを持つプレミアムティアのテナントには、ストレージとコンピュートにより大きなインスタンス、より高いIIOPsなど、より高性能なリソース構成を提供します。
  • リファレンス

SaaS COST 1: 個々のテナントのリソース消費はどのように測定されますか?

  • 概要
    • インフラストラクチャの消費を、システムの個々のテナントに関連付けます。
    • テナントのアクティビティと消費パターンのプロファイリングに使用できる測定基準を提示し、SaaSアプリケーションを使用している各テナントのインフラのフットプリントを概算して計算できるように十分なインサイトを収集します。
  • ベストプラクティス
    • テナントの消費量の概算を計算します。
      • 単純な指標（たとえば、リクエスト数）を使用して、各テナントの消費量のおおよその割り当てを作成します。このテナント配分とAWS請求書を関連付けるために手動プロセスが使用され、テナントあたりのコストの概算が算出される。
    • テナント消費量の詳細なビューを作成します。
      • アプリケーションの個々のリソースの消費量は測定され、各テナントに帰属します。このデータは集計され、テナント消費量の詳細な見積もりに使用されます。
    • テナントの消費に関する情報を利用して、運用とアーキテクチャーの効率を向上させます。
      • テナントの消費データを使用して、運用チームとアーキテクチャチームに実用的な情報を提供し、マルチテナントシステムの効率性を分析・改善するためのポリシーと戦略を導入することができます。
  • 改善計画
    • テナントの消費量目安の概算を計算します。
      • 一般的なテナントのアクティビティに基づく消費量の概算を計算します。
        • 各テナントで生成されているリクエストの数を把握するためのツールを使用します。Amazon CloudWatch、AWS X-Ray、または言語固有のフレームワークを使用して、テナントアクティビティをキャプチャして公開します。
        • 公開されたデータを一定期間集計し、一般的なテナントアクティビティに基づいてテナント消費量の概算を計算します。
        • テナントごとのコストの概算を計算します。
        • AWSのコスト分析またはAPNパートナーツールを使用して、特定の請求期間のAWSコストの概要を組み立てます。
        • テナント消費量の近似値を請求データに適用し、テナントあたりのコストを計算します。
        • システムの主要なリソースを表すサービスに相関する可能性が高い近似モデルを選択します（コストおよび/または効率）。
    • テナント消費に関する詳細なビューを作成します。
      • テナントに関する詳細な情報をもとに、アプリケーションを構築します。
        • 測定が必要なリソースを特定します。各リソースがAWSの請求書全体にどのように関連し、全体的な経費にどのように寄与しているかを検討します。これは、リソースの計測戦略の粒度を形成するのに役立ちます。
        • ソリューションのスタック全体に計測手段を追加し、各リソースタイプの消費メトリクスを公開する。消費メトリクスの性質は、消費されるリソースの種類によって異なります。
          • 特定のリソース（マイクロサービス、ストレージ、コンピューティングなど）に対するテナント消費を最もよくモデル化するテナント・アクティビティの次元を特定します。
          • アクティビティによって駆動されるAPIベースのサービスでは、テナント・リクエストのカウントを使用してテナント消費をモデル化します。
          • スループットやCPUを多用するリソースの場合は、レイテンシーを使用してテナント消費量をモデル化します。
          • ストレージサービスでは、各テナントのコンピュート（該当する場合）とデータのフットプリントをモデル化します。
          • サーバーレス環境では、特定の関数の呼び出し回数に基づいて消費量をモデル化します。
      • 消費メトリクスの集計をサマリーします。
        • 自動化により、環境のフットプリント全体について、テナントの消費に関する詳細なインサイトを分析し、集計することができます。
        • お客様のニーズを最もよくサポートするAWSデータウェアハウスとアグリゲーションサービスを使用して、テナント消費量のインサイトを集計することができます。Amazon Kinesis Data Firehose、Amazon Redshift、Amazon S3、Amazon Athena、Amazon CloudWatch、Amazon Elasticsearch Service (Amazon ES) などは、メトリックデータの集計と分析に使用できるサービスです。
      • 各テナントの消費量の概算を算出します。
        • 集計されたテナント消費データを使用して、システムの各テナントに消費割合を割り当てるサマリーを作成します。
        • テナントの消費データをどのように重み付けし、各テナントの消費割合の合計に変換するかを決定するポリシー/ルールを導入します。
        • AWSコスト分析またはAPNパートナーツールを使用して、特定の請求期間のAWSコストのサマリーを組み立てる。
        • テナントの消費量の概算を請求データに適用し、テナントあたりのコストを計算します。
    • テナントの消費に関する情報を活用し、運用と設計の効率化を図ります。
      • テナントの消費状況を運用ビューに反映します。
        • テナントのデータを運用ダッシュボードに取り込み、テナントの消費活動を表示します。
        • マルチテナント環境の継続的に変化する負荷に効率的に対応するシステムの能力を評価するために使用できる消費量ビューを作成します。
        • システムのリソースを最も活発に消費しているテナントを特定するための消費量ビューを作成します。
        • テナントがアーキテクチャの主要要素（ストレージ・サービス、コンピューティング・リソースなど）にどのような負荷を与えているかをプロファイリングできる消費量ビューを作成することができます。
        • テナントが個々のアプリケーション・サービスにどのような負荷をかけているかをプロファイリングできる消費量のビューを作成します。
        • 運用チームが個々のテナントまたはテナント層の消費量を確認できるようにします。
      • テナントの消費データを使用して、テナントの健全性をプロアクティブに管理します。
        • SLAのしきい値に近づいているテナントをプロアクティブに識別するポリシーを作成します。
        • エクスペリエンスが制限されているテナントをプロアクティブに特定するためのポリシーを作成します。
      • テナントの消費データに基づいてアーキテクチャを最適化します。
        • テナントの消費量プロファイルを使用して、スケーリング、階層化、スロットリングの戦略を改良し、より効率的なマルチテナントの運用フットプリントを作成します。
  • リファレンス

SaaS COST 2: テナントの消費とインフラストラクチャのコストはどのように関連付けられますか?

  • 概要
    • テナントの消費量データとインフラストラクチャのコストを関連付け、テナントあたりのコストを計算します。
    • その目的は、テナントの負荷とアーキテクチャーの選択がSaaSアプリケーションの全体的なコストプロファイルにどのように影響しているかを、ビジネスチームとテクノロジーチームが継続的に把握できるようにすることです。
  • ベストプラクティス
    • 消費量とコストを手動で集計し、関連付けます。
      • ある期間のコストデータを手動で収集し、集計するためにツールが使用されます。このデータはサービスごとにまとめられ、テナントの消費データと関連付けられ、テナントあたりのコストが計算されます。
    • 自動化により、テナントの消費量とAWSのコストを関連付けます。
      • 自動化されたメカニズムがAWSまたはサードパーティツールからコストデータを取得し、このデータをテナントの消費配分と関連付け、テナントあたりのコストを決定します。
  • 改善計画
    • 消費量とコストを手動で集計・関連付けます。
      • AWSまたはサードパーティツールを使用して、インフラコストのサマリーを作成します。
        • コストデータを、テナントごとのコストレポートで公開したいレベルの詳細と最もよく一致する粒度で集計します。
        • コストデータに直接、プログラムでアクセスする場合は、AWSコストと使用状況レポートのデータにアクセスする自動化の導入を検討してください。
        • 手動でAWSツールを使用するソリューションの場合、AWS Cost Explorerからコストデータをエクスポートすることを検討します。
        • サードパーティーオプションの場合、コストデータを取り込み、要約するAWSパートナーコスト分析ソリューションの利用を検討します。
          • AWSパートナーコスト分析ツールを設定し、ニーズに最も合ったコストのサマリーを作成します。
          • コスト分析ツールからコストデータをエクスポートし、手作業でコストを管理する環境にインポートできる形式にします。
      • テナントあたりのコストの概算を算出します。
        • テナントの消費量とコストデータを1つのツール（Excelなど）で結合し、テナントあたりのコストのサマリービューを提供することができます。
        • システム内のすべてのテナントについて、テナントあたりのコストの概要を示すレポートを作成します。
          • テナントごとのコストの上位ビューを得るために、総コストに適用できる各テナントの消費割合の合計を持つことを検討します。
          • さらに、テナントの消費割合をAWS請求書の個々の要素に適用できるような、テナントあたりのコストのより詳細な表示をサポートすることを検討します。
        • これらのレポートを毎期手動で作成し、テナントあたりのコスト傾向を継続的に把握できるようにします。
      • 自動化を利用してテナントの消費量とAWSコストを関連付けます。
        • AWSコストの取り込みを自動化します。
        • AWSの課金レポートからデータを取り込み、まとめることができる自動化を導入します。
        • サードパーティの課金プロバイダにアクセスできる環境では、これらのプロバイダの取り込み自動化を使用してAWSの課金データを取り込む。これらのプロバイダーのAPIを使用して、請求データを取得します。
        • コストデータをテナントごとのコスト分析リポジトリに取り込みます。
        • Amazon Redshift、Amazon S3、Amazon ESなど、ターゲットとする分析コストとエクスペリエンスに適したAWSリポジトリのいずれかを使用して、テナントの消費データとともにコストデータを保存します。
        • サードパーティがコストを集計しているシナリオでは、APIを使用してこれらのソリューションからコスト分析リポジトリにコストデータを取り込みます。
        • 自動化により、テナントの消費量を集計し、テナントあたりのコストを計算します。
        • テナントの消費量とAWSのコストデータを関連付け、システム内の各テナントのテナントあたりのコストを生成します。
        • 運用ビューの一部としてこのデータを可視化できるように、APIを通じてテナントあたりのコストデータを公開します。
        • テナントあたりのコスト指標をクラウド財務管理モデルに統合します。
        • テナントあたりのコストデータを使用して、マルチテナントの消費動向が組織のビジネスと財務の成功にどのような影響を及ぼしているかを判断します。
        • Calculating SaaS Cost Per Tenant: A PoC Implementation in an AWS Kubernetes Environment
  • リファレンス

まとめ

思ってた以上に長くなってしまいましたが、これで迷子にならずSaaS Lensを眺めることができそうです。
同じような悩みを持った方の参考になりましたら幸いです。

以上、大阪オフィスの林がお送りしました！

Share this article

facebook logohatena logotwitter logo

関連記事

[レポート] AWS Partner Tech Study Day 2024(Well-Architected Mini Bootcamp 運用上の優秀性の柱)に参加してみた

[レポート] AWS Partner Tech Study Day 2024(Well-Architected Mini Bootcamp 運用上の優秀性の柱)に参加してみた

User avatar
おつまみ
2024.08.30
AWS Well-Architected Framework がアップデート(2024年6月27日)されたので変更点を Well-Architected Tool で比較してみた

AWS Well-Architected Framework がアップデート(2024年6月27日)されたので変更点を Well-Architected Tool で比較してみた

User avatar
いわさ
2024.06.28
AWS Well-Architected Cost Optimization Workshop で AWS コスト最適化のハウツーを学ぼう！

AWS Well-Architected Cost Optimization Workshop で AWS コスト最適化のハウツーを学ぼう！

User avatar
園部治
2024.06.07
AWS Well-Architected Framework の M&A レンズ（初版）をまとめてみた

AWS Well-Architected Framework の M&A レンズ（初版）をまとめてみた

User avatar
いわさ
2024.05.20
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.