Crafting Rails 4 Application 読み会（第５章）

Slide 1

Slide 1 text

Cra$ing Rails4 Applica0on Masatoshi Iwasaki 5. Streaming Server Events to Clients Asynchronously

Slide 2

Slide 2 text

概要 •  Railsで非同期にサーバーからクライアントにレスポンスを送り続ける方法を解説 •  WebSocketではなく Server Sent Events(SSE)を使う方法を解説。 •  これまでのplugin開発に継ぎ足してSSEを実装 – ここまでの章を読んで理解してないと多少つらい

Slide 3

Slide 3 text

Introduc0on •  ウェブアプリの大半は単一リクエスト＆レスポンスで事足りる。 – だが、そうでない場合もある。 •  クライアントとの接続を保持したまま、サーバーがクライアントにデータを送りたい。 – いわゆるストリーミング •  本章ではストリーミングをRailsで使う方法を紹介する。

Slide 4

Slide 4 text

本章のゴール •  Railsアプリからブラウザに対して、CSSが変更されたら通知を送るプラグインを作る。 •  プラグインはコントローラやアセットなどを持つため、Rails Engineを利用したプラグイン開発を行う。

Slide 5

Slide 5 text

（補足）読んでいてちょっと混乱したところ •  Pollingの話が二カ所出てくる – ブラウザからサーバーへのpolling – サーバー上でのファイル変更検知 •  CSSについては何が変更されたかを通知するだけ – CSSのURLは変わらないので、ブラウザ側で変更通知を受け取ったら再度同じURLからjsで再読み込みする。 – CSS自体は送らないので、後で出てくるSSEではイベント名だけが重要でdataは空のまま。

Slide 6

Slide 6 text

まずEngineを作る •  これまでと違って –full があるのが特徴。 •  これにより、conﬁg/routes.rbやapp ディレクトリが出来てcontrollerやmodelの追加が可能になる。

Slide 7

Slide 7 text

Rails::Engineの継承 •  lib/live_assets/engine.rb （画像左）で Rails::Engineを継承しているのが分かる。 •  Rails::Engineは可能な限り先に読み込まれないとまずいのでlib/live_assets.rb（画像右）で読み込んでいる。

Slide 8

Slide 8 text

Rails::Engineとは？ •  Rails::Rail0eとほとんど同じ。 •  違いはいくつかの初期設定とroutes.rbに含まれるルーティング情報がないこと。 •  よって、routesを設定に追加しないといけない。

Slide 9

Slide 9 text

Rail0eのroutesについて •  こんな感じで設定されている。 •  eager_load, load_pathなどpath毎に設定項目がある。

Slide 10

Slide 10 text

Ini0alizers •  Pathだけでは十分ではない。 •  Engineが自身をbootするために初期化しなければいけない項目が他にもいくつかある。 •  これらはRails::Engine.ini0alizersを見れば分かる。

Slide 11

Slide 11 text

LiveStreamingコントローラ •  まずは初期バージョンとして、コネクションが生きている限り１秒ごとに寝て起きてハローと叫ぶコントローラから。

Slide 12

Slide 12 text

•  もちろんroutes.rbに登録する。 •  今回はhelloアクションなので、toオプションでコントローラだけ指定してac0onはワイルドカードに。　 LiveStreamingコントローラ

Slide 13

Slide 13 text

Pumaを使う •  標準で利用されるWebrickはレスポンスが終わらないといつまでもバッファリングしてしまうため。 •  （現状Pumaくらいしかアプリケーションサーバーに選択肢はないと思うが）開発用に使うと言うことでadd_development_dependencyしてる。

Slide 14

Slide 14 text

すると、こうなる •  ヘッダが一度だけ表示されて、以後Hello World のみが繰り返されている。

Slide 15

Slide 15 text

（寄り道）ちなみに普通のGETだと •  GETのレスポンスが来てconnec0onが切れる。

Slide 16

Slide 16 text

サーバーからブラウザへデータを送る手法の歴史的経緯 •  はじめにpollingありき – ブラウザが継続的にサーバーに通信を送って受け取るデータが無いか確認 – 当然だがオーバーヘッドが大きい

Slide 17

Slide 17 text

