Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ChatWorkのリアクティブシステム導入事例から学ぶActor設計プラクティス

 ChatWorkのリアクティブシステム導入事例から学ぶActor設計プラクティス

Actorの設計プラクティスに関して簡単にまとめた資料です

かとじゅん

March 15, 2017
Tweet

More Decks by かとじゅん

Other Decks in Programming

Transcript

  1. アジェンダ • Falconで採用したアクターの設計がテーマ ◦ Falconのドメインモデル ◦ FYI: CQRS+ESアーキテクチャ ◦ Falcon

    の アーキテクチャ概要 ◦ Falcon の レイヤ化アーキテクチャ ▪ API(Write or Read) ▪ SparrowForwarder ◦ FYI: Actorの特徴 ◦ FYI: Actorヒエラルキーの考え方 ◦ SparrowForwarderのActorヒエラルキー ◦ FYI: レジリエントを作り込む方法 ◦ BackOffSupervisorとその拡張
  2. Actorの特徴(2/2) • DispatcherはMailboxにImmutableなメッセージを追加する (Shard Nothing)。ActorはMailboxを経由してメッ セージを順番に取得する 。開発者はDispatcherが利用するスレッドを意識しない。決まった単位のメッセージ を処理している際中は、別のメッセージを処理しないので、非同期境界を意識していれば、同一アクター内で はシングルスレッドのように見える。 •

    Actor数分のスレッド数が必要になるわけではない。 ライトウェイト。2.7百万Actorは1GB程度。スレッドモデル では1GB=4096スレッド程度と考えると大きな差がある。 • DispatcherやMailboxは必要に応じて適切な種類と設定を選ぶことでチューニングが可能。
  3. SparrowForwarderのActorヒエラルキー • このモデルは、SQSなどでも利用できる。 • Exponential BackOff機能を備えた Supervisorを経由してメッセージを透過的 に扱う。 • 下位層のActorはいつでもクラッシュしても

    よい。上位はクラッシュしてはならない。 • KafkaComsumerActorがエラーを起こした 場合はSupervisorが指数関数的な BackOffを掛けてリトライを自動的に行う。 • APIExecutorも同様に振る舞うが、 Kafka へのポーリング間隔が延びると Consumer に異常があったと見なされセッションタイム アウトが起こり、リバランスが起こってしま う。この場合はAPIExecutor側でBackOff せずに全体のフローを最初からやり直す 方がよい。現在はAPIExecutorSupervisor は利用していない。
  4. akkaのBackOff Supervisor • データ送信処理が失敗して再送信するときに、失敗回数が増えるに連れて再送信す るまでの待ち時間を指数関数的に増やす仕組みを exponential backoff という。 • SupervisorにExponential

    Backoffを付加するakka標準API ◦ 子アクターが停止もしくは再起動した時にBackoffする ◦ Supervisorにメッセージを送ると子アクターに転送される ◦ ただし、子アクターが開始・停止のイベントがとれない