インデックスライフサイクル管理でHot-Warm-Coldアーキテクチャーを実装

インデックスライフサイクル管理（ILM）は、Elasticsearch 6.6（ベータ）で初めて導入された機能であり、6.7で一般提供が開始されました。ILMはElasticsearchに含まれている機能であり、インデックスの管理に役立つように設計されています。

このブログでは、ILMを使用してHot-Warm-Coldアーキテクチャーを実装する方法について説明します。Hot-Warm-Coldアーキテクチャーはログやメトリックの時系列データを扱う場合に一般的に採用されます。たとえば、Elasticsearchを使用して複数のシステムからログファイルを集約しているとします。今日のログはインデックスが進行中であり、今週のログが最も頻繁に検索されています（Hot）。先週のログは、検索はされますが今週のログほど頻繁ではありません（Warm）。先月のログは、頻繁に検索されることはありませんが、念のために保持しておくことにします（Cold）。

上記のイラストでは、クラスターに19のノードがあり、その内訳はHotノードが10、Warmノードが6、Coldノードが3となっています。*ILMでHot-Warm-Coldを実装するために19ものノードは必要ありませんが、少なくとも2つのノードが必要です。クラスターのサイズ設計は要件によって異なります。*Coldノードはオプションであり、単に、データを配置する場所をモデル化するためのもう1つのレベルを提供するものです。Elasticsearchでは、どのノードをHot、Warm、Coldにするかを定義できます。またILMでは、フェーズ間を移動するタイミングと、そのフェーズに入るときにインデックスをどう処理するかを定義できます。

すべてのHot-Warm-Coldアーキテクチャーに適合する万能なものはありませんが、一般的にHotノードには、より多くのCPUリソースとより高速なIOが必要になります。WarmおよびColdノードは一般的に、ノードごとのディスク容量がより多く必要になりますが、より少ないCPUで対応でき、より遅いIOでも許容されます。

では、始めましょう。

シャード割り当て認識の構成

Hot-Warm-Coldアーキテクチャーはシャード割り当て認識に依存するため、まずはどのノードがHot、Warm、および（オプションとして）Coldであるかをラベリングすることから始めます。これは起動パラメーター、またはelasticsearch.yml構成ファイルで設定できます。たとえば次のようにします。

bin/elasticsearch -Enode.attr.data=hot
bin/elasticsearch -Enode.attr.data=warm
bin/elasticsearch -Enode.attr.data=cold

（Elastic Cloud上のElasticsearch Serviceを使用している場合は、Elasticsearch 6.7以降で使用できるHot/Warmテンプレートを選択する必要があります）

ILMポリシーの構成

次に、ILMポリシーを定義する必要があります。ILMポリシーは、選択した数のインデックス全体で再利用でき、Hot、Warm、Cold、Deleteの4つの主なフェーズに分けられます。1つのポリシー内ですべてのフェーズを定義する必要はありませんが、ILMは常に上記の順番でフェーズを実行します（定義されていないフェーズはスキップされます）。各フェーズについて、そのフェーズに入るタイミングと、インデックスを適切に管理するための一連のアクションを定義します。Hot-Warm-Coldアーキテクチャーを実現するためには、データのHotノードからWarmノードへの移動、およびWarmノードからColdノードへの移動を定義する割り当てアクションを構成します。

Hot、Warm、Coldノード間のデータの移動だけでなく、多数の追加のアクションを構成することができます。ロールオーバーアクションは、各インデックスのサイズまたは経過時間を管理するのに使用されます。強制マージアクションは、インデックスの最適化に使用されます。また、フリーズアクションは、クラスター内のメモリープレッシャーを低減するために使用できます。その他にも多数あります。利用可能なアクションについては、ご使用のElasticsearchバージョンのドキュメントをご覧ください。

基本的なILMポリシー

非常に基本的なILMポリシーを見てみましょう。

PUT /_ilm/policy/my_policy
{
  "policy":{
    "phases":{
      "hot":{
        "actions":{
          "rollover":{
            "max_size":"50gb",
            "max_age":"30d"
          }
        }
      }
    }
  }
}

このポリシーでは、30日後またはインデックスのサイズが50gb（プライマリシャードに基づく）になった場合、インデックスがロールオーバーされ、新しいインデックスへの書き込みが開始されます。

ILMとインデックステンプレート

次に、そのILMポリシーをインデックステンプレートに関連付ける必要があります。

