Elastic Certified Engineer Exam対策 – Data Stream

Training banner for Elastic Certified Engineer Exam: Data Stream Training, with an instructor icon and bold 'TRAINING' label. トレーニング

このブログの目的

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

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

Data Management – Define an index template that creates a new data stream

Data Streamは、Elastic Stackにおける時系列データ管理の標準的な仕組みです。ログやメトリクスなどの大量データを効率的に管理するために利用されており、その内部ではRolloverやAliasの考え方が活用されています。

試験ではData Streamの作成方法だけでなく、Index Templateとの関係、Backing IndexやWrite Indexの役割、ILMとの連携などを理解していることが求められます。

本記事では、Data Streamの基本概念から作成方法、内部構造、ILMとの連携までを実際のAPI実行例を交えながら解説します。Data Streamがどのような仕組みで動作しているのかを理解し、試験だけでなく実運用にも活用できる知識の習得を目指しましょう。

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

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

Data Streamとは

Data Streamの概要

Data Streamは、ログやメトリクス、トレースなどの時系列データを効率的に管理するための仕組みです。Elastic Stackでは、継続的に大量のデータが生成・蓄積される用途において、Data Streamの利用が推奨されています。

従来のIndex運用では、Indexの肥大化を防ぐために定期的なRolloverや書き込み先の切り替えを管理する必要がありました。一方、Data Streamを利用すると、これらの管理をElasticsearchが自動的に行うため、利用者はデータの保存先を意識せずに運用できます。

利用者はData Streamという論理的な名前に対してデータの登録や検索を行うだけでよく、内部的なIndex管理はElasticsearchに任せることができます。そのため、大量の時系列データを長期間運用する環境において、管理負荷を軽減しながら効率的にデータを管理できます。

本章では、Data Streamを構成する要素や内部構造、Rolloverとの関係について順番に解説していきます。

Data Streamが必要になる理由

Index肥大化による運用上の課題

ログやメトリクスなどの時系列データは継続的に増加するため、すべてのデータを単一のIndexへ保存し続ける運用は現実的ではありません。Indexが肥大化すると、Shardサイズの増大による検索性能の低下や、障害発生時のRecovery時間の増加など、さまざまな運用上の課題が発生します。

Rollover運用の複雑さ

そのため、実運用では一定のサイズや期間ごとに新しいIndexへ切り替えるRolloverが利用されます。しかし、従来のIndex運用では、Rollover後の書き込み先の切り替えや複数Indexの管理を利用者が意識する必要があり、設定や運用が複雑になりがちでした。

Data Streamによる運用の自動化

Data Streamは、このような時系列データ運用における課題を解決するために導入された仕組みです。利用者は個々のIndexを管理するのではなく、Data Streamという単位でデータを扱うことができます。これにより、Rolloverや書き込み先の管理を自動化しながら、大量の時系列データを効率的に運用できるようになります。

時系列データの標準的な保存方式

Elastic AgentやBeatsから収集されるログ・メトリクスの多くもData Streamへ保存されており、ログ、メトリクス、トレースなどの時系列データにおいて、Elastic Stackの標準的な保存方式となっています。

Data Streamを構成する要素

Data Streamは単一のIndexではなく、複数の要素によって構成されています。利用者は通常これらを意識する必要はありませんが、Data Streamの動作を理解するためには、それぞれの役割を把握しておくことが重要です。

Data Streamを構成する主な要素は以下の3つです。

Data Stream

利用者がデータの登録や検索を行うための論理的な名前です。アプリケーションやElastic Agentは、通常このData Stream名を指定してアクセスします。

Backing Index

Data Streamの内部で実際にDocumentが保存されるIndexです。Data Streamは1つ以上のBacking Indexで構成されており、利用者からは隠蔽されています。

Write Index

現在データの書き込み先となっているBacking Indexです。新しいDocumentは常にWrite Indexへ登録されます。Rolloverが実行されると、新しいBacking Indexが作成され、それが新たなWrite Indexとなります。

