分散システムとはどのように実現したか

こんにちは、Habr！



すぐに最高クラスの開発者向けの絶妙なノベルティが登場します-「 リアクティブデザインパターン 」。



この本の著者であるローランド・クーンは、分散システムの分野で第一級のスターであり、Akkaの開発者の一人です。 カットの下で、分散システムに関するプログラマティック記事とGitHub Webサイトに掲載されているアクターモデルの翻訳を提供します



アクターモデルについて私が好きなことを尋ねられたとき、私は通常「分布を正確にモデル化します」と答えます。 これは、分散コンピューティングとは何かを具体的に説明し、その中に見掛け倒しがなく、重要な特性が隠されていないことを意味します。 この記事では、分散モデルについて学んだことをお伝えしたいと思いました。 彼女が読者にも興味があることを願っています。



免責事項：おそらく誰かがこれらの重要なポイントを80年代にすでに述べているでしょう。 申し訳ありませんが、この点について詳しく調べる時間はありませんでした。私は自分で勉強することを好みます。

##開始：Akka型なしアクター

バージョン1.3と2.0の間でAkkaのファイナライズに参加しました。 この期間中、デバイスツールキットとそれが提供する一連の保証の両方でいくつかの基本的な変更を行いました。 すべての変更に対して、彼らは「この機能が確実に分散コンテキストで機能することを保証することが不可能な場合、それを行わない」という黄金律を使用しました。 私たちは、以下の精神で、分布が何であるかを直感的に理解しました。

• メッセージの送信者と受信者は（通信遅延の観点から）非常にリモートシステムに配置できるため、「一部の要求が既に処理されている」ことを知ることはほとんど意味がありません。
• すべての通信は信頼できません。すべてのメッセージは失われ、遅延し、プロセス（アクター）は互いに独立して失敗する可能性があります。さらに、これは1つのマシンとネットワークの異なる部分の両方で発生します。

当時、Akka開発チームは、すべてのアクター間の一貫性に問題があるという信念に深く根ざしており、可能であれば、そのような調整の必要性を回避する必要がありました。 一貫性を実現するには多くの時間がかかります。インストールされると、システム要素はすでに「信号の伝播時間」を考慮してプログラムされていない限り、作業中の「調整ポイント」から遠く離れて結果を台無しにする可能性があります。



ユーザーAPIをどのように配置し、そのような厳しい制限の条件で個々の機能を配置できますか？ アクターモデルでは、3つの特性が定義され、4番目の特性が暗示されています（この暗黙の特性に戻ります）。

• メッセージを送信する
• メッセージが到着すると動作が変化する（つまり、順次処理）
• 追加の俳優の作成

Akkaはこれら3つの機能をすべて実装していますが、独自の方法でメッセージ配信の保証を提供します。 信頼性のある配信の代わりに、オプションの配信が編成されています。 ユーザーが必要な信頼性のレベルを決定することをお勧めします。 つまり、単一の電源障害で十分であるため、（過度の）保持がなければ、配信は真に信頼できるものではないと考えられます。信頼性の問題はありません。 ただし、実際にいくつかのローカルアクターを実行するためだけに長期ストレージを必要とするのは非常に困難です。 ここには重要な制限があります：1対1のユーザーAPIは操作上のセマンティクスに対応します。つまり、ActorRefは常に同じように動作する必要があります。refには信頼性がないため、設定ツールだけでは大きな信頼性を提供することは不可能ref ! msg



ref ! msg



推測されません。



Akkaが提供するその他のオプションを次に示します。

• 必須のペアレンタルコントロール（特に、子役の寿命は親の寿命に制限されます）
• 別名DeathWatchライフサイクル監視

アクターモデルの制限を超えることはそれほど単純ではありません。このためには、アクターがホストされているノードのクラスター内で一貫性を実現する必要があります。 どの状況がノードの致命的な障害と見なされるかについてコンセンサスに達することによってのみ、これらの機能がすべての条件で同じセマンティクスで機能することを保証できます。 私がニュースレターを読むとき、そのような問題が冗談を言うことができないことは間違いありません。 疑問が常に発生します：なぜノードがクラスターからノックアウトされ、なぜそれらを後で返せないのか（説明：ノードが死んでいると宣言されるとすぐに、すべての監視と死の監視は取り消されます。 。

##最初の停止：Akka Typed

アッカアクター間の相互作用は型付けされておらず、最初からイライラさせられました。 メッセージの送信は、オペレーターによって仲介されます!



