Reactive Messaging Patternsに学ぶシステム間統合

補足記事↓
http://yoskhdia.hatenablog.com/entry/2018/03/15/212954

Transcript

1. Reactive Messaging Patterns に学ぶシステム間統合 2018/3/15 第5回Reactive System Meetup in 西新宿 @yoskhdia #reactive_shinjuku
2. Reactive Messaging Patternsとは ＋ ＝
3. Reactive Messaging Patternsとは ✘ EIPをベースにAkkaでどう実装するかを紹介 するパターン本です。 ✘ 書籍「Akka実践バイブル(Akka in Action)」の なかでも、EIPの実装例がいくつか出てきま す。お得ですね？ ✘ Akkaを基盤技術としているので、 Akka実践バイブルと併読がオススメ
4. Reactive Messaging Patternsとは ✘ いくつかのカテゴリに分類されます。 ✗ Messaging Channels ✗ Message Construction ✗ Message Routing ✗ Message Transformation ✗ Message Endpoints ✘ いくつかのパターンは他のパターンの組み 合わせです。
5. Reactive Messaging Patternsとは ✘ 著者は「実践ドメイン駆動設計」の Vaughn Vernon氏 ✘ なので、RMPでもDDDの用語が チラホラ出てきます。 ✗ 境界づけられたコンテキスト ✗ 公表された言語
6. Reactive Messaging Patternsとは ＋ ＝
7. 私は ✘ Reactive Messaging Patterns(RMP)読書会を 2016/4〜2017/9にかけて（共同）開催 ✘ 書籍「Akka実践バイブル（翔泳社）」 のレビュアー ✘ ScalikeJDBC (scalikejdbc-streams)の Organization member
8. 話さないこと ✘ RMPの各パターン詳細は話しません。 ✗ 参考：Reactive Messaging Patternsを使った境界づ けられたコンテキストの統合 ✘ Akkaの詳細な書き方は話しません。 ✗ どんなものを使えば良いかは例示しますが、実 装方法までは踏み込みません。
9. 話すこと ✘ システム間統合にしぼります。 ✘ ここでは、異なる出自（異なるコンテキス ト）のシステム同士を良い感じに連携させ ることを指します。 ✘ 2つのシステムをくっつけて、 1つのシステムにするという話では ありません。
10. 境界で起きる問題を扱います System A 私たちの システム System B
11. 事前知識
12. Channel メッセージ・チャンネル・プロセッサ Processor Processor Message Channel Channel
13. 基本編
14. システム間統合のよくある問題 ✘ 外部からの不整合データ問題 ✗ 「パラメータが足りない」 ✗ 「フォーマットに従っていない」 ✘ 内部からの不整合データ問題 ✗ 「誤った入力をしてしまいました」 ✗ 「うっかり消してしまいました」 ✘ 特例ルール対応問題 ✗ 「仕様を変更します」 ✗ 「この時だけ変換が必要です」
15. どう立ち向かうか？
16. 外部からの不整合データ問題 鉄則： システムに入れる前に綺麗に！
17. Filter Invalid Message Channel Enricher Normalizer Splitter 基本プロセッサは 間引く・補完・正規化・分割 System A 私たちの システム
18. 相手システムとの間のメッセージ ✘ メッセージの統一が重要 →Normalize / Canonical Message Model ✘ EIPではCanonical Data Modelが紹介されて いますが…… ✗ DataではなくMessageに着目する方が境界づけら れたコンテキスト&ユビキタス言語で モデリングしやすい ✗ Dataに着目すると同じような属性を持つものが まとめられてしまう恐れがある
19. メッセージの蒸留 ✘ メッセージのパラメータを変更することは コストが高いです。 ✗ 同じアプリケーションでも、RollingUpdateなどで 異なるメッセージモデルが混在する状況は発生 し得えます。 ✘ しかし、ドメインモデルの進化は 止められない/止めたくない。 ✗ トランスポートレイヤとドメインレイヤを分けて考 えましょう。
20. （参考）ドメインイベントは一級オブジェクト ドメインイベントを設計する ✘ Command ✘ Event ✘ Document こちらもどうぞ
21. 内部からの不整合データ問題 鉄則 1/2： おかしなまま外に出さないようにする！
22. System B 私たちの システム Filter Invalid Message Channel Enricher Normalizer Aggregator 基本プロセッサは 間引く・補完・正規化・結合
23. 内部からの不整合データ問題 鉄則 2/2： 早め早めに誤りを検出する！
24. 自己防衛 Filter Invalid Message Channel Resequencer Channel Adapter Idempotent Receiver
25. 内部からの不整合データ問題 ✘ 不整合データを自分で生み出す可能性も あります。 ✘ おかしなデータを検知できるように備えま しょう。 ✘ リカバリできるものなのかを切り分けて、 適切にInvalid Message Channelを設計しま しょう。 ✗ No more 島流し（一律Dead Letter）
26. 特例ルール対応問題 鉄則： 柔軟に組み換えられるようにしよう！
27. ここまで見てきたように ✘ Pipe & Filterという考え方は強力 ✗ 責務を明確にした 小さなプロセッサを作る ▪ 関数的に設計（non-副作用） ✗ メッセージの型を揃えて合成する ✘ UNIX哲学に通ずるものがありますね
28. なんでもバラバラにすれば良いわけではない ✘ OCM(Object capability model) ✗ 例えば、Content Filterを単一の親Actorが持つ子 Actorとした方が良いケースがある。 ✗ 通常のActorとして公開してしまうと、メッセージ の送信先が複雑化し、責務を閉じることが難しく なる。 ✗ 意図しない送信元からlookupされる恐れもある ので、モジュール凝集度が低くなる。 ✗ 単一の親に限定することで、凝集度が高くなり テストもしやすくなる。
29. 避けては通れない トランザクションの話
30. は時間の都合上カット 交流会かLTかブログにて…
31. Akkaの活かしポイント
32. Message? 実は、ここまでの話には暗黙の了解があった ことにお気づきだろうか…… ✘ 同じプロトコルのメッセージング ✗ みんなAkka使ってる？ ✗ 型の共有？ ✗ リアルタイム？バッチ？
33. Message ✘ Protocol ✗ HTTP/TCP/MQ ✗ File (CSV/TCV/HFS/etc...) ✗ Database共有 ✗ 独自プロトコル /etc... ✘ Format ✗ ByteString/JSON/protobuf/MessagePack/etc… 相手との力関係により、 連携方式が決まることも多い。
34. 異なるSourceから同じFlowへ Mail Transport REST Transport MQ Transport Router Text Translator JSON Translator XML Translator Message Channel Protocolの解決 Formatの解決
35. Streamingからはじめる ✘ SOAの難しさはStreamingの難しさ ✗ 参考：Transforming enterprise integration with reactive streams ✘ ストリームを基本とする。 ✗ ついついエンドポイントから考え始めてしまう。 ✗ 中心に捉えるべきはストリーム ✗ Akka Httpも、あくまでエンドポイントの ひとつなだけ（Source）
36. I love Akka Streams! ✘ Akka Streamsが最強に便利 ✗ Reactive Streams実装のひとつ ✗ ここまで紹介したコンポーネントを Flowとしてほぼ実装できる（※） ✗ 参考：Transforming enterprise integration with reactive streams ✘ Alpakkaが最強に便利 ✗ 様々なStoreやMQなどをAkka Streamsにつなげる ためのコネクタ集 ✗ 個人的にはReactive Streams準拠のコネクタが増 えて欲しい
37. ミドルウェアとの接合点における注意 ✘ ミドルウェア特有の事情をどう吸収する か？ ✗ Envelope Wrapperパターン ✗ 例えばSQSではReceiptHandleなどがあり、 これをメッセージにラップして隠蔽する ✘ ネットワークを超えて同じ型を共有？ ✗ ProtobufやMessagePackなどの公表 ✗ Akka Typed ( & StreamRef )
38. メッセージに翻訳して Akkaの土俵に持ち込む
39. 大規模になってくると更に ✘ スループットの違うシステムによる 数の暴力 ✗ スパイクアクセス ✘ コアシステムへの流入集中 ✗ 単一障害点 ✗ 状態の共有
40. ✘ Akka(Reactive) Streams ✗ Back Pressure ✗ Non-blocking ✗ Asynchronous ✘ Akka Cluster ✗ Scalability ✗ Location Transparency ✗ 参考：Akka Clusterの耐障害設計 ✘ Akka Persistence ✗ State Persisting そこでAkka
41. 十分過ぎる道具 勝ったも同然？
42. トレードオフ ✘ 非同期にメッセージを扱うことは難しさも 招く。 ✗ メッセージを分割して並列処理するとき、たとえ ばいずれかのメッセージがロストしたら、どうリカ バリするのか？ ✘ 得られることと失うことを天秤にかけま しょう。 ✗ 銀の弾丸は無い
43. 話していないこと ✘ 対多パターン ✗ Message Busなどのファンイン・ファンアウト ✘ メッセージの到達保証パターン ✗ Guaranteed Delivery ✘ Testのためのパターン ✘ 運用のためのパターン ぜひRMP/EIPを読んでみてください
44. Akkaだから嬉しいこと ✘ メッセージ駆動 ✗ リアクティブ宣言の体現 ✘ 位置透過 ✗ 数々のパターンの実現のしやすさ ✗ たとえば、Return Addressパターンのように返送 先を指定したいときにもActorRefをメッセージに 含めるだけでOK（※） ✘ 豊富なツールキット ✗ ストリーミングの容易さ ✗ エンドポイント構築の容易さ
45. Akkaの登場によって、 EIPの実践がしやすくなりました。 良い時代ですね！
46. Happy Hakking! Akka is awesome! Woohoo!
47. THANKS! Presented by Yoshitaka Okuda You can find me at @yoskhdia & Special Thanks Matsushita-san and members of the RMP reading club!
48. 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 いらすとや