Amazon OpenSearch Service の物理設計とスケーリング戦略 - 2025年版完全ガイド

最終更新日：2025年08月26日｜公開日：2025年08月22日

writer：益子竜与志

Amazon OpenSearch Service の設計について、2025年の最新アップデートを踏まえた実践的な指針をまとめました。

シャード設計の推奨値が用途別に細分化され、新たにServerlessオプションやOR1ストレージなど、選択肢が大幅に広がっています。本記事では、従来の設計手法をベースに、最新のベストプラクティスを交えながら、実際のプロジェクトで使える設計フローを解説していきます。

特に「シャードサイズは10-50 GiBで統一」という従来の考え方から、「検索重視なら10-30 GiB、書き込み重視なら30-50 GiB」という新しい指針への転換は、パフォーマンス最適化において重要なポイントとなります。

Amazon OpenSearch Service の物理設計とスケーリング戦略 - 2025年版完全ガイド

OpenSearch Service の現在地と設計の重要性

Amazon OpenSearch Service は、Elasticsearch OSS 7.10 までの互換性を維持しながら、独自の進化を続けています。2025年現在、単なる検索エンジンの枠を超えて、ログ分析、セキュリティ分析、時系列データ処理、そして最近では「ベクトル検索」まで幅広いワークロードに対応するプラットフォームへと成長しました。

マネージドサービスとはいえ、適切な物理設計なしには期待するパフォーマンスは得られません。特に「シャード数」は一度決めると変更できないため、慎重な設計が求められます。本記事では、2025年8月時点の最新ドキュメントに基づき、実践的な設計アプローチを体系的に解説していきます。

設計の前提となる基本概念

シャード設計の新しい指針

OpenSearch のシャード設計において、まず押さえるべき重要な変更点があります。

「デフォルトのシャード数」がOpenSearch Service版とオープンソース版で異なるということです。OpenSearch Service では5つのプライマリシャードと1つのレプリカ（合計10シャード）がデフォルトとなっていますが、オープンソース版OpenSearchでは1プライマリ＋1レプリカ（合計2シャード）がデフォルトです。

推奨シャードサイズも、従来の「10-50 GiB」という大雑把な指針から、用途別により明確になりました。

表用途別の推奨シャードサイズ

用途	推奨サイズ	理由
検索レイテンシ重視	10-30 GiB	クエリ処理の並列度を高め、応答速度を最適化
書き込みスループット重視	30-50 GiB	インデックス作成のオーバーヘッドを削減
アーカイブ・分析用途	50 GiB以上も許容	UltraWarmやコールドストレージと併用前提

この表が示すように、ワークロードの特性に応じてシャードサイズを調整することで、より効率的な運用が可能になります。

さらに、OpenSearch 2.17以降ではノードあたりのシャード上限が最大4,000まで拡張されました。従来の上限1,000から大幅な増加ですが、これは「より多くのシャードを作るべき」という意味ではありません。むしろ、時系列データのような特殊なユースケースに対応するための拡張と捉えるべきでしょう。

ストレージ容量の正確な見積もり

ストレージ設計において、AWSが提供する計算式は変わらず有効です。

厳密な計算式は以下の通りです。

ソースデータ × (1 + レプリカ数) × (1 + インデックス作成オーバーヘッド)
÷ (1 - Linux予約5%) ÷ (1 - サービス予約20%) = 最小ストレージ要件

ただし実務では、簡易版として「ソースデータ×(1+レプリカ)×1.45」を使うことも可能です。この簡易式は、各種オーバーヘッドを総合的に考慮した実用的な係数となっています。

重要な注意点として、サービス予約の20%には「最大20 GiB/インスタンス」という上限があります。大容量インスタンスを使用する場合、この上限により実効的な予約率が下がることを考慮する必要があります。

ワークロードタイプ別の設計アプローチ

長期存続インデックスの設計

ウェブサイト検索、ドキュメント検索、ECサイトの商品検索など、データが長期間保持され頻繁に更新される「長期存続インデックス」の設計では、以下の点を重視します。

