Elasticsearchクラスターのスケーリング戦略：成長のためのガイド

Elasticsearchは、リアルタイム検索、ロギング、分析機能を提供する数え切れないほどのアプリケーションのバックボーンとなっています。データ量が増加し、クエリ負荷が増大するにつれて、Elasticsearchクラスターは必然的にスケーリングの課題に直面します。クラスターを効果的にスケーリングすることは、パフォーマンスの維持、高可用性の確保、ダウンタイムなしでの将来の成長への対応のために不可欠です。このガイドでは、水平スケーリングと垂直スケーリングの両方に関する実績のある戦略と、ハードウェアおよびインテリジェントなシャード割り当てに関する重要な考慮事項を検討します。

パフォーマンスが低下する前に正しくスケーリングする方法を理解することは、成功し成長するシステムと応答性のないボトルネックとの違いです。容量を拡張するためのコアな方法と、クラスターを堅牢に保つために必要なアーキテクチャ上のベストプラクティスをカバーします。

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

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

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

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

垂直スケーリングを使用する場合：

レイテンシが最優先事項であり、既存のデータセットからより高速なクエリ応答が必要な場合。
新しいノードの追加が不必要な調整オーバーヘッドをもたらす可能性がある、短期間の高いピーク負荷を処理する場合。

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

RAM（メモリ）： これは最も重要なアップグレードであることがよくあります。ElasticsearchはJVMヒープサイズ（一般的にシステム全体のRAMの50％、最大約30〜32GBに設定すべき）に大きく依存しています。より多くのメモリがあれば、より大きなキャッシュ（フィールドデータ、リクエストキャッシュ）とより優れたガベージコレクションパフォーマンスが可能になります。
CPU： 複雑な集計、重いインデックス作成、高いクエリ同時実行性には不可欠です。
ストレージ（ディスクI/O）： より高速なSSDまたはNVMeドライブは、特に重いI/Oワークロードにおいて、インデックス作成のスループットと検索速度を大幅に向上させます。

⚠️ 垂直スケーリングに関する注意： JVMの制限により、最適化された圧縮された通常のオブジェクトポインター（oops）のために、ヒープに約32GBを超える容量を割り当てることはできません。過度の垂直スケーリングは一時的な解決策であることがよくあります。

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

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

水平スケーリングを使用する場合：

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

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

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

スケーリングは単にハードウェアを追加すること以上のものであり、構造化されたインデックスとノードのトポロジが必要です。

ノードの役割と専門化

最新のElasticsearchデプロイメントは、特に大規模なクラスターでは、ノードに専用の役割を割り当てることから大きなメリットを得られます。これにより、重いタスク（インデックス作成など）と重要なタスク（検索の調整など）間のリソース競合を防ぐことができます。

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

シャード割り当て戦略

シャードは、Elasticsearchにおける分散と並列処理の基本的な単位です。不十分なシャード割り当ては、スケーリングのペインポイントの第一の原因です。

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

適切なプライマリシャード数（index.number_of_shards）の選択は重要であり、インデックス作成後には容易に変更できません（インデックスエイリアスまたはリインデックスを使用しない限り）。

シャードが少なすぎる： 検索中の並列処理を制限し、効果的な水平スケーリングを防ぎます。
シャードが多すぎる： マスターノードにオーバーヘッドを引き起こし、不必要にメモリフットプリントを増やし、「小さなシャード問題」の非効率につながります。

ベストプラクティス： プライマリシャードのサイズを10GBから50GBの間で目指します。多くの場合、データノードあたりのCPUコアあたりのプライマリシャード1つが良好な開始点ですが、これはワークロードによって大きく異なります。

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

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

number_of_replicas: 1 を設定すると、各プライマリシャードに1つのコピーがあり、高可用性（HA）を確保します。
レプリカを増やす（例：2にする）と、検索が複数のシャードコピーに同時にヒットできるようになり、読み取りスループットが大幅に向上します。

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はこれを自動的に試みますが、特にマルチゾーンまたはマルチデータセンターのデプロイメントでは、ノード属性（ラックアウェアネスなど）が構成されていることを確認する必要があります。

Cluster Allocation Explainer APIを使用して、シャードが新しいノードに移動しない理由や、ノードが過負荷になっている理由を診断してください。

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

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

ステップ1：監視と診断

変更を加える前に、ボトルネックを診断してください。一般的な指標：

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

ステップ2：即時のリソースニーズへの対応（垂直調整）

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

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

ノードを追加する場合は、次の手順に従ってください。

同等またはそれ以上のハードウェアを備えた新しいデータノードをプロビジョニングします。
正しいマスター対象またはデータの役割で設定します。
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を効果的にスケーリングするには、分散とリソース管理の理解に基づいたプロアクティブな計画が必要です。垂直スケーリングを無制限に続けないでください。負荷を水平に分散させることに焦点を当ててください。

主なポイント：

水平スケーリングを優先する： 継続的な成長と回復力のための最良のパスを提供します。
専用マスターノード： マスターの役割を分離して、クラスター管理を安定させます。
シャードサイジングは永続的： インデックス作成時にプライマリシャードサイズを10GB〜50GBにすることを目指します。
JVMヒープを監視する： ノードあたり約30GBのヒープサイズを超えないようにします。
リインデックスを使用する： 水平スケーリングでプライマリシャード数の変更が必要な場合は、重要なインデックスを再構築します。