SEDA (Staged Event-Driven Architecture)

Casssandraの設計を理解する上で、SEDAのアーキテクチャを理解する必要があったので調べてみました。
http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf

既存技術の問題

  • Thread modelは設計・管理しやすいがサーバのスケーラビリティという観点からは問題あり。負荷が増えると、スレッドコンテキストの切り替えでスループットも落ち、一定以上の負荷の下では性能が出ない。
  • Event model は負荷には強いがスケジューリングがアプリケーションに任されるため、設計・実装が難しい

SEDAで提案しているアーキテクチャ

ThreadモデルとEventモデルのいいとこ取りをするために、

  • アプリケーションを、複数の独立なStageに分離して管理する。
  • 各Stageをincoming event queue, thread pool, application-supplied event handlerで構成し、各ステージはイベントをpassingすることで繋ぐ
  • event handlerでは、Threadのallocationとschedulingを気にしないようにStageで隠蔽

する
という構成を取っている。

SEDAの構成の利点

  • 各ステージはスレッドにより実行される
  • スレッドとコネクション要求の処理とを分離するため、コネクション数が増えてもスレッド数が増加してスループットが落ちることはない
  • アプリケーション(event handler)はスレッドのスケジューリングなどを気にしなくて良い
  • ステージでは、ステージごとに様々なスケジューリング・スレッドモデルを採用可能
  • ステージ間のeventのやりとりが監視しやすい
Sedaの構成要素について

Stageとresource controllerが構成要素。

SEDA Stage
  • Stageは、incoming event queue, thread pool, application-supplied event handlerから構成される。
  • Stageの操作は(resource allocationとschedulingを行う)controllerによって管理される
  • 各ステージのロジックは、event handlerに実装される。event handlerで処理して、他のstageのincoming event queueにイベントをつっこむ
SEDA resource controllers
  • Thread pool controller
    • stage内で実行するスレッドの数を調整する。event queueのメッセージ数を観察して、thread poolのサイズを調整する。
  • batching controller
    • event handlerの各iterationで処理するイベントの数を調整する

See also

以下の二つの論文もざっと目を通しておこうかなと。