Elastic Certified Engineer Exam対策 – Index Settings・Mappings・Aliasesの設定

Banner for training: 'Elastic Certified Engineer Exam' prep with Japanese subtitle and a vertical TRAINING label on the right. トレーニング

このブログの目的

本ブログシリーズの目的は、Elastic Certified Engineer Examの合格に必要な知識と技術を体系的に習得することです。Elastic Certified Engineer Examでは、Elasticsearchの運用や設計に関する実践的なスキルが問われます。本記事は、Index Settings・Mappings・Aliasesに関する知識と実装スキルの習得を目的としており、Elastic社が公開している試験ガイドの以下の試験範囲に関連する内容を扱います。

Data Management – Define an index that satisfies a given set of requirements

Elasticsearchでは、Indexを作成する際にSettings・Mappings・Aliasesを定義できます。SettingsはIndexの動作や運用方法を制御し、MappingsはDocumentの構造やフィールド型を定義します。また、AliasesはIndexに対する論理名を提供し、ILMのRollover機能とも密接に関連しています。試験では、これらの設定項目の役割を理解するだけでなく、要件に応じて適切な設定を実装できることが求められます。

本記事では、Index Settings・Mappings・Aliasesの主要設定と実装方法を学び、試験対策に必要な知識と実践力の習得を目指します。

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

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

Index Settings・Mappings・Aliasesとは

Elasticsearchでは、Create Index APIを利用してIndexを作成します。Indexを作成する際には、主に以下3つの要素を定義できます。

  • Settings
  • Mappings
  • Aliases

これらはそれぞれ異なる役割を持っており、Indexの動作や構造、利用方法を決定します。

Create Index APIの基本構造は以下のとおりです。

PUT demo_index-000001
{
  "settings": {},
  "mappings": {},
  "aliases": {}
}

一見すると単純な構造ですが、Elastic Certified Engineer Examでは、この3つの領域について幅広い知識が求められます。

Settingsとは

Settingsは、Indexの動作や運用方法を定義するための設定です。

例えば、Primary Shard数やReplica Shard数、Refresh間隔、ILM（Index Lifecycle Management）との連携設定などを定義できます。

Settingsによって、Indexの可用性や性能、データ保持戦略などが決まります。そのため、Elasticsearchを設計・運用するうえで非常に重要な要素となります。

Mappingsとは

Mappingsは、Indexに格納されるDocumentのフィールド構造を定義するための設定です。

例えば、

  • user_nameはkeyword型
  • messageはtext型
  • created_atはdate型

といったように、各フィールドのデータ型や振る舞いを定義します。

また、Dynamic MappingやDynamic Templates、Runtime FieldなどもMappingsの一部として定義されます。

検索精度や集計結果に大きく影響するため、Mapping設計はElasticsearchにおいて特に重要な設計要素の一つです。

Aliasesとは

Aliasesは、Indexに対する別名（エイリアス）を定義するための機能です。例えば、実際のIndex名が以下のような場合、

logs-000001

利用者は直接Index名を参照するのではなく、

logs

というAlias経由でアクセスできます。

Aliasを利用することで、Index名の変更やRolloverが発生してもアプリケーション側の設定変更を最小限に抑えることができます。

また、ILMのRollover機能ではWrite Aliasが重要な役割を担うため、Elastic Certified Engineer Examでも理解しておくべき機能の一つです。

参考 : Settings / Mappings / Aliases の定義例

