Elasticsearchクラスタの成長に合わせたスケーリング戦略ガイド

Elasticsearchクラスタのスケーリングは、検索が遅くなったり、インデックスキューが滞留したり、ディスクが予想よりも早くいっぱいになり始めたりすると緊急課題になります。データ量とクエリ負荷が増大するにつれて、既存のノードにリソースを追加するのか、ノードを追加するのか、シャード戦略を変更するのか、ホットインデックスを再設計するのかを判断する必要があります。

このガイドでは、垂直スケーリングと水平スケーリング、ノードロール、シャードサイジング、そして推測に頼らずにクラスタを成長させるための実践的な手順について説明します。

Elasticsearchスケーリングの基礎を理解する

Elasticsearchクラスタのスケーリングには、主に垂直スケーリング（スケールアップ）と水平スケーリング（スケールアウト）の2つの戦略があります。最適な戦略は、多くの場合、ワークロードの特性によって決まる、両方の慎重なバランスを伴います。

垂直スケーリング（スケールアップ）

垂直スケーリングは、既存のノードのリソースを増やすことを意味します。これは最も単純なアプローチですが、物理的な限界にすぐに達します。

垂直スケーリングを使用するタイミング:

レイテンシが主な関心事であり、既存のデータセットからのより高速なクエリ応答が必要な場合。
新しいノードを追加してリバランスするよりも、短期的な負荷を迅速に軽減する必要がある場合。

主なリソースアップグレード:

RAM（メモリ）: ElasticsearchはJVMヒープと大きなOSファイルシステムキャッシュを必要とします。一般的な開始点は、圧縮通常オブジェクトポインタのしきい値（JVMによって約26〜32GB）を下回りつつ、ヒープをシステムRAMの約50％に設定することです。
CPU: 複雑な集計、大量のインデックス作成、および高いクエリ同時実行性に必要です。
ストレージ（ディスクI/O）: より高速なSSDまたはNVMeドライブは、特にI/O負荷の高いワークロードにおいて、インデックススループットと検索速度を大幅に向上させます。

垂直スケーリングに関する警告: 非常に大きなJVMヒープは、圧縮通常オブジェクトポインタの利点を失い、ガベージコレクションの一時停止が長くなる可能性があります。余分なRAMはファイルシステムキャッシュに依然として役立ちますが、ヒープサイズを増やすことは長期的なスケーリング計画ではありません。

水平スケーリング（スケールアウト）

水平スケーリングは、クラスタにノードを追加することを意味します。これにより、データとクエリ負荷が複数のマシンに分散され、ほぼ線形のスケーラビリティと高可用性が実現します。

水平スケーリングを使用するタイミング:

データ量が既存のノードの容量を超えた場合。
全体的なインデックススループットまたはクエリ同時実行性を向上させる必要がある場合。
長期的で持続可能な成長のための主要な戦略として。

水平スケーリングは、新しいデータノードを追加することで実現されます。コーディネーティングノードも追加できますが、通常はデータノードの拡張が容量の成長を促進します。

スケーラビリティのためのアーキテクチャのベストプラクティス

スケーリングは単にハードウェアを追加するだけではありません。適切に構造化されたインデックスとノードトポロジーが必要です。

ノードロールと特化

最新のElasticsearchデプロイメントでは、特に大規模なクラスタにおいて、ノードに専用のロールを割り当てることが非常に有益です。これにより、負荷の高いタスク（インデックス作成など）と重要なタスク（検索の調整など）の間のリソース競合を防ぎます。

ノードロール	主な責任	ベストプラクティスの考慮事項
マスターノード	クラスタ状態の管理、安定性。	3台または5台の専用ノードセット。データやインジェストリクエストを処理しないでください。
データノード	データの保存、インデックス作成、検索。	データ量と負荷に基づいて積極的にスケールします。
インジェストノード	インデックス作成前のドキュメントの前処理（インジェストパイプラインを使用）。	CPU負荷の高い前処理をデータノードからオフロードします。
コーディネーティングノード	大規模な検索リクエストの処理、データノードからの結果の収集。	検索リクエストが複雑になったり、調整のオーバーヘッドでデータノードに頻繁に過負荷がかかったりする場合に追加します。

シャード割り当て戦略

シャードは、Elasticsearchにおける分散と並列処理の基本単位です。不適切なシャード割り当ては、スケーリングにおける問題点の最大の原因です。

1. プライマリシャード数の最適化

適切なプライマリシャード数（index.number_of_shards）の選択は重要であり、インデックス作成後は簡単に変更できません（インデックスエイリアスや再インデックスを使用する場合を除く）。

シャードが少なすぎる: 検索中の並列処理が制限され、効果的な水平スケーリングが妨げられます。
シャードが多すぎる: クラスタ状態のオーバーヘッドが増加し、メモリ使用量が増加し、調整コストが有用な作業を上回る「小さなシャード」問題が発生します。

