選択

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

マルチテナント環境では、システムにかかる負荷が大きく異なるプロファイルやユースケースをテナントが持つ場合があります。新しいワークロードプロファイルを持つ新規のテナントが、継続的にシステムに追加されることもあります。このような要素があると、SaaS 企業にとって、急速に進化するパフォーマンス要件を満たすアーキテクチャを構築することが非常に困難になる可能性があります。

テナント負荷のこのような変動を処理して管理することが、SaaS 環境のパフォーマンスプロファイルの鍵となります。SaaS アーキテクチャは、これらのテナントの消費傾向を正しく検知することが求められるほか、テナントの需要を満たしたり、個々のテナントのアクティビティを制限したりするために、効果的に拡張できる戦略を適用できなければなりません。

テナントによってシステムに不釣り合いな負荷がかかっている可能性があるこれらのシナリオを管理するために、さまざまな戦略を使用できます。これは、需要の高いリソースの分離、スケーリング戦略の導入、スロットリングポリシーの適用によって実現されます。

最もシンプルで極端なケースでは、アプリケーションの一部にテナント固有のデプロイを作成することもできます。図 22 は、システムを分解することによってパフォーマンスの課題に対処する方法を示しています。

図 22: サイロ化されたサービスによるパフォーマンスの対処

この例では、2 つの異なるデプロイフットプリントがあります (一部はサイロモデルで、一部はプールモデルです)。図の左側では、各テナントに対して製品、注文、カートの各マイクロサービスの個別インスタンスがデプロイされていることがわかります。一方、図の右側には、すべてのテナントで共有されているマイクロサービスの集合体が表示されています。

このアプローチは、アプリケーションのパフォーマンスプロファイルにとって重要と見なされる特定のサービスを切り分けることを基本的な考え方としています。これらを分離することで、システムにおいて、(この一連のサービスについて) あるテナントの負荷が他のテナントのパフォーマンスに影響を与えないようにすることができます。この戦略では、コストが増加し、環境の運用上の俊敏性を低下することになりますが、パフォーマンス領域をターゲットにするための有効な手段になります。また、同様のアプローチは、コンプライアンスと分離の要件にも適用することができます。

例えば、各テナントに注文管理マイクロサービスを導入すれば、あるテナントが他のテナントの注文処理経験に悪影響を与えることを制限することができます。これにより、運用が複雑になり、コスト効率が低下しますが、アプリケーションの重要な領域に対してクロステナントのパフォーマンスの問題を選択的にターゲットにするブルートフォースの手段として使用することができます。

理想としては、個別にデプロイされたサービスのオーバーヘッドやコストを吸収することなく、テナントの負荷の問題に対応できる構成を通じて、これらのパフォーマンス要件に対応してください。ここでは、共有インフラストラクチャがテナントの負荷やアクティビティの変化に効果的に対応できるようにするためのスケーリングプロファイルの作成に焦点を当てます。

Amazon EKS や Amazon ECS のようなコンテナベースのアーキテクチャは、リソースの大幅なオーバープロビジョニングを必要とせずに、テナントの需要に基づいてサービスをスケーリングするように構成することができます。コンテナが迅速にスケーリングできることで、テナントの負荷が急増した場合でもシステムが効果的に対応できるようになります。コンテナのスケーリング速度と AWS Fargate のコストプロファイルを組み合わせることによって、伸縮性、運用の俊敏性、コスト効率がしっかりと融合し、環境にオーバープロビジョニングすることなくテナントの負荷の急増に対応できるようになります。

また、AWS Lambda を使用してて構築されたサーバーレス SaaS アーキテクチャは、テナント負荷の急増への対応にも適しています。AWS Lambda のマネージド型の特質により、テナント負荷の急増に対処するために、アプリケーションのサービスを迅速に拡張することができます。このアプローチには、同時実行性とコールドスタートの要素が必要になる場合がありますが、それは、クロステナントのパフォーマンスの影響を制限するための効果的な戦略にもなります。

