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

Slide 1

Slide 1 text

Reactive Messaging Patterns に学ぶシステム間統合 2018/3/15 第5回Reactive System Meetup in 西新宿 @yoskhdia #reactive_shinjuku

Slide 2

Slide 2 text

Reactive Messaging Patternsとは＋＝

Slide 3

Slide 3 text

Reactive Messaging Patternsとは ✘ EIPをベースにAkkaでどう実装するかを紹介するパターン本です。 ✘ 書籍「Akka実践バイブル(Akka in Action)」のなかでも、EIPの実装例がいくつか出てきます。お得ですね？ ✘ Akkaを基盤技術としているので、 Akka実践バイブルと併読がオススメ

Slide 4

Slide 4 text

Reactive Messaging Patternsとは ✘ いくつかのカテゴリに分類されます。 ✗ Messaging Channels ✗ Message Construction ✗ Message Routing ✗ Message Transformation ✗ Message Endpoints ✘ いくつかのパターンは他のパターンの組み合わせです。

Slide 5

Slide 5 text

Reactive Messaging Patternsとは ✘ 著者は「実践ドメイン駆動設計」の Vaughn Vernon氏 ✘ なので、RMPでもDDDの用語がチラホラ出てきます。 ✗ 境界づけられたコンテキスト ✗ 公表された言語

Slide 6

Slide 6 text

Reactive Messaging Patternsとは＋＝

Slide 7

Slide 7 text

私は ✘ Reactive Messaging Patterns(RMP)読書会を 2016/4〜2017/9にかけて（共同）開催 ✘ 書籍「Akka実践バイブル（翔泳社）」のレビュアー ✘ ScalikeJDBC (scalikejdbc-streams)の Organization member

Slide 8

Slide 8 text

話さないこと ✘ RMPの各パターン詳細は話しません。 ✗ 参考：Reactive Messaging Patternsを使った境界づけられたコンテキストの統合 ✘ Akkaの詳細な書き方は話しません。 ✗ どんなものを使えば良いかは例示しますが、実装方法までは踏み込みません。

Slide 9

Slide 9 text

話すこと ✘ システム間統合にしぼります。 ✘ ここでは、異なる出自（異なるコンテキスト）のシステム同士を良い感じに連携させることを指します。 ✘ 2つのシステムをくっつけて、 1つのシステムにするという話ではありません。

Slide 10

Slide 10 text

境界で起きる問題を扱います System A 私たちのシステム System B

Slide 11

Slide 11 text

事前知識

Slide 12

Slide 12 text

Channel メッセージ・チャンネル・プロセッサ Processor Processor Message Channel Channel

Slide 13

Slide 13 text

基本編

Slide 14

Slide 14 text

システム間統合のよくある問題 ✘ 外部からの不整合データ問題 ✗ 「パラメータが足りない」 ✗ 「フォーマットに従っていない」 ✘ 内部からの不整合データ問題 ✗ 「誤った入力をしてしまいました」 ✗ 「うっかり消してしまいました」 ✘ 特例ルール対応問題 ✗ 「仕様を変更します」 ✗ 「この時だけ変換が必要です」

Slide 15

Slide 15 text

どう立ち向かうか？

Slide 16

Slide 16 text

外部からの不整合データ問題鉄則：システムに入れる前に綺麗に！

Slide 17

Slide 17 text

Filter Invalid Message Channel Enricher Normalizer Splitter 基本プロセッサは間引く・補完・正規化・分割 System A 私たちのシステム

Slide 18

Slide 18 text

相手システムとの間のメッセージ ✘ メッセージの統一が重要 →Normalize / Canonical Message Model ✘ EIPではCanonical Data Modelが紹介されていますが…… ✗ DataではなくMessageに着目する方が境界づけられたコンテキスト&ユビキタス言語でモデリングしやすい ✗ Dataに着目すると同じような属性を持つものがまとめられてしまう恐れがある

Slide 19

Slide 19 text

メッセージの蒸留 ✘ メッセージのパラメータを変更することはコストが高いです。 ✗ 同じアプリケーションでも、RollingUpdateなどで異なるメッセージモデルが混在する状況は発生し得えます。 ✘ しかし、ドメインモデルの進化は止められない/止めたくない。 ✗ トランスポートレイヤとドメインレイヤを分けて考えましょう。

Slide 20

Slide 20 text

（参考）ドメインイベントは一級オブジェクトドメインイベントを設計する ✘ Command ✘ Event ✘ Document こちらもどうぞ

Slide 21

Slide 21 text

内部からの不整合データ問題鉄則 1/2：おかしなまま外に出さないようにする！

Slide 22

Slide 22 text

System B 私たちのシステム Filter Invalid Message Channel Enricher Normalizer Aggregator 基本プロセッサは間引く・補完・正規化・結合

Slide 23

Slide 23 text

内部からの不整合データ問題鉄則 2/2：早め早めに誤りを検出する！

Slide 24

Slide 24 text

自己防衛 Filter Invalid Message Channel Resequencer Channel Adapter Idempotent Receiver

Slide 25

Slide 25 text

内部からの不整合データ問題 ✘ 不整合データを自分で生み出す可能性もあります。 ✘ おかしなデータを検知できるように備えましょう。 ✘ リカバリできるものなのかを切り分けて、適切にInvalid Message Channelを設計しましょう。 ✗ No more 島流し（一律Dead Letter）

Slide 26

Slide 26 text

特例ルール対応問題鉄則：柔軟に組み換えられるようにしよう！

Slide 27

Slide 27 text

