自社でのHLSパイプライン再構築：TwelveLabsはどのようにして高コストな再生ボトルネックを解消したか

「ビデオインテリジェンス」と聞いて人々が思い浮かべるのは、モデルのトレーニングや検索のクオリティであることがよくあります。しかし実際には、ユーザーエクスペリエンスは、結果が読み込まれている間に、生のビデオを実際に視聴、早送り・巻き戻し、そして検証できる状態へと変換する、地味なインフラストラクチャに大きく依存しています。

この投稿は、そうした地味なシステムの1つである HLS 生成 についてのストーリーです。これは、新しくアップロードされたビデオを、ブラウザで即座に再生できるセグメント化されたストリーミング形式に変換するプロセスです。HLS（HTTP Live Streaming）は、多数の小さなメディアセグメントを指し示すプレイリスト（一般的には .m3u8）を使用してメディアを配信するため、プレイヤーは素早く起動し、ネットワーク状況に適応し、効率的にシークすることができます。

昨年、私たちは痛烈な不一致に直面しました。当社のインデックス作成パイプラインは極めて高速になった一方で、再生用ストリーミングパイプライン（当初はマネージドサードパーティのトランスコーディングサービスに外部委託していました）は、比較して遅く、コストもますます高くなっていました。その結果、インデックス作成は終わっているのに、HLS生成がまだ実行中であるために、ユーザーがPlaygroundで実際にビデオを視聴できないという、製品として混乱を招く状況が発生してしまいました。

そこで、私たちはこれを再構築しました。

1 - 無視できなかったボトルネック

契機は単純なものでした。昨年、Marengo 3.0 においてより長いビデオ（以前は約2時間、最大4時間まで）のサポートをリリースしたところ、古い制限が突如として無視できなくなりました。長いアップロードの場合、再生の準備がインデックス作成よりも大幅に遅れることがあり、フラストラクチャを伴う製品ギャップが生じました。システムはすでにビデオを理解できているのに、ブラウザではまだスムーズに再生できないのです。この不一致は、外部的にも内部的にも現れました。ユーザーは再生準備が整う前に検索結果を見ることができてしまい、また社内チームもインデックス作成が終われば当然「完了」したような体験になると期待していました。

2 - 自社構築か購入か：なぜベンダーのパイプラインから移行したのか

私たちはすぐにパイプラインの自社再構築を決めたわけではありません。そのステップを踏む前に、ベンダーの高速化モードでそのギャップを十分に埋められるかどうかをテストしました。

評価の結果、高速化によって処理能力は標準設定と比較して約3.9倍に向上しました。しかし、それでも私たちが目指していた製品体験には届きませんでした。

また、価格も高くなりました。高速化ルートにはより高価な枠が必要であり、当社の分析では、標準設定よりも約60%コストがかさむことが判明しました。

そのため、高速化によってパフォーマンスは改善したものの、根本的なトレードオフは変わりませんでした。既存のルートを改善はしてくれましたが、長期的な解決策となるほど十分に（かつ安価に）優れてはいなかったのです。

したがって、私たちの決定は、以下に示す3つの制約によって方向づけられました。

• パフォーマンス：ユーザーエクスペリエンスを妨げているのは、インデックス作成ではなくHLSであったこと。

• コスト：外部委託のパイプラインが無視できない月次コストとなり、さらに増加傾向にあったこと。

• 将来の要件：オンプレミス展開をサポートしたいと考えており、主要な再生インフラを特定のクラウドベンダーに依存していると、その方向性が難しくなること。

最後のポイントは些細なように見えて重要です。オンプレミスのエアーギャップ（隔離）環境へのデプロイでは、「自分たちで何を実行できるか」に特化して最適化し、マネージドクラウドサービスを必要とする依存関係を減らす必要があります。私たちのチームはすでに、中核となる非同期インフラを Kubernetes や制限された環境で実行できるプリミティブへと移行させていました。

インハウス（自社製）のHLSパイプラインは、この戦略的方向に合致していました。

3 - 構築したもの：実用的で拡張性の高いHLSパイプライン

アーキテクチャに手を加える前に、基本的なことを検証する必要がありました。それは、生のFFmpegトランスコーディングを十分に高速化できるか、ということです。

通常、HLS出力には、メディアをセグメント化し、それらのセグメントを参照するプレイリストファイルを作成することが含まれます。FFmpegには、この目的のための専用のHLSマルチプレクサ（muxer）さえ用意されています。

しかし、要件はパフォーマンスだけではありませんでした。私たちは、以下のようなシステムを必要としていました。

• 大規模に継続して稼働すること

• 既存のアップロード → 取り込み → インデックス作成のワークフローに統合できること

• 現実のビデオ入力が想定から外れた場合に、安全に障害処理（再試行、アラート、トリアージ）が行えること

