ESシャード・クラスタ計算

ESシャード・クラスタ計算

Elasticsearchのシャード数とクラスタサイジングを正確に算出。プライマリおよびレプリカの必要ストレージ、ノードRAM、JVMヒープ上限、ディスクウォーターマークの安全閾値を瞬時に見積もります。

サンプル読込
プライマリストレージ容量9.92 TB
総ディスク容量24.80 TB
アクティブシャード数398
推奨データノード数7 Nodes
マスターノード・クォーラム3 Dedicated
ヒープ・シャード健全性9%
ワークロードアーキテクチャ

Time-series telemetry, container logs, and system metrics with ILM rollover and 1 replica.

250.0 GB / day
30 Days
インデックスオーバーヘッド:+15%
Peak Burst:+15%
ウォーターマーク安全バッファ:20%
ノードハードウェア仕様
64 GB RAM
JVMヒープ割当比率:31 GB Heap / 33 GB OS Cache

Compressed OOPs Enabled (< 31 GB): ヒープサイズを31GB以下（推奨30.5GB未満）に保つことで、Compressed OOPsが有効となりポインタのオーバーヘッドを削減できます。

4.0 TB (4,000 GB)
20 shards / GB
10 (Conservative)20 (Official Default)25 (Aggressive)
キャパシティ逆算ソルバー

指定したハードウェア構成やノード数から逆算し、クラスタが許容可能な最大データ容量を算出します。

Max Safe Daily Ingestion278.3 GB / dayBottleneck: Disk Space
Max Shards Allowed3,7201,860 Primaries
Max Retention (Current Load)33 Days@ 250 GB/d
Cluster DimensionCalculated Metric
プライマリストレージ容量9.919 TB (9,918.8 GB)
レプリカストレージ容量19.838 TB
ヘッドルーム込み総ディスク容量24.797 TB
推奨シャード数199 Primaries (398 Active)
推奨データノード数7 Nodes
マスターノード・クォーラム3 Dedicated Master Nodes
Coordinating Ingest NodesShared with Data
クラスタートポロジー構成図（SVG）7 Data + 3 Master
DEDICATED MASTER QUORUM (Split-Brain Immune)master-01master-02master-03data-01SHARDSPR~57 shards9% densityHEAP 31GDISK 4.0Tdata-02SHARDSPR~57 shards9% densityHEAP 31GDISK 4.0Tdata-03SHARDSPR~57 shards9% densityHEAP 31GDISK 4.0Tdata-04SHARDSPR~57 shards9% densityHEAP 31GDISK 4.0Tdata-05SHARDSPR~57 shards9% densityHEAP 31GDISK 4.0Tdata-06SHARDSPR~57 shards9% densityHEAP 31GDISK 4.0Tdata-07SHARDSPR~57 shards9% densityHEAP 31GDISK 4.0T
CLUSTER HEALTH: OPTIMAL
Nodes: 7Shards: 398Disk: 24.80 TB

クライアントサイド処理

すべての高負荷演算はブラウザのメモリ上でのみ高速実行されます。

サーバー送信ゼロの完全秘匿

入力データはローカル環境にのみ保持され、外部サーバーへの通信は一切発生しません。

本番環境対応エクスポート

本番クラスタへの即時反映に適したクリーンかつ最適化されたフォーマットで出力します。

ToolsAA•100% Client-Side Private Web Utilities
技術リファレンス・アーキテクチャガイド

Elasticsearch Shard & Cluster Calculator ガイド — 技術リファレンス

Elasticsearchのシャード数とクラスタサイジングを算出します。プライマリおよびレプリカのストレージ容量、ノードRAM、JVMヒープ制限、ディスクウォーターマークの安全基準値を高精度に見積もります。

Elasticsearch Shard & Cluster Calculator ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図
Elasticsearch Shard & Cluster Calculator ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図

主要パラメータと設定項目

日次データ取り込み量ギガバイト/日（GB/日）

Luceneによるインデックス拡張が行われる前に、24時間サイクルでElasticsearchにインデックスされる非圧縮の生ドキュメント総量です。

初期値: 100 GB/日
プライマリシャード目標サイズシャードあたりのギガバイト数（GB）

推奨指標：一般的な検索ワークロードでは10 GB〜30 GB、時系列ログやメトリクス分析では30 GB〜50 GBが最適です。50 GBを超えると、シャード復旧の長期化やリバランス時のタイムアウトを引き起こすリスクがあります。

初期値: 50 GB
レプリカ数（number_of_replicas）整数（レプリカコピー数）

プライマリシャードあたりの冗長コピー数です。設定値「1」は単一ノード障害に対する高可用性を提供し、読み取り処理能力を2倍に向上させます。「2」に設定すると、2ノードの同時障害からも保護されます。