まず、検索パフォーマンスを最優先に考え、シャードサイズは「10-30 GiB」の範囲に収めます。これにより、検索クエリの並列処理が効率化され、レスポンスタイムの改善が期待できます。

インスタンスタイプの選定では、新世代のGraviton3ベース（C7g/M7g/R7g）を第一選択とします。従来のx86系インスタンスと比較して、コストパフォーマンスが約20-30%向上しているケースが多く、特にCPU負荷の高い検索処理において効果を発揮します。

レプリカ数は可用性要件に応じて決定しますが、読み取り負荷分散も考慮して最低1つは設定することをお勧めします。Multi-AZ with Standby構成を採用する場合、3つのアベイラビリティゾーンに均等に配置されるため、レプリカ数は2以上が理想的です。

ローリングインデックスの最適化

ログ分析や時系列データ処理などの「ローリングインデックス」では、データの流入量と保持期間から必要なストレージを算出します。

例えば、時間あたり200 MiBのログが流入し、14日間保持する場合の計算例を見てみましょう。

総データ量 = 200 MiB/時 × 24時間 × 14日 = 約66 GiB
最小ストレージ（厳密式）= 66 × 2 × 1.1 ÷ 0.95 ÷ 0.8 = 約191 GiB
最小ストレージ（簡易式）= 66 × 2 × 1.45 = 約191 GiB

このケースでは、書き込みスループット重視でシャードサイズを40 GiB程度に設定し、プライマリシャード数を2つとすることで、効率的な運用が可能になります。

Index State Management（ISM）を活用したロールオーバー設定により、自動的なインデックス管理も実現できます。時間ベースまたはサイズベースでのロールオーバー条件を設定し、古いインデックスの自動削除やUltraWarmへの移行を組み込むことで、運用負荷を大幅に削減できます。

新しい選択肢：Serverless とストレージ階層

OpenSearch Serverless の活用シナリオ

OpenSearch Serverlessは、インフラ設計の負担を大幅に軽減する新しい選択肢です。「OCU（OpenSearch Compute Unit）」という単位で自動スケーリングし、各OCUは6 GiB RAM、対応するvCPU、S3連携機能を提供します。

Serverless が特に効果を発揮するユースケースとして、以下のようなケースが挙げられます。

予測困難な負荷変動への対応が必要なケースでは、従来のプロビジョニング型では過剰なリソース確保が必要でしたが、Serverless なら実際の使用量に応じた課金となるため、コスト最適化が図れます。

イベントドリブンなワークロードやクリックストリーム分析のように、瞬間的にデータが急増するケースでも、OCUの自動スケーリングにより対応可能です。

ベクトル検索のPoCやプロトタイプ開発では、必要なリソース量が読みにくいため、Serverless の柔軟性が大きなメリットとなります。

デフォルトの冗長化構成では、検索用2 OCU、取り込み用2 OCUの計4 OCUから開始し、負荷に応じて自動的にスケールします。各OCUは約120 GiBのホットインデックスを処理できる設計となっているため、初期段階では約480 GiBのデータを扱えます。

データ階層化による長期保管戦略

UltraWarmとコールドストレージの活用により、大量のデータを低コストで長期保管できます。

表データ階層別の特性と用途

階層	ストレージタイプ	アクセス特性	コスト	推奨用途
ホット	EBS/インスタンスストア	ミリ秒レイテンシ	高	直近データ、頻繁な検索対象
UltraWarm	S3ベース専用ノード	秒単位レイテンシ	中	数週間〜数ヶ月前のデータ
コールド	S3直接保管	オンデマンド復元	低	アーカイブ、コンプライアンス用途

この階層化戦略を採用することで、ホットデータのストレージコストを抑えながら、必要に応じて過去データへのアクセスも確保できます。

特に注目すべきはOR1ストレージです。EBSをプライマリストレージとしながら、データ到着時にS3へ同期コピーすることで、高い書き込みスループットと耐久性を両立しています。大量のログ取り込みやIoTデータ処理など、書き込み性能が重要なワークロードに最適です。

インスタンスタイプの選定戦略

T系インスタンスの制約と使いどころ

T3/T2インスタンスには多くの機能制限があることを改めて強調しておきます。

主な制限事項として以下が挙げられます。

