メッセージとイベントを中核に置いたシステム設計の有用性について

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

自己紹介現職は Chatworkのテックリード。 Scalaや DDDを駆使した開発に 12年以上携わってきました。技術戦略の策定から高難度な技術案件のサポートまで、幅広く担当しています。執筆 WEB+DB PRESS Vol.126 - 21周年記念エッセイ今も読み続ける 1冊の本レビューエリックエヴァンスのドメイン駆動設計 Akka実践バイブルドメイン駆動設計入門良いコード／悪いコードで学ぶ設計入門 WEB+DB PRESS Vol.132 - 特集 1 オブジェクト指向神話からの脱却趣味は Rust。最近 CQRS/Event Sourcing用ライブラリを TS,Go,Rust,JVM向けに実装してます。 twitter: j5ik2o github: j5ik2o ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

アクターモデルとはアクターモデルは、並行計算モデルの一つ。 1973年に Carl Hewittが発明。アクターと呼ばれるプロセス同士が通信しあって計算を行う自らのプライベートな状態を持ち、特定のタスクを実行するための振る舞いを持っている他のアクターとメッセージを通じてのみ通信する。メッセージを受信した際にのみ、処理が実行される受け取ったメッセージに基づいて自身の状態を変更することができ、また新しいアクターを生成できる主な利点は、並行性の管理が容易になること。アクターが独立して操作を行い、直接的な共有状態がないため、データ競合やロックの問題が発生しにくくなる。これにより、多数のプロセスやスレッドが活動する大規模なシステムや、分散システムにおいて、効率的で安全な並行処理が可能になる ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

なぜメッセージとイベントに注目するのかユーザー目線では、即応性（システムがいつでも使用可能であること）は「当たり前品質」この「当たり前品質」を確保しつつ、プロダクトとしての「魅力的品質」を提供することが求められる即応性を実現するためには、スケーラビリティ (弾力性 )と耐障害性が必要これらを実現するには、メッセージ駆動が必要メソッド駆動のアーキテクチャだけでは限界がある今回は非同期なメッセージングとイベント駆動アーキテクチャにフォーカスするユーザの要求の変化ノード数は数十台から数百・数千コアへレスポンスタイムは秒からミリ秒オーダーにダウンタイムは数時間から限りなくゼロに処理対象のデータ規模はギガからペタへ (そもそも終わりがない ) 形⼿段値即応性拡張可能拡張可能耐障害性メッセージ駆動弾⼒性リアクティブシステム ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 11

Slide 11 text

Slide 12

Slide 12 text

メッセージとは何か送信者から受信者へ送られる情報の単位具体的には、送信者が受信者に伝えたい実際のデータ（本文）とそのデータに関する追加情報（メタデータ）で構成されます。メタデータには、メッセージのタイプ、送信者、受信者、優先度、有効期限などが含まれますメッセージを送受信することをメッセージパッシングやメッセージングと呼ぶこともある。通信方法には、以下の設計要素が含まれる同期通信か、非同期通信か配送保証の有無と保証レベル順序通り受信されるか否かピアツーピアか、マルチキャストか、ブロードキャストか ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

メールボックスによって弾力性を確保できるメッセージは、受信者側のキューに蓄積することが可能。受信者が処理可能な状態になったときに順次処理されるこれにより、受信者の処理能力を超えるメッセージ流量があっても、システム全体が停止することを防ぐことができる受信者が複数存在する場合、さらに効率がよくなる。メッセージの受信者全員が同時に通信できる状態になるまで待つのは非常に非効率的であり、一度に一人の受信者に同期的にメッセージを渡すこともできない。 ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 16

Slide 16 text

Slide 17

Slide 17 text

FYI: メッセージのサブセットコマンド (EIP: Command Message) コマンドリクエスト : 受信者への命令や指示。コマンドリクエスト名がメソッド、パラメータが引数に対応コマンドレスポンス : コマンド・リクエストに対応する返信。戻り値に相当するが、これも非同期にメッセージ送信しているに過ぎないイベント (EIP: Event Message) 後述概念図 Message CommandRequest id: ULID aggregateId: AggregateId replyTo: ActorRef CommandResponse id: ULID PostMessage content: Content senderId: UserAccountId PostMessageSucceeded messageId: MessageId PostMessageFailed error: PostMessageError Event id: ULID aggregateId: AggregateId occurredAt: Instant sequenceNumber: Long MessagePosted content: Content senderId: UserAccountId ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