PUT demo_index-000001
{
  // 1. Index Settings
  "settings": {
    "index": {
      // Primary Shard数
      "number_of_shards": 3,

      // Replica Shard数
      "number_of_replicas": 1,

      // Refresh間隔
      "refresh_interval": "30s",

      // Recovery優先度
      "priority": 100,

      // Default Pipeline
      "default_pipeline": "demo_pipeline",

      // ILM PolicyおよびRollover Alias
      "lifecycle": {
        "name": "demo_policy",
        "rollover_alias": "demo_alias"
      },

      // Data Tier割り当て
      "routing": {
        "allocation": {
          "include": {
            "_tier_preference": "data_hot"
          }
        }
      }
    }
  },

  // 2. Mapping
  "mappings": {

    // Dynamic Mapping
    "dynamic": true,

    // Numeric Detection
    "numeric_detection": true,

    // Date Detection
    "date_detection": true,

    // Dynamic Date Formats
    "dynamic_date_formats": [
      "strict_date_optional_time",
      "yyyy/MM/dd",
      "yyyy/MM/dd HH:mm:ss"
    ],

    // _source設定
    "_source": {
      "enabled": true,
      "includes": [
        "*"
      ],
      "excludes": [
        "internal_*"
      ]
    },

    // Routing設定
    "_routing": {
      "required": false
    },

    // Metadata設定
    "_meta": {
      "owner": "training",
      "purpose": "demo"
    },

    // Dynamic Template
    "dynamic_templates": [
      {
        "strings_as_keyword": {
          "match_mapping_type": "string",
          "mapping": {
            "type": "keyword"
          }
        }
      }
    ],

    // Runtime Field
    "runtime": {
      "is_large_transfer": {
        "type": "boolean",
        "script": {
          "source": "emit(doc['bytes'].size()!=0 && doc['bytes'].value > 1000000)"
        }
      }
    },

    // フィールド定義
    "properties": {
      "@timestamp": {
        "type": "date"
      },
      "host": {
        "type": "keyword"
      },
      "message": {
        "type": "text"
      },
      "bytes": {
        "type": "long"
      }
    }
  },

  // 3. Aliases
  "aliases": {
    "demo_alias": {
      "is_write_index": true
    }
  }
}

上記サンプルでは、Elastic Certified Engineer Examで出題範囲となる設定項目や、関連知識として理解しておきたい設定項目を効率よく学習できるよう、1つのCreate Index APIに多数の設定をまとめています。実際のシステムでは、これらの設定をすべて同時に利用するケースは多くありませんが、Index Settings・Mappings・Aliasesで利用できる代表的な設定を俯瞰的に理解するためのサンプルとして掲載しています。

また、実際の運用環境では、Create Index APIにすべての設定を直接記述するのではなく、Component TemplateやIndex Templateを利用して設定を部品化し、複数のIndexで再利用する構成が一般的です。例えば、Mapping定義、ILM設定、Shard数、Ingest Pipeline設定などをそれぞれComponent Templateとして管理し、それらをIndex Templateから組み合わせて適用します。本記事では学習しやすさを優先して1つのCreate Index APIに集約していますが、実運用ではTemplateを活用した管理方法も併せて理解しておくことをお勧めします。

Settingsの主要設定

本章では、以下のCreate Index APIを題材として、Elastic Certified Engineer Examで特に重要となるIndex Settingsについて解説します。

この設定には、Primary Shard数を定義する number_of_shards、Replica Shard数を定義する number_of_replicas、検索可能になるまでの間隔を制御する refresh_interval、Cluster復旧時の優先度を指定する priority、Document投入時に自動実行される Ingest Pipeline を指定する default_pipeline などが含まれています。

また、ILM（Index Lifecycle Management）で利用する lifecycle.name や lifecycle.rollover_alias、Data Tierへの配置を制御する _tier_preference も定義されています。これらは試験範囲に関連する設定や、Elasticsearchの運用において理解しておきたい代表的な設定項目です。

実際の業務では、すべての設定を同時に利用するケースは多くありません。しかし、Index Settingsにはどのような設定項目が存在し、それぞれがどのような役割を持つのかを体系的に理解しておくことが重要です。

以降の節では、上記サンプルで使用している主要な設定について順番に確認していきます。

number_of_shards

number_of_shardsは、Indexを構成するPrimary Shardの数を定義する設定です。

今回のサンプルでは、以下の設定によって3つのPrimary Shardが作成されます。

"number_of_shards": 3

