こんにちは。インフラ・開発部のtorigakiです。
早いもので2回目の投稿となります。
弊社はアクセスログの収集・解析にElasticsearchを使用しているのですが、今回はこのElasticsearchの運用環境について書きたいと思います。
システム構成
Elasticsearch環境は以下となります。
- GCPの仮想インスタンスで構築
- Elasticsearchサーバー3台(1クラスタ)+運用管理サーバー1台
- Elasticsearchサーバー情報(3台)
- Elasticsearchのバージョンは2.4.6。
OS | CPUコア数 | メモリ | HDD |
---|---|---|---|
Ubuntu 16.04.4 | 8コア | 8GB | 200GB |
- 運用管理用サーバーはCPU:1コア、メモリ:2GB。
- NginxのアクセスログをFluentd経由でElasticsearchに送信。
- ElasticsearchはKibanaの他にJavaのアプリからも使用しています。
- Elasticsearchの運用スクリプト(バックアップ等)は運用管理サーバーから実行しています。
運用管理サーバーの役割
Nginxでバランシング
Nginxで以下アクセスをバランシングしています。
- kibanaへのアクセス
- Elasticsearchの運用スクリプト(過去データ削除、バックアップ、インデックス作成)
※3台のうちどのノードが落ちたときでもスクリプトを実行できるようにするため、Elasticsearchへのアクセスはバランサーを通すようにしています。
Elasticsearch運用
以下を実行するスクリプトを用意して、cronで定期実行するようしています。
index(alias)作成
- 月末に来月分のindex(alias)を作成します。(例:logstash-2018.XX)
過去データ削除
- Curatorを使って定期的に削除しています。
Curatorの設定は以下ようにしています。
actions: 1: action: delete_indices description: "Delete logstash indices" options: ignore_empty_list: True continue_if_exception: False disable_action: False filters: - filtertype: pattern kind: prefix value: logstash- exclude: - filtertype: age source: name direction: older timestring: '%Y.%m' unit: days unit_count: XXX exclude:
「unit_count」に保持日数を設定します。
上記のymlファイルを以下のコマンドでcronで定期実行するように設定します。
/usr/local/bin/curator delete_indices.yml
- バックアップ
- elasticsearch-dumpを使ってJSONファイルとして保存し、GCSにアップロードしています。
elasticsearch-dumpを実行するスクリプトは以下のようにして、analyzer、mapping、dataをJSONファイルとして個別に保存し、gzipで圧縮するようにしてあります。
/usr/local/bin/elasticdump \ --input=http://localhost:9200/${index} \ --output=$ \ --type=analyzer \ | gzip > ${BACKUP_DIR}/$1/analyzer.json.gz /usr/local/bin/elasticdump \ --input=http://localhost:9200/${index} \ --output=$ \ --type=mapping \ | gzip > ${BACKUP_DIR}/$1/mapping.json.gz /usr/local/bin/elasticdump \ --input=http://localhost:9200/${index} \ --output=$ \ --type=data \ | gzip > ${BACKUP_DIR}/$1/data.json.gz
環境の移設
このアクセスログ収集用Elasticsearchは他環境から移設してきたのですが、移設時の切り替えで行った作業内容について簡単に書きたいと思います。
事前準備
- 旧環境と同一のテンプレートを新環境のElasticsearchにインポートしておきます。
- 新環境のElasticsearchに過去データをコピーしておきます。
- データコピーにはelasticsearch-dump使用してクラスタ間でダイレクトコピーしました。
- コピーしたデータがKinbanaで問題なく表示できることを確認しておきます。
- 新・旧両方のElasticsearchに同一データを送信するためのFluentdのコンフィグファイルを準備しておきます。
作業手順
- Fluentdを停止します。
- 新環境のElasticsearchに、最新データをコピーします。
- Fluentdのコンフィグファイルを新・旧同時送信用のコンフィグに差し替えます。
- Fluentdを起動します。
- 新・旧のElasticsearchに新規の同一データが送信されていることを確認します。
作業後
- 1ヶ月は新・旧並行運用して様子を見ます。
- Javaアプリの接続先を新環境に切り替えます。
まとめ
今回はElasticsearchの運用で工夫した点について紹介させていただきました。
少しでもElasticsearchの運用されている方のお役に立てれば幸いです。
弊社では引き続きエンジニア・デザイナーを募集中ですので、ご興味のある方は下からご応募いただければと思います。