音楽サービスエンジニアmeetup Vol.3 開催レポート

はじめに

こんにちは、Wano株式会社のエンジニアの成川と申します。
弊社では、大好評だった前回前々回のイベントに引き続き、今回は弊社オフィスにて、第3回の音楽エンジニアmeetupを主催いたしました。

このイベントレポートは、あくまで僕個人やいちWanoのエンジニア視点でのレポートとなります。ご了承ください。

今回は、会場からの質問を匿名で集め、発表スクリーンにコメントが流せるサービスcommentscreenを使ってみたのでので、その使用した感想もまとめていければと思います。
⬇︎このサービスを利用した実際の発表の様子。(ニコニコ動画世代にはめちゃくちゃ刺さるサービスや。。。)

前回使用したsli.doは一旦クビになりました。

前々回のイベントレポはこちら
前回のイベントレポはこちら
第3回のイベント詳細はこちら

誰向けのイベントなのか

• 音楽やそれに付随するカルチャーが好きな方
• 音楽サービスの裏側のシステムってどうなってるんだろうという方
• 今まで音楽などの趣味を仕事と別で考えていたけど、カルチャーに関わる仕事がしてみたい方

エンジニアだけではなく、音楽やカルチャー好き全ての方にオススメのイベントです。

イベントの流れ

• まずWanoの簡単な紹介
• Wanoグループ社員によるセッション×3
  
• 懇親会

まずWanoグループの簡単な紹介

Wanoグループ社員によるセッション

一人目　Yuya Yamamoto from TuneCore Japan　「アーティスト同士でお金を配分できる機能を作った話」

発表資料: アーティスト同士でお金を配分できる機能を作った話
彼はTuneCore Japanで、主にプロダクトマネージメント・マーケティングを担当しています。

発表概要

• 今年リリースされた「Split機能」という、アーティスト間で収益分配を設定できる機能の開発裏話について
• なぜこの機能を作ったのか
  • ユーザーとの会話の中でニーズがあった
  • 共作やチームで活動することが増えてきており、音楽活動の方法に選択肢が増えるのは、作品作りやカルチャーにおいて重要
• 発生した問題とその解決策
  • ユーザビリティ
    • シェアの設定を楽曲ごとの設定面倒 -> 設定コピペを可能に
    • スプリットの承認フローが煩雑になりそう -> メアドのみに限定
  • バックエンド
    • 1楽曲１アカウントが結びつく構造の変更 -> メタコピーは更新が大変になるのでデータの参照をアカウントをまたいで行えるように変更
• ユーザーの反応
  • コラボ、チームでやる時代にマッチしていて良いという声多数
  • 編曲者、トラックメーカーにはかなり朗報な機能

感想

• 弊グループ内でも、この機能の話は是非聞きたいという声が多く、弊社内での知見の共有という意味でも有益だったと思います
• マネージャー・マーケッターならではの視点も多く、これからもエンジニアだけでなく彼のようなロールの方の話も聞ける場であると良いと思います
  • ユーザーの根本的な課題を認識する姿勢(ユーザーとの会話の中での発見し落とし込む)
  • きちんとユーザーの反応がSNSから拾えているのも良い
• デフォルトの配分レートの設定とかこれからできると良さそうだなと思いました(コピペも５０曲とかになったらしんどそう)

二人目　宿本 真吾 from TuneCore Japan　「楽曲シェア機能のパフォーマンス改善」

発表資料: 楽曲シェア機能のパフォーマンス改善
彼はTuneCore Japanのシステムを担当しているエンジニアです。

発表概要

• LinkCoreという楽曲シェア機能でのパフォーマンスを改善したという話
• LinkCoreとは
  • 各配信ストアのURLが一括シェア可能
  • 誰がどのストアで等の統計データを閲覧可能
• どんな問題が起きたのか
  • 配信開始し、アーティストがSNSでリンクを拡散した瞬間に、AppサーバーのCPU利用率がMAX
  • 現状のCDN/AMP/DBキャッシュでは対応できなかった
• どう解決したか
  • 一時的にページ表示に関してはHTMLをファイルへキャッシュ（GET)、統計データの一時保存先をDBからファイルへ（POST)
  • 言語をPerlからGoへ
  • 結果、実装変更でGET4倍、POST１〜２倍/言語変更でGET１９倍、POST7~9倍 ->最終的にGET78倍、POST１１倍の改善！！

