分散システムを設計するにはどうすればいいでしょうか? Elasticsearchの仕組みを見る

分散システムにはさまざまな種類があり、非常に広範囲にわたります。システムの種類によって特性が異なります。バッチ コンピューティングとリアルタイム コンピューティングは非常に異なります。

[[276390]]

画像はPexelsより

この記事では、分散ストレージ システム、分散検索システム、分散分析システムなどの分散データ システムの設計に焦点を当てます。まず、Elasticsearch のアーキテクチャを簡単に見てみましょう。

Elasticsearch クラスター アーキテクチャ

Elasticsearch は非常に有名なオープンソースの検索および分析システムであり、現在インターネットのさまざまな分野で広く使用されています。

特に、次の 3 つの領域が際立っています。

• 検索分野では、Solr と比較して、これは真の新星であり、多くの検索システムの第一選択肢となっています。
• Json ドキュメント データベースは MongoDB よりも読み取りおよび書き込みパフォーマンスが優れており、より豊富な地理的位置クエリと数値とテキストの混合クエリをサポートします。
• 時系列データ分析・処理は、監視データのログ処理、保存、分析、可視化において非常に優れた成果を上げており、この分野のリーダーと言えます。

Elasticsearch の詳細な紹介は公式 Web サイトにあります。まず、Elasticsearch の重要な概念をいくつか見てみましょう。

• ノード: 物理的な概念、実行中の Elasticsearch インスタンス、通常はマシン上のプロセス。
• インデックス: 構成情報のマッピング、反転および転送データ ファイルを含む論理概念。インデックスのデータ ファイルは、1 台のマシンまたは複数のマシンに分散される場合があります。インデックスの別の意味は、逆インデックス ファイルです。
• シャード: 大量のデータに対応するために、インデックスは通常、特定のディメンションに従って複数の部分に分割されます。各部分はシャードであり、シャードはノードによって管理されます。

ノードは通常、同じインデックスまたは異なるインデックスに属する可能性のある複数のシャードを管理します。ただし、信頼性と可用性を確保するために、同じインデックスのシャードは可能な限り異なるノードに分散されます。シャードには、プライマリ シャードとレプリカ シャードの 2 種類があります。

• レプリカ: 同じシャードのバックアップ データ。シャードには 0 個以上のレプリカが存在する場合があります。これらのレプリカ内のデータは、強い一貫性または結果的な一貫性が保証されます。

上記のように、グラフィック表現は次のようになります。

• インデックス 1: 青い部分には、3 つの異なるノードに配置された 3 つのシャード (P1、P2、P3) があります。ここにはレプリカはありません。
• インデックス 2: 緑の部分には、2 つの異なるノードに配置された 2 つのシャード (P1 と P2) があります。そして、各シャードにはレプリカ、つまり R1 と R2 があります。

システムの可用性を考慮すると、同じシャードのプライマリとレプリカを同じノードに配置することはできません。

ここで、Shard1 の P1 と R1 はそれぞれ Node3 と Node2 に配置されています。 Node2 がダウンした場合でも、P1 と R2 は引き続き利用可能であるため、サービスは基本的に影響を受けません。

マスタースレーブアーキテクチャであるため、プライマリシャードに障害が発生した場合は切り替える必要があります。この時点で、レプリカを新しいマスターとして選出する必要があります。少し時間がかかるだけでなく、データが失われるリスクもあります。

インデックスプロセス

インデックスを構築する際、ドキュメントは最初にルーティング ルールを通じてプライマリ シャードに配置され、その後インデックス作成のためにプライマリ シャードに送信されます。成功した場合、ドキュメントはインデックス作成のためにシャードのレプリカに送信されます。レプリカ上にインデックスが正常に構築された後にのみ成功が返されます。

このアーキテクチャでは、すべてのインデックス データがシャードに保存され、1 つのコピーがプライマリ シャードに保存され、もう 1 つのコピーがレプリカ シャードに保存されます。

レプリカ シャードまたはプライマリ シャードが失われた場合 (たとえば、マシンのダウンタイムやネットワークの中断により)、失われたシャードを他のノードで復元する必要があります。

このとき、新しいシャードを構築するには、このシャードのすべてのデータを他のレプリカ (レプリカ) から新しいノードにコピーする必要があります。

