最初の部分で始まった話を締めくくる。 今日は、日常業務でSObjectizerを使用して長年にわたって発生したいくつかのレーキについて見ていきます。

レーキのリストを続けます

人々は同期を望んでいます...

アクターモデルのアクターとSObjectizerのエージェントは、非同期メッセージを介して通信します。 そして、これがアクターのモデルがいくつかのタイプのタスクにとって魅力的である理由の1つです。 非同期性は基礎の1つであり、ボーナスの1つであるように思われるので、健康を活用して楽しんでください。

しかし、違います。 実際には、リクエストはすぐにSObjectizerのエージェントの同期相互作用の可能性を作り始めました。 非常に長い間、私はこれらの要求に抵抗しました。 しかし、結局彼はあきらめました。 SObjectizerで1つのエージェントから別のエージェントに同期リクエストを実行する機能を追加する必要がありました。

コードでは次のようになります。

//  . struct get_messages final : public so_5::signal_t {}; ... //   ... auto msgs = request_value<std::vector<message>, get_messages>(mbox, so_5::infinite_wait); // ...  . for(const auto & m : msgs) ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはrequest_value関数の呼び出しです。この関数は同期要求を実行し、要求結果が受信されるまで現在のスレッドの実行を一時停止します。

この場合、応答でメッセージオブジェクトのベクトルを取得するために、get_messagesタイプのリクエストを送信します。 そして、制限時間なしで答えを待ちます。

