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

Elasticsearchは、膨大な量のデータを処理するのに優れている強力な分散検索・分析エンジンです。しかし、最適なパフォーマンスと安定性を達成するには、データの分散構造、特にシャードサイズ設定が大きく影響します。

シャードはElasticsearchインデックスの基本的な構成要素であり、データのパーティション分割、レプリケーション、クラスターノード間での分散方法を決定します。不適切なシャードサイズ設定は、深刻なパフォーマンスのボトルネック、運用オーバーヘッドの増加、あるいは逆にリソースの未活用につながる可能性があります。

本ガイドでは、Elasticsearchクラスター内で最適なシャードサイズを決定するための実践的なフレームワークを提供します。クエリパフォーマンス、インデックス作成スループット、クラスターの回復力、リソース消費の間の重要なトレードオフを探り、特定のワークロードに対して完璧なバランスを見つけるお手伝いをします。

Elasticsearchシャードの理解

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

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

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

シャード数の影響

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

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

シャードサイズに「魔法の数字」は存在しません。最適なサイズは、データ量、インデックス作成レート、クエリパターンに大きく依存します。しかし、Elasticsearchのドキュメントとコミュニティのベストプラクティスは、いくつかの重要な指針を提供しています。

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

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

推奨最大サイズ: 一般的な合意およびベストプラクティスでは、個々のプライマリシャードを10GBから50GBの間に保つことが推奨されます。
絶対最大: 技術的には可能ですが、シャードあたり100GBを超えることは、リカバリ操作、インデックス作成パフォーマンス、クラスターの安定性に負担をかけるため、強く推奨されません。

制限の理由: ノードが失敗した場合、Elasticsearchはそのノードに保存されているシャードを再割り当て（再配置または再レプリケート）する必要があります。大きなシャードはリカバリにかかる時間を大幅に増加させ、回復力が低下する期間を長引かせます。さらに、Luceneは中サイズのセグメントを管理する際にパフォーマンスが向上します。

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

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

推奨ドキュメント範囲: シャードあたり10万から500万ドキュメントを含むことを目指します。

ドキュメントが極端に小さい場合（例：数百バイト）、ドキュメント数の推奨値に達する前にサイズ制限（50GB）に達する可能性があります。逆に、ドキュメントが非常に大きい場合（例：マルチメガバイトのJSONブロブ）、サイズ制限を下回ったままドキュメント数の上限にすぐに達する可能性があります。

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

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

ヒープあたりのシャード数: 一般的なガイドラインでは、クラスターがデータノードに割り当てられたヒープ領域の1GBあたり約20シャードを使用するように、シャードの総数（プライマリ + レプリカ）を保つことを推奨しています。

計算例: データノードに30GBのヒープが割り当てられている場合：

$$\text{30 GB} \times \text{20 シャード/GB} = \text{合計600シャード}$$

インデックスに対して100のプライマリシャードが必要な場合、この比率に従って合計オーバーヘッドを管理できるだけの十分なノードがクラスターにあることを確認する必要があります。

実用的なシャードサイズ設定手法

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

ステップ 1: インデックスの合計サイズの推定

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

例: logs-2024インデックス用に2TBのデータを格納すると予測します。

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

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

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

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

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

$$\text{プライマリシャード数} = \text{Ceiling} \left( \frac{\text{インデックス合計サイズ}}{\text{目標シャードサイズ}} \right)$$

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

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

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

レジリエンスと検索ボリュームのニーズに基づいてレプリカ数を決定します。

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

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

ステップ 5: ノードへの分散

クラスターに、これらのシャードを効果的にホストするのに十分なノード（および十分なヒープ領域）があり、20シャード/GBのヒープルールを維持していることを確認します。

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

Elasticsearchは、既存の空でないインデックスのプライマリシャード数を変更する（リサイズする）ことをサポートしていません。これは、初期設計中に覚えておくべき重要な制限事項です。

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

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

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

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

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

再シャード化が必要な場合（上級）

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

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

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

ベストプラクティスの要約

エリア	ベストプラクティス / ガイドライン
個々のシャードサイズ	プライマリシャードを10GBから50GB（最大100GB）に保つ。
ドキュメント数	シャードあたり10万〜500万ドキュメントを目指す（サイズに次ぐ）。
クラスターオーバーヘッド	データノードのヒープの1GBあたり約20シャードになるように、シャードの総数（プライマリ + レプリカ）を制限する。
インデックス管理	時系列データには、継続的に最適なサイズ設定を保証するためにインデックスライフサイクル管理 (ILM)とロールオーバーを使用する。
リサイズ	ライブインデックスのプライマリシャード数を変更しようとしない。正しくサイズ設定された新しいインデックスにデータを移行するにはReindex APIを使用する。

これらのサイズガイドラインを遵守し、継続的な管理のためにILMを活用することで、Elasticsearchクラスターがパフォーマンス、スケーラビリティ、および運用上の障害に対する回復力を維持できるようにすることができます。