モニタリング

SaaS ソリューションは、多くの場合、テナントがさまざまな経験を利用できるように階層化されたモデルで提供されます。パフォーマンスは多くの場合、SaaS 環境の階層を差別化するために使用される領域であり、テナントに高レベルの階層への移動を促すための値の境界を作成する方法として使用されます。

このモデルでは、各階層の体験をモニタリングし、制御するための構造をアーキテクチャが導入されます。これは単にパフォーマンスを最大化するだけではなく、低階層のテナントの消費を制限することにもなります。たとえシステムがこれらのテナントの負荷に対応できたとしても、純粋にコストやビジネス上の配慮から、この負荷を制限することになる場合もあります。これは多くの場合、テナントのコストの規模と、テナントによるビジネスへの貢献がもたらす収益との相関性を確保するための手段の一部になります。

この問題にアプローチするための最も複雑さの少ない方法は、個々のテナント層に関連付けられたスロットリングポリシーの導入です。テナントが制限に達すると、スロットリングが適用され、消費が制限されます。

また、特定の AWS 構成を使用してテナント層の消費プロファイルを設定するシナリオもあります。例えば、AWS Lambda では、同時実行の予約を使用して、特定のテナント層の消費を制限することができます。図 24 は、これがどのようにして実現されるかを示しています。

図 24: 同時実行の予約によるテナントパフォーマンスの制御

この例では、3 つの異なるテナントの階層を作成し、それぞれの階層に SaaS アプリケーションのマイクロサービスを 3 つの別々のコレクションとしてデプロイしています。また、これらのコレクションは、そのグループの関数に対して実行可能な同時実行関数の呼び出し数を決定するために使用される、個別の同時実行の予約設定で構成されます。ベーシック階層には 100、アドバンスト階層には 300 の同時実行の予約があります。ここでは、プレミアム階層の残りの同時実行はすべて残され、下層の消費が制限されるという考え方になります。

このアプローチは、優先順位の高い層に最高の体験を提供し、リソースを過剰に消費して上位層のテナントのパフォーマンスに影響を与えないように下位層を制限するという当社の目標にうまく合致しています。

また、コンテナには、階層化を対処することによってパフォーマンスを実現するための独自の戦略があります。例えば、Amazon EKS では、個別の ResourceQuotas と LimitRanges を構成して、名前空間で利用可能なリソースの量を制御します。

これらの制約はテナントのパフォーマンスエクスペリエンスを構成するのには役立ちますが、SaaS アプリケーションの中には、アプリケーション設計と分解の戦略によって実際にパフォーマンスに対処するものもあります。これは、上位層のテナント向けにサイロ化されたマイクロサービスをデプロイすることで実現できますが、その場合は、これらの特定のサービスに対する他のテナントによる影響を考慮する必要がなくなります。実際、システムのマイクロサービスへの分解は、階層化とターゲットにするパフォーマンスプロファイルに直接影響されることがわかります。

場合によっては、SaaS アプリケーションに、より高いレベルのテナントのエクスペリエンスを最適化するアーキテクチャ構造を導入することもできます。例えば、プレミアム階層のテナントに重要なデータのキャッシングを提供すると仮定します。キャッシュをこれらのユーザーだけに限定すれば、すべてのユーザーをサポートするキャッシュにかかる費用を回避することができます。これらの最適化を導入するための労力は、投資を保証するための十分な価値を顧客とビジネスに提供することでオフセットする必要があります。