分散システムでの恐怖と嫌悪

Roman Grebennikovは、分散システムの構築の複雑さについて説明しています。 これは、 Highload ++ 2016のレポートです。



みなさん、こんにちは、グレベンニコフ・ローマンです。 Findifyで働いています。 オンラインストアを検索します。 しかし、会話はそれについてではありません。 Findifyでは、分散システムを扱っています。



分散システムとは何ですか？







スライドから、「恐怖と憎しみ」はITでよくあることであり、分散システムはあまり一般的ではないことは明らかです。 まず、分散システムとは何か、なぜそのような痛みがあるのか​​、なぜこのレポートが必要なのかを理解しようとします。



どこかで動作する何らかのアプリケーションがあると想像してください。 サーバー側であると仮定しますが、通常のアプリケーションとは異なり、何らかの内部状態を持っています。 たとえば、ゲームがある場合、内部状態は小さな男が走る世界などです。 遅かれ早かれ、あなたは成長し、あなたの内部状態は膨張し、変化し、1つのサーバーに収まるのをやめます。







この写真では、くまのプーさんが穴に引っかかっていました。



成長し始め、同じサーバーに収まらなくなった場合は、何かをする必要があります。



いくつかのオプションがあります。



より強力なサーバーを使用できますが、すでに最速のサーバーで作業している可能性があるため、行き止まりのパスになる可能性があります。



最適化することはできますが、明確にすることはできません。すべてをクリックして加速するのは2倍困難です。



あなたは非常に不安定な道に立つことができます-分散システムを作成します。



このトラックは不安定で怖いです。

今日お話しすること

まず、分散システムについて説明します。 少しの機器、それが重要である理由、完全性とは何か、この完全性を組み合わせる方法、データを失ったり、少しだけ失わない分散システムを設計するためのアプローチ、分散システムを確認するためのツールすべてがデータで優れているか、ほとんどすべてが優れています。



1つの理論は退屈なので、この問題と少しの練習について少しお話します。 このラップトップを使用して、独自の小規模でシンプルな分散データベースを作成します。 実際にはデータベースではなく、キー値ストレージではなく、値ストレージがあります。 次に、彼女がデータを2回以上、特にひどいポーズで失わないことを証明しようとします。



次は、「それとともに生きる方法」という小さな哲学です。



分散システムはどこか遠くで機能するものであり、私たちはここに座っていると思います。 サーバーである場合もあれば、互いに通信するモバイルアプリケーションである場合もあり、何らかの内部状態を持っています。 友達とテキストメッセージを送信している場合、あなたも分散システムの一部であり、一般的な条件があり、それに同意しようとしています。 一般に、分散システムはいくつかの部分で構成されるジョークであり、これらの部分は互いに通信します。 しかし、遅延とエラーで通信するという事実により、すべてが複雑になります。 これは事態を非常に複雑にします。



人生からの小さな例。



私たちはかつてインターネットをサーフィンするWebスパイダーを書き、あらゆる種類の異なるページをダウンロードしました。 彼には長い課題があり、そこにすべてを積み上げました。 キューにはいくつかの基本的な操作があります。 これは、キューから取り出すもの、キューに入れるものです。 また、キューに3番目の操作がありました。キューにオブジェクトがあるかどうかを確認し、同じものを2回入れないようにします。







問題は、行が非常に大きく、メモリに収まらないことでした。 私たちは考えました：何がそんなに複雑なのですか？ 私たちは賢く、HighLoadに行きます。 したがって、このキューを細かく分割して、別のサーバーにロールしてみましょう。 各サーバーは独自のキューを処理します。 はい、キューから最初の要素を取得できないという意味で、少し整合性が失われますが、ほとんど最初の要素を取得できます。 シャードケースを選んで、それから取り出して、すべてが順調です。 つまり、キューから取得する場合、ほとんどすべてが正常であり、ロジックはもう少し複雑になっています。 キューに入れるのも簡単です。どのシャードを入れるかを調べて入れます。 キューがあるかどうかも確認してください。問題もありません。 はい、ビジネスロジックはもう少し複雑になりましたが、少なくとも重要ではなくなっており、ここには血が流れていないようです。

どのような問題がありますか

何らかのネットワークインタラクションを追加し、コンポーネントが増えると、システムの信頼性が低下することを理解しています。 信頼性が低いと、間違いが発生します。 ソフトウェアとハ​​ードウェアの場合、すべてが明確です。 鉄を使用すると、ソフトウェアを使用してサーバーをより新しいものにすることができます-金曜日に酔って展開しないでください。 そして、ネットワークでは、そのようなことはあなたがそれをどうするかに関係なく壊れます。 Microsoftには、Windows Azureのスイッチの種類に基づいたネットワークハードウェア障害統計に関する優れた記事があります。 ロードバランサーポートが年間を通じてうなる確率は約17％です。 つまり、拒否した場合に何をすべきかを提供しないと、遅かれ早かれあなたは誰か良い人を丸willみするでしょう。