ただし、SObjectizerはこれをすべてメッセージを通じて同じように実装します。 request_value内で、メッセージがターゲットエージェントに送信され、通常の方法で受信および処理されます。 つまり 受信者は、同期要求が自分に届いたことも知りません。彼にとっては、すべてが通常の非同期メッセージのように見えます。

 class collector : public so_5::agent_t { public : ... virtual void so_define_agent() override { //   . so_subscribe(mbox).event<get_messages>(&collector::on_get_messages); ... } private : std::vector<messages> collected_messages_; //  ,     get_messages. std::vector<messages> on_get_messages() { std::vector<messages> r; std::swap(r, collected_messages_); return r; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり コレクター:: on_get_messages内では、メッセージ受信エージェントは、get_messagesを通常の非同期メッセージとして受信したか、同期要求の一部であるかを判別できません。

しかし、内部では、標準C ++ 11ライブラリのstd :: promiseおよびstd :: futureに基づいて構築された、あまり複雑ではないメカニズムが隠されています。

まず、同期要求を送信するとき、受信者は通常のメッセージを受信しませんが、内部のstd :: promiseオブジェクトとともに、厄介なメッセージを受信します。

 struct special_message : public so_5::message_t { std::promise<std::vector<messages>> promise_; ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメッセージは、サブスクライブ時にSObjectizerによって自動的に生成される特別なハンドラーに入ります。

 collector * collector_agent = ...; auto actual_message_handler = [collector_agent](special_message & cmd) { try { cmd.promise_.set_value(collector_agent->on_get_messages()); } catch(...) { cmd.promise_.set_exception(std::current_exception()); } }; do_special_subscribe<get_messages, special_message>(mbox, actual_message_handler);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このトリッキーなハンドラーはユーザー定義のメッセージハンドラーを呼び出し、その後、戻り値（またはスローされた例外）をトリッキーなメッセージからstd :: promiseオブジェクトに保存します。 これにより、要求送信者がスリープしているstd :: futureがトリガーされます。 したがって、request_valueからの戻りが発生します。

明らかに、エージェント間の同期相互作用は、デッドロックを取得する直接的な方法です。 したがって、SObjectizerにはrequest_valueがありますが、慎重に使用することをお勧めします。

個人的に面白いのは、request_valueの有用なアプリケーションがすぐに見つかったことです。 過負荷からエージェントを保護するメカニズムで。 この保護がコレクター/パフォーマーのペアを介して行われる場合、パフォーマーはrequest_valueを介してメッセージの次のバッチに適用すると便利です。 また、コレクターエージェントとパフォーマーエージェントは原則として異なるスレッドで動作するため、ここでデッドロックが発生する危険性は最小限に抑えられます。

この物語の教訓はこれです：理論モデルの原則を厳守することは良いことです。 しかし、実際にこれらの原則と矛盾する何かを行うように促されている場合は、耳を傾けることは理にかなっています。 役に立つものが出てくるかもしれません。

箱から出してすぐに配布：すべてがそれほどバラ色ではありません

SObjectizer-4では、開発者はすぐに分散アプリケーションを作成できました。 TCP / IPの上に独自のプロトコルがありました。これは、C ++データ構造をシリアル化する独自の方法です。

一方で、それは非常にクールで楽しかったです。 単純なジェスチャーの助けを借りて、分散アプリケーションの一部が実行されているノード間でメッセージを自動的に飛ばすことができました。 SObjectizerは、データのシリアル化とシリアル化解除、トランスポートチャネルの制御、ブレーク時の再接続などを処理しました。

一般的に、最初はすべてがクールでした。

しかし、SObjectizerで解決されるタスクの範囲が拡大し、アプリケーションの負荷が増大するにつれて、多くの問題が発生しました。

• まず、タスクの種類ごとに、独自のプロトコルを持つことが望ましいです。 というのは、テレメトリの広がり、つまり 多数の小さなメッセージの交換（一部の損失はひどくない）は、大きなバイナリファイルの交換とは大きく異なります。 たとえば、大きなアーカイブまたはビデオファイルを交換する必要があるアプリケーションは、現在の気温のセンサーから数千のメッセージが送信されるアプリケーション以外のプロトコルを使用する必要があります。
• 第二に、非同期エージェントのバックプレッシャーの実装自体は簡単なことではありません。 また、ネットワーク経由の通信もここに混在すると、状況はさらに悪化します。 ネットワークの遅延やノードの1つでのブレーキングは、他のノードで大量の未配信メッセージの蓄積を招き、これはかなり無駄になります。
• 第三に、大規模な分散システムが1つのC ++でしか書けない時代はずっと前に終わりました。 今日、特定のコンポーネントは他のプログラミング言語で作成されます。 つまり、相互運用性が必要です。 これは、C ++とSObjectizerによって強化された独自のプロトコルは役に立たないが、分散アプリケーションの開発を妨げるという事実に自動的につながります。

したがって、SObjectizer-5には配布をサポートするツールがありません。 私たちは、事実上の標準プロトコルを介して、エージェントと外界とのコミュニケーションを促進することを目指しています。 これは、独自の自転車を発明するよりも優れています。

多くのエージェントは問題であり、解決策ではありません。 SEDA-wei forever！

まあ、このトピックは個人的に非常に似ています。 彼らはマーケティングと常識が互いに矛盾する可能性があることをもう一度強調するため:)

マーケティング資料のほとんどすべてのアクターフレームワークは、アクターが軽量エンティティであると必然的に述べており、アプリケーションでは、少なくとも10万人、少なくとも100万人、少なくとも1000万人のアクターを作成できます。

準備ができていないプログラマーがプログラムで100万人の俳優を作成する機会に直面すると、彼の屋根はわずかに破壊されるかもしれません。 アプリケーション内の各アクティビティをアクターとして配置するのはとても魅力的です。

プログラマーはそのような誘惑に負けて、すべての人のためにアクターを作成し始め、すぐに彼が自分のプログラムに何万または何十万ものアクターがいることに気づきます...これは、2つの問題の少なくとも1つにつながります。

100万人のアクターがいるアプリケーション内で何が起こっているのでしょうか？

多数のアクターを作成するときに発生する可能性のある最初の問題は、プログラムで何が起こっているのか、プログラムがこのように機能する理由、およびプログラムがさらに動作する方法についての理解不足です。

起こるのは、鳥の群れの効果と呼ばれるものです。群れの中の個々の鳥の行動は、いくつかの単純なルールのセットで記述できますが、群れ全体の構成は複雑で、ほとんど予測できません。

同様に、多数のエージェントを持つアプリケーションの場合。 各エージェントはシンプルで理解可能なルールに従って動作できますが、アプリケーション全体の動作を予測することは困難です。

たとえば、一部のエージェントは突然生命の兆候を示しなくなります。 彼らのように見えますが、彼らの作品は見えません。 そして、突然彼らは「目を覚まし」、他のエージェントに十分なリソースがないほど活発に働き始めます。

一般に、1万人のエージェントがいるアプリケーション内で発生していることを追跡することは、100人のエージェントのみが動作するアプリケーションよりもはるかに複雑です。 1万人のエージェントがいて、そのうちの1人の負荷がどれほど高いかを知りたいと想像してください。 これはすでに問題になると思います。

ところで、Erlangの素晴らしい機能の1つは、Erlangが内省のためのツールを提供していることです。 開発者は、少なくとも自分のErlang仮想マシン内で何が起こっているかを見ることができます。 プロセスの数、各プロセスが消費する量、キューのサイズなど。 しかし、Erlangには独自の仮想マシンがあり、それは可能です。

私たちがC ++について話しているなら、私が知っている限りでは、C ++フレームワークはこの分野でErlangよりもはるかに遅れています。 一方では、これは客観的です。 それでも、C ++はネイティブコードにコンパイルされ、ネイティブコードの一部を監視することははるかに困難です。 一方、このような監視の実装は重要な作業であり、多くの労力と投資が必要です。 したがって、純粋な熱意だけで開発されたオープンソースフレームワークの高度な機能を期待することは困難です。

そのため、C ++アプリケーションで多数のエージェントを作成し、Erlangと同じ高度な監視ツールを持っていない場合、アプリケーションを監視してそこで機能するものを理解することは困難です。

突然の活動の爆発

考えられる2番目の問題は、アクターの一部が突然、利用可能なすべてのリソースを消費し始めるときのアクティビティの突然のバーストです。

アプリケーションに10万人のエージェントがいると想像してください。 それぞれが何らかの操作を開始し、タイマーを設定して操作のタイムアウトを制御します。

アプリケーションの一部がスローダウンし始め、以前に開始された操作がタイムアウトによって落ち始め、タイムアウトの期限切れに関する保留中のメッセージがバッチで到着し始めたとします。 たとえば、2秒以内に1万個のタイマーが機能しました。 これは、保留中のメッセージハンドラー1万個を呼び出すことを意味します。

そして、ここでは、何らかの理由でそのような各プロセッサが10ミリ秒を費やすことが判明する場合があります。 これは、1万件の保留メッセージをすべて処理するのに100秒かかることを意味します。 これらのメッセージが4つの並列スレッドで処理される場合でも。 しかし、まだ25秒です。

この25秒間、アプリケーションの一部が愚かにフリーズすることがわかりました。 そして、これら1万件の保留中のメッセージを処理するまで、他には何も応答しません。

トラブルが一人で来るわけではありません...

最も悲しいことは、上記の問題の両方が完全に重複していることです。 突然の活動の急増により、アプリケーションの予期しない動作に直面し、鳥の群れの影響により、何が起こっているのか理解できません。 アプリケーションは機能しているようですが、どういうわけか機能しません。 そして、それについて何をすべきかは明確ではありません。 もちろん、あなたは愚かにアプリケーションを破って、それを再起動することができます。 しかし、これは10万人のエージェントを再作成し、ある状態でそれらを復元し、ある外部サービスへの接続を再開することなどを意味します。 残念ながら、このような再起動には費用はかかりません。

そのため、アプリケーションに多数のエージェントを作成する機能を、問題を解決する方法として扱うべきではありません。 そして、自分自身をさらに問題にする方法として。

もちろん、解決策は簡単です。より少ないエージェントで行う必要があります。 しかし、それを行う方法は？

SEDAアプローチ

SEDA（Staged Event-Driven Architecture）アプローチを導入すると、頭脳が非常にうまく機能します。 2000年代初頭、小さなグループの研究者がJavaで同じ名前のフレームワークを開発し、それにより、基になるアイデアの実行可能性を証明しました：複雑な操作の実行をステージに分割し、各ステージに個別の実行フロー（またはスレッドのグループ）を割り当て、ステージ間の相互作用を整理します非同期メッセージキュー。

支払い要求に対応する必要があると想像してください。 リクエストを受信し、パラメータを確認してから、このクライアントの支払いの可能性を確認し（たとえば、彼が支払いの1日の限度を超えたかどうか）、支払いのリスクを評価します（たとえば、クライアントがベラルーシからで、支払いが何らかの理由でバングラデシュから開始された場合） 、その後、これは疑わしい）、すでに資金を引き落とし、支払い結果を生成しています。 ここでは、単一の操作を処理するいくつかの段階を明確に見ることができます。

アプリケーションで100万人のエージェントを作成できるため、支払いごとに1人のエージェントを作成する必要があります。エージェントは、自分ですべての段階を一貫して実行します。 つまり 彼自身が支払いパラメータを検証し、1日の限度とその超過を決定し、不正監視システムなどに要求を出します。 概略的には、次のようになります。

SEDAアプローチの場合、各段階で1つのエージェントを実行できます。 1人のエージェントは顧客からの支払い要求を受け入れ、2番目のエージェントに転送します。 2番目のエージェントは要求パラメーターを確認し、有効な要求を3番目のエージェントに送信します。 3番目のエージェントは制限などをチェックします。 概略的には、次のようになります。

エージェントの数は桁違いに削減されます。 これらのエージェントの監視ははるかに簡単です。 このようなエージェントの過負荷からの保護は大幅に簡素化されています。 これらのエージェントは、DBMSで動作する場合、一括操作を使用する機会を得ます。 つまり エージェントは、たとえば1000個のメッセージを蓄積し、データベースへの2〜3回の一括呼び出しでそれらすべてを処理します。 エージェントの活動に影響を与える機会があります。 たとえば、外部の不正監視システムが突然落ちて、1万件の否定的な回答を生成する必要がある場合、これらの1万件の回答すべてをすぐに送信するのではなく、たとえば10秒間均等に広めることができます。 したがって、システムの他の部分を過負荷から保護します。

追加のボーナス：1つのエージェントのみが特定のステージにサービスを提供する場合、このステージでのトランザクション処理の優先順位付けタスクは大幅に簡素化されます。 たとえば、スケジュールされたトランザクションよりも優先度の高いオンラインクライアントからのトランザクションを処理する必要がある場合。 SEDAアプローチの場合、これは各エージェントが各トランザクションを担当する場合よりも簡単に実装されます。

さらに、SEDAアプローチのフレームワーク内であっても、アクターモデルが提供するメリットを活用しています。 しかし、文字通り数万人ではなく数十人の俳優に制限されています。

おわりに

結論として、俳優のモデルはクールなジョークですが、特効薬ではありません。 いくつかのタスクでは、アクターのモデルはうまく機能しますが、そうでないものもあれば、まったく機能しないものもあります。

しかし、アクターのモデルがタスクに合っていても、それでもいくつかのことは実際には痛くないでしょう：

• まず、開発者自身が肩に頭を抱えている必要があります。 開発者がアプリケーションで数十万人のアクターを意識せずに作成し、過負荷の問題を考えず、アクティビティの自発的なバーストが何であるかなどわからない場合、アクターのモデルを使用すると、「ベアスレッド;
• 第二に、アクターフレームワークが開発者にすべての可能な支援を提供することは良いことです。 特に、アクターを過負荷から保護するようなこと、エラー処理、およびアプリケーション内で起こっていることの内観。 そのため、SObjectizerの機能をこの方向に徐々に拡張しています。 メッセージの制限、例外への反応、統計情報の収集、情報の監視、メッセージ配信メカニズムをトレースするためのツールなどをすでに追加しています。

ところで、俳優のフレームワーク内のこのような補助ツールのセットは、私の意見では、フレームワークの成熟度を決定する兆候です。 フレームワークでアイデアを実現し、そのパフォーマンスを示すことはそれほど難しくありません。 あなたは数ヶ月の仕事を費やし、非常に実用的で興味深いツールを手に入れることができます。 これはすべて純粋な熱意で行われます。 文字通り：私はそのアイデアが好きで、それを望み、やりました。

しかし、統計の収集やメッセージの追跡など、あらゆる種類の補助手段で発生したことを装備することは、すでに退屈なルーチンであり、時間と希望を見つけるのはそれほど簡単ではありません。

したがって、既成のアクターフレームワークを探している人への私のアドバイス：アイデアの独創性と例の美しさだけでなく注意を払ってください。 また、アプリケーションで何が起こっているのかを把握するのに役立つあらゆる種類の補助的なものも見てください。たとえば、現在のアクタの数、キューのサイズ、メッセージが受信者に届かない場合、どこに行くのかを調べる...そのようなものを提供し、それはあなたのために簡単になります。 そうでない場合は、さらに作業が必要になります。

さて、私は自分で追加します。上記のレーキから開発者を保護する独自のアクターフレームワークを最初から作成して作成したい場合、これは良い考えではありません。 占領は絶対に恩知らずです。 はい、返済はほとんどありません。 これはすでに確認されています。 人前で。