ミクシィ、エムスリーが「コロナ禍の技術的チャレンジ」をプレゼン！大規模なシステム移行とスピーディーな機能改修の裏側を明かす【後編】

2021.05.18 働き方

2021年4月13日～17日にかけて、エンジニアtypeでオンラインカンファレンス『ENGINEERキャリアデザインウィーク』（ECDW）を開催した。

本記事は前編に続き、「Tech企業４社がプレゼン！コロナ禍の技術的チャレンジ」のセッションからミクシィ、エムスリーの発表内容を紹介する。

遠隔での作業が増えがちなコロナ禍で、各社のスピーディーな事業展開から学べることがあるはずだ。

「TIPSTARを支えるリモート映像編集と自動映像編集」／ミクシィ馬淵俊弥さん

株式会社ミクシィ　開発本部インフラ室映像技術グループ　馬淵俊弥さん

1991年生まれ。2014年に新卒で大手国内ISP企業に入社し、ISPのネットワークバックボーンの運用や設計、ネットワーク運用自動化のための取り組み等に従事。その後18年にミクシィにネットワークエンジニアとして入社し、『モンスターストライク』のインフラネットワーク運用や、パケット高速処理システムの開発、オープンソース光伝送装置の導入等を経た後、『TIPSTAR』の映像編集システムの開発も兼任し、現在はメイン開発者として従事

スタジオ編集からリモート編集へ、運用体制を変更

馬淵さんの携わる『TIPSTAR』は、全国43会場で行われる競輪を365日放送し、TIPSTARと呼ばれる３人１組の演者の結果予想を見ながら賭けることができる、共有型スポーツベッティングと呼ばれるサービスだ。

これまではスタジオの機材で編集作業を実施していたが、高過ぎる運用負荷やコロナ禍のテレワーク推奨により、急きょシステムを変更せざるを得なくなったという。遠隔での映像編集をどのように実現したのかがプレゼンの主題だ。

TIPSTARで行われる映像編集は、競輪のレース映像とスタジオで収録される演者の映像の２種類ある。編集作業は、以下のような内容だ。

＜競輪映像＞2万レース／年間
・テロップとBGMの演出追加

＜演者映像＞1095番組／年
・吹き出しや状況説明のテロップの演出追加
・背景のクロマキー合成
・レース結果や的中金額のアニメーションのリアルタイム生成

「運用体制を変更する前は、各会場で撮影した競輪の映像をデータセンタへ送り、スタジオの機材を直接操作して編集してクラウドに配信。さらに同じスタジオで演者チームの撮影が行われており、演者チームの映像も手動で編集しながら複数の機材を操作し、編集後にクラウドに配信するという、それなりに操作機器の多いフローになっていました」

東京スタジオとデータセンタの体制変更の際に、課題として挙がっていたのが以下の２点だ。

1、映像編集の運用負荷が高い
365日映像編集を行い、多数の機器を操作するためオペミスの発生率が高く、品質が人に依存している状態だった

2、動的なテロップ生成／再生が必要
映像素材を複雑に組み合わせて使用するケースがあり、かつレースという特性上、事前に素材を用意しておくことも難しい。既存の製品では要件に合わず、運用負荷が軽減しづらい状況だった

これに加え、新型コロナウイルスの流行により、３密を避けたリモートでの撮影・編集に対応しなければならなくなった。

そこで同社が開発したのが、リモート編集システム『BreezeCast』だ。編集作業をWebブラウザベースで完結できるプロダクトで、WebRTCによるリアルタイムの映像モニタリングによって、リモートでも映像編集が可能となる。さらに、シングルページアプリケーションによるインタラクティブな編集やボタン一つで複雑な編集をこなせる仕様により、運用者にストレスが掛からない配慮がされているそうだ。

BreezeCastの大まかな構成がこちら。映像を同軸ケーブルで出さなければならない制約があるためオンプレミスを採用し、ロジック（図の上半分）はGoogleクラウドプラットフォームの中に収容されている。このAPIからインターコネクトを通じて、オンプレミス上のレンダリングするサーバーに命令を飛ばして操作したり、編集機器を操作したりしている。

「ここで重要な役割を担うのが、WebRTCです。そもそもライブ編集をするには『編集前のリアルタイム映像』と『編集後のリアルタイム映像』のいずれも必要です。この二つの映像を同時に流すことができないと適正な編集判断ができないため、それを既存のWebシステムで利用可能にするためにWebRTCを採用しました」

