【要約】GCSの動画をローカル保存せずYouTubeへストリーミングアップロードする【Python】 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がCloud Run上で動画生成・投稿パイプラインを構築した際、以下のリソース制約と運用課題に直面した。
- ・Cloud Runのコンテナファイルシステムへの書き込みはメモリを消費する。
- ・HD動画をローカルにダウンロードすると、メモリ不足（OOM）を招くリスクがある。
- ・YouTube APIのサムネイルサイズ制限（2MB）により、高解像度画像がエラーとなる。
- ・動画が削除された際、メタデータの状態により再アップロードがスキップされる。
// Approach
開発者はメモリ消費を最小化し、パイプラインの堅牢性を高めるため、以下の手法を採用した。
- ・GCSの
blob.open("rb")とYouTube APIのMediaIoBaseUploadを組み合わせ、データをストリームで直接転送する。 - ・サムネイルはPillowを用い、2MB以下になるまでJPEGの品質を段階的に下げて再エンコードする。
- ・
videos.listで動画の存在を確認し、削除済みならメタデータをリセットして再投稿を可能にする。 - ・Cloud Tasksとの連携において、4xxエラー時は200を返してリトライを停止させる制御を行う。
// Result
本実装により、メモリ消費を抑えた効率的なアップロードを実現した。
- ・ローカルに一時ファイルを保存せず、Cloud Runのメモリ使用量を大幅に削減した。
- ・サムネイルのサイズ制限エラーを回避し、自動化プロセスを安定させた。
- ・動画の削除検知とリトライ制御により、運用フェーズでの手動介入を減らす設計とした。
Senior Engineer Insight
> サーバーレス環境におけるI/O設計として非常に理にかなっている。特に
MediaIoBaseUploadによるストリーミングは、メモリ制約のあるCloud Runにおいて必須のテクニックだ。ただし、アップロード中断時のレジューム機能が欠けており、大規模ファイルではリトライコストが高くなる懸念がある。また、429エラー（レートリミット）のハンドリングをより精緻化すれば、さらに堅牢なシステムになるだろう。