ベストプラクティス: 多くの時系列およびログワークロードでは、シャードサイズを数十ギガバイト、多くの場合約10GB〜50GBを目標にします。これを開始範囲として扱い、独自のインデックスレート、保持期間、クエリパターンでテストしてください。

2. 高可用性と読み取りスループットのためのレプリカシャード

レプリカシャード（index.number_of_replicas）は冗長性を提供し、読み取り容量を増加させます。

number_of_replicas: 1を設定すると、すべてのプライマリシャードに1つのコピーが存在し、高可用性（HA）が保証されます。
レプリカを増やすと、検索がプライマリコピーまたはレプリカコピーによって処理される可能性があるため、読み取り容量を向上させることができますが、ストレージ使用量とインデックス作成作業も増加します。

HA設定の例: 10個のプライマリシャードがあり、number_of_replicas: 1を設定した場合、クラスタはノード全体に分散された少なくとも20個のシャードコピー（10プライマリ + 10レプリカ）を必要とします。

PUT /my_growing_index
{
  "settings": {
    "index.number_of_shards": 20,
    "index.number_of_replicas": 1 
  }
}

アウェアネスによるホットスポットの防止

新しいノードを追加するときは、シャードが障害ドメイン全体に分散されていることを確認してください。Elasticsearchは自動的にリバランスしますが、ゾーンまたはラックアウェアネスは、ノード属性と割り当てアウェアネス設定を構成した場合にのみ機能します。

クラスタ割り当て説明APIを使用して、シャードが新しいノードに移動しない理由や、ノードが過負荷になっている理由を診断してください。

実践的なスケーリング手順：成長への対応

クラスタのパフォーマンスが低下した場合（JVMヒープ圧力の高さ、クエリの遅さ、インデックス作成の遅さ）、次の手順を順に実行します。

ステップ1：監視と診断

変更を加える前に、ボトルネックを診断します。一般的な指標は次のとおりです。

CPU高/空きメモリ低: 計算またはメモリの不足を示します（垂直スケーリングの必要性の可能性）。
過剰なディスクキューの長さ: I/Oボトルネックを示します（より高速なディスクまたはノード追加が必要）。
検索レイテンシのスパイク: 多くの場合、キャッシュの不足またはシャード/レプリカの数が少なすぎることが原因です（より多くのメモリまたは水平スケーリングが必要）。

ステップ2：当面のリソースニーズに対処する（垂直調整）

メモリプレッシャーが高い場合は、安全な制限内（最大32GB）でJVMヒープサイズを増やし、OSファイルシステムキャッシュに十分なRAMが利用可能であることを確認します。

ステップ3：スケールアウト（水平拡張）

ノードを追加する場合は、次の手順に従います。

同一または優れたハードウェアを備えた新しいデータノードをプロビジョニングします。
正しいロールで構成します。容量の成長には、通常、デプロイメントに応じてdata_hot、data_content、またはdataなどのデータロールを意味します。
discovery.seed_hostsを使用して、それらを既存のクラスタにポイントします。
新しいノードが参加すると、Elasticsearchは自動的に既存のシャードのリバランスを開始し、新しい容量を活用します。

ステップ4：将来を見据えたインデックス作成（再インデックス）

既存のインデックスのシャード数が最適でない場合、新しいノードを完全に活用できません。それらを再構築する必要があります。

新しいインデックステンプレートを作成するか、Create Index APIを使用して、必要なシャード数とレプリカ数を指定します。
Reindex APIを使用して、サイズが適切でない古いインデックスから新しいインデックスにデータを移行します。
移行が完了したら、エイリアスを使用してトラフィックを切り替えます。

再インデックスコマンドの例:

POST _reindex
{
  "source": {
    "index": "old_index_bad_shards"
  },
  "dest": {
    "index": "new_index_optimized_shards"
  }
}

ベストプラクティスチェックリスト

Elasticsearchのスケーリングは、最初に監視し、一度に1つの変数を変更し、シャードレイアウトを成長パターンに合わせて維持する場合に最も効果的に機能します。

重要なポイント:

水平スケーリングを優先する: 継続的な成長と回復力のための最良の道を提供します。
専用マスターノード: マスターロールを分離することで、クラスタ管理を安定させます。
シャードサイジングは永続的: インデックス作成時に、プライマリシャードサイズを10GB〜50GBに目標設定します。
JVMヒープを監視する: JVMの圧縮ポインタしきい値を下回るヒープを維持し、OSキャッシュに十分なRAMを残します。
再インデックスを使用する: スケールアウト時にプライマリシャード数の変更が必要な場合、重要なインデックスを再構築します。