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.3k
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
Amazon Qを使ってIaCを触ろう!
maruto
0
410
Better Code Design in PHP
afilina
PRO
0
130
C++でシェーダを書く
fadis
6
4.1k
EMになってからチームの成果を最大化するために取り組んだこと/ Maximize team performance as EM
nashiusagi
0
100
タクシーアプリ『GO』のリアルタイムデータ分析基盤における機械学習サービスの活用
mot_techtalk
4
1.5k
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
430
NSOutlineView何もわからん:( 前編 / I Don't Understand About NSOutlineView :( Pt. 1
usagimaru
0
340
Jakarta EE meets AI
ivargrimstad
0
130
距離関数を極める! / SESSIONS 2024
gam0022
0
290
Hotwire or React? ~アフタートーク・本編に含めなかった話~ / Hotwire or React? after talk
harunatsujita
1
120
OSSで起業してもうすぐ10年 / Open Source Conference 2024 Shimane
furukawayasuto
0
110
シェーダーで魅せるMapLibreの動的ラスタータイル
satoshi7190
1
480
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
28
2k
Building Adaptive Systems
keathley
38
2.3k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Site-Speed That Sticks
csswizardry
0
28
Testing 201, or: Great Expectations
jmmastey
38
7.1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
RailsConf 2023
tenderlove
29
900
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Optimizing for Happiness
mojombo
376
70k
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 いらすとや