最適なシャードサイジング：クラスターパフォーマンスと管理のバランスを取る

強力な分散検索・分析エンジンであるElasticsearchは、データをノード間で効率的に管理・分散する能力に大きく依存しています。この分散の核となる要素がシャードの概念です。シャードはインデックスのより小さく管理可能な断片であり、そのサイジングと分散の方法は、クラスターのパフォーマンス、スケーラビリティ、管理性に大きな影響を与えます。本記事では、Elasticsearchにおける最適なシャードサイジングを決定するための重要な考慮事項について深く掘り下げ、生のパフォーマンスと運用オーバーヘッドの適切なバランスを見つけるお手伝いをします。

シャードサイジングの理解は、あらゆるElasticsearchデプロイメントにとって極めて重要です。小さすぎるシャードが多すぎると、オーバーヘッドが増加し、ノードリソースやクエリレイテンシに影響を与えます。逆に、大きすぎるシャードが少なすぎると、スケーラビリティが妨げられ、ホットスポットが発生し、リカバリ操作が長引く可能性があります。このガイドでは、シャード割り当てについて十分な情報に基づいた決定を下すために必要な知識と実践的な戦略を提供し、より効率的で堅牢なElasticsearchクラスターの実現を支援します。

Elasticsearchシャードの基本

サイジング戦略に入る前に、基本的な概念を把握することが不可欠です。

インデックス: ドキュメントの集まり。Elasticsearchでは、インデックスは複数のシャードに分割されます。
シャード: 分散の単位。各シャードは自己完結型のLuceneインデックスです。インデックスは複数のシャードを含むことができ、クラスター内の異なるノードに分散されます。
プライマリシャード: インデックスが作成されると、固定数のプライマリシャードが割り当てられます。これらのシャードにデータがインデックス化されます。作成後、プライマリシャードの数は変更できません。ただし、レプリカシャードを追加することは可能です。
レプリカシャード: プライマリシャードのコピーです。冗長性を提供し、読み取りスループットを向上させます。プライマリシャードが失敗した場合、レプリカが昇格してプライマリになることができます。レプリカシャードの数はいつでも変更できます。

シャードがパフォーマンスに与える影響

インデックス作成パフォーマンス: 各シャードはインデックス作成のためにリソースを必要とします。シャードが増えると、リクエストを管理するコーディネイトノードのオーバーヘッドが増加します。ただし、シャードが大きくなりすぎると、単一シャードへのインデックス作成がボトルネックになる可能性があります。
クエリパフォーマンス: 検索リクエストは、関連するすべてのプライマリシャードに分散されます。シャード数が多いと、処理しなければならないリクエスト数が増加し、レイテンシが増加する可能性があります。逆に、非常に大きなシャードは、Luceneがそのシャード内のより多くのデータを処理する必要があるため、検索時間が長くなる可能性があります。
クラスター管理: シャード数が多いと、クラスター状態管理を担当するマスターノードの負荷が増加します。また、シャードの再配置、スナップショット作成、リカバリなどの操作のオーバーヘッドにも影響します。
リソース利用率: 各シャードはメモリとディスクI/Oを消費します。シャードが多すぎるとノードリソースを使い果たし、パフォーマンスの低下やノードの不安定化につながる可能性があります。

シャードサイジングのための主要な考慮事項

「理想的な」シャードサイズは固定値ではなく、特定のワークロード、データ特性、ハードウェアに依存します。ただし、いくつかの要因が意思決定を導くはずです。

1. データ量と増加率

現在のデータサイズ: 現在インデックスにどれだけのデータがありますか？
増加率: データの増加速度はどれくらいですか？これは将来のシャードサイズを予測するのに役立ちます。
データ保持ポリシー: 古いデータを削除する予定はありますか？これはアクティブなデータの有効サイズに影響します。

2. インデックス作成負荷

インデックス作成レート: 1秒あたりにどれだけのドキュメントをインデックス化していますか？
ドキュメントサイズ: 個々のドキュメントの平均サイズはどれくらいですか？
インデックス作成スループット: 現在のシャード構成で、ノードはインデックス作成負荷を処理できますか？

3. クエリパターン