応答性のあるスケーリング戦略はこの問題を解決するのに役立ちますが、単にテナントがクロステナントに影響を与えるような負荷をかけることを防ぐためだけであれば、他の対策を講じることもできます。これらのシナリオでは、システム上の負荷のレベルを制御するためにスロットリングを適用する制限 (階層別の制限も可能) を設定することによって、テナントのアクティビティを検出して制限することもできます。これは、テナントの負荷を調査し、制限を超えるアクティビティを特定し、その経験をスロットリングするポリシーを導入することで実現できます。

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

SaaS 企業のビジネスモデルは、多くの場合、インフラストラクチャのコストをテナントの実際のアクティビティに合わせる戦略に大きく依存しています。SaaS システムのテナントの負荷や構成は常に変化しているため、SaaS 体験の一部であるリアルタイムで予測不可能な消費パターンを非常によくミラーリングしたパターンで、リソースの消費を効果的にスケーリングできるアーキテクチャ戦略が必要です。

図 23 のグラフは、インフラストラクチャの消費とテナントのアクティビティを調整した環境の仮想的な例を示しています。青の実線は、ある期間にまたがるテナントの実際のアクティビティ傾向を表し、赤色の破線は、テナントの負荷に対応するためにプロビジョニングされている実際のインフラストラクチャを表しています。

図 23: テナントのアクティビティと消費の調整

ここでの戦略は、理想的な環境において、赤色の線と青色の線とのギャップをできるだけ小さくすることです。ここでは、システムの可用性やパフォーマンスに影響を与えないようにするためのクッションがあるため、常に多少の誤差が生じます。同時に、テナントの現在のパフォーマンスニーズをサポートするのに十分なインフラストラクチャを提供できるようにする必要があります。

ここでの主な課題は、この図に示されている負荷が予測できないことが多いということです。一般的な傾向は考えられますが、アーキテクチャやスケーリングの戦略では、今日の負荷が明日も、あるいは 1 時間後も同じであると想定することはできません。

消費とアクティビティを調整するための最もシンプルなアプローチは、サーバーレスな体験を提供する AWS のサービスを利用することです。これの典型的な例としては、AWS Lambda があります。AWS Lambda を使用することで、サーバーやスケーリングポリシーが自分の責任ではないモデルを構築することができます。サーバーレスの場合、SaaS アプリケーションには、テナントの消費と直接関係のある料金しか発生しません。SaaS システムに負荷がなければ、AWS Lambda コストはかかりません。

また、AWS Fargate を使用すると、このサーバーレスマインドセットのコンテナベースのバージョンが可能になります。Fargate を Amazon EKS または Amazon ECS と合わせて使用すると、アプリケーションで実際に消費されるコンテナの計算コストのみを支払うことになります。

このサーバーレスモデルは、コンピューティング構造を超えて使用できます。例えば、ソリューションのストレージ部分にも、サーバーレステクノロジーを利用できます。Amazon Aurora Serverless では、データベースを実行しているインスタンスのサイズを調整することなく、リレーショナルデータを保存することができます。その代わり、Amazon Aurora Serverless では実際の負荷に基づいて環境のサイズが決定され、アプリケーションが消費する分だけ料金が請求されます。

スケーリングポリシーを作成する必要性のないモデルでは、運用とコストの経験が合理化されます。とらえどころのない完璧な自動スケーリング設定を求め続けるのではなく、アプリケーションの機能に時間とエネルギーを集中させることができます。さらに、AWS の請求額の予期せぬ跳ね上がりを気にすることなく、ビジネスを成長させ、新たなテナントを受け入れることも可能になります。

サーバーレスが選択肢にない場合は、従来のスケーリング戦略に立ち戻る必要があります。これらのシナリオでは、テナントの消費メトリクスを取得して公開し、これらのメトリクスに基づいてスケーリングポリシーを定義する必要があります。