理解する必要がある分散システムにおける同様のクラスタ技術と原則

序文

今日の情報爆発の時代では、1 台のコンピューターでは、成長するビジネスの発展をサポートできなくなりました。強力なスーパーコンピュータは存在しますが、そのようなハイエンドマシンは高価なだけでなく柔軟性にも欠けています。普通の企業にはそれを維持する余裕はなく、失う余裕もありません。したがって、安価な普通のコンピューターをまとめて組み合わせ、それらを連携させてスーパーコンピューターのように外部にサービスを提供するのは自然なことです。ただし、これによりソフトウェアの複雑さが増し、開発されたソフトウェアに水平拡張機能が必要になります。たとえば、Kafka、Elasticsearch、Zookeeper などがこのタイプのソフトウェアに属します。これらは本質的に「分散型」であり、つまり、マシン ノードを追加することでデータ ストレージと負荷圧力を共有できます。

なぜクラスタリングが必要なのでしょうか?

さまざまな場所に分散したコンピュータがネットワークを通じて相互に通信し、連携して外部全体にサービスを提供します。これはクラスターです。私たちが開発するシステムがそのような機能を持っていれば、理論的には水平方向に拡張する能力があり、マシンの数に応じてシステムのスループットが向上します。そうすれば、将来的にシステムに高負荷がかかった場合でも、状況にうまく対処できるようになります。

[[236565]]

なぜCAPを同時に満たすことができないのでしょうか?

上記の分析から、クラスタリングを実現するには、実際には複数のコンピュータを使用してシステム負荷を分散し、複数のコンピュータがデータ処理に参加することになることがわかります。可用性を確保するために、通常はデータのコピーが各コンピューターにバックアップされるため、1 つのノードが同期されている限り、データが失われることはありません。たとえば、Kafka パーティションには複数のコピーがあり、Elasticsearch レプリカ シャーディングがあります。同じデータ ブロックとそのコピーが異なるマシンに配置されているため、時間が経つにつれて、信頼性の低いネットワーク通信と相まって、すべてのマシン上のデータが必然的に不整合になります。このとき、極端な状況が発生してすべてのマシンがダウンした場合、データが失われないようにするにはどうすればよいでしょうか (実際には、方法は 2 つしかありません)。

1. 可用性の確保: 通常のサービスを再開する最初のマシン (必ずしもすべてのデータがあるわけではありません) を信頼できるデータ ソースとして選択し、クラスターを迅速に復元します。つまり、ダウンタイムは同期よりも優れています。

2. データの整合性を確保する: すべてのデータを含む最初のマシンが正常に戻るまで待ってから、クラスターを復元します。つまり、ダウンタイムよりも同期の方が優れています。たとえば、Kafka のアンクリーンリーダー選出メカニズムを無効にすることがそのような戦略です。

実際、ほとんどのマシンが利用できない場合は、可用性と一貫性の間で妥協する必要があるため、分散システムにより適合した別の Base 理論が作成されました。

分散ストレージの問題を解決するにはどうすればよいでしょうか?

複数のコンピューターで構成されたクラスターが外部にサービスを提供する場合、実際には外部に対して読み取りおよび書き込み機能が提供されます。

データブロック技術

各マシンにデータを合理的かつ均等に書き込み、クラスターの書き込み能力を向上させるため;読み取り要求の負荷をさまざまなノードに分散し、クラスターの読み取り機能を向上させる。データ ストレージと物理ノードを分離し、分散読み取りおよび書き込みの並列処理機能を向上させるために、賢明なエンジニアは、Kafka のパーティションや Elasticsearch のシャードなど、総称してデータ ブロックと呼ばれる論理データ ストレージ ユニットを導入しました。このような仮想化により、クラスターの読み取りと書き込みの柔軟性が大幅に向上します。

注: したがって、名前は重要ではなく、理由を知ることが最も重要です。

調整ノード

実際、クラスターが全体としてデータを処理するとき、各ノードは読み取りおよび書き込み要求を受信する可能性がありますが、データは異なるノードに分散されているため、各ノードはクラスター内の任意のデータ ブロックの場所を明確に把握し、要求を対応するノードに転送する必要があります。これは「調整ノード」の仕事です。たとえば、Elasticsearch のマスターノードはクラスター内のすべての変更を管理し、プライマリシャードはデータブロック内のすべての変更を管理します。

