Elastic Certified Engineer Exam対策 – Index Lifecycle Management (ILM)

このブログの目的

本ブログシリーズの目的は、Elastic Certified Engineer Examの合格に必要な知識と技術を体系的に習得することです。Elastic Certified Engineer Examでは、Elasticsearchの設計・運用に関する実践的なスキルが問われます。

本記事は、Index Lifecycle Management（ILM）に関する知識と実装スキルの習得を目的としており、Elastic社が公開している試験ガイドの以下の試験範囲に関連する内容を扱います。

Data Management – Define an Index Lifecycle Management policy for a time-series index

ILMは、Indexのライフサイクルを自動的に管理するための機能です。ログやメトリクスなどの時系列データを長期間運用する環境では、Indexの世代管理やデータ保持期間の管理、ストレージコストの最適化が重要になります。試験では、ILMの基本的な仕組みを理解するだけでなく、要件に応じてLifecycle Policyを設計・実装できることが求められます。

特に、Hot・Warm・Cold・Frozen・Deleteの各Phaseの役割や、Rollover、Read Only、Shrink、Force Merge、Searchable SnapshotなどのActionを適切に選択し、要件を満たすLifecycle Policyを作成できることが重要です。また、Rollover利用時のmin_ageの挙動や、Explain Lifecycle APIを利用した状態確認についても理解しておく必要があります。

本記事では、ILMの基本概念から始まり、5つのPhaseの役割、主要Actionの概要、Lifecycle Policyの作成方法、状態確認方法、Lifecycle Policyの更新や切り替え方法までを解説します。また、実際のLifecycle Policyサンプルを通じて、認定試験で求められる実装スキルを習得することを目指します。

実際にLifecycle Policyを作成し、Indexへ適用しながら学習を進めることで、ILMの動作をより深く理解できるようになります。ぜひ実際に手を動かしながら学習を進め、試験合格につなげてください。

試験情報は以下サイトで確認可能です。

https://www.elastic.co/training/elastic-certified-engineer-exam

Index Lifecycle Management (ILM) とは

Elasticsearchでは、ログやメトリクスなどの時系列データを継続的に蓄積していくため、運用を続けるほどIndex数やデータ量が増加していきます。その結果、ストレージ使用量の増加や検索性能の低下、運用管理の複雑化といった課題が発生する場合があります。

ILMは、このような課題を解決するために提供されている、Indexのライフサイクル管理を自動化する機能です。Indexの作成から削除までの運用ルールをあらかじめ定義しておくことで、Indexの世代管理やデータ保持、ストレージ階層間の移動などを自動的に実行できます。

例えば、作成直後のIndexは高速なストレージ上で検索や更新を行い、一定期間が経過した後は低コストなストレージへ移動し、最終的には削除するといった運用を自動化できます。これにより、検索性能を維持しながらストレージコストを最適化できるようになります。

ILMでは、ライフサイクル管理のルールをLifecycle Policyとして定義します。Lifecycle Policyは複数のPhaseで構成され、それぞれのPhaseの中でActionを実行します。

• Policy：Indexのライフサイクル全体を定義する設定
• Phase：Indexが経由するライフサイクル上の各段階
• Action：各Phaseで実行される具体的な処理

例えば、以下のような構成になります。

• Lifecycle Policy
  • Hot Phase
    • Rollover
  • Warm Phase
    • Read Only
    • Shrink
    • Force Merge
  • Delete Phase
    • Delete

このように、ILMは「Policy → Phase → Action」という階層構造で管理されます。以降の章では、各Phaseの役割や代表的なAction、Lifecycle Policyの作成方法について順番に解説していきます。

なぜILMが必要なのか

ログ分析基盤や監視基盤では、日々大量の時系列データが生成されます。そのため、Indexの作成や世代管理、データの移動、不要になったIndexの削除などを手動で実施することは現実的ではありません。

ILMを利用することで、これらの運用作業を自動化できるため、運用負荷を大幅に削減できます。また、データの利用頻度に応じて適切なデータ階層へ移動できるため、検索性能とストレージコストのバランスを取りながら効率的に運用することが可能です。

ILMの5つのPhase

