Amazon WorkSpacesでAWS re:Invent 2020 Keynoteの副音声配信をしてみた話 #reinvent

はじめに

清水です。はじめてのオンライン開催となった今年2020年のAWS re:Invent、全5回行われたKeynoteの裏で「非公式副音声配信」と題しまして弊社メンバーの即興解説（雑談?）をお伝えしていました。 ^*1 その配信のサポートをさせていただく中で、Amazon WorkSpaces上にZoomミーティング + OBS Studioな環境をセットアップ、実際にこれを使ってYouTube Liveへの配信を行いました。本エントリではWorkSpacesなどの環境セットアップの手順や実際に配信を行ってみてわかったいろいろなことを備忘録がてらまとめておきたいと思います。わりとボリューミーなエントリになってしまったので、左側の目次をうまく活用してご参照ください。

事の発端からWorkSpaces利用構想まで

事の発端はre:Invent 2020ひとつ目のKeynoteとなるAndy Jassy Keynoteのおよそ1週間前、弊社菊池の発案によりはじまりました。参加者が各自自宅からZoom ミーティングを通して参加、OBS Studioを経由してYouTube Liveに配信する、というところまでは決まっている中で、配信担当の堀からトラブルなどあった場合のバックアップ役としてお声がけいただきました。

この段階で大まかな構成（Zoomミーティング + OBS StudioのからYouTube Liveで配信する）は決まっていましたが、実際に配信エンコーダ側をどうするかは決まっていない状況でした。弊社社内でもATEM Miniなどを使ってZoomミーティングの画面をキャプチャ、そのキャプチャ映像をOBS Studioでエンコードして配信する、という方法は知られていましたので、これが候補の一つとなります。

• 【2020年】勉強会をライブ配信する安定構成を紹介します。 | Developers.IO

ただATEM Miniは私の手元になく、物理的にリソースが準備できるかわからない点がありました。そして何より、個人的には以前からAmazon WorkSpacesを使ってライブ配信を行う、という事例を聞いたことがあり、この構成を使ってみたい気が満々でした。

• クラウドを使った堅牢なインターネットライブ配信を実現する - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
• Amazon WorkSpacesで堅牢な配信を実現する｜NUMAGUCHI, Shigeru｜note

とはいえ配信まであまり時間もない中でしたので、配信の主担当の堀にはATEM Miniを使った方法で検証、確認を進めてもらいつつ、私のほうでAmazon WorkSpaces上に配信エンコーダ環境を構築する方法で進めていきました。

WorkSpacesの構築

まずはAmazon WorkSpacesの環境を準備します。ポイントとしてはこちらのAWS builders.flashの記事にもある通り、WorkSpacesのスペックとしてPowerProもしくはGraphicsタイプを選択することです。特に検証段階ではスモールスタートではないですが、いきなりそこまで大きなスペックからスタートせず、スペックが不足しているならば大きなスペックタイプに変更、という手順を踏むことが個人的には多いです。今回は「ライブ配信のみであればPowerProバンドルタイプでCPU70%前後での運用が可能」ということで、当初からPowerProを選択し、このまま検証をへて配信本番を迎えました。（後述しますが、このPowerProでスペック的には問題ありませんでした。）ZoomでミーティングをしながらOBS Studioで配信するということでそれなりのスペックは必要だと思っていましたが、この情報のおかげでスペック選定についてはだいぶショートカットすることができました。

続いてWorkSpacesを構築するネットワークなどインフラ面の環境についてです。Amazon WorkSpacesではオンプレミス環境との接続も考慮してPrivate Subnetへ配置、インターネットアクセスはNAT Gateway経由とすることなども可能です。ですが今回はWorkSpaces自体にPublic IP Address（Elastic IP）を付与することとしました。つまりPublic Subnetに展開します。なおVPCについても新規に作成することとしました。ADについても既存ADドメインと連携はせず、こちらも新規にSimple ADを作成することとします。

マネジメントコンソールの「高速セットアップ」で起動するという手段もありましたが、せっかくなので(?)VPCなどは自分で準備して「詳細設定」から起動してみました。以下の構成となります。またリージョンについては東京リージョンを使用しています。

