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
以下の二つの論文もざっと目を通しておこうかなと。
- Why Events Are A Bad Idea (for high-concurrency servers)
- Dynamo