ILMでは、Indexのライフサイクルを複数のPhaseに分けて管理します。各Phaseは、データの利用頻度や保存期間に応じた運用を実現するための論理的な区分です。Lifecycle Policyでは、それぞれのPhaseに対して実行するActionを定義し、Indexの状態を段階的に変化させていきます。

ILMで利用できるPhaseは、Hot・Warm・Cold・Frozen・Deleteの5種類です。

Hot Phase

Hot Phaseは、Indexが作成された直後のPhaseです。新しいデータの書き込みや検索が最も頻繁に行われる期間であり、高速なストレージ上で運用されます。

時系列データを管理する環境では、多くの場合、このPhaseでRollover Actionを利用してIndexの世代管理を行います。Rolloverについては後続の記事で詳しく解説します。

Warm Phase

Warm Phaseは、一般的には書き込み頻度が大幅に低下し、主に検索用途で利用される期間です。

このPhaseでは、Indexを読み取り専用にするRead Onlyや、Primary Shard数を削減するShrink、Segment数を削減するForce MergeなどのActionが利用されます。これにより、ストレージ使用量や検索時のオーバーヘッドを削減できます。

Cold Phase

Cold Phaseは、アクセス頻度が低下したデータを保持するためのPhaseです。

検索頻度は低いものの、必要に応じて参照できる状態を維持します。一般的には、Warm Phaseよりも低コストなノードへ配置することで、ストレージコストの削減を図ります。

Frozen Phase

Frozen Phaseは、さらにアクセス頻度の低いデータを長期間保管するためのPhaseです。

このPhaseではSearchable Snapshotを利用することで、Snapshot上のデータを直接検索できるようになります。ローカルストレージの消費を抑えながらデータを保持できるため、長期保存が必要な環境で有効です。なお、Searchable SnapshotはCold Phaseでも利用可能です。

Delete Phase

Delete Phaseは、保存期間を過ぎたIndexを削除するPhaseです。

不要になったIndexを自動的に削除することで、ストレージ使用量の増加を防ぎます。ログや監査データなど、保持期間があらかじめ決まっているデータの管理でよく利用されます。

Phase遷移の仕組み

ILMでは、Indexが自動的に各Phaseを順番に遷移していきます。典型的なライフサイクルは以下のようになります。

Hot → Warm → Cold → Frozen → Delete

ただし、すべてのPhaseを定義する必要はありません。例えば、HotとDeleteのみを利用するPolicyや、Hot・Frozen・Deleteのみを利用するPolicyも作成できます。

各Phaseへ移行するタイミングは、min_ageによって制御されます。min_ageは、そのPhaseへ移行するために必要な経過時間を表します。Hot PhaseでRolloverを利用している場合はRollover時刻、利用していない場合はIndex作成時刻を基準として計算されます。

例えば、以下のようなPolicyを定義した場合、

{
  "hot": {
    "actions": {
      "rollover": {
        "max_age": "30d"
      }
    }
  },
  "warm": {
    "min_age": "30d"
  },
  "cold": {
    "min_age": "90d"
  },
  "frozen": {
    "min_age": "180d"
  },
  "delete": {
    "min_age": "365d"
  }
}

この場合、Indexは作成後30日経過するとRolloverが実行され、新しいIndexが作成されます。その後、Rolloverされた元のIndexは、Rollover実行を基準として、30日後にWarm Phaseへ移行し、90日後にCold Phaseへ移行し、180日後にFrozen Phaseへ移行し、365日後にDelete Phaseへ移行します。

重要なポイントとして、Hot PhaseでRollover Actionを利用している場合、Warm・Cold・Frozen・Delete Phaseのmin_ageはIndex作成時刻ではなく、Rollover実行時刻を基準として計算されます。

例えば上記の例では、Index作成から30日後にRolloverが発生した場合、

• Warm Phase：Index作成から60日後 = Rollover後30日
• Cold Phase：Index作成から120日後 = Rollover後90日
• Frozen Phase：Index作成から210日後 = Rollover後180日
• Delete Phase：Index作成から395日後 = Rollover後365日

に移行します。

このように、Rolloverを利用する場合は、各Phaseのmin_ageが「Index作成からの経過時間」ではなく、「Rollover実行からの経過時間」として扱われる点に注意してください。

Phase Execution

