- これまでの納品から配信までのフロー
- エンコーダー刷新の機会がやってくる
- JIROが成し遂げた納品から配信までのフロー
- JIROが成し遂げたこと
- 皆が待ち望んだものがやっとできた！
- JIROのこれから
- まとめ
はじめましての人は、はじめまして。知っている人は、こんにちは。 配信基盤スクラムチームでプロダクトオーナーをやっている@yanoshiです。
さて、早いもので本稿は連載7本目です。目次記事はこちらです。
折り返しも過ぎたということで、こうして記事が揃ってくるとなかなか圧巻ですね。 嬉しいことに、近頃は社内外を問わず「連載読みました！」とか「〇〇の記事良かったです」と言われるようになってきました。わいわい。
さて、エンコーダーが速くなったぞ！
前回の記事で向山さんが紹介してくれましたが、びっくりするくらいエンコーダーが速くなりました。
「速くなった？ 何がよ？」
って話ですよね。それを簡単に説明したいと思います。
これまでの納品から配信までのフロー
皆さんは動画エンコードと聞いてどんなことを想像するでしょうか？
動画配信事業部はコンテンツホルダーではありません。 そのため、初めから手元に動画素材があるわけではありません。 様々なコンテンツホルダーから素材が納品され、それらを適切に加工し、最終的に「配信可能な状態」にする必要があります。
この工程を 「受領加工フェーズ」 と運用部門では呼んでいます。
1日数十本、納品される動画コンテンツに対して、ユーザーに不要な部分の削除や音ズレの解消等々の適切な編集処理を行っています。 また、納品形態も様々で、HDDやデータ転送サービスによるファイル納品はもちろんのこと、Blu-ray DiscやDVD、過去にはテープ素材で納品 されるものもありました。
このような理由から 受領加工の工程を完全に自動化することはほぼ不可能であり、人の手で素材を受け取り、適切な形に加工する必要があります。 これらの業務を行うチームとしてWEBサイト運営部 映像制作グループが存在します。 彼らによって動画サービスの配信コンテンツは支えられています。
上図中の「エンコード処理」と「パッケージング処理」に該当する部分は、私たちの前身となるチームなどで開発した「自動エンコーダー」と呼ばれる内製ツールにて行われていました。ちなみに、その多くは実は9本目の記事を書く予定になっている池田さんが開発したものだったりします。それも入社後4ヶ月目にして加賀に1ヶ月出張して仕様確認し、その後1年掛けて開発したという当時の弊社らしいエピソードがあります。*1これらのツールが、石川県加賀市に存在する事業所の一角に設置された自作PC群のうえで稼働していました。いろいろとアツいですよね。
しかしながら、これらのツールは各工程の要素のみを自動化するにとどまっていました。
池田さんがこれらのツールを作るまでは、そもそもエンコーダーすら自動化されておらず、「帰る前にエンコーダーを実行して、朝確認する」といったとても温もりのある運用でした。 なので、これらのツールも大変革命的だったと言えるでしょう。しかし、各工程で人がやっていた操作をそのまま自動化するにとどまっていました。
その結果、見て取れるように、その多くの工程に人の手が介在していました。例えば、ファイルのデータセンターへのアップロードも然りで、「どこにアップロードされたか」を記録するのも人の手で行われていました。 一部の作業はマクロツール等を使って自動化されていたものの、 その多くはWindowsにてGUI操作で行われていたため、それなりの労力が必要で、かつヒューマンエラーの危険性もありました。
そう、一言でいうと「大変」だったのです。
少し課題を列挙するだけで、いっぱい出てきます。
- エンコード時間はファイルの尺の長さに比例して増加
- エンコードの進捗はエンコードを行っているチームしか分からず、コンテンツホルダーから「いつ頃配信が開始できそう？」と問い合わせがあっても、一部のメンバーしか把握するすべがなく、返答に時間を要する
- エンコードタイミングが現場に任されているため、エンコードプログラムを気軽に更新できない
- エンコードパラメータも同様に変更しにくい
- ファイルの設置場所等の情報がモノリシックなレガシーシステムに結合しており、参照が容易ではない
- 上記の理由からファイル修正が必要あり、ストレージに上がっているファイルを取得するにも温もり運用
- エンコードマシンの多くがWindows 7であり、サポート期限が迫っていた
しかし、「課題いっぱいだから明日から刷新しよう！」とは簡単には言えません。
「複雑に絡み合ったシステム」「難解な業務フロー」「止められない業務」 等々気軽に刷新できない様々な理由がありました。
そんなことからなかなかこれまでエンコーダーに手を加えることができずにいました。 そして自動エンコーダーが開発されてから8年近くが経とうとしていました。
エンコーダー刷新の機会がやってくる
そんな時、エンコーダーを刷新する良い機会が舞い込んできました。 そうです。事業所統合です。
実は昨年、石川に点在していた多くの事業所が、一箇所に統合されました。 これまではエンジニア、コンテンツデータを扱うチーム、文字情報等のメタデータを扱うチーム、キャンペーンの設定やバナーの変更等のサイトの運営を行うチーム等々が、それぞれ異なる事業所にて業務を行っていました。 同じサービスに関わる業務を行っているにもかかわらず拠点がバラバラというのは効率が悪い…といった話は以前よりあったようで、他にも様々な理由が合わさった結果、統合計画が動き始めたようです。
当然、エンコード等を行ってくれている映像制作グループも事業所移転を行う予定でした。 しかしここで大きな問題が出てきます。 新しい事業所は敷地面積等の都合から、エンコードに利用しているPCを全台は持っていけないのです。
「これは困った。もうエンコーダーを刷新するしかない！」
さらに喜ばしいことに、タイミング良く周辺システムも揃いつつありました。
まず配信メタ情報を格納できるst-api が完成したことは大きな出来事でした。
DMM動画サービスの問題を解決しようとしている話（再生URL生成API編）
エンコードのワークフローをいじるうえで、モノリシックなレガシーシステムは大きな障壁でした。 元々のデータ管理の方法だと、過去の仕様を把握するのも大変でしたし、なおかつデータをいじると思いもしない箇所で障害を発生するリスクが有り、気軽にデータ変更が行えないという開発/運用上の障壁がありました。 これがst-apiの登場によって解決します。
DMM Player v2 の登場も重要です。
Electron製動画再生プレイヤー「DMM Player v2」
エンコーダーを刷新するうえでネックになっていたのがWMVの作成です。 当初からエンコーダーを刷新するなら、オンプレのデータセンター上で行いたいという話題が出ていたのですが、WMVの作成にはWindowsアプリケーションが必要であり、もしWMVを今後も作り続けるのであればWindows Sever上での稼働が必要不可欠でした。 しかしながら、開発コストやライセンスコストの面でこれはなるべく避けたいと考えていました。
DMM Player v2がリリースできればWMVファイルを作る必要はなくなるため、上記の障壁は一気に解決します。
さらにCMAFに準拠したマルチDRMな配信 の仕組みができたことによって、作るべきファイル数は半減しました。
あと、 新事業所の立地もデータセンターでのエンコードに適していました。 データセンターでエンコードするには、大容量の動画データを事業所から常に転送し続ける必要があります。当然太い回線が必要となります。 これまで映像制作グループが作業を行っていた事業所は少々辺鄙な場所にあり、大規模な専用線を敷設するにはコスト的に見合いませんでした。
しかし 新しい事業所はそのあたりの問題が解決されており、比較的大容量な回線が敷設可能 でした。
私たちのチーム以外のところでも重要なシステムが開発されました。業務工程やコンテンツのメタ情報を管理する CODAと言われるいわゆるCMS(Content Management System) が稼働を開始し、一部業務で利用され始めていました。 新しく開発するエンコーダーがこのCODAと組み合わされば、運用者はコンテンツのメタ情報を意識することなく、編集業務等に集中が可能です。
要は、機が熟していたわけですね。
まぁ、事業所移転の話題が出てきた時期には、すでにVR関連のエンコードがエンコード時間的に限界となりつつあり、 事業所移転がなくとも少しずつエンコーダーを刷新する予定ではありました。
しかし、事業所移転がきっかけとなって大きな前進を始められたのは事実です。
逆に言うと、事業所移転の計画が実行に向けて動き始めたことにより、 「引越し日までに新しいエンコーダーに移行していないと業務が停止する」と言うデッドラインができてしまいました。 これはプレッシャーですね。
とりあえずそんなこんなでエンコーダーを刷新するに至りました。 そしてJIROが生まれます。
JIROが成し遂げた納品から配信までのフロー
JIROによってこれまで抱えていた課題はほぼ全て解決しました。
コンテンツ編集作業が終われば、後はJIROに中間ファイルを投げ込むと全て自動でやってくれます。素敵ですね。
JIROが成し遂げたこと
では、JIROが何をもたらしたのか詳しく見ていくことにしましょう。
その1. 受領加工フェーズ全体の高速化
これまで行っていた多くの業務をシステマティックに自動化できました。
さらにオペレーションを行うツールもいい感じのものができました。
(こちらはDMM Player v2の記事を書いてくださった保月さん謹製)
もはや自明ですが、これによりかなりの業務効率向上を達成しています。
その2. 進捗の可視化
関係するチームのメンバー全員が管理画面を通してエンコードの進捗状況を確認できます。これで、コンテンツホルダーから問い合わせがあっても簡単に返答できます。
これまではエンジニアも進捗を確認することはできなかったのですが、JIROによりその状況は打破されました。 エラー等も可視化され、万が一問題が発生しても迅速に対応もできますし、事細かに一部工程の再実行もやり直すことができます。 素敵ですね。
こちらは以前インターン生の鵜重さんが開発してくれたものに、 10本目の記事を書いてくれる予定の小田さんがJIROに関する機能を追加実装しました。
その3. 垂直統合されたファイル管理
JIROによって得られた大きなアウトプットにmounterがあります。 私たちの配信基盤には20を超えるストレージクラスタが存在しており、構築した世代によってGlusterFSやScality RINGといった様々なオブジェクトストレージがあります。
mounterではこれらのあらゆるストレージへのアクセスができ、st-api等と連携して「どのストレージに格納されているか」を鑑みたうえでファイル操作が可能です。便利！
私たちのシステムには、公開前にファイルアクセスができないよう、ファイルシステムを用いたセキュリティの仕組みがあるのですが、公開に合わせてそれらを解除する必要があります。 何らかの理由で公開前に動作確認する必要があった時、これまでは実際にストレージに潜ってファイルシステムを操作する必要がありました。 これはセキュリティのリスクもあるとともに、オペレーションミスの可能性もありました。
しかしmounterの完成によって、mounterのAPIからこれらのオペレーションが可能となり、Rundeck等のジョブスケジューラから権限のある人ならこれらの作業を実行できるようになりました。 安全、簡単、便利ですね。
(こちらはVODSTの記事やmlicの記事を書いてくださったまさきさん謹製です)
その4. 爆速エンコード
私たちのシステムでは、納品された素材から現状2Dコンテンツは最大9種類、VRは最大16種類のファイルを生成しています。
これはABRを行うためであったり、デバイスごとのデコード能力の差異を吸収するために行っています。 ちょうど先日私がDMM meetup #15 コンテンツ配信を支える技術にて登壇したスライドがあるので、こちらを参照いただくと分かりやすいかもしれません。
当然恐ろしいほど時間がかかり、これまではVRコンテンツにおいてエンコードだけでも10日近くかかってしまうこともありました。
これが1日程度で終了するようになったので、かなり大きな進歩です。
(上記例では実は優先度設定はしていないため、仮に優先的に他のエンコードキューを押しのけてエンコードした場合はさらに速く結果が得られます)
私たちのサービスでは、定期的に半額キャンペーンが行われるのですが、その前には駆け込みで大量のコンテンツ納品があります。 昨年の12月にそういった駆け込みの納品があり、合計16134時間にも及ぶコンテンツが納品されましたが、無事エンコードを捌くことができました！
その5. 低コスト
大きなリソースを要するエンコードを行っているため、工夫をしなければ計算リソースでとてもコストが掛かってしまいます。
しかし、JIROでは配信サーバーの余剰リソースを用いてエンコードを行っています。 例えばストレージサーバーや配信のオリジンサーバー(≠キャッシュサーバー)は、I/O負荷は高いもののCPU負荷はそこまでではありません。 こういったサーバーでも、サーバー購入の性質上(まとめて買ったほうが安い)、それなりに良いCPUを搭載したサーバーが用いられています。
これらのサーバーの余剰リソースを上手く活用しています。 その結果JIRO専用に用意したサーバーは、エンコード規模から考えるととても少ない台数で済みました。
余剰リソースを用いているためコスト計算は難しいのですが、 各マネージドなクラウドエンコーダーと比較すると数十分の1程度のコストでエンコードが実現されています。
皆が待ち望んだものがやっとできた！
さて、ここまで見ていただいたように、たくさんの周辺要素がきれいに揃った結果、やっと実現に至ったのがJIROです。
私たちのチームは、様々な尖ったスキルを持ったメンバーが集っており、「一つのシステムをみんなで作る」という機会が実はこれまであまりありませんでした。 JIROはまさしく総力戦で、チームメンバー全員が何かしらのコミットを行った大規模プロジェクトだったように思っています。 副次的効果ですが、チームの結束が更に深まったようにプロダクトオーナーとしても感じています。
私たちのチームは結成されてから、もうすぐ丸3年になります。 私はこのチームが結成される際に異動してきたのですが、その頃から皆で「エンコードを効率化したいよね」とか「配信関連のメタ情報を分離したいよね」といった話をしていました。今思い返せば懐かしいものです。
その頃からコツコツ仕込んできたものがようやく実を結んだ…それがJIROなのです。
JIROのこれから
JIROがもたらしたものは大きいですが、まだワークフローをJIROに切り替えたに過ぎず、その真価はまだ完全には発揮されていません。
今後は 得られたエンコードパワーを上手く活用し、画質向上やさらなる高解像度化等々、ユーザー体験が向上するような取り組みを加速 させていきたいと思います。
また、このシステムは動画サービスにロックインしておらず、他のサービスはもちろん更にはSaaSのような形で外部に提供することも可能だと考えています。*2 夢は広がりますね。
まとめ
チームそして私の夢でもあったイケてるエンコーダーがついに完成しました。
ただ、これはゴールではなくスタートだと考えています。 この力を大いに発揮してユーザーに価値を提供していこうと思っておりますので、今後とも私たちのサービスをどうぞよろしくおねがいします。
ちなみに次回記事では、 八田さんがエンコーダー部分をもっと掘り下げて、ffmpegやx264に関する知見を紹介してくれます。 乞うご期待！
（*1:池田さんはWebフロントエンジニアで採用されていたはずが、録画サーバー沼の人だったが故にアサインされたという面白い経緯）
（*2:もしご興味がある方がいらっしゃれば、是非ご一報ください！）
