C ++でアクターを使用して15年にわたってたまたま蓄積した塊に関する記事の1つで、多くのアクターがそれ自体で問題になることが多いと言われましたが、解決策ではありません。 また、 SEDAアプローチのアイデアを使用すると、アクターモデルに基づいてアプリケーションを開発する際の生活が大幅に簡素化されます。 ただし、質問が前の記事へのコメントで後で示したように、SEDAアプローチとアクターモデルの組み合わせは明らかではないため、このトピックをもう少し掘り下げることは理にかなっています。

アクターのモデルとその利点

俳優モデルについてのいくつかの言葉

アクターモデルでは、3つの基本原則を使用して、アクターと呼ばれる特別な計算エンティティを通じて適用作業が実行されます。

• アクターは着信メッセージに応答します。
• アクターには、着信メッセージへの応答を決定する動作があります。
• メッセージを受信すると、アクターは次のことができます。
• • いくつかの（最終的な）メッセージを他のアクターに送信します。
  • （最終的な）数の新しいアクターを作成します。
  • 後続のメッセージを処理するための新しい動作を定義します。

通常、アクターは着信メッセージを待ってスリープします。 そのようなメッセージが表示されると、アクターはウェイクアップし、メッセージを処理して、次のメッセージを受信するまで再びスリープ状態になります。

アクターモデルは、アクターがどうあるべきかを決定しません。 したがって、アクターモデルの実装は非常に異なって見える場合があります。 したがって、アクターモデルの最も有名な実装の1つは、 Erlangプログラミング言語と見なされます。 そこでは、アクターはErlang VM内で実行される軽量プロセスです。 アクターモデルの最も有名な実装の1つであるJVMのAkkaフレームワークでは、アクターは、アクターのメッセージを受信したときにフレームワークによってメソッドが自動的に呼び出されるオブジェクトとして表されます。 一方、JVMのアクターの別の実装であるQuasarでは、アクターはコルーチンです。 C ++の世界では、 QP / C ++やSObjectizerなどのフレームワークは、アクターの表現をステートマシンであるオブジェクトとして使用します。 CAFフレームワークでは、アクターはオブジェクトまたは関数のいずれかです。 また、 Just :: Thread Pro：Actors Editionフレームワークでは、各アクターは個別のOSスレッドです。

したがって、異なる実装の動作原理は異なります。どこかで、フレームワークがアクターオブジェクトのコールバックメソッドを呼び出し、どこかで、アクター自体が次の着信メッセージを受信するためにフレームワークをプルするように強制されます。 ただし、一般的な作業スキームはどの場合でも保持されます。俳優への着信メッセージがない場合、俳優はスリープして何もしません。 メッセージが表示されるとすぐに、アクターは目を覚まし、着信メッセージを処理し、次の着信メッセージを待ってスリープします。

俳優の便利さは何ですか？

私の意見では、アクターモデルには2つの大きな利点があり、特定の状況で開発者の生活を大幅に簡素化します。

まず、各アクターは独自の状態を持ち、非同期メッセージを介してのみ外部と通信します。 すなわち 最も純粋な形では何も共有しないという実施形態。 この重要性は、マルチスレッドプログラミングと分散アプリケーションの構築の両方で過大評価されることはほとんどありません。

確かに、アクターモデルを使用してマルチスレッドコードを記述する場合、人種やデッドロックなどについて考える必要はありません。 確かに、アクターモデルには落とし穴がありますが、ベアスレッド、ミューテックス、および条件変数の使用と比較すると、アクターモデルの学習と使用ははるかに簡単です。

非同期メッセージングでは、受信者が同じプロセス内にいるか、リモートホスト上で動作しているかは関係ないため、原則として、アクターモデルは配布との親友です。 ただし、配信の問題は、特にアクター間の集中的なメッセージングに関してははるかに複雑であるため、ここではすべてが明確ではありません 。 しかし、重い負荷について話していない場合、特にフレームワーク/環境がそのような機会をすぐに提供する場合、アクターモデルに基づいて分散アプリケーションを構築することは難しくありません。