個人的にWorkSpaces環境を構築するのがものすごくひさしぶり（以前はクラスメソッド入社前、個人的にOffice環境が使いたくて立ち上げたものでした）だったこともあり、VPC作成からSimple AD、そしてWorkSpaces本体の起動まで、備忘録がてらもろもろまとめておきたいと思います。

構築にあたっては以下を参考にしています。

• Simple AD を使用して WorkSpace を起動する - Amazon WorkSpaces

VPC

まずはVPC、サブネットなどの作成です。[VPCを作成]ボタンから進みます。

名前タグ、ならびにIPv4 CIDRブロックを入力します。IPv6 CIDRブロックは今回は「なし」としました。作成後にDNSホスト名を有効にしておきます。

続いてサブネットの作成です。 [サブネットの作成]ボタンから進み、先ほど作成したVPCを選択、サブネットの情報（サブネット名、アベイラビリティゾーン、IPv4 CIDRブロック）を入力していきます。今回3AZ分、3つのサブネットを作成しました。（後述するとおり、実際に使用したAZは2つだけですが。） ^*2

続いてインターネットゲートウェイを作成、VPCにアタッチしておきます。

ルートテーブルを作成し、パブリックサブネット（インターネットとの通信可）となるようルートを編集します。

ルートテーブルの「サブネットの関連付け」から先ほど作成した3つのサブネットとルートテーブルを関連付けしておきます。

以上でVPCの作成は完了です。

Simple AD

続いてSimple ADリソースを作成します。Directory Serviceのマネジメントコンソールからもリソースの作成は可能ですが、今回はWorkSpacesのマネジメントコンソール画面からリソース作成を進めていきます。（ざっとしか確認できていませんが「企業名」など、一部項目が追加で設定できるようです。）

開始方法では「詳細設定」を選択して、[起動]ボタンで進みます。

ディレクトリタイプの選択では「Simple AD」を選択します。

ディレクトリ情報の入力、ディレクトリサイズは「スモール」を選択します。その他、組織名、ディレクトリのDNS名、管理者パスワード、ディレクトリの説明を入力していきます。ディレクトリのNetBIOS名は今回空欄としました。

VPCとサブネットの選択では、先ほど作成したVPCならびにサブネットを指定します。初期ADサイト名はデフォルトである「Default-First-Site-Name」のままとします。

確認と作成で内容を確認、[ディレクトリの作成]ボタンでリソースを作成します。

作成直後は以下のようにステータスが「Requested」の状態です。

しばらくすると以下のようにステータスが「Active」に変わります。

以上でSimple ADの作成は完了です。続いてWorkSpacesの作成に進みます。

WorkSpaces

WorkSpacesはマネジメントコンソールの左側メニューから「WorkSpaces」を選択、[WorkSpacesの起動]ボタンから進めます。

ディレクトリの選択にて、先ほど作成したSimple ADならびにサブネットを選択します。セルフサービスアクセス許可（WorkSpaceユーザ地震で再構築やリソーススペックなどの変更を許可するか）は有効にしました。またAmazon WorkDocsについては今回は無効としています。（WorkDocsについては、正直なところ詳細を確認している時間がなかったため、とりあえず使わないという選択をしました。ただファイルの保存や共有などは発生してしまうので、運用フローにWorkDocsをうまく組み込めると良さそう、というところでしょうか。）

[次のステップ]ボタンを押下すると、以下のように「ディレクトリ登録中」の画面が表示され、少し待ったのち次の画面に遷移します。

続いてユーザの特定です。現状、ディレクトリ内にユーザはいない状態ですので、ここで新規ユーザを作成してディレクトリに追加します。ユーザ名、名、姓、Eメールをそれぞれ入力して[ユーザの作成]ボタンを押下します。

ユーザが追加できたら、[次のステップ]ボタンで進みます。

バンドルの選択画面では、ハードウェアで「PowrPro」、言語で「Japanese(日本語)」に絞り込んだあと、OSとしてWindows 10を選択しました。ルートボリュームとユーザボリュームは、デフォルトで設定されている175GB/100GBのまま進めます。（後述しますが、2台目のWorkSpacesではここでXXXGB/XXXGBとしました。）

