この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
清水です。すばやく簡単にセットアップできるマネージド型のライブストリーミングソリューションAmazon Interactive Video Service (Amazon IVS)のコントロールプレーンの対応リージョンが増え、東京リージョンも加わり合計7リージョンになりました！
Amazon IVS、リリース当時から対応しているコントロールプレーンのリージョンはアイルランド（eu-west-1）、バージニア（us-east-1）、オレゴン（us-west-2）の3つのみでした。いつから追加されたか、たしかな資料などは確認できなかったのですが、例えば2022年2月はじめに公開された以下のエントリではリージョン追加は確認できていない状況でした。
おそらく2022年2月か3月中に追加されたかたちかと思いますが、現状では冒頭に示したとおり以下7リージョンでコントロールプレーンが利用可能となっています。
- ムンバイ（ap-south-1） [NEW!]
- アイルランド（eu-west-1）
- フランクフルト（eu-central-1） [NEW!]
- バージニア（us-east-1）
- ソウル（ap-northeast-2） [NEW!]
- 東京（ap-northeast-1） [NEW!]
- オレゴン（us-west-2）
冒頭の画像はAmazon IVSに対応していないリージョンでIVSのページに遷移しようとしたものなのですが（他のリージョンを案内されるアレですね）、以前はここが3リージョンのみだったわけです。
AWSリージョンテーブルでも、例えば東京リージョンで提供中のサービスAmazon IVSが含まれていることを確認しています。（スクリーンショットは選択リージョンとサービス名を一枚に収めることができなかったため割愛します。）
さて、この対応リージョンの拡充はあくまでIVSのコントロールプレーンの話です。データプレーンはこれまでも、これからもグローバルのままでこの点に変更はありません。本エントリではこのIVSでのリージョンの考え方、また東京?含めリージョンが拡充したことで何が変わるか、変わらないかをまとめてみます。
Amazon IVSのリージョンについて
まずはAmazon IVSのリージョンの考え方について振り返っておきましょう。ユーザガイドに詳細が記載されています。
冒頭に示したリージョン選択画面、コントロールプレーン対応リージョン一覧の下にある説明もわかりやすいかと思います。
「 データプレーン 」、つまり実際に映像をIngestする部分と視聴者がコンテンツ配信ネットワークを介してライブストリームを視聴する部分は グローバル になります。具体的には、配信（Ingest）ならびに視聴においてはそれぞれのデバイスに最も近いCDNのPoP（Point of Presence）が自動的に選択されるようになっています。そのため、「コントロールプレーン」対応リージョンがアイルランド（eu-west-1）、バージニア（us-east-1）、オレゴン（us-west-2）の3箇所だったときにも、日本での配信・視聴でわずか3秒未満というの超低遅延が実現できていた、というわけです。
「 コントロールプレーン 」についても確認しましょう。Amazon IVSでライブストリーミングを行う際には、チャンネルを作成しストリームキーを取得する必要があります。これらIVSのリソースを作成するにはマネジメントコンソールだったり、AWS CLIなどAPI経由だったりでアクセスするわけですが、このアクセス先はリージョンごとに異なります。マネジメントコンソールならIVSの画面に遷移する前に対応リージョンを選択しておく必要がありますし（非対応のリージョンの場合、冒頭に示したリージョン選択画面が表示されます）、AWS CLIなどAPIを利用する場合であれば対応リージョンを指定する必要があるわけです。
また例えばオレゴンリージョンで作成したチャンネル「my-channel」とアイルランドリージョンで作成した「my-channel」は同じチャンネル名ですがそれぞれ独立しています。このように、Amazon IVSコンソールやAPI、リソース（チャンネル、ストリームキー、再生キー、録画設定）など「コントロールプレーン」は リージョナル である、ということになります。
東京リージョンとオレゴンリージョンそれぞれのコントロールプレーンを使った比較
Amazon IVSにおけるデータプレーンとコントロールプレーンの違いを確認したところで、今回のリージョン拡充によりどのようなことが変わるのでしょうか。本エントリでは例として、東京リージョンとオレゴンリージョンのコントロールプレーンを使用した場合の違いを考えてみたいと思います。
超低遅延なライブストリーミングは変わらない
Amazon IVSの大きな特徴の1つである超低遅延なライブストリーミングについては変わりありません。これはグローバルな「データプレーン」が利用されているからですね。実際に今回東京リージョンで「Ultra-low latency」チャンネルを作成、オレゴンリージョンに同様に作成したチャンネルとも比較してみましたが、遅延はどちらも3秒未満、以下のエントリと同様の結果が得られました。
Amazon IVSの料金も変わらない
AWSの多くのサービスでは、使用するリージョンによって料金が変わります。例えばEC2であれば、基本的に東京リージョンよりもオレゴンリージョンのほうがインスタンスの時間あたりの使用料が低くなっています。ではAmazon IVSではどうでしょうか。IVSではライブ動画入力、ライブ動画出力の2つの要素で料金が決まります。このうちライブ動画入力についてはリージョンによる価格の差異はありません。
ライブ動画出力については、以下のように「リージョン」によりコストが変わります。しかしこの「リージョン」は「請求リージョン」と呼ばれ、通常のAWSのリージョンとは異なります。「請求リージョン」はライブストリーミングを視聴している視聴者の場所が基準となります。東京リージョンのチャンネルでも、オレゴンリージョンのチャンネルでも、日本からの視聴者であれば「請求リージョン」として日本が適用され料金が決定する、というわけです。つまり、Amazon IVSの料金もコントロールプレーン対応リージョンにより変わることはありません。
「ライブ動画出力にかかるコスト」 Amazon Interactive Video Service の料金
チャンネル録画の保存先S3バケットは変わる
Amazon IVS、リリース当時はストリーミングをアーカイブ・録画する機能がなくAWS Elemental MediaLiveと連携するなどして録画する必要がありましたが、2021年4月にAmazon S3へのライブストリームの保存をサポートしました。
この録画機能を使用する場合、保存先となるS3バケットについてはチャンネルと同じリージョンである必要があります。ユーザガイドにも以下のように記載がありますね。
チャネル、録画設定、および S3 の場所は、同じ AWS リージョン内にある必要があります。他のリージョンでチャンネルを作成して録画する場合は、それらのリージョンで録画設定と S3 バケットも設定する必要があります。
「Amazon S3 への自動録画」 ステップ 3: 任意の録画によるチャネルの作成 - Amazon Interactive Video Service
マネジメントコンソールでも、recording configuration作成時に以下のように記載されています。（東京リージョンの例）
これまではIVSで録画機能を使用する場合、保存先となるS3バケットはアイルランド、バージニア、オレゴンのいずれかである必要がありましたが、今回のリージョン拡充でこのS3バケットの選択肢も広がることになりました。（「コントロールプレーン」のリージョンと同じリージョンとなる点は変わりません。）
ということで、東京リージョンとオレゴンリージョンそれぞれのコントロールプレーンを使ったケースを比較すると、チャンネル録画先のS3バケットは変わる、ということになります。
Timed Metadata挿入時のエンドポイントは変わる
Amazon IVSの大きな特徴の1つにストリーム内にメタデータを埋め込むTimed Metadataがあります。このTimed Metadata、挿入時にはコントロールプレーンのリージョンならびにチャンネル名を指定してAPI（AWS CLIならaws ivs put-metadata）を叩きます。AWS CLIでTimed Metadataを埋め込み、マネジメントコンソールで確認した例としては以下などを参照ください。
コントロールプレーンのリージョンに対してAPIを叩くわけですから、Timed Metadata挿入時のエンドポイント自体は変わる、ということになります。なおTimed Metadataを挿入すると実際にはストリーム内にデータが埋め込まれるわけになります。ストリームのデータ自体はグローバルなわけですが、埋め込む操作はリージョナルなコントロールプレーンから、ということでほんのわずかかと思いますが利用するリージョンによってTimed Metadata挿入時の遅延（APIを叩いてから反映されるまで）が変わるかもしれませんね。
マニフェストファイルから伺えるエッジのドメインとロケーションについて
東京リージョンとオレゴンリージョン、それぞれのコントロールプレーンを使った場合の比較からリージョンによって変わること、変わらないことを確認してみました。その中でIVSの特徴の1つの超低遅延なライブストリーミングについては「グローバルなデータプレーンを利用しているため変わらない」、とましましたが、実際にストリーミングに使用しているCDNのPoPのドメイン名から、この点を深追いしてみます。
なお本節で扱うエッジのドメイン名とロケーションの関係についてはドキュメント等に記載がなく、独自研究となります。あくまで推測である点をご了承ください。
以前Amazon IVSのマニフェストファイルを読み解いてみた際、トップレベルマニフェストファイルではなくそれに続く各ビットレートごとのマニフェストファイル取得先のドメイン、またセグメントファイル（tsファイル）取得先のドメインについては空港コードに対応した文字列が含まれている、という推測をしました。詳細は以下エントリの「各ファイルごとのリクエスト先DNS名について」を参照ください。
今回もこの仮定のもと、東京リージョンに作成したチャンネル、オレゴンリージョンに作成したチャンネルそれぞについて、(1) 私（東京在住）の自宅のインターネット回線、(2) 東京リージョンのCloudShell、(3) オレゴンリージョンのAWS CloudShellそれぞれからマニフェストファイルにアクセスし、ビットレートごとのマニフェストファイル取得先のドメイン名、セグメントファイル取得先のドメイン名について確認してみます。
東京リージョンに作成したチャンネルの場合
まずは東京リージョンに作成したチャンネルについて、Playback URLつまりトップレベルマニフェストファイルについてはXXXX.ap-northeast-1.playback.live-video.netというドメインから取得することになりますが、これ以降のビットレートごとのマニフェストファイル、セグメントファイル取得元のドメインについて確認していきます。なお、実際のマニフェストファイルの中身はぎょっとするほどのランダムな文字列が含まれているため、ドメイン名のみを抜粋しています。
(1) 自宅（東京）のインターネット回線
- ビットレートごとのマニフェストファイル取得先ドメイン
video-weaver.tyo03.hls.live-video.net
- セグメントファイル取得先ドメイン
video-edge-785e36.tyo03.hls.live-video.net
どちらもTYO、東京を示す空港コードをドメインの一部に持つサーバから取得していました。
(2) 東京リージョンのCloudShell
- ビットレートごとのマニフェストファイル取得先ドメイン
video-weaver.sin01.hls.live-video.net
- セグメントファイル取得先ドメイン
video-edge-04665c.sin01.hls.live-video.net
以前、東京リージョンの起動したEC2からアクセスしたした際には空港コードでシンガポールに該当するSINをドメインの一部に持つサーバから取得していました。今回はEC2ではなくCloudShellですが、同様にSIN、シンガポールを示す空港コードをドメインの一部に持つサーバから取得する結果となりました。直感的に最寄りではない印象をうけますが、データセンター群としてAWS東京リージョンとシンガポールは割と近い、と考えています。
(3) オレゴンリージョンのCloudShell
- ビットレートごとのマニフェストファイル取得先ドメイン
video-weaver.sea01.hls.live-video.net
- セグメントファイル取得先ドメイン
video-edge-7ea514.sea01.hls.live-video.net
オレゴンリージョンのCloudShellでアクセスした場合、アメリカは西海岸シアトルにあるシアトル・タコマ空港を示すSEAをドメインの一部に持つサーバからの取得となりました。最寄りの場所へのアクセスという印象がありますね。
オレゴンリージョンに作成したチャンネルの場合
続いてオレゴンリージョンに作成したチャンネルについて、こちらもPlayback URLはXXXX.us-west-2.playback.live-video.netとなりますが、これ以降のマニフェストファイル、セグメントファイルの取得先ドメインを確認します。
(1) 自宅（東京）のインターネット回線
- ビットレートごとのマニフェストファイル取得先ドメイン
video-weaver.tyo03.hls.live-video.net
- セグメントファイル取得先ドメイン
video-edge-ab9c54.tyo03.hls.live-video.net
東京リージョンに作成したチャンネルの場合と同様、TYOの文字列を含むサーバからの取得となりました。
(2) 東京リージョンのCloudShell
- ビットレートごとのマニフェストファイル取得先ドメイン
video-weaver.sin01.hls.live-video.net
- セグメントファイル取得先ドメイン
video-edge-078baa.sin01.hls.live-video.net
こちらも東京リージョンに作成したチャンネルの場合と同様ですね、SINの文字列を含んでいます。
(3) オレゴンリージョンのCloudShell
- ビットレートごとのマニフェストファイル取得先ドメイン
video-weaver.sea01.hls.live-video.net
- セグメントファイル取得先ドメイン
video-edge-7e981c.sea01.hls.live-video.net
こちらも東京リージョンに作成したチャンネルの場合と同様です。アメリカ西海岸シアトルを示すSEAの文字列を含むサーバからの取得でした。
チャンネルのリージョンは違ってもファイル取得先ロケーションは（おそらく）変わらない
東京リージョンとオレゴンリージョン、それぞれのチャンネルを使用した場合でも、ビットレートごとのマニフェストファイルならびにセグメントファイル取得先ドメインについては、(1) 東京の自宅インターネット回線であればTYOを含むサーバ、(2) 東京リージョンのCloudShellであればSINを含むサーバ、(3) オレゴンリージョンのCloudShellであればSEAを含むサーバ、とそれぞれ同じロケーションにある（と思われる）サーバからの取得となりました。あくまでこれら文字列が空港コードとして実際のロケーションを示す、と仮定した場合の推測になりますが、データプレーンはグローバルであることが伺えるかなと思います。
まとめ
Amazon IVSのコントロールプレーン対応リージョンの拡充アップデートについてお伝えしました。コントロールプレーンのリージョンが変わっても、IVSの大きな特徴の1つである超低遅延なライブストリーミングは変わりありません。1つ大きく変わるとすればライブストリーミング録画時の保存先S3バケットのリージョンかと思います。録画は東京リージョンのS3バケットに保存しておきたい、という要件にも東京リージョンのデータプレーンを使用することで対応可能になりましたね！
個人的にはAmazon IVSのコントロールプレーン対応リージョンについて、従来の3リージョンの状態で超低遅延配信ができていたこと（これはデータプレーンがグローバルだからですね）、また3つのリージョンが利用可能であれば冗長性も取れることなどから、必ずしも拡充することはないのかな、などと思っていました。「あにはからんや、東京リージョンに対応するとは」などと思ったのですが、大きなポイントはやはり、録画時の保存先S3バケットのリージョン指定かなと思いました。この録画保存先S3バケットとチャンネルが同一リージョンである、という制約を知っていると、このコントロールプレーン対応リージョンの拡充がより嬉しく感じますね！また録画保存をしない場合でも、より近い場所でコントロールできることは喜ばしいことかと思いました。
9