「世界は事実の総体である」ウィトゲンシュタインの哲学から「 1.1 世界は、事実の総体である。事物の総体ではない。」世界が事物の総体であり、事実の総体ではないとしたら、「ここにリンゴがある」という事実すらも世界には含まれなくなってしまうつまり「事実」が中心的な要素である。事物はその「事実」の一部として存在する。ドメイン分析のフェーズにおいても以下の視点が役立つ事実 : ドメインイベント事物 : ドメインイベントに関連するドメインモデルドメインイベントはドメイン分析のツールとして使える ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

メッセージの同期通信と非同期通信の比較メッセージを送信するに当たって、両者間が同期か、非同期かの違い。同期通信では、両者が同時に通信の準備ができている必要がある非同期通信では、送信者は受信者の準備がでているかに関係なく送信できる ※同期通信には、相手に送信できたかわかるためのタイマーが必要になる。同期通信送信者受信者タスクを依頼する⼀定時間返信を待つタスクの完了を通知する他のタスクを実⾏する⾮同期通信送信者受信者タスクを依頼する依頼だけを受け取れる他のタスクを実⾏するタスクの完了を通知する完了通知をいつ受け取ってもいい返信時の処理 ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 28

Slide 28 text

フロー制御を考慮したメッセージの送受信送信レートを調節して受信側に負担が掛からないようにするプロセスのこと＝フロー制御送信側は受信側からの要求で流量を調整する。送信側にて背圧制御 (バックプレッシャ )がかかるバックプレッシャなし送信者受信者メッセージを送信メッセージを送信メッセージを送信処理能⼒オーバー返信を返す下流が遅いとき送信者受信者 1要素を要求メッセージを送信返信を返す下流が早いとき送信者受信者 2要素を要求メッセージを送信メッセージを送信返信を返す返信を返す ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 29

Slide 29 text

フロー制御とメソッドの同期化との比較一方で、ある種のフロー制御を含むメソッド呼出しにて、送信側が受信側のリソースを奪い合う場合、処理は一般的にロックやセマフォの同期化で直列化する必要がでてくる。これも一応暗黙的な背圧で便利だが、トラフィック量が増えると弾力性が一気に失われる。障害に変わることが多い。しかもデバッグも厄介メッセージは待ち行列の概念を使っていて、柔軟なフロー制御ができる。キューが満杯になったらドロップさせたり、キューに優先度を設けたりすることも可能 ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 30

Slide 30 text

フロー制御の典型的な利用シーン実際に Chatwork社での実装例。下流の I/Oが処理しきれないほどの要求が発生した場合、ユースケースなどの上流の送信レートを緩和する (バックプレッシャ ) また、下流でのエラーや障害に対して上流での処理を適切に緩めることで、連鎖的な障害の発生を防ぎ、システム全体の安定性を保つ Akkaや Pekkoはこの手の複雑なフロー制御を引き受けることができ、開発者は本来の課題に集中できる ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 31

Slide 31 text

位置透過性（ Location Transparency) 送信先がローカルかリモートかは区別しない送信先がローカルであってもリモートのように、メッセージが即座に送信されたり即座に処理されることを前提とせず、メッセージの送信や受信が途中で失われる可能性も考慮される。具体的には、コンポーネント同士がメッセージをやり取りする際に、その内部構造がどのようになっているかや、コンポーネントがどこに配置されているかに関わらず、メッセージパッシングの抽象化によって統一される。これにより、コンポーネント間の通信がローカルであろうがリモートであろうが、同様の方法で処理され、開発者はその違いを意識する必要がなくなる。 // groupChatRef1がリモートであってもローカルであっても、同じ方法でメッセージを送信できる groupChatRef1 ! PostMessage("Hello World", senderId, replyTo) // Java Style: groupChatRef.tell(PostMessage.of("Hello World", senderId , replyTo)); ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 32

Slide 32 text

透過的リモーティング (Transparent Remoting) 送信元がリモートかローカルかは区別しない受信側プロセスが送信元がリモートかローカルかを区別しない仕組み。リモートからのメッセージもあたかもローカルから届いたメッセージをハンドラに渡される。メッセージに付与される送信元の replyToはローカルの宛先のように見えるが、実際にはリモートと接続可能なプロキシが生成される。 replyToにメッセージを送ることができる。 // replyToはリモート上のクライアントプロキシーに該当する def greeterBehavior: Behavior[Message] = Behaviors.receive { (context, message) => message match { case Greet(who, replyTo) => // replyTo: ActorRef[Greeted] // メッセージを処理して応答 replyTo ! Greeted(who) // replyTo.tell(Greeted.of(who)); Behaviors.same // ... } } ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 33

Slide 33 text

