基盤

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

マルチテナント環境におけるテナントのワークロードは、常に変化します。テナントが異なるタイプの負荷をシステムにかける場合があります。新しいワークロードプロファイルを持つ新規のテナントが、継続的にシステムに追加されることもあります。これらの要因により、SaaS 企業にとって、こういった拡大するニーズに応え、対応できる十分な耐障害性を持ったアーキテクチャを構築することは非常に難しくなっています。

このような負荷の変動は、テナントの操作性に悪影響を及ぼす可能性があります。1 つのテナントがシステムの一部に極度な負荷をかけた場合を想像してみましょう。API 経由でシステムを利用できる場合は、これは特に顕著となります。この場合、このテナントの負荷はシステムのリソースを過剰に消費することになり、さらにシステム全体の信頼性または他のテナントの操作性に影響を与えます。

あるテナントが他のテナントに影響を与える可能性があることは、階層サービスのあるシステムではより複雑な問題になります。例えば、システムにベーシック、アドバンスト、プレミアム階層があるとします。これらの各階層がシステムにどの程度の負荷もかけられる場合、ベーシック階層がプレミアム階層のテナントの信頼性に影響を及ぼす場合があります。

マルチテナント環境では、システムの信頼性に影響を与えうるワークロードと利用パターンの特定に、特に積極的に取り組む必要があります。マルチテナント環境における信頼性の問題は、システム全体に広がりやすく、さらにはすべての顧客の操作性に影響を与える可能性もあります。

これらのワークロードの問題に対処するため、ワークロードの問題がアプリケーションの信頼性に影響を及ぼす前に、それを検知し、解決するメカニズムをシステムに導入する必要があります。

アプリケーションとアプリケーションスタックのアーキテクチャは、テナントがシステムの信頼性と他のテナントの操作性に影響を及ぼさないために採用する戦略に影響があります。一般的なアプローチの 1 つとしては、スロットリングを使用して、テナントによる過度なリソースの消費を防ぐ方法があります。図 21 はそれを Amazon API Gateway を使って行う例を示しています。

この例では、API Gateway で使用量プランを活用して、システム内の各テナントに対して別々の使用量を定義していることがわかります。このアプローチでは、異なる API キーをシステムのベーシックおよびアドバンスト階層に対して使用します。これらのキーは異なる SLA の使用量プランにつながっています。このアプローチにより、2 つの異なるレベルでの制御が可能になります。まず、使用量プランの設定を通じたリクエストによって、すべてのテナントがシステムを飽和状態にしないようにします。もう 1 つのメリットは、使用量設定を使って、低い階層のテナントが高い階層のテナントの操作性に影響を及ぼすことがないようにできます。

このモデルは API Gateway を基盤としてスロットリングポリシーを実装しますが、この中核となる概念は他のインフラストラクチャ構造に適用できます。このアプローチの基本的な目的は、エントリポイントでアプリケーションへのアクセスをモニタリングして管理し、環境の全体的な信頼性に影響を与える可能性がある負荷をかけているテナントを検知し、スロットリングすることです。

図 21: 階層ごとにテナントをスロットリングする

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

SaaS 環境の信頼性は、問題がテナントに影響を及ぼす前に、前もって特定し解決できるプロバイダーの能力に大きく左右される傾向にあります。マルチテナント環境において、健全性を積極的に把握するためには、テナントのワークロードの健全性の状況について、より詳細でテナントに対応したインサイトが得られる追加の信頼性データを取得する必要があります。

これらのテナントに対応したインサイトは、テナント固有の傾向、アクティビティ、インサイトの特定に使用され、そのテナントの信頼性またはシステム全体の信頼性に影響を及ぼす状況を効果的に把握できるようになります。このデータを保持し、積極的に確認することで、アラーム、ポリシー、停止状態に陥ることなくシステムの修復を試みる自動化を構築できます。

これを可能にするには、アプリケーションにコードを導入して、テナントのコンテキストとともに健全性のインサイトを作成する必要があります。これはまず、有益な健全性データである、アーキテクチャのワークフローとイベントを特定することから始めます。消費データ、スケーリングインサイト、レイテンシーメトリクスなどが該当します。これらのインサイトはログファイル経由で、またはデータを蓄積するデータウェアハウスに作成されます。

リポジトリにこの健全性データが蓄積された後、蓄積した健全性データの分析に基づき、アラームを出すツール、またはポリシーをトリガーするツールを導入します。

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

マルチテナント環境のテストモデルは、単にアプリケーションの機能が想定どおりに機能することを確認するのみにとどまりません。SaaS プロバイダーは、システムが効果的にマルチテナントソリューションに関連する一般的な信頼性の問題に対応できることを検証するテストを構築する必要もあります。

マルチテナントのテスト戦略の一部として含められるさまざまな観点があります。多くの場合、これらのテストは現在ある構造を検証して、SaaS 製品のスケーリング、運営、信頼性のフットプリントに対応することを目的としています。