Auto-Tuneが利用不可
UltraWarmおよびコールドストレージが利用不可
クラスタ内のインスタンス数が10台以下に制限
専用マスターノードとして使用不可

これらの制約から、T系インスタンスは開発環境での検証や、小規模なPoCなど限定的な用途にとどめるべきです。本番環境では、最低でもM系インスタンスの採用を推奨します。

専用マスターノードの設計指針

台数設定の鉄則

専用マスターノードの台数設定には明確なルールがあります。

「3台」が推奨値であり、ほとんどのケースでこれを選択すべきです。1台構成は単一障害点となるため「禁止」、2台や4台といった偶数構成は「非推奨」です。これは、クォーラム（過半数）による意思決定メカニズムに起因します。

5台構成は耐障害性が向上しますが、多くの場合は過剰です。非常に大規模なクラスタ（ノード数200以上、シャード数10,000以上）でない限り、3台構成で十分な可用性を確保できます。

サイズ選定の新基準

専用マスターノードのサイズ選定では、管理対象となるノード数とシャード数に応じてRAM容量を決定します。

表専用マスターノードのサイズ選定基準

RAM容量	管理可能ノード数（目安）	管理可能シャード数（目安）	推奨インスタンスタイプ
8 GB	〜30	〜15,000	m6g.large
16 GB	〜60	〜30,000	c6g.xlarge
32 GB	〜120	〜60,000	c6g.2xlarge
64 GB	〜240	〜120,000	r6g.2xlarge

OpenSearch 2.17以降では計算式が拡張され、より多くのシャードを管理できるようになっていますが、実際の運用では余裕を持ったサイジングを心がけるべきです。

高可用性構成のベストプラクティス

Multi-AZ with Standby の活用

Multi-AZ with Standbyは、3つのアベイラビリティゾーンにデータを完全複製し、スタンバイインスタンスを配置する高可用性構成です。

従来のMulti-AZ構成と比較して、以下の点で優れています。

ゾーン障害時の自動フェイルオーバーが高速化され、RPO（目標復旧時点）とRTO（目標復旧時間）が大幅に改善されます。

スタンバイノードが常時起動しているため、障害発生時の切り替えがシームレスに行われます。

データの3重複製により、複数ゾーン障害にも耐えうる構成となっています。

ただし、コスト面では通常構成の約1.5倍となるため、ビジネス要件とのバランスを考慮する必要があります。

Blue/Green デプロイメントによる安全な変更

設定変更時のBlue/Green デプロイメントにより、サービス無停止での構成変更が可能です。

Blue/Green デプロイメントの流れは以下の通りです。

現行環境（Blue）と並行して新環境（Green）を構築
データを新環境に同期
トラフィックを段階的に新環境へ切り替え
問題がなければ旧環境を削除

この仕組みにより、インスタンスタイプの変更、ストレージサイズの拡張、OpenSearchバージョンのアップグレードなど、従来はダウンタイムを伴った作業が無停止で実行できます。

実践的な設計ワークフロー

段階的アプローチの重要性

OpenSearch Service の設計は、以下のワークフローに沿って段階的に進めることが重要です。

第1段階：ワークロード分析 まず、対象となるワークロードを「長期存続インデックス」か「ローリングインデックス」に分類します。この分類により、後続の設計方針が大きく変わってきます。

第2段階：容量見積もり前述の計算式を用いて必要なストレージ容量を算出します。簡易式（×1.45）で概算し、詳細設計時に厳密式で検証するアプローチが実用的です。

第3段階：シャード設計 用途別の推奨サイズ（検索重視：10-30 GiB、書き込み重視：30-50 GiB）に基づき、プライマリシャード数を決定します。将来の成長を見込んで過大にシャードを作る誘惑に駆られますが、小さすぎるシャードは管理オーバーヘッドが増大するため避けるべきです。

第4段階：インスタンスタイプ選定 Graviton3世代を第一選択とし、公式の目安（100 GiBあたりvCPU×2、RAM 8 GiB）で仮決めした後、必ず代表的なワークロードでベンチマークテストを実施します。

