サイロモデル、プールモデル、ブリッジモデル

SaaS アプリケーションを構築するアーキテクチャモデルには、さまざまな種類があります。規制、競争力、戦略、コスト効率、マーケットごとの検討事項など、すべてが SaaS アーキテクチャの形になんらかの影響を与えます。これと同時に、SaaS アプリケーションの規模の定義には、戦略やパターンがあります。このパターンには「サイロ、ブリッジ、プール」の 3 つのカテゴリがあります。

まずサイロモデルとは、テナントに専用リソースが提供されるアーキテクチャです。SaaS 環境で、システムの各テナントが完全に独立したインフラストラクチャスタックを所有している状況を想像してください。または、システムの各テナントがそれぞれ別のデータベースを持っているとしましょう。テナントのリソースの一部または全部が、このように専用のリソースとしてデプロイされている場合、これをサイロモデルと呼びます。サイロ環境は専用のリソースを有しますが、アイデンティティ、オンボーディング、オペレーションが共有に依存することは同じであり、すべてのテナントは共有構造で管理およびデプロイされるという点に注意する必要があります。これが SaaS がマネージド型サービスモデルとは異なる点です。後者では、顧客は個別のオンボーディング、管理、オペレーション機能を使い、独自バージョンのシステムを実行する場合もあります。

これと反対に、SaaS のプールモデルとは、テナントがリソースを共有しているシナリオを指します。これはマルチテナントの古い概念で、テナントはスケールメリット、管理のしやすさ、俊敏性などの理由で、共有のスケーラブルなインフラストラクチャに依存しています。このような共有リソースは、コンピューティング、ストレージ、メッセージングなど、SaaS アーキテクチャの一部または全部の要素に適用できます。

最後のパターンはブリッジモデルです。ブリッジとは、SaaS ビジネスは必ずしもサイロまたはプールのどちらかに分類されるわけではないということを表しています。むしろ多くのシステムでは、混合モードにして、サイロモデルとプールモデルのシステムを併用しています。例えば、アーキテクチャにおける一部のマイクロサービスの実装にサイロを使用し、その他のサービスにプールを使用するような場合があります。サービスデータの規制のプロファイルと他のテナントによる影響の可能性は、マイクロサービスにサイロモデルを採用する理由になる場合があります。その一方で、俊敏性、アクセスパターン、コストプロファイルの課題などは、プールモデルを選択する理由になるでしょう。