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
300
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.2k
Event Storming and Narrative
yoskhdia
0
4.2k
Don't build framework, Build platform
yoskhdia
0
170
より効果的な目標の立て方 / How to plan your effective experience
yoskhdia
1
880
ドメインイベントを設計する / Modeling the Domain Event
yoskhdia
5
9.3k
実務家のためのSQL / SQL for Beginers
yoskhdia
1
380
DDD ユビキタス言語再考 / Rethink the ubiquitous language
yoskhdia
1
9.4k
DDD + Clean Architecture + UCDOM Full版
yoskhdia
31
10k
DDD + Clean Architecture + UCDOM Essence版
yoskhdia
13
4.3k
Other Decks in Programming
See All in Programming
Vaporモードを大規模サービスに最速導入して学びを共有する
kazukishimamoto
4
4.3k
OpenTelemetryでRailsのパフォーマンス分析を始めてみよう(KoR2024)
ymtdzzz
4
1.6k
外部システム連携先が10を超えるシステムでのアーキテクチャ設計・実装事例
kiwasaki
1
230
offers_20241022_imakiire.pdf
imakurusu
2
360
PLoP 2024: The evolution of the microservice architecture pattern language
cer
PRO
0
1.6k
Vue SFCのtemplateでTypeScriptの型を活用しよう
tsukkee
3
1.5k
ECSのサービス間通信 4つの方法を比較する 〜Canary,Blue/Greenも添えて〜
tkikuc
11
2.3k
PagerDuty を軸にした On-Call 構築と運用課題の解決 / PagerDuty Japan Community Meetup 4
horimislime
1
110
現場で役立つモデリング 超入門
masuda220
PRO
13
2.9k
Importmapを使ったJavaScriptの 読み込みとブラウザアドオンの影響
swamp09
4
1.2k
Identifying User Idenity
moro
6
7.9k
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
0
160
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
RailsConf 2023
tenderlove
29
880
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.4k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Designing for humans not robots
tammielis
249
25k
A Tale of Four Properties
chriscoyier
156
23k
Become a Pro
speakerdeck
PRO
24
5k
Practical Orchestrator
shlominoach
186
10k
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 いらすとや