プール分離
分離サイロモデルは多くの SaaS 企業で非常にうまく位置づけられていることがわかります。SaaS に移行している企業の多くは、テナントに基盤インフラストラクチャの一部またはすべてを共有できる、効率性、俊敏性、コスト面での利点を求めています。この共有インフラストラクチャアプローチは、プールモデルと呼ばれ、分離の議論に一定の複雑さを付加しています。図 17 はプールモデルでの分離の実装に関連する課題を表しています。
図 17: プール分離モデル
このモデルでは、すべてのテナントで共有しているインフラストラクチャを、テナントが利用していることがわかります。これにより、リソースをテナントによる実際の負荷に正比例してスケーリングできます。図の右側は 1 つのサービスをコンピューティングの観点から詳しく表したものです。テナント 1 から N までがすべて、特定の時間に共有コンピューティング内で隣り合って実行する可能性があることを示しています。この例のストレージもまた共有されており、個別のテナント識別子でインデックス付けされたテーブルとして示しています。
このモデルは SaaS プロバイダーにとっては適切に機能しますが、分離の議論全体を複雑にする可能性があります。共有されたリソースで分離を実装することは、それほどわかりやすく典型的なネットワーキングではなく、テナント間の境界作成は IAM 構造に依存できません。
この重要な点は、分離がより難しい環境であるものの、それを理由にして環境の分離要件の緩和はできないということです。共有モデルではクロステナントアクセスの可能性が増加するため、リソースが分離されていることの確認を徹底する必要がある領域といえます。
プール分離モデルを掘り下げると、このアーキテクチャ上のフットプリントは課題が独自に交じり合っており、テナントのリソースを適切に分離するには、それぞれに独自のタイプの分離構造が必要となることがわかります。
プールモデルのメリットとデメリット
すべてを共有することで高い効率性と最適化を実現できますが、SaaS プロバイダーはこのモデルの採用に伴ういくつかのトレードオフを強調する必要があります。多くの場合、プールモデルのメリットとデメリットは、サイロモデルで取り上げたメリットとデメリットの逆となります。以下は一般的にプール分離モデルに関わる主なメリットとデメリットです。
メリット
-
俊敏性 – テナントを共有インフラストラクチャモデルに移行すると、その特性である効率性とシンプルさを利用して、SaaS サービスの俊敏性を整備できます。基本的にプールモデルは、SaaS プロバイダーが統一された単一の操作性でテナントすべての管理、スケーリング、運営ができるようにするためのものです。操作性の一元化と標準化は、SaaS プロバイダーがより簡単に管理を行い、テナントごとに 1 回限りのタスクを実行する必要なく、すべてのテナントに変更を適用できるようにする基盤となります。このオペレーション上の効率性は、SaaS 環境の全体的な俊敏性のフットプリントの鍵となります。
-
コスト効率性 – 多くの企業は SaaS の高いコスト効率性に魅力を感じています。このコスト効率性の大部分は、一般的に分離のプールモデルによるものです。プールされた環境では、システムはすべてのテナントによる実際の負荷とアクティビティに基づきスケーリングします。すべてのテナントがオフラインであれば、インフラストラクチャコストは最小限になります。この主要な概念としては、プールされた環境はテナント負荷に動的に適応でき、テナントアクティビティをリソース使用量により最適に合わせられることにあります。
-
管理と運営の簡素化 – 分離のプールモデルでは、システム内のすべてのテナントを一括で確認できます。すべてのテナントの管理、更新、デプロイが、システム内のすべてのテナントに対応する単一の操作で可能です。これにより、管理と運営に関わるフットプリントのほとんどの部分が簡素化されます。
-
イノベーション – プールされた分離モデルによって実現する俊敏性は、SaaS プロバイダーが迅速なペースでイノベーションを実行するための中核となり得ます。分散型の管理、サイロモデルの複雑さから離れるほど、製品の性能と機能により重点を置けるようになります。
デメリット
-
他のテナントによる影響 – リソースが共有されるほど、あるテナントが他のテナントの操作性に影響を及ぼす可能性は高くなります。例えば、あるテナントのアクティビティによってシステムに大きな負荷がかかると、他のテナントに影響を生じさせる場合があります。適切なマルチテナントアーキテクチャと設計ではこれらの影響を抑制しようとしますが、プールされた分離モデルでは、他のテナントの状況によって 1 つ以上のテナントが影響を受ける可能性が常にあります。
-
テナントコストの追跡 – サイロモデルでは、非常に簡単にリソースの消費を特定のテナントに紐付けられます。一方、プールされたモデルでは、リソースの消費を紐付けることはより難しくなります。各 SaaS プロバイダーはシステムを測定して、効果的に消費量を個々のテナントに紐付けるために必要な詳細データを取得する方法を見つける必要があります。
-
影響範囲を軽減 – すべての共有リソースを共有することは、オペレーションリスクにもつながります。サイロモデルでは、あるテナントに障害が発生すると、大抵の場合その障害の影響はそのテナントのみに限定されます。一方、プールされたモデルでは、停止はシステム内のすべてのテナントに影響する可能性が高く、ビジネスに大きな影響を及ぼす場合があります。通常、障害を特定して明らかにし、スムーズに障害から復旧できるよう、耐障害性の高い環境の構築に対して、より高いコミットメントを必要とします。
-
コンプライアンスによる抵抗 – プールモデルのテナントを分離できる手段はあるものの、インフラストラクチャの共有という概念によって、このモデルで実行することを躊躇させる状況になる場合があります。特に、ドメインのコンプライアンスまたは規制ルールで、リソースのアクセシビリティと分離に厳格な制限がある環境が該当します。そのような場合、システムの一部分については、サイロ化する必要性が生じる場合があります。