ここまで見てきたように ✘ Pipe & Filterという考え方は強力 ✗ 責務を明確にした小さなプロセッサを作る ■ 関数的に設計（non-副作用） ✗ メッセージの型を揃えて合成する ✘ UNIX哲学に通ずるものがありますね

Slide 28

Slide 28 text

なんでもバラバラにすれば良いわけではない ✘ OCM(Object capability model) ✗ 例えば、Content Filterを単一の親Actorが持つ子 Actorとした方が良いケースがある。 ✗ 通常のActorとして公開してしまうと、メッセージの送信先が複雑化し、責務を閉じることが難しくなる。 ✗ 意図しない送信元からlookupされる恐れもあるので、モジュール凝集度が低くなる。 ✗ 単一の親に限定することで、凝集度が高くなりテストもしやすくなる。

Slide 29

Slide 29 text

避けては通れないトランザクションの話

Slide 30

Slide 30 text

は時間の都合上カット交流会かLTかブログにて…

Slide 31

Slide 31 text

Akkaの活かしポイント

Slide 32

Slide 32 text

Message? 実は、ここまでの話には暗黙の了解があったことにお気づきだろうか…… ✘ 同じプロトコルのメッセージング ✗ みんなAkka使ってる？ ✗ 型の共有？ ✗ リアルタイム？バッチ？

Slide 33

Slide 33 text

Message ✘ Protocol ✗ HTTP/TCP/MQ ✗ File (CSV/TCV/HFS/etc...) ✗ Database共有 ✗ 独自プロトコル /etc... ✘ Format ✗ ByteString/JSON/protobuf/MessagePack/etc… 相手との力関係により、連携方式が決まることも多い。

Slide 34

Slide 34 text

異なるSourceから同じFlowへ Mail Transport REST Transport MQ Transport Router Text Translator JSON Translator XML Translator Message Channel Protocolの解決 Formatの解決

Slide 35

Slide 35 text

Streamingからはじめる ✘ SOAの難しさはStreamingの難しさ ✗ 参考：Transforming enterprise integration with reactive streams ✘ ストリームを基本とする。 ✗ ついついエンドポイントから考え始めてしまう。 ✗ 中心に捉えるべきはストリーム ✗ Akka Httpも、あくまでエンドポイントのひとつなだけ（Source）

Slide 36

Slide 36 text

I love Akka Streams! ✘ Akka Streamsが最強に便利 ✗ Reactive Streams実装のひとつ ✗ ここまで紹介したコンポーネントを Flowとしてほぼ実装できる（※） ✗ 参考：Transforming enterprise integration with reactive streams ✘ Alpakkaが最強に便利 ✗ 様々なStoreやMQなどをAkka Streamsにつなげるためのコネクタ集 ✗ 個人的にはReactive Streams準拠のコネクタが増えて欲しい

Slide 37

Slide 37 text

ミドルウェアとの接合点における注意 ✘ ミドルウェア特有の事情をどう吸収するか？ ✗ Envelope Wrapperパターン ✗ 例えばSQSではReceiptHandleなどがあり、これをメッセージにラップして隠蔽する ✘ ネットワークを超えて同じ型を共有？ ✗ ProtobufやMessagePackなどの公表 ✗ Akka Typed ( & StreamRef )

Slide 38

Slide 38 text

メッセージに翻訳して Akkaの土俵に持ち込む

Slide 39

Slide 39 text

大規模になってくると更に ✘ スループットの違うシステムによる数の暴力 ✗ スパイクアクセス ✘ コアシステムへの流入集中 ✗ 単一障害点 ✗ 状態の共有

Slide 40

Slide 40 text

✘ Akka(Reactive) Streams ✗ Back Pressure ✗ Non-blocking ✗ Asynchronous ✘ Akka Cluster ✗ Scalability ✗ Location Transparency ✗ 参考：Akka Clusterの耐障害設計 ✘ Akka Persistence ✗ State Persisting そこでAkka

Slide 41

Slide 41 text

十分過ぎる道具勝ったも同然？

Slide 42

Slide 42 text

トレードオフ ✘ 非同期にメッセージを扱うことは難しさも招く。 ✗ メッセージを分割して並列処理するとき、たとえばいずれかのメッセージがロストしたら、どうリカバリするのか？ ✘ 得られることと失うことを天秤にかけましょう。 ✗ 銀の弾丸は無い

Slide 43

Slide 43 text

話していないこと ✘ 対多パターン ✗ Message Busなどのファンイン・ファンアウト ✘ メッセージの到達保証パターン ✗ Guaranteed Delivery ✘ Testのためのパターン ✘ 運用のためのパターンぜひRMP/EIPを読んでみてください

Slide 44

Slide 44 text

Akkaだから嬉しいこと ✘ メッセージ駆動 ✗ リアクティブ宣言の体現 ✘ 位置透過 ✗ 数々のパターンの実現のしやすさ ✗ たとえば、Return Addressパターンのように返送先を指定したいときにもActorRefをメッセージに含めるだけでOK（※） ✘ 豊富なツールキット ✗ ストリーミングの容易さ ✗ エンドポイント構築の容易さ

Slide 45

Slide 45 text

Akkaの登場によって、 EIPの実践がしやすくなりました。良い時代ですね！

Slide 46

Slide 46 text

Happy Hakking! Akka is awesome! Woohoo!

Slide 47

Slide 47 text

THANKS! Presented by Yoshitaka Okuda You can find me at @yoskhdia & Special Thanks Matsushita-san and members of the RMP reading club!

Slide 48

Slide 48 text

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 いらすとや