Elasticsearchでは、1つのIndexが内部的に複数のShardへ分割されます。Shardは実体としてはLucene Indexであり、Elasticsearchは複数のShardを組み合わせることで大量のデータを管理しています。

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

Index
├─ Primary Shard 0
├─ Primary Shard 1
└─ Primary Shard 2

Shardに分割することで、複数ノードへデータを分散配置できるようになり、大量データの格納や検索性能の向上を実現できます。

また、Elasticsearchにおけるデータ格納の階層構造は概ね以下のようになります。

Index
 └─ Shard
      └─ Segment

DocumentはShardへ格納され、Shard内部ではSegmentという単位で管理されます。Segmentについては、後述するRefreshの理解にも関係するため、概念として把握しておきましょう。

number_of_shardsを設計する際は、「将来的にどの程度データが増加するか」「どの程度のノード数で運用するか」を考慮する必要があります。

なお、Elastic Certified Engineer Examでは重要なポイントとして、number_of_shardsはIndex作成後に変更できないことを理解しておく必要があります。

number_of_replicas

number_of_replicasは、Primary Shardの複製であるReplica Shardの数を定義する設定です。

今回のサンプルでは、各Primary Shardに対して1つのReplica Shardが作成されます。

"number_of_replicas": 1

例えば、Primary Shardが3個存在する場合、Replica Shardも3個作成されます。

Primary Shard 0
Replica Shard 0

Primary Shard 1
Replica Shard 1

Primary Shard 2
Replica Shard 2

Replica Shardには主に以下の役割があります。

  • 障害発生時の冗長化
  • 検索処理の分散

あるノードが停止した場合でも、Replica Shardが存在していればサービスを継続できます。また、検索処理はPrimary ShardだけでなくReplica Shardにも分散できるため、検索性能の向上にも寄与します。

number_of_replicasは動的設定であり、Index作成後でも変更可能です。
例えば、以下のように変更できます。

PUT demo_index-000001/_settings
{
  "number_of_replicas": 2
}

Elastic Certified Engineer Examでは、

  • number_of_shardsは変更不可
  • number_of_replicasは変更可能

という違いを理解しておくことが重要です。

refresh_interval

refresh_intervalは、Documentを検索可能にするまでの間隔を定義する設定です。

今回のサンプルでは30秒ごとにRefreshが実行されます。

"refresh_interval": "30s"

ElasticsearchはDocumentを受信すると、まずメモリ上に保持します。その後、Refresh処理によって新しいSegmentが検索可能な状態となります。

この仕組みにより、ElasticsearchはNear Real Time Search（NRT検索）を実現しています。

一般的なRDBMSのように即座に検索可能になるわけではなく、Refreshが実行されたタイミングで検索結果に反映されます。

refresh_intervalを短くすると検索への反映は速くなりますが、その分Refresh処理が頻繁に実行されるためIndexing性能へ影響する場合があります。

逆に大量データを高速投入したい場合は、”-1”を指定することで、自動Refreshを無効化することも可能です。

"refresh_interval": "-1"
  • RefreshはDocumentを検索可能にする処理
  • Refreshによって新しいSegmentが検索対象になる

Elastic Docs > Reference > Elasticsearch > Index settings > General > index.refresh_interval

https://www.elastic.co/docs/reference/elasticsearch/index-settings/index-modules

priority

priorityは、Cluster再起動後やNode障害からの復旧時におけるIndexのRecovery優先度を定義する設定です。今回のサンプルでは、priorityを100に設定しています。

"priority": 100

Elasticsearch Clusterが再起動した場合、すべてのIndexが同時に復旧されるわけではありません。priorityの値が大きいIndexほど優先的にRecoveryが実行されます。

例えば、業務上重要なログや検索サービス向けのIndexには高いpriorityを設定し、過去データを格納するアーカイブ用Indexには低いpriorityを設定するといった運用が可能です。

通常の検索やIndexingには影響しないため利用頻度は高くありませんが、Recovery動作を制御できる設定として知識として理解しておくとよいでしょう。

