自社サービス

受託開発

会社情報

お知らせ

採用情報

ブログ

お問合せ

旧SkyWayと新SkyWayは何が変わったのか？アーキテクチャの違いを整理してみる

旧Skywayの終了期限が近づいているため、改めて新Skywayとの違いを整理してみました。

実際に触ってみると、

  • なぜ Subscribe が必要なのか？
  • Publication って何？
  • Room に入っただけでは映像が来ないのはなぜ？

といった疑問が出てきます。

これは単に API が変わったのではなく、
通信モデルそのものが変わっているためです。

この記事では、SkyWay の公式ドキュメントをもとに、
旧SkyWayと新SkyWayのアーキテクチャの違いを整理してみます。

結論：通信モデルが変わっている

SkyWay の公式ドキュメントでは、通信モデルについて次のように説明されています。

  • 旧SkyWay：電話モデル
  • 新SkyWay：Pub/Sub モデル

この違いが、新SkyWayのAPIの設計にも大きく影響しています。

旧SkyWayは「電話モデル」

旧SkyWayでは、主に次の概念で通信が構成されていました。

  • Peer
  • Room

アプリケーションの設計も、

  • 誰と接続するか
  • どの Room に入るか

という 接続そのもの を中心に考える形になります。

実際、旧SkyWayでは Room に入ると
他の参加者のメディアを比較的シンプルに受信できる設計でした。

新SkyWayは「Pub/Subモデル」

一方、新SkyWayでは通信の考え方が少し変わっています。

新SkyWayでは、Roomに参加した Member が

  • Stream を Publish（公開）
  • 他の Stream を Subscribe（購読）

することで通信が成立します。

つまり、

「接続する」というより
「何を公開し、何を購読するか」

を明示的に扱う設計になっています。

新SkyWayでは通信の要素が分かれている

新SkyWayでは、通信に関係する概念がいくつかに分かれています。

主な要素は次の通りです。

  • Room
    通信のグループ
  • Member
    Roomに参加しているユーザー
  • Stream
    映像・音声・データ
  • Publication
    公開された Stream
  • Subscription
    Stream を購読した状態

旧SkyWayに慣れていると少し細かく感じますが、
この構造によって通信状態をより明示的に管理できます。

Stream を Publish すると Publication ができる

新SkyWayでは、Stream を Publish すると
Room 上に Publication が作られます。

Stream
  ↓ publish
Publication

この Publication が存在することで、

「この Member はこの Stream を公開している」

という状態が Room 上に表現されます。

Subscribe すると Subscription ができる

他の Member は Publication を Subscribe することで、
Stream を受信できます。

Publication
  ↓ subscribe
Subscription
  ↓
RemoteStream

ここが旧SkyWayとの違いで、

Room にいるだけでは Stream は届きません

受信したい Member が
Subscribe を実行して Subscription を作る必要があります。

Publish / Subscribe は通信状態そのもの

新SkyWayでは、Publish / Subscribe は
単なる関数呼び出しではありません。

Roomの状態として、

  • Publication
  • Subscription

というリソースが作られます。

例えば、Publication を unpublish すると
関連する Subscription は自動的に削除されます。

つまり、

  • Publish → Publication ができる
  • Subscribe → Subscription ができる
  • Unpublish → Subscription も消える

という形で、通信状態がリソースとして管理されているのが特徴です。

認証の仕組みも変わっている

旧SkyWayでは主に 認証（Authentication） が中心でした。

一方、新SkyWayでは
トークンベースの認証・認可 が導入されています。

つまり、

  • 接続できるか
  • 何をできるか

をトークンで制御できるようになっています。

この仕組みによって、

  • Roomの操作
  • StreamのPublish
  • Memberの操作

などをアプリケーション側で細かく制御できます。

P2P と SFU も Room の設計に含まれる

新SkyWayでは、Roomの通信方式として

  • P2P
  • SFU

を選択できます。

Stream を Publish するときの通信方式も
Room の種類に依存します。

公式ドキュメントでは、

  • P2PRoom では SFU 通信は使えない
  • SFURoom では P2P 通信は使えない

と説明されています。

つまり通信方式は単なる最適化ではなく、
Room の設計に関わる前提条件になっています。

DataChannel の扱いも変わっている

旧SkyWayでは

room.send()

のような API がありました。

新SkyWayでは、この用途は

  • DataChannel
  • Room.metadata

などを使う形に変わっています。

また、公式ドキュメントでは

DataChannel は SFU 通信では使用できない

と説明されています。

このあたりも、
新SkyWayが 通信の用途ごとに責務を分ける設計になっていることが分かります。

見方を少し変えると理解しやすい

旧SkyWayと同じ感覚で新SkyWayを見ると、
APIが少し複雑に感じるかもしれません。

ただ、見方を少し変えると理解しやすくなります。

旧SkyWayの考え方

  • 誰と接続するか
  • Roomに入るか
  • 接続を維持する

新SkyWayの考え方

  • Roomに誰がいるか
  • 誰が何を Publish しているか
  • 自分は何を Subscribe しているか

この視点で見ると、新SkyWayの設計はかなり整理されています。

まとめ

旧SkyWayと新SkyWayの違いは、
単なるSDKの更新ではなく 通信モデルの変更にあります。

  • 旧SkyWay：電話モデル
  • 新SkyWay：Pub/Sub モデル

新SkyWayでは、

  • Room
  • Member
  • Publication
  • Subscription
  • トークンベース認証

といった仕組みを使って、
通信状態をより明示的に扱えるようになっています。

新SkyWayを理解するうえでは、

「接続するSDK」ではなく
「公開と購読で通信を構成するSDK」

として見ると分かりやすいかもしれません。

参考

  • SkyWay公式ドキュメント
  • 新SkyWay JavaScript SDK API Reference

タグ例：
SkyWay WebRTC リアルタイム通信 PubSub アーキテクチャ

WebRTC,エンジニアリング

Posted by エンジニアチーム