Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ChatWorkのリアクティブシステム導入事例から学ぶActor設計プラクティス
Search
かとじゅん
March 15, 2017
Programming
9
2.8k
ChatWorkのリアクティブシステム導入事例から学ぶActor設計プラクティス
Actorの設計プラクティスに関して簡単にまとめた資料です
かとじゅん
March 15, 2017
Tweet
Share
More Decks by かとじゅん
See All by かとじゅん
AIコーディングエージェントの現実と設計品質の重要性
j5ik2o
0
55
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
15
7.2k
アクターシステムに頼らずEvent Sourcingする方法について
j5ik2o
8
1.2k
メッセージとイベントを中核に置いたシステム設計の有用性について
j5ik2o
12
3.9k
私のキャリアの旅路: 技術をきっかけに変化を楽しむ
j5ik2o
3
930
いかに開発効率と品質を高めるか: ドメイン駆動設計と組織パターンの視点から考える
j5ik2o
5
2.9k
社内のメンバーに「関数型プログラミングの学習・教育」についていろいろ聞いてみた
j5ik2o
2
2.1k
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
j5ik2o
2
3.2k
EIPとAkkaについて
j5ik2o
3
2.9k
Other Decks in Programming
See All in Programming
AI Coding Agentのセキュリティリスク:PRの自己承認とメルカリの対策
s3h
0
200
個人軟體時代
ethanhuang13
0
320
機能追加とリーダー業務の類似性
rinchoku
2
1.3k
速いWebフレームワークを作る
yusukebe
5
1.7k
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
3
300
1から理解するWeb Push
dora1998
7
1.9k
Tool Catalog Agent for Bedrock AgentCore Gateway
licux
6
2.4k
Testing Trophyは叫ばない
toms74209200
0
860
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
360
Navigating Dependency Injection with Metro
zacsweers
3
260
Zendeskのチケットを Amazon Bedrockで 解析した
ryokosuge
3
300
Amazon RDS 向けに提供されている MCP Server と仕組みを調べてみた/jawsug-okayama-2025-aurora-mcp
takahashiikki
1
110
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Adaptive Systems
keathley
43
2.7k
Writing Fast Ruby
sferik
628
62k
The Invisible Side of Design
smashingmag
301
51k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
13k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Transcript
ChatWorkのリアクティブシステム導入事 例から学ぶActor設計プラクティス Junichi Kato (@j5ik2o)
自己紹介 • Scala歴 6年 • サーバサイド開発・設計担当 • 最近やってること ◦ TISさんやセプテーニさんでDDD基礎講座(有償)
◦ OAuth2/OpenID Connectのプロバイダ実装
アジェンダ • Falconで採用したアクターの設計がテーマ ◦ Falconのドメインモデル ◦ FYI: CQRS+ESアーキテクチャ ◦ Falcon
の アーキテクチャ概要 ◦ Falcon の レイヤ化アーキテクチャ ▪ API(Write or Read) ▪ SparrowForwarder ◦ FYI: Actorの特徴 ◦ FYI: Actorヒエラルキーの考え方 ◦ SparrowForwarderのActorヒエラルキー ◦ FYI: レジリエントを作り込む方法 ◦ BackOffSupervisorとその拡張
Falconのドメインモデル • 集中と選択でメッセージとそれにまつわるドメインイベントのみ • すでに成熟しており、議論が紛糾することがなかったので、Actor を使ったモデル駆動設計の議論が主戦場だった。 Message MessageCreated MessageUpdated
FYI: CQRS+ESアーキテクチャ
Falconのアーキテクチャ概要
Falconのレイヤ化アーキテクチャ
API(Write/Read)のアプリケーションアーキテクチャ DAS = Data Access Stream DIPを適用したレイヤ化アーキテクチャ= ヘキサゴナルアーキテクチャ
SparrowForwarderのアプリケーションアーキテクチャ
FYI:Actorの特徴
Actorの特徴(1/2) • メッセージを受信して初めて、利用可能なスレッドを使って反応する。メッセージに反応しないコンポーネントは 貴重なCPU資源を消費しない。 • メッセージに反応するかどうかはコンポーネントが選択でき、送信側と受信側のコンポーネントは、インターフェ イスと時間から分離される。 • アクターは一度に決まった単位のメッセージを処理する。 CPUを頻繁に消費するポーリングとブロッキングを採
用せず、高スループットにフォーカスするために CPUを解放する。必要に応じた反応が低レイテンシーを導く。
Actorの特徴(2/2) • DispatcherはMailboxにImmutableなメッセージを追加する (Shard Nothing)。ActorはMailboxを経由してメッ セージを順番に取得する 。開発者はDispatcherが利用するスレッドを意識しない。決まった単位のメッセージ を処理している際中は、別のメッセージを処理しないので、非同期境界を意識していれば、同一アクター内で はシングルスレッドのように見える。 •
Actor数分のスレッド数が必要になるわけではない。 ライトウェイト。2.7百万Actorは1GB程度。スレッドモデル では1GB=4096スレッド程度と考えると大きな差がある。 • DispatcherやMailboxは必要に応じて適切な種類と設定を選ぶことでチューニングが可能。
FYI:Actorヒエラルキーの考え方
ActorSystemのヒエラルキー • 最初にActorSystemが作られる。ActorSystemを使ってSupervisorを作る。 Supervisorが 子アクターを作ることでヒエラルキーを構築する。 • 実際には、アプリケーション用のアクターはuser guardian配下に所属する。
アクターヒエラルキーの目的 • スーパバイザのライフタイムは、子アクターが存 在する間と同じ。親によって作られた子アクター は、スーパバイザの監督下に置かれる。スーパ バイザの責任はすべての子アクターが終了した 時に終わる。 • クラッシュする可能性が高いアクターは、可能な 限りヒエラルキーの下層に配置すべき。下層で
起きた障害は、上位までのヒエラルキーが管理 ・エスカレーションが可能。最上位が障害を起こ した場合は、最上位のアクターの再起動もしく はアクターシステムのシャットダウンが必要にな る。
アクターヒエラルキーの実装パターン1 • 利点は、各アクターが相互に直接通信するこ と。スーパバイザは監督業務とインスタンス作 成のみ。 • 欠点は、再起動しか使えないことと、メッセージ がデッドレターに送られて失われてしまうこと。 親のスーパーバイザはメッセージフローから分 離してしまう。
アクターヒエラルキーの実装パターン2 • スーパバイザは単なる生成や監督ではなく、間 接参照として、すべてのメッセージを単に透過 的にフォワードする。スーパバイザは子を終了 したり、他のアクターとは無関係に新しいもの を生み出したりできる。 • 先の例と比べてメッセージフローのギャップが ない。
SparrowForwarder内部設計 ココの話
SparrowForwarderのActorヒエラルキー • このモデルは、SQSなどでも利用できる。 • Exponential BackOff機能を備えた Supervisorを経由してメッセージを透過的 に扱う。 • 下位層のActorはいつでもクラッシュしても
よい。上位はクラッシュしてはならない。 • KafkaComsumerActorがエラーを起こした 場合はSupervisorが指数関数的な BackOffを掛けてリトライを自動的に行う。 • APIExecutorも同様に振る舞うが、 Kafka へのポーリング間隔が延びると Consumer に異常があったと見なされセッションタイム アウトが起こり、リバランスが起こってしま う。この場合はAPIExecutor側でBackOff せずに全体のフローを最初からやり直す 方がよい。現在はAPIExecutorSupervisor は利用していない。
FYI:レジリエントを作り込む方法
Supervisorを実装する
子アクターを実装する
Supervisor経由で実行する
Supervisor経由での実行結果
akkaのBackOff Supervisor • データ送信処理が失敗して再送信するときに、失敗回数が増えるに連れて再送信す るまでの待ち時間を指数関数的に増やす仕組みを exponential backoff という。 • SupervisorにExponential
Backoffを付加するakka標準API ◦ 子アクターが停止もしくは再起動した時にBackoffする ◦ Supervisorにメッセージを送ると子アクターに転送される ◦ ただし、子アクターが開始・停止のイベントがとれない
BackOffSupervisorの拡張(1/3) • akkaからフォークした拡張(本家でも改善中なのでご参考程度に) → https://git.io/vyotj • 子アクターの開始と停止をフックできる • 以下はハンドラーを指定する方法
BackOff Supervisorの拡張(2/3) • ハンドラーの代わりにアクターを指定する方法
BackOff Supervisorの拡張(3/3) • Backoff機能付きSupervisor を自前で作る方法 • Supervisor自身がBackoff Retryが可能
まとめ • ActorRefは疎結合になるので、依存の方向性に気をつけながら、レイ ヤー化アーキテクチャを作る(Propsファクトリとメッセージの依存を間 違えなければまず問題が起きることはない)。静的型配線したいなら、 akka-streamを検討する価値はある。 • Actorの自己回復力(BackOffSupervisor)をいかした設計は、運用負 荷が下がる。これがActorのすべてと言ってもいいすぎではない。 •
でもActorの設計は難しい。Actorヒエラルキーなしはあまり意味がな い。歯を食いしばってActorのコンセプトを学びましょう…。
ご静聴ありがとうございました。