ライブ動画配信サービス「ワイキュー」の作り方
石井直矢氏（以下、石井）：「ライブ動画配信サービス『ワイキュー』の作り方 〜優れた社内技術で実現する、少人数のサービス開発〜」というタイトルで発表させていただきます、石井といいます。よろしくお願いいたします。
普段はフロントエンドエンジニアとして、JavaScriptやTypeScriptを使って開発を行っています。そんな自分について、簡単に自己紹介をさせてください。
もともとサービス開発がしたくて、Yahoo! JAPANに入りました。そのなかで、スマートフォン版のトップページの開発に携わりまして、トップページのリニューアルプロジェクトを経て、JavaScriptを触っていくようになりました。
左が自分が入った頃のYahoo! JAPANのトップページなんですが、覚えている方はいらっしゃいますか？ いまは右側のデザインに変わっています。この開発でJavaScriptを多く使うようになって、そこで勉強するようになりました。
リニューアルには成功しましたが、このとき使っていたアメリカのYahoo! Inc.が作ったYUIというライブラリのサポート終了に伴い、別のライブラリに書き換えないといけなくなってしまいました。
そこで、この問題が出た2015年度に、にわかに盛り上がりを見せていたReactを採用して、見た目は完全に同じですがJSのコードを全部イチから書き換えるといったプロジェクトを、自分が主導してリリースしました。
そんな開発の経験を経て、Reactの入門書を執筆しました。
Reactと一緒に大規模アプリケーションで使われるReduxというライブラリについてもかなり詳しく書いていて、本書の半分くらいを占めています。もし興味がある方は、手に取っていただけたらうれしいなと思います。
そんな感じでフロントエンド開発をメインでやってきましたが、いまでは「ワイキュー」というサービスを開発しています。先ほど善積と染矢のセッションを聞かれた方もいるかもしれませんが、一緒に開発をしています。
「どうやらこの人はフロントエンドの人らしい」ということがわかっていただけたところで、今日はアーキテクチャの話をみなさんは聞きに来られたのかなと思います。間違っているわけではなくて、そんな自分がアーキテクチャの話をするのには訳があります。「アーキテクチャに精通していない自分も含めた少人数のチームでも、ワイキューという新サービスを半年でリリースできたのはなぜか？」を、紹介していきたいなと思います。
ワイキューの概要
その前に、先ほど善積と染矢のセッションを聞かれた方はもう1回になってしまいますが、ワイキューについて簡単に説明させてください。
賞金山分け型のエンタメライブ番組で、全問正解した人で賞金となるTポイントを山分けします。毎日21時からライブ配信して、いろんなジャンルの問題があるのが特徴です。
以上がユーザー向けの説明です。技術面でこれを解説していくと「ライブ動画配信」「リアルタイムのコメントコミュニケーション」「同じタイミングで回答や問題を出す」ためリクエストが集中する、賞金付与については失敗できないといった難しさを持ったプロダクトです。
これを分解すると「ライブ動画配信」「コメント」「出題・回答」「Tポイント」という4つの要素になり、これらを実現するアーキテクチャはこのような図となります。
ワイキューのシステムは、だいたいこのようにできています。
先ほどの4つの要求を満たすシステムのなかで、私たちワイキューチームが作っているのは、（スライドを指して）この図の赤い部分のみです。
その他の黒い部分については、すべて社内プラットフォームが提供してくれているものを使っています。
なので、このように関係するアーキテクチャが多いサービスでも開発メンバー3人でサービスを立ち上げることができました。つまり、多様なプラットフォームの開発があり、それが使えることでワイキューの開発は支えられています。
ライブ動画配信のシステム構成
ではそれぞれの要素について、1つずつ具体的にどのようになっているか説明していきます。
まず1つ目は、ライブ動画の配信システムの構成についてです。
文字などが少し小さくて見づらいかもしれませんが、動画配信スタジオがあって人が動画をビデオで撮る。エンコーダーを通してRTMPというプロトコルでサーバーに配信して、その動画をCDNに置いて、ユーザーのもとに届けるものを自分たちで作らなければなりません。ですが、説明したにもかかわらず、自分自身はあまりよくわかっていません。
これは社内のプラットフォームが提供してくれている「動画プラットフォーム」というサービスを使っています。
そのため、ワイキュー自身ではあまり開発することがなく、このプラットフォームを使うだけで開発できています。
この動画プラットフォームはHLSというライブストリーミングを提供するプラットフォームです。
ショッピングやオークションのライブコマースでも利用されているプラットフォームで、動画自体にメタ情報をプラスできます。
これはワイキューに合わせて機能を提供してもらいまして、ワイキューでは動画のなかにある「問題を出しなさい」「答えを出しなさい」という情報をもとに画面の制御を行っています。
こういうものを同じ社内にいる別のチームの人が作ってくれているので、「ワイキューというサービスをやりたいので、こういう機能がほしいんですけど」と相談し、それに合わせて機能を提供してもらいました。
他にも身近にいるメリットとして、配信機材の手配なども手伝ってもらいました。最初はGoProで撮影して社内で検証していましたが、そのGoProもプラットフォームの方が「貸してあげるよ」と言って貸してもらったものをいまだに使っています。
そんななか、フロントエンドエンジニアの自分がどんなコミットをしていたかというと、これは
動画プラットフォーム自体の開発をする代わりに、この辺りの制御に集中できたんです。トップページではない初の開発だったので、かなり楽しく開発することができました。
コメントのシステム構成
こんな感じで、他の要素についても説明できればと思います。次はコメントについてです。コメントは、みなさんがイメージする一般的なコメントのシステムとだいたい同じところから始まります。
WebSocketでコメントをやりとりする。それだけなんです。
実際にYahoo! JAPANとしてサービスを提供するためには、NGワードなどを登録して、誹謗中傷や悪い言葉を表示させないよう制御しなければなりません。これらはデータベースに保存されていて、そこから大丈夫かどうかチェックしてサーバーに返し、リアルタイムで新しいNGワードが入ってきたらそれを登録する、といったことをするシステムが必要ですが、作るとなるとこれってけっこう大変じゃないですか。
これだけで時間がかかってしまいますが、この部分に関してもYahoo! JAPANには不正投稿判定のプラットフォームがあって、それを使うだけでコメントのフィルタリングがすぐできます。
ワイキューには、いくつもユーザーから入稿できる部分があって、こういう機能もプラットフォームとして提供されています。弊社で展開されているために他のサービスで登録されたワードを自分のサービスでも使うこともできるし、単純な文字列マッチだけではなく機械学習によって未知の文字列にも対応できるプラットフォームです。
そのなかで自分はどんなコミットができたか、というと描画のパフォーマンスに集中できました。
1月21日の配信ではイケメンな方の「みなさんの好きな食べ物は何ですか？」といった質問に対してワーッとコメントが入ってきて、秒速75コメントが記録されました。
最近ではチームプレイにも対応していて、そういうコミュニケーションができるようになっていますが、正直、動画を見てクイズに答えるだけだったらコメントの機能ってなくても成立するじゃないですか。でも、コメントがあることで、人気（ひとけ）であったり、楽しい感じが表現できます。そういう楽しい気持ちを作れるのは、開発としても楽しいことかなと思っています。
出題・回答のシステム構成
出題・回答のシステムに関しては、あまりプラットフォームが大々的に使われているわけではなくて、Yahoo! JAPANというよりはワイキュー独自のシステムなので、ほぼほぼ自分たちで作っている部分です。
このシステムの難しいところは、問題への回答リクエストが短い時間にギュッと集中して行われるので、それをすべてさばききらなければいけないところです。
それが実現できたのはなぜかというと、この図のなかではサーバーが1台だけで表現されていますが、もちろん実際には1台ではありません。西日本・東日本それぞれにサーバーのクラスタが立っていて、それぞれのクラスタのなかにはサーバー50台分ぐらいのインスタンスが立っています。
ワイキューは別に地震のときにサービスが止まっても大丈夫なのですが、大事なニュースに関しては、データセンターが地震で壊れてしまったときにもサービスを展開させるために、Yahoo! JAPANでは日本の東西でBCPが行われています。
なので、ワイキューのようなサービスでもちょっとした設定をするだけで、東西にそれぞれ2クラスタずつ、それぞれ何十台というインスタンスを立てることができます。これもYahoo! JAPAN社内のPaaSプラットフォームを利用することより、クリックしていくだけでできるようになっています。
他には、パフォーマンスを出すためにはRDBよりもKVSのほうが良かろうということで、問題を保存するストレージにはCassandraを採用しています。また、ワイキューではコメントの保存にRedis、賞金データの保存にOracleを使っています。これらもすべてプラットフォームとして提供されているので自分でサーバーを立てる必要はなく、クリックしていくだけで設定できます。
そのなかで自分がどういうコミットができたかといいますと、フロントエンドの開発に集中できています。問題を出すとか、消すとか、それなりに大変でしたが、そこに集中することができました。
他に、APIサーバーやBackend For Frontend（BFF）という中継するサーバーの構築にも挑戦することができました。自分はブラウザまわりのJavaScriptしか書いたことがありませんでしたが、このようなサーバー管理ではなく、サーバーのメインになっているアプリケーションを作るという、自分としては新しいことに挑戦できました。
TypeScriptの開発などは新しい挑戦なのですが、新しいことって楽しいですよね。そのため、楽しく開発することができました。
ポイントのシステム構成
最後、Tポイントについてはこういったシステムです。
ポイントはユーザーの資産に影響するセンシティブな機能ですので、とくに「いくら増やした」「増やしてなかった」あるいは「消えた」「漏れた」となると大変な苦情になります。そのため、特別堅牢にシステムを構築しています。
まず、問題などとは処理系を分けています。問題を出せなくなったなどの場合でも、課金処理みたいな、Tポイントの付与処理がダウンしないように処理系を分ける、サーバーを分けています。さらに、データベースもCassandraではなくOracleを利用しています。
一方で、出題・回答というリクエストとは違い、直ちにTポイントの付与処理などを行わなければいけない、というわけではありません。なので、いったん付与情報をMessage Queueに保存して、それをサーバーやデータベースが余裕のあるタイミングで逐次処理をしていく、という方法を取っています。
実際にTポイントを付与する仕組み自体は、ワイキュー自身はわかっておらず、Tポイントのシステムがやってくれています。
いま登場したプラットフォームは「Message Queue」「Oracle」「Tポイント」というのがありました。Message Queueというプラットフォームは、アメリカのYahoo! Inc.が開発したOSSであるPulsarという技術を用いています。これはYahoo! JAPANでは使っているだけではなくて、OSSにコントリビュートしているチームがあります。
Oracleもプラットフォームとして提供されているし、TポイントについてはかなりYahoo! JAPAN固有のプラットフォームだなと思います。ポイントやお金に相当するものをユーザーに付与するものを独自に開発するのは相当大変だと思いますが、Yahoo! JAPANにはそれがプラットフォームとしてあります。「これを使わない手はないな」ということで使っています。
自分はここに対してどうコミットしたかということなのですが、正直なにもしてないです（笑）。フロントエンドエンジニアとして貢献することは……、僕とバックエンド2人のチームなんですが、2人の方が作ってくれたお金まわりの処理をするAPIを叩くだけでよかった。
APIを作ってくれている彼らも本当にセンシティブなところにはシステムがあるのでつなぎ込んでいくだけです。複雑な処理にもかかわらず、データを消さないようにするみたいな面倒さはもちろん気にはしますが、普通のAPIに近いかたちで実現できています。
このようにワイキューのシステムはできていて、この図のなかでも青い部分に関しては、すべてプラットフォームが提供している部分です。半分ぐらいというか、このサーバー3つのアイコンでまとめたなかに同じぐらいのサイズのシステムがたくさんあるのだろうなと思うと、工数としてはかなり削減できているように思います。
この図にずっと出てきているのに紹介してなかったものがありますね。ここにあるリバースプロキシはHTTPSでサービスを提供するために置いています。ここも設定をしていくだけで、URLと代表的なサーバーのドメインを紐付けることができます。
CDNも社内にあり、ここから静的なJavaScriptのファイルや画像のファイルなどを引き出します。この図のなかにはありませんが、Push通知をするためのプラットフォームもありますね。
ワイキューが管理していないこと
まとめに入りたいと思います。
ワイキューが管理していないことです。
ワイキューは、プラットフォームとして提供されているシステムに関しては、自分たちでは管理していません。物理的なサーバーも管理しておらず、PaaSのかたちで提供されているものを使っているだけです。
いまの図はデータの流れを表現した図だったので出ませんでしたが、当然「ログインする」ということも、Yahoo! JAPAN IDによるログインはプラットフォームになっていますし、各システム間でデータをやりとりするための権限や認証の部分もプラットフォームです。
作ったコードをGitに上げて、それをサーバーに上げるといったCI/CDの環境や、クライアントで取った、またはサーバーで取ったエラーのログの収集や解析もプラットフォームとして提供されています。
ワイキューでは使ってないサービスももちろんあって、Container as a Service（CaaS）、Function as a Service（FaaS）、アラート検知、画像の変換、Push通知、広告を出すといったところも、全部プラットフォームになっています。
一方でワイキューが何をやっているのか？ といいますと、ワイキューは「こういうシステム構成にするぞ」ということ自体を管理していて、問題管理のAPI、コメントやユーザーの端末で動くプログラムといったワイキュー固有の機能は管理しています。
もっと大事なのは「機能ではない部分」をワイキューが開発・管理しています。それは「楽しい！」「ワイワイ！」という演出や、おもしろいサービスを作るという部分ですね。
ワイキューがリリースするまで
こんなワイキューがリリースされるまでをお話します。
去年の4月に開発メンバーが入り、8月の末には動画を作って、社内のスタジオから社内向けにサービスを提供できるような状態まで作ることができました。
全部の、動画を配信するところ……Tポイントやコメントのフィルタリングまで、全部自分で開発していたらとてもこんな期間では作れませんが、ひとえにプラットフォームが充実しているおかげで、ワイキュー自体の開発に集中することができたと思っています。
Yahoo! JAPANには基盤からNGワードフィルターまで幅広くプラットフォームがそろっています。サービスを作る側はサービスのコアバリューに集中することができ、プラットフォーム側はプラットフォーム自体の開発に集中できています。
社内プラットフォームが充実しているおかげで、ワイキューのような新規サービスもすばやく堅牢に作ることができました。
「完全分業をしている」といった話をしてきましたが、基本的には「これは健全な関係だな」と思っています。
「ユーザーのニーズ」「自分のやりたいこと」「会社としてやってほしいこと」すべてを満たした仕事が楽しい仕事、あるいは価値のある仕事のあり方なんじゃないかなと思っています。
自分の例では、「ワイキューで遊んでくれる人がいる」のは「ユーザーのニーズ」で、「自分が得意なフロントエンドで開発に集中できる」のが「自分のニーズ」。これが「仕事としてできる」言ってしまえば「お給料をもらえる」のも価値です。この3つが満たされていて、かなり楽しく開発できている実感があります。
一方でプラットフォームエンジニアとしては、プラットフォームを必要としているサービスがYahoo! JAPAN社内にはたくさんありますので、そこにニーズがあります。彼らは社内に色々なプラットフォームがあるので、好きなプラットフォーム、自分の興味がわくプラットフォームを追求して、サービスを提供してくれています。それも仕事としてもちろん評価されています。
こういった、サービスもプラットフォームも楽しく開発ができる環境がYahoo! JAPANにはあります。そんなプロフェッショナルが集まってできあがる1つのプロダクトの開発に、みなさんもジョインしてみてはいかがでしょうか。
以上になります。ご清聴ありがとうございました。
（会場拍手）
