20200414 Amazon Elasticsearch Service Best Practice

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark
Amazon Web Services Japan, K. K.
Analytics Solutions Architect, Makoto Shimura
[これから始める Amazon Elastic Search Service セミナー]
Amazon Elasticsearch Service
Best Practice

⾃⼰紹介
志村誠
ソリューションアーキテクト
• データ分析・機械学習系サービスを担当
• 好きなサービス
• Amazon Athena
• AWS Glue
• Amazon SageMaker
• and Amazon Elasticsearch Service!!

Agenda
• Amazon ES のアーキテクチャ
• Amazon ES のサイジング
• ストレージ要件の計算
• シャード数の選択
• インスタンスタイプの選択
• Amazon ES の運⽤監視
• まとめ

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark
Amazon ES のアーキテクチャ

Amazon ES アーキテクチャのベストプラクティス
マスター
マスター
候補
マスター
候補
データノード
専用マスター
(候補) ノード
Amazon ES ドメイン
シャード 1: プライマリ
シャード 2: レプリカ
Availability Zone A Availability Zone B Availability Zone C

マスター
マスター
候補
マスター
候補
データノード
Amazon ES では，Elasticsearch クラスタのことを
「ドメイン」と呼ぶ．ノードの追加や
インスタンスタイプの変更，ストレージの追加等は
後から実施可能
専用マスター
ノード

マスター
マスター
候補
マスター
候補
データノード
マスターノード
• マスター候補ノードから選出される
• 1 つのクラスタに 1 ノードだけ存在
• クラスタの状態管理を⾏う
マスター候補ノード
• マスターノードの障害時にマスターに昇格
• マスターノードと合わせて 3 台以上必要
• 2 台の場合，マスターノード障害時に，候補
ノードがマスターに昇格はできない
専用マスター
ノード

マスター
マスター
候補
マスター
候補
データノード
マスターノードが選出できなくなると，クラスタが成⽴しなくなる
AZ レベルの障害に備えるため，3 つのマスター (候補)ノードを 3AZ に分散して
配置するのがベストプラクティス
新しいマスターノード選出のためには，マスター (候補) ノードの数/2 + 1 (切捨) 台の
ノードが必要
• 3 台の場合，3/2 + 1 = 2.5 → 2 台なので，1 台の故障を許容
• 2 台の場合，2/2 + 1 = 2 台なので，1 台が故障したらクラスタが停⽌
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains-dedicatedmasternodes.html
専用マスター
ノード

専用マスター
ノード
マスター
マスター
候補
マスター
候補
データノード
データノード
• インデックスデータを保持
• データの追加や削除，検索の際にアクセスされる
• Amazon ES では最⼤ノード数 200 までをサポート
• 本番環境では，可⽤性向上のため 3AZ に分散して配置するのを推奨
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/aes-bp.html

専用マスター
ノード
マスター
マスター
候補
マスター
候補
データノード
シャード
• インデックスのデータを分割したユニット
• 各シャードは，複数のレプリカを持つことが可能
• レプリカ数 0 は，1 データノード障害でデータ⽋損が発⽣するため⾮推奨
• マルチ AZ 構成のドメインにしておくと，レプリカは⾃動的に別の AZ の
• ノードに分散して配置される

マスター
マスター
候補
マスター
候補
データノード
マスターノードとデータノードは同居可能だが，
頻繁なデータ書き込みや検索によりデータノードの負荷が
⾼まると，マスターノードの動作が不安定になりうる
そのためマスターノードは，データノードと別で
⽤意するのがベストプラクティス
専用マスター
ノード

VPC から Amazon ES にプライベート接続
• Amazon ES ドメインへのアクセスを，VPC からクローズドな形で実現可能
• 各サブネットには，AZ に割り当てられたデータノード数の 3 倍の IP アドレスが
必要（Blue/Green デプロイメントで利⽤するための予約）
• VPC 接続が必要かどうかは，ユースケースに応じて判断
マスタ
ノード
Your VPC
Amazon ES
マスタ
ノード
マスタ
ノード
データ
ノード
データ
ノード
データ
ノード
データ
ノード
データ
ノード
データ
ノード
Private subnet Private subnet Private subnet
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-vpc.html

Amazon ES のサイジング

ストレージ要件の計算

