C ++でアクターを使用して15年以上にわたって埋めたバンプに関する最後の記事へのコメントで、 SObjectizer-5に 「 すぐに使える 」ディストリビューションがないというトピックが再び取り上げられました。 これらの質問にはすでに何度も答えていますが、これだけでは不十分であることは明らかです。

SObjectizer-4には分散性がサポートされていたため、SObjectizer-5には分散性がありませんが、SObjectizerによって解決されるタスクの範囲が拡大し、SObjectizerアプリケーションの負荷が大きくなると、いくつかのレッスンを学ぶ必要がありました：

• タスクのタイプごとに、独自の専用プロトコルを持つことが望ましいです。 大量の小さなメッセージの交換は、その一部の損失はひどいものではないため、大きなバイナリファイルの交換とは非常に異なります。
• 非同期エージェントにバックプレッシャーを実装すること自体は簡単なことではありません。 また、ネットワーク経由の通信もここに混在すると、状況はさらに悪化します。
• 今日、分散アプリケーションの一部は、C ++ではなく、他のプログラミング言語で確実に記述されます。 したがって、相互運用性が必要であり、C ++とSObjectizerによって強化された独自のプロトコルにより、分散アプリケーションの開発が妨げられます。

さらに記事では、トピックをより詳細に開くようにします。

前文

最初に、前提条件を定式化しようとしますが、それなしでは、アクターフレームワークに独自のトランスポートプロトコルを使用する意味はありません。

透過的なメッセージの送受信

そのままの配布は、透過的である場合に適しています。 つまり リモート側にメッセージを送信するときは、アプリケーション内でメッセージを送信するのと同じです。 つまり エージェントがsend <Msg>（ターゲット、...）を呼び出し、すでにフレームワークがターゲットが他のプロセスまたは別のノードであると判断した場合。 その後、シリアライズし、メッセージを送信用のキューに入れて、何らかのチャネルに送信します。

そのような透明性がなく、リモート側にメッセージを送信するためのAPIが同じプロセス内でメッセージを送信するためのAPIと著しく異なる場合、フレームワークに組み込まれたメカニズムを使用する利点は何ですか？ 既製のMQブローカー、ZeroMQ、RESTful API、またはgRPCなどを使用した方がよいのはなぜですか？ このテーマで自転車を所有することは、ずっと前にはるかに大きな力で開発されている既製のサードパーティ製ツールよりも優れているとは考えられません。

メッセージを受信する場合も同様です。 エージェントにとって、近隣エージェントからの着信メッセージがリモートホストからの着信メッセージと変わらない場合、これは、1つの大きなアプリケーションを1つまたは複数のノードの異なるプロセスで動作できる部分に簡単かつ自然に分割できるようにするものです。 ある方法でローカルメッセージを受信し、別の方法でリモートサイトからメッセージを受信した場合、自分の自転車の利点ははるかに少なくなります。 繰り返しますが、なぜ既存のMQブローカーの1つを使用せず、自分の自転車を優先するのかが明確ではありません。

アプリケーショントポロジの透明性

分散アプリケーションのすべてのノードが互いに接続されていると便利です。

この場合、ノードAからノードEにメッセージを送信してもまったく問題はありません。

実際には、トポロジはそれほど単純ではなく、いくつかのノード間に直接接続がない状況で作業する必要があります。

この場合、ノードAはノードEにメッセージを直接送信できません。そのため、中間ノードDのサービスを使用する必要があります。当然、アクターフレームワークを使用するプログラマーは、メッセージ転送ルートの選択について何も知らないようにしたいと思います。 プログラマーがAからEへのメッセージがDを通過することを明示的に示す必要がある場合、そのような配布から私たちが望むほど多くの意味はないので。

チャネルの数とタイプを最小限に抑える

たとえば、2つのノードで3種類のトラフィック（たとえば、確認を伴う通常のトランザクションフロー、調整情報の定期的な交換、テレメトリー）を交換する必要がある場合、理論上、これら2つのノード間に3つの異なるチャネルを作成することが可能です。 1つ目はトランザクショントラフィック、2つ目は調整ファイル、3つ目はテレメトリです。

実際にのみ便利ではありません。 チャンネルが少ないほど良い。 1つのチャネルだけで3種類のトラフィックすべてを送信するのに十分であれば、プログラマー自身にとっても簡単になります。DevOpsは間違いなく感謝します。

分散アプリケーションのトポロジの問題を解決するには、チャネル数を最小限にすることも重要です。 したがって、ノードAとEが相互作用する必要がある場合、この相互作用のためにAとDの間に3つの異なるチャネルを作成し、次にEとDの間にさらに3つのチャネルを作成するのが便利ではないでしょう。

したがって、「すぐに使える」優れた配信は、同じ通信チャネルを介してさまざまな種類のトラフィックを駆動できるはずです。 彼女がうまくいかない場合、トラフィックの種類ごとに異なる種類のトランスポートを使用する方がはるかに簡単です。

まあ、実際には、落とし穴自体

