アクターモデルについて

株式会社ナチュラルスタイル 三辻尚栄

      2012/07/13
Actor はオブジェクトである
●
     内部状態をもつ
●
     ただし、公開メソッドはない

    Actor           Actor              Actor
    - 名前: mitsuwo   - 名前: dojo         - 名前: 握手会
    - 年齢: 34        - 年齢: 24           - 場所: メッセ
    - 既婚: True      - 既婚: False        - 入場者数: 2



Actor                       Actor
    - 名前: 藍染ジーパン            - 名前: JK Tシャツ
    - 価格: 24,800円           - 価格: 4,800円
    - 在庫数: 15               - 在庫数: 33
Actor はメッセージを受け取る
●
    アドレスがある
●
    メッセージを受け付ける(非同期)
●
    メールボックスのようなものを持っている
              to: event001
                                       Actor: event001
              内容:入場(3)
                                       [メッセージキュー]
                                       ・入場(3)
                                       ・入場(8)
              to: event001             ・入場(5)
    ユーザー      内容:入場(8)
                             Actor環境


                                       - 名前: 握手会
              to: event001
     Actor    内容:入場(5)                 - 場所: メッセ
                                       - 入場者数: 2

    他のActor
Actor はメッセージを処理する
 ●   自分の番が来たらメッセージを1件だけ処理する
 ●
     このときに内部状態に変更を加えるかも
 ●
     独立したスレッドのようなものが動いてる感じになる


Actor: event001        Actor: event001        Actor: event001
[メッセージキュー]             [メッセージキュー]             [メッセージキュー]
・入場(8)                 ・入場(5)
・入場(5)


                  処理                     処理


- 名前: 握手会              - 名前: 握手会              - 名前: 握手会
- 場所: メッセ              - 場所: メッセ              - 場所: メッセ
- 入場者数: 5              - 入場者数: 13             - 入場者数: 18
Actor はプロセス越しに通信する
ホスト: 10.10.0.1

   プロセス: PID1001



     Actor: yrm     Actor: dojo




   プロセス: PID1002

                          dojo@PID1001


    Actor: habu    Actor: mitsuwo
Actor はネットワーク越しに通信する
ホスト: 10.10.0.1                         ホスト: 10.10.100.1

   プロセス: TCP4001                          プロセス: TCP4001



     Actor: yrm    Actor: dojo             Actor: mine    Actor: tashiro




   プロセス: TCP4002                          プロセス: TCP4002


                           sho@10.10.100.1:4002

    Actor: habu   Actor: mitsuwo             Actor: sho   Actor: kubota
例: 簡単なチャット(DBの場合)

            DB




  INSERT   SELECT   SELECT
                             メッセージを閲覧する人は
                             定期的にSELECTを投げて
                             新しいメッセージがないか
                             見に行く(ポーリング)


  書き込み      閲覧         閲覧
例: 簡単なチャット(Actorの場合)

          Actor: ChatMaster




                    メッセージ
                    のコピー


                                             メッセージが届くとAgentが画
  メッセージ
                                             面に追加するのでポーリングし
            Actor: Agent      Actor: Agent   なくていい。
                                             ただし、過去ログは残らない。
            画面に追加             画面に追加

   書き込み        閲覧                閲覧
どこがいいの?
    [長所]
●
    並行プログラミングが簡単にできる
    –   Actor の作者はスレッドを直接扱うことがない
    –   Actor の作者は内部状態に対するロックを考えなくていい
●
    スケーラブル
    –   ボトルネックをどんどん小さなActorに分けられる
    –   CPUをどんどん増やせる(コア数 or ホスト数)

    [短所]
●   共有データの扱いがDBに比べて面倒なときがある
●   Actor 環境自体のオーバヘッドがある
    –   メッセージのコピー
    –   一旦キューに入れて処理すること
Actor環境の実装
      (メッセージスロット)
●
    スレッドセーフなキューを用意
●   Actor 毎にインスタンス化
●
    メッセージ投入スレッド
