Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Yoshitaka Okuda

April 09, 2018
Tweet

More Decks by Yoshitaka Okuda

Other Decks in Programming

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