感想

• LinkCoreという機能に関しても、社内で知りたい人が多かった機能なので皆興味深く聞いている様子でした
• 処理速度に関してはやっぱりGoはすごい
• きちんとベンチマークを出して比較していて良い
• DBとファイルGET/POST比較は、Redisなどのオンメモリキャッシュも加えて検討すると良いかもしれないですね
• サーバーのオートスケールも検証すると良いかもしれない
• Goはいい言語だが、正規表現など弱い部分もあるので、適材適所で使っていければ良いと思いました
• VideoKicks（動画納品サービス)でも同様の機能要望が出ているので、その際の知見として有益でよかったです

三人目 Kryslov Leonid from Wano株式会社 「AWS S3のコスト最適化」

発表資料:AWS S3のコスト最適化
彼はVideoKicksのシステムを担当しているエンジニアです。

発表概要

• VideoKicksで取り扱っている動画のストレージコストを下げる施策について
• AWS S3 Deep Archiveを使用
  • ファイルの取り出しは手動なら12h以内、自動なら48h以内
  • Standard Classは$24/Tbに対して、Deep Archiveは$1/Tb
• 全体フローのステップ/システム構成
  • 1.ファイルのアーカイブ -> 2.納品側から取り出し依頼(配信ストアの追加が多い) -> 48h後 -> 3.納品側へ取り出し完了通知 -> 4.納品プロセス開始

• 結果どれくらいコストを削減できたか
  • 対象ファイルは全体の55%、コスト４割削減に成功！！
• 将来的にどうしていきたいか
  • S3 Intelligent-Tieringなどを検討し、より最適化していく

感想

• 私のチームの涙ぐましい動画ストレージコスト削減のお話
• 彼はロシア出身。ネイティブ並みに日本語が上手い。かつ英語もペラペラ(あるUSプロジェクトで非常にお世話になっている。。)
• 2日がかりの、壮大なピタゴラは圧巻です
  
• また、大きいサイズのファイルを転送する際は、マルチパートアップロードが必須だったりで、ファイルの正常性担保が非常に大変そうでした(E-tag、md5周り)

懇親会

僕は参加できなかったのですが、前回前々回同様好きな音楽や音楽系サービスの話で盛り上がったようです！
また、遠方の方でvol.1から気になってたけどなかなか遠くて行けなかったと言う方が、仕事でこちらに来ている都合で今回参加できたようで、社員一同vol.3まで続けていてよかったなと思いました。
また、ストレージや言語の話(Perl,Go)の話でセッション以上の内容を共有できたようで、非常に有意義な時間を過ごせたようです。

commentscreenを使用してみての所感

良かった点

• sli.doと比べて、別にスクリーンを用意しなくていいので手軽
• 発表者が自分で質問を途中で拾えたりもする

悪かった点

• 意外と発表者から、質問が見えづらくて拾いづらい
• 後から質問の時間を設けても、質問がプールされていないのでまた質問させることになってしまう
  • ファシリテーターが質問を拾っておくことで、ここは次回以降解決できそう

終わりに

第三回ということもあって、前回の課題であった簡単な弊社サービス紹介動画によるイベント開始前の手持ち無沙汰の解消や、アンケートの収集なども解決できてイベントとして洗練されてきた感じを受けました。また、前回も前々回も参加してくださった方なども見受けられ、リピーターが獲得できているのはとてもいい傾向だと思います。参加者の皆さん本当にこの師走で忙しい中参加していただきありがとうございました！

また、非エンジニアの方の登壇＋commentscreenの投入という新しい挑戦もでき、どんどんといいイベントになっているのは間違い無いと思います。

しかし、このまま同じトピックで続けていても、開催側も参加側もマンネリ化してしまうのでは無いか、という意見が振り返りの場で出たということもあり、次回は少しトピックを限定したり（クラウド特集、Go特集etc)でテーマ自体をガラリと変化させる必要があると感じたので、次回以降はそういった試みに挑戦するやもしれません！

また次回以降も開催していきますので、ご興味のある方は是非、connpassで
Wanoグループのメンバーになって告知を待っていただければと思います。

ではまた次回、あなたとお会いできるのを楽しみにしております！