このコピー プロセスには時間がかかり、その間は残っているプラ​​イマリ レプリカのみがトラフィックを伝送できます。リカバリが完了する前に、フェイルオーバーが完了するまで、システム全体が比較的危険な状態になります。

これは、レプリカが存在する理由の 1 つを反映しており、データの損失を回避し、データの信頼性を向上させることです。

レプリカが存在するもう 1 つの理由は、読み取り要求の数が多い場合、1 つのノードではすべてのトラフィックを処理できないことです。このとき、クエリ機能を拡張するために、クエリ負荷を分散するためのレプリカが必要です。

ロール展開方法

次に、役割を分担する 2 つの異なる方法を見てみましょう。

Elasticsearch は上記の両方の方法をサポートしています。

• ハイブリッド展開
• 階層型展開

ハイブリッド展開 (左に表示):

• デフォルトモード。
• マスターノードを考慮せずに、データノードとトランスポートノードの 2 種類のノードがあります。

このデプロイメント モードでは、これら 2 つの異なるタイプのノード ロールが同じノードに配置されます。これは、データとトランスポートの 2 つの機能を持つノードに相当します。

• インデックスまたはクエリのリクエストがある場合、リクエストはランダムに（カスタマイズされて）任意のノードに送信されます。

このノードはグローバル ルーティング テーブルを保持し、ルーティング テーブルを通じて適切なノードを選択し、これらのノードに要求を送信し、すべての要求が返された後、結果をマージしてユーザーに返します。ノードは 2 つの役割を果たします。

• 利点は、使い方が非常に簡単で、簡単に始めることができ、システムの宣伝に大きな価値があることです。最も単純なシナリオでは、すべての機能を完了するために 1 つのノードを起動するだけで済みます。
• 欠点は、複数の種類のリクエストが相互に影響を及ぼしてしまうことです。大規模クラスター内のデータ ノードがホットになると、このデータ ノードを通過する他のすべてのノード間リクエストに影響します。障害が発生した場合、その影響はさらに大きくなります。
• Elasticsearch の各ノードは、他のすべてのノードと 13 個の接続を維持する必要があります。

この場合、各ノードは他のすべてのノードとの接続を維持する必要があり、システム内の接続数には上限があるため、接続数によってクラスターのサイズが制限されます。

• また、クラスターのホットアップデートはサポートされていません。

階層化展開（右図参照）:

• ノードは構成によって分離できます。
• いくつかのノードをトランスポート ノードとして設定します。トランスポート ノードは、要求の転送と結果のマージにのみ使用されます。
• その他のノードは、データの処理専用のデータ ノードとして設定できます。
• 欠点は、始めるのが複雑なことです。トランスポートの数を事前に設定する必要があります。この数はデータ ノード、トラフィックなどに関連しています。そうしないと、リソースがアイドル状態になるか、マシンが過負荷になります。
• 利点は、役割が互いに独立しており、互いに影響を及ぼさないことです。通常、トランスポート ノードのトラフィックは均等に分散され、単一のマシンの CPU またはトラフィックが完全に利用されることはまれです。

データノードはデータを処理するため、CPU、ネットワーク、ディスクなどの単一マシンのリソースが完全に占有されやすくなります。

• 分離後、DataNode に障害が発生した場合、単一のノードのデータ処理にのみ影響し、他のノードの要求には影響しません。影響は最小限の範囲に限定されます。
• 役割が独立すると、トランスポート ノードのみがすべてのデータ ノードに接続する必要があり、データ ノードは他のデータ ノードに接続する必要はありません。

クラスター内のデータ ノードの数はトランスポート ノードの数よりもはるかに多いため、クラスターの規模を大きくすることができます。

さらに、トランスポート ノードをグループ化して、固定グループ内のデータ ノードにのみ接続するようにすることもできます。これにより、Elasticsearch の接続数の問題が完全に解決されます。

• ホット アップデートをサポートしています。まずデータ ノードを 1 つずつアップグレードし、アップグレードが完了した後にトランスポート ノードをアップグレードします。プロセス全体を通して、ユーザーはそれに気付かない場合があります。