●
    定時にメッセージを発生させる仕組み
Actor環境の実装
        (スケジューラー)
●
    スレッドプールを用意
●
    コア数分だけスレッドをたてておく
●   各Actor に平等にスレッドを割り当てる
●
    メッセージスロットから
    メッセージを受け取ってActorの処理を実行
Actor環境の実装
               (通信機構)
●
    メッセージのネットワーク対応
    –   オブジェクトを深くシリアライズ → XML, json など
    –   XML, json など → オブジェクトにデシリアライズ
●
    ネットワーク通信を束ねる
    –   あるエンドポイントに対して通信が発生したら接続
    –   Actor間・メッセージ間で接続を使い回す
    –   一定時間通信がなければ切断
実在するActor環境
●   Erlang/OTP     エリクソン社のActor専用VM環境
●   Scala          言語に組み込み、通信なし?
●   akka(Java/Scala) JVM上で動作する環境、通信も可
●   Theron(C++)    ドキュメントなど良さそう、通信なし
実例
500エラーシステム
500エラーの用途
●
    異常事態を知る → 障害発生時の通知
●
    現在発生しているエラーを見る → リリース時
    の影響確認
●
    過去に発生したエラーの見る → 問い合わせ対
    応等
●
    一定期間に発生したエラーの状況を知る → い
    つまでも放置されているエラーを無くす
こんな機能があるといい
●
    単位時間あたりの発生件数がしきい値を超え
    たらメールで通知する機能
●
    現在発生しているエラーを受信する機能
●   過去に発生したエラーをDBから検索する機能
●
    今日とか今週のエラーの統計をメールで通知
    する機能
500エラーシステム
                                    発生件数がしきい値を
500エラーが発生したら                        超えたらメール
POST(HTTP)

Webサーバ                                             受け取った500エラーを
                                                   send(WebSocket)

Webサーバ                             Actor: Agent          Webブラウザ
               Actor: Receiver


Webサーバ                             Actor: Agent          Webブラウザ

 (数百台)

                Actor: Logger      Actor: Agent          Webブラウザ



                          INSERT

                                            過去ログをSELECT参照
                     DB

                                                  集計データを定期的にメール