したがって、組み込みの配信は、ローカルメッセージングと違いがなく、それ自体がトポロジを決定し、メッセージの最適な配信ルートを選択し、同じ通信チャネルを介して異なるタイプのメッセージを送信できる場合に適しています。 このような配布の実装では、いくつかの問題に直面する必要があります。 「重要度」や「重要度」の程度で並べ替えようとせずに、ランダムな順序でそれらのリストを示します。 ええ、はい、リストは決して完全ではありません。 これは私がすぐに思い出したことです。

アプリケーションとトランスポートエージェント間のバックプレッシャー

非同期メッセージングは​​、バックプレッシャーの良い友達ではありません。 send <Msg>（ターゲット、...）を実行するエージェントは、受信者のキューに未処理のメッセージがたくさんある場合、送信呼び出しで一時停止することはできません。 ターゲットがリモート側の場合、次のものが得られます。

• リモート側に送信する必要があるメッセージのキューがあります。 これらはまだシリアル化されていないため、適切にシリアル化して、チャネルに送信する準備をする必要があります。 メッセージを任意の形式に変換するエージェントが処理できるよりも多くのメッセージを送信エージェントが生成する場合、このキューは非常に急速に大きくなります。
• まだチャネルに送られていないデータを送信するためにすでに準備されているバッファー（またはバッファーのセット）があります。 ネットワークギャップが発生すると、チャネルへの書き込み速度が低下すると、これらのバッファーのボリュームが増加します。

ここでは、さまざまなアプローチを使用できます。 たとえば、同じエージェントがメッセージを受信し、それらをシリアル化し、チャネルに書き込みます。 この場合、シリアル化されたデータ用に制限されたサイズのバッファーがありますが、まだシリアル化されていないメッセージのキューのサイズに影響を与える機会はほとんどありません。 また、2つの異なるエージェントがあります。1つはメッセージを受信し、バイナリデータでバッファにシリアル化し、2つ目のエージェントはこれらのバッファをチャネルに書き込む役割を果たします。 その後、メッセージキューとバッファキュー（およびこれらのバッファのサイズ）の両方が、ネットワークおよび/またはアプリケーション自体の何らかの種類の中断とともに増大する可能性があります。

簡単な解決方法は、過剰分を「カット」することです。 つまり チャネルの速度が低下し始めた場合、キューが特定のサイズを超えて大きくなることを許可しません。 そして、いくつかのデータ（たとえば、最も古いデータまたは最も新しいデータ）を捨てるだけです。 しかし、これはいくつかの種類の解決策を必要とするいくつかの問題につながります：

• これらのバッファのサイズは、できるだけ小さく失い、小さなプラグを落ち着いて生き残るために調整するのに適しています。 これらのパラメーターの設定には頭痛の種があります。 これらのパラメータが実行時に現在の条件に適応しなければならない場合はさらに楽しいです。
• 適用されたアプリケーションロジックでは、何らかの方法でメッセージをスローするという事実を修正する必要があります。 大まかに言って、IDがID1のメッセージAがネットワークプラグのためにスローされた場合、このトレースがログに表示されるはずです。 そうしないと、トランザクションXが開始され、送信ステージAに到達し、移動せずに「ハング」した理由が理解できません。

ここで、通信チャネルが信頼できず、いつでも壊れる可能性があるという事実の問題を追加します。 これは短期的なギャップである可能性があります。この場合、送信のためにすでに準備されているものをメモリに保存することが望ましいです。 また、チャネルに書き込むためにバッファにすでに蓄積されているすべてのものを捨てる必要がある長いギャップがあるかもしれません。

さらに、「長い」という概念は、アプリケーションごとに異なる場合があります。 どこかで「長い」とは数分、あるいは数十分です。 また、メッセージが1秒あたり10,000のレートで送信される場合、わずか5秒のギャップが長いと見なされます。

アプリケーションからトランスポートエージェントへの対話の問題は、通常、アプリケーションエージェントがメッセージをリモートプロセスに送信していることを知る必要がなく、同じプロセス内の隣接エージェントにメッセージを送信していないことです。 しかし、このことから、発信データの伝送速度が低下したり、チャネルが完全に壊れると、アプリケーションエージェントは発信メッセージの生成をそれほど簡単に停止できなくなります。 そして、適用されたエージェントが生成するものとチャネルに入ることができるものとの間の不一致は、トランスポート層、つまり すぐに使用できる同じ透過的な配布。

トランスポートエージェントとアプリケーションエージェント間のバックプレッシャー

分散アプリケーションのコンポーネントでは、トラフィックは発信だけでなく着信にもなります。 つまり トランスポート層は、I / Oチャネルからデータを読み取り、シリアル化を解除して通常のアプリケーションメッセージに変換します。その後、アプリケーションメッセージは通常のローカルメッセージとしてアプリケーションエージェントに配信されます。

したがって、チャネルからのデータは、アプリケーションがデシリアライズ、アプリケーションエージェントへの配信、および処理を管理するよりも早く到着する可能性があります。 この状況が偶然に残された場合、これはアプリケーションにとってうまくいきません。過負荷が発生し、悪いシナリオでは、パフォーマンスの低下によりパフォーマンスが完全に失われます。

