フルスタック隔離

SaaS 組織はテナント間の共有インフラストラクチャが伴う規模の経済によって動かされています。同時に、環境内のテナントの一部またはすべてが専用の (サイロ化された) インフラストラクチャを必要とする、SaaS アーキテクチャが結果として生まれる可能性のある現実的な要因があります。コンプライアンス、他のテナントによる影響、階層戦略、従来の技術などは、テナントに独自のインフラストラクチャを提供する結果となる多くの考慮事項の一部です。これは、サイロ化またはフルスタックの隔離 SaaS と呼ばれます。

このアプローチは、個人の顧客に 1 回限りの方法で企業の製品がインストールおよび管理される、マネージドサービスプロバイダー (MSP) とよく間違われます。このアプローチは有効なものの、SaaS の主義とは合致しません。SaaS モデルへの鍵は、単一の統合されたエクスペリエンスを通して、すべてのテナントが管理および運用される、価値システムを採用することです。これは、すべてのテナントがソフトウェアの同じバージョンを実行し、同時にデプロイされ、同じプロセスを通してオンボードされ、すべてのテナントに適用される単一の運用エクスペリエンスを通してすべて管理されることを意味します。

このアプローチでは、共有インフラストラクチャモデル (プール) のコスト効率性は実現されません。その分散された性質によっても、運用とデプロイがより複雑になります。それでも、正しく行えば、フルスタックモデルで、SaaS の考え方の中心である俊敏性、革新性、運用の効率性の目標を達成することができます。

図 7 は、フルスタック隔離 (サイロ) モデルのわかりやすい全体像です。このモデルの各テナント環境は明快です。各テナントに独立した VPC を提供したことがわかります。これらの VPC は、各テナントによって使用される完全に隔離されたスタックを持ちます。コンピューティングとストレージの構造は、AWS のサービスのあらゆる組み合わせで構成できます。各テナント環境が、同じインフラストラクチャ構成と、同じ製品のバージョンを持つようになっていることが鍵です。そのため、新しいテナントを追加することは、各テナントの同じインフラストラクチャのフットプリントを持つ別の VPC を追加するのと同じくらいシンプルです。

また、このモジュールは Amazon Route 53 を使用して受信トラフィックを適切な VPC にルーティングしていることがわかります。ルーティングは、サブドメインが各テナントに割り当てられているモデルに依存しています。これは SaaS 環境で非常に一般的なパターンです。このルーティングは、テナント JWT トークンの内容を調べ、テナントのコンテキストを決定し、挿入されたテナントのヘッダーを通してルーティングのルールをトリガーすることでも実現できます。ただし、このアプローチは、アカウントの制限に達し、テナントの ID のランタイム解決の遅延に対応するための調整が必要となる場合があります。それでも、これは一部の SaaS 環境では有効な選択肢です。

図 7: フルスタック (サイロ) 隔離

この例はテナントごとの VPCモデルを図示しているものの、フルスタックモデルの実装に使用できる他のアーキテクチャがあります。一部の組織では、各テナント環境が個別のプロビジョニングされたアカウントにデプロイされる、テナントごとのアカウントモデルの使用を選択する場合があります。選択するオプションは、サポートする必要があるテナント数と、目標とする全体的な管理エクスペリエンスによって変わります。サポートする必要のあるテナント数が、AWS アカウントで作成可能な VPC 数を超える場合があります。

統合されたオンボード、管理、運用

フルスタック隔離 (サイロ) モデルの実際の SaaS 要素は、このエクスペリエンスのオンボード、管理および運用を考えるときに現れます。SaaS の完全な価値提案を実現するために、このモデルはテナント環境すべてを管理および運用するために使用できる、一連のサービスを導入する必要があります。

図 8 は、これらの追加のサービスレイヤーを表しています。ここで紹介するのは、SaaS プロバイダーの管理エクスペリエンスのニーズの周囲に構築された、完全に独立した一連のサービスです。

図 8: フルスタックの隔離環境の管理

テナント環境のスタックは、ドメイン、レガシー、およびその他の要件により形作られますが、管理エクスペリエンスのスタックは、テナントに適用されるものとはまったく異なる目標と使用パターンによって決まる場合があります。

この管理は、従来のサーバーレスの SaaS アプリケーションモデルと非常によく合致します。管理環境に 2 つのエントリポイントがあることがわかります。1 つは、Amazon CloudFront と Amazon S3 を使用する管理アプリケーションで、テナント環境を管理および構成するために SaaS 管理者によって使用されるアプリケーションのエクスペリエンスを提供するためのものです。また、サインアップと API のエクスペリエンスがハイライトされていることがわかります。これは、パブリック API リクエストを介してテナントのオンボードをトリガーできることを表します。この API は、SaaS プロバイダーのデベロッパーの API エクスペリエンスの一部にもなります。

最後に、オンボード、管理、運用のエクスペリエンスを統制するために使用される共有サービスである一連のマイクロサービスが示されています。管理、規模、コスト効率のモデルに基づいて、マイクロサービスのモデルとして Lambda を選択しました。これらのサービスは他の AWS コンピューティングサービスを使用して実装できます。

図の右側には、各テナント環境を表す個々の VPC があります。このテナントあたりのVPCモデルでは、管理プレーンがこれらのテナント環境のリソースを構成し、それにアクセスできるようにするために、有効なパスを開く必要があります。このために、AWS は AWS PrivateLink、VPC ピアリング、Amazon EventBridge などの多くのオプションを提供しています。選択するオプションは、構築する管理エクスペリエンスの性質により変わります。