default_pipeline

default_pipelineは、Document投入時に自動実行されるIngest Pipelineを指定する設定です。

今回のサンプルでは、demo_pipelineというPipelineを指定しています。

"default_pipeline": "demo_pipeline"

通常、Pipelineを利用する場合は以下のようにpipelineパラメータを指定します。

POST demo_index-000001/_doc?pipeline=demo_pipeline
{
  "message": "hello"
}

一方、default_pipelineを設定している場合は、pipelineパラメータを指定しなくても自動的にPipelineが実行されます。

POST demo_index-000001/_doc
{
  "message": "hello"
}

Ingest Pipelineでは、Document投入時にフィールド追加や値変換、GeoIP解析、User Agent解析などを実行できます。

Elastic Certified Engineer ExamではPipelineの作成や利用方法が問われることがあります。そのため、IndexへPipelineを関連付ける方法としてdefault_pipelineの存在を理解しておくとよいでしょう。

lifecycle.name

lifecycle.nameは、IndexへILM（Index Lifecycle Management）Policyを関連付ける設定です。今回のサンプルでは、demo_policyというILM Policyを適用しています。

"lifecycle": {
  "name": "demo_policy"
}

ILMは、Indexのライフサイクルを自動管理する仕組みです。

例えば、

  • Hot Phaseでデータを受け付ける
  • Warm PhaseでRead Only化する
  • Cold Phaseへ移動する
  • 一定期間後に削除する

といった処理を自動化できます。lifecycle.nameを設定すると、対象Indexは指定したILM Policyに従って管理されるようになります。大量のログデータやメトリクスデータを長期間管理する環境では、ILMは非常に重要な機能です。

lifecycle.rollover_alias

lifecycle.rollover_aliasは、ILMのRollover処理で利用するWrite Aliasを指定する設定です。今回のサンプルでは、demo_aliasを指定しています。

"lifecycle": {
  "rollover_alias": "demo_alias"
}

Rolloverとは、一定サイズや一定期間に到達したIndexを新しいIndexへ切り替える機能です。例えば、

demo_alias
 └─ demo_index-000001

という状態から、

demo_alias
 ├─ demo_index-000001
 └─ demo_index-000002 (Write Index)

へ自動的に切り替えることができます。

ILMでRollover Actionを利用する場合は、通常以下の3要素が必要になります。

  • Index名（末尾に連番を持つ）
  • Write Alias
  • lifecycle.rollover_alias

試験ではRollover関連の設定を求められるケースがあるため、AliasとILMの関係を理解しておくことが重要です。

ILMでRolloverを利用する場合、
・lifecycle.rollover_aliasで指定するAliasと、
・aliasesで定義するWrite Alias
は同一である必要があります。また、そのAliasは対象Indexを指し、is_write_indexがtrueに設定されている必要があります。これらの条件を満たしていない場合、ILMはRollover対象Indexを特定できず、Rollover処理は失敗します。

_tier_preference

_tier_preferenceは、IndexをどのData Tierへ配置するかを指定する設定です。今回のサンプルでは、data_hotを指定しています。

"_tier_preference": "data_hot"

ElasticではNodeを用途別に分類するData Tierという仕組みがあります。代表的なTierは以下のとおりです。

Tier主な用途
Hot頻繁に書き込み・検索されるデータ
Warm更新頻度が低いデータ
Cold長期保管データ
FrozenSearchable Snapshotを利用した超長期保管データ
Content一般的な検索コンテンツ

_tier_preferenceを設定すると、Elasticsearchは対象Indexを指定したTierを持つNodeへ優先的に配置します。

例えば、

"_tier_preference": "data_hot,data_warm"

のように複数指定することも可能です。

Dynamic TemplatesとRuntime Field

Dynamic TemplatesとRuntime Fieldについては、それぞれ別途コンテンツを用意している為、そちらを参照ください。