PUT _template/my_template
{
  "index_patterns": ["test-*"],
  "settings": {
    "index.lifecycle.name": "my_policy",
    "index.lifecycle.rollover_alias": "test-alias" 
  }
}

注：これは、ロールオーバーアクションを使用するときに、（インデックス上で直接ではなく）インデックステンプレート 内のILMポリシーを指定する場合に必要です。

ポリシーにロールオーバーアクションが含まれる場合は、インデックステンプレートの作成後に、インデックスと書き込みエイリアスもブートストラップする必要があります。

PUT test-000001 
{
  "aliases": {
    "test-alias":{
      "is_write_index": true 
    }
  }
} 

ロールオーバーに関するすべての要件が正しく満たされれば、test-*で始まる任意の新しいインデックスが30日後または50gbに達した後、自動的にロールオーバーされます。max_sizeによってインデックスのロールオーバーを管理すると、インデックスのシャード数（つまりオーバーヘッド）を大幅に削減することができます。

入力に関するILMポリシーの構成

BeatsとLogstashはILMをサポートしており、有効化されると上記の例に類似したデフォルトのポリシーがセットアップされます。また、BeatsとLogstashはロールオーバーアクションのすべての要件にも対応します。つまり、BeatsおよびLogstashでILMが有効化されると、日々のインデックスが大規模（1日あたり50db超）でない限り、新しいインデックスが作成されるタイミングが決まる主な要因は「サイズ」になる可能性が高くなります（これは良好な方法です）。7.0.0以降、BeatsおよびLogstashではロールオーバーを規定したILMがデフォルトとなります。

ただし、Hot-Warm-Coldアーキテクチャーのすべてに当てはまる汎用の方法はないため、BeatsおよびLogstashはHot-Warm-Coldポリシーを搭載した状態で提供されることはありません。Hot-Warm-Coldアーキテクチャーで機能する新しいポリシーを作成し、適用しながら最適化していくことが可能です。

BeatsまたはLogstashのデフォルトのポリシーを更新することは可能ですが、そうするとデフォルトとカスタムの違いがあいまいになってしまいます。また、デフォルトポリシーを更新すると、今後のバージョンで正しいポリシーを適用する際のリスクが高まります*（Beatsテンプレートのデフォルトは7.0以降では変更されています）*。BeatsおよびLogstashの構成を使用して、それぞれの構成を介してカスタムポリシーを定義することも可能です。これも機能はしますが、ILMポリシーを変更するために数百（または数千）のBeatsの構成を変更するのは大変です。下記で説明する3つ目のアプローチでは、複数テンプレートのマッチングを使用します。これにより、ElasticsearchでILMポリシーの完全な制御を維持できます。

Hot-Warm-ColdアーキテクチャーのILMポリシーの最適化

まずは、Hot-Warm-Coldアーキテクチャーに最適化されたILMポリシーを作成しましょう。繰り返しになりますが、すべてのケースに合う汎用の方法はなく、各自の要件は異なる可能性があります。

