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
   

   View Slide

2. Reactive Messaging Patternsとは
   ＋ ＝
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. Reactive Messaging Patternsとは
   ＋ ＝
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. 事前知識
    

    View Slide

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

    View Slide

13. 基本編
    

    View Slide

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

    View Slide

15. どう立ち向かうか？
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

31. Akkaの活かしポイント
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

46. Happy Hakking!
    Akka is awesome! Woohoo!
    

    View Slide

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

    View Slide

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

    View Slide