三歩あるけば物も忘れる

ElasticSearchのサイジングについて記載します。
理解した・・・と思って書いてみた、あってる？

ストレージサイズは、ソースサイズから求められる。
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/sizing-domains.html#aes-bp-storage

最小ストレージ要件 = ソースデータ x (1 + レプリカの数) x (1 + インデックス作成オーバーヘッド) ÷ (1 - Linux 予約スペース) ÷ (1 - Amazon ES のオーバーヘッド)
→ソースデータ x (1 + レプリカの数) x (1 + 0.1) ÷ (1 - 0.05) ÷ (1 - 0.2)
→ソースデータ x (1+ レプリカの数) x 1.45

可用性要件で、いくつに分散して保持したいかで決める。
・レプリカ数をAZ数の倍数とした場合、均等に各AZに分散される。
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-managedomains-multiaz.html

ノード数＝インスタンス数
・ノード数はレプリカ数や総ストレージ容量によって変わる。
・インスタンス毎のストレージサイズは、インスタンスタイプ毎に異なるので、最低ノード数は以下の計算となる。
　最低ノード数 ＝ 総ストレージ容量 / インスタンス毎の最大ストレージサイズ
※インスタンスタイプは、ストレージ要件の容量 100 GiB ごとに vCPU x 2 コア、メモリ 8 GiB に近い構成になるようにします。
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

■インスタンスタイプのvCPUとメモリ表
https://aws.amazon.com/jp/elasticsearch-service/pricing/

https://aws.amazon.com/jp/blogs/news/get-started-with-amazon-elasticsearch-service-how-many-shards-do-i-need/
シャード数 = インデックスのサイズ / 30GB

以下の理由から、1シャードは30GB程度にすると良いらしい。
・シャードが大きいと、Elasticsearch の障害復旧が困難になる可能性があります。
・各シャードはある程度の CPU とメモリを使用するため、小規模なシャードが多数ある場合には、パフォーマンスの問題やメモリ不足のエラーが発生する可能性があります。
https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/sizing-domains.html#aes-bp-sharding