右下に隠れて(?)いる[次のステップ]ボタンでWorkSpacesの設定に進みます。実行モードはAlwaysOn（常時起動）ではなく時間課金のAutoStopにしました。自動停止時間は取り急ぎ1時間に設定していますが、のちほど24時間に変更しました。（ライブ配信本番中に停止してしまうことを避けるため。）暗号化については今回は無効としています。

このページでも右下に隠れてしまっている[次のステップ]ボタンを探し出し、最後の確認画面に進みます。内容を確認して[WorkSpacesを起動]ボタンでWorkSpacesを起動します。

起動直後は以下のようにステータスがPENDINGです。これがAVAILABLEになるまで少し待ちます。

以下がAVAILABLEとなった状態です。これでWorkSpaces自体の構築が完了しました。

WorkSpaces上での配信環境のセットアップ

続いてWorkSpacesへ接続し、配信環境をセットアップしていきます。

WorkSpacesへの接続

まずはWorkSpacesへの接続です。WorkSpaces起動後、入力したEメールアドレス宛に以下のようなメールが届きます。この手順にしたがってWorkSpacesに接続します。まず1.に記載のURLをクリックします。

認証情報の更新画面に遷移します。新しいパスワードを入力して、[ユーザの更新]ボタンで進みます。

WorkSpacesのクライアントダウンロード画面に遷移するので、環境にあった合わせてクライアントソフトウェアをダウンロード、インストールします。

インストール後、WorkSpacesクライアントを立ち上げます。macOS環境の場合、メニューの"Settigs" > "Change Language..."から使用言語の変更ができるので、日本語に変更しておきました。まずは登録コードを入力します。

続いてユーザ名、パスワードを入力してサインインします。

WorkSpacesに接続できました。Windowsのネットワーク設定では「いいえ」を選択しておきました。

アプリケーションインストール

WorkSpaceへ接続できたので、続いて必要なアプリケーションをインストールしていきます。

• Chromeブラウザのダウンロードとインストール
  • ダウンロードまではデフォルトでインストールされているFirefoxブラウザを利用
• ミーティング用Zoomクライアントのダウンロードとインストール
  • https://zoom.us/download
• OBS Studioのダウンロードとインストール
  • https://obsproject.com/ja/download
  • インストール直後、OBS起動時に現れる「自動構成ウィザード」はキャンセルして別途設定を実施
• エクスプローラで「ファイル名拡張子」の表示 ^*3
  • 
• その他、ファイルのやり取りのためにCloudBerry ExplorerとWinSCPもインストールしました（詳細は後述）

ZoomとOBS Studioのセットアップ

続いてOBS StudioでZoomミーティングのようすをキャプチャして配信するセットアップです。まずWorkSapcesクライアントについてはフルHD 1920x1080の解像度の外付けディスプレイにフルスクリーン表示するようにしました。（WorkSapcesクライアントやZoomアプリの画面サイズの違いによるキャプチャ部分の差異をなくすため）。Zoomミーティングについても最大化表示をしておきます。

OBSのソースでは「ウィンドウキャプチャ」を選択します。

キャプチャ方法で「[Zoom.exe]: Zoom ミーティング」を選択します。

これでZoomミーティングの映像キャプチャができます。以下のように、ウィンドウが重なっても（Zoomミーティングアプリの前面にOBSアプリを表示しても）ZoomミーティングのキャプチャではOBS部分は無視され、Zoomミーティングのみがキャプチャされます。

音声については、Windows OS上でなっているデスクトップ音声をそのままキャプチャします。デフォルトで音声ミキサー部分に「デスクトップ音声」が表示（追加）されているのでこれを使います。もし追加されていない場合や、削除してしまった場合などは"設定" > "音声"でデスクトップ音声を「既定」にします。

以上でOBSでZoomミーティングのようすをキャプチャする設定は完了です。必要に応じて演出的要素（テキストの追加やZoomキャプチャ部分のトリミングなど）を加えます。また音声については必要に応じて音量をOBS側で上げ下げしておきます。（実際、音声については音量が100%では少し小さく、160%ほどにしておくのが良い具合でした。）

OBS Studioの設定詳細

