Elasticsearch シャードサイジングガイド：パフォーマンスとスケーラビリティのバランス

Elasticsearchは、大量のデータを処理するのに優れた強力な分散型検索・分析エンジンです。しかし、最適なパフォーマンスと安定性を達成するには、データ分散の構造化方法、特にシャードサイジングが重要です。シャードはElasticsearchインデックスの基本構成要素であり、データがどのように分割、複製、クラスターノード全体に分散されるかを決定します。不適切なシャードサイジングは、深刻なパフォーマンスのボトルネック、運用オーバーヘッドの増加、または逆にリソースの未活用を引き起こす可能性があります。

このElasticsearchシャードサイジングガイドでは、初期シャード数を選択し、実際のワークロードメトリクスで検証する実用的な方法を提供します。目標は完璧な数値ではなく、データが成長しても回復可能で、検索可能で、コスト効率の良いシャードレイアウトを実現することです。

Elasticsearchシャードの理解

サイジングに入る前に、シャードとは何か、クラスターアーキテクチャ内でどのように機能するかを理解することが不可欠です。Elasticsearchのインデックスは、1つ以上のプライマリシャードで構成されています。各プライマリシャードは独立したLuceneベースのインデックスであり、データをホストできます。

プライマリシャード vs レプリカシャード

プライマリシャード: 実際のデータを保持します。インデックス作成と検索操作を担当します。インデックスのプライマリシャード数を定義すると、データがクラスター全体にどのように水平分散されるかが決まります。
レプリカシャード: プライマリシャードのコピーです。冗長性（フォールトトレランス）を提供し、プライマリとレプリカの両方のコピーがクエリを処理できるようにすることで検索スループットを向上させます。

シャード数の影響

シャードの総数（プライマリ+レプリカ）は、クラスターのオーバーヘッドに直接影響します。すべてのシャードは、そのステータスとメタデータを追跡するためにメモリ（ヒープスペース）とCPUリソースを必要とします。シャードが多すぎて小さいと、マスターノードに過負荷がかかり、クラスター管理のオーバーヘッドが増加し、個々のシャードが小さくてもパフォーマンスが低下します。

主な制約とサイジングの推奨事項

シャードサイズに単一の「マジックナンバー」はありません。最適なサイズは、データ量、インデックス作成レート、クエリパターンに大きく依存します。ただし、Elasticsearchのドキュメントとコミュニティのベストプラクティスは、いくつかの重要なガイドラインを提供しています。

1. サイズのしきい値：最適なシャードサイズ

最も重要な要素は、単一のシャードに含まれるデータのサイズです。

一般的な目標範囲: 多くの本番クラスターは、プライマリシャードを10GB～50GBの範囲に設定することを目指しています。
大規模シャードの注意: より大きなシャードは、一部の追加専用または低クエリのワークロードで機能する可能性がありますが、リカバリ時間が長くなり、再配置のコストが高くなります。100GB近くまたはそれ以上のシャードに依存する前にテストしてください。

なぜ制限があるのか？ ノードに障害が発生した場合、Elasticsearchはそのノードに保存されているシャードを再割り当て（再配置または再複製）する必要があります。シャードが大きいと、リカバリに必要な時間が大幅に増加し、復元力が低下する期間が長くなります。さらに、Luceneは中程度のサイズのセグメントを管理する方がパフォーマンスが優れています。

2. ドキュメント数のしきい値

サイズが最も重要ですが、特に非常に小さなドキュメントの場合、ドキュメント数も関連します。

シャードあたりの安全なドキュメント数に普遍的なものはありません。数百万の小さなログドキュメントを含むシャードは適切に動作する可能性がありますが、より少ない大きな、高度に分析されたドキュメントを含むシャードはコストがかかる可能性があります。ドキュメント数だけに頼るのではなく、シャードストアサイズとワークロードの動作の両方を追跡してください。

3. クラスターオーバーヘッドとシャード数

リソース消費を効果的に管理するために、ノードあたりのシャード総数を制限します。

古いガイダンスでは、GBあたりのヒープあたりのシャードルールがよく使用されていました。これらは厳格な制限ではなく、大まかな警告サインとして扱ってください。最新のElasticsearchは、古いリリースよりもシャードあたりのヒープオーバーヘッドが低くなっていますが、シャードが多すぎると、クラスター状態の作業、ファイルハンドル、セグメントオーバーヘッド、リカバリの複雑さが依然として増加します。

実用的なシャードサイジング手法

以下の手順を使用して、予想される総データサイズに基づいて、新しいインデックスの適切なプライマリシャード数を計算します。

ステップ1：総インデックスサイズの見積もり

このインデックスが運用期間（例：6ヶ月または1年）にわたって保存すると予想されるデータの総量を決定します。