第二に、各アクターは、独自のロジックに従って動作する特定の自律エンティティになることができます。 たとえば、リレーショナルDBMSでは、アクターを作成してSQLクエリを実行できます。 各アクターは、最初から最後までリクエストを実行できます：リクエストの逆アセンブル、その正当性の確認、実行計画の作成、ストレージシステムからのデータのリクエスト、リクエストを満たすデータの選択、リクエストの送信者へのデータ送信。 1つのエンティティのフレームワーク内にこのすべてのロジックをアクターの形で実装すると便利です。 その後、アプリケーション（たとえば、RDBMSサーバー）はN個のアクターを作成し、それぞれが異なるリクエストに個別に対応します。

これらの2つの利点を組み合わせると、アクターモデルは、マルチスレッドアプリケーションで、互いに強く結びついていないさまざまなアクティビティを同時に実行する必要がある場合に非常に便利であることがわかります。

SEDAのアプローチと美徳

SEDAのアプローチ

SEDAアプローチの本質は、特定の各アプリケーション操作が個別のステージに分割され、各ステージに個別のコンピューティングエンティティが割り当てられることです。 したがって、RDBMSでのSQLクエリのサービスは、SQLクエリの解析、クエリパラメーターの検証、クエリプランの構築、リポジトリからのデータの収集、クエリを満たすデータのフィルター処理、クエリ送信者への結果の送信の各段階に分けることができます。

ステージ間の相互作用は、非同期メッセージを送信することにより実行されます。 そのため、SEDAアプローチの場合、別のエンティティステージがSQL式を解析します。 解析が成功すると、SQLクエリの解析されたビューが次のエンティティ段階に送信されます。 次のエンティティは、すでに解析されたリクエストのパラメーターを検証します。 パラメータが有効な場合、リクエストは次のエンティティ段階に送信され、リクエストの実行のための計画が準備されます。 等

SEDAアプローチの特徴は、ステージエンティティ間のメッセージキューを使用して、アプリケーションの負荷を制御できることです。 「解析」段階と「検証」段階の間の線は、20要素の固定サイズを持つことができると仮定します。 これは、検証ステージのキューが完全にいっぱいになると、解析ステージが次のメッセージをキューに入れられないことを意味します。

したがって、ステージ間に固定サイズのキューが存在すると、アプリケーションを過負荷から保護できます。 しかし、さらに興味深いことに、オーバーロードが検出されたとき（つまり、既に満たされているキューに新しいメッセージを挿入しようとしたとき）に異なる動作を使用できます。

• それまでは、キュー内のスペースを解放するまで、現在のエンティティステージを一時停止できます。
• 別の処理を実行する別のエンティティステージにメッセージを送信することができます（たとえば、過負荷のために要求を処理できない場合、「再試行後」の特別な応答を生成できます）。
• いくつかの古いメッセージをキューから削除しようとすることができます（たとえば、場合によっては、長い間順番を待っていたメッセージを捨てることができます。高い確率で、その処理の結果はだれにも不要になるからです）。

さらに、動作はキューの満杯だけでなく、たとえば平均メッセージ処理時間にも依存する場合があります。 したがって、平均時間が増加し始めた場合は、キューのサイズを強制的に削減して、キューで長時間を費やすことを余儀なくされるメッセージを保存しないようにすることができます。

SEDAアプローチの利点

SEDAアプローチの実装が非共有アーキテクチャを使用する場合（および、原則として、個別のステージエンティティが可変データを分離する必要がないために使用されます）、SEDAの場合、マルチスレッドプログラミングと同じ利便性がありますアクターモデルと同様に、分散アプリケーションを構築します。

ただし、SEDAアプローチの最も重要な利点は、固有の過負荷保護です。 アクターモデルでは、アクターのオーバーロードはアキレス腱です。 しかし、SEDAアプローチでは、開発者はすぐにエンティティステージを過負荷から保護し、標準メカニズムの1つを選択するか、独自の方法を実装して使用する必要があります。 最も肯定的な方法で、高負荷下でのアプリケーションの安定性と応答性に影響します。

