Amazon Elasticsearch Service の Blue/Green デプロイについて調べてみた

Posted on

Amazon Elasticsearch Service (Amazon ES) では、クラスタを変更したときに Blue/Green デプロイが行われます（Amazon ES ではクラスタのことをドメインと呼びます）。

公式ドキュメントでは次のように説明されています。

Amazon ES では、ドメインの更新時に Blue/Green デプロイプロセスが使用されます。 Blue/Green は通常、2 つの本稼働環境（ライブとアイドル）に使用して、ソフトウェアの変更時に両者間で切り替える方法を指します。

Amazon ES の場合は、ドメインの更新用に新しい環境を作成し、これらの更新の完了後に新しい環境にユーザーをルーティングする方法を指します。この方法では、新しい環境へのデプロイに失敗しても、ダウンタイムを最小限に抑えることができ、元の環境を維持することができます。

本番環境で採用するにあたって、もう少し詳しく知っておきたかったので実際に検証してみました。なお、検証した Elasticsearch のバージョンは 6.2.2 です。

事前準備

t2.medium の 1 ノードのドメインを起動します。今回は検証なので専用マスターノードは有効にしていません。

ドメインの更新中も問題なくレスポンスを返すか確認するためにサンプルデータを入れておきます。

サンプルデータを入れた直後のドメインの状態です。この状態でドメインを変更します。

GET _cluster/health
{
  "cluster_name": "xxxxxxxxxxxx:manabusakai",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 5,
  "active_shards": 5,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 5,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 50
}

GET _cat/indices?v
health status index uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   bank  -Q351H8UR3y01vx-BV1nLg   5   1       1000            0    475.2kb        475.2kb

スケールアップとスケールアウトしたときの挙動

普段の運用でよく行うであろうスケールアップとスケールアウトを試してみます。

下のグラフはインスタンスタイプを t2.medium から m4.large に変更したときと、そのあとインスタンス数を 1 から 2 に増やしたときのノード数の変化です。

インスタンスタイプとインスタンス数を変更したときのノード数の変化

Blue/Green デプロイが行われているので、インスタンスタイプの変更では 1 → 2 → 1、インスタンス数の変更では 1 → 3 → 2 と変化していることがわかります（一時的に変更前のノード数 + 変更後のノード数になる）。ノードを追加したときも既存のノードは再利用されずに、All at once 方式で新旧のノードをすべて入れ替えているようです。

次にストレージサイズを 10 GB から 15 GB に増やしたときのノード数の変化です。

ストレージサイズを変更したときのノード数の変化

先ほどと同じように一時的にノード数が倍になって、元に戻っていることがわかります。

変更中に _cluster/health を叩くと number_of_nodes が増えていることが確認できます。もちろん、変更中も問題なくレスポンスを返します。

GET _cluster/health
{
  "cluster_name": "xxxxxxxxxxxx:manabusakai",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 5,
  "active_shards": 10,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 100
}

AWS re:Invent のこちらのスライドを見ると、Elasticsearch のノードの前には ELB が配置されているようなので、ノードは Auto Scaling で管理されていると推測できます。

アクセスポリシーの変更

Amazon ES は IAM と統合されており、アクセス制御を IAM で行うことができます。それを設定するのがアクセスポリシーです。

以前はアクセスポリシーを変更するだけでも Blue/Green デプロイが行われていましたが、今年 3 月のアップデートで即時に反映されるようになりました。

実際に試してみると数秒で反映され、ノード数に変化はありませんでした。これはとても良いアップデートですね！

ちなみに、VPC を選んだ場合はドメインに対して Security Group が設定できますが、Security Group の変更は Blue/Green デプロイが行われます。こちらも即時反映されるように改善してほしいですね。

その他の注意点

ドメインを変更すると一時的にノード数が倍になるので Elasticsearch の負荷が高まります。ドメインの安定性を高めるためにも本番環境では専用マスターノードを有効にすることが勧められています。すでに有効にしているドメインでも、専用マスターノードの負荷が高い場合は先にスケールアップさせておくといいでしょう。

また Elasticsearch のデータ量や負荷状況によっては Blue/Green デプロイが完了するまでにかなりの時間がかかります。変更するときは負荷が落ち着いている時間帯を狙ってやると良さそうです。

まとめ

Amazon ES ドメインでどういうときに Blue/Green デプロイが行われるかしっかり把握できました。またオンラインで変更できる理由も理解できました。これで安心して運用できそうです。

Popular Entries

Recent Entries