📚 OpenSearch Service ISM ポリシー

インデックスのライフサイクル管理を図書館の書籍管理で理解する

🎯 この資料で分かること

  • ISMポリシーは「図書館の書籍管理システム」 - 新刊から古書、アーカイブまで自動で整理
  • インデックスの自動ライフサイクル管理 - 時間経過やサイズに応じて自動的に状態を変更
  • コスト最適化の鍵 - 古いデータを低コストストレージに移動して最大90%削減
  • パフォーマンス維持 - 最新データは高速ストレージ、古いデータは低コストストレージで効率化
  • 完全自動化 - 人手を介さずにポリシーに基づいて自動実行

📖 たとえ話：図書館の書籍管理システム

🏛️ 図書館で考えるとわかりやすい！

大きな図書館を想像してください。新刊はすぐ手に取れる 新刊コーナー に配置され、 時間が経つと 一般書架 へ移動、さらに古くなると 書庫 へ、 最終的には読まれなくなった本は 廃棄 されます。

OpenSearch ServiceのISMポリシーは、まさにこの図書館の書籍管理と同じ。 インデックス（データ） を自動的に最適な「場所」に移動させ、 コストとパフォーマンスのバランスを取ります。

📚 新刊コーナー

👥 よく読まれる新しい本
Hot Storage

最も頻繁にアクセスされる最新のインデックス。高速なSSDストレージに配置。

📖 一般書架

📅 少し古い本
Warm Storage

時々アクセスされるインデックス。読み取り専用にしてコスト削減。

🗄️ 書庫（地下倉庫）

📦 滅多に読まれない古書
Cold/UltraWarm Storage

まれにしかアクセスされないインデックス。低コストストレージに移動。

🗑️ 廃棄処分

❌ もう必要ない本
Delete

保持期間を過ぎたインデックスを完全削除してストレージを解放。

🔧 ISMポリシーとは？

💡 Index State Management (ISM)

ISMポリシー は、OpenSearchインデックスのライフサイクルを自動管理するための仕組みです。 時間の経過やインデックスのサイズなどの条件に基づいて、自動的にアクションを実行します。

ISMポリシーの3つの要素

🔄

States（状態）

インデックスが現在いる「場所」。例：Hot、Warm、Cold、Delete

📚 図書館の例：新刊コーナー、一般書架、書庫など

⚡

Actions（アクション）

各状態で実行する具体的な操作。例：read-only化、スナップショット作成、削除

📚 図書館の例：貸出禁止、書庫への移動、廃棄処分

🎯

Transitions（遷移条件）

次の状態に移る条件。例：7日経過、50GB超過

📚 図書館の例：発行から3ヶ月、1年間未貸出など

🔄 インデックスのライフサイクルフロー

典型的なインデックスの一生

1
Hot
作成直後
読み書き可能
高速SSD
→
2
Warm
7日経過
読み取り専用
コスト削減
→
3
Cold
30日経過
低頻度アクセス
S3ベース
→
4
Delete
90日経過
完全削除
容量解放

📚 図書館での流れ

新刊（1週間） → 新刊コーナーで誰でも自由に借りられる
一般書（1ヶ月） → 一般書架に移動、貸出は継続
古書（3ヶ月） → 地下書庫に移動、リクエストがあれば取り出す
廃棄（1年） → 誰も借りないので処分して棚を空ける

⚙️ 主要なISMアクション

🔒

read_only

インデックスを読み取り専用に設定

💡 新規書き込みを防ぎ、Warmストレージへの移行準備

📦

snapshot

S3にスナップショットを作成

💡 バックアップを取得してデータを保護

🔥

force_merge

セグメントを統合して最適化

💡 検索パフォーマンス向上とストレージ削減

🧊

warm_migration

UltraWarmストレージに移行

💡 S3ベースの低コストストレージに移動（最大90%削減）

❄️

cold_migration

Coldストレージに移行

💡 さらに低コスト（アクセス時に解凍が必要）

🗑️

delete

インデックスを完全削除

💡 不要になったデータを削除してコスト削減

📊

rollover

条件を満たしたら新インデックス作成

💡 サイズや経過時間で自動的にインデックスをロールオーバー

📉

shrink

シャード数を削減

💡 古いインデックスのリソース使用を最適化

💻 実装例：ログ管理ISMポリシー

アプリケーションログを管理する典型的なISMポリシーの例です。