WebRTCの特性としては、以下が挙げられる。
1、低遅延なデータ送受信(音声／映像／その他データ)
2、Webで利用可能
3、双方向でのやり取りが可能

「緊急事態が重なったため、カスタマイズ性よりもスピードを重視しました。株式会社時雨堂のWebRTC SFU Soraとmomoを利用したことで、２〜３営業日で同軸映像を遅延なく、Web上で表示可能な状態にすることを実現しました」

WebRTCの同軸モニタリング構成はこの通り。このような仕様変更により、スタジオから離れた場所にいても3フレーム程度（0.1秒）程度の誤差で編集ができる環境が整ったそうだ。

参加者からの質問「快適な映像の秘訣は？」

プレゼン後は参加者からの質問コーナーが設けられた。その回答を一部抜粋して紹介したい。

――SPA（シングルページアプリケーション）というと初期表示が遅いイメージがありますが、最初からサクサクで全く気になりませんでした。何か対策をされているのでしょうか？

「映像をサクサク動かすために、SPA上は映像を受け取るための手続きだけで、実際は映像をサーバーで受け取っています。現状はサーバーサイドレンダリングとあまり変わらない動きですが、もし今後ロードした後に動作がもっさりするようになれば、対策が必要かもしれません」

「急成長するサービスを支える技術」／エムスリー高島亮祐さん

エムスリー株式会社　基盤開発チームリーダー　高島亮祐さん

大学卒業後、システムインテグレーターでエンジニアとして働く中で、プログラミングの面白さに目覚める。業務の傍で技術書の翻訳をしており、訳書に『実用的でないPythonプログラミング』など。2019 年よりエムスリーにて勤務

コロナ禍でサイトアクセスが増大。一気に限界に達した

医療従事者専用の情報交換等を目的とした『m3.com』を始め、医療業界にまつわる数々の独自サービスを展開するエムスリー株式会社。同社からは基盤開発チームに所属し、共通サービスの開発運用等に携わる高島さんが登壇。急成長するサービス開発の裏側を紹介した。

エムスリーでは、新型コロナウイルスに関連した情報発信や専門家によるWebセミナーの開催等を積極的に実施していたところ、サイトアクセスが前年比150％を超えるほどに増大したという。

「弊社では長年にわたり安定した成長を続けてきましたが、コロナ禍での予期せぬサービス急成長により、さまざまなリソースが一気に限界に達してしまいました。この背景には、オンプレミスで構築され20年近く続いている古いサービスが多数あったことも影響しています」

そこで同社は、アクセス増加への対策として以下を実行した。
1、クラウド移行によるAPサーバーのスケールアウト
2、サービスを分割（マイクロサービス化）して主要サービスの負荷軽減
3、リソース単位のクラウド移行によるボトルネックの回避
4、分散トレーシングで見つけたアプリケーションの問題の修正

当初、APサーバを３台から６台へ増強したが不安定さが見られ、以前から検討していたクラウド移行を前倒しすることに。AWSのサービスを最大限に活用して構成を組み直したそうだ。

「構成はこの図の通りです。大きく変えていますが、アプリケーションの中身はまったく手を付けておらず、動作環境のみをクラウドに移行しています」

結果的に、スケールアウトは期待通りの効果を見せているという。クラウドではコンテナ数を一気に16に増やしたことで、安定してリクエストをさばけるようになった。一方で、ログ連携など、プラスαの機能の移行方式の検討には時間と手間が掛かったと高島さんは付け加えた。

続いて、マイクロサービス化を実施。改善の背景として、同社ではユーザーのアクティビティーをトラッキングする仕組みを採用している。アクセスが増加する状況で、以下の図のようなリソースの共用や複雑な仕組みが相互に悪影響を及ぼしている状態だったという。

この構成をクラウド化を機にシンプルに変更。別のサービスに相乗りしていた箇所を完全に独立させ、GCPのサービスで構成している。現在は、随時・日次の二股に別れていた箇所も一本化したシンプルな構成になっており、メンテナンスがスムーズになったそうだ。

さらに、「あるサービスの呼び出しがタイムアウトになる」というボトルネックの課題に対して、クラウド上にロードバランサーを構築。これは、サーバーとクライアントの間にある共用ロードバランサーのSSL接続数が上限に達していたためだ。上記の改善により接続数が上限に張り付かなくなり、タイムアウトの問題は解消されたという。