第5段階：マスターノード設計 3台構成を基本とし、前述のRAM目安表に基づいてサイズを選定します。Multi-AZ with Standbyの採用可否もこの段階で決定します。

第6段階：運用設計 ISMによる自動化、CloudWatchでの監視項目（特にShard数、Heap使用率、Storage使用率）の設定、Blue/Greenデプロイメントの手順確立などを行います。

Serverless 採用の判断基準

プロビジョニング型かServerlessかの選択は、以下の観点から判断します。

負荷予測の確度が低い、または変動が激しい場合はServerlessが有利です。一方、安定した負荷が見込める場合は、プロビジョニング型の方がコスト効率が良いケースが多いです。

運用負荷の観点では、Serverlessはシャード設計やノードサイジングが不要なため、運用チームの負担を大幅に軽減できます。

コスト構造の違いも重要です。Serverlessは使用量ベースの課金のため、初期投資を抑えられますが、大規模・定常的なワークロードではプロビジョニング型の方が経済的になる傾向があります。

設計例：ログ分析システムの構築

要件定義と初期見積もり

実際のプロジェクトを想定した設計例を見てみましょう。

あるWebサービスのログ分析システムを構築するケースを考えます。要件は以下の通りです。

ログ流入量：500 MiB/時（ピーク時は2倍）
保持期間：30日（ホット）+ 90日（ウォーム）+ 1年（コールド）
検索要件：直近7日は高速検索必須、それ以前は数秒の遅延許容

まず、ホットデータの容量を計算します。

30日分のデータ量 = 500 MiB/時 × 24時間 × 30日 = 360 GiB
ピーク考慮 = 360 GiB × 1.5 = 540 GiB
最小ストレージ（簡易式）= 540 × 2 × 1.45 = 約1,566 GiB

階層化戦略の適用

このケースでは、データ階層化が効果的です。

ホット層（30日）には約1.6 TiBが必要ですが、検索頻度の高い直近7日分（約126 GiB）のみを高性能インスタンスに配置し、残りはコスト効率の良い構成とします。

UltraWarmには31-120日のデータ（約1.4 TiB）を配置します。検索頻度は低いものの、必要時にはすぐアクセスできる状態を維持します。

121日以降のデータはコールドストレージへ自動移行し、年次監査やコンプライアンス要件に対応します。

最終構成の決定

以上の分析を踏まえ、以下の構成を推奨します。

ホット層（検索重視）

データノード：r7g.xlarge × 3台（Multi-AZ配置）
ストレージ：GP3 600 GiB/ノード
シャードサイズ：25 GiB（検索最適化）
インデックス戦略：日次ローリング、7日経過後に読み取り専用化

ホット層（コスト最適化）

データノード：m7g.large × 3台
ストレージ：GP3 400 GiB/ノード
8-30日のデータを保持

UltraWarm層

warm.ultrawarm1.medium × 2台
31-120日のデータを自動移行

専用マスターノード

m7g.large × 3台（シャード数とノード数から算出）

この構成により、パフォーマンス要件を満たしながら、従来の全データホット保持と比較して約60%のコスト削減が見込めます。

トラブルシューティングと最適化

よくある設計ミスと対策

実際のプロジェクトでよく見かける設計ミスと、その対策をまとめました。

過剰なシャード分割は最も多い失敗パターンです。「将来の成長に備えて」という理由で、初期段階から数百のシャードを作成してしまうケースです。結果として、各シャードが数百MBという極小サイズになり、管理オーバーヘッドだけが増大します。対策として、初期は控えめなシャード数から始め、ISMによるローリングで段階的に拡張する戦略を採用すべきです。

不適切なレプリカ数設定も頻繁に見られます。「可用性のため」といってレプリカを3つも4つも設定するケースがありますが、ストレージコストが比例して増加します。Multi-AZ with Standbyを活用すれば、レプリカ1でも十分な可用性を確保できます。

T系インスタンスの本番利用は、コスト削減の誘惑から陥りやすい罠です。前述の機能制限により、後から拡張が必要になった際に大規模な移行作業が発生します。

パフォーマンスチューニングの実践

設計後の運用フェーズでは、継続的なパフォーマンスチューニングが重要です。

