次の方法で共有

マルチテナント SaaS アプリケーションと Azure AI Search の設計パターン

  • [アーティクル]

マルチテナント アプリケーションとは、他のテナントのデータを表示したり共有したりできない多数のテナントに同じサービスと機能を提供するものです。 このアーティクルでは、Azure AI Search を使用して構築されたマルチテナント アプリケーションのテナント分離戦略について説明します。

Azure AI Search の概念

Azure AI Search はサービスとしての検索ソリューションとして、開発者はインフラストラクチャを管理したり、情報取得の専門家になったりすることなく、豊富な検索機能をアプリケーションに追加できます。 データはこのサービスにアップロードされた後、クラウドに保存されます。 Azure AI Search API への単純な要求を使用すると、データを変更して検索できます。

検索サービス、インデックス、フィールド、ドキュメント

設計パターンについて説明する前に、いくつかの基本的な概念を理解しておく必要があります。

Azure AI Search を使用する場合は、 検索サービスをサブスクライブします。 データは Azure AI Search にアップロードされると、検索サービス内の インデックス に保存されます。 1 つのサービス内に多数のインデックスを作成できます。 データベースのなじみのある概念に照らし合わせた場合、検索サービスはデータベースに例えることができ、サービス内のインデックスはデータベース内のテーブルに例えることができます。

検索サービス内の各インデックスは、カスタマイズ可能な多数の " フィールド" によって定義された独自のスキーマを持ちます。 データは、 個々のドキュメントの形式で Azure AI Search インデックスに追加されます。 各ドキュメントは特定のインデックスにアップロードする必要があり、そのインデックスのスキーマに適合する必要があります。 Azure AI Search を使用してデータを検索すると、フルテキスト検索クエリが特定のインデックスに対して発行されます。 これらの概念をデータベースの概念と照らし合わせた場合、フィールドはテーブル内の列に例えることができ、ドキュメントは行に例えることができます。

スケーラビリティ

Standard 価格レベル の Azure AI Search Serviceは、ストレージと可用性の 2 つのディメンションでスケールインできます。

  • パーティション " を追加すると、検索サービスのストレージを増やすことができます。
  • レプリカ " を追加すると、検索サービスが処理できる要求のスループットを向上させることができます。

パーティションとレプリカを自由に追加および削除することで、アプリケーションに必要なデータとトラフィックの量に合わせて検索サービスの容量を調整できます。 検索サービスが読み取り SLAを実現するには、2 つのレプリカが必要です。 サービスが読み取り/書き込み SLAを実現するには、3 つのレプリカが必要です。

Azure AI Search にはいくつかの異なる 価格レベル があり、各レベルでは 制限とクォータが異なります。 サービス レベルの制限、インデックス レベルの制限、パーティション レベルの制限があります。

S3 高密度

Azure AI Search’の S3 価格レベルには、マルチテナント シナリオ専用に設計された高密度 (HD) モードのオプションがあります。 多くの場合、1 つのサービスで小規模なテナントを多数サポートして、簡潔性とコスト効率のメリットを実現する必要があります。

S3 HD では、パーティションを使ってインデックスをスケールアウトするのではなく、1 つのサービスでより多くのインデックスをホストすることで、1 つの Search サービスで小さな多数のインデックスをまとめて管理できます。

S3 サービスは、固定数のインデックス (最大 200) をホストするように設計されており、サービスに新しいパーティションが追加されたら、各インデックスのサイズを水平方向に拡張できます。 S3 HD サービスにパーティションを追加すると、サービスでホストできるインデックスの最大数が増えます。 個々の S3HD インデックスの理想的な最大サイズは約 50 から 80 GB ですが、システムによって設けられた各インデックスに対するハード サイズ制限はありません。

マルチテナント アプリケーションに関する考慮事項

