Rails上でのpub/sub イベントハンドラの扱い

Rails上でのpub/sub イベントハンドラの扱い

1. 1. ota42y 2018/07/25 Shinjuku.rb #63 Rails上でのpub/sub イベントハンドラの扱い
2. 2. • ota42y • サーバサイドエンジニア • rubyとかrustとかgoとかC++とか • Twitter、github → ota42y • 最近はサーバレスしたりGPUで遊んだり ElasticSerachしたり色々… 自己紹介
3. 3. • 技術書典4でマイクロサービス本を出した – https://ota42y.com/blog/2018/04/10/mi croservices_yorozu_book/ – C94の1日目西め06aで再販した本を出します 自己紹介
4. 4. イベントドリブンアーキテクチャ
5. 5. イベントドリブンアーキテクチャ • イベントベースで情報をやりとりするアーキテクチャ • 送り手はイベントを起こすだけで受け手を知らない • 受け手はイベントの監視だけで送り手を知らない • 疎結合に組める
6. 6. • 詳しくは過去の発表資料を… • マイクロサービスにおける 非同期アーキテクチ • https://www.slideshare.net/ota42y/ss- 80254350 • Rails DMの動画も公開されました • https://www.youtube.com/watch?v=amsQa PIajqs イベントドリブンアーキテクチャ
7. 7. • AWS SNS/SQSを利用したpub/subシステム • 送り手はSNSにイベントを送る • 事前に受け手はキュー(SQS)でSNSをsubscribe SNS/SQSによるイベントドリブン Lifelog Ranking Point AWS SNS AWS SQS
8. 8. • AWS SNS/SQSを利用したpub/subシステム • 送り手はSNSにイベントを送る • 事前に受け手はキュー(SQS)でSNSをsubscribe • SNSはイベントをSQSにコピーして送ってくれる • サーバのworkerがSQSを監視して中身を取り出す SNS/SQSによるイベントドリブン Lifelog Ranking Point AWS SNS AWS SQS
9. 9. • AWS SNS/SQSを利用したpub/subシステム • 送り手はSNSにイベントを送る • 事前に受け手はキュー(SQS)でSNSをsubscribe • SNSはイベントをSQSにコピーして送ってくれる • サーバのworkerがSQSを監視して中身を取り出す • 今回はこの取り出す部分の話 SNS/SQSによるイベントドリブン Lifelog Ranking Point AWS SNS AWS SQS
10. 10. 外部イベントの処理フロー
11. 11. • WorkerがSQSに入っているイベントを取って処理する イベントドリブンアーキテクチャ A MyServer SNS SQS Login Event
12. 12. • WorkerがSQSに入っているイベントを取って処理する • キューに入るイベントの種類は一つではない • 送り手は複数種類のイベントをpublishする • 複数の送り手のイベントをsubscribeしている イベントドリブンアーキテクチャ A MyServer SNS SQS Login Event B Buy Event Logout Event
13. 13. • イベントに対して適切に処理を分けないといけない • 誰がどうやってそれを管理するか • イベント事の違いをどこで吸収するか • 交通整理をするのは誰か?という話 イベントドリブンアーキテクチャ A MyServer SNS SQS Login Event B Buy Event Logout Event ?
14. 14. • この処理フローはRails wayの外 • ActiveJobとかと違って外部から非同期データが来る • Model層のような場所は共通化したい • 既存のRails wayとどう整合性を合わせるか イベントドリブンアーキテクチャ A MyServer SNS SQS Login Event B Buy Event Logout Event ?
15. 15. 既存のレールを知る HTTP Requestの処理フロー
16. 16. • リクエストの処理フロー • リクエストのパスとメソッドを取り出す • routes.rbのルールに沿って解釈 HTTP Requestの処理フロー UserControllershow user Request create post Request routes.rb PostController Model Model
17. 17. • リクエストの処理フロー • リクエストのパスとメソッドを取り出す • routes.rbのルールに沿って解釈 • 見つけたcontrollerを呼び出す HTTP Requestの処理フロー UserControllershow user Request create post Request routes.rb PostController Model Model
18. 18. • リクエストの処理フロー • リクエストのパスとメソッドを取り出す • routes.rbのルールに沿って解釈 • 見つけたcontrollerを呼び出す • controllerはパラメータを見たりして処理をする • 処理自体はmodel層とかが基本(のはず) HTTP Requestの処理フロー UserControllershow user Request create post Request routes.rb PostController show user params Model Model create post params
19. 19. レールに合流する 非同期イベントの処理フロー
20. 20. Login Event Buy Event • イベントの処理フローはリクエストの処理を真似できる イベントの処理フロー Model Model SQS
21. 21. Login Event Buy Event • routes.rbがやっていたこと相当 • 取ってきたEventから種類を判定 • どういった処理を実行するかを決定する イベントの処理フロー ? ? routes.rbっぽい 何か ? Model Model controllerっぽ い何か
22. 22. Login Event Buy Event • controllerがやっていたこと相当 • パラメータから必要なデータを取り出して実行 イベントの処理フロー ? ? routes.rbっぽい 何か ? login event params Model Model buy event params controllerっぽ い何か
23. 23. Login Event Buy Event • パラメータを取り出した先はRailsの普通のフロー • Railsのレールに合流する イベントの処理フロー ? ? routes.rbっぽい 何か ? login event params Model Model buy event params controllerっぽ い何か ここはいつも通り
24. 24. Login Event Buy Event • パラメータを取り出した先はRailsの普通のフロー • Railsのレールに合流する • 既存のメタファーを活用 • routes.rbとcontrollerがイベント用に形を変えた イベントの処理フロー ? ? routes.rbっぽい 何か ? login event params Model Model buy event params controllerっぽ い何か ここはいつも通り
25. 25. イベント処理の実装 workerとhandler層
26. 26. • イベントのプロトコル • イベントのフォーマットを決める • イベントのルーティング • イベントに対応するHandlerを設定 • イベントを処理するHandler層 • controllerに相当するイメージ イベント処理の実装
27. 27. Login Event Buy Event ? ? routes.rbっぽい 何か ? login event params Model Model buy event params controllerっぽ い何か • 送り手が自由すぎると受け手が対応するのがつらい • HTTPだとパスとメソッドでcontrollerを決定できる • パラメータも決められたところに設定する • イベント処理では決まりがない… • routes.rbの役割を誰がやるのか ルーティングを解決する この辺
28. 28. • raising_dragon • https://github.com/ota42y/rising_dragon • イベントのルーティングを解決する役割 • shoryukenベースのSQSを見るワーカー機能 • イベント処理のプロトコルを共通化する • イベント処理のルーティングをする RisingDragon
29. 29. • 送り一定のルールに沿ってイベントを送らせる • イベントのtype、id、タイムスタンプを必須に • イベント固有のデータをdataの中に プロトコルを決める 送り手の自由にできる領域
30. 30. • 送り一定のルールに沿ってイベントを送らせる • イベントのtype、id、タイムスタンプを必須に • イベント固有のデータをdataの中に • 受け手の処理が楽に • typeは必ずあることが保証される→自動で処理可能 • 受け手はdataだけ見れば良い プロトコルを決める 送り手の自由にできる領域
31. 31. • イベントにはtypeが必ず入る • これを利用してどのクラスを呼び出すかを決める • イベント名とHandler(後述)クラスを指定する ルーティングを設定する
32. 32. • gemで共通化 • RisingDragon • 送り手と受け手に入れる • 共通フォーマットは意識しなくていい • イベント固有のデータだけ考える ルーティングの解決まとめ RisingDragon Login Event Buy Event ? ? login event params Model Model buy event params controllerっぽ い何か
33. 33. • イベントにおけるcontrollerの役割 • 送られてきたデータを取り出す Handler層 LoginHandler BuyHandler Handler Login Event Buy Event login event params Model Model buy event params RisingDragon
34. 34. • eventのdataを見て処理する • 必要なものはdataに全部入ってるはず • typeでクラスが決まるのでそれは見なくていい • controllerでpathは普通見ないし Handler層 LoginHandler BuyHandler login event params Model Model buy event params Handler
35. 35. • eventとRailsのレールとの橋渡し役 • この層から先は通常のRailsのフローに乗せる • Modelとかに処理をさせる • renderしないcontrollerのような役割 • app/handler以下にファイルを置いてる Handler層 LoginHandler BuyHandler login event params Model Model buy event params Handler
36. 36. まとめ
37. 37. まとめ • イベントドリブンアーキテクチャはRailsのレールの外 • Railsのレールにうまく合流したい • routes.rbとcontrollerのメタファーを利用する • controller層に相当するhandler層の提案 • eventとhandlerの対応付けを記述する LoginHandler BuyHandler Handler Login Event Buy Event login event params Model Model buy event params ルーティング層
38. 38. まとめ • 送り手〜受け手のイベント形式を決める • RisingDragon • 送ってからhandlerまでの処理は自動で行われる • Handlerの中だけを書けば良くなる A SNS SQS Login Event B Buy Event Logout Event LoginHandler BuyHandler Handler RisingDragon