初期値: 1
JVMヒープ割り当て量RAMギガバイト数（GB）

標準的な「50%ルール」に基づき、物理ノードRAMの半分をJVMヒープに割り当て、残り50%をOSのファイルシステムキャッシュ（Lucene mmapfs）用に確保します。Compressed OOPs（圧縮オブジェクトポインタ）を有効に維持するため、厳格に31 GBを超えないように設定する必要があります。

初期値: 31 GB
シャード/ヒープ比率JVMヒープ1 GBあたりのシャード数

Elastic社公式のアーキテクチャ上限は、JVMヒープ1 GBあたり最大20シャードです（例：30 GBのヒープで最大600シャード）。本番環境ではセグメントメタデータによるヒープ枯渇を防ぐため、10〜15シャード/GBに抑えるのが安全な推奨基準です。

初期値: 20シャード/GB
ディスクウォーターマーク安全バッファ空き容量バッファ比率（%）

ノードの使用率を、新規シャード割り当てが停止する85%のローウォーターマーク（low watermark）や、強制再配置が実行される90%のハイウォーターマーク（high watermark）以下に安全に維持するための未割り当てディスクマージンです。

初期値: 20%

現場のベストプラクティス・実践Tips

31 GBの壁：Compressed OOPs（圧縮オブジェクトポインタ）の閾値

ES_JAVA_OPTSのヒープ割り当てを32 GB以上に設定してはなりません。約31.5 GBを超えると、JVMは32ビットの圧縮オブジェクトポインタ（Compressed OOPs）から64ビットの非圧縮ポインタへと切り替わります。これにより、同一のオブジェクト参照を保持するために約40%多くのメモリが即座に浪費され、結果として32 GBのヒープは31 GBのヒープよりも実質的に使用可能なメモリ領域が大幅に減少します。

Rollover APIと日次インデックスによるオーバーシャーディング対策

固定シャード数で構成された「logstash-YYYY.MM.DD」のような静的日付ベースのインデックスパターンの運用は避けてください。流入量が少ない日は100 MBの極小シャードが乱立し、トラフィック急増日には80 GBもの巨大シャードが発生してしまいます。インデックスライフサイクル管理（ILM）とRollover APIを併用し、「max_primary_shard_size: 50gb」や「max_age: 30d」を設定することで、シャードサイズを均一化しオーバーシャーディングを根本から排除できます。

Luceneセグメントキャッシュと50%ルールの原則

システム全体の物理RAMの50%以上をElasticsearchのJVMヒープに割り当ててはなりません。Luceneはインデックスセグメントファイル、転置インデックス、doc_valuesをメモリ上に保持するため、基盤となるLinux OSのページキャッシュに大きく依存しています。OSキャッシュが不足すると激しいディスク読み取りI/Oが発生し、クエリレイテンシの急増やガベージコレクション（GC）の停止時間の悪化を招きます。

専用Masterノードのクォーラム（定足数）算出式

6ノード以上のクラスタやミッションクリティカルな環境では、専用のMaster適格ノード（node.roles: [master]で構成）を厳密に3台運用してください。これにより、クォーラム算出式 (N / 2) + 1 = 2票を満たしてスプリットブレイン（脳分離状態）を確実に防止でき、Master管理処理のために高コストなストレージやコンピュートリソースを浪費することも防げます。

よくある落とし穴とトラブルシューティング

⚠️UNASSIGNED（未割り当て）シャードによるクラスタのRed / Yellow化

「GET _cluster/allocation/explain」を実行して詳細原因を確認してください。最も多い2大原因は次の通りです：(1) データノードのディスク使用率が85%のローウォーターマークを超過し、Elasticsearchがレプリカシャードを配置できなくなっている、(2) number_of_replicasがデータノードの総数以上（または同数）に設定されている。レプリカ数を削減するか、ストレージを拡張してください。

⚠️ディスク使用率95%（Flood Stage）超過によるクラスタの読み取り専用ロック

いずれかのデータノードが95%のフラッドステージ（flood stage）ウォーターマークに達すると、Elasticsearchは全インデックスに対して自動的に「cluster.blocks.read_only_allow_delete: true」を適用します。不要なインデックスを削除するかディスクを拡張した後、「PUT */_settings」で「{'index.blocks.read_only_allow_delete': null}」を実行して書き込みロックを解除してください。

⚠️JVMヒープ逼迫によるCircuitBreakingException [parent] Data Too Largeエラー

このエラーは、親サーキットブレーカーのメモリ使用量がヒープの95%を超えた場合に発生します。原因としては、オーバーシャーディングによる過剰なセグメント数、textフィールドでの整理されていないfielddataの展開、あるいは大規模な集計（Aggregation）バケットの生成が挙げられます。読み取り専用インデックスに対して「_forcemerge?max_num_segments=1」を実行して小さなインデックスを集約し、アクティブな総シャード数を削減してください。