Dynamic Templates → 『Dynamic Template』
Runtime Field → 『Runtime Field』

Mappingsの主要設定

Mappingsは、Indexに格納されるDocumentの構造や各フィールドのデータ型を定義するための仕組みです。Elasticsearchでは、フィールドの型定義だけでなく、Dynamic Mappingの動作制御や、_source、_routingといったメタ情報に関する設定もMappingsの中で定義します。

Mappingの基本的な考え方や、date・keyword・text・longなどの代表的なフィールド型については、「IndexとMapping」の記事で詳しく解説しています。本章では、Elastic Certified Engineer Examで理解しておきたいMappingsの主要設定について確認していきます。

dynamic

dynamicは、Document投入時に新しいフィールドが検出された場合の動作を制御する設定です。

Elasticsearchでは、あらかじめMappingに定義されていないフィールドが投入された場合、自動的にMappingを生成できます。この機能をDynamic Mappingと呼びます。設定値は以下のとおりです。

値動作
true自動的にMappingを作成
falseMappingは作成しない
strict未定義フィールドが存在するとエラー
runtimeRuntime Fieldとして追加

numeric_detection

numeric_detectionは、文字列として投入された値を数値として自動判定する機能です。

例えば、以下のDocumentを投入した場合、

{
  "price": "100"
}

numeric_detectionが有効であれば、Elasticsearchは文字列ではなく数値と判断し、自動的にlong型やfloat型のMappingを生成します。

{
  "price": {
    "type": "long"
  }
}

通常、文字列はtextまたはkeywordとして扱われますが、numeric_detectionを利用することで数値形式の文字列を自動的に数値型へ変換できます。ただし、すべての文字列が数値判定の対象になるわけではないため、実運用では明示的なMapping定義が推奨されるケースもあります。

date_detection

date_detectionは、文字列として投入された値を日付として自動判定する機能です。

例えば、以下のようなDocumentを投入すると、

{
  "created_at": "2025-01-01"
}

Elasticsearchは値を日付形式として認識し、自動的にdate型のMappingを生成します。

{
  "created_at": {
    "type": "date"
  }
}

Dynamic Mappingでは、文字列が日付形式に一致するとdate型として登録されます。この挙動を無効化したい場合はdate_detectionをfalseに設定します。

dynamic_date_formats

dynamic_date_formatsは、date_detectionで利用される日付フォーマットを定義する設定です。

例えば、以下のように設定できます。

"dynamic_date_formats": [
  "strict_date_optional_time",
  "yyyy/MM/dd",
  "yyyy/MM/dd HH:mm:ss"
]

date_detectionが有効な場合、新しいフィールドの値がdynamic_date_formatsで定義された形式に一致すると、自動的にdate型としてMappingが作成されます。

つまり、

  • date_detection：日付判定を行うか
  • dynamic_date_formats：どの形式を日付として認識するか

を制御する設定となります。

試験では両者の役割の違いを理解しておくことが重要です。

_source

_sourceは、投入された元のDocumentを保存するための設定です。

Elasticsearchでは、投入されたJSONドキュメントが通常そのまま_sourceに保存されます。

"_source": {
  "enabled": true
}

主な設定項目は以下のとおりです。

設定説明
enabled_sourceの保存有無
includes保存対象フィールド
excludes保存対象外フィールド

例えば、

"_source": {
  "includes": ["*"],
  "excludes": ["internal_*"]
}

のように設定すると、internal_で始まるフィールドを_sourceから除外できます。

_sourceはGet APIやUpdate API、Reindex APIなど多くの機能で利用されるため、無効化する場合は影響範囲を十分に理解する必要があります。

_sourceを無効化すると検索できなくなるのでは？
_sourceを無効化すると検索できなくなるのでは？と思うかもしれませんが、Elasticsearchの検索処理は主にInverted IndexやDoc Valuesを利用して実行されます。そのため、_sourceを無効化していても検索自体は可能です。ただし、検索結果として元のJSONドキュメントを返却する際には通常_sourceが利用されるため、_sourceを無効化すると検索結果に元データが表示されなくなります。また、Get API、Update API、Reindex APIなど_sourceに依存する機能も利用できなくなるため、無効化する際は十分な検討が必要です。