アクターモデルについて

  • 1.
  • 2.
    Actor はオブジェクトである ● 内部状態をもつ ● ただし、公開メソッドはない Actor Actor Actor - 名前: mitsuwo - 名前: dojo - 名前: 握手会 - 年齢: 34 - 年齢: 24 - 場所: メッセ - 既婚: True - 既婚: False - 入場者数: 2 Actor Actor - 名前: 藍染ジーパン - 名前: JK Tシャツ - 価格: 24,800円 - 価格: 4,800円 - 在庫数: 15 - 在庫数: 33
  • 3.
    Actor はメッセージを受け取る ● アドレスがある ● メッセージを受け付ける(非同期) ● メールボックスのようなものを持っている to: event001 Actor: event001 内容:入場(3) [メッセージキュー] ・入場(3) ・入場(8) to: event001 ・入場(5) ユーザー 内容:入場(8) Actor環境 - 名前: 握手会 to: event001 Actor 内容:入場(5) - 場所: メッセ - 入場者数: 2 他のActor
  • 4.
    Actor はメッセージを処理する ● 自分の番が来たらメッセージを1件だけ処理する ● このときに内部状態に変更を加えるかも ● 独立したスレッドのようなものが動いてる感じになる Actor: event001 Actor: event001 Actor: event001 [メッセージキュー] [メッセージキュー] [メッセージキュー] ・入場(8) ・入場(5) ・入場(5) 処理 処理 - 名前: 握手会 - 名前: 握手会 - 名前: 握手会 - 場所: メッセ - 場所: メッセ - 場所: メッセ - 入場者数: 5 - 入場者数: 13 - 入場者数: 18
  • 5.
    Actor はプロセス越しに通信する ホスト: 10.10.0.1 プロセス: PID1001 Actor: yrm Actor: dojo プロセス: PID1002 dojo@PID1001 Actor: habu Actor: mitsuwo
  • 6.
    Actor はネットワーク越しに通信する ホスト: 10.10.0.1 ホスト: 10.10.100.1 プロセス: TCP4001 プロセス: TCP4001 Actor: yrm Actor: dojo Actor: mine Actor: tashiro プロセス: TCP4002 プロセス: TCP4002 sho@10.10.100.1:4002 Actor: habu Actor: mitsuwo Actor: sho Actor: kubota
  • 7.
    例: 簡単なチャット(DBの場合) DB INSERT SELECT SELECT メッセージを閲覧する人は 定期的にSELECTを投げて 新しいメッセージがないか 見に行く(ポーリング) 書き込み 閲覧 閲覧
  • 8.
    例: 簡単なチャット(Actorの場合) Actor: ChatMaster メッセージ のコピー メッセージが届くとAgentが画 メッセージ 面に追加するのでポーリングし Actor: Agent Actor: Agent なくていい。 ただし、過去ログは残らない。 画面に追加 画面に追加 書き込み 閲覧 閲覧
  • 9.
    どこがいいの? [長所] ● 並行プログラミングが簡単にできる – Actor の作者はスレッドを直接扱うことがない – Actor の作者は内部状態に対するロックを考えなくていい ● スケーラブル – ボトルネックをどんどん小さなActorに分けられる – CPUをどんどん増やせる(コア数 or ホスト数) [短所] ● 共有データの扱いがDBに比べて面倒なときがある ● Actor 環境自体のオーバヘッドがある – メッセージのコピー – 一旦キューに入れて処理すること
  • 10.
    Actor環境の実装 (メッセージスロット) ● スレッドセーフなキューを用意 ● Actor 毎にインスタンス化 ● メッセージ投入スレッド ● 定時にメッセージを発生させる仕組み
  • 11.
    Actor環境の実装 (スケジューラー) ● スレッドプールを用意 ● コア数分だけスレッドをたてておく ● 各Actor に平等にスレッドを割り当てる ● メッセージスロットから メッセージを受け取ってActorの処理を実行
  • 12.
    Actor環境の実装 (通信機構) ● メッセージのネットワーク対応 – オブジェクトを深くシリアライズ → XML, json など – XML, json など → オブジェクトにデシリアライズ ● ネットワーク通信を束ねる – あるエンドポイントに対して通信が発生したら接続 – Actor間・メッセージ間で接続を使い回す – 一定時間通信がなければ切断
  • 13.
    実在するActor環境 ● Erlang/OTP エリクソン社のActor専用VM環境 ● Scala 言語に組み込み、通信なし? ● akka(Java/Scala) JVM上で動作する環境、通信も可 ● Theron(C++) ドキュメントなど良さそう、通信なし
  • 14.
  • 15.
    500エラーの用途 ● 異常事態を知る → 障害発生時の通知 ● 現在発生しているエラーを見る → リリース時 の影響確認 ● 過去に発生したエラーの見る → 問い合わせ対 応等 ● 一定期間に発生したエラーの状況を知る → い つまでも放置されているエラーを無くす
  • 16.
    こんな機能があるといい ● 単位時間あたりの発生件数がしきい値を超え たらメールで通知する機能 ● 現在発生しているエラーを受信する機能 ● 過去に発生したエラーをDBから検索する機能 ● 今日とか今週のエラーの統計をメールで通知 する機能
  • 17.
    500エラーシステム 発生件数がしきい値を 500エラーが発生したら 超えたらメール POST(HTTP) Webサーバ 受け取った500エラーを send(WebSocket) Webサーバ Actor: Agent Webブラウザ Actor: Receiver Webサーバ Actor: Agent Webブラウザ (数百台) Actor: Logger Actor: Agent Webブラウザ INSERT 過去ログをSELECT参照 DB 集計データを定期的にメール