Elasticsearch のような分散システムは非常に複雑になる可能性があり、パフォーマンスと安定性に影響を与える要因が多数あります。シャードはElasticsearch の最も基本的な概念の 1 つであり、その仕組みを理解することで Elasticsearch クラスターを効果的に管理できるようになります。

この記事では、プライマリ シャードとレプリカ シャードとは何か、それらが Elasticsearch クラスターに与える影響、さまざまな需要に合わせてそれらを調整するためのツールについて説明します。

破片を理解する

Elasticsearch インデックス内のデータは膨大な量にまで増大する可能性があります。管理しやすいように、すべてのデータはインデックスに保存され、インデックスはいくつかのシャードに分割されます。各 Elasticsearch シャードは Apache Lucene インデックスであり、個々の Lucene インデックスには Elasticsearch インデックス内のドキュメントのサブセットが含まれています。このようにインデックスを分割すると、リソースの使用量を制御できます。Apache Lucene インデックスには、2,147,483,519 (2³¹ - 129) ドキュメントの制限があります。

場合によっては、再バランス調整のためにインデックスをノード間で移動する必要があります。このプロセスは時間とリソースの両方を大量に消費する可能性があるため、インデックスが大きくなりすぎないようにする必要があります。これにより、回復時間を管理しやすい状態に保つことができます。さらに、インデックスは常に結合する必要がある Lucene セグメントで構成されているため、セグメントが大きくなりすぎないことが重要です。これらの理由から、Elasticsearch はインデックス データをプライマリ シャードと呼ばれるより小さく管理しやすいチャンクに分割し、複数のマシン間でより簡単に分散できるようにします。レプリカシャードは、対応するプライマリ シャードの正確なコピーであり、その機能についてはこの記事の後半で説明します。

適切な数のシャードを持つことはパフォーマンスにとって重要です。したがって、事前に計画を立てるのが賢明です。クエリが異なるシャード間で並列に実行されると、各シャードが異なるノードに配置され、クラスター内に十分なノードがある場合に限り、単一のシャードで構成されたインデックスよりも高速に実行されます。ただし同時に、シャードはインデックス化されたデータとクラスター メタデータの両方に関して、メモリとディスク領域を消費します。シャードが多すぎると（オーバーシャーディングとも呼ばれます）、クエリ、インデックス要求、および管理操作が遅くなる可能性があるため、適切なバランスを維持することが重要です。

プライマリ シャードの数は、特定のインデックス インスタンスのインデックス作成時に定義されます。後でプライマリ シャードの数を変更する必要がある場合は、サイズ変更 API を使用できます (分割(プライマリ シャードを増やす)、縮小(プライマリ シャードを減らす)、または複製(レプリカの新しい設定でプライマリ シャードの数は同じ))。これらの操作は、Lucene セグメントをコピーし、すべてのドキュメントの完全な再インデックスを回避します。インデックスを作成するときに、インデックスの設定としてプライマリ シャードとレプリカ シャードの数を設定できます。

(シャードまたはレプリカの数を指定しない場合、Elasticsearch 7.0 以降、両方のデフォルト値は 1 になります)。理想的なシャードの数は、インデックス内のデータ量に基づいて決定する必要があります。一般的に、最適なシャードは 10 ～ 50 GB のデータを保持し、シャードあたりのドキュメント数は 2 億未満である必要があります。たとえば、1 日に約 300 GB のアプリケーション ログが蓄積されると予想される場合、それらをホストするのに十分な数のノードがあれば、そのインデックスに約 10 個のシャードを持つことが妥当です。

シャードは、その存続期間中に、次のようなさまざまな状態を経る可能性があります。

• 初期化中:シャードが使用される前の初期状態。

• 開始済み:シャードがアクティブでリクエストを受信できる状態。

• 再配置中:シャードが別のノードに移動されている途中に発生する状態。これは、たとえば、ノードのディスク容量が不足している場合など、特定の状況下では必要になることがあります。

• 未割り当て:割り当てに失敗したシャードの状態。これが発生すると理由が提供されます。たとえば、シャードをホストしているノードがクラスター内になくなった場合(NODE_LEFT) 、または閉じたインデックスに復元された場合(EXISTING_INDEX_RESTORED) などです。

すべてのシャード、その状態、およびその他のメタデータを表示するには、次のリクエストを使用できます。