最初の設計提案では、FFmpegを使用し、キュー駆動型のワーカーフリートを備えたシンプルな「HLS変換サービス」を自社構築するというアプローチを正式化しました。

3.1 - 包括的なフロー

大まかなアーキテクチャは以下のようになります。

図1：ビデオの取り込みは、2つの独立したパスに分岐します。理解パイプラインは検索可能な表現を生成し、再生パイプラインはストリーミング用のHLSセグメントを準備します。これらのパスは目的において切り離されていますが、同じ入力を共有しているため、再生におけるいかなる非効率性も、製品のボトルネックとして直接表面化します。

1. Redisベースのキューに「変換タスク」を生成し、完了メッセージを消費してジョブの状態を更新するバックエンドオーケストレーターサービス。

2. 変換タスクと完了シグナル（SUCCEEDED/FAILED）用の個別のストリームを備え、ジョブキューとメッセージブローカーの両方として使用されるRedis。

3. FFmpegを実行し、HLSセグメントとプレイリストを書き込み、結果をストレージにアップロードするように設計された「HLSコンバーターポッド」としてのワーカー。

3.2 - オートスケーリング

エンコードのワークロードには波があります。デモデイやモデルの展開により、「再生可能にする必要のあるビデオ」が突如として急増することがあります。私たちは、常に稼働し続けるHLSフリートを過剰にプロビジョニングしたくはありませんでした。

そのため、（Redisを含む）イベントソースに基づいてワークロードをスケーリングできるKubernetesイベント駆動型オートスケーラーであるKEDAを利用し、ワーカー数とキューのダイナミクスを紐付けました。

また、顧客間での公平な利用を保証し、ノイジーマイノリティ（近隣のノイズ）問題を克服するため、キューのメッセージは異なる顧客に分散されるように生成されます。

3.3 - 信頼性

HLSを外部委託しても障害が消え去るわけではありません。単に障害を外部化しているだけです。自社内に取り込むということは、最後の1マイルの信頼性に責任を持つことを意味していました。

私たちは最初から、フォールトトレランス（耐障害性）を計画に組み込んでいました。

• バックオフを伴う失敗時の再試行

• 「有害なジョブ（Poison Job）」用のデッドレターキュー

• および、サポートチームやエンジニアが迅速にデバッグできるようにするための、明確なエラー報告とオブザーバビリティ（観察可能性）

それでもやはり、インシデントは発生しました。インシデントログの例では、社内ユーザーから「HLSがいつまでも終わらない」という報告があり、根本原因を調査したところ、自社製のHLSコンシューマーが期待通りにリクエストを処理していなかった（“hls task is never activated”）ことが判明しました。

このシステムを所有することで、以前は「タダ」で手に入っていた運用力を、自ら鍛える必要に迫られました。

• ハンドラー開始時のログ記録の改善

• コンシューマーの健全性に関するアラート監視範囲の拡大

• キューに入れられた処理が気付かれずに停止しないための、より確実な保証

結果として、私たちはタイムアウトを減らすために、cronjobによるコンシューマーのクリーンアップやハートビートメカニズムといった、具体的な信頼性向上のプラクティスを採用しました。

4 - 本当の高速化は「FFmpegのフラグ設定」によるものではなかった

図2：FFmpegはパイプラインにおける1つのステージに過ぎません。エンドツーエンドの遅延は、むしろビデオがシステム内をどのように移動するかによって左右されます。すなわち、ワーカーへのデータの取り込み（ストリーム配信かダウンロードか）、ディスクI/Oと中間書き込み、そしてストレージへのセグメントのアップロードです。エンコーダーのフラグではなく、これら境界部分の最適化こそが実質的な処理能力向上をもたらします。

ビデオパイプラインに関する一般的な誤解として、パフォーマンスは主に「適切なFFmpegコマンド」を選択することにかかっている、というものがあります。実際には、大幅な向上はFFmpegの周囲のすべてから得られることが多いのです。

私たちの場合、最初から目標値に達したわけではなく、解決すべきボトルネックには、ワーカーへのビデオの移動、ディスクI/O、中間書き込み、そしてCPUとGPUの選択に関するベンチマークなどが含まれていました。

以下は、重要となった設計上の選択肢です。

4.1 - ソースをストリーミングするか、事前にダウンロードするか

ワーカーにビデオを取り込むことは、一見簡単そうに思えます。しかし、大容量のアップロードを大規模に行うとなると話は別です。

実際には、ハイブリッドな取得戦略を採用しています。ファイルサイズと実行時のヒューリスティクスに応じて、ワーカーは署名付きURLからストリーミングするか、ローカルにアセットをダウンロードします。これにより、大容量アップロード時の不要なデータ移動を避けつつ、小規模なジョブをシンプルかつ効率的に処理できます。

4.2 - セグメントの並列アップロード

HLS出力は多数のファイルで構成されます。再生時間とセグメントサイズに応じて、1つのプレイリストと、数百から数千のセグメントが存在します。

