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

More Related Content

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

Editor's Notes

  1. この中に、マイクロサービスアーキテクチャを知ってる人どれくらいいますか? ありがとうございます、以外と少なくて資料作った会がありました…
  2. この中に、マイクロサービスアーキテクチャを知ってる人どれくらいいますか? ありがとうございます、以外と少なくて資料作った会がありました…