ネットワークで発生する最も一般的な問題は、NETSPLITです。 ネットワークが半分に崩壊したとき、それは絶えず崩壊したか、パケット損失があります。 この結果、それはバラバラになるか、バラバラになりませんでした。



ネットワークに問題がある場合、シャーディングのキューはどうなりますか？



キューから何かを取得する場合、キューから最初の要素を取得する準備ができている場合は、利用可能なシャードから取得することができます。



キューにコンポーネントがあるかどうかを確認する必要がある場合、使用できないシャードに移動する必要がある場合は何もできないという事実により、すべてが複雑になります。



しかし、キューに何かを入れる必要があると事態は複雑になり、シャードは利用できません。 その破片はどこか遠くにあるので、それを置く場所はありません。 それを失うか、どこかに延期してそれから何かをする以外に何も残っていません。 システムの設計に失敗を入れなかったからです。







おじさんは写真で悲しい。 彼はシステムの設計に失敗をしなかったからです。 私たちは賢く、非常に賢く、この問題に対処するための多くの異なる選択肢を考え出した他の叔父がいることは確かです。







次に、CAP定理がシーンに表示されます。



CAP定理は、分散システムの設計の基礎です。 これは正式には定理ではなく、経験則である定理ですが、誰もが定理と呼んでいます。



次のように聞こえます。 分散システムを作成する3つの柱があります。 これは、整合性、可用性、およびネットワークの問題に対する耐性です。 クジラは3匹いますが、2匹を選ぶことができます。 2つだけでなく、ほとんど2つです。 これについては後で説明します。



順序-整合性、アクセシビリティ、持続可能性とは何ですか。 これは一種の定理であり、正式な説明が必要です。

在庫状況

これは可用性であり、継続的な可用性を意味します。 システムへの各リクエスト、生きているノードへのシステムへのリクエストはすべて正常に処理されなければなりません。 つまり、リクエストの一部を後で延期するか、何かがうまくいかなかったために録音を側方に延期した場合、これは一貫性のない可用性です。 すべてのノードが要求に応答しない場合、またはすべてのノードがすべての要求に応答しない場合、これはCAP定理の観点からも一貫性のない可用性です。



これがあなたに答えたら：







これも可変可用性です。

誠実さ

次の項目は整合性です。 整合性の観点から、分散システムには非常に多くの異なるタイプの整合性があると言えます。







それらの約50があります。 CAP定理にあるのはどれですか？



CAP定理は最も厳格なタイプです。 線形化可能性が呼び出されます。



整合性、線形化可能性。 とてもシンプルに聞こえますが、その下には大きな影響があります。 操作Aの後に操作Bが開始された場合、BはAの終わりまたはより新しい状態でシステムを見るはずです。 つまり、Aが完了すると、次の操作ではAの前に何が起こったのかを見ることができません。すべてが論理的で、複雑なことは何もないようです。 言い換えると、「シーケンシャル操作には一貫した履歴があります。」



次に、これらのストーリーについて詳しく説明します。







何らかのレジスタがあると想像してください。 これは私たちが読むことができるものであり、以前にそこに書いたものだけです。 変数のためのただ一つの穴。 リーダーとライターは1人です。 そこですべてを読み書きしますが、複雑なことは何もありません。 読者と作家が複数いるとしても、それほど複雑なことはありません。







しかし、スライドから実際の世界に移動するとすぐに、ネットワークの遅延があるため、この図は少し異なって見えます。 正確な時期はわかりません。 録音はwとw1の間で行われ、正確にどこで起こったかはわかりません。 測定値も同じです。 たとえば、歴史の観点から、このような単純な3つのストーリーを書き留めることができます。







最初にaを読んでから、bを書いてから、bを読みます。写真のようにはっきりと。 原則として、別のストーリーが可能です。aを読んだとき、aをもう一度読んでから、bを書きました（写真のようにすべてがある場合）。



第三話。 aを読んだ後、突然bを読んでからbを書いた場合、それはそれと矛盾します。 線形化可能性の観点から、このようなストーリーは線形化できませんが、CAP定理では、矛盾しないストーリーが少なくとも1つ存在する必要があります。 その後、システムは線形化可能です。 いくつかあるかもしれません。

持続可能性