本質的に、それは「一般から特定へ」の機能です-完全に無制限で、フィードバックはありません。 フィードバックの欠如は、情報の交換には費用がかかるため、分散システムをモデル化するときに行う必要がある譲歩です。 しかし、タイピングに関連する制限は偶然見逃されたようです。アクターがどのように定義されているかを考えると、同じ問題が見られます。これは、一般から特定に機能する部分関数です。 したがって、アクターはブラックボックスに変わります。これは、メッセージを送信すると機能する場合と機能しない場合があります。 したがって、アクターはアクションの大幅な自由を受け取りますが、イベントのダイナミクスとは別に判断することは困難になります。JavaScriptでバブルをタイプセーフなJavaの世界に注入しているようです。



バージョン2.4 AkkaにはAkka Typedが付属しているので、この方法で3回目の要望を明確にします。アクターが受信するメッセージのタイプを制限し、コンパイラーがしきい値から明らかに不正なプログラムを拒否できるようにします。 実際、アクターの定義は、あるタイプの入力メッセージから特定の動作（同じタイプによって制限される）へのパスを記述する不可欠な関数です。 したがって、不適切な入力情報を拒否して、同じタイプのアクターへのリンクを正当にパラメーター化することが可能になりました。

 //  -Scala    dotty type ActorRef[-T] = T => Unit type Behavior[T] = (T | Signal) => Behavior[T] // ,   ,     
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような変更は、内部および補助機能の洗練の繰り返しに触発されますが、静的タイプのアクターだけでなく、メッセージに正しくタイプされたActorRefを含めると、アクター間の通信中に表示されるタイプが時間とともに変化する可能性があります（作業の異なる段階で）。

 case class Authenticate(token: Token, replyTo: ActorRef[AuthResponse]) sealed trait AuthResponse case class AuthSuccess(session: ActorRef[SessionCommand]) extends AuthResponse case class AuthFailure(reason: String) extends AuthResponse
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようにプロトコルをシミュレートし、クライアントにActorRef[Authenticate]



のみを提供する場合、クライアントが完全に間違ったタイプのメッセージを送信するのを防ぐだけでなく、認証の成功に対するセッションの依存性も表現します。 実際、 ActorRef[Sessioncommand]



がなければ、コンパイラはそのようなメッセージの送信を許可しません。

##関連トピック：プロトコル

前の例では、作業のどの段階が対応するプロトコルで記述されているかに応じて、さまざまなタイプのメッセージを使用します。そのようなアプローチは、時間の経過とともに困難になる可能性があります。 別の陰湿な瞬間は、作業の各段階で送信されるメッセージの数を静的にチェックしないことです。クライアントは同じメッセージを繰り返し送信できるだけでなく、その段階からActorRefを保存して下の段階にロールバックできます。 もちろん、そのようなスキームは、異なる時点で同じタイプを繰り返し使用するプロトコルにサイクルが現れるとすぐに破棄されます。



これらの問題に対処するには、多段階プロトコルをその構造のコンテキストで記述する必要があります。 有望なアプローチの1つは「 セッションタイプ 」と呼ばれますが、ここではすべての質問に答えているわけではありません。 たとえば、プログラミング言語で操作の線形性（つまり、時間をさかのぼって以前に利用した情報を使用できないこと）を表現することは依然として問題です。 この種の近似の1つは、 AlcesteのScalaにあるIchannelsライブラリです。

##構成可能性への道

アクターの概念の定式化は、すべてのメッセージに対して単一のエントリポイントがなければならないことを意識的に暗示しています。 このようなエントリポイントは、 context.become(...)



を使用して型指定されていないAkkaで作成するか、ErlangまたはAkka Typedで処理される各メッセージを手配できます。 さまざまなタイプの行動からアクターを構成する場合（つまり、アクターは仲介者によって異なる動作をする）、そのようなエントリポイントを介して到着するすべてのメッセージは逆多重化する必要があります-この方法でのみ、内部ロジックに従って正しい宛先に到着します。 この状況は、 SessionCommand



されていないアクターを操作する場合は少し面倒ですが、Akka Typedは実際の苦痛になります。ここでは、 Authenticate



とSessionCommand



両方がSessionCommand



ような動作を定式化するキャスト操作が必要です。 厳密に型指定されたロジックには、厳密なレイアウトルールが必要です。これは、純粋な関数のレイアウトであれ、分散コンピューティングであれ、普遍的な真実のようです。



Alex Prokopetsは、ベルリンで開催されたScalaDays 2016カンファレンスでのプレゼンテーションで、文字通り私の目を開き、このジレンマから抜け出す方法を指摘しました。 アクターモデルの本質は、異なる目的のために異なるバージョンのアクター（それらへのリンク）の割り当てを必要とするようなものです。 それらから、異なるプロトコルを使用して各仲介者と通信できるより大きなオブジェクトを組み立てることができます。 独立したアクターを作成する場合、次の欠点に直面します。内部の一貫性が失われます。 俳優は、分散したカオスの海の中で、検査された単一の島に変わります。 したがって、コツはアクターを仮想化し、それぞれに独自の識別子を持つ複数の入力ポイントを作成することです。 アレックスはRxJavaのようにストリーミング処理のセマンティクスを使用しますが、π計算を使用してこのような複合アクターの内部レイアウトを整理するというアイデアにすぐに惹かれました。



