Azure AI 検索は、異種コンテンツのインデックスを作成し、API、アプリケーション、AI エージェントを使用した取得を可能にするスケーラブルな検索インフラストラクチャです。 これは、チャット完了モデルによる動的なコンテンツ生成を必要とするエンタープライズ検索シナリオや AI を利用したカスタマー エクスペリエンスに適しています。
この記事では、Azure AI 検索での信頼性のサポートについて、可用性ゾーンと複数リージョンのデプロイによるリージョン内の回復性を含めて説明します。
信頼性は、お客様と Microsoft の間で共有される責任です。 このガイドを使用して、特定のビジネス目標とアップタイム目標を満たす信頼性オプションを決定できます。
信頼性のための運用環境のデプロイに関する推奨事項
運用環境のワークロードでは、少なくとも 2 つのレプリカを含む課金対象レベルを使用することをお勧めします。 この構成により、一時的な障害やメンテナンス操作に対する検索サービスの回復性が向上します。 また、AI Search の サービス レベル アグリーメント (SLA) も満たしています。 SLA では、読み取り専用ワークロードには 2 つのレプリカ、読み取り/書き込みワークロードには 3 つ以上のレプリカが必要です。
AI Search では Free レベルの SLA は提供されません。これは 1 つのレプリカに制限されており、運用環境では推奨されません。
信頼性アーキテクチャの概要
AI Search を使用する場合は、 検索サービスを作成します。 各検索サービスでは、検索可能なコンテンツを格納する多くの検索インデックスがサポートされています。
AI Search は、プライマリ データ ストアとして設計されていません。 代わりに、インデクサーを使用して、検索サービスを外部データ ソースに接続します。 インデクサーは、ソース データをクロールし、処理とエンリッチメントを実行するスキルを呼び出し、インデックスにスキルの出力を設定します。
また、サービスのレプリカの数も構成します。 AI Search では、レプリカはサービスの検索エンジンのコピーです。 レプリカは、単一の仮想マシン (VM) を表すものと考えることができます。 各検索サービスには、1 ~ 12 個のレプリカを含めることができます。
複数のレプリカを追加すると、AI 検索で次のことができます。
検索サービスの可用性を高める。
クエリが他のレプリカで引き続き実行されている間は、1 つのレプリカでメンテナンスを実行します。
より高度なインデックス作成とクエリワークロードを処理する。
リージョンでサポートされている場合は、異なる可用性ゾーンにレプリカをプロビジョニングして回復性を向上させます。
AI Search では、1 つのレプリカが プライマリ レプリカに自動的に割り当てられます。 すべての書き込み操作は、そのレプリカに対して実行されます。 他のレプリカは読み取り操作に使用されます。
次の図は、3 つのレプリカを持つ検索サービスが 3 つの可用性ゾーンに分散された様子を示しています。
検索インデックスで使用されるストレージを表す パーティションの数を構成することもできます。
レプリカとパーティションはそれぞれ異なる方法で読み取りと書き込みのパフォーマンスに影響するため、レプリカとパーティションの追加の影響を理解することが重要です。 レプリカとパーティションの詳細については、「検索サービスの容量を見積もって管理する」を参照してください。
一時的な障害
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが一時的な障害に対処できることが重要です。これは通常、影響を受けた要求を再試行することで対処します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
AI Search インデクサーには、一時的な障害処理が組み込まれています。 データ ソースが短時間使用できない場合、インデクサーは復旧して再試行するように設計されています。 変更追跡を使用して、最後に正常にインデックスが作成されたドキュメントからインデックス作成を再開します。
検索サービスでは、標準の予定外のメンテナンス操作中に一時的な障害が発生する可能性があります。 Azure AI 検索では、事前通知は提供されません。また、特定の時刻にメンテナンスのスケジュールを設定することもできません。 ダウンタイムを最小限に抑えるためにあらゆる作業が行われますが、単一レプリカ サービスの場合でも、短時間の中断が発生する可能性があります。 これらの一時的な障害に対する回復性を向上させるために、2 つ以上のレプリカを使用することをお勧めします。
AI Search と対話するアプリケーションを構築する場合は、一時的な障害を処理する必要があります。 読み取り操作と書き込み操作の両方に指数バックオフを伴う再試行戦略を使用します。
可用性ゾーンのサポート
可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
AI Search はゾーン冗長です。つまり、レプリカは検索サービス リージョン内の複数の可用性ゾーンに分散されます。
サービスに複数のレプリカを追加すると、AI Search は各レプリカを異なる可用性ゾーンに配置しようとします。 使用可能なゾーンよりも多くのレプリカを持つサービスの場合、レプリカは可能な限り均等に複数のゾーンに分散されます。
次の図は、4 つのレプリカを持つ検索サービスの例が 3 つの可用性ゾーンにデプロイされる様子を示しています。
Von Bedeutung
AI Search では、レプリカの正確な配置は保証されません。 配置は、容量の制約、スケーリング操作、およびその他の要因の影響を受けます。
リージョンのサポート
Availability Zones のサポートは、インフラストラクチャとストレージによって異なります。 サポートされているリージョンの一覧については、「 AI 検索のリージョンを選択する」を参照してください。
要求事項
検索サービスが次のすべての条件を満たしている場合、ゾーン冗長が自動的に有効になります。
- リージョンの要件を満たす
- Basic サービス レベル以上である
- 少なくとも 2 つのレプリカがある
注
AI Search は、複数のレプリカがある場合に、複数のゾーンにレプリカを分散しようとします。 ただし、読み取り/書き込みワークロードでは、可能な限り高い可用性 SLA を受け取るように、3 つ以上のレプリカを使用する必要があります。
ゾーン間でのインスタンスの分散
AI Search は、異なる可用性ゾーン間にレプリカを配置しようとします。 ただし、時折、検索サービスのすべてのレプリカが同じ可用性ゾーンに配置される状況が生じます。 この状況は、サービスからレプリカが削除された場合に発生する可能性があります。たとえば、使用するレプリカの数を減らすようにサービスを構成してスケールインする場合などです。 レプリカの削除によって、残りのレプリカが可用性ゾーン間で再調整されることはありません。
すべてのレプリカが単一の可用性ゾーンに配置される可能性を減らすために、スケールイン操作の直後にスケールアウト操作を手動でトリガーできます。 たとえば、検索サービスに 10 個のレプリカがあり、7 個のレプリカにスケールインするとします。 1 回のスケール操作を実行する代わりに、一時的に 6 つのインスタンスにスケーリングし、すぐに 7 つのインスタンスにスケーリングしてゾーンの再調整をトリガーできます。
費用
各検索サービスは、1 つのレプリカで始まります。 ゾーンの冗長性には 2 つ以上のレプリカが必要であり、サービスを実行するためのコストが増加します。 レプリカの課金への影響を理解するには、料金計算ツールを使用します。
可用性ゾーンのサポートを設定する
検索サービスがゾーン冗長の要件を満たしている場合は、追加の構成は必要ありません。 AI Search では、可能な限り、異なる可用性ゾーンにレプリカを配置しようとします。
容量の計画と管理
可用性ゾーンの障害に備えて、レプリカの数 をオーバープロビジョニングすることを 検討してください。 オーバープロビジョニングを使用すると、検索サービスは容量の損失を許容し、パフォーマンスを低下させることなく引き続き機能します。 停止中にレプリカを追加するのは困難であるため、オーバープロビジョニングは、容量が減っても、検索サービスが通常の要求ボリュームを処理できるようにするのに役立ちます。 詳細については、「 オーバープロビジョニングによる容量の管理」を参照してください。
通常の運用
このセクションでは、検索サービスがゾーン冗長用に構成されていて、すべての可用性ゾーンが動作している場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング: AI Search では、使用可能なすべてのレプリカに対して、すべてのクエリと書き込みの自動負荷分散が実行されます。 AI Search は、任意の可用性ゾーン内の任意のレプリカに読み取り操作を送信できます。 AI Search サービスが選択した 1 つのプライマリ レプリカに書き込み操作を送信します。
ゾーン間のデータ レプリケーション: データの変更は、可用性ゾーン間のレプリカ間で自動的にレプリケートされます。 レプリケーションは非同期的に行われます。つまり、書き込みが他のレプリカにレプリケートされる前に、1 つのプライマリ レプリカにコミットされます。
ゾーンダウン エクスペリエンス
このセクションでは、検索サービスがゾーン冗長用に構成され、可用性ゾーンの停止が発生した場合に想定される内容について説明します。
検出と応答: AI Search は、可用性ゾーンで障害を検出する役割を担います。 ゾーンのフェールオーバーを開始するために何もする必要はありません。
通知： AI Search では、ゾーンがダウンしても通知されません。 ただし、Azure Resource Health を使用してレプリカの正常性を監視できます。 ゾーンがダウンしている場合、そのゾーン内のレプリカは使用不可と表示されます。 また、Azure Service Health を使用して、ゾーンの障害を含む AI Search サービスの全体的な正常性を把握することもできます。
これらのサービスにアラートを設定して、ゾーン レベルの問題に関する通知を受け取ります。 詳細については、「 Azure portal での Service Health アラートの作成 」および 「Resource Health アラートの作成と構成」を参照してください。
アクティブな要求: 失敗したゾーン内のレプリカが処理する要求は終了します。 クライアントは、 一時的な障害を処理するためのガイダンスに従って要求を再試行する必要があります。
予想されるデータ損失: 影響を受ける可用性ゾーンに読み取りレプリカのみが含まれている場合、データ損失は発生しません。
影響を受けたゾーンにあったためにプライマリ レプリカが失われた場合、まだレプリケートされていない書き込み操作が失われる可能性があります。
予想されるダウンタイム: ほとんどの場合、他の可用性ゾーンの読み取りレプリカは引き続き要求を処理するため、ゾーン障害によって検索サービスに読み取り操作のダウンタイムが発生することは想定されません。
影響を受けたゾーンに存在したためにプライマリ レプリカが失われた場合、AI Search は、書き込み操作を再開できるように、別のレプリカを新しいプライマリに自動的に昇格させます。 通常、レプリカの昇格が発生するまでに数秒かかります。 この間、書き込み操作が成功しない可能性があります。 一時的な障害処理のガイダンスに従って、アプリケーションが準備されていることを確認します。
ただし、検索サービスのすべてのレプリカが単一の可用性ゾーンに存在する可能性は低い状況がいくつかあります。 このシナリオでは、ゾーンが復旧するまでダウンタイムが発生する可能性があります。 詳細と回避策については、「インスタンスの配布」を参照してください。
トラフィックの再ルーティング: ゾーンで障害が発生すると、AI Search は障害を検出し、要求を存続ゾーン内のアクティブなレプリカにルーティングします。 プライマリ レプリカが失われた場合、別のレプリカが新しいプライマリに昇格されます。
ゾーンの回復
可用性ゾーンが復旧すると、AI Search は通常の操作を自動的に復元し、復旧されたゾーンを含むすべてのゾーンで使用可能なレプリカへのトラフィックのルーティングを開始します。
ゾーン障害を検出するためのテスト
AI Search は、ゾーン冗長サービスのトラフィック ルーティングを管理します。 ゾーン障害プロセスを開始または検証する必要はありません。
マルチリージョン サポート
AI Search は、単一リージョンのサービスです。 リージョンが使用できなくなった場合、検索サービスも使用できなくなります。
代替のマルチリージョン アプローチ
必要に応じて、異なるリージョンに複数の AI Search サービスをデプロイできます。 お客様は、リージョンごとに個別のサービスをデプロイおよび構成する責任を担います。 複数リージョンアーキテクチャを使用するセカンダリ Azure リージョンで同じデプロイを作成すると、アプリケーションは単一リージョンの障害の影響を受けにくくなります。
この方法に従う場合は、リージョン間でインデックスを同期して、最後のアプリケーションの状態を回復する必要があります。 負荷分散ポリシーとフェールオーバー ポリシーも構成する必要があります。
ソリューション全体のパフォーマンスを最適化するには、データ ソースの読み取り専用レプリカでインデックス作成を実行する機会を探します。 たとえば、一部のインデクサーでは、地理的に分散されたデータ ソースの読み取りレプリカからの読み取りがサポートされています。
詳細については、「Azure AI 検索での複数リージョンへのデプロイ」を参照してください。
バックアップ
AI Search はプライマリ データ ストレージ ソリューションではないので、セルフサービスのバックアップと復元のオプションは提供されません。 ただし、index-backup-restore または Python の サンプルを使用して、インデックス定義とそのドキュメントを一連の JSON ファイルにバックアップし、インデックスを復元するために使用できます。
ただし、誤ってインデックスを削除し、バックアップがない場合は、インデックスを再構築できます。 再構築には、検索サービスでインデックスを再度作成し、プライマリ データ ストアからデータを取得してインデックスを再読み込みする必要があります。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。
AI Search では、可用性 SLA は次の検索サービスに適用されます。
- 請求可能なサービス レベルを使用するように構成されます。
- 読み取り専用ワークロード (クエリ) 用に少なくとも 2 つの レプリカがあります。
- 読み取り/書き込みワークロード (クエリとインデックス作成) 用に少なくとも 3 つのレプリカがあります。