PUT _ilm/policy/hot-warm-cold-delete-60days
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size":"50gb",
            "max_age":"30d"
          },
          "set_priority": {
            "priority":50
          }
        }
      },
      "warm": {
        "min_age":"7d",
        "actions": {
          "forcemerge": {
            "max_num_segments":1
          },
          "shrink": {
            "number_of_shards":1
          },
          "allocate": {
            "require": {
              "data": "warm"
            }
          },
          "set_priority": {
            "priority":25
          }
        }
      },
      "cold": {
        "min_age":"30d",
        "actions": {
          "set_priority": {
            "priority":0
          },
          "freeze": {},
          "allocate": {
            "require": {
              "data": "cold"
            }
          }
        }
      },
      "delete": {
        "min_age":"60d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Hot

このILMポリシーでは、インデックス優先度を高い値に設定することから開始されています。そうすることで、Hotインデックスが他のインデックスの前に復元されます。30日後または50gb（どちらか早いほう）に達すると、インデックスはロールオーバーされ、新しいインデックスが作成されます。その新しいインデックスには再びポリシーの最初から適用されます。つまり、ロールオーバーされたばかりのインデックスはWarmフェーズに入ってから7日間、そのままWarmフェーズで維持されます。

Warm

インデックスがWarmフェーズに入ると、ILMはインデックスを1つのシャードに圧縮し、1つのセグメントに強制マージし、Hot未満の値（かつColdよりも高い値）にインデックス優先度を設定して、割り当てアクションによってインデックスをWarmノードに移動させます。これが完了すると、ロールオーバーされてから30日後にColdフェーズに入ることになります。

Cold

インデックスがColdフェーズに入ると、ILMは再びインデックス優先度を下げて、HotおよびWarmインデックスが最初に復元されるようにします。そして、インデックスをフリーズし、Coldノードに移動させます。これが完了すると、ロールオーバーされてから60日後にDeleteフェーズに入ることになります。

Delete

Deleteフェーズに関してはまだ説明していませんでした。簡単に言うと、Deleteフェーズにはインデックスを削除するDeleteアクションがあります。インデックスが特定の期間、Hot、Warm、またはColdフェーズに留まることができるように、Deleteフェーズには常にmin_ageが必要です。

Kibana内からILMポリシーを作成

膨大な量のJSONを書くのは好きではありませんか？ （私も好きではありません）。 Kibana UIを使用してポリシーを検査または作成しましょう。

そのほうが楽です。

そして、この新しいhot-warm-cold-delete-60daysポリシーをBeatsおよびLogstashのインデックスと関連付ける必要があり、それらがHot データノードに書き込まれるようにします。BeatsとLogstashは両方とも（デフォルトで）独自のテンプレートを管理しているため、複数テンプレートのマッチングを使用して、ILMポリシーに適用するインデックスパターンのポリシーおよび割り当てルールを追加します。このテンプレートはBeatsおよびLogstashのインデックスパターンにマッチするため、マッチさせたいインデックスパターンがどれかを知っておく必要があります。ここではlogstash-、metricbeat-、およびfilebeat-*を使用していますが、いくつでも追加できます（BeatsおよびLogstashの構成でILMのサポートが有効化されている場合）。ここで、ILMをサポートしていないデータ生産元にインデックスパターンを追加する場合は、このポリシーのロールオーバーに関する要件を手動で満たす必要があります。

PUT _template/hot-warm-cold-delete-60days-template
{
  "order":10,
  "index_patterns": ["logstash-*", "metricbeat-*", "filebeat-*"],
  "settings": {
    "index.routing.allocation.require.data": "hot",
    "index.lifecycle.name": "hot-warm-cold-delete-60days"
  }
}

Beatsおよび/またはLogstashでILMを有効化

最後に、BeatsおよびLogstashでILMを有効化しましょう。

6.7のBeats：

output.elasticsearch:
  ilm.enabled: true

6.7のLogstash：

output {
  elasticsearch {  
    ilm_enabled => true
  }
}

BeatsおよびLogstashでの有効化の方法については、それぞれのバージョンのドキュメントをご覧ください。新しいバージョンでは変更されている可能性があります。

これで、インデックスパターンにマッチするすべての新しいインデックスにより、Hotノードに新しいインデックスが作成され、ILMはhot-warm-cold-delete-60daysポリシーを適用します。

ILMポリシーの更新

ILMポリシーはいつでも更新できます。**ただし、ポリシーへの変更はフェーズが変わったときにのみ適用されます。**たとえば、インデックスが現在Hotフェーズ（次はWarmフェーズ）の場合、Hotフェーズに追加した変更はいずれもそのインデックスで有効になることはなく、Warmフェーズに追加した変更はそのインデックスがWarmフェーズに入ると適用されます。これにより、特定のフェーズでアクションが繰り返されることが回避されます。インデックスに関するILMの状態については、Explain APIを使用して確認できます。

ILMの提供前におけるHot-Warmアーキテクチャーの実装方法に関する以前の情報のほとんどは、基盤のメカニズムが同じため、現在も引き続きあてはまります。ただし、ILMを使用することで、このパターンの実現にCuratorを使う必要はありません。

今後の展望

バージョン7.0以降、BeatsとLogstashは、ライフサイクル管理をサポートするクラスターに接続すると、デフォルトでインデックスライフサイクル管理を使用します。またBeatsでは、ほとんどのILM設定がoutput.elasticsearch.ilm名前空間からsetup.ilm名前空間に移動されています。その例については、7.0 Filebeatのドキュメントをご覧ください。さらに、7.0以降では、.watcher-history-*などのシステムインデックスをILMで管理することも可能です。

ILMにより、時系列インデックスに関してHot-Warm-Coldのような省コストのアーキテクチャーを簡単に実装できるようになりました。今すぐお試しいただき、ご感想をディスカッションフォーラムにお寄せください。ぜひご活用ください。