Akka Typedの上にある種類のセッションDSLの最初のバージョンは、プリミティブアクションと計算の一貫した競争力のある配置のモナド記述に基づいてすぐに作成されました。

 val server = toBehavior(for { backend ← initialize server ← register(backend) } yield run(server, backend)) private def initialize: Process[ActorRef[BackendCommand]] = { val getBackend = channel[Receptionist.Listing[BackendCommand]](1) actorContext.system.receptionist ! Receptionist.Find(BackendKey)(getBackend.ref) for (listing ← readAndSeal(getBackend)) yield { if (listing.addresses.isEmpty) timer((), 1.second).map(_ ⇒ initialize) else unit(listing.addresses.head) } } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

主な抽象化は、指定されたタイプの値を最終的に計算するプロセスです。 順次リンクには、flatMapまたはmapを使用し、fork（プロセス）アクションを使用して競合する実行スレッドを作成します。 結果として生じる完全なプロセスは、単一のアクター内で評価されます（toBehavior関数は、適切なインタープリターでそれをラップします）。 到着すると入力に応答します。これがすべきことです。readAndSealオペレーションは、初期化プロセスの一部として作成されたgetBackendチャネルに利用可能なメッセージが表示されるまでプロセスを一時停止します。

このライブラリのドラフトバージョンで提案されているプリミティブは、π計算のアクションと構成機能に対応しています。

• チャンネル作成
• 送る
• 取得
• シーケンス
• 選択肢
• 並列化

私の頭の中で、すべてがすぐに調整され始め、まるでそれ自体で、完全に再利用可能な行動を構成する世界が出現し始めました。

##深い（はい、深い）失望

次の質問をするとすぐに夢が崩れました。 重要なメッセージ-プロセスの別の要素の次のプロトコルへの道を開くもの-が何らかの理由で失われた場合、どうなりますか。 信頼できる配信を保証しても次の問題は解決しません：他のアクターは最初のアクターから完全に「独立して」拒否することができます。また、チャンネルの録音終了がActorRefに対応する場合、ロケーションの透過性は非常に強力なセマンティック現象であるため、すべての作業の進行はリモートシステムに依存することは論理的です。 この問題を修正するには、受信操作のタイムアウトに上限を設定できますが、この場合、ローカルプロセスが失敗するのを待つ必要があります。 ローカルプロセスもチャネルを介して作業を調整するという事実に基づいて、チャネルがハングすることを意味します。 これは、（分散）ガベージコレクションを使用して解決できるセキュリティ問題です。 （当然、プログラマーのエラーによりチャンネルがハングする可能性があるため、いずれにしても、致命的なリソースリークから安全に再生することが賢明なようです）。



また、紙でπ計算を表現すると、おそらくどこにも移動しないような式で死んだプロセスを分離して排除することが可能であることに気付きました：結局のところ、彼らは他のプロセスに知られていないチャネルで送信または受信を待っています。 実装がScalaファジークロージャに基づいている場合、デッドプロセスを排除するこのような操作は実際には達成できません。



しかし、最大の難点は、π計算の定義機能、つまりチャネルを交換する機能を実際に実装するのが非常に難しいという事実に関連しています。 送信側では、問題は簡単に解決されます。チャンネルは単にActorRefとして提供されます。 ただし、受信者側では、送信されたメッセージが1つの定義特性のみを持つ多くの受信者に配信されるようにする必要があります：現時点では、各受信者はチャネルへのリンクを持ち、受信者は情報を受信する準備ができています。 実際には、メッセージを受信する受信者が1人だけになるようにする必要があります。



非常に高価なので、Akkaは少なくとも基本的なプリミティブで作業する場合は控えなければならないようなグローバルな調整からです。 最も単純なソリューションは、原則として-無限に実質的に制限なしにスケーリングする必要があると想定されています。 私たちはそのような理想に近づくよう努めています。 無限のスケーラビリティは必ずしも必要ではなく、一貫性のあるデータベースが私たちに適している絶対的な現実の状況がありますが、これは私たちが卓越性を追求することを妨げるものではありません。

##丘を登る

チャネルの使用は、レシーバーをシリアル化できないようにする（つまり、ネットワークを介して送信することを許可しない）ことで「修正」でき、受信操作がこれに適さないアクターのコンテキストから行われる場合は例外をスローします。 そのような解決策は、π計算と強く矛盾するだけでなく、コードまたは型レベルで見えない状況に依存する機能がユーザーAPIとしてどこでも定義された関数を提供することは推奨されないため、見苦しいでしょう。



