2月7日に開催された「DeNA Technology Conference 2018(TechCon)」のセッションでは、仮想ライブ空間「SHOWROOM」におけるサービス構築・運用の裏側が披露された。本稿では、SHOWROOM Tech Studioのヘッド 池滝俊太氏による講演「『SHOWROOM』の大規模化に伴う技術課題のソリューション ～演者・視聴者の熱量を支える負荷対策、HTML5対応など～」をダイジェストでお届けする。

成長を続けるサービスの”裏側”

SHOWROOMは、アイドルやタレント、アーティストとリアルタイムにコミュニケーションでき、ギフティングやコメントで応援ができるサービス。生放送のみで、演者と視聴者が同じ時間を共有することにこだわっており、視聴者は自分のアバターを通したアクションを通じて演者との一体感を得られやすいことが大きな特徴だ。

池滝氏は、2014年に新卒でDeNAに入社後、新規事業開発を経て、SHOWROOMのコンセプトに共感して自ら異動を希望。SHOWROOMでAndroidアプリやサーバサイドの開発などに従事し、現在はTech Studioのヘッドとして、エンジニアのマネジメントを行う。

「2013年11月にサービスを立ち上げ、5年目に突入しました。技術的負債も溜まってくる一方、サービスは成長を続けています。今日はどのようにチームが戦ってきたのかを実例を交えてご紹介します」(池滝氏)

SHOWROOM Tech Studioのヘッド 池滝俊太氏

講演では、大きく「負荷対策」「PC版のHTML5化」という2つの取り組みを紹介し、その上で、サービスやシステムをどのような考えで作っていくかを解説した。

きっかけは大規模イベントに向けた準備

まず、負荷対策については、サービスが成長する過程でどんなトラブルが起きたのかを振り返った。SHOWROOMのサーバ側は、MySQLやMemcachedを基盤に、Web・バッチ・デーモンを全てPerlで処理するというアーキテクチャだ。ギフティングやコメント向けのリアルタイムサーバはDeNAが開発した「bcsvr」を利用、動画配信サーバにはWowzaが開発する「Wowza Streaming Engine」を利用している。

「2016年6～8月に大きなイベントがあり、当時の約10倍のトラフィックが見込まれました。そこにターゲットを合わせて大規模な負荷対策を行ったのが（負荷対策に取り組み始めた）発端です。方針としては、まず何よりもサービスを止めないことを大前提に掲げ、対策を講じていきました」(同氏)

具体的には、ギフティングアクションのPublish処理など、非同期化できる処理の非同期化、Q4Mを利用したMySQLでのジョブキューの利用、アクセス数の多い順にAPIを1つ1つチューニングすること、MySQLへのクエリーのチューニングなどだ。特にMySQLへのクエリについては、過剰にselectしていたレコードを絞って必要数分のレコードをとるようにしたり、「Order by」や絞り込みをMySQL側で行わず、アプリサーバ側で行ったりした。

動画配信サーバの負荷対策

また、動画配信サーバの負荷対策では、オートスケールで対処できるようにした。人気の高いトップコンテンツなど事前に大規模配信がわかっている場合、オートスケールにかかる数分の安定性を確保するため、事前に手動でスケールさせておくといった工夫も行っている。

「ビジネスのメンバーを通して依頼が来ますから、Slackを用いたChatOpsでスケールアウトします。反応の大きさはTwitterで確認することもあります。それでもトラフィックが多い場合は、CDNに流しています。ただ、遅延が少し大きくなるのでトレードオフです」(同氏)

動画配信サーバは、Origin/Edgeという構成をとっている。配信者がOriginサーバに配信すると、Edgeサーバを経由してユーザーに届けられる。また、配信者は「Shard」という単位で一定数がまとめられている。大規模なトラフィックが発生する場合、特定のShardで配信を行うことを決めておき、Originサーバに対してスケールアウトを指示すると、Edgeサーバがスケールアウトして負荷が分散される仕組みだという。

独自ツールによる高負荷状況のシミュレーション

一方、クライアント(アプリ)に対しては、独自ツールで高負荷状況のシミュレーションを行って、長時間のスムーズな視聴ができるかどうかを検証している。アバターやギフトの描画はOpenGLレイヤーで行っており、Android StudioやXcodeなどでCPU負荷、GPU負荷を確認している。高負荷シミュレーションの仕組みは日常的にQAに用いている。ルーム内の実装を大幅に変更したときなどの再検証に役立つという。

さまざまな負荷対策を行ってはいるものの、それでも障害に直面することもある。2017年2月にはトップコンテンツの大規模なユーザーが流入し、Webが応答しない障害が発生した。原因はイベント機能のポイント集計のクエリが遅く、データベースの負荷が高まったことだった。

「負荷対策プロジェクトを実施した後も機能改修は継続されますから、負荷対策も継続的にやっていくしかありません。そこで、社内ドキュメントだけでなく、しっかりチーム全員で振り返る負荷対策勉強会を催すようになりました。勉強会では、サーバサイドだけでなく、クライアントサイドの人にとっても学びがあります。APIコールをできるだけ減らそう、タイミングをずらせるように工夫しようといった考えの起点になります」(同氏)