{ "policy" : { "description" : "Application logs lifecycle policy" , "default_state" : "hot" , "states" : [ { "name" : "hot" , // 最新7日間：高速ストレージで読み書き可能 "actions" : [ { "rollover" : { "min_index_age" : "1d" , // 1日経過 "min_primary_shard_size" : "50GB" // または50GB超過 } } ], "transitions" : [ { "state_name" : "warm" , "conditions" : { "min_index_age" : "7d" // 7日経過したらWarmへ } } ] } , { "name" : "warm" , // 7-30日：読み取り専用、最適化して効率化 "actions" : [ { "read_only" : {} // 読み取り専用化 } , { "force_merge" : { "max_num_segments" : 1 // セグメント統合 } } , { "shrink" : { "num_new_shards" : 1 // 1シャードに削減 } } ], "transitions" : [ { "state_name" : "cold" , "conditions" : { "min_index_age" : "30d" // 30日経過したらColdへ } } ] } , { "name" : "cold" , // 30-90日：低コストストレージ（S3ベース） "actions" : [ { "snapshot" : { "repository" : "backup-repo" , "snapshot" : "cold-snapshot" } } , { "cold_migration" : { "timestamp_field" : "@timestamp" } } ], "transitions" : [ { "state_name" : "delete" , "conditions" : { "min_index_age" : "90d" // 90日経過したら削除へ } } ] } , { "name" : "delete" , // 90日以降：完全削除 "actions" : [ { "delete" : {} // インデックスを完全削除 } ] } ] } }

📋 ポリシーの適用方法

# ポリシーをOpenSearchに登録 PUT _plugins/_ism/policies/logs-lifecycle-policy { // 上記のポリシー定義 } # インデックステンプレートにポリシーを設定 PUT _index_template/logs-template { "index_patterns" : [ "logs-*" ], "template" : { "settings" : { "plugins.index_state_management.policy_id" : "logs-lifecycle-policy" , "plugins.index_state_management.rollover_alias" : "logs" } } }

🎯 実際のユースケース

🔍 アプリケーションログ管理

課題：

毎日50GBのログが生成され、ストレージコストが月100万円に。最新データは高速検索が必要だが、古いログはほとんどアクセスされない。

ISMソリューション：
  • 0-7日：Hotストレージで高速検索
  • 7-30日：Warm化して読み取り専用
  • 30-90日：Cold移行で90%コスト削減
  • 90日以降：自動削除

結果：月間コストを30万円に削減（70%削減）

📊 メトリクスデータ保存

課題：

IoTセンサーから1分ごとにデータが送信され、1年分のデータ保持が必要。リアルタイムデータのみ頻繁にアクセス。

ISMソリューション：
  • 当日：Hotで高速クエリ
  • 1週間：Rolloverして新インデックス作成
  • 1ヶ月：UltraWarmに移行
  • 1年：長期保存用にS3へスナップショット後削除

結果：パフォーマンス維持しながら80%のコスト削減

🛡️ セキュリティログ（コンプライアンス）

課題：

法規制で3年間のログ保持が必須。セキュリティ調査時は過去データへの高速アクセスが必要。

ISMソリューション：
  • 0-30日：Hotで即座に調査可能
  • 30-180日：Warmで検索可能を維持
  • 180日-3年：Coldで低コスト保存
  • 毎日スナップショットをS3に保存

結果：コンプライアンス要件を満たしながら大幅なコスト削減

💰 ストレージ階層別のコスト比較

ストレージ階層 相対コスト 検索速度 適切な用途
Hot (標準) 100%（基準） ⚡⚡⚡ 最速 直近7日、頻繁なクエリ
UltraWarm 約10% ⚡⚡ 高速 7-90日、時々検索
Cold 約1-2% ⚡ 遅い（解凍必要） 90日以上、稀な検索
S3 Snapshot 約0.5% ❄️ 非常に遅い 長期アーカイブ、復元時のみ

💡 コスト削減の具体例

シナリオ： 1TB/日のログを90日保存（合計90TB）

ISM未使用の場合：
すべてHotストレージ → 約 $18,000/月

ISM使用の場合：
• 0-7日 (7TB)：Hot → $1,400/月
• 7-30日 (23TB)：UltraWarm → $460/月
• 30-90日 (60TB)：Cold → $240/月
合計：約 $2,100/月（88%削減！）

🌟 ベストプラクティス

成功のための推奨事項

  • データアクセスパターンを分析 - まずはログ分析してどのデータがいつアクセスされるか把握しましょう
  • 段階的な移行期間を設定 - 7日→30日→90日のように明確な境界を設けると管理が簡単
  • Force Mergeは必ず実行 - Warm移行前にセグメント統合してストレージとパフォーマンスを最適化
  • Rolloverは1日または50GBを目安に - 大きすぎるインデックスは管理が困難
  • 削除前に必ずスナップショット - 万が一に備えてS3にバックアップを保持
  • テスト環境で検証 - 本番適用前に小規模データで動作確認
  • モニタリング設定 - CloudWatchアラームでISM実行状況を監視
  • ポリシーは複数作成 - ログタイプ別（アプリ、セキュリティ、メトリクスなど）に最適化

⚠️ よくある落とし穴と対策

🚨 注意すべきポイント

  • ❌ UltraWarm/Coldノードが未設定
    warm_migration設定してもノードがないと失敗します。事前にクラスター設定を確認！
  • ❌ Read-Only化せずにWarm移行
    書き込み可能な状態では移行できません。必ずread_onlyアクションを先に実行。
  • ❌ 遷移条件が重複
    複数の遷移条件が同時に満たされると予期しない動作に。明確な優先順位を設定しましょう。
  • ❌ Rolloverエイリアス未設定
    rolloverアクション使用時はエイリアス設定が必須。インデックステンプレートで設定を。
  • ❌ 削除前のスナップショット忘れ
    一度削除したデータは復元不可。必ずスナップショットアクションを削除前に実行。

🔧 トラブルシューティング

❓ ポリシーが実行されない

確認ポイント：
  • ポリシーがインデックスに正しく適用されているか
  • 遷移条件が適切か（min_index_ageなど）
  • ISMジョブスケジューラーが有効か
確認コマンド：
# ポリシー適用状況確認 GET _plugins/_ism/explain/my-index # ポリシー実行履歴確認 GET _plugins/_ism/policies/my-policy/_explain

❓ Warm移行が失敗する

よくある原因：
  • UltraWarmノードが不足
  • インデックスがread_onlyでない
  • シャード数が多すぎる
対策：
  • UltraWarmノードを追加
  • read_onlyアクションを先に実行
  • shrinkアクションでシャード削減

❓ パフォーマンスが低下

考えられる原因：
  • Force Merge実行中の高負荷
  • 大量のインデックスの同時移行
  • Coldからの頻繁なアクセス
最適化：
  • Force Mergeはオフピーク時に実行
  • 移行をバッチで段階的に実施
  • アクセスパターンに応じて遷移期間を調整

📊 ISMのモニタリング

監視すべきメトリクス

  • 📈 各状態のインデックス数 - Hot/Warm/Coldの分布を確認
  • 💾 ストレージ使用量 - 階層別のストレージ消費を監視
  • ⚠️ ポリシー実行エラー - 失敗したアクションを早期発見
  • ⏱️ 遷移実行時間 - 移行処理のパフォーマンス確認

CloudWatch監視設定例

# ISM失敗アラーム設定 aws cloudwatch put-metric-alarm \ --alarm-name opensearch-ism-failures \ --metric-name ISMActionsFailed \ --namespace AWS/ES \ --statistic Sum \ --period 300 \ --threshold 1 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 1 # ストレージ使用率アラーム aws cloudwatch put-metric-alarm \ --alarm-name opensearch-storage-high \ --metric-name ClusterUsedSpace \ --namespace AWS/ES \ --statistic Average \ --period 300 \ --threshold 85 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 2

📝 まとめ

🎓 重要ポイントの再確認

  • 1️⃣ ISMは図書館の書籍管理
    新刊から古書、アーカイブまで自動的に最適な場所に移動
  • 2️⃣ 3つの要素で構成
    States（状態）、Actions（アクション）、Transitions（遷移条件）
  • 3️⃣ 大幅なコスト削減
    UltraWarmで90%、Coldで最大98%のストレージコスト削減
  • 4️⃣ パフォーマンス維持
    最新データは高速、古いデータは低コストで両立
  • 5️⃣ 完全自動化
    人手不要でポリシーに基づき24時間365日稼働

🚀 次のステップ

  • 自社のデータアクセスパターンを分析してISMポリシーを設計
  • 小規模環境でテスト実施して動作を確認
  • CloudWatchでモニタリング設定して継続的に最適化
  • 定期的にコスト効果を測定してポリシーを調整

Created by SSuzuki1063

AWS SAP Learning Resources