Amazon Web Services ブログ
Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) でのインデックスステート管理の自動化
本記事は Amazon Web Services, Big Data and Analytics Consultant である Gene Alpert、DevOps Consultantである Satya Vajrapu によって投稿されたものです。
時系列データでは、過去のデータより直近 (過去4時間〜1日) データへアクセスするのが一般的です。多くの場合、さまざまなデータワークロードをサポートするために、複数のインデックスを管理する必要があります。これにより、インデックスのライフサイクルを管理するためのカスタムソリューションが必要となります。インデックスが多くなるにつれて、ソリューションの管理が煩雑になり、管理業務によるオーバヘッドが生じます。
Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) を利用することで、定期的なインテックス管理作業を自動化することができます。これにより、インデックスのライフサイクル管理のために追加のツールを使わずにすみます。インデックスステート管理 (ISM) では、インデックスの保持期間やサイズなどの条件に応じて管理オペレーションを自動的に行うポリシーを Amazon OpenSearch Service ドメイン内に作成することができます。本記事では、定期的なインデックス管理作業を自動化するポリシーを実装する方法、およびインデックスやインデックスパターンへのポリシーの適用について説明します。
前提条件
はじめる前に、以下の前提条件が満たされていることを確認してください:
- OpenSearch または Elasticsearch 6.8 以降の既存クラスタを使用する (ISM および UltraWarm を有効化する必要があります)、もしくは UltraWarm を有効化した Amazon OpenSearch Service を新しく構築します。
- 手動スナップショットレポジトリを登録します。
- ユーザのユーザロールが Amazon OpenSearch Service ドメインの OpenSearch Dashboards コンソールへのアクセスのための十分な権限があること確認します。必要に応じて、ドメインへのアクセスを設定し、確認します。
ユースケース
Amazon OpenSearch Service では、アクティブな書き込みと低遅延の分析のためのデフォルトのホットストレージ、3 PB までの読み取り専用データをホットストレージの 1/10 のコストで使用可能な UltraWarm、長期的なアーカイブのためのコールドストレージという 3 つのストレージ階層がサポートされています。ホットストレージはデータのインデックス作成や高速アクセスのために使用されます。UltraWarm はより低頻度にアクセスされるデータのためにより安価なストレージを用いることでホットストレージを補完します。インタラクティブな分析体験は維持されます。UltraWarm ノードは、接続されたストレージではなく、Amazon Simple Storage Service (Amazon S3) と高度なキャッシュソリューションを用いてパフォーマンスを向上させます。
機能のデモとして、日次でインデックスが作られる時系列データのサンプルユースケースを紹介します。このユースケースでは、作成から 24 時間後にインデックスを自動的にスナップショットし、2 日後にUltraWarmストレージに移行し、30 日後にコールドストレージに移行します。作成後 60 日後にインデックスを削除します。
Amazon OpenSearch Service ドメインを作成しスナップショットレポジトリの登録があれば、以下の手順を実行します:
- ドメインのステータスが「アクティブ」になれば、OpenSearch Dashboards の URL を選択します。
- OpenSearch Dashboards にログインします。テナント選択画面が表示された場合、任意のテナントを選択します。
- 新規のドメインを使う場合、OpenSearch Dashboards の最初に表示される画面で Add data を選択し、表示される全てのサンプルデータの Add data を選択します。既存のドメインを使う場合、左上のハンバーガーアイコンを選択し、Home 画面を選択、Ingest your data セクションにある Add sample data をクリックし、表示される全てのサンプルデータの Add data を選択します。
- 左上のハンバーガーアイコンを選択し、左側のメニューで Index Management を選択します。State management policies ページのポリシーの一覧が表示されます。
- Create policy を選択します。
- JSON Editor を選択し、Continue を選択します。
- Policy ID に
ism-policy-exampleを入力します。 - Define Policy の下のテキストボックスの中身を次のポリシーで置き換えます:
{
"policy": {
"description": "Demonstrate a hot-snapshot-warm-cold-delete workflow.",
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [],
"transitions": [
{
"state_name": "snapshot",
"conditions": {
"min_index_age": "24h"
}
}
]
},
{
"name": "snapshot",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "30m"
},
"snapshot": {
"repository": "snapshot-repo",
"snapshot": "ism-snapshot"
}
}
],
"transitions": [
{
"state_name": "warm",
"conditions": {
"min_index_age": "2d"
}
}
]
},
{
"name": "warm",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"warm_migration": {}
}
],
"transitions": [
{
"state_name": "cold",
"conditions": {
"min_index_age": "30d"
}
}
]
},
{
"name": "cold",
"actions": [
{
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"cold_migration": {
"start_time": null,
"end_time": null,
"timestamp_field": "@timestamp",
"ignore": "none"
}
}
],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "60d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"cold_delete": {}
}
],
"transitions": []
}
],
"ism_template": [
{
"index_patterns": [
"index-*"
],
"priority": 100
}
]
}
}ポリシーの最後のセクション (ism_template) では、このポリシーを自動的に新規インデックスにアタッチするためのパターン (index_patterns) が定義されています。複数のパターンの定義も可能です。
また、ISM API を使うことでプログラムによるポリシーやマネージドインデックスを管理することができます。
- Create を選択します。ポリシーの一覧に作成したポリシーが表示されます。
- 左側のメニューから Indices を選択し、検索ボックスに
opensearch_dashboards_sample入力します。追加されたサンプルデータが表示されます。 - 全てのインデックスを選び、Apply policy を選択します。
- Policy ID の下の Search policies ボックスを選択し、表示されたドロップダウンメニューから上で作成したポリシーを選択します。
- Apply を選択します。
上記の手順により、ポリシーがインデックスにアサインされ、これでポリシーが選択されたインデックスを管理します。
Policy managed indices ページで Job status が Initializing になっていることが確認できます。
初期化が完了すれば、Job statusが Running に変更されます。
ポリシーの解説
この章では、ISM ポリシーの構成と内容について解説します。
ポリシーは、以下を定義する JSON ドキュメントです:
- インデックスが遷移しうるステート
- インデックスがステートに遷移した際に、プラグインに実行してほしいアクション
- インデックスが新しいステートに遷移するための条件
ポリシードキュメントは description、インデックスがデフォルトで持つステートを示す default_state、そしてステート定義のリストから始まります。
ステートはマネージドインデックスの現在の状態です。マネージドインデックスは同時に一つのステートにのみ存在します。ステートには、インデックスがそのステートに入る際に実行される連続的なアクション (action) と、それらのアクションが実行終了した際に評価される遷移 (transitions) が関連づけられています。
最初のステートは hot です。このユースケースでは、hot ステートに対してアクションが定義されていません。マネージドインデックスは最初に hot ステートに入り、snapshot、warm、cold、そして最終的に delete に遷移していきます。遷移では、ステートの変更が実行されるための条件が定義されています。この場合、インデックスが作成されてから 24 時間経過すれば、ステートが snapshot に変わります。
OpenSearch Dashboards の Index Management 画面でインデックスの状態を素早く確認することができます。Policy managed indices ページでそれぞれのマネージドインデックスのステートが表示されます。
ポリシードキュメントの最後のステートではインデックスが削除されます。このポリシーは、インデックスがクリティカルでないかつ書き込みが行われないことを想定しています。レプリカ数を0であることがデータ損失のリスクを伴います。
アクションを使って Amazon Simple Notification Service (Amazon SNS)、Amazon Chime、Slack または Webhook URL にポリシーアクションに関する情報を通知こともできます。詳細についてはこちらを参照してください。
以下のスクリーンショットはコンソールでのインデックス状態を示しています。
ISM ポリシーに関する追加情報
UltraWarm をサポートしない Amazon OpenSearch Service の既存のドメイン (前提条件を満たさない) を使う場合、warm および cold ステートの代わりに read_only および reduce_replicas ステートを使用することができます。
次のコードは、これら2つのステートを定義するポリシーテンプレートです:
{
"name": "reduce_replicas",
"actions": [
{
"replica_count": {
"number_of_replicas": 0
}
}
],
"transitions": [
{
"state_name": "read_only",
"conditions": {
"min_index_age": "2d"
}
}
]
},まとめ
この記事では、ISM を UltraWarm とコールドストレージとともに使う方法について説明しました。このプラグインでのサンプルポリシーを使ったインデックスの管理方法を手順で示しました。
ISMプラグインに関する詳細について、Index Store Management のドキュメンテーションを参照してください。改善や機能要望がありましたら、Issue を作成してください。
プロジェクトにコントリビューションするには、Contributing Guidelines を参照してください。ISM プラグインはオープンソース OpenSearch のどのようなデプロイメントでも利用できます。また、更に詳細情報については、OpenSearch ドキュメンテーションの Index State Management を参照してください。
原文はこちらです。
本ブログは Startup Solutions Architect の Torgayev Tamirlan が翻訳しました。