ある企業が、Amazon OpenSearch Service（旧 Elasticsearch Service）クラスターを使ってアプリケーションログのリアルタイム検索を提供している。クラスターの JVM ヒープ使用率が常に 85% 以上になっており、ノード間のシャード再配置（Shard Rebalancing）が頻発してパフォーマンスが低下している。最小限のコスト増加でパフォーマンスを安定させる最も適切な方法はどれか。
- A. OpenSearch クラスターのインスタンスタイプを最大のものに変更してメモリを増やす。
- B. ウォームノード（UltraWarm）を追加して古いインデックスデータをウォームノードに移行し、ホットノードのメモリ負荷を削減する。古いデータはアクセス頻度が低く、ウォームノードの低コストストレージに適している。
- C. ログデータを OpenSearch への送信前に Lambda 関数でフィルタリングして送信量を削減する。
- D. OpenSearch クラスターを新しいリージョンに移行して未使用のキャパシティを利用する。
解答と解説を見る
正解: B
OpenSearch Service の UltraWarm（ウォームノード）は S3 バックの低コストストレージを使用し、古いインデックスデータをウォームノードに移行することでホットノードのメモリ・ストレージ負荷を大幅に削減できる。古いログは検索頻度が低く若干高いレイテンシー（ホットに比べて）は許容されることが多い。UltraWarm のストレージコストはホットノードの 1/10〜1/5 程度で済む。選択肢Aのインスタンスタイプを最大に変更することは短期的には有効だが、コストが大幅に増加し「最小限のコスト増加」要件に合わない。データ量が増加し続ければ同じ問題が再発する。選択肢DのOpenSearch を別リージョンに移行することは実際のメモリ不足問題の解決にはならない。選択肢CのLambda によるログフィルタリングは送信量を削減できるが、既存のクラスターに蓄積されたデータのメモリ問題は解決しない。また必要なログが失われる可能性もある。