ヒープメモリの最適化では、JVMヒープを物理メモリの50%以下に設定することが基本ですが、32GB以下に抑えることで、圧縮OOPSによる効率化が図れます。CloudWatchでJVMMemoryPressureを監視し、75%を超える場合はインスタンスタイプの見直しを検討します。

クエリ最適化では、Filter contextとQuery contextの使い分けが重要です。スコアリングが不要な条件はFilter contextで処理することで、キャッシュの活用とCPU負荷の削減が可能です。

バルク処理の調整では、一度のバルクリクエストサイズを5-15 MBに調整し、並列度は利用可能なCPUコア数の2倍程度に設定することで、取り込みスループットを最大化できます。

将来を見据えた設計思想

ベクトル検索への対応準備

生成AIの普及に伴い、ベクトル検索のニーズが急速に高まっています。OpenSearch Service でもk-NN（k-nearest neighbor）検索がサポートされており、セマンティック検索やレコメンデーションシステムへの応用が進んでいます。

ベクトル検索を見据えた設計では、以下の点を考慮する必要があります。

メモリ要件が通常の検索より大幅に増加するため、R系インスタンスの採用が基本となります。次元数とベクトル数に応じて、必要なメモリ量を事前に見積もることが重要です。

インデックス構築時間も長くなる傾向があるため、書き込み性能に優れたOR1ストレージの採用も検討価値があります。

現時点では実験的な要素も多いため、Serverlessでのスモールスタートも有効な選択肢です。

継続的な最適化サイクル

OpenSearch Service の設計は、一度決めたら終わりではありません。ワークロードの変化、新機能のリリース、コスト最適化の機会など、継続的な見直しが必要です。

四半期ごとの設計レビューを実施し、以下の観点から最適化の機会を探ります。

利用状況の分析では、CloudWatchメトリクスから実際のリソース使用率を確認し、過剰・不足がないか検証します。特に、シャードサイズの実態とCPU/メモリ使用率のバランスは重要な指標です。

新機能の評価も欠かせません。AWSは頻繁に新機能をリリースしているため、既存の設計に組み込める改善点がないか定期的にチェックします。

コスト最適化の観点では、Reserved InstancesやSavings Plansの活用、データ階層化の見直し、不要なレプリカの削減など、継続的な改善機会があります。

まとめ

Amazon OpenSearch Service の物理設計は、2025年現在、より多様な選択肢と柔軟な構成が可能になっています。従来の画一的なアプローチから、ワークロード特性に応じた最適化へとパラダイムがシフトしています。

特に重要な変化として、シャードサイズの用途別推奨値（検索：10-30 GiB、書き込み：30-50 GiB）、Serverlessという新しい選択肢、データ階層化による長期保管戦略、そして最新世代インスタンスによるパフォーマンス向上が挙げられます。

設計の成功には、まず要件を正確に把握し、適切な計算式で容量を見積もり、ワークロード特性に応じたシャード設計を行い、最新のベストプラクティスを適用することが不可欠です。そして何より、継続的な監視と最適化のサイクルを回すことが、長期的な成功の鍵となります。

本記事で紹介した設計フローと最新情報を活用し、より効率的で拡張性の高いOpenSearch環境を構築していただければ幸いです。技術は日々進化していますが、基本的な設計原則と体系的なアプローチを押さえることで、変化にも柔軟に対応できるはずです。

この記事を書いた人

ソリューションアーキテクト益子竜与志

複数のITベンチャーで技術責任者／経営企画を歴任し、事業戦略とプロダクト成長を主導。2017年にRagate株式会社を創業し、サーバーレス技術の黎明期よりAWS・サーバーレス開発プロジェクトを牽引し、AWS Top Engineers 2024 ( Service ) ・AWS Rising Star Partners of the Year – Japan賞を受賞。経営課題/戦略を起点としたDX戦略策定とクラウドシステムデリバリを強みに、SMB市場を中心に数多くの企業変革を支援。GLOBIS経営大学院MBAで培った経営戦略・マーケティングミックスの知見と、AWS／先端技術の深い専門性を掛け合わせ、価値創出を加速させている。

【保有資格・認定】