マルチテナント アプリケーションでは、さまざまなテナント間である程度のプライバシーを維持しながら、各テナントにリソースを効果的に分配する必要があります。 このようなアプリケーションのアーキテクチャを設計するときには、考慮事項がいくつかあります。

  • テナントの分離: " アプリケーション開発者は、テナントが他のテナントのデータに対して未承認のアクセスや望ましくないアクセスを実行できないように対策を講じる必要があります。 テナント分離戦略では、データのプライバシーの観点を超えて、共有リソースを効果的に管理し、ノイジー ネイバーから保護する必要があります。

  • クラウド リソースのコスト: " 他のアプリケーションと同様に、ソフトウェア ソリューションは、マルチテナント アプリケーションのコンポーネントとしてコスト競争力を維持する必要があります。

  • 運用の容易さ: " マルチテナント アーキテクチャを開発するときには、アプリケーションの運用と複雑さへの影響が重要な考慮事項となります。 Azure AI Search には、 99.9% の SLAがあります。

  • グローバル展開: マルチテナント アプリケーションは多くの場合、世界中に分散するテナントにサービスを提供する必要があります。

  • スケーラビリティ: " アプリケーション開発者は、アプリケーションの複雑さを低レベルで維持することと、テナント数とテナントのデータやワークロードのサイズに合わせてスケーリングできるアプリケーションを設計することを両立させる方法を検討する必要があります。

Azure AI Search には、テナント のデータとワークロードを分離するために使用できる境界がいくつか用意されています。

マルチテナント シナリオの場合、アプリケーション開発者は 1 つ以上の検索サービスを利用し、サービス、インデックス、またはその両方でテナントを分けます。 Azure AI Search には、マルチテナント シナリオをモデル化するときの一般的なパターンがいくつかあります：

  • "テナントあたり 1 つのインデックス:" 各テナントは、他のテナントと共有する検索サービス内に独自のインデックスを持ちます。

  • テナントごとに 1 つのサービス: 各テナントには独自の専用の Azure AI Search Serviceがあり、最高レベルのデータとワークロードの分離を提供します。

  • 両パターンの組み合わせ: " 大規模でアクティブなテナントには専用のサービスを割り当て、小規模なテナントには共有サービス内の個々のインデックスを割り当てます。

モデル 1: テナントあたり 1 つのインデックス

テナントごとのインデックス モデルの図

テナントごとのインデックス モデルでは、複数のテナントが 1 つの Azure AI Search Serviceを占有し、各テナントには独自のインデックスがあります。

テナントは、すべての検索要求とドキュメント操作が Azure AI Search のインデックス レベルで発行されるため、データの分離を実現します。 アプリケーション層では、さまざまなテナントのトラフィックを適切なインデックスに送信すると同時に、すべてのテナントにわたってサービス レベルでリソースを管理する必要性が認識されています。

テナントごとのインデックス モデルの主な特性は、アプリケーション開発者がアプリケーションのテナント間で検索サービスの容量をオーバーサブスクライブできることです。 テナントにワークロードが不均等に分配されている場合は、非常にアクティブでリソースを集中的に使用する多数のテナントに対応すると同時に、ロングテールのあまりアクティブではないテナントにもサービスを提供するために、検索サービスのインデックスにテナントの最適な組み合わせを割り当てることができます。 このモデルのトレードオフは、各テナントが同時に非常にアクティブである状況には対応できないことです。

テナントごとのインデックス モデルは、Azure AI Search Service全体が事前に購入され、その後テナントで満たされる可変コスト モデルの基礎を提供します。 これにより、未使用の容量を試用版や無料アカウント用に指定することが可能になります。

グローバル展開されているアプリケーションでは、テナントごとのインデックス モデルが最も効率的とは言えない場合があります。 アプリケーションのテナントが世界中に分散している場合、リージョンごとに個別のサービスが必要になり、それぞれのテナントでコストが重複する可能性があります。

Azure AI Search を使用すると、個々のインデックスとインデックスの合計数の両方のスケールを拡大できます。 適切な価格レベルが選択されていれば、ストレージまたはトラフィックの観点からサービス内の個々のインデックスが肥大化したときに、検索サービス全体にパーティションとレプリカを追加できます。

1 つのサービスのインデックスの総数が増えすぎた場合は、新しいテナントに対応するためにサービスをもう 1 つプロビジョニングする必要があります。 新しいサービスが追加される際に検索サービス間でインデックスを移動する必要がある場合、Azure AI Search ではインデックスの移動が許可されないため、インデックスのデータをあるインデックスから別のインデックスに手動でコピーする必要があります。

