DMMが9月28日にサービス開始したライブ配信アプリ「LIVEcommune（ライブコミューン）」。ライブを見ながらチャット感覚でコメントやプレゼントを送ったり、リアルタイムで配信者や他のユーザーと盛り上がることができます。
今回はこのライブ配信アプリ「LIVEcommune」の開発チームにどんな技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！
DMMが映像配信のノウハウを活かしたライブ配信アプリ「LIVEcommune」をリリース！
白石：まずは、「LIVEcommune」がどのようなアプリなのか教えてください。
植田：今回開発したアプリ「LIVEcommune」は、配信者と視聴者を繋ぐ生配信アプリです。配信者をプレゼントで応援したり、嬉しいことや面白いことを「LIVEcommune」を通じて共有できます！一般ユーザーがスマホアプリのカメラで配信し、それをスマホユーザーが見てチャットなどでコミュニケーションをとって楽しむライブ配信アプリです。さらに、オンライン上で盛り上がっていただくスタンプ・アイテムを提供しています。
ライブ配信アプリはもうすでにレッドオーシャンになっており、日本だけでなく、中国をはじめるとするアジアでも盛り上がっている市場です。「LIVEcommune」はスピード感を持ってまずはユーザにとって絶対に必要な基本機能を厳選して開発を行いました。戦略的な機能はこれから実装をしていくといったところですが、動画広告やコンテンツ配信など各社マネタイズに工夫しているようです。
▲株式会社DMM.comラボ 植田隼人さん /「LIVEcommune」の開発リーダー、システムの取りまとめをしている
白石：この開発には何人くらい携わっているんですか？
植田：開発時はエンジニア、デザイナー、ディレクターなど、事業推進責任者含めると最大20人でした。今は10人ちょっとくらい。メンバー構成としてはリーダー、開発メンバー、サーバーサイド、iOSエンジニア、Androidエンジニア、ディレクター、デザイナーですね。
山本：iOSはXcodeと、当時の最新であるSwift 3.1で開発しました。あと、MVVMというアーキテクチャを取り入れて、RxSwiftというデータバインディングできるライブラリを使いました。RxSwiftはデータのやりとりから、コントローラーからモデルの間にビューモデルがあって、データのやり取りを簡単にすることができるライブラリです。
▲株式会社DMM.comラボ 山本修平さん / 「LIVEcommune」ユニットリーダー、iOSアプリエンジニアを務める
杉野：僕がエンジニアチームと大きく関わったのは、ぬるぬる動くスタンプのアニメーションのところです。はじめの要求としては3～4カ月くらいでiOS、Android、Webに書き出せるものを作ってほしいという要望もあり、デザイナーだけで完結できるAirbnbが出したライブラリでLottieというのを使いました。
After EffectsからiOS、Android、Webにそのまま反映できるので、ぬるぬる動くアニメーションが実現できました。データはJSON形式にしてアプリの方に送り、アニメを再生するのはRottyを使ってiOS、Androidに吐き出しています。Web版はこれから開発予定です。新しいことに挑戦したいという気持ちもあって、楽しかったですね。
▲株式会社DMM.comラボ 杉野さん /「LIVEcommune」のUIデザインとコンセプトメイキング、技術選定を担当
ロゴが変化するデザイン、ダイナミック・アイデンティティにチャレンジ
白石：デザインやロゴはどうでしたか？
杉野：今回良かったのは開発スタートしたときに、コンセプトやどういうアプリにしようというのがなかったんですね。搭載する機能だけが決まっていた。でも、コンセプトがあった方が機能を作る上での方向性も決めやすいと思ったので、デザインはコンセプトメイキングから入りました。こちらも開発と並行だったけど楽しかった。
コンセプトは「いつでもどこでも一体感を共有」「アプリを開くと新しい発見」「リアルタイムコミュニケーション」。この3つをロゴに落とし込みました。communeの語源は、親しく交わるとかコミュニティ、コミュニケーションからきています。
白石：丸くもこもこしているところがユーザーが交わっているところなんですね。
杉野：ライブアプリなので、再生を想起させるものを作りました。決めるのに2カ月くらいかかりました(笑)。イベントやメディアによってロゴの形や色が変化するダイナミック・アイデンティティという新しい概念も、これから取り入れようとしています。
▲ダイナミックアイデンティティ以外にもロゴの別案(パターン)も複数案出し、検討していったとのこと
WebのフレームワークはLaravel、データベースはAmazon Aurora、KVSはRedis
中里：僕はアプリの中でWebViewを使っているところや、API周りを担当しました。
アプリの中でユーザーが貯めたポイントを現金やiTunesカードなどの景品と交換できるのですが、そのユーザー認証や銀行口座などの入力、景品交換をする一連のページをWebViewを使って開発しています。
▲株式会社DMM.comラボ 中里勇輝さん /「LIVEcommune」Web/APIの開発を担当
白石：なぜ、WebViewで開発しようと思ったんですか？
中里：今後Web版が出たときに共有できるし、DMMの共通機能も使いやすかったからですね。
白石：APIはどの辺を使ったんでしょう。
中里：最初にフレームワークどうしようという話になったときに候補に挙がったのが、Laravel, CakePHP, FuelPHP。どれを採用してもチームの中で全員が使ったことがあるのがなかったし、どうせ学習コストがかかるのなら海外ではメジャーなフレームワークを使ってみたい。ということで、更新頻度も多く、海外ではメジャーだったのでLaravelを選びました。
白石：基本的にはPHPを使っているとのことですが、PHP7になって結構変わりました？
中里：メソッドを作る時に、引数などの型を完全に指定できるようになりましたね。指定したものと違うクラスが来たら、エラーになります。
あと、今回はAWS上に誰でも用意されたコマンドを打てば簡単に開発環境が作れる仕組みを作りました。これまで人によってバージョンが違うと動かなかったりエラーが出たりなど、ローカルで開発環境を作ってはまることが多かったんですが、今回はそういうことがなく、全員同じ開発環境がコマンド１発で作ることができました。
白石：どういうコマンドなんですか？
中里：AWS上でインスタンスを作って、ansibleでPHPやMySQLをインストールして設定するとAWS上に個人環境ができるというものです。ローカルでソースコードを書いて、シンクさせます。元を変えたら全員の環境がアップデートされます。新しいメンバーが参加しても、開発環境の準備で時間を取られることがなくなりました。
白石：反映が遅いということはなかった？
中里：ないですね。すぐに反映されます。
白石：データベースは何を使ってるんですか？
中里：AWSのAmazon Auroraと、KVSはRedisを利用しています。
データ通信のサーバーはSocket.IOで実装、言語はGoを採用
田仲：視聴中のチャットなどのデータ通信は、Socket.IOを利用しており、言語はGoを使用しています。たいていのものはSocket.IOで通信していますが、認証やセキュリティ的要件が必要なものは一回APIサーバーを挟んで通信していますね。
▲株式会社DMM.comラボ 田仲祐介さん /「LIVEcommune」配信サーバー、インフラ周りを担当
白石：重要な方はAPIを挟むんですね。
田仲：視聴者が画面をタップするとハートを送ることができるのですが、これらのデータの信頼性がそこまで重要でないものは速度を重視して、Socket.IOで完結させています。
植田：ちなみに去年くらいから、プラットフォーム上で使う言語はGoを採用するようになってきました。エンジニアが使いたい言語をチームで話し合って決めているので、自由度は高いです。
配信サーバーはWowzaで構築、チャット用サーバーはRedisで運用
白石：DMMさんがもともと自社で持っている映像配信のイメージが強いですが、そのプラットフォームを活用したのでしょうか。
植田：そうですね。社内のインフラチームにはサーバーの基礎の構築だけお願いしました。サーバーにAPIサーバーなどはの特定の情報は持たないようにして、AMIによる構築とで構築することによってオートスケーリングを組み合わせることによって、と組み合わせて障害が起きた際の復旧をインスタンスを自動化することができました。
ログはAWSのElastic SearchとKibanaを使っていて、チャット用のサーバーはRedisで運用しています。
田仲：配信サーバーの方はWowzaという製品を使って構築していて、そちらはAWSではなく、オンプレで構築しています。Wowzaは映像配信のデファクトスタンダードと言われているもので、一部モジュールの方はJavaで開発しています。
AWS Lambdaも少し使っているところがあるんですけど、そこはNode,Ruby,Pythonを使っています。
白石：田仲さんはオールラウンダーですね！配信サーバーだけはオンプレなんですか？
田仲：配信サーバーは要求されるスペックが高く、AWSで試算してみたらランニングコストがかなり高かったので、オンプレで構築しました。
田仲：当初WebRTCの採用も検討したんですが、少人数のグループでの映像配信には向いていると思うのですが、不特定多数に配信するこのサービスでは負荷対策の問題がありました。現在は、RTMPとHLSという技術を組み合わせて使用しています。
配信サーバーのリリース時は、使われていない配信サーバーから順に停止して入れ替えていくんですが、たいていの場合は人力で1台ずつリリースしていると聞きます。そこを自動化したことで、人的なコストとリリースにかかる時間を抑えることができました。
白石：配信はロードバランシングできるんですか？
田仲：視聴という意味では、配信サーバーからHLS形式でクラウドフロンドのCDNをはさんでます。配信のインプットはロードバランサーをはさむのは困難なことと、一度に大量のアクセスが来るものでもないので、振分ロジックをAPIサーバーの方で実装しました。それにより、配信負荷が均等になるように振分されます。
白石：大量のトラフィックが発生する視聴側はHLSで負荷分散をするわけですね。
ユーザー数に合わせたサーバーや開発体制の構築を
白石：最後に、今後サービスや開発の課題でチャレンジしていきたいことを聞かせてください。
田仲：当初予定していた視聴者数などの要件定義に耐えられるような構築したのですが、サービス開始直後ということもあり、まだそこまで利用されていない状態です。今後は利用状況に応じてスケーリングすることにより、ランニングコストの調整をしていきたいなと考えています。
植田：今回のプロジェクトでは、開発手法としてスクラム開発を取り入れました。社内でスクラム開発が増えてきているという背景もありますが、一番の理由は定期的に成果物を確認し合い、手戻りをなくしたいからです。
スクラム開発をやるにあたって、本やネットで調べて手探りでやってみましたが、わからないことがたくさんあったんですね。開発が一旦落ち着いてきたので、今度はもっと正規なスクラム開発をやってみようと思っています。
白石：ちなみにプロジェクト管理のツールは何を使ってるんですか？
杉野：JIRAを使っています。ドキュメント管理はConfluenceやGoogle Docsですね。あとはホワイトボードも活用しています。誰がどんな業務を抱えているのか、目で見てわかりやすいので。
山本：機能ドリブンで開発をしてきましたが、リリースしてわかったことや、自分たちが実際にユーザー側に立って使って感じたことを改善していきたいですね。
白石：DMMさんはエンジニアがチームで話し合って技術剪定をしているので、新しい技術にもチャレンジしやすい環境があって楽しそうですね。今日は興味深い話をいろいろ語っていただき、ありがとうございました！