Rollover・AliasとData Streamの関係

Rolloverとは

Rolloverとは、現在利用しているIndexへの書き込みを終了し、新しいIndexへ書き込み先を切り替える仕組みです。ログやメトリクスのような時系列データは継続的に増加するため、単一のIndexへデータを保存し続けるとIndexが肥大化し、検索性能や運用効率の低下につながります。

そのため、実運用ではIndexのサイズやDocument数、経過時間などを条件として定期的に新しいIndexへ切り替える運用が行われます。この切り替え処理をRolloverと呼びます。

Data Streamでも内部的にRolloverが利用されています。一定の条件を満たすと新しいBacking Indexが作成され、以降のDocumentは新しいIndexへ保存されるようになります。利用者はこの切り替えを意識する必要はありませんが、Data Streamの動作を理解するうえでRolloverの概念は重要です。

AliasとData Stream

Aliasとは、1つまたは複数のIndexに対して付与できる論理名です。利用者は実際のIndex名ではなくAlias名を指定して検索やデータ登録を行うことができます。

例えば、logs-000001 というIndexに logs というAliasを設定しておけば、アプリケーションはIndex名を直接指定することなく logs という名前でアクセスできます。そのため、Indexの切り替えや構成変更が発生しても、アプリケーション側の設定変更を最小限に抑えることができます。

また、従来のRollover運用ではAliasが重要な役割を担います。Rolloverによって新しいIndexが作成されるたびに、どのIndexへ書き込むのかを管理する必要があるためです。そのため、通常はAliasと is_write_index を組み合わせて現在の書き込み先Indexを管理します。

一方、Data StreamではAliasによる書き込み先管理を利用者が意識する必要はありません。Data Stream自身が現在の書き込み先となるBacking Indexを管理し、Rollover時の切り替えも自動的に実施します。そのため、Rolloverを利用する通常のIndex運用ではAliasが必要になりますが、Data Stream運用ではAliasは必須ではありません。

Data Streamは、このようなAliasベースのRollover運用を簡素化し、利用者が個々のIndex管理を意識せずに時系列データを扱えるようにした仕組みと考えることができます。

Data Stream Alias
なお、複数のData Streamをまとめて参照するためのData Stream Aliasも存在します。作成にはIndex Aliasと同じ _aliases APIを利用します。

Data Streamのメリット

  • Aliasや “is_write_index” を利用した書き込み先管理を意識せずに運用できること
  • Backing Indexの作成や切り替えを意識することなく、単一のData Stream名でデータを管理できること
  • ILMと連携しながらRolloverやライフサイクル管理を自動化できること
  • Elastic AgentやBeatsなど、Elastic Stackの標準的なデータ収集基盤と高い親和性を持つこと
  • ログやメトリクス、トレースなどの時系列データを管理するための標準的な仕組みとして利用できること

Data Streamの作成

Index Template

Data Streamを作成するためには、事前にIndex Templateを定義する必要があります。

Index Templateは、新しく作成されるIndexに適用するSettingsやMappingsを定義するための仕組みです。Data Streamでは、Rolloverによって新しいBacking Indexが自動的に作成されるため、すべてのBacking Indexに共通の設定を適用できるよう、Index Templateを利用します。

また、Data StreamそのものもIndex Templateをもとに作成されます。そのため、Data Streamを利用する場合は、まず対応するIndex Templateを作成することが基本となります。

本記事では、Data Streamの作成に必要な最低限の設定に絞って説明しますが、実運用ではIndex SettingsやMappings、ILM PolicyなどもIndex Templateへ定義することが一般的です。

data_streamの定義

Index TemplateをData Stream用として利用するためには、data_streamセクションを定義する必要があります。

例えば、以下のようにdata_streamを定義すると、このIndex Templateは通常のIndexではなくData Stream用のTemplateとして扱われます。

