Cerevoのライブ配信機器遠隔操作サービス「LiveShell Remote」とさくらのクラウド
目次
はじめに
さくらのナレッジ編集部の法林です。
8月1日に、株式会社Cerevoから、ライブ配信機器の遠隔操作サービス「LiveShell Remote (ライブシェル リモート)」がリリースされました。
このLiveShell Remoteを構築するにあたり、インフラとしてさくらのクラウドを利用したという話を聞きました。そこで、サービスの概要、システム構成、さくらのクラウドをどのように使っているか、などの話をうかがってきましたのでご紹介します。お話をうかがったのは、Cerevoの椚座(くぬぎざ)淳介さんと小林隆仁さんです。
LiveShell Remoteの概要
これがCerevoのライブ配信機器「LiveShell W」です。HDMIで入ってきた映像を取り込み、それをエンコードしてYouTubeなどに打ち上げるという、ライブ配信用のエンコーダ装置です。ちなみにLiveShellシリーズの開発を始めてから13年ほどになりますが、LiveShell Wは5代目ぐらいになる製品です。
このLiveShell WにはWebアプリケーションが内蔵されていて、製品の中で完結するようなWeb UIが動いているのですが、これを遠隔で使いたいという要望があります。つまり、LiveShell Wが物理的に離れた場所にある状態で、インターネットを経由してこのWeb UIにアクセスしたいという要望です。それを実現するのが今回開発したLiveShell Remoteというサービスです。
LiveShell Wを使った配信における映像の流れは以下のようになります。
- カメラからLiveShell Wに映像を入力(HDMIで2系統の入力が可能)
- LiveShell Wにて映像のスイッチや合成などを行う
- 生成された映像をLiveShell Wから配信サービス(YouTubeなど)に送信して配信
LiveShell Remoteを使うと、LiveShell Wで行う映像のスイッチや合成、および配信サービスへの送信などの制御を、すべて遠隔で実施できるようになります。
LiveShell Remoteの主な機能
LiveShell Remoteにアクセスすると、すでに登録されているLiveShellデバイスの一覧が表示されています。ここで、表示されているデバイスの右側にある「LiveShell Studioを開く」というボタンを押すと、LiveShell Wに実装されているWebアプリケーション(LiveShell Studio)の画面が表示されます(下図)。
LiveShell Studioでは、カメラから入力された映像のプレビュー、スイッチングや合成、配信サービスへの送信を行うことができます。画面の左側には各入力のサムネイルが表示されます。必ずしも表示させる必要はないので、オンとオフを選べます。プレビューをオンにしておくと、映像のスイッチングや、合成された映像も見ることができます。例えばスイッチングしたときにフェードする様子が見られたり、PinP合成の映像などを確認することができます。
そして、これらの処理を行った結果、実際に配信されるストリームが画面右側ということになります。右側の部分では、YouTubeに打ち上げるなどの配信のコントロールができるようになっています。
LiveShell Remoteは、このようなLiveShell Studioが持つ各種機能を、遠隔で操作できるサービスということになります。デバイス内にWebアプリが実装されているので、リモートから操作しても、デバイスに付いている物理ボタンで操作しても、まったく同じように操作できます。言い換えると、すべての機能がLiveShell Studioに入っていて、LiveShell Remoteはそれを観察し操作するだけのシステムという形になっています。
LiveShell Remoteのアーキテクチャ
ユーザがLiveShell Studioを操作する場合、LiveShellデバイスとユーザ端末がIP接続されていれば難なく操作できますが、実際には間にNATやファイアウォールが入っていることが多く、そのような場合は直接通信できません。そこで、ユーザ端末とLiveShellデバイスを仲介するような中継サーバ(リレーサーバ)を設置し、それを介してLiveShellデバイスとの通信を行うというアーキテクチャになっています。
技術的な詳細は非公開な部分もありますが、実際にやっていることとしては、LiveShellデバイスから暗号化されたトンネルをリレーサーバに張っています。そうすることによって、ユーザから見ると、クラウド上に設置されたWebサーバに対してアクセスをしているような感覚で、実際にはトンネルを通じて機器との通信ができるという仕組みになっています。
また、LiveShell Studioでは映像のプレビューを見ることができますが、APIでつながっているだけのサーバに対して映像ストリームを送信するのは難しいので、Webアプリケーションの中に映像のプレーヤーを置き、それを見に行くような形でプレビューを実現しています。プレビュー用の映像は、実際に配信される映像とまったく同じ品質のものを分岐して流しています。Webアプリに対するアクセスは、プレビュー映像なども含めてすべてトンネル経由で行われるので、クラウド上にはコンテンツを一切持っておらず(Webアプリのデータも、ユーザがLiveShellに入力した映像/音声も)、基本的にすべてのコンテンツをただ中継しているだけです。
なお、LiveShell Remoteには中継の仕組みだけではなく、ユーザ管理やライセンス管理といった機能も必要なので、それも合わせてクラウド上にシステムを構築しています。
過去のLiveShell配信システムからアーキテクチャを大幅に変更
従来のLiveShellシリーズでは「Dashboard」という別のサービスでリモート制御などの機能を提供していましたが、これが10年前ぐらいに作られたシステムで、保守が困難になってリプレースの時期に来ているという事情がありました。そこで、このあたりの仕組みを新たに構築することになり、LiveShell Remoteを開発したという経緯があります。
特に、DashboardではWebサーバなども含めたすべてのシステムがクラウド上にあり、そのAPIを使って機器の制御を行っていたのですが、LiveShell RemoteではWebアプリケーションがデバイスに内蔵され、そのWebアプリを遠隔で操作するという、アーキテクチャの大幅な変更を行いました。こうすることによって、遠隔でもローカルでもまったく同じUIが使えるというメリットが生まれました。
このような変更を行うことができた要因として、デバイスやネットワーク性能の劇的な進化があります。Dashboardを開発した当時はデバイスの性能が現在に比べるとかなり非力で、デバイス側にWebサーバを載せるようなことは難しかったのでこういう設計になりました。しかしその結果として、アプリケーションへの機能追加が難しいとか、クラウドに障害が発生するとそれに接続しているすべてのデバイスに影響が及ぶといった問題も抱えていました。しかしDashboardの開発から10年が経過し、デバイスもネットワークも大きく性能が向上した結果、このようなアーキテクチャ変更が可能になりました。今回のアーキテクチャでは、例えばLiveShell Remote(もしくはその基盤となるクラウド)に障害が発生してもLiveShellデバイス自体は変わりなく動作しているので、遠隔での操作はできなくてもデバイス自体の操作や配信は問題なく実施できます。
それから、この10年でソフトウェアの方もかなり進歩があり、Webアプリケーションもかなり多彩なUIが作れるようになりました。このあたりの表現能力の進化も大きいとのことです。
ちなみに今回のシステムで採用している技術としては、フロントエンドはReact、バックエンドはDjangoを使用しています。LiveShellデバイスの中にはgRPCを扱えるサーバが実装されていて、それがボタンやLEDの操作をしたり、Webサーバとの通信などをしています。
さくらのクラウドの利用
そして、このLiveShell Remoteのシステムは、さくらのクラウド上に構築しています。
大きな採用理由はトラフィック課金がないこと
さくらのクラウドを採用した大きな理由として、トラフィックによる課金がないことが挙げられます。
LiveShell Remoteのプレビュー機能では、LiveShellデバイスからクラウドを通ってユーザ端末まで映像が送信されます。映像がクラウド上を流れる関係で非常にトラフィック量の多いサービスになるので、トラフィックで課金をしないというさくらのクラウドの料金体系が非常にマッチしていました。これがAWSなどを利用すると、トラフィックの部分で費用が非常に大きく跳ね上がる可能性があって見積が難しくなりますが、さくらのクラウドを使うことでこの問題を気にしなくてよくなりました。
システム構成
システムの構成としては、最小単位として東京と石狩に各1セットのシステムがあり、各セットは3-4台のサーバで構成されています。各サーバの役割は以下の通りです。
- Webサーバ：LiveShell Remoteにアクセスしたときに最初に表示されるデバイス一覧画面などを提供
- リレーサーバ：デバイスとの間でトンネルを張り、クライアントからのアクセスを中継
- APIサーバ：Webサーバやリレーサーバからのリクエストを受けて、裏側にあるデータベースと通信
- データベース：本システムに関する各種データを保存
外部からはWebサーバとリレーサーバが見えていて、裏側にAPIサーバとデータベースが存在します。データベースはさくらのクラウドのデータベースアプライアンスを使っています。
ネットワーク構成としては、対外的にはルータ＋スイッチを使って接続しています。各セット内のサーバ同士はローカルネットワークのスイッチでつながっています。それから、東京と石狩のローカルネットワーク同士もつながっています。これはブリッジ接続を使っています。
冗長化の設計が難しい
Cerevoの皆さんに、今回構築したシステムに関する課題や、さくらのクラウドを利用してみてどうだったかを聞いてみました。
まず現時点の課題としては、東京/石狩というゾーンを超えたデータベースの冗長化をしたいというのがあります。さくらのクラウドのデータベースアプライアンスにも冗長化オプションはあるのですが、スペックの大きなプランしかなく、今回の用途に対してはサイズが大きすぎてコスト的に見合わないそうです。大規模なデータベースではないからといって冗長化が不要なわけではないので、より小規模な冗長化プランの登場が待たれるところです。
また、データベース以外の面でも、このシステムにおいては全体的に冗長化の設計が難しかったようです。その理由としては、デバイスを起動した時にどれかのリレーサーバにセッションを張らなければならないという点があります。それ自体はDNSのラウンドロビンに近い方法などを利用して分散できるのですが、クライアントからの接続はリレーサーバ経由で、いわばVPNを張るような形で行っているので、簡単に冗長化できないということです。
フロントエンドもバックエンドもハードウェアもわかる人材を求めて
今回の開発は小林さんが主体となって進めましたが、全体でも3-4人という少人数で、フロントエンドもバックエンドもデバイスの制御も実装しました。現代的なWebアプリを開発するための知識に加えて、ハードウェアの制御もあるので組み込み方面のことも理解している必要があるという、ソフトウェア開発やサービス開発といってもやや特殊な面を持つシステム開発と言えます。フロントエンドもわかり、バックエンドもわかり、ハードウェアもわかるような人はなかなか希少です。
今回お話をうかがう中で、そのような人材をどこでどのように見つけて採用しているのかといった話題も出ました。Cerevoの場合はハードウェアを扱っているイメージが先行しているので、それ以外の技術属性を持つ人がなかなか応募してこないという実情があるようです。さくらインターネットもインフラの会社というイメージが強いせいかソフトウェアエンジニアの応募が少ないので、似たような状況ではあります。椚座さんからは「GoやRustで低レイヤーなこともやりたいけどガチガチの組み込みはちょっと…という人には、こういう開発はすごく面白いと思うんですよ。組み込みほどの泥臭さはないけど、Web一辺倒かと言われるとそうでもなく、現代的な形のステートマシンを作るという仕事なので、意外にあるようで少ない仕事かもしれません。こういった仕事に興味のある人はぜひ応募してください」というコメントをいただきました。
また、技術コミュニティが主催するイベントに出ることで、こういった人材と出会い、採用につなげているという話もありました。9月7-8日(土日)には東京の科学技術館で「NT東京2024」が開催されます。こちらのイベントにはCerevoもさくらインターネットも協賛し展示を行います。今回のシステムについても紹介できればと思いますので、ぜひご来場ください。
おわりに
コロナ禍を経て、イベントにおけるライブ配信はより需要が増した感がありますが、配信に携わる人は会場で機材を操作しなければならないので、リモートワークで働く人に作業をお願いすることはできませんでした。しかしLiveShell Remoteが登場したことで、リモートワークの人にも配信作業をお願いできる可能性が出てきました。これは大きな進歩だと思います。これに加えてカメラの遠隔操作などの仕組みも用意すれば、出演者だけスタジオに入り、あとはすべて遠隔操作で配信するようなことも可能になるかもしれません。
さくらインターネットはリモートワークを前提とした働き方を推進している会社なので、このような機材が出てきたのはとてもうれしいことです。自社イベントで配信を行うこともあるので、これからもより良い配信の形を模索していきたいと思います。
Cerevoの皆さん、このたびは取材に応じていただきありがとうございました！