ストレージ要件の計算
Amazon ES のストレージ容量のサイジングは，以下の式で計算可能
最⼩ストレージ要件 =
ソースデータサイズ x
(1 + インデックス作成オーバーヘッド) x
(1 + レプリカの数) ÷
(1 - Linux 予約スペース) ÷
(1 - Amazon ES のオーバーヘッド)
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/sizing-domains.html

ソースデータのサイズ
• インデックス作成のやり⽅は，⼤きく 2 種類ある
• ⽤途に応じて適切なものを選択
• 将来的な拡張の余地まで考慮しておく⽅が良い
⻑期保存インデックス
• 通常の⽅式
• ソースデータをすべて同じインデッ
クスに格納
• 主に検索⽤途で⽤いられる
ローリングインデックス
• ⽇次，週次など⼀定間隔で新しいイ
ンデックスに切り替え
• 古いインデックスはレプリカ数を減
らしたり，削除したりする
• 主にログ分析⽤途で⽤いられる

インデックス作成のオーバーヘッド
• インデックスサイズは，データ特性にはよるものの，⼀般的に元のソース
データよりも 10% 程度⼤きくなる
• ソースデータが既にある場合は，実際に計測することが可能．_cat/indices
API で返ってくる，pri.store.size が，Amazon ES 上に実際に格納された，
インデックスの（プライマリシャードのみの）サイズとなる

シャードのレプリカ数
• レプリカ数が増えると，単純にプライマリシャードのデータをコピーしてそのぶんだけ持
つことになる
• データの可⽤性と耐久性を⾼め，特に読み込みヘビーなワークロードの場合，検索パ
フォーマンスの改善にもつながる
• 最適な数は実際に検証して決める必要があるが，データ⽋損を防ぐため，最低 1 つはレプ
リカを持つことを強く推奨

Linux 予約スペース & Amazon ES のオーバーヘッド
Linux 予約スペース
• ストレージ容量の 5% の領域を確保しておく必要がある
• root ユーザの重要プロセスやシステム復元等のための領域
Amazon ES のオーバーヘッド
• ノードごとにストレージ容量の 20%（最⼤ 20GB）の領域を確保する必要
• セグメントマージ，ログ，その他の内部オペレーションのための領域
• 500GB/ノード x 3 台の場合: MIN(20GB, 500GB x 0.2) x 3 = 60GB を確保
• 50GB/ノード x 30 台の場合: MIN(20GB, 50GB x 0.2) x 30 = 300GB を確保

ストレージ容量の計算例
1 ⽇に 30GB のログが追加され，2 週間保持する必要がある．データの可⽤性を
⾼めるためレプリカ数は 2 とする．ノード 1 台あたりのストレージサイズは
80GB とする
ソースデータサイズ x
(1 + インデックス作成オーバーヘッド) x
(1 + レプリカの数) ÷
(1 - Linux 予約スペース) ÷
(1 - Amazon ES のオーバーヘッド)

ストレージ容量の計算例
1 ⽇に 30GB のログが追加され，2 週間保持する必要がある．データの可⽤性を
⾼めるためレプリカ数は 2 とする．ノード 1 台あたりのストレージサイズは
80GB とする
(30 x 14) x
(1 + 0.1) x
(1 + 2) ÷
(1 – 0.05) ÷
(1 – 0.2)
= 1823.7GB

シャード数の基本的な考え⽅
• シャード数は，インデックス作成後に変更できないため，あらかじめ拡張余地を
考えて設定しておく必要がある
• 各シャードを管理するのにも⼀定の CPU とメモリを消費するため，拡張余地の
ために⼩さすぎるシャードを多数保持するのは推奨されない．その場合は，デー
タが増加した際にインデックスの再作成を⾏う⽅が良い
• ⼀般的にシャードあたりのサイズは 10-50GB 程度にするのがベスト
• シャード数は以下の計算式で表せる
プライマリシャードの数 =
(ソースデータ + 拡張の余地) x
(1 + インデックス作成オーバーヘッド) ÷
シャードあたりのサイズ
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/sizing-domains.html

シャード数の計算例
1 ⽇に 30GB のログが追加され，2 週間保持する必要がある．今後のシステム規模
の拡⼤と併せて，最⼤ 20% 程度ログの量が増加する可能性がある
(ソースデータ + 拡張の余地) x
(1 + インデックス作成オーバーヘッド) ÷
シャードあたりのサイズ