特定のインデックスのシャードを表示するには、URL にインデックスの名前を追加します (例: sensor)。

このコマンドは、次の例のような出力を生成します。デフォルトでは、表示される列にはインデックスの名前、名前（つまりシャードの数、プライマリ シャードかレプリカか、シャードの状態、ドキュメント数、ディスク上のサイズ、シャードが配置されているノードの IP アドレスとノード ID が表示されます。

レプリカを理解する

各シャードにはデータのコピーが 1 つ含まれますが、インデックスにはシャードの複数のコピーが含まれる場合があります。したがって、シャードには、プライマリ シャードとコピー、またはレプリカの 2 種類があります。プライマリ シャードの各レプリカは常に異なるノードに配置されるため、ノード障害が発生した場合でもデータの高可用性が確保されます。冗長性とデータ損失やダウンタイムの防止の役割に加えて、レプリカはクエリをプライマリ シャードと並行して処理できるため、検索パフォーマンスが向上し、処理速度が向上します。

プライマリ シャードとレプリカ シャードの動作にはいくつかの重要な違いがあります。どちらもクエリを処理できますが、インデックスリクエスト（つまりインデックスにデータを追加するなどの処理は、レプリカ シャードに複製される前に、まずプライマリ シャードを通過する必要があります。前述のように、プライマリ シャードが使用できなくなった場合 (たとえば、ノードの切断やハードウェア障害などにより)、レプリカが昇格してその役割を引き継ぎます。

レプリカはノード障害の際に役立ちますが、インデックス作成時にメモリ、ディスク容量、計算能力を消費するため、レプリカを多くしすぎないことが重要です。プライマリ シャードとレプリカのもう 1 つの違いは、インデックスの作成後はプライマリ シャードの数を変更できないのに対し、レプリカの数はインデックス設定を更新することでいつでも動的に変更できることです。

レプリカに関して考慮すべきもう 1 つの要素は、利用可能なノードの数です。同じノードに同じデータのコピーが 2 つあると、ノードに障害が発生した場合に保護が提供されないため、レプリカは常にプライマリ シャードとは異なるノードに配置されます。その結果、システムがn 個のレプリカをサポートするには、クラスター内に少なくともn + 1 個のノードが必要になります。たとえば、クラスター内に 2 つのノードがあり、インデックスが 6 つのレプリカで構成されている場合、割り当てられるレプリカは 1 つだけです。一方、7 つのノードを持つシステムは、1 つのプライマリ シャードと 6 つのレプリカを完全に処理できます。

シャードとレプリカの最適化

プライマリ シャードとレプリカ シャードの適切なバランスを持つインデックスが作成された後でも、インデックスの周囲のダイナミクスは時間の経過とともに変化するため、これらを監視する必要があります。たとえば、時系列データを扱う場合、最近のデータを持つインデックスは、一般的に古いデータを持つインデックスよりもアクティブになります。これらのインデックスを調整しないと、要件が大きく異なるにもかかわらず、すべて同じ量のリソースを消費することになります。

ロールオーバー インデックス API を使用すると、新しいインデックスと古いインデックスを分離できます。特定のしきい値（ディスク上のインデックスのサイズ、ドキュメントの数、または年齢）に達すると、新しいインデックスを自動的に作成するように設定できます。この API は、シャードのサイズを制御するのにも役立ちます。インデックス作成後はシャードの数を簡単に変更できないため、ロールオーバー条件が満たされない限り、シャードにはデータが蓄積され続けます。アクセス頻度が低い古いインデックスの場合、インデックスの縮小と強制マージは、メモリとディスクのフットプリントを削減する 2 つの異なる方法です。前者はインデックス内のシャードの数を減らし、後者は Lucene セグメントの数を減らし、削除されたドキュメントによって使用されていたスペースを解放します。

Elasticsearchの基盤となるプライマリシャードとレプリカシャード

Elasticsearch は、膨大な量のデータのための分散ストレージ、検索、分析プラットフォームとして高い評価を得ています。しかし、このような規模で事業を展開する場合、必然的に課題が生じます。そのため、プライマリ シャードとレプリカ シャードの仕組みを理解することは、Elasticsearch にとって非常に重要かつ基本的なことであり、プラットフォームの信頼性とパフォーマンスを最適化するのに役立ちます。

