ライブイベントプラットフォーム
数千人が見て、反応する。チャット、投票、ステージ付きで、サーバーはピークに合わせて構築。
ライブとマルチプレイヤー
全員が、同じ場所に、同時に。
数千人のためのライブイベント、全員が同じ瞬間に同じものを見る共有空間、そして貴社自身の製品の中の音声、映像、共同編集。全員が一斉に訪れても持ちこたえるように作ります。
こんな経験はありませんか。
全員が参加した瞬間にローンチイベントが止まった。貴社の製品にコラボレーション機能がないので、チームは5つのツールで共同作業している。授業、オークション、コンサート、ゲーム。いちばん大事な瞬間は、いちばん多くの人がいる瞬間で、ありふれたソフトウェアが音を上げるのはまさにそのときです。
何が変わるか
01
アクセスの集中に耐える
最初の本番の前に、数千人分の模擬ユーザーで試験します。
02
全員が同じものを見る
ひとつの信頼できる情報源。誰も別の世界にいることはありません。
03
音声と映像が貴社のもの
通話、ステージ、画面共有を貴社の製品の中に、貴社のログインとルールで。
04
離れずに共同作業
カーソル、共同編集、コメント、在席表示を、すでにあるものに追加。
05
人の近くにある
リージョンごとのサーバー。レイテンシを測定し、報告します。
得られるもの
01
02
共有ルームと世界
2Dまたは3Dのひとつの空間に多人数が集まり、状態は同期されます。
03
コラボレーション層
貴社の製品の中の在席表示、共同編集、コメント。
04
音声と映像
通話、ステージ、同意のもとでの録画を、WebRTCで。
05
ストリーミング
低遅延の映像とデータを、リージョンごとにブラウザとアプリへ。
06
在席表示とチャット
誰がいて、誰が入力中で、何が変わったかを、ミリ秒単位で。
3つの例
01
ベンガルールの教育企業
400人で落ちるプラットフォームで、2,000人の生徒にライブ授業を。ピークに合わせて再構築し、教師の映像、ホワイトボード、チャットがインド全土で同期します。
02
ストックホルムのデザインソフトウェア企業
顧客は共同作業のためにファイルを他のツールへ書き出していました。製品内に在席表示、カーソル、コメントを追加し、チームは製品を離れなくなりました。
03
ドバイのオークションハウス
6か国の入札者、遅れる配信、遅れて届く入札。低遅延の映像と権威ある入札サーバーにより、すべての入札者が同じ瞬間に同じ落札を見ます。
進め方
01
打ち合わせ
何人が、何をして、世界のどこにいて、何が決して壊れてはならないか。
02
プロトタイプ
2週間: 50人をひとつのルームに、ライブで、貴社の実際の用途で。
03
お聞きした人数に合わせて構築
平均ではなくピークに合わせてアーキテクチャを選びます。
04
負荷試験
最初のイベントの前に、数千人分の模擬ユーザーで。
05
運用
監視、イベント中の待機、各イベント前の容量計画。
確かめられる証拠
私たちが運用したものの負荷試験レポートをお求めください。ユーザー数、リージョンごとのレイテンシ、そして修正前の試験でどこが壊れたか。
WebRTCとWebSockets、RustとGo、RedisとPostgreSQLで構築しています。よくいただく質問
ひとつのルームに何人まで入れますか
音声ルームで50人、ライブイベントで数千人、配信の視聴なら数百万人。お聞きした人数に合わせてアーキテクチャを選びます。
レイテンシはどのくらいを想定すべきですか
共有状態はリージョン内で数十ミリ秒、映像は0.5秒未満。測定し、報告します。
既存の製品に追加できますか
はい。貴社のアプリケーションの上の層として、貴社のログインで構築します。
録画とプライバシーはどうなりますか
録画は同意のもとでのみ行い、お客様が選んだ場所に保存し、国ごとの保管規則に従います。
イベント中も運用してもらえますか
はい。名前の決まったエンジニアが待機し、容量は事前に計画します。
作りたいものをお聞かせください。
エンジニアが内容を読み、数分以内にお客様の言語で返信します。どのプロジェクトも、固定価格の2週間のプロトタイプから始まります。