よくある質問 (FAQ)

Elasticsearchでシャードサイズはどのように計算すればよいですか？▼

プライマリシャードのサイズは、「（1日の取り込みデータ量（GB）×（1 ＋ インデックスオーバーヘッド倍率））÷ プライマリシャード数」で算出されます。本番環境では、「GET _cat/shards?v&h=index,shard,prirep,store」を実行し、doc_valuesやセグメントメタデータを含めた実運用上のディスク使用量を確認・測定してください。

Elasticsearchで推奨される最大シャードサイズはどれくらいですか？▼

公式の推奨上限値は、時系列ログ、メトリクス、セキュリティイベント分析などのワークロードで1シャードあたり最大50 GB、低レイテンシが求められる検索カタログでは20 GB〜30 GBです。65 GBを超えるシャードは、Luceneのセグメントマージによる負荷増大、クラスタのリバランス時間の長期化、スナップショットリストアの著しい遅延を引き起こします。

JVMヒープ1 GBあたり、シャード数はいくつにするべきですか？▼

設定されたJVMヒープ1 GBあたり、厳格に最大20シャード以下を維持してください。標準的な30 GBヒープを割り当てたノードの場合、プライマリおよびレプリカを含めて最大600シャードまで安全にサポートできます。20シャード/GBを超えて運用すると、セグメントメモリのオーバーヘッドによりクラスタ全体の不安定化やOOM（メモリ不足によるクラッシュ）を引き起こす危険性があります。

プライマリシャードとレプリカシャードの違いは何ですか？▼

プライマリシャードは、インデックスされたドキュメントを保持し、書き込み処理が最初に実行される元のパーティションです。レプリカシャードはプライマリシャードの完全な同期的複製であり、ハードウェア障害に対する耐障害性（高可用性）の確保や、複数ノードにまたがる検索スループットのスケーリングを提供します。なお、レプリカシャードが対応するプライマリシャードと同一の物理ノード上に配置されることはありません。

未割り当て（unassigned）シャードによりElasticsearchクラスタがRedステータスになるのはなぜですか？▼

Redステータスは、1つ以上のプライマリシャードがいずれのノードにも割り当てられず、データの一部または全部が利用不可になっている危機的状態を示します。主な原因としては、ディスク使用率が95%のフラッドステージウォーターマークを超えた場合、レプリカが存在しないプライマリシャードを保持していたホストがクラッシュした場合、またはディスク上のLuceneセグメントファイルが破損している場合が挙げられます。「GET _cluster/allocation/explain」を実行して、割り当てをブロックしている正確な原因を特定してください。

関連開発者ツール

全ツール一覧 →
DB接続プール・サイジング計算開発者ツール

商用環境向けのデータベース接続プール計算およびキャパシティプランニングツールです。リトルの法則（Little's Law）、HikariCPのコア飽和計算式、PgBouncerのトランザクション多重化比率に基づき、Kubernetes Podごとの最適プールサイズ算出、スレッドスラッシング防止、キュー待機時間の予測、OOM（メモリ枯渇）クラッシュからのDB保護を正確に実行できます。

ツールを開く→
APIレートリミット計算機開発者ツール

トークンバケットやRPS（秒間リクエスト数）に基づくAPIレートリミットを、ブラウザ上でリアルタイムに試算・可視化できるシミュレーションツールです。

ツールを開く→
抵抗カラーコード計算・判読開発者ツール

IEC 60062規格に準拠し、3・4・5・6本帯の抵抗カラーコードを双方向で瞬時に計算・判読。許容差範囲、温度係数（TCR）ドリフト、E系列の逆算合成、SMD相当コードまで高精度に算出します。

ツールを開く→
RabbitMQキュー容量計算開発者ツール

RabbitMQのキューメモリ消費量とスループットをリアルタイムに試算・可視化できる、完全ブラウザ完結型の高精度サイジングツールです。

ツールを開く→
PostgreSQLメモリ計算機開発者ツール

PostgreSQLのメモリ設定計算およびPGTuneに基づくpostgresql.confパラメータを自動生成。shared_buffers、work_mem、effective_cache_size、max_connectionsを最適化します。

ツールを開く→
RAID容量計算（ZFS対応）開発者ツール

RAID 0/1/5/6/10/50/60およびZFS（RAIDZ1/Z2/Z3）構成の実効容量を十進法TB・二進法TiBで正確に計算。パリティ損失、URE（回復不能読み取りエラー）によるリビルド失敗リスク、再構築所要時間、ドライブベイ配置の可視化に対応した高精度ストレージ設計ツールです。

ツールを開く→