最後の項目は、文字Pです。パーティションの許容範囲は、ロシア語では「ネットワークの停止に対する抵抗」と言えます。 次のようになります。







数台のサーバーがあり、掘削機が早朝ここに運転し、それらの間の配線を切断したと想像してください。 クラスターが半分にバラバラになった場合、2つのオプションがあります。 最初の方法：大きい方の半分が生存し、小さい方が脱落します。 小さい方が脱落しているため、アクセシビリティが失われています。 しかし、大きなものは生きています。 しかし、彼らは完全性を失いませんでした。 両方とも機能します。私たちはあちこちで記録を受け入れ、すべてを受け入れます。すべては問題ありません。 そうしてはじめて、ワイヤがはんだ付けされると、1つのシステムがあり、2つのシステムがあり、それらは自分たちの生活を送ることがわかります。



CAP定理の観点から、システムの設計には3つのアプローチがあります。 これらは、3つの2つの組み合わせに依存するCP / AP / ACシステムです。



ACシステムに問題があります。 一方で、彼らは私たちが高可用性と整合性を持っていることを保証します。 ネットワークが壊れるまで、すべてがクールです。 また、これは頻繁に発生するため、実際にはACシステムを使用できますが、ACシステムを使用するときに生じる妥協点を理解している場合に限ります。



現実の世界には2つの方法があります。 整合性をシフトしてアクセシビリティを失うか、アクセシビリティにシフトしても整合性を失うことができます。 3番目はありません。



実際には、さまざまなCP / AP / ACシステムを実装する多くのアルゴリズムがあります。 2フェーズコミット、Paxos、クォーラムおよびその他のいかだ、ゴシップおよびその他のアルゴリズムヒープ。



次に、それらのいくつかを実装して、何が起こるかを確認します。 あなたは言うことができます：「10分が経過した、私たちの頭はすでに爆発し、私たちはちょうど到着しました。」 したがって、私たちは実際に何かをしようとします。

実際に行うこと

単純なマスター/スレーブ分散システムを作成します。 このために、Scala、Dockerを使用し、すべてをパックします。 非同期/同期レプリケーションを備えたマスター/スレーブ分散システムができます。 次に、Jepsenを取得し、実際にすべてが正しいか間違っているかを示します。 Jepsenを実行した後、結果を説明してみましょう。 ジェプセンとは何ですか？ 少し後で説明しますが、おそらくあなたの多くは聞いたことがあるでしょうが、目で見たことはありません。



マスタースレーブ 一般的に、それは基本的なもののように見えます。 クライアントは、マスターに書き込み要求を送信します。 マスターはディスクに書き込みます。 マスターは、同期または非同期ですべてをスレーブに分散します。 レコードとして散在する前、または後に、クライアントに同期的または非同期的に応答します。



CAPの定理の観点から、物事がどのように整合性、アクセス可能性などを備えているかを理解しようとします。



何か試してみましょう。







ここには小さなワークピースがありますので、カラオケでもっと書きます。 他のサーバーと連携するのに役立つ2つの機能があります。 つまり、分散システムのノード間で通信する最も簡単な方法としてHTTPを使用します。 どうして？



2つの機能があります。 このノードにこれらのデータを書き込みます：







このノードからデータを読み取り、これをすべて非同期的に実行する別の関数：







また、Responseを解析する便利な機能。 応答を受け取り、文字列を返します。







複雑なことは何もありません。



まず、分散システムの単純なサーバーを作成します。







まず、ここに宿題があります。 システム内のデータ、ここでは実際のデータベースではなくライブデモがあるため、統計全体を1つの変数に格納します。







したがって、単純に文字列を保存し、複製などを行います。 さまざまな便利なジョークがあります。たとえば、変数環境HOSTNAMEからの読み取り、近隣のノードなどです。







ここでは、2つの機能のプラグを作成します。







分散システムからの読み取りと分散システムからの書き込み。 もちろん、今は実装しませんが、先に進みます。



ここでバラライカを起動します。







すべてが非常に簡単です。 まだ実装されていないルート関数がありますが、それは何かをします。 使用する残りのルートについて説明します。







これをすべて8000番目のポートで取得します。







どのようなルートがありますか？ 2つのルートがあります。 最初はdbです。







このルートは、データベースクライアント向けです。 私たちは彼と協力しており、彼女は内部で何かをしています。



そこに着いたら、まだ実装していない魔法の関数readを呼び出します。







そこにデータを投稿する場合、書き込み関数を呼び出します。 複雑なことは何もないようです。







これに加えて、ローカルと呼ばれる別のルートがあります。