ILMは定期的にLifecycle Policyを評価し、現在のPhaseで実行すべきActionを自動的に処理します。各Actionは複数の内部Stepに分割されて実行されており、処理の進行状況はExplain Lifecycle APIから確認できます。

“Step”という概念まで試験で問われることはありませんが、indexのlifecycle statusで登場する概念となり、以下の公式Document等でも確認することが可能です。

Elastic Docs > Reference > Elasticsearch > REST APIs > Guides and examples > Understand the lifecycle status

https://www.elastic.co/docs/reference/elasticsearch/rest-apis/explain-lifecycle

POINT

• ILMにはHot、Warm、Cold、Frozen、Deleteの5つのPhaseが存在する。
• Indexは各Phaseを順番に遷移しながらライフサイクルを進める。
• Phaseの遷移タイミングはmin_ageで制御する。
• Rolloverを利用する場合、後続Phaseのmin_ageはRollover実行時刻を基準に計算される。
• Hot PhaseではRollover、Warm PhaseではRead Only・Shrink・Force Mergeが代表的なActionである。
• 試験では各Phaseの役割と代表的なActionの組み合わせを理解しておくことが重要である。

ILMで利用される主要Action

ILMでは、Phaseごとに実行する処理をActionとして定義します。Actionを利用することで、Indexの世代管理やストレージ最適化、データ保持期間の管理などを自動化できます。

本章では、認定試験で特に重要となる代表的なActionについて解説します。なお、Rolloverについては後続の記事で詳しく解説するため、本章では概要のみを説明します。

Rollover

Rolloverは、新しいIndexを作成し、書き込み先を切り替えるためのActionです。

時系列データを1つの巨大なIndexへ蓄積し続けると、検索性能や運用効率が低下する可能性があります。Rolloverを利用することで、Indexを適切なサイズや期間で分割しながら管理できるようになります。

Rolloverは主にHot Phaseで利用される代表的なActionです。一定のサイズやDocument数、経過時間などの条件を満たした場合に実行されます。Rolloverの詳細な仕組みやAliasとの関係については、後続の記事で解説します。

Read Only

PUT _ilm/policy/demo_readonly_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "30d",
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "readonly": {}
        }
      }
    }
  }
}

Read Onlyは、Indexを書き込み不可の状態にするActionです。

Warm Phaseへ移行したIndexは、通常、新しいデータを書き込む必要がありません。そのため、Indexを読み取り専用にすることで、誤更新を防ぎ、後続のShrinkやForce Mergeなどの処理を実行できる状態にします。

Shrink

PUT _ilm/policy/demo_ilm_policy_shrink
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "30d",
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "shrink": {
            "number_of_shards": 1
          }
        }
      }
    }
  }
}

Shrinkは、Primary Shard数を削減するActionです。

例えば、Hot Phaseで4シャード構成だったIndexを、Warm Phaseで1シャードへ縮小するといった運用が可能です。アクセス頻度が低下したデータに対してShard数を削減することで、クラスタリソースを効率的に利用できます。

Force Merge

PUT _ilm/policy/demo_ilm_policy_forcemerge
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "30d",
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "forcemerge": {
            "max_num_segments": 1
          }
        }
      }
    }
  }
}

Force Mergeは、Index内のSegment数を削減するActionです。

Elasticsearchでは、Indexingによって多数のSegmentが作成されます。Force Mergeを実行することでSegment数を減らし、検索時のオーバーヘッドを削減できます。

一般的には、書き込みが終了したWarm PhaseのIndexに対して利用されます。

Allocate

PUT _ilm/policy/demo_allocate_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "30d",
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "cold": {
        "min_age": "90d",
        "actions": {
          "allocate": {
            "number_of_replicas": 0
          }
        }
      }
    }
  }
}

Allocateは、Indexを特定のノードやデータ階層へ配置するためのActionです。また、number_of_replicasを利用してReplica Shard数を変更することもできます。

Allocateは、Data Tier登場以前はIndexを特定ノードへ移動するために利用されていました。現在は主にReplica数の変更や特殊なShard配置制御に利用されます。

また、Warm PhaseやCold Phaseへの移行時にReplica Shard数を増減させることで、可用性やストレージ使用量を調整することも可能です。例えば、Hot Phaseでは高可用性のためReplicaを1に設定し、Cold PhaseではReplicaを0に変更してストレージ使用量を削減するといった運用が行えます。