以下は備忘録がてら、OBS Studioの設定についてのスクリーンショットを載せておきます。基本的にはOBS Stuidoのデフォルト設定をそのままを使い、細かなチューニングなどは行っていません。（録画設定だけ、フォーマットをmp4としています。）それでも1つのマシンでZoomミーティングに参加＆キャプチャしながら、配信と録画（録画は配信と同品質ですが）をしてもCPU的にまだ余裕がある（カツカツではない）状態です。この環境がお手軽に準備できるのは便利だなぁと思います。 ^*4

やってみてわかったいろいろ

セットアップとしては上記の通りとなります。実際にこの構成でWorkSpaces環境でZoomミーティングをOBS Studioでキャプチャ、YouTube Live経由での配信を行ってみたところ、非常に安定して本番運用ができました。 ^*5 ネットワーク環境なども含めてですが安定性としてはMac+ATEM Miniの環境よりも良さそう、ということで配信2回目以降はWorkSpacesのみで配信を完結させることになったほどです。（WorkSpaces2台での正副環境）

ただ、WorkSpacesの環境には慣れが必要かと思います。例えばローカル（WorkSpacesクライアントを動作させているMac環境）で鳴っている音なのか、WorkSpacesで鳴っている音なのかの判断ができません。これはMac環境特有の問題かもしれません（Windowsではアプリケーションごとにボリューム調整ができたはず）し、サードパーティ製ソフトウェアで対応することもできるかもしれませんが、今回は物理的に、WorkSpacesクライアントを動作させるMac、Zoomミーティングに参加するMac、Keynoteのライブ配信を再生するiPhone、などと環境を分けて対処しました。またATEM Miniのように物理的にHDMIでの映像出力をキャプチャしているのではなく、1つのディスプレイ上にキャプチャ対象のZoomミーティングとOBS Studioが稼働していることも注意が必要です。（Zoomアプリのサイズ変更を指定しますとキャプチャサイズが変わってしまうなど）これはWorkSpacesのデュアルディスプレイ機能などを使うことで解決する可能性もあるかと思います。

以下では実際にWorkSapcesでの配信を行ってみてわかったことなどを（わりと取り止めもなく）まとめてみたいと思います。

CPU使用率など負荷まわり

WorkSpaces構築の際、バンドルタイプとしては PowerPro を選択したと記載しました。実際にPowerProのスペックでZoomミーティングへの参加ならびにOBSでの配信と録画（ただし録画は配信と同品質）を行った場合のCPU負荷としては60%弱、多少負荷がかかっている状態でも70%ほどでした。（Zoomミーティングの画面共有で動きが多くなる、とかだと多少変わるかもしれません。）なお、WorkSpaces環境からZoomミーティングへの参加はしており、コンピュータオーディを接続している状況ですが常にミュート、ビデオも開始していない状況です。実際のZoomミーティングへの参加（顔と声の参加）は別端末のMacから行っていました。またWorkSpaces接続プロトコルはPCoIPです。最近GAされたAmazon WorkSpaces Streaming Protocol(WSP)ではWorkSpacesからビデオ通信（クライアントのカメラを接続）も可能になるとのことですが、これを使用する場合はCPU負荷などもまた変わってくるかと思います。

そしてネットワークなども影響しますが、ドロップフレームも一切発生しませんでした。以下は実際の配信本番時のスクリーンショットです。

なにより、CPU負荷がそれなりにかかっている状況でも手元の環境（Mac）がファンの騒音でうるさくなったり、パームレスト部分があったかくならないのがありがたいです。MacBook Pro (13-inch, 2019, Four Thunderbolt 3 ports)、少し前のモデルよりCPUコア数は多くなっているのですが、その分(?)発熱も多いんですよね。ただしWorkSacesクライアントで常時、映像と音声をストリーミングしている状態なのでそれなりにMacにも負荷はかかります。

ネットワークの安定性

