ライブ配信アプリにおける柔軟な配信インフラの選定

ライブコミュニティ事業本部Pococha事業部の平野・小張です。この記事では、ライブ配信アプリPocochaにおける、現状の AWS IVS を用いた配信インフラに加え、新たな候補として TRTC を検証対象とし、複数の配信インフラを柔軟に活用するための考察を紹介します。

1. １つの配信インフラに依存する課題と、複数の配信インフラを活用する利点

ライブ配信アプリは、配信者の映像や音声を配信サーバーに送信し、それを視聴者に届ける仕組みを持っています。主な配信インフラとして、Amazon Interactive Video Service (Amazon IVS)、Tencent クラウドストリーミングサービス (CSS)、Wowzaなどがあります。これらを利用することで配信サービスを展開できますが、以下の課題があります。

1.1 耐障害性の課題

一つの配信インフラに依存すると、サービス全体がそのインフラの耐障害性に依存することになります。これは、配信インフラに障害が発生した際に、サービス全体が停止してしまうリスクを伴います。過去には配信インフラの障害により、サービスを一時停止する必要に迫られた場面がありました。

ライブ配信は、その瞬間の体験を提供するものであり、常に安定した配信が求められます。特に、大規模なイベントや重要なライブストリーミングの場合、一度の障害が大きな損失をもたらすことがあります。そのため、耐障害性を高めるためには、一つのインフラに依存せず、複数のインフラを利用してリスクを分散させることが重要です。これにより、どれか一つのインフラに障害が発生しても、他のインフラがバックアップとして機能し、サービスの継続を可能にします。

1.2 品質の柔軟性

配信サービスは技術革新が激しく、数年前の低遅延技術が現在では陳腐化することもあります。例えば、かつて最先端とされていた低遅延技術が、新しいプロトコルや技術の登場により、もはや標準的なものとなってしまうことがあります。このように、技術の進化は非常に速いため、常に最新の技術を取り入れることが重要です。

新しい通信プロトコルを採用するインフラも次々と出現しており、これに対応するための柔軟性が求められます。例えば、QUICやSRTなどの新しいプロトコルが登場し、それぞれに異なる利点と特性があります。これらの新技術を迅速に取り入れることで、配信の品質を向上させることが可能ですが、一つの配信インフラに依存しているとこれらの技術を効果的に活用することが難しくなります。

さらに、視聴者の要求も年々高度化しています。高解像度、低遅延、安定したストリーミング品質など、さまざまな要件に応じた対応が求められます。一つのインフラでは、すべての要求に応えることが難しく、結果としてユーザー体験が損なわれる可能性があります。

そのため、複数のインフラを利用し、それぞれの強みを活かして品質を向上させることが重要です。例えば、特定のインフラは低遅延に強みがあり、別のインフラは高解像度配信に適しているかもしれません。これらを組み合わせることで、ユーザーに対して最適な品質の配信を提供することができます。

1.3 コストの最適化

競争が激化する中で、コストの柔軟な選択肢も求められます。配信サービスの運営には、多大なコストがかかります。特に、高品質な配信を実現するためには、安定したネットワークや高性能なサーバー、最新の技術を導入する必要があり、その結果として運営コストが増大します。したがって、配信の品質だけを追求するとコストが上がるため、配信のスタイルに応じてコストを最適化する必要があります。

例えば、大規模なイベントや重要なライブストリーミングでは、高解像度で遅延の少ない配信が求められるため、より高性能なインフラを利用することが適切です。しかし、音声のみの配信や動きの少ない配信では、そこまでの品質を必要としない場合も多く、コストを抑えるために、性能はそこまで高くないがコストパフォーマンスに優れたインフラを選択することが考えられます。

2. 改善構成案

これらの課題を解決するためには、複数の配信インフラを柔軟に選択できる環境が必要です。設計の際に以下の条件を意識しました。

サービスで利用している基本機能を有している
各環境やプロトコルの良さを活かす
配信や配信者ごとに配信インフラを変更できる

