はじめに
こんにちは。スマサテで開発を担当しているキノシタです。
以前の記事でVector導入によるログ収集基盤の構築について紹介しましたが、今回はその続編として、収集したログを効率的に管理するためのIndex Lifecycle Management（ILM）の設定について解説します。
ログは貴重な情報源ですが、無制限に保存し続けるとストレージコストが膨大になってしまいます。かといって、トラブルシューティングに必要なログを早期に削除してしまうのも問題です。この課題を解決するのがILMです。
Index Lifecycle Management（ILM）とは
ILMは、Elasticsearchにおけるインデックスのライフサイクルを自動的に管理する機能です。時間の経過やデータサイズに応じて、インデックスを異なるフェーズに移行させ、ストレージコストを最適化しながら必要な期間データを保持できます。
Elasticsearchでは5つのライフサイクルフェーズが定義されています：
- Hot: インデックスが活発に更新され、クエリされている状態
- Warm: 更新頻度が低いか更新されないが、まだクエリされている状態
- Cold: 更新頻度が低いか更新されず、クエリ頻度も低い状態
- Frozen: もはや更新されず、クエリも稀な状態。クエリが極めて遅くても許容される
- Delete: インデックスが不要となり、安全に削除できる状態
今回の設定では、Hot、Frozen、Deleteの3つのフェーズを活用しています。
本番環境と開発環境で異なる戦略
スマサテでは、本番環境（production）と開発環境（dev）で異なるILMポリシーを適用しています。それぞれの環境の特性に応じて、最適な設定を行うことが重要です。
本番環境のILMポリシー
本番環境では、トラブルシューティングや分析のために約3ヶ月（90日以上）のログを保持する設計としました。
# 本番環境ILMポリシーの概要
Hot Phase:
- ロールオーバー条件:
- 最大プライマリシャードサイズ: 50GB
- 最大経過日数: 14日
- インデックス優先度: 100
Frozen Phase:
- 移行タイミング: ロールオーバー後即座に（0日後）
- Searchable snapshot化
- スナップショットリポジトリ: found-snapshots
Delete Phase:
- 移行タイミング: ロールオーバーから90日後
- 動作: インデックスの削除
Frozenフェーズの活用
本番環境の特徴は、Frozenフェーズを活用している点です。そうすることで以下のメリットが得られます。
- コスト効率: 通常のデータノードと比較して、ストレージコストを大幅に削減
- 検索可能性の維持: 必要に応じてスナップショットからデータを取得し、検索可能な状態を維持（ただし、クエリは極めて遅くなることを許容）
- 長期保管: 90日間という長期間のログ保持が現実的なコストで実現
開発環境のILMポリシー
開発環境では、コストを抑えつつ必要十分な期間ログを保持する設計としました。
# 開発環境ILMポリシーの概要
Hot Phase:
- ロールオーバー条件:
- 最大プライマリシャードサイズ: 20GB
- 最大経過日数: 7日
- インデックス優先度: 100
Delete Phase:
- 移行タイミング: ロールオーバーから7日後
- 動作: インデックスの削除
開発環境ではFrozenフェーズを無効化し、シンプルな2フェーズ構成としています。これにより：
- 最短7日、最長14日のログ保持期間を確保
- 開発・検証に必要十分な期間を確保しつつコストを最小化
- シンプルな構成により管理の複雑性を排除
ロールオーバーの仕組み
ILMでは、設定した条件（データサイズ、ドキュメント数、または経過日数）に基づいて自動的にロールオーバーが実行されます。ロールオーバーとは、書き込み先のインデックスを新しいものに切り替える仕組みです。これにより古いインデックスは検索用に残しつつ、新しいインデックスに書き込みを続けられます。
ロールオーバーのメリット：
- インデックスサイズを適切に保つことで検索パフォーマンスを維持
- 時系列データを効率的に管理
- 古いインデックスを異なるフェーズに移行させることが可能
なお、ロールオーバーが発生すると、インデックスの経過時間は作成日時ではなくロールオーバー時刻を基準に計測されるため、フェーズ移行のタイミングはロールオーバー時刻からの経過時間で決まります。
実際のデータ保持期間の計算
ILMの設定を行う際、実際のデータ保持期間を正確に把握することが重要です：
本番環境の場合
- 最短: 約90日（50GBで即ロールオーバー → Frozen → 90日後削除）
- 最長: 約104日（14日目にロールオーバー → Frozen → 90日後削除）
開発環境の場合
- 最短: 約7日（20GBで即ロールオーバー → 7日後削除）
- 最長: 約14日（7日目にロールオーバー → 7日後削除）
この差は、ロールオーバーのトリガーとなる条件（サイズまたは日数）のどちらが先に満たされるかによって生じます。
おわりに
今回は、ElasticsearchのIndex Lifecycle Management (ILM) を活用して、インデックスのライフサイクルを自動的に管理する方法を紹介しました。この改善により、インデックスのローテーションや削除を効率的に制御でき、ストレージコストを最適化しつつ、検索パフォーマンスを安定的に維持できるようになりました。
スマサテでは、このような技術的課題に一緒に取り組んでくれるエンジニアを募集しています。インフラからアプリケーションまで幅広い領域で挑戦したい方は、ぜひWantedlyをご覧ください。
参考リンク
注意
- 本記事の設定は Elastic Cloud 上の運用 を前提としています。
- 特に Frozen フェーズでは Searchable Snapshot を利用する仕組みになっており、この機能は Enterprise ライセンス以上 でのみ利用可能です。
Discussion