これらがどのように機能し、どのように最適化するかを知ることは、より堅牢でパフォーマンスの高い Elasticsearch クラスターを実現するために重要です。クエリ応答が遅くなったり、頻繁に停止したりする場合は、この知識がこれらの障害を克服する鍵となる可能性があります。

クラスター、ノード、シャード、シャードのサイズ設定方法、シャードの割り当てと回復の詳細については、Elasticsearch の公式ドキュメントを参照してください。

このトピックは、 Elastic コミュニティ YouTube チャンネルの入門コースとしてもご利用いただけます。

最後に、ノード、シャード、レプリカについて心配したくない場合は、 Elastic Cloud Serverless を試してみてください。この Elastic Cloud オファリングは Elastic によって完全に管理され、ワークロードに合わせて自動的に拡張されます。無料トライアルを利用すると、サーバーレス アプローチのその他の利点を理解するのに役立ちます。

システムの信頼性を測る優れたテスト

優れたテストとは、IT システムの作成および保守のプロセスに関わるすべての人の信頼を高めるテストです。テストは、クールであったり、高速であったり、コード カバレッジを人為的に増やしたりするためのものではありません。テストは次のことを確認する上で重要な役割を果たします。

• 私たちが提供したいものは、本番環境で機能するようになります。

• システムは要件と契約を満たしています。

• 将来的には後退は起こりません。

• 開発者 (および関係する他のチーム メンバー) は、自分たちが作成したものが機能すると確信しています。

もちろん、これはテストがクールで高速でなかったり、コード カバレッジを増加できなかったりすることを意味するものではありません。テスト スイートをより速く実行できればできるほど、良い結果が得られます。テスト スイートの全体的な期間を短縮することを目指す場合、自動テストによって得られる信頼性、保守性、および自信を犠牲にすべきではありません。

優れた自動テストにより、さまざまなチーム メンバーの自信が向上します。

• 開発者: 開発者は、自分が行っている作業が機能することを確認できます (作業中のコードが自分のマシンから送信される前でも)。

• 品質保証チーム: 手動でテストする量が少なくなります。

• システム オペレーターと SRE: システムの導入と保守が容易になるため、安心できます。

最後になりましたが、システムのアーキテクチャについてです。私たちは、システムが整理され、保守が容易で、アーキテクチャがクリーンで目的を果たしている場合を好みます。しかし、時には「この方がテストしやすい」という言い訳のために、あまりにも多くのものを犠牲にしているアーキテクチャを目にすることがあります。テストが非常に容易であることは何も悪いことではありません。システムが、その存在を正当化するニーズに応えるのではなく、テストができるように主に書かれている場合にのみ、尻尾が犬を振るという状況が発生します。

2種類のテスト: モックと依存関係

テストを確認する方法、および分類する方法は数多くあります。この投稿では、テストを分割する際の 1 つの側面、つまりモック (またはスタブ、フェイクなど) の使用と実際の依存関係の使用のみに焦点を当てます。私たちの場合、依存関係は Elasticsearch です。

モックを使用したテストは、外部依存関係を開始する必要がなく、すべてがメモリ内でのみ行われるため、非常に高速です。自動テストにおけるモックとは、実際の依存関係を使用せずにプログラムの一部をテストするために、実際のオブジェクトの代わりに偽のオブジェクトを使用することです。これが、それらが必要な理由であり、高速検出ネットテストでそれらが優れている理由です。入力の検証。たとえば、リクエスト内の負の数値が許可されていないことを確認するためだけに、データベースを起動して呼び出す必要はありません。

ただし、モックを導入すると、次のようないくつかの影響が生じます。

• すべてをいつでも簡単にモックできるわけではないので、モックはシステムのアーキテクチャに影響を与えます (時には大きな影響があり、時にはそれほど大きくない影響もあります)。

• モック上で実行されるテストは高速かもしれませんが、模倣するシステムを詳細に反映するモックは通常無料では提供されないため、そのようなテストの開発にはかなり時間がかかります。システムの仕組みを知っている人が、適切な方法でモックを作成する必要があります。この知識は、実際の経験やドキュメントの学習などから得られます。