Long Polling •  ブラウザがサーバーに問い合わせたときにサーバー側で更新が無ければレスポンスを返す前に時間を空ける •  通常のpollingよりは回数が減るが、ブラウザ間の互換性や無通信時間が長いと判断されてproxyにconnec0onを切られたりした。

Slide 18

Slide 18 text

HTML5の登場 •  Server Sent Events（SSE）とWebsockets •  違いは何か？ – Websocketsはブラウザとサーバーの相互通信をサポート – SSEはサーバーからクライアントへの一方通行 •  Websocketsはブラウザの互換性が影響するが、SSEはそこを気にせず使うことができる。 •  本章ではSSEを採用してLive Streamingを実現。

Slide 19

Slide 19 text

Event Stream Format •  SSEが採用するメッセージ形式 •  各メッセージは２つの改行で区切られる。 •  ここではJSON形式を使っているが、他の形式でもいい。

Slide 20

Slide 20 text

（補足） SSE深掘り •  厳密にはテキスト形式で text/event-‐stream として送信される。 •  最後に\nが２つ並んでいれば良いので、１メッセージの行数はいくつでもいい。 •  dataフィールドは必須。 •  他にも予約済みフィールド名がある模様。 –  Retry: 接続が切れた後に再接続するまでのタイムアウト時間（ms） –  Event: イベント名。JSのaddEventListnerでここに指定したイベント名をそのまま利用できる。参照先　h\p://www.html5rocks.com/en/tutorials/eventsource/basics/

Slide 21

Slide 21 text

コントローラ実装に戻る •  SSEを利用してサーバーにCSS再読み込みイベントを送るようにした。 •  発表者注：この時点ではまだ sleep 1が残っている。サーバーでCSSの変更を検知すると同時に ﬁle systemのpollingを避けるのは次のセクション。

Slide 22

Slide 22 text

JSの実装

Slide 23

Slide 23 text

ヘルパーメソッドの定義 •  これを定義することで、、

Slide 24

Slide 24 text

Layoutファイルでのasset呼び出し •  live_assetsメソッドでjsを読み込むことができる。

Slide 25

Slide 25 text

アプリ側アクションの作成 •  さっきまではpluginのコントローラでsseアクションを追加していたが、これはアプリ側。

Slide 26

Slide 26 text

マルチスレッドの設定 •  だが、これだけでは期待した通りに動かない •  allow_concurrency = trueにしないとRailsは単一スレッドでしか動作しない – よって、allow_concurrencyを有効にする。 •  発表者注：マルチスレッドの話は本章であまり深く触れられていない。

Slide 27

Slide 27 text

これで動くようになった •  デモをご覧ください。

Slide 28

Slide 28 text

残る問題 •  sleepして変更を検知するのは効率が良くない – ファイルが変更されたときだけクライアントに通知を送りたい。 •  テストが書けてない。 •  そもそもallow_concurrencyって何なんですか？

Slide 29

Slide 29 text

スレッドを利用したファイル変更検知 •  単純な方法：Filesystem polling – 一定時間毎にファイルが変更されていないかを調べに行く – 長期間変更されていないときにやるのは無意味 – 監視するスタイルシートの数が増えるほどCPU負荷が上がる。

Slide 30

Slide 30 text

変更検知をOSに任せる •  ほとんどのOSはファイルの変更を通知してくれるAPIを持っている。 •  Listen gemを使うことでこれらAPIを簡単に利用可能。 – ただし、各環境毎に別のgemが必要（後述） – 今回はassets/stylesheetsを監視したいので、このディレクトリを渡せば済む。

Slide 31

Slide 31 text

スレッドを使って実装

Slide 32

Slide 32 text

ファイル変更検知のテスト •  Integra0on testは書けないが、ファイル変更検知については切り出せたのでテストが書ける。

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

（補足）各環境のﬁlesystem no0ﬁca0on •  On windows •  On *BSD From h\ps://github.com/guard/listen

Slide 35

Slide 35 text

イベントが正しく送られるかのテスト •  今度は先にテストを書く。 •  さっきのテストと違ってEngineが読み込まれたときにstart_listnerは動いているという前提。

Slide 36

Slide 36 text

CSS変更検知のリスナー実装 •  Engineの中で定義することで、pluginが読み込まれた直後にlistnerが走るようになった。