定足数

百度百科事典：定足数は法定数と翻訳され、会議を開催したり、決議を可決したり、選挙を実施したり、特別な機関を組織したりするときに法律で定められた必要人数を指します。規定数に達しない場合は無効となります。

ネットワーク パーティションの存在により、このメカニズムは、クラスター ノード間のマスターの選出やデータ ブロック間のヘッダーの選出など、分散システムで広く使用されています。分散ストレージでは、クォーラム読み取り/書き込みメカニズムとも呼ばれ、書き込み時にほとんどのノードが正常に書き込まれることが保証されます（一般的な方法は、プライマリデータブロック（ヘッダー）を選択して正常に書き込まれることを確認してから、冗長レプリカデータブロックと同期することです）。読み取り時には、ほとんどのノードのデータが確実に読み取られます (一般的な方法は、調整ノードがリクエストをさまざまなノードに分散し、取得したすべてのデータをグローバルに要約して並べ替えてから返します)。読み取りと書き込みの両方が大部分を占めるため、最も多くのデータを読み取ることができることを保証できるように、中央に最も重複するデータが存在する必要があります。

上記の分析から、ほとんどのノードがアクティブで利用可能な状態である限り、クラスター全体の可用性は影響を受けないという結論を下すことができます。ほとんどのデータ ブロックがアクティブで利用可能な状態である限り、読み取りおよび書き込みサービスは継続的に提供できます。 1 つのデータ ブロックが同期状態を完了している限り、データは失われません。これは実際には、冗長メカニズムを通じて障害/回復モードの障害を処理しようとする試みです。簡単に言えば、単一点障害を許容するには、少なくとも 3 つのノードを展開する必要があります。 2 つの障害点を許容するには、少なくとも 5 つのノードを展開する必要があります。マシン ノードの数が増えるほど、パーティション耐性が強くなります。ひらめきがあるんですよね？したがって、クラスターの可用性を確保するための前提は、奇数のノードと奇数のデータ ブロックがアクティブで使用可能な状態を維持することです。そうでない場合、マスターまたはヘッダーを選択できません。

ほとんどの投票メカニズムは非常に柔軟に使用できます。分散システムが強力な一貫性を追求する場合、書き込み操作が完了する前に、すべてのデータ ブロックとそのレプリカが正常に書き込まれるまで待機する必要があります (つまり、すべて書き込み)。これは、すべてが書き込まれるか、まったく書き込まれないかのいずれかの取引保証として理解できます。たとえば、Kafka のバージョン 0.11.0.0 以降では、プロデューサーが複数のトピック パートにメッセージを送信する場合、このメカニズムを使用して、メッセージ配信の 1 回限りのセマンティクスが保証されます。かっこいいでしょう？この場合、どのノードからでも最新のデータを読み取ることができ、読み取りパフォーマンスは最高になります。分散システムが最終的な一貫性を追求する場合、プライマリ データ ブロック (リーダー) が正常に書き込まれるのを待つだけで、その後、プライマリ データ ブロックはメッセージの到達可能性を通じてレプリカ データ ブロックに同期されます。

さまざまなシナリオでデータの信頼性とシステム スループットの要件を満たし、データの永続性とシステムの可用性を最大化するために、多くのコンポーネントでは、ユーザーが多数決クォーラムを定義できるようにする構成項目が提供されています。いくつかの一般的なコンポーネントの構成について説明します。

エラスティックサーチ

上の図からわかるように、クラスター全体は Elasticsearch インスタンスを実行する 3 つのノードで構成され、2 つのプライマリ シャード、各シャードに 2 つのセカンダリ シャード、合計 6 つのシャード コピーがあります。 Elasticsearch は同じシャードを異なるノードに自動的に配置します。これは非常に合理的かつ理想的です。新しいドキュメントを作成する場合:

1. クライアントは、新しいドキュメントを作成するためにノード 1 に書き込み要求を送信します。