• モックは維持される必要があります。システムが外部の依存関係に依存していて、この依存関係をアップグレードする必要がある場合、依存関係を模倣するモックも、破壊的変更、ドキュメント化された変更、ドキュメント化されていない変更（これもシステムに影響を与える可能性があります）をすべて反映して更新されるようにする必要があります。これは、依存関係をアップグレードしたいが、(モックのみを使用した) テスト スイートではテストされたすべてのケースが確実に機能するという確信が得られない場合に特に困難になります。

• モックではなくシステムの開発とテストに努力が向けられるようにするには、規律が必要です。

これらの理由から、多くの人は正反対の方向に進むことを主張しています。つまり、モック (またはスタブなど) を決して使用せず、実際の依存関係のみに依存するということです。このアプローチは、デモや、システムが小さく、膨大なカバレッジを生成するテスト ケースが少数しかない場合に非常にうまく機能します。このようなテストには、統合テスト (大まかに言うと、システムの一部を実際の依存関係に対してチェックする) やエンドツーエンド テスト (実際の依存関係をすべて同時に使用し、システムの動作をすべてのエンドでチェックしながら、システムが使用可能かつ成功であると定義するユーザー ワークフローを再生する) などがあります。このアプローチを使用することの明らかな利点は、依存関係に関する想定と、それらを作業中のシステムにどのように統合するかについても (多くの場合は意図せずに) 検証できることです。

ただし、テストで実際の依存関係のみを使用する場合は、次の点を考慮する必要があります。

• 一部のテスト シナリオでは、実際の依存関係は必要ありません (例: リクエストの静的不変条件を検証する場合)。

• このようなテストは通常、フィードバックを待つのに時間がかかりすぎるため、開発者のマシンでスイート全体で実行されることはありません。

• CI マシンではより多くのリソースが必要となり、時間とリソースを無駄にしないように調整するのにさらに時間がかかる可能性があります。

• テストデータを使用して依存関係を初期化するのは簡単ではないかもしれません。

• 実際の依存関係を持つテストは、大規模なリファクタリング、移行、または依存関係のアップグレードの前にコードを封鎖するのに最適です。

• これらは不透明なテストである可能性が高く、つまり、テスト対象のシステムの内部については詳細に説明されず、結果に注意が払われます。

スイートスポット：両方のテストを使用する

システムを 1 種類のテストだけでテストするのではなく、適切な場合には両方の種類のテストを活用し、両方のテストの使用率を向上させることができます。

• モックベースのテストの方がはるかに高速なので、最初にモックベースのテストを実行し、すべてが成功した場合にのみ、その後でより遅い依存関係テストを実行します。

• 外部依存関係が実際には必要のないシナリオでは、モックを選択します。モックに時間がかかりすぎる場合は、そのためだけにコードを大幅に変更し、外部依存関係に依存します。

• 意味がある限り、両方のアプローチを使用してコードをテストしても問題はありません。

SystemUnderTestの例

次のセクションでは、ここにある例を使用します。これは Java 21 で記述された小さなデモ アプリケーションで、ビルド ツールとして Maven を使用し、Elasticsearch クライアントに依存し、Elasticsearch の最新の追加機能であるES|QL (Elastic の新しい手続き型クエリ言語) を使用しています。Java がプログラミング言語でない場合でも、これから説明する概念を理解し、それを自分のスタックに適用すれば問題ありません。実際のコード例を使用すると、特定の事柄を説明しやすくなります。

BookSearcherは、データの検索と分析（この場合は書籍）の処理に役立ちます（以前の投稿の 1 つで示したように）。

• 唯一の依存関係として、バージョン8.15.xの Elasticsearch が必要です ( isCompatibleWithBackend()を参照)。たとえば、コードに前方互換性があるかどうか不明であり、後方互換性がないことは確実であるためです。運用中の Elasticsearch を新しいバージョンにアップグレードする前に、まずテストでそれをアップグレードして、テスト対象システムの動作が同じままであることを確認します。

• これを使用して、特定の年に出版された書籍の数を検索できます ( numberOfBooksPublishedInYear参照)。

• また、データセットを分析して、特定の 2 年間に最も多く出版された 20 人の著者を見つける必要がある場合にも、これを使用できます ( mostPublishedAuthorsInYears参照)。

まずはモックでテストする

テストで使用するモックを作成するには、Java エコシステムで非常に人気のあるモック ライブラリであるMockito を使用します。

