より良い視聴体験を求めて、ニコニコ動画の配信基盤刷新の舞台裏

もりこ

2024年7月16日 02:30

2024年3月に移行完了

配信基盤とは？

旧基盤の課題

2016年から運用

インフラは100％オンプレ
→開発と運用で問題を抱えるようになった

開発の難しさ

動画と放送で要求が違うから有効活用ができる（と思ってた）
→意図通りにいかない

複雑化してメンテが大変になった
モノリシックに拍車がかかった
効率の悪化

運用の難しさ

1000台を超えるクラスター運用が難しい
- アプリ更新時、新旧バージョン混在でも稼働し続ける必要性
- ホスト故障の対応

デプロイが難しい
- 生放送中の変換中は処理を止めることができない
- 放送終了を待つなどの複雑な手順が必要

→この影響で動画機能の更新が行えないケースが発生

デプロイの仕組みが難しい
- Ansibleを使っていて、複雑なアプリ構成に対応するための複雑なデプロイの仕組みやスクリプトを組み合わせるのてメンテコストが大変

→アプリケーションの更新が月1回しか行えない

オンプレである事による制約

ピーク負荷に合わせた機材購入が必要
非効率な機材利用率
- 機材が遊んでいる時間が結構発生していた
機材量を超える突発的なアクセス増に対応できない
- スポットで機材が増やせず機会損失に

→コスト的な無駄と機会損失を招いていた
→改善が進めようと頑張っていたが、頭を悩めていた
→稼働中のシステム構成を変えるのは非常に難しい

クラウドを利用して刷新

クラウドネイティブなアーキテクチャによる新規開発
これまでの動画配信の知見を最大限に活用

→刷新により全ての課題の解消を目指す

旧配信基盤をそのままクラウドで動かす道も選択肢としてはあったが不採用

刷新と課題の解決

開発の難しさの解決

分散してシステムの複雑化を抑えるのを期待
マイクロサービスにして単純化を図った
システムの単純化

→リソースの削減が特に効いた

運用の難しさの解決

Ansibleでオンプレに直接アプリをデプロイしていた
→マネージドにすることによって、手間と時間がかなり削減できた

オンプレである事による制約の解決

コスト最適化でも大きな利点があった

現在のアーキテクチャ（ブレブレですみません・・・）

アーキテクチャ検討とコスト試算

刷新後の費用を見積もらないと移行を決定できない

旧配信基盤より高くなってはいけない
むしろコストダウンを行いたい

新規開発なので設計と同時に費用試算を行う必要がある

むずかしい・・・

仮アーキテクチャの設計

クラウド技術を採用した新しいアーキテクチャを設計
PoC実装を行い、必要な機能が実現できるかを確認

仮アーキテクチャ基づくコスト試算

運用ちゅうの配信基盤から取得した計測データを当てはめて試算
オンプレとクラウドでコスト構造が大きく異なるので難しい
100以上の項目に細分化して試算
- 統計データを参考にしながら計算した
コスト構造
- 送信帯域（オンプレ）と送信データ料（クラウド）

アーキテクチャ正式決定とそれに基づくコスト試算
そして開発へ・・・

コスト試算は本当に難しい

試算結果に不安を感じながらの作業だった
アマゾンウェブサービスジャパン合同会社による支援でクリアできた

技術的な挑戦

チームは旧配信基盤の開発・運用メンバーを中心に構成

初めてのクラウドネイティブ開発
初めてのk8s運用
Go言語を利用した初めての本格的な開発

→技術スタックがなかった
→キャッチアップと設計・開発を同時に進行した

当初は手探りで不安なシーンが多々あった

複数の施策で解決

AWS社内勉強会
メンバー全員での設計共有会
アマゾンウェブサービスジャパン合同会社による支援

既存動画のマイグレーション

処理時間のほとんどをディスクI/Oに振れた

ユーザー体験の改善

旧基盤では対応が難しかった
→制約がかなり引きずっていた

動画取得速度の改善とIPv6対応

CloudFrontを採用
- 高速なデータ転送によりバッファリング速度が改善
- 簡単にIPv6対応が行えた

エコノミータイムの廃止

ピークタイムの負荷を抑えるための機能
- 一般会員は360pまでの視聴に制限
- 有料のプレミアム会員は常時1080pで視聴が可能

→2024/3/1に廃止
→無料会員でも常時720pまで視聴が可能に

クラウド化することで廃止が可能に

1080p動画尺制限の廃止

動画尺によって画質に制限があった
- 30分以上の動画は360pまでの変換・視聴に制限される

→2023/12/4に廃止
→動画尺によらず1080pのフルHD画質が利用可能になった