それは私たちのためではなく、分散システムのメンバーである異なるノードが互いに通信できるように作られました。 他の人はそこに書かれたものを読むことができました。



そこに到達したら、マジック変数値を読み取ります。







そこに投稿する場合、そこに投稿した内容をこの変数に書き込みます。







複雑なことは何もありません。 Scalaから小さな脳が爆発するかもしれませんが、大丈夫です。



サーバーを作成しました。 MasterSlaveのロジックを作成します。 次に、MasterSlaveが実装する別のクラスを作成します。 実際、非同期MasterSlaveからの読み取りは、そこにある変数に書き込まれたもののローカル読み取りにすぎません。







録音はもう少し複雑です。







私たちは最初に自分自身に手紙を書きます。







次に、所有しているすべてのスレーブを調べて、すべてのスレーブに書き込みます。







ただし、この関数には機能があり、Futureを返します。







ここでは、スレーブへのすべての書き込み要求を非同期にぼかし、クライアントに次のように言います。「すべては問題ありません。記録しました。さらに先に進むことができます。」 落とし穴を伴う可能性のある典型的な非同期レプリケーションは、今ではすべて見ることができます。



これをすべてコンパイルしてみましょう。 これはScalaです。彼女は長い間やっています。 一般に、コンパイルする必要があるとリハーサルしました。 コンパイル済み。

次にすること

書きましたが、すべてを実行する必要があり、ラップトップが1台あります。 しかし、私たちは分散システムを作っています。 単一ノードの分散システムは、完全に分散されたシステムではありません。 したがって、Dockerを使用します。







Dockerはアプリケーションをコンテナ化するためのシステムであり、おそらく誰もが聞いたことがあるでしょう。 すべてが本番環境で使用されているとは限りません。 使用してみます。 これは、すべてを簡素化するための軽い仮想化システムです。 Dockerには豊富なエコシステムがあり、このエコシステムのすべてを使用するわけではありません。 ただし、1つのコンテナーだけでなく、グループを一度に起動する必要があるため、Docker Composeを使用してそれらを一度にロールバックします。



単純なDockerfileがありますが、それは非常に単純ではありません。







次に、JavaをインストールするDockerfileがSSHをプッシュします。 なぜ必要なのか尋ねないでください。 アプリケーションがすべてを起動します。



そして、5つのノードすべてを記述するComposeファイルがあります。







ここにいくつかのノードの説明があります。 今すぐ統合を試みます。 このためのスクリプトがあります。







展開中に色を変更します。







これで、Dockerコンテナが作成されます。 これで起動します。 5つのノードすべてが起動しました。







今、私たちは分散システムが生きていることを攻撃するのを待っています。 少し時間がかかります、それはJavaです。 MasterSlaveが起動したと言っています。







これに加えて、この分散システムから何かを読み取ることができるシンプルなスクリプトがすべてあります。



ノードn1にあるものを見てみましょう。







そこに0が書き込まれます。



誰がマスターであり、誰がスレーブであるかに対する保護がなかったので、n1は常にマスターであるという信念を持っています。 すべてを単純化するために、常に書き込みます。



このマスターで何かを書いてみましょう。



n1 1を置く



ユニットがそこに記録されました。 ここでログにあるものを見てみましょう。







ここにレコードに小さなものがあり、すべてのスレーブに対してこのレコードを展開しました。ここに記録されました。







ノードn3に移動して、そこにあるものを確認することもできます。







書き留めたシングルがあります。



私たちはボーナスを得ることができます、私たちは膝の上に分散システムを書きました、それはうまくいきます。 しかし、それはうまくいきました。



今、私たちは彼女を病気にしようとします。 彼女を病気にするために、Jepsenと呼ばれるこのようなフレームワークを使用します。 Jepsenは、分散システムをテストするための最初のフレームワークですが、1つ微妙な点があります。Clojureで書かれています。 Clojureは知らないLispです。 これは、既存のデータベース、キューなどの既製のテストのセットです。 いつでも自分で書くことができます。さらに、エキゾチックなものを除き、おそらくすべてのデータベースで、見つかった問題に関する記事がたくさんあります。おそらく、ZooKeeperとRethinkDBだけがそれを取得できませんでした。彼らはそれを手に入れたが、他の人と比べて少しだけ。あなたはそれについて読むことができます。

Jepsenの仕組み

ネットワークエラーをシミュレートし、分散システムでランダム操作を生成します。 次に、これらの操作が分散システムと参照動作、この分散システムのモデルに適用された方法、およびこれに問題があるかどうかを調べます。



Jepsenが問題を見つけた場合：







ここで冗談を言いたかった。