各テストの前にモックをリセットするには、次のように開始します。

前に述べたように、モックを使用してすべてを簡単にテストできるわけではありません。しかし、できること（そしておそらくそうすべきこと）もあります。現時点では Elasticsearch のサポートされているバージョンは8.15.xであることを確認してみましょう (将来的には、システムが将来のバージョンと互換性があることが確認されたら、範囲を拡張する可能性があります)。

同様に (単に異なるマイナー バージョンを返すことによって)、 BookSearcherが8.16.xとまだ動作しないことを確認できます。これは、互換性があるかどうかわからないためです。

ここで、実際の Elasticsearch に対してテストするときに同様のことを実現する方法を見てみましょう。このため、 Testcontainers の Elasticsearch モジュールを使用します。このモジュールの要件は 1 つだけで、Docker コンテナーを実行するため、Docker にアクセスする必要があります。ある角度から見ると、Testcontainers は単に Docker コンテナを操作する方法に過ぎませんが、Docker Desktop (または同様のもの)、CLI、またはスクリプトで操作する代わりに、使い慣れたプログラミング言語でニーズを表現できます。これにより、イメージの取得、コンテナの起動、テスト後のガベージコレクション、ファイルのコピー、コマンドの実行、ログの調査などがテスト コードから直接実行できるようになります。

スタブは次のようになります。

この例では、 Testcontainers の JUnit 統合を@Testcontainersおよび@Containerと利用しています。つまり、テストの前に Elasticsearch を起動したり、テスト後に停止したりする必要はありません。必要なのは、各テストの前にクライアントを作成し、各テストの後にクライアントを閉じることだけです (大規模なテスト スイートに影響を及ぼす可能性のあるリソース リークを回避するため)。

非静的フィールドに@Container注釈を付けるということは、テストごとに新しいコンテナが開始されることを意味します。そのため、古いデータやコンテナの状態のリセットについて心配する必要がありません。ただし、多くのテストではこのアプローチがうまく機能しない可能性があるため、次の投稿のいずれかで代替案と比較する予定です。

注記：

テストでElasticsearchに接続する

Elasticsearch Java クライアントは、セキュリティと SSL/TLS が有効になっている場合でも、テスト コンテナーで実行されている Elasticsearch に接続できます (バージョン 8.x ではこれがデフォルトであるため、コンテナー宣言でセキュリティに関連するものを指定する必要はありませんでした)。実稼働環境で使用している Elasticsearch でも TLS と何らかのセキュリティが有効になっていると仮定すると、統合テストの設定を実稼働環境のシナリオにできるだけ近づけ、テストでそれらを無効にしないことが推奨されます。

コンテナがフィールドまたは変数elasticsearchに割り当てられていると仮定して、接続に必要なデータを取得する方法:

• elasticsearch.getHost() コンテナが実行されているホストが提供されます (ほとんどの場合、おそらく"localhost"になりますが、設定によっては別の名前になる場合があるため、これをハードコードしないでください。そのため、ホストは常に動的に取得する必要があります)。

• elasticsearch.getMappedPort(9200) コンテナ内で実行されている Elasticsearch に接続するために使用する必要があるホスト ポートを指定します (コンテナを起動するたびに外部ポートが異なるため、これも動的な呼び出しである必要があります)。

• 上書きされない限り、デフォルトのユーザー名とパスワードはそれぞれ"elastic"と"changeme"です。

• コンテナのセットアップ中に SSL/TLS 証明書が指定されておらず、セキュリティで保護された接続が無効になっていない場合 (バージョン 8.x からのデフォルトの動作)、自己署名証明書が生成されます。それを信頼する（例：cURLと同様に、証明書はelasticsearch.caCertAsBytes() ( Optional<byte[]>を返します) を使用して取得できます。または、別の便利な方法として、 createSslContextFromCa()を使用してSSLContextを取得することもできます。

全体的な結果は次のようになります。

ElasticsearchClientのインスタンスを作成する別の例は、デモ プロジェクトにあります。

注記：

最初の統合テスト

Elasticsearch バージョン 8.15.x を使用してBookSearcherを作成できることを確認する最初のテストは次のようになります。

