Snapshot Lifecycle Managementを使ってみた!#Elastic #Elasticsearch #GCP

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
皆さん、Elasticsearchのインデックスバックアップには何を使っていますか?
バージョン7.5以降は、以下の3つの手法が用意されています。

バージョン7.5で新たに提示されたSnapshot Lifecylce Management(以下、SLM)について、本投稿でご紹介します!
【参考】
・SLM: Manage the snapshot lifecycle
・Curator Reference
必要なサブスクリプション
- SLMは無償(ベーシック)で利用可能です。

利用環境
- GCS repository pluginを使い、SLMの設定手順をご紹介します。
- 現時点における最新のElasticバージョンでGCP上に環境構築しています。
| 項目 | パラーメータ |
|---|---|
| Elasticsearch ver | 7.10.2 |
| Kibana ver | 7.10.2 |
| OS (GCE VM) | CentOS 7 (centos-7-v20201112) |
| Region | us-central1 (アイオワ) |
【構成図】
- VMには、Elasticsearch/Kibanaを同居させています。
- GCPのVPCネットワークは、defaultネットワークを利用しています。

【補足】
・本投稿では、VMの作成およびElasticプロダクトのインストール手順は省略しています。
【参考】
・Elasticsearchのインストール方法
・Kibanaのインストール方法
実施概要
- SLMを利用するにはリポジトリが必要になります。
- GCPのVMでリポジトリ登録する場合、Google Cloud Storage(以下、GCS)が推奨になります。
- GCSをリポジトリ登録するために必要な権限はサービスアカウントで付与します。
- サービスアカウントキーは、Elasticsearchキーストアに格納して利用する必要があります。
実施手順
- 以下の手順で設定を実施しました。
- GCS repository pluginのインストール
- GCSのバケット作成
- サービスアカウントの作成
- クライアントの設定
- リポジトリの登録
- スナップショットポリシーの設定
1. GCS repository pluginのインストール
- まず、GCSのバケットをスナップショット用のリポジトリにするためのプラグインをインストールします。
- 実行するコマンドは以下の通りになります。(数分で終わります)
$ sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install repository-gcs
- プラグインを認識させるため、Elasticsearchのプロセスを再起動します。
$ sudo systemctl restart elasticsearch
【参考】
・Google Cloud Storage Repository Plugin
2. GCSのバケット作成
- ここからはあえてCLIで設定を作っていきます。
-
GCPコンソールにログインし、Cloud Shellを起動します。

-
以下のコマンドを実行して、GCSのバケットを作成します。
$ gsutil mb -p unique-voyage-xxxxxx -c nearline -l us-central1 -b on gs://es_repo
- 設定値は以下の通りです。GCPコンソールからGUIで設定してもOKです。
| 項目 | パラメータ |
|---|---|
| バケット名 | es_repo |
| ロケーションタイプ | Region |
| ロケーション | us-central1 (アイオワ) |
| ストレージクラス | Nearline |
| アクセス制御 | 均一 |
| 暗号化 (オプション) | Googleが管理する鍵 (デフォルト) |
| 保持ポリシー (オプション) | 未設定 (デフォルト) |
| ラベル (オプション) | 未設定 (デフォルト) |
【補足】
・ 「unique-voyage-xxxxxx」は、GCPプロジェクト名になります。
・ Elasticsearchインデックスのスナップショット用途なので、Nearlineとしています。
・ VMと同じリージョンで作成しています。
【参考】
・ストレージバケットの作成
3. サービスアカウントの作成
- Cloud Shellで以下のコマンドを実行して、サービスアカウントを作成します。
$ gcloud iam service-accounts create es-repo \
--description="for_repository-gcs" \
--display-name="es-repo"
- 上記で作成したサービスアカウントに対して、ストレージ管理者権限を付与します。
$ gcloud projects add-iam-policy-binding unique-voyage-xxxxxx \
--member="serviceAccount:es-repo@unique-voyage-xxxxxx.iam.gserviceaccount.com" \
--role="roles/storage.objectAdmin"
- 設定値は以下の通りです。GCPコンソールからGUIで設定してもOKです。
| 項目 | パラメータ |
|---|---|
| サービスアカウント名 | es-repo |
| 説明 | for_repository-gcs |
| 表示名 | es-repo |
| ロール名 | Storage オブジェクト管理者 |
【補足】
・ 「オブジェクト作成者」では権限が不足していたため、「オブジェクト管理者」としています。
-
作成したサービスアカウントのキーを発行します。

-
JSON形式で「作成」します。

-
キーファイル(.json)がローカルPCにダウンロードされます。あとでElasticsearchのキーストアに格納します。

