【Rails】Action Cableについて調べてみた
はじめに
こんにちは。Ruby on Railsを学習しているmockeyと申します。
現在卒業制作で作成中のアプリ内にOpenAI APIを使用したチャットボット機能を実装しています。
リアルタイムでの更新ができたらと調べていたところ、RailsにはAction Cableという仕組みがあることを知りました。
今回はその仕組みについて調べたことを学習記録の一環として記載していきます。
どなたかのお役に立てれば嬉しいです。
Action Cableとは?
Action Cableは、WebSocketとRailsの他の部分をシームレスに統合するためのフレームワーク。
これを使うことで、Railsアプリケーションにリアルタイム機能を簡単に追加でき、アプリのパフォーマンスや拡張性を損なうことなく、Rubyでリアルタイム通信を実現できる。
Rails 5から導入され、チャットアプリやSNSなど、リアルタイムの更新が必要な機能を簡単に作成できるようになった。Action Cableはフルスタックのフレームワークであり、クライアント側のJavaScriptとサーバー側のRubyの両方を統合して使うことができる。
WebSocketとは?
WebSocketとは、WebブラウザとWebサーバー間で双方向の通信を行うための通信プロトコル。
HTTPは、クライアントはまずサーバーにリクエストを送り、それに対してサーバーがレスポンスを返す。
一方、WebSocketはクライアントとサーバーのどちらからでもデータを送受信できる。クライアントとサーバー間で一度接続が確立されると、その接続を維持することができるので、都度データを要求しなくてもリアルタイムでデータ交換が可能になる。
コネクション
クライアントとサーバーの間の通信のことを指す。
1つのAction Cableサーバーは、同時にいくつものコネクションを持つことができる。
例えば、ユーザーが異なるブラウザタブを開いたり、スマホやタブレットなど別のデバイスを使うと、それぞれに対して別々のWebSocketコネクションが作成される。
これによって、同時ユーザーが複数の場所から同時にチャットやリアルタイムのやり取りが可能になる。
コンシューマー
WebSocketコネクションのクライアントは、コンシューマー(consumer)と呼ばれます。 Action Cableのコンシューマーは、クライアント側のJavaScriptフレームワークによって作成される。
コンシューマーとは?(Railsガイド)
WebSocketコネクションのクライアントは、コネクションのコンシューマーと呼ばれます。 ある個人ユーザーが「ブラウザタブ」「ウィンドウ」「デバイス」を開いて接続するたびに、コンシューマコネクションが1個ずつ作成されます
チャネル
チャネルは、リアルタイム通信を行うための枠組みであり、クライアント(ユーザー)が特定の情報やイベントを受け取れるようになる窓口のようなもの。リアルタイム通信におけるサーバーのようなもので、テレビのチャンネルのようにメッセージを配信する役割を持つ。
MVCのコントローラーと似ており、それに応じた処理を行う。
例)チャット機能の場合
ChatChannelというチャンネルがあるとすると、ユーザーはこのチャンネルにサブスクライブ(登録)することで、他のユーザーが送信したメッセージをリアルタイムで受け取れるようになる。
サブスクライバ
サブスクライバは、そのチャネルに参加するユーザーの役割。サブスクライバは、チャネルをサブスクライブ(登録)して、そこから情報を受け取ることができる。
1つのコンシューマーが複数のチャネルをサブスクライブすることもできる。これによって、ユーザーは複数の情報を同時に受け取ることができるようになる。
つまり、チャネルは情報を提供する場所で、サブスクライバはその情報を受け取りユーザーの役割である。
Pub/Sub
Pub/Subは、情報を送信する側(パブリッシャー)が、特定の受信者を指定せずにデータを送る仕組み。
誰が受け取るかを気にせずに、情報を広く配信することができ、Action Cableではサーバーと多数のクライアント間で通信することが可能になる。
ブロードキャスト
特定の情報を「ブロードキャスター」がチャネルにいる全てのサブスクライバ(受信者)に送信することを指す。
例えば、あるチャットルームでメッセージを送ると、そのメッセージがそのチャネルにサブスクライブしている全てのクライアントに配信される。
このように、ブロードキャストはチャネルにサブスクライブしている全ての受信者に情報を一斉に送信する仕組みである。
Action Cableでは、特定のイベントやアクションが発生したときに、その情報を介して全てのサブスクライバに送信する。
Action Cableの欠点
-
接続が失われるとメッセージが失われる
接続が失われてクライアントがサーバーに再接続すると、各サブスクリプションのチャネルオブジェクトが保持されずに破棄されるので、切断中のメッセージなどが失われる。 -
サーバー負荷が増える
同時に接続するクライアントの数が増えると、サーバーの負荷が大きくなり、WebSocket接続の管理が複雑化する。 -
デバッグの難しさ
HTTPリクエストとレスポンスの流れと異なるので、デバッグが難しく、リアルタイムの問題や遅延を追跡する事が難しい。 -
セキュリティの課題
認証や権限管理が不十分だと、不正アクセスやデータ漏えいのリスクが増す。
例えば、あるチャットアプリでユーザーがログインせずにWebSocket接続を行うことができるとする。
この場合、悪意のあるユーザーが他のユーザーのメッセージやデータにアクセスする可能性があるので、
認証が不十分だと誰でもチャットルームに侵入してプライベートな情報が漏れてまうことなどが考えられる。
おわりに
今回初めてAction Cableというフレームワークについて調べました。
リアルタイム機能を提供できるので、ユーザーの体験価値の向上には非常に有効な仕組みだという事が分かりました。
自身のアプリに組み込むかは上記の利点と欠点を照らし合わせて検討したいと思います。
ご覧いただきありがとうございました。
参考
Railsガイド Action Cableの概要
Rails 7でリアルタイム通信を実現! Action Cableの基本をチュートリアルとともに理解しよう
WebSocketとは何か?背景、HTTPとの違い、多彩な用途を解説!
Rails ActionCable - the good and the bad
Discussion