2. ノードはドキュメントの _id を使用して、ドキュメントがシャード 0 に属しているかどうかを判断します。シャード 0 のプライマリ シャードは現在ノード 3 に割り当てられているため、リクエストはノード 3 に転送されます。

3. ノード 3 はプライマリ シャード上でリクエストを実行します。成功した場合、リクエストはノード 1 とノード 2 のレプリカ シャードに並行して転送されます。すべてのレプリカ シャードが成功を報告すると、ノード 3 はコーディネータ ノードに成功を報告し、コーディネータ ノードはクライアントに成功を報告します。

これは、Elasticsearch が書き込み要求を処理するために使用する一般的な一連の手順です。同時に、各ビジネス シナリオにはデータの信頼性とシステム パフォーマンスに対する要件が異なるため、Elasticsearch は一貫性構成項目を提供します。

1. プライマリ シャードは、アクティブかつ使用可能な状態である限り、書き込み要求を処理できます。システムのスループットは高いですが、データが失われる可能性があります。リアルタイムの時系列データ処理（ログ）など、高いデータ信頼性を必要としないシナリオに非常に適しています。

2. all: プライマリ シャードとすべてのレプリカ シャードがアクティブで使用可能な状態にある場合にのみ、書き込み要求が許可されます。システム スループットは *** ですが、データは失われません。重要なビジネス データを処理するのに非常に適しています。

3. クォーラム: 書き込み要求を処理するには、シャード コピーの過半数がアクティブで使用可能な状態である必要があります。この構成は、システム スループットとデータの信頼性のバランスをとるために一般的なビジネス システムで使用されます。

カフカ

Kafka にデータを書き込むとき、プロデューサーは ack を設定することでデータの信頼性のレベルをカスタマイズできます。

0: ブローカーが確認メッセージを返すのを待ちません。

1: リーダーは正常に保存して戻ります。

-1(すべて): すべてのバックアップが正常に保存されました。

注: デフォルトでは、パーティションの最大限の可用性を確保するために、acks=all の場合、ISR セット内のレプリカ パーティションが正常に書き込まれている限り、Kafka は書き込み成功のメッセージを返します。本当にすべて書き込みを確実にしたい場合は、transaction.state.log.min.isr 設定を変更してトピックの最小 ISR セット サイズを指定する必要があります。つまり、ISR セットの長さをトピックのパーティション数と同じに設定します。

すべてのノードが失敗した場合でも、アンクリーンリーダー選出メカニズムが保証されます。 Kafka が ISR セットを導入して多数決メカニズムを適応させ、メッセージ配信のさまざまなセマンティクスをより確実にする方法を深く理解するには、Kafka「公式ガイド」の設計セクションを読むことをお勧めします。

スプリットブレイン クラスターとは何ですか?

分散システムの場合、障害を自動的に処理するための鍵は、ノードの稼働状態を正確に把握することです。場合によっては、ノードが利用できない場合でも、必ずしもノードがクラッシュしたことを意味するわけではありません。一時的なネットワーク障害が原因である可能性が高いです。この場合、マスター ノードがすぐに選出されると、ネットワーク通信が正常に戻ったときに、同時に 2 つのマスターが存在することになります。この現象は「クラスター スプリット ブレイン」と呼ばれており、皆さんの考えにお任せします。ハハハ、明日は早く起きて昼寝しなきゃ。皆さんおやすみなさい。

注: 可用性の高い分散システムを設計する場合、考慮する必要がある障害シナリオは非常に複雑になることがよくあります。ほとんどのコンポーネントは、障害/回復モードの障害のみを処理します。つまり、一部のノードが使用不可になって回復を待機します。ビザンチン障害、つまりノード間の信頼の問題を処理できません。おそらくブロックチェーンはこの問題を解決できるでしょう。あなたはそれについてさらに調査することができ、それから私たちは議論し、学び、一緒に進歩することができます。

***で書かれた

ここまで多くのことをお話しいただきましたが、ほとんどの投票メカニズムの長所と短所をまとめていただけますか?コメント欄にメッセージを残してください。ハハハ、本当に寝なきゃ。おやすみ。