的を絞った分離

システムでの分離オプションは、非常に細分化されることを理解しておくことが重要です。システムの各マイクロサービス、およびそのサービスが使用する各リソースには、異なる分離モデルを設定できるオプションがあります。マイクロサービスの例をいくつか確認し、異なるマイクロサービス間で分離モデルを変える方法について理解を深めましょう。図 20 は、分離のサイロモデルとプールモデル両方を使用するマイクロサービスを表しています。

この図から、システムは 3 つの異なるマイクロサービスである、製品、注文、アカウントを実装していることがわかります。これらのマイクロサービスそれぞれのデプロイおよびストレージモデルは、どのように SaaS 環境で分離 (セキュリティまたは他のテナントによる影響の分離) が行われているかを示しています。

これらサービスそれぞれの分離モデルを確認していきましょう。右上にある製品のマイクロサービスは、完全なプールモデルにデプロイされており、コンピューティングとストレージの両方がすべてのテナントに共有されています。すべてのテナントが同じテーブルでインデックス付けされた個別のアイテムとなっていることを、こちらのテーブルでは反映しています。前提として、このテーブルのテナントアイテムへのアクセスを制限できるポリシーでもって、データは分離されます。注文のマイクロサービスは、テナント 1 から 3 専用で、プールモデルに実装されています。こちらの唯一の違いは、テナントのサブセットをサポートしている点です。基本的には、注文のマイクロサービスの専用 (サイロ) デプロイがされていないテナントは、このプールされたデプロイで実行します (サイロマイクロサービスとして除外された一部のテナント以外のテナント 1 から N とします)。

この点を説明するため、専用の注文のマイクロサービス (右上) とアカウントのマイクロサービス (下) で表されているサイロ化したサービスに注目しましょう。テナント 4 と 5 に対して、注文のマイクロサービスのスタンドアロンインスタンスをデプロイしていることがわかります。この理由は、これらのテナントは注文処理に関する要件 (コンプライアンス、他のテナントによる影響など) があり、このサービスをサイロモデルでデプロイする必要があったためです。こちらでは、コンピューティングとストレージは両方とも、完全に各テナント専用となっています。

最後に、下にあるアカウントのマイクロサービスはサイロモデルを表していますが、ただしストレージレベルのみです。マイクロサービスのコンピューティングはすべてのテナントに共有されていますが、各テナントにはアカウントデータを保持するための専用データベースがあります。このシナリオでは、分離に関わる懸念事項は、データの分離のみに絞られます。コンピューティングは共有することが可能です。

図 20: 的を絞った分離

このモデルはサイロに関する議論がより細分化することを示しています。セキュリティ、他のテナントによる影響、さまざまな要因によって、どのようにかつどういう場合にサイロ分離モデルをサービスに採用するかが決まります。こちらでの重要なポイントは、サイロモデルは使うか、使わないかのみの判断に限らないということです。サイロモデルをアプリケーションの特定のコンポーネントで使用することを検討できます。また、見込み顧客がこのモデルの使用を求めた場合など、必要な場合にのみこのモデルの課題を受け入れます。この場合、顧客とのより詳細な議論で、ストレージと処理における特定の領域にのみ懸念があることがわかります。そうすることにより、サイロ分離を必要としないシステムのその部分のプールモデルの効率性が得られると同時に、階層ストラクチャを提供できる柔軟性が確保でき、個々のサービスにおいてサイロモデルとプールモデル両方の組み合わせをサポートできます。