Allocate Actionは、Data Tier登場前のNode Attributeベース運用（box_type=warmなど）でShard配置を制御するために利用されていました。現在のData Tier運用では、ILMがPhase遷移に応じて自動的に適切なTierへ移動するため、Warm/Coldへの移動目的でAllocateを使用する必要はほとんどありません。現在は主にReplica数の変更や、特定Node・Rackへの配置制御などの用途で利用されます。

Searchable Snapshot

PUT _ilm/policy/demo_searchable_snapshot_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "30d",
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "frozen": {
        "min_age": "180d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my_repository"
          }
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {
            "delete_searchable_snapshot": true
          }
        }
      }
    }
  }
}

Searchable Snapshotは、Snapshotとして保存されたデータを直接検索できるようにするActionです。

通常、Snapshotはバックアップ用途として利用されますが、Searchable Snapshotを利用すると、Snapshotから復元することなく検索できます。そのため、Frozen Phaseにおける長期保管データの管理でよく利用されます。

Delete

PUT _ilm/policy/demo_searchable_snapshot_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "30d",
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "frozen": {
        "min_age": "180d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my_repository"
          }
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {
            "delete_searchable_snapshot": true
          }
        }
      }
    }
  }
}

Deleteは、Indexを削除するActionです。保存期間を過ぎたIndexを自動的に削除することで、不要なストレージ消費を防止できます。Delete Actionは通常、Delete Phaseで利用されます。

ActionとPhaseの関係

代表的なActionと利用されるPhaseの関係を整理すると、以下のようになります。

上記は実運用およびElastic Certified Engineer Examで特によく利用される代表的なPhaseを示しています。実際には、一部のActionは他のPhaseでも利用可能です。例えば、Read OnlyはHot・Warm・Coldで利用でき、Allocateも設定内容によっては異なるPhaseで利用できます。ただし、ShrinkやForce Mergeは通常Warm Phaseで実行され、Searchable Snapshotは通常ColdまたはFrozen Phaseで利用されます。そのため、学習や試験対策では上記の対応関係を基本として理解しておくとよいでしょう。

POINT

• Actionは、各Phaseで実行される具体的な処理である。
• Hot PhaseではRolloverが最も重要なActionである。
• Warm PhaseではRead Only、Shrink、Force Mergeが頻出である。
• Frozen / Cold PhaseではSearchable Snapshotが利用される。
• Delete Actionは不要になったIndexを自動的に削除する。
• 試験ではActionの役割と利用されるPhaseの組み合わせを理解しておくことが重要である。

ILM Policyの作成

ILMを利用するためには、まずLifecycle Policyを作成する必要があります。

Lifecycle Policyとは、IndexがどのPhaseを経由し、それぞれのPhaseでどのActionを実行するのかを定義する設定です。ILMは、このLifecycle Policyの内容に基づいてIndexを自動的に管理します。

例えば、

• Hot PhaseではRolloverを実行する
• Warm PhaseではRead OnlyとShrinkを実行する
• Delete PhaseではIndexを削除する

といった運用ルールをLifecycle Policyとして定義できます。これまで説明したPhaseやActionは、すべてLifecycle Policyの中で定義します。Lifecycle Policyは以下のような構造で定義します。

{
  "policy": {
    "phases": {
      "hot": {},
      "warm": {},
      "cold": {},
      "frozen": {},
      "delete": {}
    }
  }
}

各Phaseの中にActionを定義することで、Indexのライフサイクルを制御します。

Lifecycle Policyの定義

Lifecycle Policyでは主に以下の3つの要素を定義します。

例えば、以下のPolicyは、

• Hot PhaseでRollover
• Warm PhaseでRead Only
• Delete Phaseで削除

を実行するシンプルな例です。

PUT _ilm/policy/demo_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "readonly": {}
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

試験では、Lifecycle PolicyのJSON構造を理解し、各Phaseの中にActionを定義できることが重要です。特に、

• phases
• actions
• min_age

の3つは頻出項目です。

Lifecycle Policyの作成

Lifecycle Policyは、PUT _ilm/policy APIを利用して作成します。例えば、demo_policyという名前のLifecycle Policyを作成する場合は、以下のように実行します。