SaaS テストは大抵の場合、アプリケーションが経験する極端な状態をシミュレーションします。システムが想定内と想定外の状況にどのように対応するかを効果的にモデル化し、評価できる一連のテストの構築に注力する必要があります。顧客が満足できる操作性を確保することに加え、どの程度のコスト効率性でスケーリングを実現できるかも、テストでは考慮する必要があります。アクティビティに対して過剰なリソースを割り当てている場合、ビジネスの収益に影響を及ぼしていることがあります。

SaaS 環境における負荷とパフォーマンスのテスト戦略を向上する特定の領域には以下のものがあります。

• クロステナントインパクトテスト – テナントのサブセットがシステムに過度な負荷をかけるシナリオをシミュレーションするテストを作成します。これにより、負荷がテナント間で均等に分散していない場合のシステムの対応方法を決定でき、それが全体的なテナントの操作性にどのような影響を及ぼすかを評価できます。システムが個別にスケーラブルなサービスに分割されている場合、各サービスのスケーリングポリシーを検証するテストを作成して、適切な条件に基づきスケーリングしていることを確認することもできます。

• テナントの消費量テスト – 幅の広い負荷プロファイル (変化が少ない、急増、ランダムなど) を作成して、リソースとテナントアクティビティメトリクスの両方を追跡し、消費量とテナントアクティビティの差分を特定します。最終的にはこの差分をモニタリングポリシーの一部として使用し、最適でないリソースの消費を特定できます。また、このデータを他のテストデータとともに使用して、インスタンスが適切なサイズになっているか、IOPS が適切に設定されているか、AWS のフットプリントが最適化されているかを判断できます。

• テナントワークフローテスト – これらのテストを使用して、SaaS アプリケーションの異なるワークフローがどのようにマルチテナントコンテキストの負荷に対応しているかを評価します。ソリューションの中でよく知られたワークフローを選び、これらのワークフローに複数のテナントによる負荷を集中させ、マルチテナント設定でボトルネックまたはリソースの過剰な割り当てを引き起こしたかを確認します。

• テナントのオンボーディングテスト - テナントによるシステムへのサインアップに際しては、テナントが肯定的な体験をできるようにし、オンボーディングフローに回復性、拡張性、効率性を備えさせておく必要があります。これは特に、SaaS ソリューションによってオンボーディングプロセス時にインフラストラクチャをプロビジョニングする場合に当てはまります。アクティビティの急増がオンボーディングプロセスに悪影響を与えないように確認する必要があります。また、サードパーティの統合 (課金など) を利用するような場合には、これらの統合が SLA をサポートしているかどうかを検証する必要があります。場合によっては、これらの統合で起こり得る停止に対処するためのフォールバック戦略を実装します。これらのケースでは、これらのフォールトトレランスメカニズムが期待どおりに動作するかどうかを検証するテストを導入する必要があります。

• API スロットリングテスト - API スロットリングの考え方は、SaaS ソリューションに固有のものではありません。一般的に、API を公開する場合には、スロットリングの概念を含める必要があります。また、SaaS では、異なる階層のテナントが API を介してどのように負荷をかけることができるかを考慮する必要があります。例えば、無料利用枠のテナントは、ゴールド階層のテナントと同じ負荷をかけることができないようにすることもできます。テストを行えば、各階層に関連付けられたスロットリングポリシーが正常に適用され、実施されていることを確認することができます。

• データ配信テスト - ほとんどの場合、SaaS のテナントデータが一律に配信されることはありません。テナントのデータプロファイルの変化は、データフットプリント全体のバランスを崩す可能性があり、ソリューションのパフォーマンスとコストの両方に影響を与える可能性があります。この動的な要素を相殺するために、SaaS チームは通常、これらのバリエーションを考慮して管理するシャーディングポリシーを導入します。シャーディングポリシーは、ソリューションのパフォーマンスとコストプロファイルに欠かせないものであり、優先順位の高いテスト候補となります。データ配信テストを行うと、システムが遭遇する可能性のあるテナントデータのさまざまなパターンについて、採用したシャーディングポリシーがうまく配信できるかどうかを検証することができます。これらのテストを早期に実施すれば、大量の顧客データを保存した後に新しいパーティショニングモデルに移行する際にかかる高額なコストを避けることができます。

• テナントの分離テスト - SaaS の顧客は、自分たちの環境が保護され他のテナントからアクセスできないように、あらゆる対策が講じられることを期待しています。この要件をサポートするために、SaaS プロバイダーは、各テナントのデータとインフラストラクチャを保護するための多数のポリシーとメカニズムを構築しています。これらのポリシーの実施を継続的に検証するテストの導入は、どの SaaS プロバイダーにとっても不可欠です。

ご覧のように、このテストリストでは、SaaS ソリューションがマルチテナントのコンテキストで負荷を処理できるようにすることに重点を置いています。SaaS の負荷は予測できないことが多いため、これらのテストは、テナントの 1 つまたはすべてが影響を受ける前に、主要な負荷やパフォーマンスの問題を発見する絶好の機会となります。場合によっては、これらのテストで新たな変曲点が明らかになることもあるため、システムの運用ビューに含めてもよいかもしれません。