集中型デプロイパターンと分散型デプロイパターンの比較

OPA は集中型または分散型のデプロイパターンでデプロイでき、マルチテナントアプリケーションに最適な方法はユースケースによって異なります。これらのパターンの例については、このガイドの前半のPEPs を使用した集中型 PDP APIs の使用PEPs APIs」セクションを参照してください。OPA はオペレーティングシステムまたはコンテナにデーモンとしてデプロイできるため、マルチテナントアプリケーションをサポートするために複数の方法で実装できます。

一元化されたデプロイパターンでは、OPA はコンテナまたはデーモンとしてデプロイされ、RESTful API はアプリケーション内の他のサービスで使用できます。サービスが OPA からの決定を必要とする場合、中央 OPA RESTful API が呼び出されて、この決定が生成されます。このアプローチは、OPA のデプロイが 1 つしかないため、デプロイと保守が簡単です。このアプローチの欠点は、テナントデータの分離を維持するメカニズムがないことです。OPA のデプロイは 1 つだけであるため、OPA が参照する外部データを含め、OPA の決定で使用されるすべてのテナントデータを OPA が利用できる必要があります。この方法でテナントデータの分離を維持できますが、OPA のポリシーとドキュメント構造、または外部データへのアクセスによって強制される必要があります。一元化されたデプロイパターンでは、各認可決定が別のサービスに対して RESTful API コールを行う必要があるため、レイテンシーも長くする必要があります。

分散デプロイパターンでは、OPA はマルチテナントアプリケーションのサービスと共にコンテナまたはデーモンとしてデプロイされます。サイドカーコンテナとしてデプロイすることも、オペレーティングシステムでローカルに実行されるデーモンとしてデプロイすることもできます。OPA から決定を取得するために、サービスはローカル OPA デプロイに対して RESTful API コールを実行します。(OPA は Go パッケージとしてデプロイできるため、RESTful API コールを使用する代わりに Go をネイティブに使用して決定を取得できます）。一元化されたデプロイパターンとは異なり、分散パターンはアプリケーションの複数の領域に存在するため、デプロイ、保守、更新にははるかに堅牢な労力が必要です。分散デプロイパターンの利点は、特にサイロ化された SaaS モデルを使用するアプリケーションでは、テナントデータの分離を維持する機能です。分散モデルの OPA はテナントと一緒にデプロイされるため、テナント固有のデータは、そのテナントに固有の OPA デプロイで分離できます。さらに、各認可の決定をローカルで行うことができるため、分散デプロイパターンのレイテンシーは集中型デプロイパターンよりもはるかに低くなります。

マルチテナントアプリケーションで OPA デプロイパターンを選択する場合は、アプリケーションにとって最も重要な基準を必ず評価してください。マルチテナントアプリケーションがレイテンシーの影響を受けやすい場合、分散デプロイパターンは、より複雑なデプロイとメンテナンスを犠牲にして、パフォーマンスを向上させます。DevOps と自動化によってこの複雑さの一部を管理できますが、一元化されたデプロイパターンと比較して、さらに多くの労力が必要になります。

マルチテナントアプリケーションがサイロ化された SaaS モデルを使用している場合は、分散 OPA デプロイパターンを使用して、テナントデータ分離に対するサイロ化されたアプローチを模倣できます。これは、各テナント固有のアプリケーションサービスと一緒に OPA を実行する場合、各 OPA デプロイをカスタマイズして、そのテナントに関連付けられているデータのみを含めることができるためです。一元化された OPA デプロイパターンで OPA データをサイロ化することはできません。一元化されたデプロイパターンまたは分散パターンをプールされた SaaS モデルと組み合わせて使用する場合、テナントデータの分離は OPA ドキュメントモデルで維持する必要があります。