Azure AI Search 本番運用に向けた非機能の検討ポイント - 後編
はじめに
三菱UFJフィナンシャル・グループ（以下MUFG）の戦略子会社であるJapan Digital Design（以下JDD）で、Tech PM（Technical Project Manager）をしている吉竹です。
JDDでは Azure AI Search を複数のプロジェクトで活用しています。AI Searchを使ったシステムを構築、運用する中で得られた知見を紹介するため、以下の記事を公開しました。
本記事は、上記の続きとなります。具体的には、監視、セキュリティ、バックアップ・リストアを対象に得られた知見を紹介します。
なお、前回記事の内容が前提知識になる部分もありますので、事前に目を通していただくとより理解度が高まると思います。
前編
性能
信頼性
コスト
後編（本記事）
監視
セキュリティ
バックアップ・リストア
監視
監視の全体像
AI Searchに対するアラートルールを作成することで、メトリクスが閾値を超えた場合に通知する、といったアクションを設定することが可能です。
メトリクス例としては以下のようなものがあります。例えば、「スロットルされた検索クエリの割合が5%を超えた場合」といった条件が可能です。
他にも、監視について以下のような設定・構成が可能です。
AI Search自体の正常性やアクティビティログに対するカスタムログ検索結果に対して、アラートルールを作成する
Logic Appsと連携してSlackへ通知する
アクティビティログ等のログについて、Storage AccountとLog Analytics Workspacesに連携する
AI Searchの監視については公式ドキュメントでも整理されています。
一方で、以下のような注意点もあります。
ストレージ使用量の監視
価格レベルに応じて、利用できるストレージ使用量やインデックスに上限値があります。システムを運用する中で、データの増減により上限値に抵触していないか監視したいニーズが生じますが、AI Searchではストレージ使用量などのメトリクスは提供されていません。
Azure Portalではストレージ使用量等を参照することができますが、これらの情報を監視に使いたい場合、Azure CLIやAzure Functionsなどを利用して定期的に情報を取得して監視する必要があります。自前で構築する必要があるということです。
レイテンシーにキュー時間は含まれない
前回の記事にて、セマンティックランカーを利用した場合、キューシステムによりリクエストが制御されるとご紹介しました。
私たちのシステムでもセマンティックランカーを利用していますが、性能テスト等で挙動を確認したところ、メトリクスで計測されているAI Searchのレイテンシーは、アプリケーション側で観測される時間より短い傾向がありました。これはキューでの待機時間が、メトリクスで計測されるレイテンシーには含まれていないためと考えられます。（ただし、これは私たちの観測に基づく推測です）
つまり、AI Searchでモニターされている検索レイテンシーは、エンドユーザーが体感しているレイテンシーと異なるということです。AI Searchのレイテンシーのみではなく、アプリケーションの検索時間も観測できるようにしましょう。
監視のまとめ
✔ アラートルールを使うことで、検索のレイテンシーやスロットリングの割合を監視することが可能
✔ ストレージなど監視できないメトリクスは、自前で監視の仕組みを作る必要がある
✔ AI Searchのレイテンシーのみではなく、アプリケーションの検索時間も観測できるようにする
セキュリティ
Azure上のリソースからAI Searchを利用する場合、マネージドIDを割り当てることでアクセスが可能となります。一方、私たちのプロジェクトではAzure外に構築したアプリケーションからAI Searchを利用する構成でした。
このケースにおけるセキュリティの検討ポイントを紹介します。
APIキーの管理
Azure外のリソースからAI Searchを利用する場合、APIキーが必要となります。AI Searchでは、アクセス権限の異なる2種類のAPIキーが提供されます。
管理キー (Admin Key)
インデックスの作成・更新・削除など、すべての操作が可能クエリキー (Query Key)
検索など読み取りアクセスのみが可能
検索アプリケーションからAI Searchを利用する場合は、最小権限の原則に従いクエリキーを使用するべきです。
私たちのプロジェクトでは、検索とインデックス更新でアプリケーションが分かれており、それぞれ別のキー（クエリキーと管理キー）を割り当てています。これにより、検索側のアプリケーションから意図せず更新が行われるリスクに対処しています。
なお、いずれもAPIキーについても、Key Vault等のシークレット管理ツールで厳格に管理することは必須と言えます。
アクセス制御と注意点
AI Searchの機能で、IPアドレスによるアクセス制限を設定できます。AI Searchの接続元IPアドレスを特定できそうであれば、制限を入れることが推奨されます。
例：AWSのNAT Gateway/インスタンスのIPアドレスで制限する、等
注意点として、IPアドレス制限を有効にすると、Azure Portal（管理画面）からのアクセスも一部制限されます。具体的には、インデックス等のデータにアクセス不可となります。
これは、AI Searchの内部アーキテクチャがコントロールプレーンとデータプレーンに分かれており、IPアドレス制限によりデータプレーンへのアクセスが制限されるためと推測されます。
"データ プレーン" とは、検索サービス エンドポイントに対する操作 (たとえばインデックス作成やクエリ)、またはその他の検索サービス REST API または同等の Azure SDK クライアント ライブラリで指定される操作を指します。 "コントロール プレーン" とは、Azure リソース管理 (たとえば検索サービスの作成や構成) を指します。
公式ドキュメントでは、PortalのIPアドレスを許可する方法が紹介されていますが、Portalのみでは不十分でアクセス元のIPアドレスも追加が必要です。そのため固定のIPアドレス（例：オフィスのグローバルIPアドレス等）を追加する対応が必要です。
セキュリティのまとめ
✔ APIキーは、用途に応じて管理キーとクエリキーを使い分ける
✔ IPアドレス制限を用いて、不特定多数からのアクセスを拒否する
バックアップ・リストア
データの損失やサービス障害に備え、バックアップ・リストアの戦略を立てておくことで、AI Searchの信頼性を高めることができます。
バックアップの考え方
2025年5月現在、AI Searchにはインデックスのデータをバックアップ・リストアする公式の機能は提供されていません。これは、インデックスはオリジナルのデータソースから再構築されるという考え方によるものです。
データベースのようなデータダンプは取得できないということです。
Azure AI Search は主要なデータ ストレージ ソリューションではないため、Microsoft ではセルフサービスのバックアップおよび復元のための正式なメカニズムは提供していません。
インデックスのポーティングはネイティブでサポートされません。 検索インデックスは、ダウンストリーム データ構造と見なされ、運用データを収集する他のデータ ソースからのコンテンツを受け入れます。 そのため、インデックスのバックアップと復元の組み込みサポートはありません。
そのため、AI Searchのバックアップとしては以下の対応が求められます。
データソースのバックアップ
インデックスの元となるデータ（データベース、ストレージ上のファイルなど）を確実にバックアップする。インデックス定義のコード管理
インデックスのスキーマ、インデクサー、スキルセットなどの定義を、JSONファイルやCLI, SDKによりコード管理する。なお、TerraformやBicep(*1)ではインデックスの定義までは管理できないため注意。
(*1) Bicep: Azureに特化したIaC言語
リストア（復旧）の考え方
一般的に、サーバーやデータベースは、別環境にシステムを構築しておき障害発生時に起動・データ投入する仕組み（コールドスタンバイ）を取ることが可能です。
ただし、AI Searchはサービスを一時停止して、課金を停止することができません（参考：公式ドキュメント）。そのため、コストを最小化しつつAI Searchをリストアするにはリストア先のインスタンスを再作成する必要があります。また、先述の通り直接のバックアップ機能も無いので、データソースから復旧する必要があります。
これを効率的かつ安全に行うには、IaC (Infrastructure as Code)およびインデックス定義のコード化と再作成プロセスの自動化が必要となります。データソースからデータを読み込み、インデックスを再現できるようにします。参考として、私たちのプロジェクトではTerraformとSDKを使いコード管理しています。
参考）バックアップ・リストアをサポートするツール
公式ドキュメントでは、以下のツールが紹介されています。このツールでは、インデックス定義及びスナップショットを取得し復元できるとされています。ツールは.NETやPythonのノートブックで作成されています。
https://github.com/Azure-Samples/azure-search-dotnet-utilities
このツールも検証しましたが、私たちの環境では上手く動作させることができませんでした。また、プロジェクトの非機能要件もTerraform、SDKの管理で充足しました。プロジェクトの要件上、上記のツールが必要となる場合には検証してみる価値はあるかもしれません。
バックアップ・リストアのまとめ
Azure AI Searchの運用においては、インデックスおよびデータを「いつでも再構築できる」状態にしておくことが、実質的なバックアップ・リストア戦略となります。そのためには、インデックス定義とデータ投入プロセスのコード化・自動化が鍵となります。
なお、現実的な課題として、データの損失やサービスの障害以外にも、データのエクスポートやテスト環境の構築など、データ移行が必要となるケースは存在します。こういったケースでAI Searchの制約は不便であるため、改善を期待したいところです。
✔ インデックスのデータをバックアップ・リストアする公式の機能は提供されていない
✔ 安全なバックアップ・リストアには、データソースの確実なバックアップと、インデックスのコード管理およびデータ投入プロセスの自動化が必要
まとめ
本記事では、AI Search の基礎知識をもとに、監視、セキュリティ、バックアップ・リストアの観点での検討ポイントをご紹介しました。いずれも本番運用する上では必須の概念なので、公式ドキュメントを十分に確認することをおすすめします。
2回に分けて、AI Searchにおける非機能の検討ポイントをご紹介しました。マネージドな検索サービスですが、本番運用における検討ポイントはいくつか存在しますので、導入を検討される方は抑えておきましょう。
本記事がどなたかのお役に立てば幸いです。
Japan Digital Design株式会社では、一緒に働いてくださる仲間を募集中です。カジュアル面談も実施しておりますので下記リンク先からお気軽にお問合せください。
この記事に関するお問い合わせはこちら
Japan Digital Design 株式会社
Technology & Development Div
Naoki Yoshitake