2.1 要求する基本機能

改善構成を実現するためには、いくつかの基本機能が求められます。これらの機能は、現在サービス内で利用されているもので、スムーズな導入のために必須としました。

まず、ユーザーへのアーカイブの提供や事件発生時に警察対応をするために、配信映像をストレージに保存できることが求められます。 S3に保存できることがベストですが、プライバシーや安全性が十分に配慮されている場合は各インフラのストレージを利用することも検討しています。

次に、配信サービスの品質を向上させるためには、視聴者の行動や配信のパフォーマンスを詳細に分析することが重要です。したがって、配信視聴のメトリクスを取得できることが必須です。これにより、視聴者の傾向や配信のパフォーマンスを把握し、サービスの改善点を見つけ出すことができます。

そして、Pocochaではリアルタイムで配信状況を監視し、問題が発生した場合に迅速に対応するために、監視体制を整えています。これらの監視環境はWebで行われているため、Webでの視聴ができることが必須になります。

最後に、技術的な問題や不具合が発生した際に迅速に解決するためには、サポート体制の充実が重要です。配信インフラを提供する事業者による、SDKの不具合などの相談ができるサポート体制が整っていることが求められます。これにより、技術的な問題が発生した際にも迅速に対応でき、配信サービスの安定性を確保することができます。

2.2 各環境やプロトコルの良さを活かす

ライブ配信サービスを最適化するためには、各環境や通信プロトコルの利点や特性を最大限に活かすことが重要です。先述の通り、通信プロトコルはそれぞれに特有の利点や特性があり、一つのプロトコルに固執することなく、多様なプロトコルを利用することで、より柔軟かつ効率的な配信が可能になります。

具体的には、プロトコルを共通化せず、各プロトコルの特性を考慮し選択することで、配信の品質を向上させることができます。

これを実現するために、クライアントに配信インフラごとのSDKを導入し必要に応じて切り替えることになります。

2.3 配信や配信者ごとに配信インフラを変更できる

コストやユーザー体験を最大化するために、配信開始時にサーバー側で配信のケーパビリティを判断し配信の条件や視聴者の状況に基づいて、最適なインフラを動的に選びます。例えば、イベントなどの時間が重要な場面では、遅延の短い配信インフラを選択することで、視聴品質を向上させることができます。

このように、配信や配信者ごとに配信インフラを柔軟に変更することで、常に最適な配信体験を提供することが可能になります。これにより、視聴者満足度を高め、サービスの競争力を維持することができます。

3. 構成実現のための課題

複数の配信インフラを柔軟に選択できる環境を構築するためには、いくつかの課題を解決する必要があります。

まず、複数のSDKを導入することで、実装が複雑化するという課題があります。異なるSDKを統合するためには、共通化できる設定値や機能についてインターフェースを定義します。基本的は配信視聴や、ミュート機能、ビットレートの設定などがこれに当たります。これにより、異なるSDK間での互換性を確保し、実装の複雑さを軽減することができます。

また、カメラの操作やエフェクトの処理についても課題があります。これらの機能は配信インフラの提供するSDKに含まれていることもありますが、Pocochaでは映像ソースは分離して管理しています。具体的には、カメラ操作やエフェクト処理を独立したモジュールとして設計し、各配信インフラのSDKからこれらの機能を呼び出す形にすることで、柔軟性を確保しつつ、実装の複雑さを抑えることができます。

このように、複数のSDKを扱うことで発生する実装の複雑化や、カメラ操作・エフェクト処理の分離といった課題を解決することで、柔軟で効率的な配信インフラの構築が可能となります。

4. 構成実現

4-1. Server

Pocochaの配信に関するサーバー側の既存実装は、Amazon IVSに深く依存しており、Tencentクラウドなどが提供する他の配信インフラを導入するには、大規模なリファクタリングが必要でした。そこで、配信開始/終了において、以下の図のように配信インフラに依存しない処理の流れを実装しました。

配信開始/終了の処理の流れ