【補足】
・キーファイルの中身は以下のようになっています。
{
"type": "service_account",
"project_id": "unique-voyage-xxxxxx",
"private_key_id": "xxxx61dfxxxx3a21xxxx8a8bxxxxfb70xxxx9b49",
"private_key": "-----BEGIN PRIVATE KEY-----\n\n-----END PRIVATE KEY-----\n",
"client_email": "es-repo@unique-voyage-xxxxxx.iam.gserviceaccount.com",
"client_id": "xxxxxxxxxxxxxxxxxxxxx",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/es-repo%40unique-voyage-xxxxxx.iam.gserviceaccount.com"
}
【参考】
・サービスアカウントの作成と管理
・サービスアカウントキーの作成と管理
4. クライアントの設定
- GCPコンソールからVMにブラウザウィンドウで接続します。
-
前の手順でダウンロードしたキーファイルをアップロードします。

-
ユーザのホームディレクトリにアップロードされます。
$ ll total 4 -rw-rw-r--. 1 hisas11 hisas11 2329 Jan 23 12:07 unique-voyage-xxxxxx-d095b0237324.json
- Elasticsearchキーストアにサービスアカウントキーを格納する必要があります。
- (Elasticsearchキーストアは、Elasticsearchをインストールすると自動的に生成されます)
- (Elasticsearchの認証機能で利用するビルドインユーザの情報が格納されています)
- まずは、以下のlistコマンドでキーファイルを格納する前の状態を確認します。
$ sudo /usr/share/elasticsearch/bin/elasticsearch-keystore list keystore.seed
- add-fileコマンドでホームディレクトリ上のキーファイルをElasticsearchキーストアに格納します。
- 「gcs.client.クライアント設定名.credentials_file」の「es_repo_client」はリポジトリ登録時に利用します。
$ sudo /usr/share/elasticsearch/bin/elasticsearch-keystore add-file \
gcs.client.es_repo_client.credentials_file /home/hisas11/unique-voyage-xxxxxx-d095b0237324.json
- 改めてlistコマンドを実施すると格納されていることが確認できます。
$ sudo /usr/share/elasticsearch/bin/elasticsearch-keystore list gcs.client.es_repo_client.credentials_file keystore.seed
- 正常にキーファイルが格納されているか確認するため、Elasticsearchのプロセスを再起動します。
$ sudo systemctl restart elasticsearch
- 正常にプロセス起動したら、アップロードした元のキーファイルは削除します。
$ pwd /home/hisas11 $ rm unique-voyage-xxxxxx-d095b0237324.json
【補足】
・ キーファイルの内容に不備があった場合は、プロセス起動に失敗します。
・ その場合は、Elasticsearchキーストアからキーファイルを削除します。
$ sudo /usr/share/elasticsearch/bin/elasticsearch-keystore remove \
gcs.client.es_repo_client.credentials_file
【参考】
・Client Settings
・elasticsearch-keystore
5. リポジトリの登録
-
Kibanaにログインし、[Home] > [Back up and restore]をクリックします。

-
Register a repositoryをクリックします。

-
リポジトリ名(好きな名前でOK)とレポジトリタイプ(GCS)を指定します。

-
クライアント設定名(es_repo_client)とGCSバケット名(es_repo)を指定します。

-
Registerをクリックし、リポジトリ登録を完了します。

-
以下、作成完了後の画面になります。

-
これまで同様に[Dev Tools]からAPIでリポジトリ登録することも可能です。

PUT _snapshot/my_gcs_repository
{
"type": "gcs",
"settings": {
"bucket": "es_repo",
"client": "es_repo_client",
"compress": true
}
}
【参考】
・Snapshot and Restore
・Repository Settings
6. スナップショットポリシーの設定
-
最後は、スナップショットポリシーを設定し、定期スケジュールでスナップショットを取得します。

-
今回は、テスト的に毎分スナップショットを取得する設定とします。
-
ポリシー名(好きな名前でOK)、スナップショット名(好きな名前でOK)、スケジュール(minute)を指定します。

-
Data streams and indeicesで取得したデータストリームやインデックスを選択できます。

-
今回は、全てのデータストリームやインデックスを取得するので、[Next]をクリックします。

-
オプション設定はそのままで[Next]をクリックします。

-
内容OKであれば、[Create policy]をクリックし、ポリシーを設定します。

-
以下、作成完了後の画面になります。

-
Snapshotsタブに取得されたスナップショットが表示されれば、完了です。

※ SLMはスケジュール実行のみ可能でワンショット実行はできませんでした。
【参考】
・Create a snapshot lifecycle policy
・Date math support in index names
まとめ
さて、いかがでしたでしょうか?
正直なところ、意外とセットアップに手間がかかってしまいました。
理解できてしまえばなんてことありませんでしたが
Elasticsearchキーストアを利用することも初めてで仕組みを理解するのにも時間を要してしまいました。
一度セットアップできてしまうと非常に便利な運用ツールとなります。
無償のベーシックで利用することができますので、ぜひ試してみてください!!
