Netflix、モノリシックな動画処理パイプラインをマイクロサービスプラットフォームで再構築した事例を紹介:開発者が伝えるマイクロサービスの利点
Netflixは公式エンジニアブログで、動画処理パイプラインをマイクロサービスで再構築した事例を紹介する記事を公開した。なぜ、動画処理パイプラインをマイクロサービスベースの新たなプラットフォームで再構築することに決めたのか、どのようにサービスを切り分けたのか、Netflixのビジネスに与えた影響などを紹介している。
Netflixは2024年1月11日(米国時間)に公式ブログで、動画処理パイプラインをマイクロサービスで再構築した事例を紹介する記事を公開した。
Netflixは2007年のストリーミングサービス開始とともに動画処理パイプラインの運用を開始しており、サービスの拡大に応じて以下のような機能を追加、拡張してきた。
- エンコーディングパイプラインを拡張し、4K、HDRの配信に対応(プレミアムサービスのサポートを可能に)
- 集中型リニアエンコーディングから分散型チャンクベースエンコーディングに移行。処理レイテンシが大幅に短縮され、システムの耐障害性が向上
- 制約のある専用インスタンスの使用から脱却し、リソース利用の効率化を実現
- タイトル単位やショット単位の最適化など、エンコーディングのイノベーションにより、NetflixユーザーのQoE(クオリティーオブエクスペリエンス)を改善
- スタジオのコンテンツシステムと統合し、パイプライン側でクリエイティブ側のメタデータを利用できるようにし、魅力的な会員体験を実現
- 従来のストリーミングと異なるレイテンシや耐障害性を必要とするスタジオ/コンテンツ開発に対応
Netflixは、継続的な成功を収めるためには、より堅牢(けんろう)で、柔軟で、機能豊富な動画処理パイプラインが不可欠と判断し、「Cosmos」と名付けられたマイクロサービスベースの次世代プラットフォーム上で、動画処理パイプラインの再構築に取り組み、移行を決めた。
モノリシックなアーキテクチャが新機能や有望なアイデアを妨げた
2014年に導入された「Reloaded」と名付けられた旧プラットフォームは、設計時にはスタジオパートナーから受け取った高品質のメディアファイル(メザニンファイルとも呼ばれる)をNetflixストリーミング用の圧縮アセットに変換するというユースケースに焦点を置く単一のモノリシックなシステムとして構築された。
だが、長年にわたって、さまざまなユースケースをサポートするように機能を拡張した結果、システムの複雑さが大幅に増加し、以下のような点で課題が生じた。
- 機能の結合:Reloadedは、複数のワーカーモジュールとオーケストレーションモジュールで構築されていた。新機能を開発する際には、機能の作成よりも拡張に労力がかかるようになった
- モノリシック構造:同じリポジトリ内に複数のモジュールが共存しているため、コードの分離ルールを見落としやすく、本来強固な境界となるべき箇所で意図しないコードの再利用が行われていた。これにより、開発速度が低下した。モジュールの密結合は、全モジュールを一緒にデプロイする必要がある状況を強制する形となった
- 長いリリースサイクル:デバッグやロールバックが困難な規模での共同デプロイは、本番環境のサービス停止に対する恐怖を増大させた。これを受けて「リリーストレイン」のアプローチを推進した。2週間ごとに全モジュールの「スナップショット」が取られ、「リリース候補」として昇格した。リリース候補は約2週間かけてテストされていた。したがって、修正したコードが本番環境に到達するまでに2〜4週間かかる可能性があった
こうした課題を受け、NetflixのCIS(Content Infrastructure and Solutions)チームとET(Encoding Technologies)チームは、Cosmosと名付けられた次世代プラットフォームの開発に着手した。Cosmosは、Reloadedの拡張性と安定性に加え、システムの柔軟性と機能開発の速度を大幅に向上させることを目的とした。
Cosmosはマイクロサービスアーキテクチャ、ワークフロー駆動設計、マイクロサービス単位のワークフローサポートなど、数々の機能を導入した。これらの機能を組み込むことで、CosmosはReloadedの欠点を補い、より柔軟でスケーラブルな開発者にとって有用な動画処理プラットフォームになったという。
モノリシックなシステムをどのようにマイクロサービスで分割したのか
マイクロサービスアーキテクチャの場合、システムは多数のきめ細かいサービスから構成される。そのため、最初にサービス境界の特定、定義付けに取り組んだ。例えば、Reloadedでは、動画エンコーディングモジュールは次の5つのステップに分かれていた。
- 入力された動画を小さなチャンクに分割する
- 各チャンクを独立してエンコードする
- 各チャンクの品質スコア(VMAF)を計算、評価する
- 全てのエンコードされたチャンクを単一のエンコードされた動画として構築する
- 全てのチャンクから品質スコアを集約する
チャンクの分割と品質スコアの計算は全く異なる機能を提供していたため、動画エンコーディングサービス(VES)と動画品質サービス(VQS)という2つのマイクロサービスに分割した。
上記のVESとVQSの例のような切り分けを進め、Cosmosの動画処理パイプラインにおいては、6つの動画サービスに分割した。このアプローチにより、モジュール性、保守性、システム全体の柔軟性が向上したという。
- 動画検査サービス(VIS)
- 複雑性分析サービス(CAS)
- ラダー生成サービス(LGS)
- 動画エンコーディングサービス
- 動画検証サービス(VVS)
- 動画品質サービス
また会員向けストリーミングとスタジオパートナーの個別のニーズに合わせてそれぞれの機能を調整する必要があるため、ストリーミングワークフローオーケストレーターとスタジオワークフローオーケストレーターという2つのワークフローオーケストレーターを構築した。
Netflixによると、2023年9月にCosmosの動画処理パイプラインに完全移行したとしている。
マイクロサービス移行の利点
Netflixは、Cosmosの利点として、特に新機能提供のしやすさを挙げている。その例として紹介したのが、Netflixが2022年11月に導入した広告付きプランだ。
「広告クリエイティブのフォーマットは、映画やテレビのメザニンファイルとは異なり、処理の要件も異なるなど、新たな課題が生じた。しかし、マイクロサービスアーキテクチャを採用したCosmosのモジュール性と開発者の生産性向上という利点を生かして、動画処理パイプラインを要件に適応させ、広告付きプランの展開を成功に導くことができた」と、Netflixは述べている。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 「Amazon Prime Video」が監視ツールをマイクロサービスからモノリスに移行 “やむにやまれぬ”理由とは?
Amazon.comは、同社が提供する「Amazon Prime Video」の監視ツールをマイクロサービスアーキテクチャからモノリシックなアーキテクチャに移行したと明らかにした。 - NetflixはKubernetes環境における「孤立したPod問題」にどう取り組んでいるのか
Kubernetes環境における孤立したPodとは何なのか。Netflixのエンジニアが孤立したPodの問題にどう取り組んでいるのか解説した。 - Netflix考案のテスト「カオスエンジニアリング」を探る――システムのあらゆる部分を“壊す”、そのメリットとは
海外の先進的企業の事例を基にテスト自動化に使われる手法を解説する本連載。第2回は、Netflixが考案したテスト手法「カオスエンジニアリング」について。