Elasticsearch再インデックス運用を安定化する方法

「検索インデックスを作り直すたびに、検索機能が数十分止まる」「マッピングを変えたいのに、変更方法が分からず場当たり的にインデックスを作り直している」——Elasticsearch(またはOpenSearch)を使ったサービスで、こうした相談をよく受けます。

検索エンジンは一度動き始めると「動いているから触りたくない」対象になりがちです。しかし商品データやコンテンツが増えるたびにマッピングの見直しやリインデックスは必ず発生します。この記事では、再インデックスがなぜ不安定になるのか、その原因と、無停止で安定運用するための具体的な設計、外注時に確認すべき点を整理します。

なぜ再インデックスは不安定になるのか

再インデックスが不安定な現場には、共通するパターンがあります。

• インデックスに直接エイリアスなしで書き込んでいる: アプリケーションが products のような固定インデックス名を直接参照していると、作り直す際に一時的に検索不能な時間が発生します
• マッピング変更のたびにインデックスを丸ごと削除→再作成している: Elasticsearchは既存フィールドの型変更(例: text → keyword)を直接サポートしないため、多くの現場が「消して作り直す」を安易な解決策にしてしまいます。しかし削除している間は検索が完全に止まります
• DBからの全件流し込みを1本のバッチで実行し、途中で失敗すると最初からやり直し: 数百万件規模のデータで数時間かかる処理が、ネットワーク瞬断やメモリ不足で頓挫し、リトライのたびに同じ時間を溶かします
• リソース監視をしていない: 再インデックス中にヒープが逼迫し CircuitBreakingException が発生したり、ディスクI/Oが枯渇して検索クエリ自体が遅延したりしても、原因不明のまま「重い時間帯がある」で片付けられている

これらは個別の技術的な誤りというより、「本番のインデックスを直接触る」という運用設計そのものが不安定さの根本原因です。まずここを変える必要があります。

alias運用への切り替え(最優先の改善)

再インデックス運用を安定させる最初の一歩は、アプリケーションがインデックス名ではなくエイリアスを参照する構造に変えることです。

• アプリは products という物理インデックス名ではなく、products_alias というエイリアスに対して検索・書き込みを行う
• 実体は products_v1、products_v2 のように世代管理されたインデックスとして作成する
• 新しいマッピングでのリインデックスが完了したら、products_v2 にエイリアスを張り替え、products_v1 へのエイリアスを外す。この切り替えは _aliases API でアトミックに実行できるため、検索が一瞬たりとも止まりません

POST /_aliases
{
  "actions": [
    { "remove": { "index": "products_v1", "alias": "products_alias" } },
    { "add":    { "index": "products_v2", "alias": "products_alias" } }
  ]
}

この構造さえ入っていれば、マッピング変更・再インデックスは「新しいインデックスを裏で作って、準備ができたら切り替える」という無停止のオペレーションになります。既存プロダクトでこれが未実装の場合、他の改善に着手する前に真っ先にここを直すべきです。改善に着手する前の基本的な確認観点は改善の最初の確認観点にもまとめています。

段階的な再インデックスの設計

alias運用の土台ができたら、実際のデータ移行を安定させる設計に入ります。

Reindex APIとバッチ分割

Elasticsearchの _reindex API はインデックス間のコピーを組み込みでサポートしますが、大規模データでは以下を必ず設計に入れます。

• slices パラメータで並列化する。単一スレッドでのreindexは数百万件規模で非現実的な時間がかかるため、シャード数に応じて並列実行する
• requests_per_second でスロットリングし、本番トラフィックを処理しているクラスタのリソースを食い潰さないようにする。無制限で流すと検索クエリのレイテンシが跳ね上がる
• 途中失敗に備えて進捗をチェックポイント管理する(DB側のIDやタイムスタンプでカーソルを持つ)。1本の巨大バッチで実行せず、時間帯やID範囲で区切って再実行可能な設計にする

DB発のカスタムインデクサーの場合

Elasticsearchの _reindex はES内のインデックス間コピーであり、DB(RDBやNoSQL)からのマッピング変更を伴う全量流し込みには使えません。この場合は自前のバッチ処理が必要になります。

• DBの全件走査はページネーション(カーソルベース)で行い、1回のバルクリクエストは数百〜数千件程度に収める。Elasticsearchの _bulk APIは一括サイズが大きすぎるとタイムアウトやメモリ逼迫の原因になる
• バルク投入のレスポンスで個別ドキュメントのエラーを必ずチェックする。_bulk はリクエスト全体が200を返してもドキュメント単位で失敗していることがあり、ここを見ていないと気づかないうちにデータが欠落する
• 失敗したドキュメントIDを記録し、リトライ対象として再投入できるようにする