_routing

_routingは、DocumentをどのShardへ格納するかを制御するための設定です。

通常、ElasticsearchはDocument IDを利用して自動的に格納先Shardを決定します。しかし、Custom Routingを利用すると利用者がRouting値を指定できます。

例えば、

POST demo_index/_doc?routing=user001

のように指定すると、同じrouting値を持つDocumentは同一Shardへ格納されます。

また、

"_routing": {
  "required": true
}

と設定すると、Document投入時にrouting指定が必須になります。試験では、Custom Routingの存在とrequiredパラメータの意味を理解しておけば十分です。

『routing=』で指定している値は？
『routing=』には、DocumentをどのShardへ格納するかを決定するための任意の文字列を指定します。Elasticsearchは指定された値から内部的にHash値を計算し、その結果をもとに格納先Shardを決定します。同じRouting値を持つDocumentは常に同じPrimary Shardへ格納されるため、関連データを同一Shardへ集約でき、検索時の効率向上につながります。

_meta

_metaは、Mappingに任意のメタデータを保存するための設定です。例えば、

"_meta": {
  "owner": "training",
  "purpose": "demo"
}

のように定義できます。_metaに保存した情報は検索や集計には利用されません。あくまで利用者向けの管理情報として保持されるだけです。

例えば、

  • Indexの管理者
  • システム名
  • 用途
  • バージョン情報

などを記録しておくことができます。Mappingに独自情報を付与できる仕組みとして知識レベルで理解しておくとよいでしょう。

Aliasesの主要設定

Aliasesは、Indexに対する別名（エイリアス）を定義する機能です。例えば、実際のIndex名が logs-000001 であっても、利用者やアプリケーションは logs というAlias経由でアクセスできます。

Aliasを利用することで、Index名の変更やRolloverが発生してもアプリケーション側の設定変更を最小限に抑えることができます。特にILM（Index Lifecycle Management）のRollover機能ではAliasが重要な役割を担うため、Elastic Certified Engineer Examでも理解しておきたい機能の一つです。

Aliasとは

Aliasは、1つまたは複数のIndexに対して付与できる論理名です。例えば、以下のようにAliasを定義できます。

PUT logs-000001
{
  "aliases": {
    "logs": {}
  }
}

この場合、利用者は実際のIndex名である logs-000001 を意識することなく、”logs”というAliasを利用して検索できます。また、Write Aliasとして構成されている場合はAlias経由で書き込みも可能です。

GET logs/_search

また、Aliasは複数のIndexに対して関連付けることも可能です。

logs
 ├─ logs-000001
 ├─ logs-000002
 └─ logs-000003

この場合、Alias経由で複数のIndexを一括検索できます。

Aliasを利用することで、アプリケーションと実際のIndex名を分離できるため、Indexの切り替えや運用変更が容易になります。

ILMとRollover Alias

ILMでRolloverを利用する場合、Aliasは非常に重要な役割を担います。例えば、以下のように rollover_alias を設定します。

{
  "settings": {
    "index": {
      "lifecycle": {
        "name": "my_logs_policy",
        "rollover_alias": "my_logs"
      }
    }
  }
}

Rolloverとは、一定サイズや一定期間に到達したIndexを新しいIndexへ切り替える機能です。Rollover前は以下のような構成となります。

alias"my_logs"の参照先
    ↓
my_logs-000001 (Write Index)

Rollover後は、新しいIndexが作成され、書き込み先が切り替わります。

alias"my_logs"の参照先 (is_write_indexの設定も自動で変更される)
 ├─ my_logs-000001 (過去データ)
 └─ my_logs-000002 (Write Index)