PUT _index_template/logs_template
{
  "index_patterns": ["logs-*"],
  "data_stream": {},
  "template": {
    "mappings": {
      "properties": {
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}

Elasticsearchはこの設定をもとに、Data Streamの作成やBacking Indexの管理を行います。もしdata_streamを定義しなかった場合は、通常のIndex Templateとして扱われるため、Data Streamを作成することはできません。

Data Streamを利用する際は、data_streamの定義が必須となることを覚えておきましょう。

@timestampフィールド

Data Streamでは、Timestamp Fieldとして利用される@timestampフィールドが必要です。

Data Streamは時系列データを管理するための仕組みであり、各Documentがいつ発生したデータであるかを時刻情報によって管理します。そのため、Data StreamではTimestamp Fieldとして利用される@timestampフィールドが定義されている必要があります。

また、@timestampフィールドはdate型またはdate_nanos型として扱われる必要があります。

Elastic AgentやBeatsから収集されるデータには通常@timestampが含まれているため、特別な設定を意識する機会は多くありません。しかし、独自のData Streamを作成する場合は、Data Streamが時刻情報を管理するために@timestampフィールドを利用していることを理解しておく必要があります。

以下は、@timestamp フィールドが存在しないDocumentを登録しようとした際のError

Data Streamの作成

前節では、Data Stream用のIndex Templateとして以下を作成しました。

PUT _index_template/logs_template
{
  "index_patterns": ["logs-*"],
  "data_stream": {},
  "template": {
    "mappings": {
      "properties": {
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}

このTemplateは、logs-* に一致するData StreamやBacking Indexへ適用されます。

Data Streamは、以下のAPIを利用して明示的に作成できます。

PUT _data_stream/logs-app

logs-app は logs-* に一致するため、先ほど作成した logs_template が適用されます。

また、Data Streamは必ずしも事前に作成しておく必要はありません。Data Stream用のIndex Templateが存在する場合は、Data Streamに対して初めてDocumentを登録したタイミングで自動的にData Streamが作成されます。そのため、実運用では利用するデータ収集方法や構成によって、明示的に作成する場合と自動的に作成される場合があります。

作成が成功すると、Data Streamとともに最初のBacking Indexが自動的に作成されます。利用者がBacking Indexを直接作成する必要はありません。

また、この時点で利用者から見えるのは logs-app というData Streamのみです。実際のDocumentは内部のBacking Indexへ保存されますが、その管理はElasticsearchが自動的に行います。

Data Streamの大きな特徴は、利用者が個々のIndexを意識することなく、単一のData Stream名を利用してデータの登録や検索を行える点にあります。

Data StreamへのDocument登録

Data Streamの作成後は、通常のIndexと同様にDocumentを登録できます。

例えば、以下のようにData Stream名を指定してDocumentを登録します。

POST logs-app/_doc
{
  "@timestamp": "2026-06-23T10:00:00Z",
  "message": "Application started",
  "host": "server01"
}

利用者はData Stream名を指定するだけでよく、実際にどのBacking Indexへ保存されるかを意識する必要はありません。

Data Streamは現在のWrite Indexを内部的に管理しており、新しいDocumentは自動的にWrite Indexへ保存されます。Rolloverが発生した場合でも、以降のDocumentは新しいWrite Indexへ自動的に登録されます。

Data Streamの確認

Data Streamの作成後は、Data Stream一覧や構成情報を確認できます。
以下のAPIを実行すると、現在存在するData Streamを確認できます。

GET _data_stream

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

GET _data_stream/logs-app

実行結果には、Data Stream名やGeneration、内部で利用されているBacking Indexなどの情報が表示されます。

Data Streamは利用者からIndex管理を隠蔽する仕組みですが、トラブルシューティングや運用時には現在どのBacking Indexが利用されているのかを確認することがあります。そのため、Data Streamの確認APIは実運用においてもよく利用されます。

KibanaでData Streamを確認

Stack Management > Index Management > Data Streams 画面でData Streamsは管理されています。

前節でDev Toolsで生成した”logs-app” Data Streamを確認できます。画面上からも削除、変更が可能です。

Data StreamとILM

Lifecycle Policyの適用

Data StreamはILM（Index Lifecycle Management）と連携して利用できます。ILMを利用することで、Data Streamを構成するBacking Indexに対してRolloverやPhase遷移などのライフサイクル管理を自動的に実施できます。

まずは、動作確認用のLifecycle Policyを作成します。ここではDocument数が3件に到達するとRolloverを実行し、その後1分経過するとCold Phaseへ移行する簡易的なPolicyを定義します。

PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_docs": 3
          }
        }
      },
      "cold": {
        "min_age": "1m",
        "actions": {}
      }
    }
  }
}