メッセージはマルチスレッディングと RPCを統合する位置透過性（ Location Transparency) 透過的リモーティング (Transparent Remoting) によって、マルチスレッディングと RPCの区別がなくなり、クラスター上にあるすべてのコンピュータがローカルコンピュータのように扱えるようになる。スケーリングにおけるスケールアップもスケールアウトも、すべてメッセージによって区別することなく利用可能になり、コードを大幅に変更する必要がなくなる。今日は詳しく話さないが、この特徴をうまく使ってコンテキスト境界の見直しのハードルを下げることができる ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 34

Slide 34 text

Slide 35

Slide 35 text

イベントのアーキテクチャ上の有用性実装上でも有用！イベントとは、システム内で発生した出来事を表すメッセージの一種。以下のような特徴を持ちます。状態変化の通知 (Pub/Sub) イベントは、システムの状態が変化したことを他のコンポーネントに通知するために使われる例えば、ユーザーがボタンをクリックした、新しいデータが到着した、タイマーが期限に達したなどの出来事が、イベントとして表現される不変の事実記録と状態構築 (Event Sourcing) イベントは、システム内で起きた具体的な事実を記録する。これらのイベントは変更不可能で、一度発生したら取り消すことはできないシステムの状態はこれらの事実に基づいており、イベントの集合を使って任意の時点でのシステムの状態を再構築できる。これにより、システムの現在の状態が過去の事実に基づいていることが保証される Pub/Subと Event Sourcingは、関係性が深いため混同しやすいが目的が異なる。 ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 36

Slide 36 text

Slide 37

Slide 37 text

メッセージ vs イベントメッセージベースメッセージを特定の受信者に送ることができ、受信者はそのメッセージを処理する責任を担う。受信者はメッセージを 1つずつ処理し、並行処理や同期を不要とする。また、メッセージへの応答は受信者の状態に基づいて変化するイベントベース起こった事実であるイベントを受け取ったたら、システムはタスクを実行する責任を担う。通常、イベントは発生するたびに、対応するイベントキューに追加される。イベントループはこのキューからイベントを取出し対応するコールバックを実行する ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

イベントを使う技術的な利点マイクロサービス間の疎結合 : イベントを介して通信するために、サービス間の直接的な依存関係が減少し、システム全体の変更が容易になる拡張性の向上 : イベントコンシューマを追加することで、新しい機能を追加することができるスケーラビリティの向上 : イベント処理を複数のコンシューマに分散させることで、負荷分散が可能になる耐障害性の向上 : イベントの再送によって、システムの耐障害性が向上する ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 45

Slide 45 text

State Sourcing + Pub/Sub Pros シンプルな実装 : 既存のデータベースと Pub/Subシステムを使用することで、比較的簡単に実装できる直感的なデータモデル : 現在の状態をそのままデータベースに保存するため、データモデルが直感的 Cons 2フェーズコミットの問題 : 分散トランザクションをサポートしないため、一貫性の確保が難しくなる ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 46

Slide 46 text

Event Sourcing + Pub/Sub Pros 一貫性の向上 : 同一トランザクションで処理する必要がないため、データの一貫性をより確実に保てる過去の状態の追跡が容易 : すべてのイベントを保存するため、過去の状態を容易に再現できるスケーラビリティ : 非同期処理により、システム全体のスケーラビリティが向上する Cons 複雑な実装 : イベントストアやスナップショットの管理が必要なため、実装が複雑になる (ツールである程度はカバーできるようになっている ) ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 47

Slide 47 text

FYI: 実装のためのツール Event Store Adatpor Amazon DynamoDB を Event Store化するためのライブラリ。スケーラビリティと耐障害性を両立アクターモデルに限らず、従来のオブジェクトモデルでも Event Sourcingを実現可能対応言語 : Go, Rust, Scala, Kotlin, Java, TypeScript 実施の実装例はこちら Akka Pekko Axon Proto.Actor ©2024 Junichi Kato, Chatwork Inc 1 / 49

Slide 48

Slide 48 text

Slide 49

Slide 49 text

まとめメッセージとイベントの有用性および、これらがアーキテクチャに与える影響を確認しました。メッセージングとイベント駆動設計は、現代のシステムにおいて即応性、スケーラビリティ、耐障害性を高めるために重要な役割を果たします。今回の内容が、メッセージングとイベント駆動の理解を深める一助となれば幸いです。ぜひ、これらの概念を自身のシステム開発に取り入れてみてください。質問やディスカッションはいつでも歓迎します。ご清聴ありがとうございました。 ©2024 Junichi Kato, Chatwork Inc 1 / 49