ご覧のとおり、他に何も設定する必要はありません。Elasticsearch によって返されるバージョンをモックする必要はありません。必要なのは、Testcontainers によって開始された Elasticsearch の実際のインスタンスに接続されたクライアントをBookSearcherに提供することだけです。

統合テストは内部をあまり考慮しない

ちょっとした実験をしてみましょう。列インデックスを使用して結果セットからデータを抽出するのをやめ、列名に頼らなければならないと仮定します。そのため、メソッドisCompatibleWithBackendでは、

私たちは次のことをする予定です:

両方のテストを再実行すると、実際の Elasticsearch との統合テストが問題なく合格していることがわかります。ただし、 rs.getInt(int)ではなくrs.getInt(String)ような呼び出しをモックしたため、モックを使用したテストは機能しなくなりました。これらを合格させるには、テスト スイート内の他のユース ケースに応じて、代わりにモックを作成するか、両方をモックする必要があります。

統合テストはハエを殺す大砲になり得る

統合テストは、外部依存関係が必要ない場合でも、システムの動作を検証できます。ただし、このように使用すると、通常、実行時間とリソースが無駄になります。メソッドmostPublishedAuthorsInYears(int minYear, int maxYear)を見てみましょう。最初の 2 行は次のとおりです。

最初のステートメントは、Elasticsearch (またはその他の外部依存関係) にまったく依存しない条件をチェックしています。したがって、 minYearがmaxYearより大きい場合に例外がスローされることを確認するためだけにコンテナーを起動する必要はありません。

これを確認するには、高速でリソースを大量に消費しない単純なモック テストで十分です。モックを設定したら、次の操作を実行するだけです。

このテスト ケースでは、モックする代わりに依存関係を開始するのは無駄です。この依存関係に対して意味のある呼び出しを行う機会がないためです。

ただし、 String query = ...で始まる動作、つまりクエリが正しく記述され、期待どおりの結果が得られることを検証するには、クライアント ライブラリが適切なリクエストと応答を送信でき、構文の変更がないため、統合テストを使用する方がはるかに簡単です。例:

こうすることで、Elasticsearch (このバージョンまたは移行先の将来のバージョン) にデータをフィードするときに、クエリによって期待どおりの結果が正確に返されることが保証されます。つまり、データ形式は変更されず、クエリは引き続き有効であり、すべてのミドルウェア (クライアント、ドライバー、セキュリティなど) は引き続き機能します。モックを最新の状態に保つ必要はありません。例えば、互換性を確保するために必要な変更は、8.15はこれを変更します:

例えば、ES|QL の代わりに古き良き QueryDSL を使用してください。クエリから受け取る結果は (言語に関係なく) 同じになるはずです。

必要に応じて両方のアプローチを使用する

メソッドmostPublishedAuthorsInYearsのケースは、1 つのメソッドを両方のメソッドを使用してテストできることを示しています。そしておそらくそうなるべきなのかもしれない。

• モックのみを使用するということは、モックを維持する必要があり、システムをアップグレードするときに自信がまったくないことを意味します。

• 統合テストのみを使用すると、まったく必要ないのに、かなりのリソースを無駄にすることになります。

まとめましょう

• Elasticsearch ではモックテストと統合テストの両方を使用できます。

• fast-detection-net としてモック テストを使用し、正常に合格した場合にのみ、依存関係を使用してテストを開始します (例: ./mvnw test '-Dtest=!TestInt*' && ./mvnw test '-Dtest=TestInt*'またはFailsafeおよびSurefireプラグインを使用)。

• 外部依存関係との統合があまり重要でない（またはスキップできる）システムの動作（「コード行」）をテストする場合は、モックを使用します。

• 統合テストを使用して、外部システムに関する想定と外部システムとの統合を検証します。

• 上記の点に従って、意味がある場合は、両方のアプローチを使用してテストすることを恐れないでください。

バージョン (この場合は8.15.x ) について厳しすぎるというのは、言い過ぎではないでしょうか。バージョン タグだけを使用することもできますが、この投稿ではバージョン間で変更される可能性のある他のすべての機能を表すものとして機能していることに注意してください。

シリーズの次回の記事では、テスト データ セットを使用して、テスト コンテナーで実行される Elasticsearch を初期化する方法について説明します。このブログに基づいて何かを構築した場合、または質問がある場合は、ディスカッション フォーラムやコミュニティ Slack チャネルでお知らせください。