上記の通り、Zoom参加+OBSの負荷を1台のWorkSpaces環境でうまく賄うことができます。これもWorkSpacesを使う大きなメリットの一つだと思いますが、もう一つ、ネットワークの安定性についてもWorkSpaces（AWS）のメリットを享受することができます。オンプレミス（グラウンド）環境でZoomミーティングの映像をATEM Miniでキャプチャして、OBSで配信、となるとZoomミーティングへのデータ送受信、ならびにOBSでのデータ送信が発生します。さらには配信映像の試写だったり、今回であればKeynoteの視聴だったり、これを自宅のインターネット環境で行おうとするとそこそこの負荷になるかと思います。特に最近では時間帯によって自宅インターネットの速度が低下したり、隣近所のWi-Fi電波が混信している、なんてこともあります。ここで、Zoomミーティングからの映像と、その映像をYouTube Liveへ配信する部分を自宅インターネットを介さず、すべてインターネットの向こうのクラウド上で完結できるのは大きなメリットかと考えます。最悪、自宅インターネットが多少不安定になっても、WorkSpacesクライアントの通信が悪くなる程度で、配信自体に影響はありません。WorkSpacesクライアントから切断されてしまっても、WorkSpaces上での配信自体は続行できます。（再接続時の画面サイズ変更などのショックは考慮する必要があるかと思いますが。）

2台目WorkSpacesの起動について

そんな感じでWorkSpaces環境が非常に安定していたこともあり、途中からATEM Miniを用いていた環境もWorkSpacesで運用することとなりました。ここでは2台目の起動の際の注意事項などをまとめておきます。基本的には1台目のWorkSpacesと同じVPC、ディレクトリに起動します。Simple AD構築までの手順はなく、WorkSpacesの起動のみを同様の手順で構築します。

ユーザについて

ディレクトリ上の1ユーザ名に対して作成できるWorkSpacesは1つだけです。

• ユーザーに対して複数の WorkSpace を作成する - Amazon WorkSpaces

そのため、2台目のWorkSpaces起動時に1台目と同じユーザ名を選択して起動しようとすると、以下のようにエラーが発生してしまします。

別ユーザを作成して、そのユーザにWorkSpacesを割り当てるかたちで起動しましょう。

起動時のルートボリューム、ユーザボリュームの変更

今回バンドルとしては「PowerPro with Windows 10」を利用しました。マネジメントコンソールから起動する際はルートボリューム175GB、ユーザボリューム100GBとなっています。ただWorkSpacesの料金ページを確認するとルートボリューム80GB、ユーザボリューム10GBからの料金が記載されています。

• 料金 - Amazon WorkSpaces | AWS

試しに2台目のWorkSpacesについてはルートボリュームのサイズを80GBと指定してみたところ、この設定で起動することができました。マネジメントコンソールで指定されているデフォルト値からより小さい値への変更も可能なようです。（任意の値ではなく、一定の制限などはあったかと思いますが。）

ファイルのコピーについて

クライアント環境からWorkSpacesへ、またはその逆、そして2台のWorkSpaces間でのファイルのやりとりなどが発生します。WorkSpacesクライアントではドラックアンドドロップなどでのファイルコピーはサポートされていません。

• WorkSpaces Windowsクライアントアプリケーションのデータ連携まとめ | Developers.IO

OBSに設定する画像ファイルや設定ファイル、またOBSで録画したファイルのローカル環境への保存などが発生しました。Amazon WorkDocsを使う方法もあるかと思いますが、今回はそこまで準備ができていなかったので、シンプルにAmazon S3を介してのファイルのやり取りとしました。WorkSpaces上にはS3クライアントとしてCloudBerry ExplorerとWinSCPをインストール。また対象のS3バケットへの操作権限を付与したIAMユーザを作成、クレデンシャルをそれぞれのS3クライアントソフトウェアに設定しました。

なお、CloudBerryとWinSCP、両方インストールしたのは理由があります。前者CloudBerryはファイルアップロードが高速なのですが無料版では5GBを超えるファイルサイズのアップロードに対応していません。後者WinSCPは5GBを超えるファイルサイズのアップロードにも対応していたのですが、CloudBerryと比べるとアップロードに時間がかかりました。そのため基本的にはCloudBerryを使用、ファイルサイズの制限がある場合のみWinSCPを使用する、としました。

WorkSpaces上での文字（日本語）入力について

文字入力については、私の特に設定変更などはしていないデフォルトの環境で、キーボード（US）からの文字入力はなんの問題もなく行えました。（Shirt+2で「"」が入力されることはなく、きちんと「@」が入力されます！）ただし日本語入力への切り替えはうまくいかず（例えば「Alt+~」などでの切り替えはできませんでした）、調査する時間もなかったことから取り急ぎはクライアント環境で文字を作成しコピーアンドペーストでクリップボード経由の入力を行いました。