Jepsenが何らかの問題を発見した場合、彼はあなたの分散システムの反例を見つけました。 しかし、ジェプセンテストは本質的に確率論的であるため、何も見つからなかった場合、十分に見栄えがよくなかった可能性があります。 しかし、彼がよく検索すれば、彼は何かを見つけるでしょう。 たとえば、RethinkDBの場合、リリースの約2週間前にテストを実行し、多少なりとも機能することを証明しました。



ここでは2週間テストを実行しません。5秒かかります。 Jepsenテストのタスクは、マスターへの書き込み、MasterSlaveからの読み取り、物事の整合性と、マスター/スレーブ複製を正しく記述したかどうかを理解することです。



Jepsenテストは、いくつかの重要な部分で構成されています。







分散システムに適用するランダム操作を生成するジェネレーターがあります。 分散システム自体。そこから起動しました。 Dockerでも、実際の鉄のサーバーでもかまいません。 また、分散システムの動作を記述する参照モデルがあります。 私たちの場合、これはレジスタであり、そこに書いたものです。これを読む必要があります。 複雑なことは何もありません。 Jepsenにはあらゆる場合に膨大な数のモデルがありますが、レジスタとCheckerのみを使用します。これは、モデルとの対応について分散システムに適用された操作の履歴の対応をチェックします。



問題は、JepsenがClojureで書かれており、テストもClojureで書かれる必要があるということです。 それらを他の何かに書くことができれば、それはクールだろう。 しかし、トラブル、トラブル。 Clojureは、常にリストがある言語です。 たとえば、2つの数字を追加する場合は、最初の要素が追加されたリストを作成し、次に2つの数字を追加して、最後に3つの数字を取得します。







呼び出し関数をdefnという別の関数に設定し、最初の引数は関数の名前、引数は関数、関数の本体の順になると言うことができます。 彼女をこのように呼ぶと、彼女は「ハロー、ハイロード！」と言うでしょう。 これは初心者向けのこのようなClojureコースです。



このClojureコースは次のように見えると言えます。







そして今、それは間違いなく右側のものになります。 実際、はい。 ただし、Clojureは少し具体的であるため、フレームで何が起こるかを少なくとも大まかに理解すれば十分です。



だから、ジェプセン。 最初に、テストについて説明します。







このフットクロスは、左から右、上から下に読むのは正しくありません。それは、Lispであるため、内側と外側から読む方が良いからです。 テストの説明を返す関数がありますが、まだ実装していません。 このテストを実行する別の関数にこの説明を追加すると、ディレクトリが返されます。 このディレクトリで、結果キーを使用して何かを選択し、このディレクトリにvalidというキーがあるかどうかを確認します。 存在する場合、テストに合格します。 Clojureはこのように読みます。 最初に脳を破壊する必要がありますが、すべてが明らかになります。



次に、テストについて説明します。







また、テストは引数のない関数です。 彼女は別のテストを拡張しますが、テストはまったく行われず、いくつかのテストが追加されます。 たとえば、JepsenはHTTPについて何も知らないため、データベースとの通信に使用するクライアントの名前。 チェッカー。まだ作成していませんが、作成します。 分散システムの標準として使用するモデル。 ジェネレーターは、ランダムな読み取りおよび書き込み操作を行い、それらの間に10ミリ秒の遅延を挿入し、クライアントでそれらを開始し、5秒間すべて開始します。 さらに、SSHでの作業のためにあります。



次に、読み取りと書き込みについて説明します。 これらも機能です。 これはClojureであり、すべての機能があり、他には何もありません。







クライアントについても説明しますが、最初はHTTPクライアントです。







ここには、HTTPへの書き込み、HTTPでの読み取りのためのいくつかの関数があります。 これがすべて行われる方法については説明しません。 しかし実際には、200が返された場合、すべては問題ありません。 409がHTTP 409 Conflict（非常に便利なコード）である場合、何かが間違っています。 もう少し使用します。



さらに、クライアントについて説明します。







また、これから記述するホストを取得し、クライアントと呼ばれるインターフェースを拡張する関数。 3つの機能があります。 自分自身を返すセットアップ。 クライアントを削除する必要のない分解、内部には何もありません。 このホストに転送する操作を適用するinvoke。 ここでは5秒のタイムアウトがあります。つまり、5秒以内に分散システムが機能しなかった場合、機能しないと言えます。 この読み取りがある場合、HTTP読み取りを実行し、GET要求を行います。 レコードの場合、HTTP書き込み、つまりPOSTリクエストを行います。 MasterSlaveがあり、Masterは1つしかないため、ここで少し変更します。Masterで常に書き込みます。







