Railsでは同時に複数の操作を自動的に実行できます。
スレッド化Webサーバー（RailsデフォルトのPumaなど）を用いると、複数のHTTPリクエストが同時に配信され、各リクエストはコントローラ固有のインスタンスに渡されます。
スレッド化Active Jobアダプタ（Rails組み込みのAsyncなど）も、同様に複数のジョブを同時実行します。Action Cableも同様に管理されます。
これらの仕組みはすべてマルチスレッドに関連します。各スレッドは、グローバルなプロセス空間（クラス、クラスの設定、グローバル変数など）を共有しつつ、何らかのオブジェクト（コントローラ/ジョブ/チャンネル）固有のインスタンスの動作を管理します。共有情報が変更されない限り、他のスレッドの存在はほとんど無視されます。
本ガイドでは、Railsが「他のスレッドをほぼ無視できるようにする」仕組みと、拡張機能や特殊な用途に用いられるアプリケーションでスレッドが使われる仕組みについて解説します。
Railsの「Executor」は、アプリケーションのコードをフレームワークのコードから切り離します。自分の書いたアプリケーションのコードがフレームワークで呼び出されるたびに、Executorによってラップされます。
Executorはto_runとto_completeという2つのコールバックでできています。Runコールバックはアプリケーションのコードが実行される前に呼び出され、Completeコールバックはアプリケーションのコードの実行後に呼び出されます。
デフォルトのRailsアプリケーションでは、以下の部分でExecutorのコールバックが利用されます。
- 自動読み込みや再読み込みを安全に行えるスレッドがどれかをトラッキングする
- Active Recordクエリキャッシュをオン/オフする
- 獲得したActive Recordコネクションをコネクションプールに返す
- 内部キャッシュの寿命を制限する
Rails 5.0より前は、これらの一部をRackミドルウェアのクラス（ActiveRecord::ConnectionAdapters::ConnectionManagement）で扱ったり、ActiveRecord::Base.connection_pool.with_connectionなどのメソッドで直接ラップしていました。Executorはこれらをより抽象度の高い単一のインターフェイスで置き換えます。
アプリケーションのコードを呼び出す何らかのライブラリやコンポーネントを書く場合は、次のようにexecutor呼び出しでラップすべきです。
Rails.application.executor.wrap do
# アプリケーションのコードをここで呼び出す
end
長時間実行されるプロセスからアプリケーションのコードを呼ぶ場合は、代わりにReloaderでラップするとよいでしょう。
各スレッドは、アプリケーションのコードを実行する前にこのようにラップされるべきです。これにより、アプリケーションで何らかの作業を他のスレッドに手動で委譲する場合（Thread.newを使うなど）や、Concurrent Rubyのスレッドプールを用いる場合は、そのブロックをただちに以下のようにラップすべきです。
Thread.new do
Rails.application.executor.wrap do
# ここにコードを書く
end
end
Concurrent Rubyで使われるThreadPoolExecutorにexecutorオプションが設定されていることがありますが、これはその名に反してExecutorとは無関係です。
Executorは安全に「リエントラント」にできます。現在のスレッドで既にアクティブになっている場合、wrapは何も実行しません。
アプリケーションのコードをブロックで囲むと実用上問題がある場合（Rack APIで問題が生じる場合など）は、次のようにrun!とcomplete!を組み合わせる方法も使えます。
Thread.new do
execution_context = Rails.application.executor.run!
# ここにコードを書く
ensure
execution_context.complete! if execution_context
end
Executorは現在のスレッドをReloading Interlockでrunningモードに設定します。アプリケーションでアンロードやリロードが発生中の場合は、この操作が一時的にブロックされます。
Reloaderは、Executorと同じようにアプリケーションのコードをラップします。現在のスレッドでExecutorが既にアクティブでなくなった場合は、Reloaderが呼び出しを行うので、呼び出す必要があるのはいずれか1つだけです。また、これによってReloaderのすべての挙動（あらゆるコールバック呼び出しを含む）がExecutor内部で行われることも保証されます。
Rails.application.reloader.wrap do
# アプリケーションのコードをここに書く
end
Reloaderは、フレームワークレベルで長時間実行されるプロセスがアプリケーションのコードを繰り返し呼び出す場合（Webサーバーやジョブキューなど）にのみ適しています。RailsはWebリクエストやActive Jobワーカーを自動的にラップするので、Reloaderを手動で呼び出す必要はめったにありません。Executorの方が自分のユースケースにふさわしい可能性があるかどうかを常に検討しましょう。
Reloaderは、ラップされたブロックが実行される前に、現在実行中のアプリケーションを再読み込みする必要があるかどうか（モデルのソースコードファイルが変更された場合など）をチェックします。たとえば、再読み込みが必要と判断されると、Reloaderは安全になるまで待機してから再読み込みを行い、それから実行を継続します。変更が行われたかどうかにかかわらず常に再読み込みするようアプリケーションが設定されている場合は、ブロックの末尾で再読み込みが実行されます。
Reloaderにもto_runコールバックとto_completeコールバックが備わっており、呼び出しが行われる場所もExecutorと同じですが、現在実行中にアプリケーションで再読み込みが始まった場合にのみ実行される点が異なります。再読み込みが不要とみなされた場合、Reloaderはラップされたブロックの呼び出しでその他のコールバックを実行しません。
再読み込みプロセスで最も重要な部分は、クラスのアンロードです。このとき、自動読み込みされたクラスがすべて削除され、再度読み込み可能な状態になります。クラスのアンロードは、reload_classes_only_on_change設定に応じて、RunコールバックやCompleteコールバックの直前で即座に行われます。
クラスのアンロードの直前や直後にさらに何らかの再読み込みが必要になることがよくあるので、Reloaderにはbefore_class_unloadコールバックやafter_class_unloadコールバックも備わっています。
Reloaderを呼び出す場所は、長時間実行される「トップレベル」プロセスに限定すべきです。そうすることで、再読み込みが必要と判断された場合に、他の全スレッドがExecutor呼び出しを完了するまでブロックされるようになるからです。
万一Reloadの呼び出しが「子」スレッドで発生し、かつExecutor内部で親スレッドが待ち状態になっていると、回避できないデッドロックが発生する可能性があります。再読み込みは子スレッド実行前に行われなければならないにもかかわらず、親スレッドの実行中は安全に再読み込みできないからです。子スレッドではReloaderではなくExecutorを使うべきです。
Railsフレームワークのコンポーネントでは、必要な並行性（concurrency: コンカレンシー）の管理にもこのツールが用いられています。
RackミドルウェアであるActionDispatch::ExecutorとActionDispatch::Reloaderは、それぞれExecutorとReloaderでリクエストをラップします。2つのRackミドルウェアはデフォルトのアプリケーションスタックに自動的にインクルードされます。Reloaderは、コードが変更されたときに常に新しく読み込まれたアプリケーションでHTTPリクエストを配信するようにします。
Active Jobでもジョブ実行をReloaderでラップし、キューに積まれた各ジョブを実行するときに最新のコードが読み込まれるようにします。
Action CableではReloaderではなくExecutorが使われます。Action Cableコネクションはクラスの特定のインスタンスに紐付けられていて、Websocketメッセージが到着するたびに再読み込みすることが不可能なためです。Action Cableではメッセージハンドラのみがラップされるので、長時間実行されるAction Cableコネクションでも、新しく到着したリクエストやジョブによってトリガーされる再読み込みはブロックされません。代わりに、Action CableはReloaderのbefore_class_unloadコールバックを用いてすべてのコネクションを切断します。クライアントが自動的に再接続すると、そのことが新バージョンのコードに伝わります。
上記はフレームワークのエントリポイントなので、それぞれのコンポーネントは自身のスレッド群が保護されていることを確認し、再読み込みが必要かどうかを決定する責務を負います。その他のコンポーネントは、追加のスレッドを生成するためだけにExecutorを必要とします。
Reloaderは、config.enable_reloadingがtrueかつconfig.reload_classes_only_on_changeがtrueの場合にのみファイルの変更をチェックします。これらはdevelopment環境でのデフォルトです。
config.enable_reloadingがfalse（productionのデフォルト）の場合は、ReloaderはExecutorへのパススルーのみを行います。
Executorは、データベース接続の管理などの重要な作業を常に抱えています。config.enable_reloadingがfalseかつconfig.eager_loadがtrue（productionのデフォルト）の場合、Reloading Interlockは不要になります。development環境のデフォルト設定では、ExecutorはReloading Interlockを利用して、安全な場合にのみ定数を再読み込みます。
Reloading Interlockは、マルチスレッド実行環境での再読み込みを安全に行えるようにします。
アンロードや再読み込みは、実行中のアプリケーションコードが存在しない場合にのみ安全に実行できます。再読み込みの後、たとえば定数Userが別のクラスを指している可能性があります。このルールがないと、再読み込みのタイミングが悪ければUser.new.class == Userがfalseになるだけでなく、User == Userまでfalseになる可能性があります。
Reloading Interlockはこの制約を解決するため、どのスレッドが現在アプリケーションコードを実行しているかをトラッキングして、他のスレッドがアプリケーションコードを実行していない場合にのみ再読み込みが行われるようにします。
🖋 GitHubで編集を提案する
/
📕 英語で読む
Railsガイドは GitHub の yasslab/railsguides.jp で管理・公開されております。本ガイドを読んで気になる文章や間違ったコードを見かけたら、気軽に Pull Request を出して頂けると嬉しいです。Pull Request の送り方については GitHub の README をご参照ください。
原著における間違いを見つけたら『Rails のドキュメントに貢献する』を参考にしながらぜひ Rails コミュニティに貢献してみてください 🛠💨✨
本ガイドの品質向上に向けて、皆さまのご協力が得られれば嬉しいです。
Railsガイド運営チーム (@RailsGuidesJP)
Railsガイドは下記の協賛企業から継続的な支援を受けています。支援・協賛にご興味あれば協賛プランからお問い合わせいただけると嬉しいです。
- Star
-
-