人が読むチャンネルを選択するのは便利なようです：結局、私たちはコミュニケーションします。 私たちはどこかに行って、自分自身で設定した目標を達成するために必要な順序でさまざまな人々と話します。 俳優は次に来るメッセージに対処せざるを得ません。実際には、これは「常に気を散らされている」ことを意味します。 残念ながら、チャネルを自由に選択できることが最も問題があると私たちは確信していたので、別のアプローチを見てみましょう。



代替案の1つは、原子炉について説明したアレックスによって提案されました。 チャネルAPIを使用すると、ストリーミングコンバージョンやその他の反応を添付できます。 これは優れていますが、チャネルへのリンクが別のリアクターに転送され、間違ったコンテキストからの情報の受信によりシステム内でカオスが支配する可能性が残ります。



したがって、ユーザーコードから簡単にアクセスできないAPIの暗黙的なプロパティを取得する操作をプログラムすることがいかに有益であるかを認識しました。 これがまさに、アクターモデルでこのようなトラップを回避する方法です。ここでは、メッセージに応答して実行できるアクションの3つのオプションを定義しますが、アクターは着信メッセージを積極的に要求することはできません。



もう1つの選択肢は...アクターです。 各チャネルは、着信メッセージへの応答方法を記述する動作に基づいて作成されます。 特に、メッセージごとに動作を変更できます。 したがって、別のアクターとの対話を継続し、継続性のあるチャネルを作成して、仲介者に送り返します。 カール・ヒューイットとギャル・アガは、競争をこのモデルの不可欠な部分とは考えていなかったが、このコンセプトを最初から考え、推進してきた方法です。

## 2番目の停止：サブアクター

改善されたモデルは、プロセス作成操作と読み取り操作への引数の削除を伴うチャネル作成操作の暗黙的なパッケージ化として説明できます-プロセスの1つの入力チャネルのみへの読み取りアクセスが保持されます。 シーケンシャルコンポジションでは、同じチャンネルを再利用するオプションがあり、パラレルコンポジションでは、事前に作成された継続チャンネルを通じて結果を送信することができます（必要な場合）。



裸のAkka Typedを超える利点は、継続操作の作成と設定に必要な画面コードを取り除くこと、および単一のアクタをディスパッチモジュールとして再利用することです。 したがって、このようなきめの細かい制御は、アクターの作成とスレッド間通信に一定の法外なコストをかけることなく提供されます。 アクターの動作に関するこのような段階的な記述により、アクターを再利用して構成できると考えられています。

##そしてそれだけですか？

冒頭で、「俳優は分布を正確にモデル化する」というステートメントについて何かを理解したと述べました。 問題を解決する上でこのモデルが正確にどのように機能するかを実感しただけです。明らかに、アクターモデルのすべての詳細と分散システムのセマンティクスは実際には1つの全体に結合されています。 したがって、プロセス代数に関するWikipediaの記事では、π計算とアクターモデルは実際には2倍であると述べていますが、私はもうそうは思いません。 私の意見では、π計算ではプロパティが多すぎるため、無限にスケーラブルな実装を作成できません。 特に、 非同期π計算の表現力に関するChris Makeclejonの研究について、このテーマに関していくつかの新しい研究が登場しました。 また、なぜそれを適用すべきかを説明する非常に有用なπ計算FAQも見つけました。 π計算のツールは、プロトコルの形式的な記述と検証にとって興味深いものであり、この場合、この計算の表現力は完全には使用されていません-そして、このような計算に基づいて（適応なしで）エンドユーザー向けのAPIを書くことはできません。



一方、アクターモデルを微積分の形式で完全に形式化する方法は見つかりませんでした（数学的に適切に他のタイプの微積分に変換することは不可能であるため、すべての美しい定理が満たされるように、すべての等価および合同関係を観察します）。 そのような形式化は必要ないかもしれませんが、外部プロトコルで記述されたアクターの動作に制限を加え、コード生成を使用してソースレベルに上げます（または、Alcesteで行われるようにセッション全体をコーディングするか、適切に接続されたメッセージクラスを生成します）。特定のエンドユーザーAPIで達成可能なセキュリティのレベルに応じて）。 または、π計算プロセスとして表現でき、ツリーの外部で分析できる動作の抽象的なツリーで、アクターの動作を抽出する必要があります。 概念的な観点から、次のことが最も難しいように思われました。任意の配信で信頼性の低いメッセージを送信するという基本的な動作は、自明ではないπプロセスに対応し、組み合わせの爆発につながり、可能性の数を大幅に減らします。 (?) : , .



– - , . – .