AKEOME。ジャンボです。 今日はKinesisの話をして優勝していこうと思います。細かいWebRTCに関する説明は飛ばします。
Kinesis Video Streams とは
Amazon Kinesis Video Streams を使用すると、分析、機械学習 (ML)、再生、およびその他の処理のために、接続されたデバイスから AWS へ動画を簡単かつ安全にストリーミングできるようになります。
要するにストリーミングコンテンツを解析する仕組みです。IoT の文脈で監視カメラの映像で不審者の検出や工場の不整製品検知などがユースケースとして想定されます。これまでは映像を受け入れて解析することがサービスの主体でしたが、AWS re:Invent 2019 にてWebRTCのサポートが発表になりました。
今回のリリースでできるようになったこと
Kinesis Video Streams がサポートするオープンソースプロジェクトの WebRTC は、リアルタイムのメディアストリーミング、ウェブブラウザ間のインタラクション、モバイルアプリケーション、シンプルな API によるコネクテッドデバイスを可能にします。 用途としては、ビデオチャットやピアツーピアのメディアストリーミングが一般的です。
この記述のところですね。少し既存のユースケースとは実は違くて、Kinesisが拡張したというより、「WebRTCを使うための基礎的な仕組みを一部AWSが提供し始めた」というのが正しいかと思いました。
具体的に提供されるもの
これらはすでに他社製の既存のWebRTCプラットフォームでも提供されており、ここにAmazonが乗り出した感じですね〜気になる流れ 👀
コスト
従量課金製で使用量にコストがかかる形です。WebRTCはシチュエーションによったり、ユースケースで通信料が大きく変わるので見積もりが結構難しかったりするんですが、比較的安価に見えます。具体例を見ている限り基本的には
- 時間
- クライアント数
が大きな変数となります。
試してみる
*ちなみにAWSの無料範囲外なので気をつけて下さい。
labからサンプルが公開されており、設定さえすればすぐに使えるようになっています。
言葉にすると簡単なんですが、
- 以下のようにチャンネルを作成
- 必要なtoken/userを作成して値をSDKに渡す
- アプリケーションをつくる
これだけ。WebRTCの闇は運用してからなのでこの辺が簡単なのはもはや当たり前な時代・・・
webコンソールにこんな機能があり、作成したチャネルのパフォーマンスをモニターできるのはいいなと思いました。
サンプルコードとSDKの実装、APIのドキュメントから何ができるかを見ていきましょう。
サンプルコード・SDK
READMEにほぼ概要はありますが、気になる箇所をピックアップしてみてみましょう。
// SDKからオブジェクトのイニシャライズ const kinesisVideoClient = new AWS.KinesisVideo({ region: formValues.region, accessKeyId: formValues.accessKeyId, secretAccessKey: formValues.secretAccessKey, sessionToken: formValues.sessionToken, endpoint: formValues.endpoint, }); // 自分で作ったチャネルを指定してここから配信する const getSignalingChannelEndpointResponse = await kinesisVideoClient .getSignalingChannelEndpoint({ ChannelARN: channelARN, SingleMasterChannelEndpointConfiguration: { Protocols: ['WSS', 'HTTPS'], Role: KVSWebRTC.Role.VIEWER, }, }) .promise(); const endpointsByProtocol = getSignalingChannelEndpointResponse.ResourceEndpointList.reduce((endpoints, endpoint) => { endpoints[endpoint.Protocol] = endpoint.ResourceEndpoint; return endpoints; }, {});
// にあるようにWebRTCの基本通信概念であるICEを自身でハンドリングする必要がある signalingClient.on('open', async () => { ... signalingClient.on('sdpAnswer', async answer => { ...
ここから読み取れるのは
- 配信はチャネルごとで基本的な話者(PeerIDなど)を指定するような概念はない
- role {Role} "MASTER" or "VIEWER" があり、双方向配信はこれが前提
- ICEを自分で裁く必要がある
- IE以外はサポートしている
- 実装はちゃんとWebRTCの知識がいる(よりコアに触れそう:小並感)
API Doc
絶対読みましょう。結構大事な制約とかが書いてあります。
- Currently, a signaling channel can only have one master
- A signaling channel can have up to 10 connected viewers
WebRTC Technology ConceptsとかはWebRTCに必要なことをシンプルな文章で登場人物とかをまとめてくれているので勉強になります。一方でこの記述を明記することは「フルマネージドなのはサーバの運用だけでICEをはじめとしたクライアント側の技術はラップしない、ちゃんと理解しろよ」っいうAmazonの優しさと切なさと心強さなので座して読みましょう。
サンプルコードではwebのコンソールからチャネルを作成していますが、リファレンスをみる限りhttpのエンドポイントも提供されており自身で増減させることが可能のようです。
テレビ会議システムで言えば作成されるルームごとにこのハンドリングをするようなイメージなので、webのコンソールだけだとかなりユースケース限られるなと思っていたのでさっと目を通すと良いです。
まとめ
全体的にWebRTCのコア機能に対して基本的なサーバサイドのマネージドサービスとそれを利用するための抽象度低いSDKとインターフェースを提供しています。 現状はまだ多機能とはいきませんが、AWS CloudTrailとの連携などクライアントのイベント管理と解析をできたり、単純にcloudwatchと連携できるのですでにインフラ基盤がAWSなら連携できるメリットがありますね。
ただユースケースとしてライブ配信や解析をベースとしたインターフェースになっているのとSDKの抽象度的に結構余力がないと導入できないと感じました。
ユースケース次第ではハマりますね。
それではハッピーフライデー。🍺