AWS IVSとSkyWayを選んだ理由 — SynQNowの配信アーキテクチャ

配信プラットフォームを作ると決めたとき、最初の分岐は「配信エンジンを自前で作るか、借りるか」でした。SynQNowは借りる側に振り切り、配信エンジンにAWS IVS、質疑応答の会話部分にSkyWayという2つのマネージドサービスを採用しています。

この記事では、その判断の理由と全体構成を説明します。

要件は現場から出てきた

技術選定の前に、20年の配信現場から持ち込んだ要件が4つありました。

1. 対話が成立する遅延であること。 演者の問いかけに視聴者がその場で反応できる、遅延1秒以内のモードが必要でした
2. 失敗できない現場で使えること。 株主総会やIR説明会は、配信エンジンそのものの安定性を個人の頑張りではなくサービス品質として担保する必要があります
3. クローズドにできること。 URLが流出しても、許可していない場所では再生させない
4. 少人数で運用できること。 プラットフォーム側のインフラ運用に人を張り付けた瞬間、現場に出る人手がなくなります

この4つを眺めると、実は最初の分岐の答えは半分出ています。

自前でSFUを立てる選択肢は、運用で捨てた

WebRTCで低遅延配信をするなら、オープンソースのSFU（配信サーバー）を自前で立てる選択肢があります。技術的には可能で、実際にそうしているサービスもあります。

私が捨てた理由は運用です。イベント配信の負荷は平常時ゼロ、開始5分前に一斉入場という極端なスパイク型で、このピークのためにサーバー群を設計し、スケールさせ、世界中の視聴者のために配置し、監視し、深夜のオンコールに備える——それはもう配信会社ではなくインフラ会社の仕事です。しかも2の要件（失敗できない）に対して、自前運用は「自分たちの徹夜」でしか品質を担保できません。

そこで方針を一つに決めました。土管は借りる。差別化は土管の使い方でする。 配信エンジンの安定性はマネージドサービスのSLAと運用実績に任せ、自分たちは現場の要件をアーキテクチャに翻訳することに集中する、という分担です。

AWS IVSを選んだ理由 — 2つのモードを1つの基盤で

借りると決めたあとの比較で、IVS（Amazon Interactive Video Service）を選んだ決め手は明確でした。WebRTC型とHLS型、性格の違う2つの配信エンジンが同じ基盤の中に揃っていることです。

プロトコル比較の記事で書いたとおり、WebRTCとHLSは優劣ではなく用途の違いです。同時性が要るイベントと、安定とさかのぼり再生が要るイベントの両方を1つのプラットフォームで受けるには、両方のエンジンが必要でした。これを別々のベンダーで持つと、契約も監視も障害対応も二重になります。IVSには次の2つがあり、これがSynQNowの2つの配信モードにそのまま対応しています。

IVSの構成要素	方式	SynQNowでの役割
IVS Real-Time	WebRTC	超低遅延モード。遅延1秒以内、対話・投票など同時性が要るイベント
IVS Low-Latency	HLS	追いかけ再生モード。数秒の遅延と引き換えに、シークバーで途中参加・見返しができる

IVSはTwitchの配信インフラをAWSのサービスとして切り出したもので、スパイク型の視聴負荷を世界規模で受け続けてきた実績があります。公開仕様でもReal-Timeは1ステージあたり1万視聴まで対応しており、規模の面で私たちが上限を設計する必要がありません。1の要件（遅延1秒以内）と2の要件（エンジンの安定性をSLAで担保）を、契約1つで両方満たせる構成です。

2つのモードは、イベントの設定ひとつで切り替えられます。現場でどう使い分けるかは配信モードの紹介ページにまとめています。

SkyWayを選んだ理由 — 配信と会話は別物

質疑応答で視聴者が発言する瞬間、その人は「視聴者」から「発言者」に変わります。ここでSynQNowは、発言者だけを配信とは別の会話用セッションへ引き上げる構成を取っています。担いでいるのがSkyWayです。

配信エンジンだけで質疑応答を組むこともできますが、分けたのには理由があります。1対多の配信と、少人数の会話は、最適化の方向が逆だからです。配信は「多数へ安定して届ける」ために作られ、会話は「少人数が快適に話す」ために作られています。エコーの処理、話者の切り替わり、参加者の出入り——会話特有の課題は、会話のために設計されたプラットフォームに任せるのが確実です。

SkyWayを選んだのは、NTTドコモビジネス系の国内サービスとして商用実績が長く、法人イベントで求められる安定性とサポート窓口を国内に持てるからです。誰をいつ壇上に上げるかは司会者コンソールから制御し、接続に必要なトークンは必ずサーバー側で発行します。

配信と会話を分けると、配信元では2系統の音を作り分けることになります。その具体的な組み方は配信のマイナスワン（n-1）とはで解説しています。

全体像

構成の全体像は次のとおりです。

レイヤー	構成
配信エンジン	AWS IVS（Real-Time / Low-Latency）をモードごとに使い分け
会話	SkyWay。発言者だけを動的に引き上げる
制御プレーン	AWSのマネージドサービスによるフルサーバーレス構成。自前のサーバー（EC2等）はゼロ
視聴制御	ドメイン制限＋ワンタイムトークン。トークンはサーバー側でのみ発行し、視聴URLから内部情報を推測できない設計
テナント分離	データも配信リソースも、テナント単位で分離

制御プレーンをフルサーバーレスにしたのは、SFUを自前で持たない判断と同じ理由です。平常時ゼロ・本番スパイクという負荷特性に対して、常時稼働のサーバーを持つ理由がありません。インフラはすべてコードで管理し、同じ構成を検証環境と本番環境に再現できるようにしています。

借りる選択で諦めたもの

マネージドに振り切った以上、諦めたものもあります。公平のために書いておきます。

• エンジン内部には手を入れられません。 画質や遅延のチューニングは、IVSが提供する設定の範囲内です。それより深い要求には応えられません
• エンジンの障害を自分で直せません。 だからこそ配信の設計では、オペレーターの記事で書いた「リカバリしにくいものから予見してバックアップを組む」原則をプラットフォーム自身にも適用しています
• ベンダーに依存します。 これは受け入れたうえで、依存を一箇所に集めて監視する構成にしています

それでも、20年現場をやってきた結論として、配信エンジンの安定性は自分の徹夜ではなくサービス品質で担保すべきだと考えています。私たちが張り付くべきはサーバーの前ではなく、お客様のイベントの現場です。

まとめ

• 配信エンジンは借りる。差別化は「土管の使い方」——現場の要件をアーキテクチャに翻訳する部分でする
• AWS IVSの決め手は、WebRTC型とHLS型の両エンジンが1つの基盤に揃っていること。これがSynQNowの2つの配信モードの土台
• 質疑応答は配信と切り離し、会話のために設計されたSkyWayに任せる。発言者だけを動的に引き上げる
• 制御プレーンもフルサーバーレス。平常時ゼロ・本番スパイクという負荷特性に、常時稼働のサーバーは要らない

このアーキテクチャの上で何ができるかは、機能の紹介ページにまとまっています。技術的な質問があれば、問い合わせフォームからどうぞ。