1
results
for Qiita
-
本投稿はLancers(ランサーズ) Advent Calendar 2018の4日目の記事です。 昨日は、Slack の簡易エンドポイントを Amazon API Gateway で作った話についての記事でした。 本日は、ElasticCloudからAmazon Elasticsearch Serviceへの移行して良かったこと大変だったことについて話します。 概要 会社でとあるサービスのバックエンドにElasticsearchのマネージドサービスであるElasticCloudを使用していた。 ElasticCloudはElasticsearchの開発元であるElastic社が提供しているサービスで、Elasticsearchを容易に管理できる。 しかしながら、AWSでもElasticsearchをマネージドサービスで提供しており、VPCで管理できるようになった今、普段利用しているAWSに統合できた方が総合的に管理しやすくコスト管理しやすいだろうとなり、移行することとなった。 ※追記あり 本ブログではどのように移行を行っていったかをまとめていく。 ここではあくまでも移行の手順のみになりElasticsearchに関するチューニング等は一切記載していない。 なお、ElasticCloudからの移行手順と記載したが、AWSの異なるAWSアカウントIDや異なるリージョン間での移行でも参考になるかもしれない。 正直かなり色々なステップがあり、長い記事になってしまったので、最初に要約を書いておく。 要約 ElasticCloudからAmazon Elasticsearch Serviceへは移行できる。 移行する際は同じリージョンのS3を作って、そこにスナップショットを取得して、S3のクロスリージョンコピーを利用すれば別リージョンでもデータをコピーできる。 stream2es(Elastic社が開発)とScrollAPIを使えば、比較的簡単に大量データをindex単位でリストアできる。 VPC(Proxy)配下にElasticsearchを設置した場合にtd-agentがElasticsearchにつなげなくなることがあるのでマジ注意!(reload_connections falseに設定する) 構成 構成は比較的シンプルで、サイトへのアクセスがあったらnginxのログをtailしているFluentdがElasticsearchへ必要なログを保存する。 それをRailsでできたアプリケーションサーバーから管理、閲覧できるようになっている。 最初に チームで移行しようと決まった時点で、どのような移行手順になるのか、そもそもどうやって移行するのかがわからず、まずは移行が行えるかどうかというところからのスタートだった。 ただ、調べてみるとそもそもElastic社が、自社のElasticCloudからの移行についてヘルプを記載してくれている。 Snapshot and Restore with Custom Repository Elastic社のElasticCloudもバックエンドはAWSを利用しており、S3にスナップショットを取得することができる。 同一リージョンであれば、スナップショットの取得先を別のAWSアカウント、つまり我々の環境にデータを保存することができる。 移行手順(前編) スナップショットのリストアまでの手順としては下記の通り。 ElasticCloudはap-norheast-1は未対応なので、最初にElaticCloudのS3が設置されているリージョンと同じap-southeast-1に自分のAWSアカウントでS3バケットを作成する 上記バケットへのアクセス可能なユーザーを作成する 作成したアクセスキーでElasticCloudの本番へリポジトリを登録する リポジトリへスナップショットを取得する ap-northeast-1にバケットを作成する ap-northeast-1のバケットへのアクセス許可を最初に作成したユーザーへアタッチする S3のデータをap-northeast-1のS3バケットへクロスリージョンコピーする 実際の手順 スナップショットの保存先登録、保存、S3コピー S3バケットの作成とIAMユーザー作成は、通常の手順なので省略する。 XXXXX-proddataというバケットを作成したとする。 作成したS3バケット、およびアクセスキー、シークレットアクセキーをElasticCloud側へ登録する。 % curl -XPUT 'https://Elastic社のリポジトリ.