そのため、アップロードの挙動が重要になります。特にワーカーがエンコードを終えた後にアップロードをシリアル（直列）に実行していると、セグメントアップロードの並列性が、エンドツーエンドの「再生可能になるまでの時間」に直接関わる主要因になります。

私たちは、パイプラインを「エンコード ＋ パッケージング ＋ 送信」として包括的に扱いました。

4.3 - ローカルNVMeとディスクI/Oの現実

中間出力（および最終的なHLSセグメント）をディスクに書き込む際、ストレージの処理能力がクリティカルパスの一部になります。巨大なHLS出力を伴う多数のビデオを処理するワークロードにおいて、単純なEBSベースのディスクI/Oは驚くほど深刻なボトルネックとなりました。CPUやメモリには余裕があるにもかかわらず、ストレージが原因でパイプラインが停止してしまっていたのです。

そのため、私たちは意図的にローカルNVMeを選択しました。これは、EKSで高スループットなノードローカルストレージを使用できるようにするための、これまでの社内プラットフォームでの取り組みをベースにしています。実質的に、これによりシステムはメディアパイプラインが本当に必要とする書き込みおよびパッケージング速度を維持できるようになりました。

5 - 結果：より速く、より安く、よりデプロイしやすいパイプラインに

図3：個別のエンコード手順ではなく、データの移動を中心にシステムを再設計することで、パイプラインは3つの具体的な改善を達成しました。再生開始時間の短縮、インフラコストの削減、そしてデプロイの柔軟性の向上です。その結果、ビデオのボリュームに応じて拡張し、ボトルネックにならない再生システムが実現しました。

私たちは、「再生可能になるまでの時間」、コスト、そしてベンチマークとなるベンダーの機能に追いついているかどうかで成功を測定しました。

5.1 - パフォーマンス

以前のパイプラインと比較して、平均処理速度は約6.6倍向上し、長いビデオを再生可能にするまでの時間が、1時間以上からわずか数分に短縮されました。

私たちは今でも下流のボトルネックを追跡していますが（製品体験は決して1つの数字だけで表せるものではないため）、最も苦痛であった「インデックス完了、再生未準備」という混乱を解消するには十分な成果でした。

5.2 - コスト

以前のマネージド構成を基準にすると、HLS準備のコンピューティングコストは、ビデオ1時間あたり約 0.045ドルから0.006ドル へと下がり、約87%の削減となりました。ストレージ費用を考慮しても、自社製のパイプラインの方が劇的に安価なままでした。

5.3 - 将来の要件

HLSを自社構築することのメリットは、スピードとコストだけではありません。将来のデプロイモデルとの互換性も重要です。

私たちは、エアーギャップ（隔離）された環境で動作し、オンプレミス展開における運用オーバーヘッドを削減できるインフラの選択肢に積極的に投資しています。

自社製のHLSパイプラインは、このパターンに合致します。外部依存を減らし、運用の可動域をコントロールしやすくなり、サードパーティのクラウドの可用性や価格体系によって「コア製品の機能」が妨げられる事態を減らすことができます。

6 - すべての開発チームに共通する教訓

ここでのストーリーは「HLSへの移行」ですが、得られる教訓はより幅広いものです。

1. 第一に、チームのお気に入りのサブシステムではなく、ユーザーのクリティカルパスを最適化すること。私たちは高速なインデックス作成を誇りに思っていましたが、ユーザーが製品で体験していたのは、再生の準備スピードという別のボトルネックでした。

2. 第二に、エンドツーエンドでベンチマークを行い、明らかな注目点だけに集中しすぎないこと。FFmpegそのものを超えたボトルネック（データ移動、ディスクI/O、アップロードパターン、キューのオーケストレーション）を追求したのは、「コマンドが速い」からといって「システムが速い」ことにはならないからです。

3. 第三に、インフラを自社製にするのは単なる技術的な決定ではなく、経済的かつ製品的な判断であること。推進力となったのは「自分たちでトランスコーディングを持ちたい」ということではなく、（a）ユーザーに見える遅延、（b）理にかなわないコスト曲線、そして（c）将来のデプロイ要件でした。

4. 第四に、自社内に移行するからには、信頼性を製品そのものとして扱うこと。私たちはコンシューマーがタスクをアクティブにしないといった問題に直面し、ログ記録、モニタリング、運用の実践（ハートビート、クリーンアップ用のcronjob、アラート通知など）を改善する必要がありました。

5. 最後に、段階的にリリース（Ship Incremental）していくこと。私たちの目標は明確でした。より高いリアルタイム比率を目指し、ユーザーエクスペリエンスにおいて重要な部分でベンダーと同等の機能水準に達することです。初日に完璧さを用意する必要はありません。反復して改善していける、より安全で、より安く、より速いルートが必要だったのです。