SObjectizerの使用経験から：有限状態マシンの形式のアクター-それは悪いですか、それとも良いですか？

SObjectizerフレームワーク 、その機能、機能を読者に知ってもらい、C ++ソフトウェアの開発でSObjectizerを使用して14年以上にわたって学んだいくつかの教訓について話を進めることができます。 今日は、ステートマシンの形のエージェントが適切な選択肢ではない場合について説明します。 多数のエージェントを作成する可能性は、それ自体の問題ほど解決策ではありません。 そして、最初のものが2番目のものとどのように関係しているか...

そのため、前の3つの記事（ 1、2、および3 ）で、email_analyzerエージェントが非常に単純なクラスから多少なりとも複雑なクラスに発展する様子を観察しました。 email_analyzerの最終バージョンを見ていた多くの人が、 「しかし、それは非常に難しい、もっと簡単ではないだろうか？」という質問をしたと思う。

エージェントは有限状態マシンとして表されるため、非常に困難でした。 着信メッセージを処理するには、別のメソッド（イベントハンドラー）を記述する必要があります。 エージェントが新しいイベントハンドラを開始するには、現在のハンドラが終了する必要があります。 したがって、要求を送信して応答を受信するには、エージェントは現在のハンドラーを完了して、応答を受信したときにディスパッチャーが適切なハンドラーを呼び出せるようにする必要があります。 つまり 代わりに：

