クラウドライブプロダクションプラットフォームの開発で見えたAWSでプラットフォームを開発するということ

Transcript

1. クラウドライブプロダクションプラットフォームの開発で見えた AWSでプラットフォームを開発するということ 2026/8/17 Media-JAWS 朝日放送テレビ 荒木 優 © Asahi Television Broadcasting Corporation All rights reserved. 1
2. 自己紹介 所属 朝日放送テレビ株式会社 技術局 放送技術センター 放送情報グループ 兼 技術開発部 2014年入社 13年目 島根県出身 荒木 優 YU ARAKI これまでの経歴 制作技術（音声・スタジオ/中継ミキサー・TD） 送信（テレビ/ラジオ送信インフラ・NW整備） 技術戦略・技術開発（新技術開発・社内ハンズオン講師） 放送情報（営放・視聴率関連システム） 好きなAWSサービス これまで開発に携わったプロダクト クラウドライブプロダクションプラットフォーム ネットワーク型タリー伝送システム TS3信号光伝送装置 AWS IoT Core AWS Amplify 好きなもの リアルタイムに動いているものをリアルタイムに コントロールするシステム © Asahi Television Broadcasting Corporation All rights reserved.
3. クラウドライブプロダクションプラットフォーム 直感的なタブレット操作で”プロっぽい”ライブ配信が誰でも簡単に! 最大4カメ切り替え ワンタッチリプレイ再生 スコア・カウント入力 テロップ挿入 リモコンカメラ制御 動画ファイル再生 全てタブレット一つで実現できます！ ABCテレビxNTTSportict協業サービス ABCテレビ技術局メンバーで内製 INTER BEE AWARD 2024 グランプリ受賞 コンテンツ制作 / 放送・メディア（トータルソリューション）部門 2025 日本民間放送連盟賞技術部門 優秀 受賞 © Asahi Television Broadcasting Corporation All rights reserved. 3
4. クラウドライブプロダクションプラットフォーム 本プラットフォームの概念図 現場 AWS Cloud エンコード+SRT送信 各機能ごとのコンテナ SRT受信 スイッチング テロッパー 動画ファイル再生 エンコード 配信 プラットフォーム RTSP→SRT プロトコル変換 PTZ制御 WebRTC 変換 コンテナなので オンプレでも展開可能 各種機能を 制御 タリー ステータス情報 必要な時に必要なだけ 各機能のコンテナを AWS上に自動展開 映像・音声 制御・監視 ユーザーの Webブラウザ 2025年度 このプラットフォームで 100試合程度 ライブ配信を実施 野球・サッカー・ラグビー・ハンドボール © Asahi Television Broadcasting Corporation All rights reserved. 4
5. このプラットフォームは最初から思った形には作れなかった・・・ 今日のお話は3回目のマイグレーションの結果のお話し 全部 手動 半自動 1周目 2周目 3周目 2023.11〜 プロトタイプ 〜2025 本番投入 2026 今の基盤 個別機能は動くがバックエンド ある程度の起動ウィザードは テナントも会場も、ユーザー自 のリソースは、AWSコンソール 作ってワンタッチで起動できる 身が自由に作れるようになった から全て手動で起動していた ようにしたが・・・ ⚠ 1会場動かすだけでも我々が「張 ⚠ まだシングルテナントで、動的 ここでやっと思った形になってきて り付く」必要があった に自由にテナントを作れない 「手離れ」が見えてきた 屋台 （毎日店を組み立てるとこから） 自分の店 （常設で厨房もあるが1店舗だけ） 自動 ＋ マルチテナント フランチャイズ (仕組みを渡して誰でも全国に開店) 「個別機能が動くこと」 と「サービスとして本番運用できること」 の間には深い谷がある 1周目の時点で一度作れた気になるが、その後のこの谷を埋める設計と実装がかなりカロリー高めで苦行 © Asahi Television Broadcasting Corporation All rights reserved. 5
6. ここからが大変 マルチテナントで自動展開できる基盤を開発 1つの基盤で複数顧客（テナント）のサービスを分離して動かす 目に見える機能は増えないのに、作らないといけないものが一気に増えてしまう（苦行） 物理分離 論理分離 ★今回採用 同時に必要なもの テナント別AWSアカウント・別VPC 1基盤の中で命名規則/ポリシーで分離 ・プロビジョニング機構 安全だがコスト増（AirTallyはこの方 全てのリソースを命名規則通りに展開 式） する 分ける対象：認証/リソース/データ/通信/ネットワーク ユーザー操作でリソースを作る/消す ・同時実行の制御 2人が同時に押しても壊れない ・状態の同期 "Resource": [ "arn:aws:iot:*:*:topic/${tenantId}/${projectId}/*" ] あるべき状態と実際の付き合わせ ・観測 命名規則を「文字列の約束」で終わらせないで、IAM の Resource ARN に 埋め込む ポリシー雛形は1つ・代入値はテナント毎にすることで、AWS の認可レイヤーが自動でテナ ントを越境できないように拒否してくれる ないと動いているつもりになる ・止める仕組み・消す仕組み 止め忘れがそのままAWS料金に テナント分離は自社開発のアプリのロジックではなく AWSの認可レイヤーで保証する ここはAWSの完成された仕組みに頼るべきところ © Asahi Television Broadcasting Corporation All rights reserved. 6
7. 地味な仕組みですがこれを作らないと運用できない ボタン1つで各現場のAWS環境を動的に一発で起動できるように CDKはデプロイ時にしか動かないが、ユーザーがボタンを押すのは運用中の任意のタイミング 実行時にリソースを作る仕組みを自分で書くことに・・・ ③ 数分後に使える状態になる ① ユーザーが起動を押す ② 裏で自動で走る デプロイ時に作ってある CDK / Amplify Gen2で作成 AppSync mutation その現場専用の環境が一式できる カメラのSRTを受ける口ができる Step Functions Provision / Start / Stop / Deprovision 現場ごとに必要な機能が起動する タブレットから操作できる Provisioner Lambda IoT ／ ECS ／ Network ／ Usage 他のテナントからは見えない 終わったらボタン1つで撤収でき 実行時に作られる 自分で作ったLambdaで起動 IoT Thing + Shadow + Policy ECS Task定義 + Service Security Group + Subnet GPU EC2 て課金も止まる ⚠ 1周目はこれをAWSコンソールで 手作業していた（苦行） この「リソースを作る仕組み」自体もCDKで定義する インフラを作るインフラをコードで管理する。ここを手動で作るとプラットフォームの一番大事な部分が管理対象外になってしまう。 © Asahi Television Broadcasting Corporation All rights reserved. 7
8. ここまでを整理 AWSでプラットフォームを開発するということ AWS上で作っても自分で開発するしかないこと AWSに任せられたこと IAMの認可レイヤー。自前で権 実行時の CDKはプラットフォームの 限チェックを書かなくていい プロビジョニング デプロイ時にしか動かない リソースの AWSコンソールでできることは 消す順序と整合性 依存関係は 生成・削除 全部APIでできる 同時多発への追従 会場が増えたら あるべき状態との AWS側は「今の状態」しか その分だけ裏側を増やすだけ 突き合わせ 教えてくれない CloudWatchに集まる 止め忘れの検知 放置がそのまま テナント分離 ログの集約 自分で解く必要がある あとはこれをAIに読ませる 課金になってしまう AWSは「部品」と「保証」はくれるが それを組み合わせてプラットフォームにするのは、結局まだ我々の仕事（ここが苦行） © Asahi Television Broadcasting Corporation All rights reserved. 8
9. 苦行を経て開発すると何が見えるか ① 思いついたらすぐ試せる ②「分からない」が減る ③ 相談が来る前に備えが完了 機材を集めて現場に行かなくても、 全コンテナでログの形式を揃えたの 相談が来たときにある程度土台がで クラウド上で組んで試せる。 で、Claude Code ＋ AWS MCP に きているので「できます」と答える CloudWatch を直接読ませられる。 プレッシャーが減る。都度構築だと 障害報告のチャットの文面をそのま 採算に乗らない小さい案件も受けら 以前は試すこと自体に機材と人と場所 ま貼るだけで原因まで辿れる れる が必要で試すのも大変だった 精神的に楽！ ⑤ 次に流用が効いて横展開できる ⑥ 要望への向き合い方が変わる 本番運用で我々の介入は不要にな 様々な仕組みを作る際にこのプラッ 「うちだけこうしたい」という個別 り、ユーザーのセルフサービスで トフォームの仕組みを流用でき、更 最適な要望は必ず来るが、設定値と やってもらえる。属人化から離れら なる発展が期待できる。 テナント属性である程度は吸収でき ④ 運用ごと人に渡せる れる。 るようになる 本体に変な条件分岐やforkを足さなく 運用も楽になる！ て済む © Asahi Television Broadcasting Corporation All rights reserved. 9
10. プラットフォームとは、何かやりたくなったときに 準備がもう終わっている基盤のことだと思う 映像・音声を処理するパーツ（ECSコンテナ） ※ 必要なものだけを選んで載せる（もちろんここも自社開発） SRT受信 スイッチング テロッパー ディレイ インスタント リプレイ ビデオ・オーディオ プレイヤー レコーダー エンコード 配信 WebRTC スコアCG スコアロジック 競技ごと 競技ごと 必要なものを 足せる ＋ スポーツの競技ごとのスコアCG・スコアロジックも、テロッパーやディレイと同じ「パーツ」として扱う ＝ 競技が増えても基盤は変わらない ▲ 必要なパーツを選んで自動展開 プラットフォーム ＝ ⇅ 本番中は、各パーツをリアルタイムに制御し、状態を受け取り続ける 今回作ったパーツを自動展開してマルチテナントで運用する仕組み WebUI 自動展開 リアルタイム制御・監視 マルチテナント 監視・ログ・課金 起動・撤収も本番中の操作 会場ごとに必要なパーツだ 各パーツへの操作指示と、タリー 認証・権限／IAMによるテ 稼働監視／横断ログ／使用 も、すべてここから け起動・撤収 などの状態を遅れずに返す ナント分離 量とコスト ▲ この上に組み上げる AWS ＝ 「部品」と「保証」をくれる EC2（GPU）／ECS／IoT Core／Step Functions／Lambda／AppSync／IAM／CloudWatch 足りない機能が出てきても、パーツを足すだけで済む この上でやるほうが便利で、運用負荷も小さく、きちんと動く外側の仕組みがすでにあるので精神的にも楽 © Asahi Television Broadcasting Corporation All rights reserved.
11. 君も プラットフォーマーに なろう ご清聴ありがとうございました © Asahi Television Broadcasting Corporation All rights reserved. 11