前提
- ディスク容量とシャード数の設計について
- 性能面に問題がないかどうかは、実計測すること
- Elasticsearch 7.10
サマリー
- Elasticsearchはドキュメント更新時に一時的にディスク容量が増える
- なので、ディスク容量を設計する際は、上記を考慮する必要がある
- シャード数については、上記を考慮しなくていい
ディスク容量
基本的には、ドキュメントの式から算出する
ソースデータ x (1+ レプリカの数) x (1 + インデックス作成オーバーヘッド) ÷ (1 - Linux 予約スペース) ÷ (1 - OpenSearch Service のオーバーヘッド) = 最小ストレージ要件
ポイントとしては、ディスク容量算出時は、ドキュメント更新時のディスク容量増加を加味する必要がある
Elasticsearchの仕様として、ドキュメント更新の際には、一時的に新旧分のディスク領域を使用し、セグメントマージが実施されるまで旧分のディスク領域は解放されない
参考: ドキュメント
なので、上記の式で計算する際の ソースデータ は、平常時のサイズではなく、ドキュメント更新時のサイズを使う必要がある
平常時のディスク容量をソースデータとした場合、ドキュメント更新時に容量不足になる可能性がある
ちなみに、実際に運用していたドメインのインデックスは、定期的に全ドキュメント更新を行っており、一時的に平常時の2倍程のディスク容量を使っていることがわかったため（ _cat/indices?v の pri.store.size）、改めてサイジングすることになった
また、料金はドキュメントを参照
例. 汎用 (SSD) ストレージ なら 1 GB あたり 0.162USD/月
余談
上記ディスク容量で運用していたところ、ディスク容量監視のwarningが発砲した
※ 監視はノード単位のディスク容量を見ていて、25%を切ったらwarning、20%を切ったらcriticalに設定している
上記はあくまで最小ストレージ容量なので、ノードによってディスク使用量の偏りが起きて、監視が発砲してしまったのだと理解している
というわけで、改めて監視が発砲しないようにディスク容量を設計することにした
具体的には、監視の発砲時のノード単位のディスク使用量から逆算してディスク容量を見積もる（AWS公式のやり方ではない）
監視の発砲時のノード単位のディスク使用量が全体の 30% に抑えられるよう、ノード単位のディスク使用量を再計算して、それにノード数を掛けて全体のディスク容量を算出する
※ warning監視の閾値である 25% 以上で切りのいい割合
具体的には、X - (監視の発砲時のノード単位のディスク使用量 + 今後の拡張分) = X * 30% を計算して、求めた X にノード数を掛ける
シャード数
基本的には、ドキュメントの式から算出する
(ソースデータ + 拡張の余地) * (1 + インデックス作成オーバーヘッド)/必要シャード数 = プライマリシャードの概数
シャード数の算出時は、平常時のディスク容量で考えれば良い
ドキュメント更新時にディスク容量が増えるのは一時的なものなので
ポイントとしては、上記の式を使う際の 必要シャードサイズ を具体的にどの値にするか
AWS推奨されているのは10~50GBなので、ユースケースを踏まえて、10GB刻み（10,20,30,40,50GB）でシャード数を計算してみて、その中から適切なものを選定した
具体的な選定基準としては以下
- 現状のシャードサイズを計算して、それがAWS推奨値になっていること
- 上記で求めたシャード数と上記式を使って、今度は逆にシャードサイズを求める
- 今後の拡張分も考慮したシャード数から逆算するため、現状だと、少しシャードサイズが小さくなる
- シャードがノード数で割り切れること
- シャードがノード間で均一に分配されることが推奨されている
- 基本的には多めに確保すること
- シャード数変更はインデックス再構築が必要であり簡単に行えないため