クエリの複雑性: クエリは単純なキーワード検索ですか、それとも複雑な集計ですか？
クエリ頻度: データに対してクエリはどれくらいの頻度で実行されますか？
クエリレイテンシ要件: 許容できる応答時間はどれくらいですか？

4. クラスターのトポロジとリソース

ノード数: クラスターにはいくつのノードがありますか？
ノードハードウェア: CPU、RAM、ディスク（ElasticsearchにはSSDが強く推奨されます）。
ノードあたりのシャード制限: Elasticsearchには、パフォーマンスの問題を防ぐためにノードが保持できるシャードの最大数に関するデフォルトの制限があります。これはcluster.routing.allocation.total_shards_per_node（デフォルトは1000）によって制御されます。実際のシャード数をこの制限を十分に下回ったままにすることが推奨されます。

シャード割り当てのベストプラクティス

1. 目標シャードサイズを目指す

魔法の数字はありませんが、一般的に推奨される目標シャードサイズは10GBから50GBの間です。この範囲は、しばしば適切なバランスを表します。

小さすぎる（< 10GB）: 過剰なオーバーヘッドにつながる可能性があります。各シャードにはメモリフットプリントがあり、マスターノードの負荷に寄与します。何千もの小さなシャードを管理することは、かなりの運用上の負担になります。
大きすぎる（> 50GB）: パフォーマンスの問題を引き起こす可能性があります。セグメントのマージ、リカバリ、再バランス操作に時間がかかります。大きなシャードが失敗した場合、リカバリにかなりの時間がかかる可能性があります。

2. 時系列インデックスを考慮する

時系列データ（ログ、メトリクス、イベント）の場合、時系列インデックスを使用することは標準的で非常に効果的なプラクティスです。これには、特定の期間（例：日次、週次、月次）に対して新しいインデックスを作成することが含まれます。

例: 1つの巨大なインデックスの代わりに、logs-2023.10.26、logs-2023.10.27などを持つ場合があります。
利点: データの管理が容易（Index Lifecycle Management - ILMによる古いインデックスの削除）、クエリが最新データを対象にすることが多いためパフォーマンスが向上、シャードサイズの制御。

3. インデックスライフサイクル管理（ILM）の実装

ILMポリシーを使用すると、年齢、サイズ、またはドキュメント数に基づいてインデックス管理を自動化できます。インデックスのフェーズ（ホット、ウォーム、コールド、削除）を定義し、各フェーズのアクション（レプリカ数の変更、インデックスの縮小、削除など）を指定できます。

ホットフェーズ: インデックスがアクティブに書き込まれ、クエリされています。パフォーマンスを最大化します。
ウォームフェーズ: インデックスへの書き込みは停止したが、まだクエリされています。パフォーマンスの低いハードウェアに移動でき、レプリカ数を減らしたり、縮小したりできます。
コールドフェーズ: アクセス頻度が低い。データをより安価なストレージに移動でき、さらにレプリカを減らしたり、フリーズしたりできます。
削除フェーズ: データは不要になり、削除されます。

4. シャード過多を避ける

シャード過多は、クラスターサイズとデータ量に対してシャードが多すぎる場合に発生します。これは、パフォーマンスの低下と管理上の問題を引き起こす一般的な落とし穴です。

症状: マスターノードでのCPU使用率が高い、クラスター状態の更新が遅い、リカバリ時間が長い、全体的な応答性の低下。
軽減策: 最初からプライマリシャード数を計画します。時系列インデックスの場合、インデックスごとに合理的な数のプライマリシャード（例：1または3）から開始します。レプリカは後でいつでも追加できます。

5. 過剰なインデックス作成を避ける

同様に、不必要に多数のインデックスを作成することは避けてください。各インデックスはオーバーヘッドを追加します。自然なパーティショニングメカニズムがない非時系列データの場合、適切なシャード数を持つ単一のインデックスで十分かどうかを検討してください。

6. `number_of_shards`設定を考慮する

インデックスを作成する際、number_of_shardsパラメータはプライマリシャードの数を定義します。この設定はインデックス作成後に変更できません。

