LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

OpenSearch/検索・ログ基盤のコストが膨らむ理由：常時稼働ノード＋ストレージ増加

Amazon OpenSearch Serviceのコスト最適化とは、検索・ログ基盤のストレージ階層・インスタンス種類・利用形態を見直し、AWS公式が提供するUltraWarm・Cold Storageなどの仕組みを活用して費用を適正化する取り組みです。アクセス頻度の低いデータをコスト効率の高いストレージ階層に移行したり、インスタンスの稼働状況を実績値に照らして適正化したりすることで、クラスタ全体のコストを見直せます。

コストが膨らむ主な原因は、データノードの常時稼働コストとストレージ増加の組み合わせです。OpenSearch/Elasticsearchベースの検索・ログ基盤では、クラスタを構成するデータノードがインスタンスとEBSボリュームを継続的に消費します。データ量が増えるほどノード数やボリューム容量を追加せざるを得なくなり、費用が比例して膨らみます。

もう一つの原因は、古いインデックスの扱いが後回しになりやすい点です。数か月以上前のログや検索インデックスは参照頻度が低くなりますが、設計上の整理がなければHot階層のデータノード上に蓄積し続けます。アクセス頻度に応じてデータを適切な階層に移行することが、コスト適正化の起点になります。

ストレージ階層による最適化：Hot/UltraWarm/Coldの使い分け

AWS公式によると^*1、Amazon OpenSearch Serviceはストレージ階層として「Hot」「UltraWarm」「Cold Storage」の3層を提供しており、データのアクセス頻度に応じた使い分けができます。各階層の特性を正確に理解することが、コスト最適化の設計の基礎になります。

Hot階層：直近データ・高頻度クエリ向け

Hot階層はデータノード上のEBSボリュームにインデックスを保持する形態です。クエリ応答速度が最も速く、書き込み・更新が頻繁に発生するインデックスや、直近のログ検索・リアルタイム分析に向いています。一方でデータノードとEBSボリュームの費用が常時発生するため、アクセス頻度が低下したインデックスをHot階層に置き続けることがコスト増加の要因になります。

UltraWarm階層：低頻度データを低コストで保持

UltraWarm（ウルトラウォーム）は、S3をバックエンドストレージとして活用するストレージ階層です。AWS公式によると^*1、UltraWarmはHot階層と比較してGBあたりのコストを約90%（AWS公表）低減できるとされています。単一クラスタで数PB規模のデータを保持できる点も特徴です。

インデックスはUltraWarm専用のウォームノード上でキャッシュを利用しながらクエリに対応します。Hot階層ほどの応答速度は出ませんが、対話的なクエリには対応できます。数日〜数週間以上経過した低頻度参照のログインデックスや、過去の検索インデックスをUltraWarmに移行することで、Hot階層のノード数・ボリューム容量を削減できます。

Cold Storage：長期保存・必要時のみコンピュート課金

Cold Storage（コールドストレージ）はS3に近いコストでインデックスを保管できる階層です。インデックスをCold Storageに移行すると、アタッチされているUltraWarmノードのリソースが解放されます。検索を行う際にはCold StorageからUltraWarmへのアタッチが必要になりますが、コンピュートコストは必要な時にしか発生しません。数か月以上経過した監査ログや参照頻度が極めて低い長期保存データに向いています。

どのデータをどの階層に置くか：設計の考え方

階層の設計には「アクセス頻度」と「保存期間」の2軸が基準になります。直近7〜30日以内のデータはHot、数か月以内で月数回程度クエリするデータはUltraWarm、それ以降の長期保存データはCold Storageという形が一般的な分類の出発点です。

ただし、実際の境界はユースケース（リアルタイム監視ログなのか過去分析用データなのか）や応答時間要件によって異なります。AWS公式のIndex State Management（ISM）ポリシーを設定することで、インデックスの経過日数に応じた自動的な階層移行を実装できます。

その他の削減手法：インスタンス適正化・Reserved Instance・EBS・Serverlessの選択

ストレージ階層の活用に加え、AWS公式が推奨するコスト最適化の手法として、インスタンスの適正化・Reserved Instance（リザーブドインスタンス）・EBSボリュームの見直し・Amazon OpenSearch Serverlessへの移行検討があります。

CloudWatchメトリクスを使ったインスタンス適正化（right-sizing）