クリップボードについてはデフォルト状態で、私が使用した範囲では問題なく動作しました。グループポリシーなどで制御することも可能なようです。

• WorkSpaces Windowsクライアントアプリケーションのデータ連携まとめ | Developers.IO

正環境から副環境へのOBS設定のコピー

WorkSpacesを2環境（正副）としたことから、2台のWorkSpaces上でのOBS Studioの設定をコピーする必要も出てきました。OBSにはプロファイルやシーンコレクションのエクスポート/インポート機能もありますが、OBSの設定フォルダ自体をコピーすることで対応しました。"ファイル" > "設定フォルダーを表示"で「D:\Users\cm.mediastreaming\AppData\Roaming\obs-studio」がエクスプローラで開きます。この「obs-studio」フォルダが設定フォルダとなりますので、一つ上の階層でこのフォルダをまるっとコピーします。副環境への設定コピーの他、設定を元に戻したいときにもフォルダを復元することで対応できます。 ただし、副環境にコピーした際、OBSの配信設定は「Primary YouTube ingest server」のままです。「Backup YouTube ingest server」に変更するのを忘れないようにしましょう。 ^*6

また細かな点ですが、画像ファイルなどを扱う場合は正副の環境で同じパスとなるようにしました。（例えば「D:\Users[ユーザ名]\Images」などではなく、「D：Images」などに保存する。）設定フォルダのコピーについては、OBSのバージョンが同じであることやOS環境についても同じである点に注意します。（OS環境については、異なる場合テキストソースのフォントの不一致など発生してしまうことが考えられます。またウィンドウキャプチャや映像キャプチャデバイスなどの使用状況が異なる場合でも不整合が生じてしまうかと思います。）

WorkSpacesの自動停止時間について

WorkSpacesの1台目起動時には1時間と設定していましたが、その後、本番前には24時間に設定を変更していました。これは万が一、トラブルなどでクライアントからのネットワーク断などが起こっても、WorkSpaces（とそこで稼働するOBSなどソフトウェア）が稼働していれば配信自体は続きます。このことから、もしネットワーク断の状態などでもWorkSpaces自体は起動させておきたい（不用意に自動停止させたくない）ということから、配信時間なども加味しても少し長めの24時間としました。当然、なんの操作がなくても自動停止するまでには24時間かかることになるので、配信などで使用したら手動で停止する、というようにしました。

設定の変更は「実行モードプロパティの変更」で行います。

手動での停止については、対象のWorkSpacesを選択して「WorkSpacesの停止」で行います。

なお起動については、停止の手順同様にマネジメントコンソールから手動で行うこともできますし、WorkSpacesクライアントから接続時に停止状態であれば自動で起動処理が行われます。（通常の接続よりも少し時間がかかりますが。）

WorkSpacesのWindows Updateについて

ライブ配信（特に本番配信中）にWindows Updateが走ってOSが再起動してしまう、なんてことは避けたいと思い、WorkSpacesのWindows Updateについても簡単ですが確認しておきました。

上記ドキュメントを参照したところ、夜間にメンテナンスウィンドウが設定されるそうです。Keynoteの時間帯と被る可能性も考慮して、念のためメンテナンスモードは無効にしておきました。

• WorkSpace のメンテナンス - Amazon WorkSpaces

長期運用にあたってはWindows Updateを手動で行うタイミングなども確認しておきたいですね。

YouTube LiveのPrimaryとBackup、どちらが配信されるかわからない問題

今回、基本的にはYouTube LiveのBackup ServerへのIngestも行うよう、OBS配信を正副の2環境で行っていました。ただ、OBSからYouTube LiveのPrimary、Backup双方のServerへIngestしている際、どちらの映像が配信に使われるかの挙動がいまいち掴み切れていません。 ^*7