PUT _ilm/policy/demo_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb"
          }
        }
      }
    }
  }
}

Policy名は任意に設定できますが、運用環境では用途が分かる名前を付与することが一般的です。

Lifecycle Policyの確認

作成済みのLifecycle Policyは、GET _ilm/policy APIで確認できます。

すべてのPolicyを確認する場合は、以下を実行します。

GET _ilm/policy

特定のPolicyのみを確認する場合は、Policy名を指定します。

GET _ilm/policy/demo_policy

Lifecycle Policyの削除

不要になったLifecycle Policyは、DELETE _ilm/policy APIで削除できます。

DELETE _ilm/policy/demo_policy

ただし、Lifecycle Policyを削除しても、そのPolicyが適用されているIndexが自動的に削除されるわけではありません。

POINT

• Lifecycle Policyは、Indexのライフサイクル全体を定義する設定である。
• Lifecycle Policyは、Phase・Action・min_ageによって構成される。
• Lifecycle PolicyはPUT _ilm/policy APIで作成する。
• 作成済みPolicyはGET _ilm/policyで確認できる。
• 不要なPolicyはDELETE _ilm/policyで削除できる。
• 試験ではLifecycle PolicyのJSON構造を理解し、自力で作成できることが重要である。

ILM Policyサンプル

ここまで、ILMのPhaseやAction、Lifecycle Policyの作成方法について解説してきました。本章では、実際のLifecycle Policyのサンプルを確認しながら、各PhaseでどのようなActionが実行されるのかを整理していきます。

まずは、Frozen PhaseとDelete Phaseを含むLifecycle Policyの例です。

PUT _ilm/policy/logs-custom-with-frozen
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "30d"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "allocate": {
            "number_of_replicas": 1
          },
          "forcemerge": {
            "max_num_segments": 1
          }
        }
      },
      "frozen": {
        "min_age": "60d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my_backup_repository"
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {
            "delete_searchable_snapshot": true
          }
        }
      }
    }
  }
}

上記ILM Policy作成コマンドでは、Repository “my_backup_repository”を指定しているので、Policy作成前に、以下コマンドで”my_backup_repository” レポジトリを作成しておいてください。

PUT _snapshot/my_backup_repository
{
  "type": "fs",
  "settings": {
    "location": "/var/tmp/snapshots"
  }
}

※ path.repo=/var/tmp/snapshots を設定している前提となります

このPolicyでは、以下のようなライフサイクルが実現されます。

• Hot Phase
  • Primary Shardが50GBに達する、または30日経過した時点でRolloverを実行する
• Warm Phase
  • Rollover後30日経過するとWarm Phaseへ移行する
  • Replica数を1へ変更する
  • Segment数を1まで削減する
• Frozen Phase
  • Rollover後60日経過するとFrozen Phaseへ移行する
  • Searchable Snapshotを作成し、Snapshot上から検索できるようにする
• Delete Phase
  • Rollover後90日経過するとDelete Phaseへ移行する
  • Index削除時にSearchable Snapshotも同時に削除する

ここで重要なのは、Warm・Frozen・Delete Phaseに設定されているmin_ageは、Index作成時刻ではなく、Rollover実行時刻を基準として計算される点です。例えば、Index作成から30日後にRolloverが実行された場合、Warm Phaseへの移行は作成後30日ではなく、Rollover実行からさらに30日後となります。

次に、試験で頻出となるWarm Phaseの主要Actionを含んだLifecycle Policyの例を見てみましょう。

PUT _ilm/policy/logs-hot-warm-frozen
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "set_priority": {
            "priority": 100
          },
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "30d"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "set_priority": {
            "priority": 50
          },
          "readonly": {},
          "allocate": {
            "number_of_replicas": 1
          },
          "shrink": {
            "number_of_shards": 1
          },
          "forcemerge": {
            "max_num_segments": 1
          }
        }
      },
      "frozen": {
        "min_age": "90d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my_backup_repository"
          }
        }
      }
    }
  }
}

このPolicyでは、Warm Phaseで試験頻出のActionがまとめて利用されています。

• set_priority
  • Indexの復旧優先度を変更する
• readonly
  • Indexを書き込み禁止にする
• allocate
  • Replica数や配置先を変更する
• shrink
  • Primary Shard数を削減する