最後に残ったアイテムはCheckerです。 Jepsen内で線形化可能チェッカーと呼ばれるものを使用できますが、踏んだので使用しません。







どうしたらいいのか分かりません。 したがって、私は自分自身を書きましたが、落ちません。 実際、彼は同じものを使用しますが、最終的には彼が通常は落ちる美しい画像を生成しようとしません。







メガテストを作成しました。実行してみましょう。







分散システム、テストがあり、開始するのを待っています。



leinはClojureのこのようなビルドシステムです。



さまざまなホスト、さまざまな読み取り/書き込みを書き込み始め、ログにも魔法が発生します-読み取り/書き込み、レプリケーション。 最後に、それは「失敗」を告げます。 ここで何かを忘れました。 線形化できないストーリーのリストがありますが、ここでは明らかに混乱しています。



この状況を見てみましょう。







マスター/スレーブで非同期レプリケーションを行うと、スレーブは常に遅れることを誰もが知っています。 線形化可能性の観点からスレーブ遅延とはどういう意味ですか？ つまり、ここで録音が行われ、しばらくしてから録音が複製され、ここで読み取りが行われました。 その結果、読むべきではないものを読みました。 Bを読んで、Aを読まなければなりませんでした。つまり、操作が終了したと思われる時間に戻り、そこから何を読んでいたのかを読みました。 なぜなら、すべてのスレーブがまだレプリケーションフローに追いついていないためです。 したがって、スレーブは常にマスターより遅れます。



あなたは確かにこれは幼稚園だと言うでしょう、大人の方法ですべてをしましょう。 同期レプリケーションを書きましょう、私たちは賢いです。 非同期とほぼ同じで、同期のみです。







分散システムに書き込む1つの関数を再定義します。 彼女は今では賢いやり方でそれをしています。彼女はすべての奴隷が「OK」と言う瞬間を待ちます。 その時だけ彼女は、すべてが記録されたと言います。 奴隷の一人が彼が「大丈夫」ではないと言ったら、それはトラブルが起こって、私たちはそこに行かないことを意味します。



次に、このすべてのバラライカを実行してみてください。 おそらく、あなたは今、何らかのセットアップがあり、すべてがそれほど良いものではないことを感じるでしょう。 25分が経過すると、男がすべてをダウンロードして機能したので、コンパイルされるまで待ちます。 今ではすべてを収集します。動的な言語ではなく、すべてがすぐに機能する場合、ここではすべてが長くて苦痛です。 デプロイするまですべてを書き直すか、書くかを考える時間があります。



マスター/スレーブの同期が開始されました。 すべてがうまくいくことを期待して、Jepsenテストをもう一度実行しましょう。 同期レプリケーションを実行しましたが、何がうまくいかなかったのでしょう。 それは始まり、書き始めましたが、それほど速くはありません。 彼は再び書いて、再び読んで、そこで何かが起こっている。 その結果、再び何か悪いことが起こります。







私たちは再び失敗しました。それは、線形化可能性の点で線形化できない膨大な数の物語を私たちに与えました。



問題は何ですか？



私たちはすべてを正しくやったと思った。 どういうわけか、すべてがひどく判明しました。







写真は、すべてが以前よりさらに悪化していることを示しています。



この状況を想像してください。







マスターノード1があります。操作BとCを記録し、ここにCがあり、ここに複製しました。 HTTPを介してすべてを非同期に実行しますが、これは間違っている可能性があります。 注2では、特定の順序でサインアップしました。 しかし、ノード3では、それらは台無しになりましたが、誤ってそれらを送信しました。 雑誌などがあることを忘れていました。 それらは適用されるべき順序で適用されませんでした。 その結果、Cの代わりにBが得られましたが、ここではそれが何であるか明確ではありません。 BまたはCのいずれか、Cを読む必要があります。したがって、これはこのような災害です。



マスター/スレーブCAPの定理と整合性の観点から、複製は同期複製かどうかに依存します。 非同期の場合、スレーブが遅いため、線形化が不可能であることは明らかです。 同期の観点から、それはあなたがどれだけ曲がっており、すべてを正しく実装するかに依存します。 運がよければ、いい。 私と同じなら、それから悪い。 アクセシビリティの観点から見ると、問題は私たちの奴隷では書くことができず、読むことしかできないということです。 高可用性の観点からは、私たちに寄せられるすべての要求を満たすことはできません。 読むことしかできません。 したがって、利用できません。



