Amazon Web Services ブログ

GoPro でのAmazon EC2 スポットインスタンスを利用したメディアトランスコーディングパイプラインの大規模な最適化

GoPro は、イマーシブかつエキサイティングな方法で画像のキャプチャや共有をサポートしています。2002年の設立以来、GoPro は、お客様がコンテンツから最大限の価値と楽しみを得られるように、多用途のカメラとソフトウェアツールをリリースしてきました。Amazon Web Services (AWS) がサポートする GoPro サブスクリプションは、カメラ、マウント、アクセサリー、ライフスタイルグッズなどの GoPro のラインナップに加えて、無制限のクラウドストレージ、自動ハイライトビデオ、デバイス間で同期される便利な編集機能、ライブストリーミングプラットフォーム、ソーシャルメディアプラットフォームと直接コンテンツを共有する機能など、GoPro 体験を結びつけます。現在、GoPro は毎月大量の動画データを処理し、約250万人の加入者にサービスを提供しています。


図 1: GoPro でのメディア処理

GoPro は独自のトランスコーディングとメディア処理パイプラインを使用しており、さまざまなデバイス、ビットレート、コーデック、帯域幅をサポートしています。コンテンツが Amazon Simple Storage Service (Amazon S3) に取り込まれると、前処理を行うジョブが実行されてメタデータ、解像度、コーデック情報が収集され、動画のサムネイルが作成されます。さまざまなクラスのトランスコーディングジョブが、Amazon EC2 上の FFmpeg を使用して、Amazon Elastic Container Service (Amazon ECS)クラスター、Docker コンテナ、カスタム設定ビルドで実行されます。また、動画と音声、GPMF (GoPro Metadata Format/General Purpose Metadata Format)、デマルチプレクサ、マルチプレクサのトランスコーディングを組み合わせるために、Amazon EC2 上で他の独自のツールを使用しています。

GoPro は当初、エンドユーザーがコンテンツを取り込み、処理、保存、共有できるようにするために、AWS を使用してサブスクリプションサービスを展開していました。しかし、加入者数とユーザーが生成するコンテンツの量が増加するにつれて、GoPro は柔軟でスケーラブルなインフラストラクチャを備えた、より適応性の高いコンテンツ処理パイプラインを必要とするようになりました。

一時的にピークが高くなる季節的なトラフィックに対して、インスタンスのオートスケーリングは弾力性とスケーラビリティを提供し、トランスコーディング中のEC2 キャパシティの増減を管理します。トランスコーディングワークフローは非同期で、メッセージとイベント駆動型であるため、複数のジョブを並行して実行することで効率を高め、ワークロードは中断に耐えることができます。GoPro は Amazon ECS クラスターを Amazon EC2 スポットインスタンスにデプロイして、より費用対効果の高いコンピューティングを実現し、オンデマンドコストを約 50% ～ 70% 削減しました。Amazon EC2 スポットインスタンスは、オンデマンド価格と比較して最大 90% 割引で利用できることを特徴としています。

GoPro は EC2 スポットインスタンスのベストプラクティスを活用しています。可能な限り幅広く多くのキャパシティプールを分散して利用することで、終了したスポットインスタンスを他のスポットインスタンスで置き換え、ピーク時のトラフィックを処理しています。スポットインスタンスの中断の頻度を最小限に抑えるため、GoPro はキャパシティ最適化配分戦略を採用しています。また、Terraform スクリプトによる自動化で、中断されたスポットインスタンスの自動ドレインを実行する機能も実装しています。

Auto Scaling グループにおいては属性ベースのインスタンスタイプ選択を使用することで、Amazon ECS クラスターではCPU インスタンスと GPU インスタンスの両方を使用しています。

instance_requirements = {
    memory_mib_min = 32768
    memory_mib_max = 131072
    vcpu_count_min = 32
    vcpu_count_max = 64
    cpu_manufacturers = ["amd", "intel"]
    excluded_instance_types = (["a*", "t*", "m6g*", "c6g*", "c7g*", "d*", "h*", "i*", "g*", "p*", "inf1*", "dl*", "vt*", "x*", "r6g*", "z1*", "f1*"])
}

他のすべての Auto Scaling グループでは、次の例のようなインスタンスタイプを使用しています。
（訳者注）以下の例では以前の世代のインスタンスタイプが多く見られますが、なるべくより新しい世代のものも含めることも選択肢として重要です。

spot-instance-type = [
    { instance_type = "r5b.4xlarge" },
    { instance_type = "r4.4xlarge" }, 
      . 
      .
      .
]
spot-instance-type = [{ instance_type = "g4dn.xlarge" }]
spot-instance-type = [{ instance_type = "c3.4xlarge" },
    { instance_type = "c3.8xlarge" },
    { instance_type = "c4.4xlarge" },
    { instance_type = "c4.8xlarge" }, 
      .
      .
      .
]

Auto Scaling グループ (ASG) は配分戦略としてキャパシティ最適化を行うように設定されています。これにより、起動するインスタンスの数に最適なキャパシティを持つプールからスポットインスタンスをリクエストします。

spot-allocation-strategy = "capacity-optimized"

（訳者注）配分戦略は価格とキャパシティの両方を考慮するprice-capacity-optimized (料金キャパシティ最適化)をより推奨していますが、GoPro ではキャパシティのみを考慮し中断の可能性を最も下げることができるcapacity-optimized を利用しています。

ワークフローのレジリエンスは、一連の AWS Lambda 関数の実行で高められています。

  1. Auto Scaling グループスケールイン CloudWatch イベントは、終了中のインスタンスのドレインを実行する Lambda 関数 (General Drain と呼んでいる) をトリガーします。
  2. もう 1 つの Lambda 関数 (Spot Drain と呼んでいる) はスポット ASG に特化したもので、EC2 スポットインスタンス中断通知が発生するとトリガーされます。
  3. スポットインスタンスにかんするメトリクスの収集にはさらに別の Lambda 関数が使用され、これはインスタンス終了時、起動時、およびスポットインスタンスの中断時にトリガーされます。

図 2: EC2 Auto Scaling を使ったトランスコードワークフロー

ワークフロー全体は、AWS Lambda を利用した GoPro 用のカスタムビルドのダッシュボードで監視されています。このダッシュボードは、Amazon ECS を使用してスポットインスタンスをモニタリングおよび可視化し、中断率、インスタンスタイプ、およびスポットインスタンスに関連するその他の統計情報を表示します (図3)。


図3: スポットインスタンス関連の統計情報を表示するダッシュボード

Amazon EC2 スポットインスタンスを追加し、潜在的な中断に備えて設計した結果、GoPro はコンテナ化された全ワークロードの 70% 以上をスポットインスタンスで実行し、大幅なコスト削減を実現しています。

この記事では、Amazon EC2 スポットインスタンスによって GoPro がコンピューティングリソースをよりコスト効率よく活用し、メディアサプライチェーンにおけるトランスコーディングプロセスを大規模に改善する方法について説明しました。スポットインスタンスの詳細については、EC2 スポットインスタンスのベストプラクティスのドキュメントをご覧ください。

このブログは、GoPro DevOpsエンジニアのVlad-Alexandru Voineaと、GoProのDevOpsマネージャーであるZaven Boniが執筆し、テクニカルアカウントマネージャーのJenny Oshimaが公開したものを、ソリューションアーキテクトの石神靖弘が翻訳しました。原文はこちらです。