Slide 37

Slide 37 text

CSS変更通知の流れ

Slide 38

Slide 38 text

まだ余計な待ちがある •  subscriberにeventが入るまでwhileで待っている –  CPUの無駄遣い •  Ruby の標準ライブラリにあるQueueを使って解決する。

Slide 39

Slide 39 text

スレッドとQueue •  ThreadとQueueを組み合わせることで簡単に解決できる。 •  Queueにアイテムがない場合、Threadはブロックされる。 – 逆にいえば、Queueに何かが入ったときだけスレッドが起きる。

Slide 40

Slide 40 text

Queueを使ってテストを変更

Slide 41

Slide 41 text

Subscriberの変更 •  Queueに対して subscribeするように変更。 •  Eachメソッドでblock を受け付けるようにしている。

Slide 42

Slide 42 text

（補足）subscribeの意味 •  本章ではLiveAssets#subscribeは単に subscribersとして引数のArrayを登録しているだけ。 – Subscribeメソッドのレシーバーが何かに対して subscribeするわけではない。

Slide 43

Slide 43 text

コントローラ部分を変更 •  Sleepが無くなった。

Slide 44

Slide 44 text

最後の「無駄」 •  ファイルが変更されなかった場合、通信が無いままずっと接続は維持される。 – サーバー、ブラウザ、proxyのいずれかで connec0onが切られる可能性がある。 •  ファイル変更がなくても一定時間毎にブラウザに対してpingを送ることで問題を回避する。

Slide 45

Slide 45 text

Timerのテスト実装 •  Queueに定期的にpingコマンドをsubscriberに通知するようにすればいい。

Slide 46

Slide 46 text

Timerの実装 •  Timerの場合、一定時間毎に起きて subscriberに通知するため、キューは使わずsleepを使って起きたときに通知すればいい。

Slide 47

Slide 47 text

Engineへの実装 •  １０秒ごとにevent: pingを送るようにする。

Slide 48

Slide 48 text

Code-‐Loading Techiniques •  requireでファイルを読み込む場合、起動前にすべてを読み込むことになる。 •  Autoload を使うことで最初に必要になったときに自動的に読み込むようにできる。 •  AutoloadにはRubyのものとRailsのものがある。 – Rubyのautoloadはatomicではない。そのため、あるスレッドでload中のときに他のスレッドがload対象となるクラスを参照していると参照が失敗する。 – いくつかのRuby実装がこの問題を解決中。

Slide 49

Slide 49 text

Railsのautoload •  Thread-‐safeではない。 – そのため、デフォルトではallow_concurrencyが falseになっている。 – 動作スレッドを１つに絞ることでautoloadの問題を解決している。 •  では、allow_concurrencyをtrueにしたというだけで問題は解決するのか？

Slide 50

Slide 50 text

Eager-‐Load Techiniques •  Produc0onではautloadは無効になり、起動時にすべてを読み込む（eager-‐loading）。 – しかし、appディレクトリのものしかeager-‐loadingしない。 •  本章ではRubyのautoloadを使ったので、自前でeager-‐loadingを実装しないといけない。

Slide 51

Slide 51 text

SSESubscriberのEager-‐loading •  SSESubscriberが最初に読み込まれないと、 loadが未完了の段階で複数のスレッドが動いてしまう。

Slide 52

Slide 52 text

Eager-‐loadingになっているかどうかの確認

Slide 53

Slide 53 text

Eager-‐loadingの効果 •  Unicornでも有効 – Unicornはpreforkを使うので、先に全部読み込んでおけばリクエスト毎にautoloadされるコストが削減される。 – 発表者注：その分、メモリ使用量が増える可能性はある。 •  この方法であればUnicornでもlive-‐streamingできる。 •  ただし、streaming用にプロセスが１つ占有されてしまう。

Slide 54

Slide 54 text

Threded vs Non-‐threaded •  銀の弾丸はない。 –  先ほどのPumaとUnicornの比較の通り。　 •  何が一番適しているかは複数のウェブサーバーでベンチマークを取ってみるしかない。 •  Jrubyなども検討要素。 –  ただし、Jrubyでは配列操作がthread-‐safedではないので対処が必要。　

Slide 55

Slide 55 text

ご清聴ありがとうございました