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
Reactive Messaging Patternsに学ぶシステム間統合
Search
Yoshitaka Okuda
April 09, 2018
Programming
2
320
Reactive Messaging Patternsに学ぶシステム間統合
補足記事↓
http://yoskhdia.hatenablog.com/entry/2018/03/15/212954
Yoshitaka Okuda
April 09, 2018
Tweet
Share
More Decks by Yoshitaka Okuda
See All by Yoshitaka Okuda
明日からはじめられるEventStorming(イベントストーミング) / Let's try EventStorming
yoskhdia
11
7.5k
Event Storming and Narrative
yoskhdia
0
4.5k
Don't build framework, Build platform
yoskhdia
0
190
より効果的な目標の立て方 / How to plan your effective experience
yoskhdia
1
910
ドメインイベントを設計する / Modeling the Domain Event
yoskhdia
6
9.5k
実務家のためのSQL / SQL for Beginers
yoskhdia
1
390
DDD ユビキタス言語再考 / Rethink the ubiquitous language
yoskhdia
1
9.5k
DDD + Clean Architecture + UCDOM Full版
yoskhdia
31
10k
DDD + Clean Architecture + UCDOM Essence版
yoskhdia
13
4.4k
Other Decks in Programming
See All in Programming
[JAWS DAYS 2025] 最近の DB の競合解決の仕組みが分かった気になってみた
maroon1st
0
140
Introduction to kotlinx.rpc
arawn
0
770
良いコードレビューとは
danimal141
7
1.5k
AIプログラミング雑キャッチアップ
yuheinakasaka
19
4.9k
Djangoにおける複数ユーザー種別認証の設計アプローチ@DjangoCongress JP 2025
delhi09
PRO
4
500
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
14
4.7k
How mixi2 Uses TiDB for SNS Scalability and Performance
kanmo
41
16k
「個人開発マネタイズ大全」が教えてくれたこと
bani24884
1
270
Boos Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
470
Rails 1.0 のコードで学ぶ find_by* と method_missing の仕組み / Learn how find_by_* and method_missing work in Rails 1.0 code
maimux2x
1
250
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
8
1.5k
未経験でSRE、はじめました! 組織を支える役割と軌跡
curekoshimizu
1
170
Featured
See All Featured
Speed Design
sergeychernyshev
27
810
The Cult of Friendly URLs
andyhume
78
6.2k
Building an army of robots
kneath
303
45k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Documentation Writing (for coders)
carmenintech
68
4.6k
Music & Morning Musume
bryan
46
6.4k
How STYLIGHT went responsive
nonsquared
99
5.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
440
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Gamification - CAS2011
davidbonilla
80
5.2k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Transcript
Reactive Messaging Patterns に学ぶシステム間統合 2018/3/15 第5回Reactive System Meetup in 西新宿
@yoskhdia #reactive_shinjuku
Reactive Messaging Patternsとは + =
Reactive Messaging Patternsとは ✘ EIPをベースにAkkaでどう実装するかを紹介 するパターン本です。 ✘ 書籍「Akka実践バイブル(Akka in Action)」の
なかでも、EIPの実装例がいくつか出てきま す。お得ですね? ✘ Akkaを基盤技術としているので、 Akka実践バイブルと併読がオススメ
Reactive Messaging Patternsとは ✘ いくつかのカテゴリに分類されます。 ✗ Messaging Channels ✗ Message
Construction ✗ Message Routing ✗ Message Transformation ✗ Message Endpoints ✘ いくつかのパターンは他のパターンの組み 合わせです。
Reactive Messaging Patternsとは ✘ 著者は「実践ドメイン駆動設計」の Vaughn Vernon氏 ✘ なので、RMPでもDDDの用語が チラホラ出てきます。
✗ 境界づけられたコンテキスト ✗ 公表された言語
Reactive Messaging Patternsとは + =
私は ✘ Reactive Messaging Patterns(RMP)読書会を 2016/4〜2017/9にかけて(共同)開催 ✘ 書籍「Akka実践バイブル(翔泳社)」 のレビュアー ✘
ScalikeJDBC (scalikejdbc-streams)の Organization member
話さないこと ✘ RMPの各パターン詳細は話しません。 ✗ 参考:Reactive Messaging Patternsを使った境界づ けられたコンテキストの統合 ✘ Akkaの詳細な書き方は話しません。
✗ どんなものを使えば良いかは例示しますが、実 装方法までは踏み込みません。
話すこと ✘ システム間統合にしぼります。 ✘ ここでは、異なる出自(異なるコンテキス ト)のシステム同士を良い感じに連携させ ることを指します。 ✘ 2つのシステムをくっつけて、 1つのシステムにするという話では
ありません。
境界で起きる問題を扱います System A 私たちの システム System B
事前知識
Channel メッセージ・チャンネル・プロセッサ Processor Processor Message Channel Channel
基本編
システム間統合のよくある問題 ✘ 外部からの不整合データ問題 ✗ 「パラメータが足りない」 ✗ 「フォーマットに従っていない」 ✘ 内部からの不整合データ問題 ✗
「誤った入力をしてしまいました」 ✗ 「うっかり消してしまいました」 ✘ 特例ルール対応問題 ✗ 「仕様を変更します」 ✗ 「この時だけ変換が必要です」
どう立ち向かうか?
外部からの不整合データ問題 鉄則: システムに入れる前に綺麗に!
Filter Invalid Message Channel Enricher Normalizer Splitter 基本プロセッサは 間引く・補完・正規化・分割 System
A 私たちの システム
相手システムとの間のメッセージ ✘ メッセージの統一が重要 →Normalize / Canonical Message Model ✘ EIPではCanonical
Data Modelが紹介されて いますが…… ✗ DataではなくMessageに着目する方が境界づけら れたコンテキスト&ユビキタス言語で モデリングしやすい ✗ Dataに着目すると同じような属性を持つものが まとめられてしまう恐れがある
メッセージの蒸留 ✘ メッセージのパラメータを変更することは コストが高いです。 ✗ 同じアプリケーションでも、RollingUpdateなどで 異なるメッセージモデルが混在する状況は発生 し得えます。 ✘ しかし、ドメインモデルの進化は
止められない/止めたくない。 ✗ トランスポートレイヤとドメインレイヤを分けて考 えましょう。
(参考)ドメインイベントは一級オブジェクト ドメインイベントを設計する ✘ Command ✘ Event ✘ Document こちらもどうぞ
内部からの不整合データ問題 鉄則 1/2: おかしなまま外に出さないようにする!
System B 私たちの システム Filter Invalid Message Channel Enricher Normalizer
Aggregator 基本プロセッサは 間引く・補完・正規化・結合
内部からの不整合データ問題 鉄則 2/2: 早め早めに誤りを検出する!
自己防衛 Filter Invalid Message Channel Resequencer Channel Adapter Idempotent Receiver
内部からの不整合データ問題 ✘ 不整合データを自分で生み出す可能性も あります。 ✘ おかしなデータを検知できるように備えま しょう。 ✘ リカバリできるものなのかを切り分けて、 適切にInvalid
Message Channelを設計しま しょう。 ✗ No more 島流し(一律Dead Letter)
特例ルール対応問題 鉄則: 柔軟に組み換えられるようにしよう!
ここまで見てきたように ✘ Pipe & Filterという考え方は強力 ✗ 責務を明確にした 小さなプロセッサを作る ▪ 関数的に設計(non-副作用)
✗ メッセージの型を揃えて合成する ✘ UNIX哲学に通ずるものがありますね
なんでもバラバラにすれば良いわけではない ✘ OCM(Object capability model) ✗ 例えば、Content Filterを単一の親Actorが持つ子 Actorとした方が良いケースがある。 ✗
通常のActorとして公開してしまうと、メッセージ の送信先が複雑化し、責務を閉じることが難しく なる。 ✗ 意図しない送信元からlookupされる恐れもある ので、モジュール凝集度が低くなる。 ✗ 単一の親に限定することで、凝集度が高くなり テストもしやすくなる。
避けては通れない トランザクションの話
は時間の都合上カット 交流会かLTかブログにて…
Akkaの活かしポイント
Message? 実は、ここまでの話には暗黙の了解があった ことにお気づきだろうか…… ✘ 同じプロトコルのメッセージング ✗ みんなAkka使ってる? ✗ 型の共有? ✗
リアルタイム?バッチ?
Message ✘ Protocol ✗ HTTP/TCP/MQ ✗ File (CSV/TCV/HFS/etc...) ✗ Database共有
✗ 独自プロトコル /etc... ✘ Format ✗ ByteString/JSON/protobuf/MessagePack/etc… 相手との力関係により、 連携方式が決まることも多い。
異なるSourceから同じFlowへ Mail Transport REST Transport MQ Transport Router Text Translator
JSON Translator XML Translator Message Channel Protocolの解決 Formatの解決
Streamingからはじめる ✘ SOAの難しさはStreamingの難しさ ✗ 参考:Transforming enterprise integration with reactive streams
✘ ストリームを基本とする。 ✗ ついついエンドポイントから考え始めてしまう。 ✗ 中心に捉えるべきはストリーム ✗ Akka Httpも、あくまでエンドポイントの ひとつなだけ(Source)
I love Akka Streams! ✘ Akka Streamsが最強に便利 ✗ Reactive Streams実装のひとつ
✗ ここまで紹介したコンポーネントを Flowとしてほぼ実装できる(※) ✗ 参考:Transforming enterprise integration with reactive streams ✘ Alpakkaが最強に便利 ✗ 様々なStoreやMQなどをAkka Streamsにつなげる ためのコネクタ集 ✗ 個人的にはReactive Streams準拠のコネクタが増 えて欲しい
ミドルウェアとの接合点における注意 ✘ ミドルウェア特有の事情をどう吸収する か? ✗ Envelope Wrapperパターン ✗ 例えばSQSではReceiptHandleなどがあり、 これをメッセージにラップして隠蔽する
✘ ネットワークを超えて同じ型を共有? ✗ ProtobufやMessagePackなどの公表 ✗ Akka Typed ( & StreamRef )
メッセージに翻訳して Akkaの土俵に持ち込む
大規模になってくると更に ✘ スループットの違うシステムによる 数の暴力 ✗ スパイクアクセス ✘ コアシステムへの流入集中 ✗ 単一障害点
✗ 状態の共有
✘ Akka(Reactive) Streams ✗ Back Pressure ✗ Non-blocking ✗ Asynchronous
✘ Akka Cluster ✗ Scalability ✗ Location Transparency ✗ 参考:Akka Clusterの耐障害設計 ✘ Akka Persistence ✗ State Persisting そこでAkka
十分過ぎる道具 勝ったも同然?
トレードオフ ✘ 非同期にメッセージを扱うことは難しさも 招く。 ✗ メッセージを分割して並列処理するとき、たとえ ばいずれかのメッセージがロストしたら、どうリカ バリするのか? ✘ 得られることと失うことを天秤にかけま
しょう。 ✗ 銀の弾丸は無い
話していないこと ✘ 対多パターン ✗ Message Busなどのファンイン・ファンアウト ✘ メッセージの到達保証パターン ✗ Guaranteed
Delivery ✘ Testのためのパターン ✘ 運用のためのパターン ぜひRMP/EIPを読んでみてください
Akkaだから嬉しいこと ✘ メッセージ駆動 ✗ リアクティブ宣言の体現 ✘ 位置透過 ✗ 数々のパターンの実現のしやすさ ✗
たとえば、Return Addressパターンのように返送 先を指定したいときにもActorRefをメッセージに 含めるだけでOK(※) ✘ 豊富なツールキット ✗ ストリーミングの容易さ ✗ エンドポイント構築の容易さ
Akkaの登場によって、 EIPの実践がしやすくなりました。 良い時代ですね!
Happy Hakking! Akka is awesome! Woohoo!
THANKS! Presented by Yoshitaka Okuda You can find me at
@yoskhdia & Special Thanks Matsushita-san and members of the RMP reading club!
Credits Special thanks to all the people who made and
released these awesome resources for free: ✘ Presentation template by SlidesCarnival ✘ Photographs by Unsplash ✘ Illustrations by いらすとや