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