PUT my-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,  // 例: 3つのプライマリシャード
      "number_of_replicas": 1   // 例: 1つのレプリカシャード
    }
  }
}

ヒント: 小さなインデックスやインデックス作成/クエリ負荷が非常に低いインデックスの場合、単一のプライマリシャードで十分な場合があります。より大きくアクティブなインデックスの場合は、3つまたは5つのプライマリシャードを設定すると、初期データ量が厳密に必要でなくても、より良い分散と回復オプションが得られます。トレードオフはオーバーヘッドの増加です。

7. 再バランスと再配置

Elasticsearchはノード間でシャードが均等に分散されるように自動的に再バランスします。しかし、シャードが大きすぎると、これらの操作はリソースを大量に消費し、遅くなる可能性があります。より小さく、より多数のシャードの方が再バランスが速くなることがありますが、これはシャードの管理オーバーヘッドによって相殺されます。

8. クエリパフォーマンスのチューニング

クエリパフォーマンスが低下している場合は、シャード戦略を評価します。以下を検討してください。

シャード数: シャードが多すぎると、コーディネーションのオーバーヘッドが増加する可能性があります。
シャードサイズ: 非常に大きなシャードは、セグメントのマージやシャード内の検索を遅くする可能性があります。
インデックス設計: 適切なマッピングとアナライザーを使用していますか？

最適なシャード数の計算

単一の数式はありませんが、一般的なアプローチは次のとおりです。

インデックスのライフサイクル全体にわたる総データ量を推定します。
目標シャードサイズを決定します（例：30GB）。
必要なプライマリシャード数を計算します: 総データ量 / 目標シャードサイズ。
最も近い整数に切り上げます。これにより、インデックスのnumber_of_shardsが得られます。
- 例: 90GBのデータを予想し、30GBのシャードを目指す場合、90GB / 30GB = 3のプライマリシャードが必要になります。
回復力と分散を考慮に入れます: 重要なインデックスの場合、初期データ量が厳密に必要でなくても、より良い分散と回復オプションを可能にするために、3つまたは5つのプライマリシャードの使用を検討してください。トレードオフはオーバーヘッドの増加です。
控えめに開始します: レプリカの数をプライマリシャードの数（通常は再インデックス化または複雑な回避策が必要）を変更するよりも、簡単に追加できます。確信が持てない場合は、より少ないプライマリシャードから開始し、パフォーマンスを監視してください。

例：ログ分析シナリオ

アプリケーションログをインデックス化していると仮定します。

データ量: 月あたり1TBのログを予想します。
データ保持期間: 30日間ログを保持します。
目標シャードサイズ: 20GBを目指します。
日次インデックス: 日次インデックス（logstash-YYYY.MM.DD）を作成します。各日次インデックスには、約1TB / 30日 ≈ 33GBのデータが含まれます。
インデックスあたりのプライマリシャード数: 20GBの目標と33GBの日次データ量に基づき、プライマリシャードを2つ選択するかもしれません（33GB / 20GB ≈ 1.65、2に切り上げ）。これにより、個々のシャードが目標サイズ内に収まることが保証されます。
レプリカ: 高可用性のために1つのレプリカを決定します。
総シャード数: 30日間の保持期間中、各2つのプライマリと2つのレプリカを持つ30個のインデックスが存在し、常に合計60のプライマリと60のレプリカシャードがアクティブになります。

このアプローチにより、個々のシャードは管理可能になり、古いインデックスを削除するだけで効率的にデータを削除できます。

結論

Elasticsearchにおける最適なシャードサイジングは、継続的なバランスの取り組みです。シャード数、シャードサイズ、インデックス作成負荷、クエリパターン、クラスターリソースの相互作用を理解することで、十分な情報に基づいた意思決定を行うことができます。時系列データには時系列インデックスを優先し、ILMを活用して管理を自動化し、シャード管理の運用オーバーヘッドを常に考慮に入れてください。シャードサイズを10GBから50GBの間に収め、シャード過多を避けることは、しっかりとした出発点です。定期的な監視とパフォーマンスチューニングにより、データが増加してもElasticsearchクラスターが効率的で、スケーラブルで、回復力のある状態を維持することが保証されます。