一方、着信トラフィックを処理するときは、以前に読み取ったデータを処理する時間がないときにチャネルからの読み取りを停止するなどの機会を使用する必要があります。 この場合、リモート側は遅かれ早かれチャネルが書き込み可能でないことを発見し、その側でのデータ送信を一時停止します。 何がいいですか。

しかし、問題が発生します：トランスポートエージェントが単にソケットを読み取り、バイナリデータをアプリケーションメッセージにデシリアライズし、これらのメッセージを誰かに送信する場合、トランスポートエージェントはこれらのアプリケーションメッセージに処理する時間がないことをどのように知るのでしょうか？

質問は単純ですが、透過的な配布をそれほど単純ではないようにしようとする場合に答えます。

1つのチャネルで異なる優先度のトラフィックを混合する

同じチャネルを使用して異なるタイプのトラフィックを送信すると、遅かれ早かれ、このトラフィックを優先するタスクが発生します。 たとえば、サイズが数十メガバイトの大規模な調整ファイルがノードAからノードEに送信された場合、処理中に新しいトランザクションでいくつかのメッセージを送信する必要があります。 アプリケーションのトランザクショントラフィックはリコンシリエーションでファイルを転送するよりも高いため、リコンシリエーションファイルの転送を一時停止し、トランザクションでいくつかの短いメッセージを送信して、一時停止した大きなファイルの転送に戻ります。

ここでの問題は、トランスポート層の些細な実装が失敗することです:(

忘れてはいけないのか、忘れないのか？

エージェント/アクターに基づいてアプリケーションを構築する際に、火と忘れのポリシーを使用するのが一般的な慣行であると言っても、私は間違いないと思います。 送信エージェントは受信エージェントにメッセージを単に非同期的に送信し、メッセージが途中で到着したか失われたかを気にしません（たとえば、エージェントの保護メカニズムによって過負荷からスローされたなど）。

トランスポートチャネルを介して大きなバイナリブロック（BLOB）を転送する必要があるまで、これはすべて良好です。 特に、このチャンネルに頻繁に引き裂く性質がある場合。 結局、ブロックを100MiBに転送し始め、50MiBを転送し始め、チャネルが壊れてから復元され、何も送信しなかった場合、誰もそれを好まないでしょう。 または、すべてを新たに再送信し始めました。

分散アプリケーションのパーツ間でBLOBを転送する必要に直面した場合、そのようなBLOBを分割し、小さな部分に転送し、正常に配信された部分を追跡し、配信に失敗した部分を再送信する必要があるという結論に至ります。

このアプローチは、上記の通信チャネルでトラフィックに優先順位を付けるタスクと友好的な関係にあるという点でも役立ちます。 トランスポート層の些細な実装のみがこのアプローチをサポートする可能性は低い...

合計

上記は、アクターフレームワークで配布を透過的にサポートするために重要と考えられるいくつかの前提条件です。 開発者がこの非常に透過的な配布を実装しようとするときに遭遇するいくつかの問題と同様に。 些細な実装はそれほど使用されていないことを理解するのに十分なはずであるように思えます。 特に、要件が非常に異なるさまざまなタイプのタスクを解決するためにフレームワークが積極的に使用される場合。

特定された問題のすべてまたはほとんどを正常にカバーするトランスポート層を作成することは不可能だとは言いたくありません。 私の知る限り、ZeroCのIceに同様の機能が実装されています 。 またはnanomsgで 。 それで可能です

ここには2つの問題があります。

• 高度なトランスポートレイヤーの開発にそれほど投資できますか？ ZeroCの同じIceは、10年半以上にわたって活発に開発および運用されています。 そして、nanomsgの作成者は、ZeroMQの実装に関するこの「犬を食べた」前に。 そのようなリソースと能力を持っていますか？
• 他のプログラミング言語との相互運用性を確保する方法は？ ErlangやAkkaのようなクローズドシステムは優れており、エコシステムの外で何が起こるか心配していません。 C ++用の自作のあまり知られていないアクターフレームワークの場合、状況はまったく異なります。

SObjectizer-4では、これらすべての問題に遭遇しました。 一部は決定し、一部はバイパスし、一部は残った。 しかし、SObjectizer-5を作成する際に、配布の問題をもう一度調べたところ、問題にうまく対処するのに十分なリソースがないことがわかりました。 SObjectizer-5をマルチスレッドアプリケーションを作成する際の作業を簡素化するクールなツールにすることに焦点を当てました。 したがって、SO-5は、単一プロセス内でメッセージをディスパッチする問題を解決します。 さて、プロセス間の通信...

結局のところ、このような通信は、既成のプロトコルと既製のMQブローカーを使用して行うのに非常に便利です。 たとえば、 MQTTを使用します。 もちろん、透過的な配布はありません。 しかし、実際には、高いワークロードや複雑な作業シナリオになると、透過的な分散によるメリットはほとんどないことが示されています。

ただし、エージェント間の通信に効果的に使用できるオープントランスポートプロトコルを誰かが知っていて、プログラミング言語間の相互運用性をサポートしていれば、その実装をSObjectizerで真剣に考えることができます。