このように、Aliasの参照先に新しいIndexが追加され、書き込み先（Write Index）が自動的に切り替わります。ILMでRolloverを利用する場合は、通常以下の3要素が必要になります。

  • Index名（末尾に連番を持つ）
  • Write Alias
  • lifecycle.rollover_alias

また、”lifecycle.rollover_alias” で指定するAliasと、”aliases” で定義するAliasは同一である必要があります。

Index TemplateとAlias

Rolloverを利用するIndexでは、AliasをCreate Index APIへ直接定義するのではなく、Index Templateへ定義することが一般的です。

PUT _index_template/my_logs_template
{
  "index_patterns": ["my_logs-*"],
  "template": {
    "settings": {
      "index": {
        "lifecycle": {
          "name": "my_logs_policy",
          "rollover_alias": "my_logs"
        }
      }
    },
    "aliases": {
      "my_logs": {}
    }
  }
}

Rolloverによって新しいIndexが自動生成された場合でも、Templateに定義したAlias設定を後続Indexへ継承できるためです。また、Template内のAlias定義には通常 is_write_index は設定しません。is_write_index は現在のWrite Indexを示す設定であり、初回Index作成時に設定した後は、Rollover処理によって自動的に管理されるためです。

is_write_indexの役割

“is_write_index” は、Alias経由でDocumentを書き込む際に、どのIndexを書き込み先とするかを決定する設定です。Rolloverを利用する環境では、初回のIndex作成時にWrite Indexを明示する必要があります。

PUT my_logs-000001
{
  "aliases": {
    "my_logs": {
      "is_write_index": true
    }
  }
}

複数のIndexが同じAliasを共有している場合、is_write_index : true が設定されていないと、ElasticsearchはどのIndexへDocumentを書き込めばよいか判断できません。

また、ILMは現在のWrite Indexを基準としてRolloverを実行するため、初回Indexに is_write_index : true が設定されていない場合、Rollover処理は失敗します。

初回IndexでWrite Indexを設定した後は、以降のWrite Indexの切り替えをRollover処理が自動的に管理します。

下図は、『5.2』『5.3』『5.4』をまとめた概念図となります。

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

本記事では、Index Settings・Mappings・Aliasesの主要な設定について解説しました。number_of_shardsやnumber_of_replicas、refresh_intervalといったIndex Settingsに加え、dynamicや_source、_routingなどのMappings設定、さらにAlias・rollover_alias・is_write_indexの役割について確認しました。

しかし、これらの設定は単に名称や構文を覚えるだけでは十分ではありません。実際にIndexを作成し、Mappingを定義し、Alias経由でDocumentを投入しながら動作を確認することで理解が深まります。特に、ILMによるRolloverやAliasの切り替えは、実際に手を動かして確認することで仕組みを理解しやすくなります。

Elastic社では、ElasticsearchやElastic Cloudを実際に操作しながら学習できる無償のHands-on Trainingを提供しています。これらのトレーニングでは、Index設計、Mapping、ILM、Ingest Pipeline、Query DSLなど、Elastic Certified Engineer Examで重要となる機能が含まれています。

ぜひElastic Cloud環境やHands-on Trainingを活用し、Index Settings・Mappings・Aliasesを実際に設定しながら理解を深めてください。知識だけでなく実装経験を積むことが、試験対策としても非常に有効です。

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

試験で問われるポイント

  • Indexの主要Settingsを要件に応じて設定できること
  • Mappingを利用して適切なフィールド定義ができること
  • Dynamic Mapping関連の挙動を制御できること
  • AliasおよびWrite Aliasを適切に構成できること

Elastic Certified Engineer Examでは、「要件を満たすIndexを作成する」といった単独の問題ではなく、本記事で扱ったIndex Settings・Mappings・Aliasesと、Index Template、Component Template、ILM、Data Streamなどを組み合わせた実装問題が出題されます。そのため、各機能を個別に理解するだけでなく、どのように連携して利用されるのかを理解することが重要です。ぜひ他の記事も併せて参照し、知識を横断的に整理しながら試験対策を進めてください。