DBとの整合性を保つ

再インデックス中・完了後に厄介なのが、Elasticsearchとマスタデータ(DB)のズレです。

• 再インデックスに数時間かかっている間も、DB側では更新が発生し続けます。旧インデックス(products_v1)からのコピー開始時点でスナップショットを取り、それ以降の更新差分は別途反映する仕組み(更新キューやCDC=Change Data Capture)が必要です
• 単純な「開始時刻以降の更新レコードを再度流し込む」という2段階方式でも、実務上は十分機能します。ただし再インデックス中に削除されたレコードは新インデックスに残ってしまうため、削除の伝播も忘れずに設計します
• 定期的に件数突合(DBの対象件数とElasticsearchのドキュメント数を比較する監視)を仕込んでおくと、ズレが起きたときに検索結果がおかしくなる前に気づけます。件数だけでなく、サンプリングしたレコードのフィールド値を突き合わせる仕組みまで用意できるとより安全です

DBとの整合性が崩れたまま気づかず運用しているケースは非常に多く、「検索結果に出てこない商品がある」「削除したはずのデータが検索に残っている」といった問い合わせで初めて発覚します。

監視すべき指標

再インデックス運用を安定させたあとも、日常運用で見るべき指標があります。

• クラスタヘルス(green / yellow / red)。再インデックス中に yellow に落ちる場合、レプリカ数やシャード配置の設定を見直す
• JVMヒープ使用率。再インデックス中に80%を超えるようならバッチサイズや並列度を下げる。CircuitBreakingException が出ている場合はすでに限界を超えているサイン
• インデクシングレイテンシとサーチレイテンシを分けて監視する。再インデックスの負荷が検索クエリのレスポンスタイムに影響していないかを確認する
• ディスク使用率。新旧インデックスが同時に存在する期間はディスク使用量が一時的に倍近くなるため、余裕を持った容量設計が必要

これらをダッシュボード化せず「重くなったら気づく」運用のままだと、再インデックスのたびに手探りの対応が続きます。検索まわりの体感パフォーマンス全体の診断観点は遅い検索画面を改善するための技術診断ポイントでも詳しく解説しています。

マッピング変更を安全に進める判断の分かれ道

マッピング変更にはいくつかパターンがあり、対応方法が異なります。

• 新しいフィールドの追加: 既存インデックスに動的マッピングまたは _mapping APIでの追加が可能。多くの場合、再インデックス不要
• 既存フィールドの型変更(text→keyword、integer→long等): 再インデックスが必須。alias運用の切り替えフローに乗せる
• アナライザーの変更(形態素解析の辞書追加・変更等): 既存ドキュメントは古いアナライザーで解析されたままのため、検索結果に古い挙動が混在する。これも再インデックスが必須
• シャード数の変更: インデックス作成時にしか決められない。データ量が想定より増えた場合はシャード数を増やした新インデックスへの再インデックスで対応する

「とりあえず動くから」で全部フル再インデックスにせず、変更の種類ごとに必要な作業を切り分けることが、無駄な停止時間とリソース消費を避ける鍵になります。

外注する場合に確認すべきこと

Elasticsearch/OpenSearchの運用改善を外部チームに依頼する際は、次の点を確認しておくと安心です。

• alias運用を前提にした設計を提案してくるか: インデックス名を直接アプリに埋め込んだままの提案は、次のマッピング変更で同じ問題を繰り返します
• DBとの整合性担保の方法まで踏み込んでいるか: 「reindexコマンドを実行する」だけでなく、再インデックス中の更新差分・削除の伝播・件数突合まで設計に含まれているか
• 監視の仕組みとセットで提案しているか: クラスタヘルスやヒープ使用率の監視なしに「とりあえず再インデックスします」で終わる提案は、次に同じ問題が起きたときに気づけません

技術スタックの詳細はインフラ関連の技術ページに、進め方全体は保守・運用支援サービスにまとめています。

まとめ

• 再インデックスが不安定な根本原因は、多くの場合「アプリがインデックス名を直接参照している」設計そのものにある。alias運用への切り替えが最優先の改善
• 大規模データの移行はバッチ分割・スロットリング・チェックポイント管理で段階的に行い、DBとの整合性は更新差分の反映と件数突合で担保する
• クラスタヘルス・JVMヒープ・レイテンシを日常的に監視し、「重くなったら気づく」運用から抜け出すことが安定運用の土台になる

再インデックスのたびに検索が止まる、マッピング変更が怖くて手を出せない、といった段階でもご相談いただけます。torcheeesでは既存プロダクト改善の診断と、継続的な改善支援を提供しています。まずはお問い合わせフォームから現状を聞かせてください。