分散フォールトトレラントアーキテクチャは難しいですか?わかりやすく説明する記事

位置付けには「分散型」や「フォールト トレラント アーキテクチャ」など、少し複雑に見える言葉が含まれていますが、私たちは依然として古いルールに従っています。つまり、平易な言葉 + 手描きのカラー画像数枚で、徐々に進めていくことで、すべての学生がこの複雑なアーキテクチャの設計概念を理解できるようにします。

テラバイトレベルのデータを 1 台のマシンにまとめる: 困難!

分散ストレージ システムを例に、フォールト トレラント アーキテクチャの設計について説明します。

まず、分散ストレージシステムとは何かを見てみましょう。実はとても簡単です。例としてデータベース内のテーブルを使用しましょう。

たとえば、数十億、あるいは数百億のデータを含む非常に大きなテーブルを持つデータベースがあるとします。

さらに一歩進んで、このテーブルのデータ量が数十 TB、あるいは数百 TB に達するとします。どう思いますか？

もちろん、MySQL のようなデータベースを使用する場合、単一のデータベース サーバーのディスクではこのテーブルのデータを保存するのに十分ではない可能性があるため、私はパニックと無力感を感じました。

下の画像を見て、雰囲気をつかんでみましょう。

分散ストレージとは一体何でしょうか?

つまり、数百 TB という非常に大きなデータ セットがある場合でも、その場合、それを保存するために従来のデータベース テクノロジを使用することは検討すべきではありません。

単一のデータベース サーバーを使用するだけでは不十分な可能性があるため、分散ストレージ テクノロジを検討しますか?それは正しい！これがこの問題の解決策です。

複数台のマシンももちろん使用可能です！たとえば、20 台のマシンを使用して、各マシンにデータの 1/20 を配置することができます。

たとえば、合計 20 TB のデータがある場合、各マシンに配置する必要があるのは 1 TB だけです。 1TBあれば大丈夫ですよね？各マシンは大量のデータを簡単に、そして快適に保持できます。

したがって、非常に大きなデータセットを複数の部分に分割し、複数のマシンに配置することを分散ストレージと呼びます。

次の図を見てみましょう。

では、分散ストレージ システムとは何でしょうか?

では、分散ストレージ システムとは何でしょうか?分散ストレージ システムとは、当然ながら、非常に大きなデータ セットを複数の部分に分割し、複数のマシンに保存し、これらの複数のマシンに保存されたデータを均一に管理するシステムです。

たとえば、従来の Hadoop はそのようなシステムであり、FastDFS も同様です。心を開いてアイデアの共通の本質から始めることができれば、Elasticsearch、Redis Cluster などのシステムは本質的に同じであることがわかります。

これらはすべて、大量のデータを複数の部分に分割し、複数のマシンに保存する分散システム アーキテクチャに基づいています。

この記事は分散システム アーキテクチャ レベルから始まり、特定のテクノロジに限定されないため、この分散ストレージ システムには 2 つのプロセスがあると暫定的に想定できます。

プロセスはマスター ノードであり、1 台のマシン上に存在し、複数のマシンに分散しているデータの統合管理を担当します。

別のプロセスのグループはスレーブ ノードと呼ばれます。各マシンにはスレーブ ノードがあり、そのマシン上のデータの管理とマスター ノードとの通信を担当します。

次の図を見て、その図を通して上記の説明を直感的に考えてみましょう。

何てことだ！マシンがクラッシュした場合はどうすればいいですか?

ここで別の問題が起こります。 20 台のマシンのうち 1 台がクラッシュしたらどうなりますか?

これは恥ずかしいことです。なぜなら、20TB のデータがすべて失われ、そのうち 19TB はまだ残っていますが、マシンがダウンしたために 1TB のデータが失われるからです。

したがって、このような事態が発生することを絶対に許すことはできません。データのコピー戦略を立てる必要があります。

たとえば、各マシン上の 1 TB のデータの冗長コピーを 2 つ作成し、他のマシンに配置することができます。そうすると、マシンがクラッシュしても、他のマシンにコピーがあるので問題はありません。

次のマルチコピー冗長アーキテクチャ設計図を見てみましょう。

上の写真の水色の「1TB Data 01」は、20TB のデータ セットの最初の 1TB データ シャードを表します。

写真からわかるように、コピーは 3 つあり、3 つのマシンには 3 つのコピーを表す水色のブロックがあります。

このようにして、データのコピーが 3 つ存在します。他のデータも同様です。今回は、以下のようなマシンがクラッシュしたと仮定します。これにより、データ シャード「1TB Data 01」のデータ コピーの 1 つが必然的に失われます。

次の図に示すように:

今それは重要ですか?いいえ、データ シャード「1TB Data 01」には、残っている 2 台のマシンに他の 2 つのコピーがあるためです。

したがって、誰かがデータを読み取りたい場合、他の 2 台のマシンからコピーを選択して読み取ることができます。データは失われません。心配しないで、兄弟。

マスターノードはデータコピーの消失をどのように認識するのでしょうか?

