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

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

65cc101435ac36057f2a2c80244c4c6e?s=128

Yoshitaka Okuda

April 09, 2018
Tweet

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