アクターモデルとSEDAアプローチの組み合わせ

アクターモデルとSEDAアプローチを組み合わせる理由

一見すると、アクターモデルとSEDAアプローチは互いに矛盾しているように見えるかもしれません。 そして、アクターモデルまたはSEDAアプローチを使用して、適用された問題を解決できます。 ただし、これは完全に真実ではなく、これらのアプローチの両方を一緒に使用できます。 しかし、私たちが追求する目標をよりよく理解するためには、実際に対処しなければならない俳優モデルのいくつかの問題に触れる必要があります。

アクターは過負荷から保護されていません

アクターモデルの特徴の1つは、非同期メッセージングです。 これにより、アクターを使用するときにデッドロックを心配することはできません。 しかし、この肯定的な機能には独自の価格があります。アクターのメッセージキューのサイズに制限はありません。 これは、アクターBがメッセージを処理するよりも速くアクターAがアクターBにメッセージを送信する場合、アクターBのキューのサイズは常に増加することを意味します。 さらに悪いことに、アクターBからのメッセージが、アクターAからだけでなく、アクターC、D、E、さらにリストのさらに下からも飛びます。

このトピックについては、以前の記事のいずれかで詳しく説明しました 。

ご注意 一般的に、アクターの着信キューの制限または無制限の性質は、特定のフレームワークおよびランタイムの機能です。 たとえば、SObjectizerでは、 処理を待機しているメッセージの数に制限を課すことができます 。 ただし、ほとんどの場合、デフォルトでは、アクターのキューのサイズは固定されていません。

多くの俳優は調整がより困難です。

アプリケーションに多くのアクターがいる場合、それらのアクティビティは時間内に配信されるため、アプリケーションは生命の兆候を見せなくなります。 たとえば、DBMSサーバーでアクターを使用してSQLクエリを実行し、各クエリが1つのアクターによって完全に処理される場合の上記のアプローチについて説明しました。 クエリパラメータを検証する操作はCPUに大きな負荷をかけますが、ストレージからデータを上げる操作はCPUに負荷をかけませんが、I / Oを積極的に使用する可能性があります。

そのようなすべてのアクターを作業スレッドの同じプールに配置すると、遅かれ早かれ、ほとんどすべてのアクターがSQLクエリのパラメーターを検証しようとする状況が発生します。 したがって、CPUに「ダイ」をロードします。 そして、それらはすべてデータのリポジトリにアクセスしようとし、I / O機能に遭遇します。 善のために、アクターの一部のみがCPUをロードできるようにし、他の部分はI / Oを使用するようにします。 しかし、そのような調整には追加の作業が必要であり、アクターの動作のロジックは最初に必要だったよりも複雑になります。

自然な「ボトルネック」があります

多くの場合、アプリケーションには完全に自然な「ボトルネック」があります。 利用可能なすべてのアクターにすぐに提供できない非常に限られたリソース。

たとえば、アクターは暗号化操作を実行するためにハードウェアセキュリティモジュール（HSM）を使用する必要がある場合があります。 HSM 1。 それへのインターフェースは、おそらくいくつかのサードパーティライブラリによって表され、HSMとのすべての作業（初期化、使用、初期化解除）が同期的に実行されることを意味します。

別の典型的な例：アクターはデータベースを操作する必要があり、データベースへの並列接続の数は非常に限られています。 データベースへの並列接続が100のみで、アクターが10,000個であるとします。 そして、全員がデータベースを操作する必要があります。

そのような場合は、どうにかして出なければなりません。 HSMでの作業を担当するHSMアクターを紹介できるとします。 そして、適用されるすべてのアクターは、非同期メッセージを介して彼と通信する必要がありますが、これは私たちが望むほど便利ではありません。 または、ある種のトークンメカニズムを導入できます。アプリケーションアクターはトークンを受信する必要があります。これにより、HSMを直接操作する権利が与えられます。 アクターはHSMでのアクションを完了した後、トークンが別のアプリケーションアクターに到達できるようにトークンを返す必要があります。