モデル 2: テナントあたり 1 つのサービス

テナントごとのサービス モデルの図

テナントごとのサービス アーキテクチャでは、各テナントが独自の検索サービスを使用します。

このモデルでは、アプリケーションはテナントの最高レベルの分離を実現します。 各サービスには、検索要求を処理するための専用のストレージとスループットが含まれます。 各テナントには、API キーの個々の所有権があります。

各テナントが大きなフットプリントを持つアプリケーションや、テナント間でワークロードのばらつきがほとんどないアプリケーションの場合、さまざまなテナントのワークロード間でリソースが共有されないため、テナントごとのサービス モデルが効果的な選択肢となります。

また、テナントごとのサービス モデルには、予測可能な固定コスト モデルというメリットもあります。 テナントが入るまで検索サービス全体への先行投資は不要ですが、テナントごとのサービスのコストは、テナントごとのインデックス モデルよりも高くなります。

テナントごとのサービス モデルは、グローバル展開されているアプリケーションにとって効率的な選択肢です。 テナントが地理的に分散していても、適切なリージョンに各テナントのサービスを簡単に配置できます。

個々のテナントがサービスを拡大しすぎると、このパターンのスケーリングの問題が発生します。 Azure AI Search では現在、検索サービスの価格レベルのアップグレードはサポートされていないため、すべてのデータを新しいサービスに手動でコピーする必要があります。

モデル 3: ハイブリッド

マルチテナント機能をモデル化する際のもう 1 つのパターンは、テナントごとのインデックスとテナントごとのサービスの 2 つの戦略を組み合わせたものです。

2 つのパターンを組み合わせることで、アプリケーションの最大規模のテナントは専用のサービスを占有することができ、ロングテールのあまりアクティブではない小規模なテナントは共有サービス内のインデックスを占有できます。 このモデルでは、最大規模のテナントがサービスの高いパフォーマンスを常に維持できると同時に、小規模なテナントをノイジー ネイバーから保護することもできます。

ただし、この戦略の実装は、専用のサービスを必要とするテナントと共有サービス内のインデックスを必要とするテナントを予測する先見性に依存します。 2 つのマルチテナント機能モデルの両方を管理する必要があるので、アプリケーションの複雑さが増します。

さらに細かい粒度の実現

Azure AI Search でマルチテナント シナリオをモデル化するための上記の設計パターンでは、各テナントがアプリケーションのインスタンス全体である、統一されたスコープが想定されています。 しかし、アプリケーションが多数の小さなスコープに対応できる場合もあります。

テナントごとのサービス モデルとテナントごとのインデックス モデルが十分に小さなスコープではない場合は、さらに細かい粒度を実現するインデックスをモデル化することができます。

1 つのインデックスの動作をクライアント エンドポイントごとに異なるものにするには、考えられるクライアントごとに特定の値を指定するフィールドをインデックスに追加できます。 クライアントが Azure AI Search を呼び出してインデックスのクエリまたは変更を行うたびに、クライアント アプリケーションのコードは、クエリ時に Azure AI Search のフィルター 機能を使用して、そのフィールドの適切な値を指定します。

この方法を使用すると、個別のユーザー アカウント、個別のアクセス許可レベル、完全に別個のアプリケーションの機能を実現できます。

Note

上記の方法を使用して、複数のテナントに対応するように 1 つのインデックスを構成すると、検索結果の関連性に影響を及ぼします。 検索の関連性スコアは、テナント レベルのスコープではなく、インデックス レベルのスコープで計算されるので、すべてのテナントのデータが、関連性スコアの基になる統計 (語句の頻度など) に組み込まれます。

次のステップ

Azure AI Search は、多くのアプリケーションにとって魅力的な選択肢です。 マルチテナント アプリケーションのさまざまな設計パターンを評価する場合は、さまざまな価格レベル と、すべてのサイズのアプリケーション ワークロードとアーキテクチャに合わせて Azure AI Search を最適に調整するために それぞれの サービス制限を検討してください。