データフロー
- 入室準備:フロントが WebSocket で自前サーバーに「入室したい」とリクエスト
- 認証:バックエンドが Agora のToken(合言葉)を生成してフロントに返す
- ビデオ通話開始:フロントがそのTokenを使ってAgoraチャンネルに参加
- 状態共有:参加したことをRedis Pub/Sub 経由で全サーバーに伝え、他の参加者の画面に「〇〇さんが入室しました」とWebSocket で通知。
Agora.io SDK(通信基盤・フロントエンド)
具体的な役割(メインの映像・音声)
- 自前でWebRTCのサーバー(SFU/MCU)を構築・運用するのにはとても難易度が高いです。Agoraがそれを解決し、その重たい処理を全て丸投げでき、簡単に実装できます。また、「ネットワークの品質」も非常に良いです。
Agora.io SDKの詳細
公式サイトはこちらです。
Voice SDK について
Agora.ioが提供するリアルタイム通信(RTC)の仕組みについて
基本の動き
- RTC SDK: 自分がフロントエンドに組み込むツールキットです。これがカメラやマイクのデータを制御します。
- Connect: ユーザーが「チャンネル(部屋)」に参加する動作です。
- SD-RTN™: Agoraが世界中に配置している超高速な仮想ネットワークです。これが自前で構築するのが難しい「SFUサーバー」の役割を代行し、データを最短経路で届けます。
Agora が用意してくれているもの(基盤)
左側の端(RTC SDK)と、右側(SD-RTN™)に該当する部分
- 映像・音声の送受信パイプライン: カメラやマイクからデータを取り込み、相手に届ける一連の処理。
- SD-RTN™(グローバルネットワーク): 世界中に配置されたサーバー群。これが、自前でSFU/MCUサーバーを立てる「地獄」のような非常に難しい構築・運用を担ってくれます。
- パケットロス補正・低遅延制御: ネットが不安定な場所でも、自動で映像を調整して極力カクつかないようにする高度なアルゴリズム。
- 多人数対応の最適化: 1対1から、何百人、何万人という規模まで自動でスケールする仕組み。
自分が実装(プログラミング)するところ
中央にかけての「Connect」や、アプリ独自のロジック部分
- SDKの制御: joinChannel(入室)や leaveChannel(退室)といった命令を出すコード。
- UI/UXデザイン: ビデオのレイアウト、通話ボタン、マイクのON/OFF切り替えなどの画面作り。
- Token(合言葉)の生成: 誰でもチャンネルに入れないように、期限付きの入室許可証を発行する処理。
- WebSocketによるシグナリング: 「Aさんがあなたに電話しています」という通知や、「通話開始!」といった制御信号の送受信。
- Redisによる状態管理: 「今、誰がどのサーバーのどの部屋にいるのか」を高速に同期・保持する仕組み。
- データベース連携(MySQLなど): ユーザー情報の管理、通話時間の記録、ポイント計算などのビジネスロジック。
(補足)WebRTC(SFU/MCU)とは?
- WebRTC:ブラウザやアプリの間で、サーバーを介さずに映像や音声をリアルタイムにやりとりするための共有規格。P2Pで、1対1(自分と相手)を直接つなぐのが得意です。しかし接続が不安定で難易度が非常に高いです。
- SFU:各自の映像をサーバーが受け取り、そのまま全員に転送する。構築は地獄並みに難しいです。回線状況が悪いとカクつきやすいです。
- MCU:サーバー側で全員の映像を1枚に合成して送ります。受信側の端末や回線が弱くても、1本の動画を受け取るだけでいいので安定しやすいです。
WebSocket(双方向通信・フロント/バック両方)
具体的な役割(リアルタイムな制御信号)
- 「着信通知」「入室・退出イベント」「チャットメッセージ」の送受信
- Agora だけでもメッセージ送信は可能ですが、自前のDB(複数サーバーの状態管理用)と連携させたりする場合は、自前の WebSocket サーバーがあった方が自由度は高くなる。
- 自前のDBでビジネスロジックを組む:通話開始時にDBの「通話中フラグ」を立てる。通話終了時に「通話時間」を保存してポイントを計算する。
WebSocketの参考文献
Redis Pub/Sub(状態管理/通知管理・バックエンド)
具体的な役割(サーバー間の連携)
- 複数台あるバックエンドサーバー同士の同期
- サーバー2台以上に増やした際、「WebSocketのメッセージ」を橋渡しするために必要となる
- WebSocketは「特定のサーバーが物理的につながっている状態」で、Redisがないと相手にメッセージが届かない。Redis を挟むことで、「どのサーバーに誰がいてもメッセージが届く状態」を作れる。
- Redisの理由:Key-Value 形式でメモリが揮発性なので、MySQLなどのリレーショナルより負荷が軽く高速なので、リアルタイムに更新し続けても耐えられる。
Voice / Video Call Channel(通常のビデオ通話)
- Publish(送信) : 自分の映像・音声をネットワークに流すこと。
- Subscribe(受信) : 相手の映像・音声を受け取ること。
- 特徴: お互いが送り合い、お互いを受け取る「双方向」の通信です。
Redisの参考文献
気付いたこと
通信基盤(Agora)の実装において、フロントエンド側でほとんど完結できるのは驚きでした。複雑なネットワーク処理=バックエンドの印象がありました。
バックエンドを単なるデータ保存場所としてではなく、WebSocket+Redis で状態や通知管理で使うことができるのを初めて知りました。
双方向通信やP2Pの特性を整理できた。もっとデータ処理についてのアーキテクチャ思考を身に付けたい。
まとめ
今回のブログを通じて、ビデオ通話アプリという複雑なシステムを構築するための計画が浮かんできましたでしょうか?
ビデオ通話技術は、一見すると「魔法」のように見えますが、その正体は「どのデータを、どの経路で、どのタイミングで流すか」というアーキテクチャの積み重ねです。
まずは Agora の SDK を触り、自分の顔が画面に映る瞬間の感動から始めてみてください。意外と簡単に作れてしまうかも??
ABOUT ME
2002年生まれの学生です。
趣味は小説を読むことです。たまに技術書も読みます。