例: logs-2024 インデックスに2 TBのデータを保存する見込みです。

ステップ2：目標シャードサイズの定義

ガイドラインに基づいて、安全な目標サイズを選択します（例：40GB）。

例: 目標シャードサイズ = 40 GB。

ステップ3：必要なプライマリシャード数の計算

総推定サイズを目標シャードサイズで割ります。常に最も近い整数に切り上げます。

$$\text{プライマリシャード数} = \text{切り上げ} \left( \frac{\text{総インデックスサイズ}}{\text{目標シャードサイズ}} \right)$$

計算例（2 TB = 2048 GB）: $$\text{プライマリシャード数} = \text{切り上げ} \left( \frac{2048 \text{ GB}}{40 \text{ GB}} \right) = \text{切り上げ}(51.2) = 52$$

このシナリオでは、52個のプライマリシャードでインデックスを作成する必要があります。

ステップ4：レプリカ数の決定

復元力と検索ボリュームのニーズに基づいてレプリカ数を決定します。

復元力: number_of_replicas を少なくとも1に設定します（高可用性のため）。
検索パフォーマンス: 検索トラフィックが多い場合は、2つ以上のレプリカを使用します。
例: 標準的なフォールトトレランスのために1つのレプリカを選択します。

最終インデックス設定: 52個のプライマリシャードと1つのレプリカ（合計104シャード）。

ステップ5：ノード間の分散

クラスターにこれらのシャードを効果的にホストするのに十分なノード、ヒープ、ディスク、I/O容量があることを確認します。レプリカがある場合、Elasticsearchは各レプリカをそのプライマリとは異なるノードに配置できる必要があります。

インデックスライフサイクルの管理とサイズ変更

Elasticsearchでは、既存のインデックスの index.number_of_shards を直接変更することはできません。分割、縮小、または再インデックスワークフローを使用できますが、それぞれに要件と運用コストがあります。

インデックスライフサイクル管理（ILM）の役割

時系列データ（ログ、メトリクス）の場合、ベストプラクティスはインデックスライフサイクル管理（ILM）とロールオーバー機能を活用することです。

管理が難しい大規模なインデックスを1つ作成する代わりに、テンプレートを指すロールオーバーエイリアスを作成します。

ホットフェーズ: データは現在のアクティブなインデックスに書き込まれます。ILMは、サイズまたは経過時間に基づいてこのインデックスを監視します（例：40GBに達したらロールオーバー）。
ロールオーバー: しきい値に達すると、Elasticsearchは自動的にテンプレートに基づいて新しいインデックス（計算されたプライマリシャード数で）を作成し、エイリアスを新しいインデックスに切り替えます。古いインデックスは別のフェーズ（ウォーム/コールド）に移行します。

このアプローチにより、データライフサイクル全体にわたって一貫したサイズで最適にパフォーマンスを発揮するシャードを維持できます。

再シャーディングが必要な場合（高度）

予期しないデータパターンにより、既存のインデックスが50GBの推奨を大幅に超えて成長した場合、Reindex APIを使用してシャード分散を修正する必要があります。

修正された（最適な）シャード設定で新しいインデックスを作成します。
Reindex APIを使用して、サイズが適切でない古いインデックスから新しいインデックスにすべてのデータをコピーします。
エイリアスを更新して新しいインデックスを指すようにします。
古いインデックスを削除します。

再インデックスに関する警告: 再インデックスはリソースを大量に消費する操作です。トラフィックが少ない時間帯にスケジュールし、インデックス作成とコピーの同時負荷を処理するのに十分なクラスターリソースが必要です。

ベストプラクティスのまとめ

領域	ベストプラクティス / ガイドライン
個々のシャードサイズ	プライマリシャードを10GB～50GB（最大100GB）に保ちます。
ドキュメント数	ドキュメント数を二次的なシグナルとして監視しますが、クエリとインデックス作成のメトリクスで検証します。
クラスターオーバーヘッド	ヒーププレッシャー、クラスター状態の更新、リカバリが健全な状態を保てるように、シャード数を十分に低く保ちます。
インデックス管理	時系列データにはインデックスライフサイクル管理（ILM）とロールオーバーを使用して、継続的な最適なサイジングを確保します。
サイズ変更	ライブインデックスのプライマリシャード数を変更しようとしないでください。Reindex APIを使用して、適切なサイズの新しいインデックスにデータを移行します。

目標シャードサイズから始め、予想データ量からプライマリシャード数を計算し、ロードテストと本番メトリクスで検証します。時系列データの場合、ILMロールオーバーは通常、手動による介入を必要とせずにシャードサイズを予測可能に保つ最もクリーンな方法です。