マルチテナントのマイクロサービス

マルチテナント環境で実行中のマイクロサービスは、さらなる考慮事項に対処する必要があります。これらのマイクロサービスは、各サービス内でテナントのコンテキストを参照し適用できるようにする必要があります。同時に、デベロッパーがテナントへの認識をコードに導入する必要性の度合いを制限することも目標です。

この目標を達成するために、SaaS マイクロサービスは、コンピューティングモデルに関わらず、テナント固有の処理をコードにプッシュできる、ライブラリ、モジュール共有構造を導入する必要があります。この構造は、テナントのコンテキストを解決および適用するために必要なポリシーとメカニズムを隠します。

図 10 は、マイクロサービスのマルチテナントの開発をどのように効率化できるかを示しています。ここにおける鍵となるアイディアは、テナントのコンテキストに依存するすべてを取り、ライブラリを使用してマルチテナントのポリシーを適用するということです。

この例は、SaaS マイクロサービスがテナントのコンテキストにアクセスする必要があるシナリオをいくつか示しています。フローは、製品のリストを取得するリクエストを持つ、マイクロサービスへの呼び出しから始まります。サービスのコードのどこかで、サービスがメッセージを記録します。マイクロサービスのデベロッパーは単に、ロギングラッパーにメッセージを記録します。このラッパーはトークンマネージャーからテナントのコンテキストを取得し、そのコンテキストを挿入し、この例では Amazon S3 に発行されます。ログポリシーとテナントデータがどのようにログに到達するかは、ロギングヘルパーに含めることにしたいずれかのポリシーによって管理されます。

このテーマが、ここでのエクスペリエンスの残りの部分で継続されます。getProducts() への呼び出しは、まずトークンマネージャーからテナント ID を取得します。次に、このコンテキストを使用して、DynamoDB から製品データを取得するためにこの認証情報を使用する前に、テナント範囲の認証情報を隔離マネージャーから取得します。

図 10: マルチテナントのマイクロサービスの開発

最後に、テナント ID を解決し、テナントのコンテキストを指標メッセージに挿入するのと同じ仕組みを使用して、サービスは指標 (おそらく実行時間) を記録します。

ここで説明した実践は、マイクロサービスに大規模な構造を導入することを意図したものではありません。このテナンシーの抽象化は、共通の概念を共有コードにプッシュするという一般的な設計プラクティスに従っています。この図で表されたすべての概念が、単一マイクロサービスのコンテキスト内で実行される点は重要です。これらの各ブロックは単純に、マイクロサービスによって再利用されるコードを表します。これらの概念を個別のサービスに分割すると、遅延と複雑性が高まり、通常は理想的ではありません。