(30GB x 14⽇ + 30GB x 14 x 0.2) x
(1 + 0.1) ÷
30GB
= 18.48 → 19 シャード

(30GB x 14⽇ + 30GB x 14 x 0.2) x
(1 + 0.1) ÷
30GB
= 18.48 → 19 シャード
拡張する前の当初のシャード
サイズは，以下のように計算可能
プライマリシャードサイズ =
ソースデータ x
(1 + オーバーヘッド) ÷
シャード数

(30GB x 14⽇ + 30GB x 14 x 0.2) x
(1 + 0.1) ÷
30GB
= 18.48 → 19 シャード
拡張する前の当初のシャード
サイズは，以下のように計算可能
プライマリシャードサイズ =
(30GB x 14⽇) x
(1 + 0.1) ÷
19シャード
= 24.3GB

インスタンスタイプの選択

専⽤マスターノード
• 専⽤マスターノードは，クラスター管理にリソースを使う．そのためクラスター規模に併
せて，専⽤マスターノードも⼤きくする
• 後述する CloudWatch Metrics のメトリクスに応じて，⼤きなインスタンスタイプを検討
• ⼀般的な構成のクラスターにおける，ガイドは以下のようになる
• バースト可能な t2 系インスタンスは本番構成では⾮推奨
データノード数最⼤シャード数推奨インスタンスタイプ
1–10 2500 c5.large.elasticsearch
10–30 5000 c5.xlarge.elasticsearch
30–75 10000 c5.2xlarge.elasticsearch
75–200 30000 r5.4xlarge.elasticsearch
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains-dedicatedmasternodes.html
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/cloudwatch-alarms.html
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/aes-bp.html

データノード
• Amazon ES では，インスタンスタイプごとに最⼩ / 最⼤ EBS サイズが設定されている
が，これは⼀般的な⽤途で⽤いるときの想定
• 負荷が⾼いワークロードの場合には，以下の表に⽰すような初期プランでサイジング
を⾏なった上で，必ずパフォーマンステストを実施
• バースト可能な t2 系インスタンスは本番構成では⾮推奨
• データノードのヒープメモリ 1GB あたり 20 未満のシャード数にするのを推奨
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/sizing-domains.html#aes-bp-instances
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/aes-limits.html
https://www.elastic.co/jp/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
⼀般的なワークロード負荷の⾼いワークロード
ユースケース
• 取り込み速度が遅くてもよい
• 検索クエリの負荷が低い
• ドキュメントの頻繁な追加・更新
• ⼤量の検索クエリの発⾏
• 負荷の⾼い集計クエリの発⾏
クラスター構成
アクティブシャード * 1 つにつき
1vCPU コア
100GB ストレージにつき
2vCPU コア & 8GB メモリ
* アクティブシャード: 書き込みが発生する，または頻繁にクエリ対象となるシャード

Amazon ES のサイジング例
• Amazon ES ドメインの規模に応じた，ざっくりとしたインスタンス選定例
規模
データサイズ
（⽇）
必要ストレージ
（1週間保存）
アクティブシャード
（最⼤）
トータルシャード
（最⼤）
インスタンス構成例
XSmall 〜10 GB 177 GB 4 300
2x M4/R4.large data
3x m3.medium masters
Small 10〜100 GB 1.7 TB 8 600
4x M4/R4.xlarge data
3x m3.medium masters
Medium
100〜500
GB
8.5 TB 30 3000
6x I3.2xlarge data
3x C4.large masters
Large 0.5〜1 TB 17.7 TB 60 3000
6x I3.4xlarge data
3x C4.large masters
XLarge 1〜10 TB 177.1 TB 600 5000
30x I3.8xlarge data
3x C4.2xlarge masters
Huge 10〜80 TB 1.288 PB 3400 25000
85x I3.16xlarge data
3x C4.4xlarge masters
https://aws.amazon.com/jp/blogs/news/get-started-with-amazon-elasticsearch-service-t-shirt-size-your-domain/
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/petabyte-scale.html

Amazon ES の運⽤監視