• forcemerge
  • Segment数を削減する

また、set_priorityは障害発生後のIndex復旧順序を制御するActionです。一般的には、Hot Phaseに高い優先度を設定し、WarmやColdへ移行するにつれて優先度を下げる構成が利用されます。

min_age設定時の注意点

Lifecycle Policyを作成する際は、各Phaseのmin_ageの関係にも注意が必要です。
例えば、以下の設定は適切です。

• Warm : 30d
• Frozen : 90d
• Delete : 365d

一方で、以下のような設定は不適切です。

• Warm : 90d
• Frozen : 30d

ILMではライフサイクルが前方へ進むため、後続Phaseのmin_ageは前のPhase以上の値を設定する必要があります。試験でもPolicy定義の妥当性を判断する問題が出題されることがあるため、理解しておきましょう。

POINT

• Lifecycle Policyは複数のPhaseとActionを組み合わせて定義する。
• Rolloverを利用する場合、後続Phaseのmin_ageはRollover実行時刻を基準に計算される。
• Warm PhaseではRead Only、Shrink、Force Mergeが特に重要である。
• Searchable SnapshotとDelete Actionを組み合わせる場合は、delete_searchable_snapshotの動作を理解しておく。
• set_priorityはIndexの復旧優先度を制御するActionである。
• 試験では、要件に応じて適切なPhase・Action・min_ageを選択し、Lifecycle Policyを自力で定義できることが重要です。各Actionの役割やPhase遷移の仕組みを理解したうえで、要件を満たすPolicyを作成できるようにしておきましょう。

ILMの状態確認

Lifecycle Policyを作成してIndexへ適用した後は、ILMが期待どおりに動作しているかを確認する必要があります。実運用では、「現在どのPhaseにいるのか」「どのActionを実行中なのか」「ILMサービス自体が正常に稼働しているのか」を確認する場面が頻繁に発生します。

本章では、試験でも重要となるExplain Lifecycle APIとILMサービスの状態確認方法について解説します。

Explain Lifecycle API

Explain Lifecycle APIは、Indexに適用されているLifecycle Policyの実行状況を確認するためのAPIです。現在のPhaseやAction、Stepなどを確認できるため、ILMのトラブルシューティングや動作確認で最も利用頻度の高いAPIの一つです。

例えば、以下のように実行します。

GET my.metrics-system-dev/_ilm/explain

実行結果には、現在のLifecycleの状態が表示されます。

この結果から、

• 適用されているPolicy名
• 現在のPhase
• 実行中のAction
• 実行中のStep

等を確認できます。

phase・action・stepとは

Explain APIでは、主に以下の3つの項目を確認します。

なお、StepはILM内部の処理単位であり、認定試験で詳細を問われることはほとんどありません。しかし、Explain APIの結果には表示されるため、phase → action → step の関係は理解しておきましょう。

ILMの進行状況確認

Explain APIを利用することで、Indexに適用されているLifecycle Policyの現在の実行状況を確認できます。具体的には、現在のPhase・Action・Stepや適用中のPolicy、経過時間などを確認できます。ILMのトラブルが発生した場合は、まずExplain APIを確認し、どのPhase・Action・Stepで処理が停止しているかを調査することが基本となります。また、現在のPhaseを確認することで、Warm・Cold・Frozen・Deleteなどの各Phaseへ移行済みかどうかを判断できます。

ILMサービスの状態確認

ILMサービス自体の状態は、以下のAPIで確認できます。

GET _ilm/status

実行結果の例です。

主な状態は以下のとおりです。

通常運用では RUNNING になっていることを確認します。もし STOPPED になっている場合は、Lifecycle Policyが定義されていてもPhase遷移やActionは実行されません。そのため、ILMが正常に稼働していることを確認することも重要です。

POINT

• Explain Lifecycle APIは、ILMの実行状況を確認するための最も重要なAPIである。
• Explain APIでは、policy・phase・action・stepを確認できる。
• phaseとactionから、現在どの処理が実行されているかを判断できる。
• ILMサービスの状態はGET _ilm/statusで確認できる。
• 試験では、ILM Policyを要件通りに設定できるかが重要。

Lifecycle Policyの更新と切り替え