次に、このLifecycle PolicyをData Stream用のIndex Templateへ設定します。

PUT _index_template/logs_template
{
  "index_patterns": ["logs-*"],
  "data_stream": {},
  "template": {
    "settings": {
      "index.lifecycle.name": "logs_policy"
    },
    "mappings": {
      "properties": {
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}

Data Streamによって生成されるBacking Indexは、このTemplateの設定を引き継ぐため、Lifecycle Policyも自動的に適用されます。

最後にData Streamを作成します。

PUT _data_stream/logs-app

logs-app は logs-* に一致するため、先ほど作成した logs_template が適用されます。また、Templateに定義した logs_policy も同時に適用されるため、このData Streamを構成するBacking IndexはILMによる管理対象となります。

このように、Data Streamでは個々のBacking Indexへ直接Lifecycle Policyを設定するのではなく、Index Templateを通じて適用することが一般的です。Rolloverによって新しいBacking Indexが作成された場合も、同じLifecycle Policyが自動的に引き継がれます。

次節では、実際にDocumentを登録し、RolloverやPhase遷移の様子を確認してみましょう。

ILMによるRolloverの実践

前節では、Document数が3件に到達するとRolloverを実行し、1分後にCold Phaseへ移行するLifecycle PolicyをData Streamへ適用しました。

ここでは実際にDocumentを登録し、Data Streamがどのようにライフサイクル管理されるのかを確認してみましょう。

まず、以下のように4件のDocumentを登録します。

POST logs-app/_doc?refresh=true
{
  "@timestamp": "2026-06-23T10:00:00Z",
  "message": "message-1"
}

POST logs-app/_doc?refresh=true
{
  "@timestamp": "2026-06-23T10:00:01Z",
  "message": "message-2"
}

POST logs-app/_doc?refresh=true
{
  "@timestamp": "2026-06-23T10:00:02Z",
  "message": "message-3"
}

POST logs-app/_doc?refresh=true
{
  "@timestamp": "2026-06-23T10:00:03Z",
  "message": "message-4"
}

Lifecycle Policyでは max_docs: 3 を設定しているため、3件目のDocument登録後にRollover条件を満たします。その結果、新しいBacking Indexが作成され、4件目以降のDocumentは新しいWrite Indexへ登録されます。

現在のData Streamを確認してみましょう。

GET _data_stream/logs-app

または、Backing Indexを直接確認することもできます。

GET _cat/indices/.ds-logs-app*?v

実行結果には、以下のように複数のBacking Indexが表示されます。

.ds-logs-app-2026.06.23-000001
.ds-logs-app-2026.06.23-000002
...

これはRolloverが実行され、新しいBacking Indexが作成されたことを意味します。

利用者は常に logs-app というData Stream名を利用しているだけですが、内部ではWrite Indexが自動的に切り替えられています。これがData Streamの大きな特徴です。

さらに1分経過すると、Lifecycle Policyに従って最初のBacking IndexはCold Phaseへ移行します。利用者は個々のIndexを管理する必要はなく、ILMとData Streamの組み合わせによってライフサイクル管理を自動化できます。

次節では、Explain APIを利用してLifecycle Policyの適用状況や現在のPhaseを確認してみましょう。

Rolloverされない場合

本章のサンプルでは、max_docs: 3 を条件としてRolloverを設定しています。しかし、3件のDocumentを登録した直後にRolloverが実行されるとは限りません。

ILMはリアルタイムに動作する仕組みではなく、一定間隔でLifecycle Policyの条件を評価しています。そのため、Rollover条件を満たしていても、ILMの次回チェックまで実行が保留される場合があります。

学習や動作確認を行う際は、ILMのチェック間隔（Poll Interval）を短縮すると、Rolloverの動作を確認しやすくなります。

PUT _cluster/settings
{
  "transient": {
    "indices.lifecycle.poll_interval": "1s"
  }
}

上記設定を適用すると、ILMは1秒間隔でLifecycle Policyを評価するようになります。そのため、Rollover条件を満たした後、短時間でRolloverが実行されることを確認できます。

なお、この設定は学習や検証用途を想定したものであり、”transient”とある通り”一時的な設定”とあんりますが、実運用環境では通常デフォルト値のまま利用します。動作確認が完了したら、必要に応じて設定を元に戻しておきましょう。

設定値を確認するコマンドは以下となります。

GET _cluster/settings?include_defaults=true

Explain APIによる状態確認

ILMを利用する場合、Lifecycle Policyが期待どおりに適用されているかを確認することが重要です。その際によく利用されるのが Explain API です。

Explain APIを利用すると、Indexに対して現在どのLifecycle Policyが適用されているのか、どのPhaseに属しているのか、また現在どのActionが実行中なのかを確認できます。

例えば、前節で作成したData StreamのBacking Indexに対して以下のAPIを実行します。

GET .ds-logs-app-*/_ilm/explain

または、特定のBacking Indexを指定することもできます。

GET .ds-logs-app-2026.06.23-000001/_ilm/explain

以下は実際に出力された情報です。

{
  "indices": {
    ".ds-logs-app-2026.06.23-000001": {
      "index": ".ds-logs-app-2026.06.23-000001",
      "managed": true,
      "policy": "logs_policy",
      "index_creation_date_millis": 1782200986390,
      "time_since_index_creation": "39.04m",
      "lifecycle_date_millis": 1782201480037,
      "age": "30.82m",
      "age_in_millis": 1849201,
      "phase": "cold",
      "phase_time_millis": 1782201540087,
      "action": "migrate",
      "action_time_millis": 1782201540087,
      "step": "check-migration",
      "step_time_millis": 1782201540287,
      "step_info": {
        "message": "Waiting for all shard copies to be active",
        "shards_left_to_allocate": -1,
        "all_shards_active": false,
        "number_of_replicas": 1
      },
      "phase_execution": {
        "policy": "logs_policy",
        "phase_definition": {
          "min_age": "1m",
          "actions": {}
        },
        "version": 1,
        "modified_date_in_millis": 1782200964978
      },
      "skip": false
    }

    ～省略～

    ".ds-logs-app-2026.06.23-000004": {
      "index": ".ds-logs-app-2026.06.23-000004",
      "managed": true,
      "policy": "logs_policy",
      "index_creation_date_millis": 1782201534185,
      "time_since_index_creation": "29.91m",
      "lifecycle_date_millis": 1782201534185,
      "age": "29.91m",
      "age_in_millis": 1795054,
      "phase": "hot",
      "phase_time_millis": 1782201534483,
      "action": "rollover",
      "action_time_millis": 1782201534683,
      "step": "check-rollover-ready",
      "step_time_millis": 1782201534683,
      "phase_execution": {
        "policy": "logs_policy",
        "phase_definition": {
          "min_age": "0ms",
          "actions": {
            "rollover": {
              "max_docs": 3,
              "min_docs": 1,
              "max_primary_shard_docs": 200000000
            }
          }
        },
        "version": 1,
        "modified_date_in_millis": 1782200964978
      },
      "skip": false
    }
  }
}

この結果から、

  • ILMによって管理されているか（managed）
  • 適用されているLifecycle Policy（policy）
  • 現在のPhase（phase）
  • 実行中または直前のAction（action）

を確認できます。

上記レスポンスからは以下の情報がわかります。

Backing IndexPhaseAction状態
.ds…000001coldmigrateCold移行済み
.ds…000002coldmigrateCold移行済み
.ds…000003coldmigrateCold移行済み
.ds…000004hotrollover現在のWrite Index

前節のサンプルでは、Rollover後に1分経過するとCold Phaseへ移行するよう設定しました。そのため、一定時間経過後にExplain APIを実行すると、phase が cold になっていることを確認できます。

Explain APIはILMのトラブルシューティングでも頻繁に利用されます。例えば、「Rolloverが実行されない」「Phaseが移行しない」といった場合には、まずExplain APIを確認することで、現在どの段階で処理が進行しているのかを把握できます。

試験対策としては、Explain APIの詳細な出力内容を暗記する必要はありませんが、policy、phase、action を確認できるAPIであることは理解しておくことをお勧めします。

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

本記事では、Data Streamの基本概念から、RolloverやAliasとの関係、Index Templateの作成方法、Backing IndexとWrite Indexの役割、さらにILMとの連携について解説しました。

しかし、Data Streamは概念を理解するだけでなく、実際に作成して動作を確認することで理解が深まります。特に、Data Stream作成時のIndex Templateの定義、Document登録時のBacking Indexの生成、ILMによるRollover、Explain APIによる状態確認などは、実際に操作することで仕組みを理解しやすくなります。

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

ぜひElastic Cloud環境やElastic Learning Portalを活用し、実際にData Streamを作成しながら学習を進めてみてください。知識として理解するだけでなく、実際に手を動かして動作を確認することが、試験対策としても非常に有効です。

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

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

  • Data Streamを作成するためのIndex Templateを定義できること
  • Data Stream、Backing Index、Write Indexの関係を理解していること
  • Data Streamに対してILMを適用できること

Data Streamについては、Index Template、Index Settings、Mapping、ILM Policyを組み合わせ、要件に応じたData Streamを構築できるようにしておくことが重要です。

【参考】この記事で使用したコマンド

記事の最後に掲載するのであれば、単なるコマンド一覧ではなく、「Data Stream構築の流れ」に沿って整理した方が復習しやすいと思います。

本記事で使用した主なコマンド

1. Lifecycle Policyの作成

PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_docs": 3
          }
        }
      },
      "cold": {
        "min_age": "1m",
        "actions": {}
      }
    }
  }
}

2. Data Stream用Index Templateの作成

PUT _index_template/logs_template
{
  "index_patterns": ["logs-*"],
  "data_stream": {},
  "template": {
    "settings": {
      "index.lifecycle.name": "logs_policy"
    },
    "mappings": {
      "properties": {
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}

3. Data Streamの作成

PUT _data_stream/logs-app

4. Documentの登録

POST logs-app/_doc?refresh=true
{
  "@timestamp": "2026-06-23T10:00:00Z",
  "message": "message-1"
}

5. Data Streamの確認

全Data Streamを確認

GET _data_stream

特定のData Streamを確認

GET _data_stream/logs-app

6. Data Stream内のDocument検索

GET logs-app/_search

7. Backing Indexの確認

GET _cat/indices/.ds-logs-app*?v

8. ILMのチェック間隔変更（学習用）

PUT _cluster/settings
{
  "transient": {
    "indices.lifecycle.poll_interval": "1s"
  }
}

設定値確認

GET _cluster/settings?include_defaults=true

9. Explain APIによるILM状態確認

全Backing Indexを確認

GET .ds-logs-app-*/_ilm/explain

特定のBacking Indexを確認

GET .ds-logs-app-2026.06.23-000001/_ilm/explain