したがって、CAP定理は非常に具体的なものです。 定義は厳密であり、実際のデータベースの内容を常に説明するとは限らないため、データベースに非常に慎重に適用する必要があります。 1つのレジスタを記述するため。 すべてのトランザクションと他の操作を同じレジスターに減らすことができれば、これは良いことです。 しかし、通常これは難しいか、不可能です。 可用性それはそのような可用性ですが、待ち時間は何も言いません。 分散システムの一貫性が非常に優れているが、要求に1日に1回応答する場合、本番環境で使用することも非常に困難です。 CAP定理では考慮されないさまざまな実用的な側面があります。 同じパーティションパケットの損失、つまり、不安定なネットワークパーティションがあり、変数がある場合、5秒ごとにいくつかのパケットが失われます。



したがって、個人的な経験によると、人々が脆弱な心で分散システムを書き始めると、遅かれ早かれ知識が結晶化し、すべての松葉杖が新しいバンプを埋め、それは曲線傾斜コンセンサスアルゴリズムのように見えます。 すべてのノードが一般的な状態に同意しようとするが、このアルゴリズムが極端な場合にあまりテストされていない場合、それらはまれであり、なぜそれを心配します。 しかし、一般的な場合のコンセンサスは、障害が発生した場合に何らかの形で障害を乗り切る可能性があるという一般的な条件に関する合意です。



そのような例：







分散システムに書き込むクライアントがあり、そこには7つのノードがあります。 ここで投票しています。 ほとんどのノードがすべてを書き留めておくことに同意した場合、すべてが正常であるように見えます。 読書でも同じこと。 少数のノード（1-2-3）が落ちた場合、それで問題ありません。 すべてが正常であるため、アクセシビリティまたは整合性を失っていません。 多数派が脱落した場合、アクセシビリティは失われます。記録できなくなったが、整合性はまだ失われていないためです。



膝の上でライブデモをしましょう。







定足数を作ろうとします。 ジェプセンをもう一度取得して、取得したものを説明してみましょう。



ここではすべてがもう少し複雑になります。なぜなら、私たちはすでに賢いからです。 最初に、クォーラムのサイズを記述する関数を作成します。







3つのノードの場合、これらは2つ、5つのノードの場合、3つなどです。わずかな過半数です。



次に、マジックの読み取りおよび書き込み機能について説明します。







クォーラムを使用して分散システムから読み取る場合、HTTPを介してすべてのノードにそこにあるものを尋ねます。







次に、クォーラムで機能する関数を呼び出します。これは次のように記述します。







最後に、次のように取得する必要があると言います。







レコードとほぼ同じ。 すべてのノードに書き込みます。書き込まれた内容を確認します。







クォーラムが集まるかどうか：







次に、ユーザーに対する何らかの応答を作成します。







定足数でどう生きるか







これは少し標準的なScalaです。 ここでは、分散システムのさまざまなノードからさまざまなサーバーから届いた一連の回答があります。 これは、たとえば0000のように、ほとんど単なる行のシーケンスです。







それらを自分でグループ化します。







どのグループが会う頻度を調べます：







人気で並べ替え：







最も人気のある回答を取り上げます。







すべてが正しいようです。



次は答えを形成する関数です：







彼女はScalaについても非常に規範的であり、何が起こっているのか完全には明らかではありません。



最も人気のある回答と投票数：







そして、投票数が私たちの定足数以上であるか、この定足数に等しい場合、すべてが大丈夫です、私たちは書き留めました。 正常であり、録音が成功し、定足数が集まったと言います。







何がおかしいのでしょうか？



何かが正しくない場合、魔法のHTTP 409 Conflictを言います。







今、私たちはそれをすべて台無しにしようとします：







そしてやり直してください。



ここで、魔法のスクリプトをもう一度試します。 ノードn2にあるものを見てみましょう。







今、それは沈黙している、そのような瞑想的なプロセス。 もうほとんど。 彼女がタップするのを待っています。 ノックアウト。



ノードn2にあるものを見てみましょう。







0があります。ここで何が起こったか見てみましょう。







ローカル読み取り、5票で0の読み取りがあり、通常はクールです。 真の分散システム。



そこに何かを書きましょう：







そこに小さなものを書きました。 彼女はサインアップしました：







ここでは、このユニットを他のノードに展開しました。 ここには、5票の定足数があります。 すべてがうまくいくようです。



ジェプセンに戻ります。 クォーラムがあるため、クォーラムには多くのマスターを含めることができます。 一般に、定足数のようなものはありません。



クライアントで松葉杖を削除します：







そして、すべてを再起動して、整合性テストを再度実行したときにクォーラムに何が起こるかを確認します。 コードを悪用した場合は、すべての力で。