今、問題があります。たとえば、ある兄弟がデータ シャード「1TB データ 01」を読み取りたい場合、マスター ノードを見つけて、「データ シャード「1TB データ 01」がどこにあるか教えてもらえますか? どのマシンにありますか? 読み取る必要があります!」と尋ねます。

次の図を見てみましょう。

このとき、マスター ノードは「1TB Data 01」の 3 つのコピーのうち 1 つを選択し、他のノードに次のように伝える必要があります。「兄弟、そのようなマシンにコピーがあります。そのマシンに移動して「1TB Data 01」のコピーを読み取ることができます。」

しかし、ここで問題となるのは、マスターノードが「1TB データ 01」のコピー 3 が失われたことを認識していないことです。マスターノードが依然として他のノードに失われたコピー 3 を読み取るように通知する場合、それは絶対に許可されません。

では、レプリカ 3 が失われたことをマスター ノードに通知するにはどうすればよいでしょうか?実のところ、それは非常に簡単です。各マシン上のデータを管理するスレーブ ノードは、数秒ごとに (たとえば 1 秒ごとに) マスター ノードにハートビートを送信します。

その後、マスター ノードは、スレーブ ノードから送信されたハートビートを一定期間 (たとえば、30 秒以内) 受信していないことを検出すると、スレーブ ノードが配置されているマシンがクラッシュし、そのマシン上のデータ コピーが失われたと判断します。すると、マスターノードは、失われたデータのコピーを読み取るように他のノードに指示しなくなります。

次の図をご覧ください。スレーブ ノードがダウンすると、マスター ノードはハートビートを受信できなくなり、そのマシン上のレプリカ 3 が失われたと認識します。この時点では、ダウンしたマシン上のレプリカ 3 を他のユーザーが読み取ることは許可されません。

この時点で、マスター ノードは、「1TB データ 01」のコピー 1 またはコピー 2 を読み取るようにユーザーに通知できます。実際には、これら 2 つのコピーがまだ存在しているため、どちらでもかまいません。

たとえば、クライアントにレプリカ 1 を読み取るように通知することができます。この時点で、クライアントはそのマシン上のスレーブ ノードを見つけて、レプリカ 1 を読み取りたいと伝えることができます。

全体のプロセスを下の図に示します。

十分な数のレプリカを維持する

このとき、別の問題があります。つまり、データ シャード「1TB データ 01」にはコピー 1 とコピー 2 の 2 つのコピーしかなく、3 つのコピーには足りません。

各データ シャードには 3 つのコピーが必要であると想定しているためです。考えてみましょう。現時点でこのデータ シャードに 1 つのコピーを追加するにはどうすればよいでしょうか?

とても簡単です。マスターノードは、マシンがクラッシュしたことを感知すると、特定のデータシャードのコピー数が不足していることを感知できます。

この時点で、レプリカ レプリケーション タスクが生成され、レプリカがあるマシンからコピーをレプリケートするために別のマシンが選択されます。

たとえば、次の図を見ると、2 番目のマシンからコピーを作成するために 4 番目のマシンを選択できます。

しかし、レプリケーション タスクが配置されたので、マシン 4 にそれをどのように通知するのでしょうか?実際、それは非常に単純でもあります。マシン 4 は 1 秒ごとにハートビートを送信しませんか?

マシン 4 がハートビートを送信すると、マスター ノードはハートビート応答を通じてマシン 4 にレプリケーション タスクを送信し、マシン 4 がマシン 2 からコピーを複製できるようにします。

もう一度、このプロセスを見てみましょう。

上の図を見ると、マシン 4 に「1TB データ 01」の別のコピー 3 が存在することになりますか?では、データ シャード「1TB データ 01」には、再び 3 つのコピーがあるのでしょうか?

重複したコピーを削除する

一方、マシン3が突然復旧した場合、そこにも「1TBデータ01」のコピー3が存在するため、この時点で「1TBデータ01」には4つのコピーが存在することになります。コピーは冗長ではないでしょうか?

それは問題ではありません。マスター ノードは、マシン 3 が復活したことを感知すると、レプリカが多すぎると判断し、レプリカを削除するタスクを生成します。

マシン 3 がハートビートを送信すると、コピーを削除するコマンドが発行され、マシン 3 は自身の冗長ローカル コピーを削除できるようになります。こうすることで、コピー数を 3 個に抑えることができます。

同様に、次の図を見てみましょう。

要約する

さて、ここまでの非常に平易な言葉による説明と、10 枚を超える図による段階的な進化の説明により、分散システムについてこれまで理解していなくても、分散システムの完全なデータ フォールト トレラント アーキテクチャがどのように設計されているかを確実に理解できると思います。

実際、データ シャーディング ストレージ、マルチコピー冗長性、ダウンタイム認識、自動コピー移行、冗長コピー削除のメカニズムは、Hadoop や Elasticsearch などの多くのシステムで同様です。

したがって、著者はここで、この分散システムとミドルウェア システムの基盤となるデータ フォールト トレラント アーキテクチャの考え方を吸収することを強くお勧めします。

こうすることで、将来同様の技術を学ぶときに、その原理や考え方について既視感を覚えることになります。