これらの特殊なケースはすべて深刻な問題ではありません。 しかし、彼らは「紙の上」を忘れていたまさに「渓谷」であることが判明しました。 そして、それらの迂回には、追加の努力と実装の複雑化が必要になりますが、最初は単純で明白に見えました。

アクターモデルとSEDAアプローチの組み合わせは何を提供しますか？

アクターモデルに基づいてアプリケーションを開発するときに、SEDAのアイデアを使用できます。 この場合、舞台の本質は俳優だけになります。 適用された問題の分解中に、SEDAアプローチから開始しますが、分解の結果として強調表示された段階をアクターの形で実装します。

RDBMSを使用して、アクターを介してSQLクエリを処理する例を見てみましょう。 RDBMSサーバーでは、SQLクエリの解析、パラメーターの検証、計画の構築、リポジトリからのデータの取得、クエリの条件を満たすデータのフェッチ、結果の送信などのステージアクターを使用できます。 これらの各アクターは、アクターの通常のルールに従って機能します。着信メッセージがない間、ステージアクターは眠っています。 着信メッセージが表示されると、アクターステージが起動して処理します。

この場合、無料の費用はかかりませんが、いくつかの素晴らしいボーナスが得られます。 しかし、ボーナスとその価値のリストに移る前に、1つの重要な点に注意する必要があります。

ステージアクターは、異なる独立したアプリケーション操作に関連するアクションを実行する必要があります。 たとえば、SQLクエリを実行するためのプランを構築するためのアクターステージは、Aliceクライアントからの挿入クエリ、Bobクライアントからの更新クエリ、およびクライアントからの選択クエリの計画を構築できる必要があります。イブ。

したがって、アクターステージは、メッセージの送信者とメッセージが関連する操作に関する情報を保持する必要があります。 これは、情報をさらに次の段階に転送し、メッセージの送信者に否定的な結果を送信するために必要になる場合があります。

制限では、アクターステージでは、処理が最も効果的になるように、保留中のメッセージをグループ化する機能が必要になる場合があります。 たとえば、RDBMSサーバーのクエリプランを担当するアクターステージの場合、挿入クエリのプランを作成する方が、選択クエリのプランを作成するよりもはるかに安価です。 したがって、このようなアクターは最初にすべての挿入要求を処理してから、選択要求の処理に進むことができます。 しかし、これは、アプリケーションが非常に高い負荷に直面する場合の制限であり、すべておよびすべての人を最適化する必要があります。

ボーナス1：アクターの総数の削減

これは直感に反するように聞こえるかもしれません。主な議論の1つは、アクターモデルのほぼすべての実装が、数十万、数百万、さらには数千万のアクターを作成する可能性につながるためです。 アプリケーションの100万人の俳優が刺激的で、パターンを破り、新しい視野を開いているように思えます...しかし、これは常にそうではなく、私たち自身の経験からは、俳優の数が少ないほど良いということがわかりました。

少数のアクターを制御する方が簡単です。 何百ものアクターが動作するアプリケーション自体は、監視がはるかに簡単です。 数百の「重い」アクターの主要なバイタルインジケータをZabbixなどのある種の監視システムにエクスポートし、さまざまな監視コンソールや通知システムを介して追跡することは非常に可能です。 しかし、何百万という「軽い」俳優の主な指標で同じことをすることはすでに困難です。

少数の俳優の仕事は調整が容易です。 アクターAとBがCPUバウンドであることがわかっている場合、それぞれに別々のOSスレッドを割り当て、これらの各スレッドをそのコアにバインドすることもできます。 I / Oにバインドされ、非同期I / Oを実行するアクターC、D、およびEに対して、1つの共通の作業スレッドを選択できます。 アクターが少ないほど、誰が、いつ、どのように、どのリソースを消費するかについて合意するのが簡単になります。