それは書き始めました、多くのすべてがここで起こっています。



最後に、それは私たちに真実を告げました：







すべてがうまくいくようです。 しかし、私はこれについてあなたに言った、ジェプセンはテストのそのような確率論的性質である。 したがって、ここでは5秒ではなく15をオンにします。







そして、信頼性のために、このテストを再度実行してください。 彼が私たちに他の何かをもたらすかもしれないという希望で、バグの発見は確率的です。 非常に興味深いリラックスしたプロセス。 二度目の試みで、それが私たちのために何かを見つけることを期待しましょう。 今、私たちは定足数がどこかでうなり声を上げることを期待して、彼女をより長く15秒運転しています。 もうほとんど。 誰もが彼が教えてくれることを楽しみにしています。 それは私達に失敗を告げた：







何を期待していましたか。 ここで何が失敗しましたか？



これらの2つの関数を異常に見てみましょう。







ここで何かが間違っています。 まず、Scalaであるため、常に何かが間違っている可能性があります。 第二に、ロジックに何らかの問題があります。



この一連のエントリを見てみましょう。







2つのクライアントがあります。 ここで操作Aを記録し、ノードが「OK」と言って、書き留めて、ここに定足数を得ました。 しかし、Aを記録したことをクライアントに伝えるまで、ここではより高速なクライアントが実行され、Bを記録することができました。ノードはクォーラムが一緒になったことを彼に伝えました。 このクライアントにBを記録したことを伝え、これにAを記録したと言いました。それから何かを読みました。ここで何を読みましたか？







時間が短いので、ここでBを読むことをお勧めします。これはすべて線形化可能ではありません。 私たちはAを読まなければならなかったので、そのような状況があるべきではないので。 システム内の競合を解決する必要があるためです。



これを回避するために、RAFTまたはPAXOSアルゴリズムの作成者でない限り、車輪を再発明して定足数を自分で記述する必要はありません。 このアルゴリズムは、私たち全員が通常の分散システムを作成するのに役立ちます。



PAXOS＆RAFTクォーラムアルゴリズムは状態マシンを記述し、状態マシンは状態間を行き来します。 これらの遷移はすべて記録されます。







これらのアルゴリズムは、このログで操作合意の順序を記述します。 ウィザードの選択、操作の適用、このジャーナルをノードでソートする方法について説明します。 しかし、すべてのノードに同じジャーナルがある場合、このジャーナルを最初から最後まで実行する有限状態マシンは、すべてのノードで同じ状態になります。 それはとても良いようです。



問題は、PAXOSが非常に複雑であることです。 数学者のために数学者によって書かれています。 それを実装しようとすると、PAXOS実装の別のバリエーションがありますが、その中には多くのバリエーションがありますが、その数を考えるのは恐ろしいことです。 それは実際には人々のためではなく、フェーズに分割されていません。 これは、数学的構造を記述する巨大なフットクロスです。 よく考えなければなりません。 PAXOSとPAXOS実装のこれらすべてのバリエーションは、本書で記述されているものを、実稼働で使用できる実際の実装に向けてどのように考えるかについてのものです。



これを防ぐために、このようなRAFTアルゴリズムがあります。 それはより新しく、すべての問題を考慮し、優れたコンセンサスアルゴリズムを実装するために必要なすべてのステップを説明しています。 そこはすべてクールです。 膨大な数の異なる実装があります。







これはJava専用ですが、PHPでもすべての言語の実装があると思いますが、理由は明らかではありません。 このライブラリを使用して、自分でテストしてみてください。 すべてが正しいRAFTを実装しているわけではありません。 私はakka-raftを使用しようとしましたが、これは動作するように見えますが、何らかの理由でJepsenテストに合格しませんでした。



合意アルゴリズムは、MongoDBの3番目のバージョンでもRAFTが登場した場所で多く使用されています。 Cassandraでは、PAXOSは一生ものでした。多くのデータベース、キューシステムでは、成熟に達すると、遅かれ早かれコンセンサスアルゴリズムが現れます。



一般に、分散システムを作成するとき、多くの方法があることを理解する必要があります。これらのパスが存在することを知っておく必要があり、独自のパスをもう1つ実行しないでください。パスを選択するときは、すべてのパスが整合性、遅延、帯域幅、およびその他の異なるものの間の妥協点であることを理解する必要があります。この妥協点を理解し、それを対象分野に適用できれば、すべてが問題ありません。







これらのアプローチのどれが優れているかは言えません。それはすべてあなた次第です。それはすべてあなたのビジネスタスクに依存します。これらは単なるツールです。





レポート：分散システムの恐怖と嫌悪感。