配信インフラの動的選択による最適化:
配信開始時に配信の条件や配信者の状況を評価し、最適な配信インフラを動的に選択します。これにより、コストを最適化すると共に、常に高品質な配信体験を提供することで、ユーザー体験の向上が図れます。

共通インターフェースによる柔軟性・拡張性の向上:
配信の開始および終了時の処理を管理する　BroadcastOriginManager は、共通のインターフェースとして機能し、具体的な配信インフラに依存しない形で動作します。この Manager は、具体的な処理を Strategy に委譲します。 Strategy に各配信インフラ固有の処理を集約することで、開発効率を損なわずに、機能の追加や変更が可能となっています。これにより、新しい配信インフラの導入や既存のインフラの変更が迅速に行えるようになり、ビジネス要件に柔軟に対応できるようになりました。

4-2. Client

クライアントアプリでは、これらの構成実現のために各種SDKをラップしたクラスを提供しています。クラスは大きくLivePlayerとLivePlayerViewに分かれており、標準的なビデオプレーヤークラスと同じように扱えるようなインターフェースを持っています。

protocol LivePlayer {
  func load(url: URL)
  func play()
}

struct IVSLivePlayer: LivePlayer {
  let base: IVSPlayer

  func play() { 
    base.play() 
  }

  func load(url: URL) { 
    base.load(url: url)
  }
}

let player = IVSLivePlayer()
let playerView = IVSPlayerView()
playerView.player = player
player.load(url: url)
player.play()

この仕組みにより、SDKの依存が少ないコードを実現できています。また、共通のprotocolを扱うことで次のようなFactoryクラスを作ることができます。

struct LivePlayerFactory {
  func make(_ liveEdge: LiveEdge) -> some LivePlayer {
    switch liveEdge {
      case .ivs(let url):
        IVSLivePlayer(from: url)
      case .rts(let token):
        IVSRTSLivePlayer(from: token)
      case .hls(let url):
        AVPlayer(from: url)
    }
  }
}

このFactoryクラスによって、抽象化された配信エンドポイントに応じて使用するLivePlayerの実装を分岐することができます。また、配信インフラを複数使い分けることが可能となり適切な品質やコストを選択することが可能になりました。配信機能でも同様の仕組みを採用しており、実験的に特殊な配信環境を検証することもできます。

SDKによっては特殊な設定や接続準備が必要なものもあるため、今後はより柔軟に実装が出来る設計を構想しています。あくまでprotocolは共通化するための仕組みであり、protocolの制約によってSDKの真価を発揮出来ないような状態にしないことを意識する必要があります。

5. 将来的な展望

このようなライブ配信アプリにおける柔軟な配信インフラの選定の取り組みにより、ライブ配信サービスの品質と柔軟性をさらに向上させ、ユーザーに対して一層魅力的な体験を提供していきたいと考えています。

将来的には、この仕組みを活用し、単純な配信視聴だけでなく、配信者同士のコラボレーションやサーバーサイドでのコンポジションといった高度な機能にも挑戦したいと考えています。これにより、複数の配信者がリアルタイムで共同作業を行ったり、サーバー側で映像や音声を合成することで、より魅力的で多様なコンテンツを提供できるようになります。

また、現在の構成ではインフラ起因の大きな問題が起きた際に、配信を継続することはできません、配信中に発生する問題に対して配信中にインフラを切り替える仕組みを構築するなど、視聴者に対して安定した配信体験を提供できる仕組みが必要だと考えています。これにより、配信の信頼性をさらに高めることができます。

さらに、より多くの環境で快適に視聴できる環境づくりを進めたいと考えています。さまざまなデバイスやネットワーク条件に対応するための最適化を行い、例えば低帯域幅のネットワーク環境でも高品質な配信が可能になるような技術が必要とされています。これにより、世界中の視聴者がどこからでも快適にコンテンツを楽しむことができるようになります。

今回のライブ配信アプリにおける柔軟な配信インフラの選定は、あくまで我々の配信環境の目標への一部に過ぎませんが配信サービス構築の参考になればと思います。