上記では、Elasticsearch のデプロイメント レイヤー アーキテクチャについて紹介しました。さまざまなシナリオに応じて、さまざまな展開方法が適しています。ニーズに応じて適切な方法を選択する必要があります。

Elasticsearch データ層アーキテクチャ

次に、現在の Elasticsearch データ層アーキテクチャを見てみましょう。

データストレージ

Elasticsearch のインデックスとメタは現在、ローカル ファイル システムでのストレージをサポートしており、niofs、mmap、simplefs、smb などのさまざまな読み込み方法もサポートしています。最高のパフォーマンスは、インデックスをメモリに直接ロックする mmap メソッドです。

デフォルトでは、Elasticsearch は読み込み方法を自動的に選択しますが、設定ファイルで自分で設定することもできます。ここにはいくつか詳細がありますので、詳細については公式ドキュメントを参照してください。

インデックスとメタデータの両方がローカルに保存されるという事実は、マシンがクラッシュしたりディスクが破損したりするとデータが失われるという問題を引き起こします。この問題を解決するには、レプリカ機能を使用できます。

レプリカ

各インデックスに対して、レプリカの数という構成項目を設定できます。レプリカの数を 2 に設定すると、シャードは 3 つになり、そのうち 1 つがプライマリ シャード、他の 2 つがレプリカ シャードになります。

3 つのシャードは、マスターによって可能な限り異なるマシンまたはラックにスケジュールされます。これら 3 つのシャード内のデータは同じであり、同じサービス機能を提供します。

レプリカには 3 つの目的があります。

• サービスの可用性の確保: 複数のレプリカが設定されている場合、1 つのレプリカが使用できなくなった場合でも、要求トラフィックは引き続き他のレプリカに送信され、サービスを迅速に復元できます。
• データの信頼性を確保する: プライマリ ノードが 1 つしかなく、レプリカ ノードがない場合、プライマリ ノードのディスクが破損すると、このノード内のすべてのシャードのデータが失われ、再インデックスしか選択できなくなります。
• より優れたクエリ機能を提供: Shard が提供するクエリ機能がビジネス ニーズを満たせない場合は、N 個のレプリカを追加し続けることで、クエリ機能を N 倍に増やすことができ、システムの同時実行性を簡単に高めることができます。

質問

上記でいくつかの利点について説明しましたが、このアーキテクチャでは、シナリオによっては問題が発生する可能性もあります。 Elasticsearch は、ローカル ファイル システムに基づく技術アーキテクチャを使用し、レプリカを使用してデータの信頼性を確保します。このアーキテクチャは、ある程度、ほとんどの要件とシナリオを満たすことができます。

しかし、いくつか残念な点もあります。

• レプリカはコストの無駄をもたらします。データの信頼性を確保するには、レプリカを使用する必要があります。ただし、1 つのシャードが処理能力を満たす場合、別のシャードの計算能力は無駄になります。
• レプリカは書き込みパフォーマンスとスループットの低下をもたらします。インデックス作成または更新を行うたびに、まずプライマリ シャードを更新し、更新が成功した後にレプリカを並行して更新する必要があります。ロングテールと相まって、書き込みパフォーマンスは大幅に低下します。
• ホットスポットが発生した場合や緊急に容量拡張が必要な​​場合、レプリカを動的に追加すると時間がかかります。新しいシャードのデータは他のシャードから完全にコピーする必要があり、これには長い時間がかかります。

上記では、Elasticsearch データ層のアーキテクチャと、レプリケーション戦略の長所と短所について紹介しました。以下では、分散データ システム アーキテクチャのさまざまな形式について簡単に紹介します。

分散システム

ローカルファイルシステムに基づく分散システム

上の図は、ローカル ディスクに基づいてデータを保存する分散システムを示しています。インデックスには合計 3 つのシャードがあります。各シャードには、プライマリ シャードに加えてレプリカ シャードがあります。

ノード 3 のマシンがクラッシュするか、ディスクが破損した場合、まず P3 が使用できなくなったことを確認し、R3 をプライマリ シャードとして再選択し、このシャードでマスターとスレーブの切り替えが行われます。次に、新しいマシン Node 7 を見つけて、Node 7 で P3 の新しいレプリカを再起動します。