初回のKeynote副音声配信の際、配信副環境のみWorkSpaces（Backup ServerへのIngest）、配信正環境はATEM Mini（Primary ServerへのIngest）という環境下でWorkSpaces側の映像が配信される、ということがありました。これについては、ATEM Miniの環境でネットワークが少し不安定だった、ということからネットワークが安定しているWorksSpacesの映像に切り替わっていた、と推測できます。

ただ、正副2環境ともWorkSpacesという環境下でも、副の映像が配信されているケースだったり、気がついたら配信される映像が制服切り替わっていたり、ということがありました。WorkSpacesの2環境で顕著に異なる点として挙げられるのはアベイラビリティゾーンでしょうか。これがネットワークの安定性に影響したのかな、とも思いましたが、確かではありません。正環境のままずっと配信されるということもあったりで挙動が掴めないため、基本的には配信している映像をみて正副を判断。また音声のミュートや調整、フタ画像のオン/オフなどは正副環境双方で実施することとしました。

この中で、配信している映像をみて正副が判断できるよう、微妙に映像に違いを入れました。具体的には以下が実際の副環境の映像（フタ画像ですが）になりますが、左下にある白いドットがその判断材料となります。 ^*8

正副2台のWorkSpaces環境を1台のクライアントPCでまかなえるか

今回、YouTube LiveのPrimary、Backup双方に2台のWorkSpacesから配信を行う場合、二人の配信担当者が別々の場所（自宅等）からWorkSpacesに接続するというかたちを取りました。これは配信担当者の冗長性も踏まえてのことです。対して、配信担当者が一人だった場合、そしてWorkSpacesのクライアント端末が1台だった場合に正副2台のWorkSpaces環境をライブ配信中に監視などできるか、という点も考えておきたいと思います。

まず、WorkSpacesクライアントアプリ自体の2重起動はMac環境では可能です。（Windows環境では未確認です。）ただし2つ目のアプリの起動にはターミナルからコマンドを実行する必要があります。

• WorkSpacesアプリケーションを複数起動して別々の環境に同時接続してみる | Developers.IO

ただ、Mac環境ですと2つのWorkSpacesクライアント双方から音が鳴る状況となります。OBS StudioではWindowsのデスクトップ音声をキャプチャしている状態ですので、WorkSpaces（Windows OS上）でミュートするわけにもいきません。Zoomミーティングの会話が少しエコーがかかったようになります。（わずかながら音声遅延の差があるため。）例えばアプリケーションごとにミキサーなどで音声調整ができればこの解決は可能かもしれません。（Windows環境ならできそうな気もします。またMac環境でもサードパーティ製アプリなどでできるかもしれません。）

この音声調整の問題を解決する、もしくはWorkSpaces環境からの音声のモニタリングはしないことにする（実際の配信での音声確認のみとする）とすれば、正副2台のWorkSpaces環境を1台のクライアントPCでまかなう、ということも不可能ではないかと思います。もしくは配信担当が一人でも2台のクライアントPCを準備する、などでしょうか。（仮想環境への接続、なかなか混乱する要素が多くあるので、この構成のほうが妥当そうな気が個人的にはしています。）

まとめ

AWS re:Invent 2020 Keynoteの「非公式副音声配信」の配信エンコーダ環境として使用したAmazon WorkSpaces上のZoom + OBS Studioな環境について、WorkSpacesの構築、またWorkSpaces上での配信環境のセットアップ、またやってみてわかったことをいろいろとまとめてみました。繰り返しになりますが、WorkSpaces上での配信環境、とても安定していました。バンドルタイプでなかなか良いスペックのPowerProを選択したこともありますが、この環境がオンデマンドで必要なときに使えるのは大変便利だと思います。ネットワーク面での安心感もありますね。ただ仮想環境として（物理的にHDMI映像をキャプチャする場合、などと比べて）多少クセのようなものはあるかと思いますので、慣れるまでは少し注意しておきましょう。

あわせて読みたい

一昨年、昨年は現地ラスベガスから動画配信をしていました。（それと比べると、今年はネットワーク面を気にしなくて良かったのが大きいです。）

• AWS Media Servicesを使ってラスベガスから動画配信してみた #reinvent #mediaservices | Developers.IO
• AWS Media Servicesを使ったラスベガスからの動画配信2019 ~不安定な配信の裏側で何が起こっていたのか~ #reinvent | Developers.IO

脚注