大手Eコマース企業が、商品検索プラットフォームとしてAmazon OpenSearch Service（データノード：r6g.2xlarge.search × 7台、専用マスターノード：c6g.2xlarge.search × 3台）を運用しています。最近、サービスレベルの劣化が深刻化しています。 【現在の構成・状況】 ・合計インデックスサイズ：3.5 TB（30個のインデックス） ・ピーク時クエリ負荷：3,000リクエスト/秒（セール期間） ・1日あたり2億件のドキュメント更新 ・アクセスパターン：直近7日間のデータへのクエリが全体の85%を占める ・すべてのインデックスにデフォルト設定（プライマリシャード：1、レプリカ：1）が適用されている ・UltraWarm（温かいデータ向けの低コストノード層）およびCold Storage（コールドデータ向けのさらに低コストなストレージ層）は未設定 ・ISM（Index State Management：インデックスのライフサイクルを自動管理するポリシー機能）ポリシーは未設定 【問題点】 ・クエリの35%が応答時間2秒超（SLAは1秒以内） ・JVMヒープ使用率が常時75〜85%（推奨上限を超過） ・クラスターが断続的にYellow状態（一部のレプリカシャードが未割り当て）になる ・Luceneセグメント（検索インデックスの内部データ構成単位）数が多く（1インデックスあたり数百〜数千個）、バックグラウンドのマージ処理がI/Oを圧迫している パフォーマンスの改善とクラスター安定化のために最も効果的な対策の組み合わせはどれですか？（2つ選択）
選択肢Bのシャード最適化とISMポリシー：デフォルトの1プライマリシャードでは全クエリが単一シャードに集中するため並列処理が不可能で、3,000 rpsのピーク負荷への対応力が著しく低下します。シャード数を適切に増やすことで検索リクエストを複数ノード・シャードに分散できます。ISMポリシーによるデータ階層化により、全クエリの85%にしかアクセスされない8日以降のデータをUltraWarm/Cold Storageに移動することでホットノードのストレージとJVMヒープを大幅に解放します。 選択肢Dの選択肢：7日超の古いインデックスは新規書き込みがなくイミュータブルなため、Force Mergeによるセグメント統合（数百〜数千→1〜5個）はJVMのセグメントメタデータメモリを大幅に削減し、バックグラウンドマージによるI/O圧迫を解消します。クラスターのYellow状態解消により読み取りスループットと安定性も回復します。 選択肢A：全インデックスを1プライマリシャードに統一することは高クエリ負荷環境で逆効果です。JVMヒープをRAMの70%に設定することはOpenSearchのベストプラクティスに反します。 選択肢C：Serverlessへの全面移行は大規模なアーキテクチャ変更であり、既存の設定・データ移行コストが高く即時の問題解決になりません。 選択肢E：JVMヒープをRAMの75%に設定することはOpenSearchのベストプラクティスに違反します。refresh_intervalを60秒に延長すると検索結果の鮮度が大幅に低下します。