ILMを利用した運用では、一度作成したLifecycle Policyを後から変更したり、別のLifecycle Policyへ切り替えたりする場面があります。

例えば、

• データ保持期間を365日から730日に変更したい
• Warm Phaseへ移行するタイミングを変更したい
• 新しいActionを追加したい
• 既存Indexに別のLifecycle Policyを適用したい

といったケースです。本章では、Lifecycle Policyの更新方法や適用中Policyの切り替え方法について解説します。

Lifecycle Policyの更新

作成済みのLifecycle Policyは、再度同じPolicy名でPUT _ilm/policy APIを実行することで更新できます。例えば、既存のPolicyにDelete Phaseを追加する場合は以下のように定義します。

PUT _ilm/policy/demo_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb"
          }
        }
      }
    }
  }
}

PUT _ilm/policy/demo_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb"
          }
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Lifecycle Policyはバージョン管理されており、更新後は新しい定義が利用されます。

ただし、既にILM管理下にあるIndexは、現在実行中のPhaseやActionの状況によっては、更新内容が直ちに反映されない場合があります。そのため、Policyを更新した後はExplain Lifecycle APIを利用して状態を確認することが重要です。

Lifecycle Policyの適用変更

Indexに適用されているLifecycle Policyは変更できます。例えば、現在demo_policyが適用されているIndexをnew_policyへ変更する場合は、Index Settingsを更新します。

PUT logs-000001/_settings
{
  "index.lifecycle.name": "new_policy"
}

適用変更後は、新しいLifecycle Policyに基づいて管理されるようになります。ただし、変更時点のPhaseやActionの状況によっては期待どおりに動作しない場合もあるため、運用環境では十分な確認が必要です。

Policy変更時の確認方法

Policyを更新したり切り替えたりした後は、Explain Lifecycle APIを利用して状態を確認します。

GET logs-000001/_ilm/explain

POINT

• Lifecycle Policyは、同じPolicy名でPUT _ilm/policyを実行することで更新できる。
• Indexに適用されているLifecycle Policyは、index.lifecycle.nameを変更することで切り替えられる。
• Lifecycle Policyは既存Indexにも適用できる。

Elastic社が提供する無料On-Demand Trainingで理解を深めよう

本記事では、Index Lifecycle Managementの基本的な考え方から、5つのPhaseの役割、代表的なAction、Lifecycle Policyの作成方法、ILMの状態確認方法、Lifecycle Policyの更新や切り替え方法までを解説しました。また、認定試験で特に重要となるRollover、Read Only、Shrink、Force Merge、Searchable Snapshotについても紹介しました。

Elastic社では、ElasticsearchやElastic Cloudを実際に操作しながら学習できる無償のHands-on TrainingやOn-Demand Trainingを提供しています。これらのトレーニングでは、ILMだけでなく、Data Stream、Index Template、Mapping、Query DSL、Aggregation、Ingest Pipelineなど、Elastic Certified Engineer Examで重要となる機能について体系的に学習できます。

特にILMは、「30日後にWarm Phaseへ移行する」「90日後にFrozen Phaseへ移行する」「Primary Shardが50GBを超えたらRolloverする」といった要件を実際にLifecycle Policyとして定義し、その後の動作を確認することで理解が深まります。また、Explain Lifecycle APIやILM Status APIを利用して現在のPhaseやActionを確認する習慣を身につけることで、試験本番でも落ち着いて対応できるようになります。

ぜひHands-on TrainingやElastic Cloud環境を活用し、Lifecycle Policyの作成からPhase遷移の確認までを実際に体験しながら理解を深めてください。

Elastic Cloud アカウント作成

https://cloud.elastic.co/registration

Elastic Training

https://www.elastic.co/training

Elastic Learning Portal

https://learn.elastic.co/pages/58/home-page

試験で問われるポイントの確認

• 要件に応じて、Hot・Warm・Cold・Frozen・Deleteを含むLifecycle Policyを定義できること。
• Rollover、Read Only、Shrink、Force Merge、Searchable Snapshotを適切なPhaseに設定できること。
• Rollover利用時のmin_ageの起点がRollover実行時刻になることを理解し、適切なPhase遷移を設計できること。
• 要件に応じてLifecycle Policyを、既存Indexへの適用を実施できること(Index TemplateでPolicyを指定)。