AWS公式によると^*1、Amazon CloudWatch（クラウドウォッチ）のメトリクスを確認してインスタンスを適正化することがコスト削減の基本手法の一つです。CPU使用率・JVMメモリ使用率・ディスクキュー長・クラスタのステータスを継続的にモニタリングすることで、過剰スペックになっているノードを特定できます。

インスタンスタイプの変更やノード数の調整は、クラスタの安定性に直接影響するため、メトリクスの実績値を十分に確認したうえで計画的に行う必要があります。特にメモリプレッシャー（JVM heap使用率が長期間高止まりしていないか）の確認は、インスタンスダウンサイジングの前提条件になります。

定常稼働ノードへのReserved Instance適用

長期間安定的に稼働するクラスタのインスタンスに対しては、Reserved Instance（RI）の適用でオンデマンド料金と比較してコストを抑えられます。AWS公式によると^*1、1年または3年の期間コミットにより割引が適用されます。稼働要件が固まっているクラスタに対して、AWS Cost Explorer上のRI推奨を参考にRI購入を検討するとよいです。

EBSボリュームの適正化

Hot階層のデータノードに紐づくEBSボリュームも費用に影響します。AWS公式によると^*1、EBSボリュームのサイズと種類を見直すことがコスト最適化の手法の一つです。ボリューム使用率が低い場合はサイズを縮小できます。また、OpenSearch ServiceはgpとioタイプのEBSに対応しており、ワークロードによってはgp3（gp2より低コストで性能設定が柔軟）への切り替えも検討対象になります。

Amazon OpenSearch Serverlessの選択

Amazon OpenSearch Serverless（サーバーレス）は、クラスタ管理・キャパシティ設定・シャード/インデックスのライフサイクル管理を自動化する形態です。AWS公式によると^*1、サイジングやシャード・インデックスのライフサイクルを自動で管理するため、運用工数を削減できます。

ただし、Serverlessはデータサイズが小さいまたはリクエスト負荷が低い場合にはオンデマンドのOpenSearch Serviceより費用が高くなる可能性があります。どちらが費用対効果に優れるかは、データ量とリクエスト量の組み合わせによって変わるため、AWS公式の料金シミュレーターで現行クラスタの想定コストと比較することが大切です。

最適化を進める流れ：可視化→設計→適用→モニタリング

Amazon OpenSearch Serviceのコスト最適化を体系的に進めるには、現状の費用構造と使用状況を把握してから設計・実装に進む順序が重要です。設計を省略して設定変更を先行すると、クラスタ安定性に影響するリスクがあります。

ステップ1：使用状況の可視化——コストと利用実態を把握する

AWS Cost ExplorerでAmazon OpenSearch Serviceのコスト内訳を確認し、インスタンス費用・EBSボリューム費用・データ転送費用の割合を把握します。続いてAWSマネジメントコンソールのOpenSearch Service画面でクラスタのメトリクス（CPU・JVMメモリ・ストレージ使用率）を確認し、過剰リソースになっているノードやHot階層に蓄積している古いインデックスを特定します。

インデックスの一覧と容量は、Kibana（キバナ）またはOpenSearch Dashboards（ダッシュボード）の「Index Management」メニュー、またはAPIを使って確認できます。インデックス名とデータの年月・用途を対応付けて整理すると、階層移行の優先度が立てやすくなります。

ステップ2：階層・サイズ設計——移行ポリシーを決める

可視化した情報をもとに、「どのインデックスをいつUltraWarmまたはCold Storageに移行するか」をISM（Index State Management）ポリシーとして設計します。コンプライアンス要件がある場合は法令・社内規程に照らして最低保存期間を確認したうえで移行ポリシーを決定します。

インスタンス適正化を同時に進める場合は、階層移行後にHot階層のノード数やボリューム容量が実際に削減できるかを先にシミュレーションします。移行前後で必要なインスタンス数とEBSサイズを試算することで、コスト削減効果を事前に確認できます。

ステップ3：設定の適用——ISMポリシー・インスタンス変更・RI購入

設計に基づいてISMポリシーを作成・適用します。ISMポリシーはOpenSearch Dashboards上のGUIまたはAPIから設定でき、インデックスの経過日数・サイズを条件に移行・削除・スナップショット取得を自動化できます。UltraWarmが有効化されていない場合は、クラスタ設定でUltraWarmを有効化してからウォームノードを追加します。