Amazon ES の設定変更
• Amazon ES では，ドメインの更新時に Blue/Green デプロイプロセスが⾏われる．具体
的にはインスタンスタイプの変更，マルチ AZ の有効化/無効化，バージョンアップグ
レード等．アクセスポリシーの変更の場合は，通常 Blue/Green デプロイは発⽣しない
• Blue/Green デプロイ時には，⼀時的にクラスターに倍のノードが追加されるため，専⽤
マスターノードに⼤きな負荷がかかる
• そのため⼤きな設定変更は，負荷の低い深夜帯等に実施するのを推奨
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains.html#es-managedomains-multiaz
Blue/Green デプロイによる
⼀時的なノード数の増加

Amazon ES の監視項⽬
公式ドキュメントには，アラームを設定するべき CloudWatch メトリクスがまと
められている．代表的な項⽬は以下の通り
メトリクスとアラーム説明
CPUUtilization maximum is >= 80%
for 15 minutes, 3 consecutive times
データノードの CPU リソースが⾜りない恐れあり．インスタン
スのスケールアップ or スケールアウトを検討
JVMMemoryPressure maximum is >= 80%
データノードのメモリエラーの恐れあり．インスタンスのス
ケールアップ or スケールアウトを検討
ClusterStatus.yellow maximum is >= 1
for 1 minute, 1 consecutive time
1 つ以上のレプリカシャードがノードに割りあってられていな
い．クラスタ状態を確認
FreeStorageSpace minimum is <= XXX
for 1 minute, 1 consecutive time
ディスク容量不⾜の恐れあり．XXX には，各ノードのストレー
ジ容量の 25% の値を MB 単位で記⼊
MasterCPUUtilization maximum is >= 50%
専⽤マスターノードのリソースが⾜りない恐れあり．インスタ
ンスのスケールアップを検討
MasterJVMMemoryPressure maximum is >= 80%
for 15 minutes, 1 consecutive time
専⽤マスターノードのリソースが⾜りない恐れあり．インスタ
ンスのスケールアップを検討
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/cloudwatch-alarms.html

Amazon ES のスナップショット
• スナップショットは，クラスターのバックアップ
• Amazon ES には，以下の 2 種類のスナップショットが存在する
• 基本的には⾃動スナップショットで⾜りるが，異なる Amazon ES にデータ移
⾏したい場合は，⼿動での取得が必要
種類⽤途説明
⾃動スナップショット • バックアップ
• ES 5.3 以降の場合，1h ごとにスナップショットを
取得し，14 ⽇間保持（ES 5.1 以前は 1 ⽇ごと）
• 追加課⾦なし
⼿動スナップショット
• バックアップ
• データ移⾏
• Elasticsearch ⾃体の API を叩いて，⼿動で S3 に
対してスナップショットを作成
• S3 利⽤料⾦がかかる
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html

Elasticsearch on EC2 を Amazon ES に移⾏
1. Elasticsearch on EC2 で _snapshot/repos API を⽤いて，S3 にスナップ
ショットリポジトリを登録し，スナップショットを作成
2. Amazon ES ドメインを新しく作成し，同じ S3 バケットをスナップショット
リポジトリとして登録
3. Amazon ES ドメイン側から，_restore API を⽤いてスナップショットを復元
Elasticsearch
スナップショット作成リストア
S3EC2 Amazon ES
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html
https://aws.amazon.com/jp/premiumsupport/knowledge-center/migrate-amazon-es-domain/

まとめ

まとめ
• Amazon ES は 3 台以上の専⽤マスターノードを使⽤し，3AZ にわたってドメ
インを構築する．シャードのレプリカも必ず 1 つ以上を指定．これにより可
⽤性と耐久性を確保することが可能に
• ストレージ・シャード数・インスタンスタイプは，このセッションで紹介し
たガイドに従って選択．また構成を決める際に，必ずパフォーマンステスト
を実施する．本番環境では，t2 インスタンスは使⽤しない
• クラスターの状態や CPU，メモリなどのメトリクスを監視して，指定した閾
値を超えたらアラートをあげる

20200414 Amazon Elasticsearch Service Best Practice

20200414 Amazon Elasticsearch Service Best Practice

Recommended

Recommended

More Related Content

More from Amazon Web Services Japan

More from Amazon Web Services Japan (20)

Recently uploaded

Recently uploaded (20)

20200414 Amazon Elasticsearch Service Best Practice