この2年間、複数の人々がほぼ遅延なしで仮想的に集まることができるリアルタイムアプリが急増しました。また、ユーザーの期待も高まっています。ユーザーは、リアルタイムのビデオやオーディオ機能が完璧に機能することを期待しています。リアルタイムアプリケーションを開発する開発者は、低レベルのインフラストラクチャの構築やメンテナンスに費やす時間を短縮したいと考えていることがわかりました。開発者たちは、自分たちのアイデアを本当に特別なものにするための機能を構築するために、より多くの時間を費やしたいとも述べています。
そこで本日、開発者がリアルタイムのオーディオ/ビデオアプリケーションを構築できる新製品を発表します。Cloudflare Callsは、以下のようなものを構築できるAPI群を公開しています。
- カスタムUIを採用したビデオ会議アプリ
- 司会者が選ばれた聴衆をスピーカーとしてステージに招き入れることができるインタラクティブな会話
- インストラクターだけが参加者全員を見ることができ、参加者はインストラクターだけを見ることができる、プライバシーを重視したグループワークアウトアプリ
- 1人または複数の人が1万人以上の聴衆とリアルタイムでビデオ通話できるリモート「炉辺談話」(100ミリ秒以下の遅延)
これらを実現するプロトコルがWebRTCです。Cloudflare Callsは、Cloudflareネットワークを「スーパーピア」にすることで複雑さをなくし、信頼性と安全性の高いリアルタイム体験の構築を支援する製品です。
WebRTCとは？
WebRTC はピアツーピアのプロトコルであり、2人以上のユーザーのデバイスが直接 に、ブラウザを離れることなく会話することを可能にします。ネイティブの実装では、ピアツーピアは通常、参加者が 2 人だけの 1 対 1 の通話ではうまく機能します。しかし、参加者を追加すると、ビデオのフリーズや参加者の同期がとれなくなるなど、信頼性の問題が発生することがよくあります。なぜでしょうか。参加者の数が増えると、ユーザーのデバイス間の調整オーバーヘッドも増加するためです。各参加者が他の参加者にメディアを送信する必要があるため、各コンピュータからのデータ消費量が指数関数的に増加します。
この問題を解決するのが、SFU (Selective Forwarding Unit) です。SFUは、参加者間の映像・音声データをインテリジェントに管理・ルーティングすることで、ユーザー同士をリアルタイムでアプリに接続するシステムです。SFUを利用するアプリは、各ユーザーが他のユーザーにデータを送信する必要がないため、各ユーザーに必要なデータ容量を削減することができます。SFUは、リアルタイムアプリケーションにおいて、誰が話しているかを判断する必要がある場合や、WebRTCサイマルキャストにおいて適切な解像度の映像を送信する場合などに必要となる部品です。
SFUの先にあるもの
SFUが集中処理型であることは弱点でもあります。集中型のWebRTCサーバーは特定のリージョンを必要とするため、速くなるのは一部のリージョンのみとなり、世界のほとんどのリージョンにいるユーザーにとっては遅くなります。
もし、世界中の郵便物を受け取ったり、送ったりする郵便局が1つだけだとしたら、世界中のほとんどの人への郵便物は遅れて届くことになります。SFUは、各ユーザーが送信した情報を受信し、郵便局のように適切な宛先に転送します。SFUが広く使われているのは、信頼性が高く、設定可能で、手頃な価格、大規模なもので、すぐに使える別の手段がほとんどないためです。
一般的に、SFUはパブリッククラウド上に自社で構築されます。高解像度のメディアを多くのデバイスで送受信するため、多くの帯域幅を消費します。また、リージョンとスケーラビリティを手動で設定する必要があり、開発工数のオーバーヘッドが大きくなります。
SFU-as-a-serviceを提供するだけでは、コストと帯域幅の効率という問題を解決できないと考えました。
世界最大級のWebRTCサーバー
従来のWebRTC実装による 5 人でのビデオ通話では、各人のデバイスが互いに直接会話します。WebRTC の用語では、5人の参加者のそれぞれをピアと呼びます。 5人での通話の信頼性は、最も弱いインターネット接続を持つ人 (またはピア) の信頼性と同じ程度にしかなりません。
「もしCloudflareがWebRTCピアとして機能するとしたら？」というシンプルな前提でCallsを構築しました。Callsは「スーパーピア」または「全世界にまたがる巨大サーバー」であり、最小公倍数のピアや集中処理型SFUの制限を超えてアプリケーションを構築することができます。開発者は、P2Pトポロジーの中で最も弱いピアの弱点を補おうとするのではなく、自分たちのアプリの強みに集中することができます。
Callsは、すべての参加者が1ヶ所の集中型サーバーに接続する従来のSFUポロジーを使用しません。その代わり、各参加者は自分のローカルなCloudflareデータセンターに接続します。他の参加者がそのメディアを取得したい場合、そのオリジナルのメディアストリームをホームにしているデータセンターが見つかり、データセンター間でトラックが自動的に転送されます。参加者同士が物理的に近い場合、メディアは世界中を回って集中管理された地域に送られるのではなく、同じデータセンターを使用するため、遅延が大幅に削減され、信頼性が向上します。
Callsは、設定可能でグローバル、リージョンレスのWebRTCサーバーで、Cloudflareの拡大し続けるネットワークと同じサイズです。WebRTCプロトコルは、ピアが メディアトラックを送受信することを可能にします。ビデオ通話中、コンピュータは通常、 2 つのトラックを送信しています。1 つは話している音声を含み、もう 1 つはカメラからのビデオストリームを含んでいます。Calls は WebRTC RTCPeerConnection API をCloudflareネットワークに実装し、ユーザーがメディアトラックをプッシュできるようにします。また、Callsは、同じピア接続のコンテキスト内で他のメディアトラックをリクエストできるAPIも公開しています。
今日、「WebRTC でリアルタイム」と言うと、50人以上の参加者によるビデオ会議で、各参加者が他の参加者と会話し、各参加者が他の49人の参加者の参加と退出を確認できるものを想像するでしょう。Calls APIは、バニラWebRTCだけでは実装できないきめ細かな制御を可能にします。Callsを使用して構築する場合、制限となるのは、技術ではなく、あなたの想像力だけです。
Cloudflare Callsは、パフォーマンスと信頼性のトレードオフなしに、標準のRTC APIを活用することができます。コールはエッジでPeerConnection APIを実装し、エンドユーザー同士が直接接続する際の予測不可能性を低減します。Callsは、Cloudflareのすべてのロケーションと、Cloudflareのすべてのサーバーで実行されます。Cloudflareネットワークは、世界人口の90%から10ミリ秒以内の距離にあるため、目立った遅延は生じません。
Cloudflare Callsは、JanusやMediaSoupなどの独自のWebRTCサーバーを運用している場合に有効なソリューションとなります。 Cloudflare Callsは、JanusやMediaSoupの既存のデプロイメントを置き換えることもできます。特に、単一の集中型デプロイメントにグローバルに接続するクライアントがいる場合、そのようなケースに適しています。
地域（リージョン）：地球
独自のリアルタイムインフラストラクチャを構築し、維持することは、アーキテクチャとスケーリングに関するユニークな課題を伴います。「どのリージョンをサポートするか？」、「別のクラウドリージョンにインフラを拡張する適正な数として何人以上のユーザーが必要か？」、「計画外の使用量の急増に対応するためにどのように拡張するか？」、「インフラの使用量が少ない時間帯に損失を出さないためにはどうするか」自社のWebRTCサーバーインフラを運用する場合、こうした難問に答え、その答えを見直し続けていかなければなりません。
Cloudflare Callsでは、これらの質問に答える必要がなくなります。Callsは、すべての接続にエニーキャストを使用するので、すべてのパケットは常に最も近いCloudflareのロケーションにルーティングされます。これは本質的にグローバルであり、あなたのユーザーは自動的に彼らの近くにあるロケーションからサービスを受けます。通話は利用状況に応じて拡張され、チームは独自の自動スケーリングロジックを構築する必要がありません。
「どこに問題があるのか」により速く答える
既存のWebRTCワークロードをお持ちのお客様は一様に、問題のトラブルシューティングを簡単に行えるようにしてほしいと言われます。ビデオ通話で複数人が会話する場合、ユーザーエクスペリエンスに問題が発生した場合のリスクはより高くなります。Webページの読み込みに失敗した場合、ユーザーは数分後に再試行するのが一般的です。ビデオ通話が乱れると、通話が終了してしまうことが多いのです。
Cloudflare Callsが観測可能性を重視することで、お客様は問題の真相をより早く知ることができるようになります。CallsはCloudflareのインフラストラクチャ上に構築されているため、OSI参照モデルのすべてのレイヤーからエンドツーエンドで可視化することができます。
Callsは WebRTC Statistics APIサーバーサイドビューを提供し、クライアントから送信されたデータのみに依存することなく、各ピア接続とその中のメディアの流れに関する問題を掘り下げることができるようにします。統計情報APIは、開発者が体験に関する情報を取得するのに慣れている標準的な場所であるため、これを選択しました。これはブラウザで利用可能な同じAPI であり、WebRTC接続のパフォーマンスに関する洞察を得るために、今すでに使用しているかもしれません。
プライバシーとセキュリティーを核にする
通話では、参加者同士でIPアドレスなどの情報を共有する必要がありません。例えば、治療者と患者をビデオ通話でつなぐアプリを作るとします。従来のWebRTCの実装では、患者と治療者の両方のデバイスが直接会話することになり、IPアドレスなどの潜在的な機密データが露出することになります。IPアドレスなどの情報を公開すると、ユーザーがDoS攻撃を受ける可能性があります。
Callsを使用する場合、WebRTCを使用することに変わりはありませんが、個々の参加者はCloudflareネットワークに接続します。Cloudflare Callsを利用したビデオ通話を4人で行うと、4人の参加者の端末はそれぞれCloudflareネットワークとのみ会話することになります。エンドユーザーにとっては、セキュリティとプライバシーが強化されただけで、ピアツーピアの通話と同じように感じられることでしょう。
最後に、Cloudflare Callsを通過するすべてのビデオとオーディオのトラフィックは、デフォルトで暗号化されています。Callsは、Argoを含むCloudflareの既存製品を活用し、ビデオオーディオコンテンツを安全かつ効率的にルーティングしています。
次は何を？
本日よりCloudflare Callsの未公開ベータ版をリリースします。Cloudflare Callsを試すには、招待をリクエストし、その後の数週間、受信箱を確認してください。
Callsは、ベータ期間中は無料でご利用いただけます。当社は、Callsをベータ版から一般利用への移行を希望する初期のお客様との協力関係を求めています。現在、リアルタイムビデオアプリを構築している方、従来のWebRTCインフラストラクチャの拡張に課題をお持ちの方、または単に探求したい素晴らしいアイデアをお持ちの方は、招待をリクエストする際、コメント欄にご記入いただければ、こちらからご連絡差し上げます。