void some_agent::some_event() { ... //  . send< request >(receiver, reply_to, params…); //     . auto resp = wait_reply< response >(reply_to); ... //  . }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はこのように書かなければなりません：

 void some_agent::some_event() { ... //       . so_subscribe(reply_to).event(&some_agent::on_response); //  . send< request >(receiver, reply_to, params...); //    some_event  . //         //  ,   . } void some_agent::on_response(const response & resp) { ... //  . }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、結果のemail_analyzerエージェントの量と複雑さ。

おそらくこのアプローチには、書き込み量を20〜30％削減するトリックがいくつかありますが、原則として状況は変わりません。

ここで、理解性とコンパクト性に大きく影響する可能性があるのは、同期操作を伴う線形コードへのコールバックに基づいたイベントモデルからの脱却です。 次のようなもの：

 void email_analyzer(context_t ctx, string email_file, mbox_t reply_to) { try { //   . auto raw_content = request_value< load_email_succeed, load_email_request >( ctx.environment().create_mbox( "io_agent" ), 1500ms, //     1.5s email_file ).content_; auto parsed_data = parse_email( raw_content ); //  -checker-,     //   message chain,     . auto check_results = create_mchain( ctx.environment() ); introduce_child_coop( ctx, disp::thread_pool::create_disp_binder( "checkers", disp::thread_pool::bind_params_t{} ), [&]( coop_t & coop ) { coop.make_agent< email_headers_checker >( check_results, parsed_data->headers() ); coop.make_agent< email_body_checker >( check_results, parsed_data->body() ); coop.make_agent< email_attach_checker >( check_results, parsed_data->attachments() ); } ); // ..      ,   //      . auto check_handler = [&]( const auto & result ) { if( check_status::safe != result.status ) throw runtime_error( "check failed: " + result ); } ); //     0.75s   ,  //      . auto r = receive( from( check_results ).total_time( 750ms ), [&]( const email_headers_check_result & msg ) { check_handler( msg ); }, [&]( const email_body_check_result & msg ) { check_handler( msg ); }, [&]( const email_attach_check_result & msg ) { check_handler( msg ); } ); //     ,    . if( 3 != r.handled() ) throw runtime_error( "check timedout" ); //      ,    . send< check_result >( reply_to, email_file, check_status::safe ); } catch( const exception & ) { send< check_result >( reply_to, email_file, check_status::check_failure ); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、この場合、ErlangやGoなどの言語でこの問題を解決するのに似た、よりコンパクトで理解しやすいコードが得られます。

私たちの経験は、エージェントが「リクエストを送信し、唯一の答えがすぐに待機し始めた」という形式の一連の操作を実行する状況では、有限状態マシンの形式での実装は、コードの量と複雑さの点で不利になることを示唆しています。 単純に応答を待って受信後すぐに作業を続ける代わりに、エージェントは現在のイベントハンドラーを完了する必要があり、他のすべてのアクションは別のハンドラーに移動する必要があります。 エージェントがその存続期間中にN個の連続した非同期操作を実行する場合、このエージェントは（N + 1）ハンドラーを持っている可能性が高くなります。 良くないことは そのようなエージェントの開発と保守には、多くの時間とエネルギーがかかります。

エージェントが何かを待っているたびに、いくつかの異なるメッセージが彼に届き、エージェントがそれぞれに応答する必要がある場合、状況は完全に異なります。 たとえば、エージェントは現在の操作の結果を待ち、その瞬間に操作のステータスをチェックして新しい操作の実行を要求するリクエストがエージェントに届く場合があります。 この場合、各エージェント待機時に予想されるすべてのタイプのメッセージへの応答をペイントする必要があります。また、これにより、エージェントコードが大量かつ理解度の低いヌードルに非常に迅速に変わる可能性があります。

SObjectizerは現在、ステートマシンの形式でのみエージェントをサポートしているため、適用されたエージェントのロジックがステートマシンにどの程度当てはまるかを慎重に評価する必要があります。 あまり良くない場合、SObjectizerは最良の選択ではないかもしれません。コルーチンを使用するソリューションを見るのは理にかなっています。 たとえば、 boost.fiberまたはSynca （ Habrには興味深い記事がありました： No. 1およびNo. 2 ）。

そのため、ミニシリーズ「SObjectizer：シンプルからコンプレックス」の前の3つの記事は、一方でSObjectizerの機能を示していますが、一方で、どこに行くことができるかを見ることができます。問題を解決する別のアプローチがあります。 たとえば、コルーチンの形でエージェントを使用することが理にかなっている有限状態マシンの形でエージェントを使用し始めた場合。

しかし、多くの場合、コルーチンがステートマシンよりも収益性が高い場合、SObjectizerがコルーチンとしてエージェントをサポートしないのはなぜですか？ これにはいくつかの重大な理由があります。技術的および組織的です。 おそらく、コルーチンがC ++言語の一部であった場合、SObjectizerのコルーチンエージェントはすでにそうでした。 しかし、以来 C ++のコルーチンは現在、サードパーティのライブラリを介してのみ利用可能であり、トピックは最も単純ではありません。SObjectizerにこの機能を追加することは急いではありません。 さらに、この問題にはまったく異なる側面があります。 しかし、それについて話すには、遠くから行く必要があります...

むかしむかし、SObjectizerの最初のバージョンが発売されたとき、私たちは俳優モデルベースのツールを最初に手に入れた多くの新参者と同じ間違いを犯しました：くしゃみごとにエージェントを作成できるなら、それを作成する必要があります。 タスクの実行は、エージェントとして提示する必要があります。 このタスクが1つの要求のみを受信し、1つの回答のみを送信することにある場合でも。 一般的に、新しい機会からの酔いは、あなたが突然「世界にはエージェント以外の何者でもない」という意見に固執し始めるためです。

これはいくつかの負の結果をもたらしました。

まず、アプリケーションコードは、私たちが望んでいるよりも、より多く、より複雑であることがわかりました。 結局のところ、非同期メッセージは損失の対象となり、1つの同期呼び出しを書き込むことができる場所では、要求メッセージの送信、応答メッセージの処理、要求または応答の損失を診断するためのタイムアウトの周りに鐘とwereがありました。 コードを分析すると、半分のケースのどこかで、メッセージに対する対話が正当化されたことが判明しました。 そこで、データは異なるワークフロー間で転送されました。 そして、残りの場所では、多数の小さなエージェントを1つの大きなエージェントにマージし、通常の同期関数呼び出しを通じてその中のすべての操作を実行することができました。

第二に、エージェント上に構築されたアプリケーションの動作は、監視するのがはるかに難しく、予測するのがさらに難しいことが判明しました。 良い例えは、大きな鳥の群れの飛行を観察することです。個々の個体の行動の規則は単純で理解できますが、群れ全体の行動を予測することはほとんど不可能です。 そのため、数万人のエージェントが同時に生活するアプリケーションでは、それぞれが完全に理解可能な方法で機能しますが、共同作業の複合効果は予測できない場合があります。

まだ悪いのは、アプリケーションで何が起こっているかを理解するために必要な情報量の増加です。 email_analyzerの例を見てみましょう。 単一のanalyser_managerエージェントは、キューで待機しているリクエストの総数、稼働中のemail_analyzerエージェントの総数、キューでリクエストを待機する最小、最大、および平均時間（リクエスト処理時間と同様）などの情報を提供できます。 したがって、analyzer_managerのアクティビティの監視は問題ではありません。 しかし、個々のemail_analyzerからの情報の収集、集約、および処理はすでに困難です。 さらに、これらの薬剤が困難であるほど、その寿命は短くなります。

そのため、アプリケーション内のエージェントの数が少ないほど、エージェントを追跡しやすくなり、何がどのように発生し、どのように発生するかを理解しやすくなり、特定の条件でのアプリケーションの動作を予測しやすくなります。

第三に、数万人のエージェントが内部にいるアプリケーションで時々発生する予測不能性により、アプリケーションが部分的または完全に動作不能な状態になる可能性があります。

典型的なケース：10万人のエージェントのアプリケーション。 これらはすべて、定期的なメッセージの助けを借りて、操作のタイムアウトを制御します。 そして、ある時点で、たとえば2万人のエージェントのタイムアウトがすぐに始まります。 したがって、処理用のメッセージキューは、作業スレッド上で膨らみます。 これらのキューはレイクされ始め、各エージェントはメッセージを受信して​​処理します。 しかし、これらの2万のメッセージが処理されている間に、時間がかかりすぎて、タイマーからさらに2万のメッセージが到着します。 これは、まだキューにある古いメッセージの一部に追加されます。 彼にはすべてを処理する時間がなく、さらに2万件のメッセージが到着することは明らかです。 等 アプリケーションは正直に動作しようとしているようですが、徐々に低下して完全に動作しなくなります。

私たちのプロジェクトでSObjectizerを使用する最初の段階でこのレーキを歩いた結果、100万人のエージェントを作成する機会は、私たちの実践で求められているものよりもマーケティングの弾丸であるという結論に達しました* 。 また、 SEDA-wayとして知られるようになったこのアプローチにより、制御がはるかに簡単で、予測可能な動作をするアプリケーションを構築できます。

アクターモデルと組み合わせてSEDAアプローチを使用することの本質は、シーケンシャル操作のチェーン全体を実行するアクターを作成する代わりに、各操作に対して1つのアクターを作成し、パイプラインで構築することです。 電子メールアナライザーの例では、電子メールコンテンツを順次ダウンロードし、このコンテンツを解析および分析するemail_analyzerエージェントを実行する代わりに、複数のステージエージェントを作成できます。 1つのステージエージェントが要求キューを制御します。 次の段階のエージェントは、メールを使用したファイルのアップロード操作を処理します。 次のステージのエージェントは、ロードされたコンテンツを解析します。 次は分析です。 等など

重要な点は、以前の実装では、email_analyzer自体がすべての操作を開始しますが、1つの特定の電子メールに対してのみです。 また、SEDAアプローチでは、操作ごとに1つのエージェントがありますが、各エージェントは一度に複数のメールに対してそれを行うことができます。 ちなみに、このSEDAアプローチの痕跡はIOエージェントとしての例でも見ることができます。これはSEDAのステージエージェントにすぎません。

したがって、SEDAからのアイデアを積極的に使用し始めたとき、ステージエージェントは有限状態マシンとして非常に便利に実装されることが判明しました。 ある特定の瞬間に、彼らは異なる入ってくる影響を待ち、その状態に応じてそれらに反応しなければなりません。 ここで、私たちの意見では、長期的には有限状態マシンはコルーチンよりも便利です。

ところで、SObjectizerに最初に精通した人にしばしば注意を払うもう1つのポイントに注意することができます。エージェントの冗長性です。 実際、SObjectizerのエージェントは原則として、少なくともコンストラクターを持つ別個のC ++クラスです。コンストラクターで初期化する必要のあるフィールドがいくつかあり、so_define_agent（）メソッドが再定義され、いくつかのイベントハンドラーが別々になりますメソッド...単純な場合、これらすべてが公平な構文オーバーヘッドにつながることは明らかです。 たとえば、Just :: Thread Proでは、単純なアクターロガーは次のようになります。

 ofstream log_file("..."); actor logger_actor( [&log_file] { for(;;) { actor::receive().match<std::string>([&](std::string s) { log_file << s << endl; } ); } } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一方、SObjectizerでは、エージェントを記述するために従来のアプローチを使用する場合、次のようなことを行う必要があります。

 class logger_actor : public agent_t { public : logger_actor( context_t ctx, ostream & stream ) : agent_t{ctx}, stream_{stream} {} virtual void so_define_agent() override { so_subscribe_self().event( &logger_actor::on_message ); } private : ostream & stream_; void on_message( const std::string & s ) { stream_ << s << endl; } }; ... ofstream log_file("..."); env.introduce_coop( [&log_file]( coop_t & coop ) { coop.make_agent< logger_actor >( log_file ); } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、SObjectizerにはもっと多くの落書きがあります。 ただし、逆説は、SEDAアプローチに固執すると、多くのエージェントが存在せず、異なるタイプのメッセージを処理できる場合、エージェントコードは非常に急速に膨張するということです。 これは、エージェントの作業の論理（原則として、より複雑）が原因であり、エージェントがログ記録や監視などの追加事項で満たされているという事実が原因です。 そしてここで、エージェントのメインアプリケーションコードが数百行以上のボリュームを持っている場合、SObjectizer側からの構文オーバーヘッドのサイズはまったく重要ではないことがわかります。 さらに、エージェントが大きく複雑になるほど、その表現は別のC ++クラスの形式でより有益になります。 おもちゃの例では、これは見えませんが、「戦闘」コードでは非常に強く感じられます（ここでは、例えば、最も難しい実際のエージェントではない小さな例 ）。

したがって、実際の経験に基づいて、アクターモデルとSEDAアプローチを適切に組み合わせると、有限オートマトンの形式でエージェントを表現することは完全に通常のソリューションであるという結論に達しました。 もちろん、そのような決定は、表現力の点でコルーチンに失われます。 しかし、一般に、ステートマシンの形式のエージェントは非常にうまく機能し、特別な問題を引き起こすことはありません。 おそらく、 microexamplesでのアクターモデルの実装に対するさまざまなアプローチを比較することを除きます。

記事の終わりに、読者に訴えたいと思います。 エージェントのオーバーロードなどの非同期メッセージに基づいた相互作用のメカニズムのこのような重要な問題に触れたいという計画の記事がもう1つあります。 同時に、SObjectizerがエージェントのエラーにどのように応答するかを示します。 しかし、聴衆の意見を知ることは興味深いでしょう。あなたが好きなもの、嫌いなもの、私がもっと知りたいこと。 これは、次の記事の準備とSObjectizer自体の開発の両方で大いに役立ちます。

---

*私たちは私たちの経験について話していることを強調します。 明らかに、アクターモデルを使用して他の問題を解決する他のチームは、アプリケーションで多数のアクターを正常に使用できます。 そして、これにはまったく反対の意見があります。