DMM meetup #25 ～動画配信事業部のシステムカイゼン実録～

に参加してきたので、そのときのレポート

事業部紹介からのはじまりの軌跡

動画サービスが、DMM において最初期に作られたサービスである

つまり、レガシーな状態がある。

2017 年

社長が変わって、プロダクトファーストな文化になった。

ある日、動画事業部で EC をやってくれと言われた。

メンバー全員で、ユーザは何に困っているのかを考えた。

仕組みを作ることで、他事業も高速に事業を成長させられるようにしようとなった。

これまでのKAIZEN紹介

開発プロセスの改善

以前の環境

LAMP 環境
CVS
本番デプロイは rsync

開発環境が使いづらい

クラウド上に環境をつくることで、自由に利用できるようにした
環境構成をコード化して属人化を解消
常に最新に環境を保てるようにした

バージョン管理に難あり

git, github の導入
ブランチ運用の整理をした
レビュー効率も上がった

ロールバックが大変

以前までは

巻き戻した状態で再コミット -> 再度 rsync
対象ファイルが多いと大変

今では

commit を revert するだけで OK

異常に気付きにくく、調査もしづらい

以前までは

数百台のサーバーがそれぞれにログを吐いている
サーバーメトリクスもとっていない

今は

ログはクラウド保存
メトリクスも取れる
通知を slack に飛ばすようにした

動画ECサービスのリプレイスを目指して(仮)

DMM 動画について

国内トップクラスの作品数を誇る動画配信サービス

現在のシステム構成

LB -> WebServer -> DB

という構成

WebServer は事業部毎にサーバーが分かれている

LB からの応答のみするサーバー
LB からの応答も受けるし、DB 接続もするサーバー

の種類がある

システムの課題

最初期から運用されているシステムのため、仕様を把握し切れていない状態
アーキテクチャが定まっていないため、機能追加に時間がかかる

システムの改善内容

少しずつ修正するのは大変（どこで障害が起こるか分からない）だったので、

リプレイスをしようとなった。

API の刷新
フロントエンドの刷新
DB スキーマ最適化、バージョン更新、クラウド化

API の刷新の進め方

マイクロサービスアーキテクチャを採用

マルチモジュールを利用したプレイヤー共通化作戦

Android アプリの話

アプリについて

視聴機能だけのアプリ（playstore）
ストア機能付きのアプリ

この 2 つはソースコードは別々なため、機能追加の際に工数がかかる。

ソースセット共通化アセット

共通の機能については、共通ソースセット内に作る

昔は、app モジュールに全機能があり、密結合していた

今は、マルチモジュール化している

画面・機能毎に分割

新卒一年目のエンジニアもKAIZENしてみた！

動画の分析を、先輩に相談しながら進めていた。

リモートワークでコミュニケーションがとりづらかった。

そこで、動画分析をするツールを自分で作った。

結果、早く仕事を終わらせることができた。