ご注意 常に俳優の数を減らすことは良いことではありません。 同時に存在する何億ものアクターが通常よりも多いタスクがあるかもしれません。 たとえば、.NETのOrleansフレームワークはマルチプレイヤーゲームHalo（Halo 4およびHalo 5）に使用され、各ユーザーは個別のアクターとして登場しました。これは、このような問題を解決する完全に合理的なアプローチのようです。 ただし、場合によっては、同時に生きている俳優が少ないほど簡単です。

ボーナス2：「ボトルネック」は自然に表現される

ステージアクターを使用すると、既存の「ボトルネック」（つまり、すべての生きているアクターが同時に共有できないリソース）が単純かつ自然にステージアクターとして表現されることがすぐにわかります。 そして、そのような「ボトルネック」での作業は特別ではなくなります。

たとえば、単一のHSMとHSM機能を必要とする多数のアプリケーションアクターがある場合、各アクターはHSMへのアクセスをリクエストし、このアクセスが許可されるまで待機し、待機タイムアウトなどを制御する必要があります。 これはすべて、適用されるアクターの実装を複雑にします。

しかし、暗号化操作（たとえば、発信ドキュメントの暗号化と署名）を実行する段階が、対応する段階アクターによって表される場合、次のようになります。

• このアクターステージは、HSMに排他的にアクセスできます。これは、実装とその後のメンテナンスに非常に便利です。
• チェーンのステージアクターは、HSMを使用する機能をまったく気にしません。 彼らは単に発信文書を準備し、暗号化および署名する必要があります。その後、HSMを所有する舞台俳優に文書を転送し、次の文書の準備に進みます。

その結果、ステージアクターを使用して適用されるロジックは、すべての適用された処理を独立して実行するアクターに適用されるロジックよりも大幅に単純化できます。 ステージアクター間のメッセージ送信は、「ボトルネック」がある場合とない場合の両方で同じように見えるためです。

ボーナス番号3：一括操作を使用する機能

アクターでMQブローカーを実装していると想像してください。 そして、各アクターは自分のトピックを処理する責任があります（1つのトピック== 1つのアクター）。 また、新しいメッセージをデータベースに書き込むことにより、公開されたメッセージの永続性を確保する必要があります。 つまり、アクタートピックは新しい発行コマンドを受信しました。最初にデータベースにメッセージを保存する必要があり、その後でのみ確認付きでpublish_ackを送信できます。

各アクタートピックがデータベースで個別に操作を実行する場合、データベースで多数の小さなトランザクションが実行される状況が発生する可能性があります（同じテーブルへの単一挿入が多く、同じテーブルからの単一削除が多い）。 良くないもの。

ただし、パブリッシュ操作を実行する別のアクターがある場合、一括操作によってデータベーステーブルへの複数の挿入を一度に実行することが可能になります。 MQブローカーのスループットを向上させるという観点から見ると、多くのシングルインサートよりもはるかに有益です。

ボーナス料金：すぐに輻輳制御なし

アクターモデルに基づくSEDAアプローチのアイデアを使用するため、ステージアクターをSEDA固有の過負荷から保護するための既成の手段がありません。 したがって、ステージをアクターの形で無頓着に配置し、ステージアクターが互いに自由にロードできるようにすると、あるステージが後続のステージアクターが実行できるよりもはるかに多くの作業を生成する状況ですぐに自分を見つけることができます。

したがって、ステージアクターを過負荷制御から保護することに注意する必要があります。 そして、何らかのフィードバック（バックプレッシャー）の実装に困惑する必要があるかもしれません。

原則として、複雑なことは何もありません。 過負荷に対する保護に関しては、異なるコンテキスト（異なるワークスレッド）で動作するアクター-コレクターとアクター-アクターのカップルが自分自身を証明しています。

コレクターアクターはメッセージを受信し、固定サイズの内部キューにメッセージを蓄積します。 このキューがいっぱいの場合、コレクターアクターは、アプリケーションアプリケーションロジックに適したアクションを実行できます。古いメッセージの一部を破棄する、別のアクターにメッセージを転送する、または否定応答を送信する。