インスタンス適正化やRI購入はクラスタの稼働安定性に影響するため、ステージング環境での動作確認やメンテナンス時間帯での適用が推奨されます。変更後は少なくとも1〜2週間分のメトリクスを確認し、JVMメモリやCPUが許容範囲内に収まっているかを確かめます。

ステップ4：継続的なモニタリング——定期的なコスト・利用状況の確認

AWS Cost ExplorerのカスタムレポートやAWS Budgetsのアラートを設定し、OpenSearch Serviceの費用が一定のしきい値を超えた際に通知を受け取れるようにします。月次でインデックスの成長量とColdストレージへの移行状況を確認し、ISMポリシーを見直すことで最適化の継続的な維持につながります。

外注の使いどころ：コスト診断・階層設計・基盤運用の委託判断軸

Amazon OpenSearch Serviceのコスト最適化を内製で進めるには、AWSサービスの知識・Elasticsearch/OpenSearchのインデックス管理・ISMポリシーの設計・インフラコスト分析の経験が必要です。複数のスキルを同時に求められるため、担当者の確保や習熟コストが課題になりやすいです。

内製対応が難しいポイント

コスト最適化に取り組む際に内製で詰まりやすいのは、「現状のインデックス構成と費用の対応付け」です。インデックス数が多い・命名規則が統一されていない・複数システムのログが混在しているといった状況では、どのインデックスから移行すべきかの判断に時間がかかります。

また、UltraWarm・Cold Storageの設計は、移行後のクエリ応答時間の変化やスナップショット管理の運用設計と合わせて検討する必要があります。設計が不十分なまま移行すると、アプリケーション側のタイムアウトエラーや監視ツールのクエリ失敗につながるリスクがあります。内製で対応する場合は、本番移行前に検証環境での十分な動作確認が不可欠です。

外注が効果的なフェーズと委託判断軸

外注が費用対効果に優れるのは、主に以下の3つのフェーズです。

• コスト診断フェーズ：AWS Cost ExplorerとOpenSearchメトリクスを組み合わせた現状分析・削減ポテンシャルの試算。自社に分析ノウハウがない場合に特に有効です。
• 階層設計・実装フェーズ：ISMポリシーの設計・UltraWarm/Cold Storageの有効化・インスタンス適正化の実装。クラスタ安定性に影響する変更のため、OpenSearch運用実績のある委託先が向いています。
• 継続運用フェーズ：月次コスト確認・ISMポリシーの定期見直し・インシデント対応。社内に専任担当がいない場合、月次サポート契約で継続的に支援を受ける形が選択肢になります。

委託先を選定する際の判断軸は、「AWSのOpenSearch Serviceに関する実務経験があるか」「ISMポリシーの設計・実装実績があるか」「コスト削減の試算プロセスを提示してもらえるか」の3点です。加えて、元請（プライムベンダー）として一貫して対応できる体制かどうかも確認すると、ベンダー間の連携コストを抑えられます。

まとめ：OpenSearchコスト最適化を進める3つの判断軸

本稿では、Amazon OpenSearch Serviceのコストが膨らむ理由から、AWS公式のストレージ階層活用・インスタンス適正化・Reserved Instance・Serverlessへの移行判断、そして外注の使いどころまでを整理しました。要点を3つに集約すると次のとおりです。

第一に、コスト削減の起点はストレージ階層の活用です。Hot階層に蓄積している低頻度参照インデックスをUltraWarmまたはCold Storageに移行することで、GBあたりのコストを大幅に低減できます（AWS公表で約90%低減）。ISMポリシーを使った自動移行の仕組みを組み込むことで、継続的な最適化が維持しやすくなります。

第二に、インスタンスとEBSのright-sizingは、CloudWatchメトリクスの実績値を見てから判断することが大切です。過剰スペックの解消とReserved Instanceの活用を組み合わせることで、コンピュートコストの削減につながります。

第三に、内製対応が難しい局面では外注の活用が費用対効果を高めます。コスト診断・階層設計・継続運用の各フェーズで委託の選択肢を持つことで、担当者不在のリスクや設計ミスによる障害リスクを低減できます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS公式「Amazon OpenSearch Service のコスト最適化手法」（Amazon Web Services）

Tweet