データはローカル ディスクに保存されるため、シャード 3 のデータをノード 6 からノード 7 にコピーする必要があります。

200G のデータがあり、ネットワークがギガビットの場合、コピーには 1600 秒かかります。レプリカがない場合、これらのシャードは 1600 秒以内に使用できません。

信頼性を確保するには冗長なシャードが必要であり、これにより物理リソースの消費量が増加します。このアイデアのもう 1 つの具体化は、デュアル クラスターを使用してクラスター レベルのバックアップを実行することです。

このアーキテクチャでは、データが HDFS/HBase などの他のストレージ システムで生成される場合、準備されたデータを対応するマシンに配布するためのデータ転送システムも必要になります。

このアーキテクチャの可用性と信頼性を確保するには、実稼働環境でデュアル クラスターまたはレプリカを使用する必要があります。メリットと副作用については、上記で Elasticsearch を紹介した際に紹介したので、ここでは繰り返さないことにします。 Elasticsearch はこのアーキテクチャアプローチを使用します。

分散ファイルシステムに基づく分散システム

最初のアーキテクチャの問題に対処するための別のアプローチは、ストレージとコンピューティングを分離することです。

最初のアプローチの問題の根本的な原因は、データの量が多く、データのコピーに時間がかかることです。では、データのコピーを回避する方法はあるのでしょうか?

この目標を達成するための 1 つのアイデアは、基盤となるストレージ層で共有ストレージを使用することです。各シャードは、分散ファイル システム内のディレクトリ/ファイルに接続するだけで済みます。シャードにはデータは含まれず、コンピューティング部分のみが含まれます。

つまり、各ノードはコンピューティング部分のみを担当し、ストレージ部分は HDFS などの別の基盤となる分散ファイル システムに配置さます。

上の図では、ノード 1 は最初のファイルに接続されています。ノード 2 は 2 番目のファイルに接続されます。ノード 3 は 3 番目のファイルに接続されます。

ノード 3 がダウンした場合は、ノード 4 に空のシャードを作成し、基盤となる分散ファイル システムの 3 番目のファイルに接続するための新しい接続を構築するだけで済みます。接続は非常に速く確立され、かかる合計時間も非常に短くなります。

これは、ストレージとコンピューティングを分離した典型的なアーキテクチャであり、次のような利点があります。

• このアーキテクチャでは、リソースをより柔軟にすることができます。ストレージが不足している場合は、ストレージ システムの容量のみを拡張する必要があります。コンピューティングが不足する場合は、コンピューティング部分の容量のみを拡張する必要があります。
• ストレージとコンピューティングは独立して管理され、リソース管理の粒度は小さくなり、管理はより洗練され、無駄が減るため、全体的なコストが削減されます。
• 負荷がより顕著になり、ホットスポットに対する耐性が強くなります。一般的に、ホットな問題は主にコンピューティング部分で発生します。ストレージとコンピューティングが分離されたシステムの場合、コンピューティング部分はデータにバインドされていないため、リアルタイムで拡張、縮小、移行できます。ホットスポットが発生すると、コンピューティングをすぐに新しいノードにスケジュールできます。

このアーキテクチャには欠点もあります。分散ファイル システムへのアクセスのパフォーマンスは、ローカル ファイル システムへのアクセスほど良くない可能性があります。

これは、以前の世代の分散ファイルシステムではより明白な問題でしたが、さまざまなユーザーモード プロトコル スタックの使用により、そのギャップはますます小さくなってきています。 HBase はこのアーキテクチャを使用しており、Solr もこのタイプのアーキテクチャをサポートしています。

要約する

上記の 2 つのアーキテクチャには、それぞれ長所と短所があります。一部のアーキテクチャの欠陥や不具合については、さまざまなアイデアやソリューションも大きく異なりますが、アイデアの範囲が広ければ広いほど、一般的にメリットも大きくなります。

上記では、分散データ（保存/検索/分析など）システムのストレージ層の 2 つの異なるアーキテクチャ方式のみを紹介しました。皆様のお役に立てれば幸いです。

ただし、分散システム アーキテクチャの設計には、幅広いコンテンツ、多くの詳細、および多くのトレードオフが伴います。特定の分野や側面にご興味がある場合は、メッセージを残していただければ、後ほどご相談させていただきます。