アクターコレクターは、メッセージを複製できる状況で非常に役立ちます。 たとえば、アクターAはReqメッセージを送信し、Respが受信されない場合、Respが5秒間応答するのを待ちます。その後、AはReqを送信します。 アプリケーションが負荷のかかった状態で実行され、Req処理の速度が低下し始めると、Aは最初のRespに到達する前に複数のReqを送信できます。 すべての要求がアクター-コレクターを通過する場合、アクター-コレクターは重複する要求を識別して排除できる場合があります。

アクター-パフォーマンスは、コレクター-アクターから蓄積されたメッセージをバッチで受け取ります。 俳優-俳優は次のパックを処理した後、次のパックなどのためにコレクタ-俳優に向かいます。

この2要素スキームはシンプルで信頼性が高く、さらに監視が非常に簡単です（蓄積されたメッセージの数や次のメッセージパックの処理時間などのパラメータは、Zabbixなどのツールで監視用に取り出すことができます）。 ただし、手動で実装する必要があります。 同じC ++で、テンプレートクラスを使用して、このようなコレクターアクターを開発する際のコピーと貼り付けを減らすことができます。 それにもかかわらず、これはすべてアプリケーション開発者が行うべきであり、これは開発段階とメンテナンス段階の両方でのコストです。

SEDAのアプローチが非常に優れている場合、なぜそれを使用し、アクターをまったく使用しないのですか？

実際には、これはカテゴリからの質問です。「 名前を置換するアプローチが非常に優れている場合、なぜそれを使用しないのですか？」

どのアプローチにも長所と短所があります。 したがって、一部のニッチでは、利点が欠点をはるかに上回るため、純粋な形のこのアプローチのみを使用できます。 他のニッチでは、長所と短所の比率はそれほど明白ではないため、アプローチを拒否するか、既存の弱点を補うために他のアプローチからの借用で補完します。

これは、アクターのモデルの場合とまったく同じです。どこかで十分です。 どこかにその欠点に対処する必要があります。 どこかで使用しません

SEDAアプローチでも同様です。 どこかで、このアプローチを使用してアプリケーション全体を開発できます。 しかし、ほとんどの場合、1つのSEDAアプローチでは十分ではありません。 アプリケーションの一部は、ステージングされたアプリケーションの操作で明確かつ簡単に表示されることはありません。 そして、SEDAのアプローチを別のもので補完する必要があります。 たとえば、同じ俳優。

さらに、実際には、疑問が生じます。実装レベルでのエンティティ段階は何ですか？ 各ステージはOSスレッドになりますか？ または、コールバックメソッドを持つオブジェクトになりますか？ ステージロジックはステートマシンによって記述されますか？ ステージは、処理のための新しい要求があるまで、いくつかのアクションを実行する必要がありますか、またはステージは新しいアプリケーションを待機する必要がありますか？ その結果、コードでは、エンティティ段階はプロファイルのみで同じアクターになることが判明する場合があります。 そうだとすれば、アクターのモデルとその実装は、エンティティ段階の実装のための既製のベースとして単純に頼みます。

私自身の経験からの匿名の例

私たち自身は、アクターモデルとSEDAアプローチを組み合わせた利点をすぐには理解せず、特定の数のコーンを取得することができました。そのうちのいくつかは、以前の2つの記事（ No. しかし、これら2つのアプローチの組み合わせを開始したときでも、条件を満たしたモデルをすぐに決定することはできませんでした。

その結果、SObjectizerが使用されたプロジェクトの1つ（「フルプログラム」と呼ばれる）で、次の作業スキームに決めました。

アプリケーションはいくつかのメッセージフローを処理しました。 各スレッドには同じタイプのメッセージがありました。 いくつかの共通の機能と類似点がありましたが、各ストリームの処理は独自の方法で構築されました。

各ストリームの処理にはいくつかの段階がありました。 ( ). - 250ms ( 50ms 2s). - , - , , , , , ( ). , . , 200ms 250ms . - 50ms . , , 300ms 250ms, .

- , -. - - , «» , -. - (.. , ). -, -, , . .

, , . , , . , , . , - . , , .

おわりに

SEDA-. , - . , , , , ( , , , Akka Quasar JVM). .