NASCAR のマルチ PB メディアアーカイブを AWS Storage で高速にモダナイゼーション

NASCAR archive content composition

National Association for Stock Car Auto Racing (NASCAR) は、米国で最も人気のあるモータースポーツの公認団体であり、米国内の 15 の主要なモータースポーツ・エンターテインメント施設を所有しています。NASCAR は約 15 年前に、過去 70 年以上にわたる NASCAR のコンテンツを含むすべてのビデオ、オーディオ、画像アセットを収集し、一元的に管理することを開始しました。このメディアコンテンツのコレクションは、時とともに大きくなり、世界最大のレーシングメディアアーカイブの 1 つとなりました。

NASCAR において、私はメディアとイベントの技術実装を担当しています。私の一番の関心は NASCAR のメディアシステムエンジニアリングとイベント情報技術の運用にあります。私は、我々の AWS ソリューションアーキテクチャと AWS サービスとの統合、および社内で開発したメディアベースのワークフローについて責任を負っています。私が率いるメディアテクノロジストチームは、NASCAR の戦略的技術目標に関連する新しいエキサイティングな機能を構築するために、AWS ソリューションアーキテクト、エンジニアリング、ソリューションマネージャーと密接に連携しています。

NASCAR のメディアライブラリーが増え続ける中、私たちはコストからスタッフ配置まで、私たちの従来のデータ管理インフラに由来する潜在的なリソースの課題や欠点に直面していました。このことを念頭に置き、私たちはコストの最適化と、インサイトとイノベーションの観点からデータを最大限に活用することに注力する必要がありました。このブログでは、大規模なビデオアーカイブを AWS に移行し、アーカイブとリストアに関連するワークフローを自動化するための理由とアプローチについて説明します。

NASCAR メディアアーカイブの概要と課題

NASCAR のビデオ、画像、オーディオコンテンツをアーカイブするための技術や手順は、時間の経過とともに進化してきました。過去 10 年間、NASCAR のメディアライブラリーは、8,600 本以上の LTO 6 テープと数千本の LTO 4 テープを持つ LTO テープライブラリーに格納されていました。また、ディザスタリカバリ用に同量の LTO テープが地理的に離れた場所に保管されていました。

NASCAR のライブラリーは非常に大きくなり、現在では年間およそ 1.5 PB〜2 PB のデータ増加率になっています。この加速度的な成長により、データの取り込みと必要な LTO テープのマイグレーションプロセスを維持することがますます困難になってきました。LTO テープの次のバージョンがリリースされる前に、そしてマイグレーション作業が完了する前に、LTO ライブラリーのテープスロットを使い切ってしまうのか？ LTO テープの出し入れのためにスタッフを増員しなければならないのか？どちらのシナリオが先に起こるか競争になっていました。

これらの可能性を考慮し、私たちは戦略を振り返り、データアーカイブプロセスを進化させ、モダナイズするためにピットインする必要があると判断しました。Amazon S3 Glacier Flexible Retrieval (以前のAmazon S3 Glacier) と Amazon S3 Glacier Deep Archive を採用し、デジタルアセットの価値を最大化し、データから新しい洞察を得ることを決断したのはその時でした。このブログでは、15 PB のメディアアーカイブをオフサイトのテープ保管庫から AWS に移行するまでの 18 ヶ月の道のりについて説明します。このブログのゴールは、あなたが自身のアーカイブを AWS に移行することを検討する際に、役に立ついくつかのポイントを得ることです。

Modernizing NASCAR’s multi-PB media archive at speed with AWS Storage

NASCAR アーカイブのコンテンツ構成

NASCAR のストレージワークフローは、アーカイブとバックアップという 2 つの領域に分かれています。

NASCAR ライブラリーのアーカイブは、Apple ProRes コーデックという高解像度のメディアファイル、つまりメザニンファイルという最高品質のアセットにフォーカスしており、ほとんどの場合、再作成することはできません。以前のワークフローでは、メザニンを LTO ライブラリーに保存し、アーカイブソフトで管理していました。このアーカイブソフトは、LTO 上にファイルのコピーを 2 つ作成し、1 つは LTO ライブラリーに残し、もう 1 つはオフサイトの保管場所にエクスポートしていました。ユーザーはメザニンファイルへのアクセスが必要な場合、メディアアセット管理システムからリクエストを送信すると、アーカイブソフトウェアにリストア要求が初期化・自動化され、LTO からローカル SAN にファイルがリストアされる仕組みになっています。

NASCAR ライブラリーのバックアップ面では、低解像度のプロキシファイルが中心となっています。これらのファイルは、検索、オフライン編集、アセットロギングに使用され、世界中のユーザーがすぐにアクセスできるように 24 時間 365 日オンライン状態を維持する必要があります。私たちのプロキシファイルはメザニンファイルから生成され、理論的には再生成することが可能です。しかし、本当のディザスタリカバリの状況では、メザニンファイルを復元し、それをトランスコードしてプロキシファイルを作成することにかかる 50 万時間近いファイルを再生成する時間は、現実的ではなく、非効率的なものになります。NASCAR のワークフロー全体におけるプロキシの価値を考慮し、現在は回転ディスクによるディザスタリカバリソリューションから Amazon S3 Glacier Deep Archive への移行も選択しました。私たちが S3 Glacier Deep Archive を選んだのは、この非常に低コストのストレージクラスが提供する驚くべきコスト削減を利用するためで、大部分はファイルがディザスタリカバリワークフローとしてのみ使用されているためです。

プロキシワークフローとメザニンワークフローはそれぞれ独立しています。しかし、両ワークフローは、クラウド上の AWS Storage とサーバーレスアーキテクチャに移行することで、機能強化が図られています。プロキシバックアップワークフローの場合、もっぱら Amazon S3 Glacier Flexible Retrieval を使用しており、ほとんど – もしなければ – アクセスのないプロキシバックアップを永続的かつ効率的に保存することが可能です。メザニンアーカイブのワークフローでは、S3 Standard、S3 Glacier Instant Retrieval、S3 Glacier Deep Archive を導入しています。ファイルオブジェクトは、NASCAR ライブラリーの S3 ライフサイクル戦略に従って S3 に書き込まれます。ファイルが S3 Standard での期限を迎えると、S3 Glacier Instant Retrieval、その後、S3 Glacier Deep Archive にライフサイクルで移行し、永久保存されます。

Figure 1: Media archive architecture overview

図 1：メディアアーカイブのアーキテクチャ概要

NASCAR の Amazon S3 アーカイブライフサイクル戦略

私たちのアーカイブとリストアのワークフローは、週末に行われる 38 レースで構成される NASCAR の年間レースシーズンを中心に構成されています。私たちは、季節や毎週のレーススケジュールを反映した、複数の Amazon S3 ストレージクラスで構成されるライフサイクルポリシーを使用できることを発見しました。レースウィーク中、ファイルオブジェクトは S3 Standard にアーカイブされ、その後タイマーが開始され、ライフサイクルポリシーが有効になります。

当初は、前回のレースシーズンでのファイルパターンの利用状況から、リソースの最大化とコスト削減のために、S3 Standard、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive の各ストレージクラスを使用していました。しかし、S3 Glacier Instant Retrieval のリリースに伴い、メザニンは S3 Glacier Flexible Retrieval から移行しました。通常、レースウィークには、そのレース場で開催された前回のレースからアーカイブされたファイルのリストアが要求されます。NASCAR のレーストラックのほとんどは、1 年に 1 回しかレースを開催しません。毎年レースが開催されるため、リストアリクエストを 3～5 分に抑えるために、現在は S3 Glacier Instant Retrieval に 2 年間データを保存しています。NASCAR の現在のワークフローでは、各バケットに対して、以下のような期限に基づいたライフサイクル戦略を有効にしています。

メザニン – 1 日後に S3 Glacier Instant Retrieval に、730 日 (2 年) 後に S3 Glacier Deep Archive に永久保存するライフサイクル
ソース – 1 日後に S3 Glacier Deep Archive に永久保存するライフサイクル
プロジェクト – 1 日後に S3 Glacier Deep Archive に永久保存するライフサイクル
Proxy DR – 1 日後に S3 Glacier Deep Archive に永久保存するライフサイクル

S3 バケットに新たにアップロードされたコンテンツのために、先に挙げたライフサイクルポリシーを設定しました。また、ファイル名の分類に合わせたプレフィックス・スコープ付きのライフサイクルポリシーも作成しました。その際、2 年以上前に記録された移行アセットは、非常に低コストで長期保存が可能な S3 Glacier Deep Archive に保存します。

Figure 2: NASCAR library lifecycle configuration

図 2：NASCAR ライブラリーのライフサイクル構成

NASCAR のビデオアーカイブの移行プロセス

従来の LTO ライブラリーから 15 PB のデータをクラウドに移行するプロセスは複雑です。LTO 上のすべてのファイルをリストアし、アーカイブのために Amazon S3 ストレージにアップロードし、Amazon DynamoDB のテーブルで移行状況をインベントリ化することで構成されています。

コンセプトの実証として、まずいくつかの Python スクリプトで構成される半自動化ワークフローを開発しました。最初のスクリプトは、LTO テープのリスト情報をエクスポートするもので、各 LTO テープにあるすべてのファイルが含まれています。次のスクリプトでは、LTO テープからディスクにファイルをリストアすることができました。そして、すべてのファイルが LTO テープからディスクにリストアされ、検証されました。次に、Amazon S3 へのアセットのアップロードを行うスクリプトをセットアップしました。さらに、必要なファイルインベントリスキーマを持つ Amazon DynamoDB テーブルをセットアップしました。最後に、新しいオブジェクトが Amazon S3 バケットに書き込まれるたびにトリガーされる AWS Lambda 関数をセットアップしました。Lambda 関数の唯一の目的は、Amazon DynamoDB テーブルをファイルオブジェクトの情報で更新することです。

ワークフローの完全自動化を迅速に行うため、CloudFirst の Rapid Migration automation workflow を利用しました。Rapid Migrate を使うことで、前述のワークフローのうち、LTO テープのファイルインベントリ検索、LTO ファイルリストのリストア、S3 アップロードの機能を完全に自動化することができました。これにより移行作業がスピードアップし、1 年強でアーカイブ全体を完全に移行することができました。

Figure 3: Road to the automated archive architecture

図 3：自動アーカイブアーキテクチャへの道のり

NASCAR の S3 アーカイブのプロセス概要

Amazon S3 ストレージへの移行の次のステップは、メディアアセットアーカイブパイプラインの開発でした。このパイプラインは、Avid Media Central Cloud UX システムに接続されるビデオ、オーディオ、画像アセットのアーカイブを自動化するために必要なコンポーネントでした。新しいアーカイブ・アーキテクチャを AWS で作成することで、アーカイブプロセスを完全に制御できるようになり、アセットを管理するための別のサードパーティ製アーカイブ管理システムへの依存が解消されました。

Figure 4: Upload archive architecture

図 4：アーカイブアップロード構成

ワークフローは、新しいメディアアセットが Avid Media Central Cloud UX 環境に取り込まれた時点で初期化されます。ビデオファイルが当社のハウススタンダードにトランスコードされた後、ソースメディアのハイレゾエッセンスが、図 4 に示すプロセスで Amazon S3 にアップロードされます。インジェストプロセスにおいて、Avid はアーカイブ API に POST リクエストを送信し、クエリパラメータにメッセージ body を要求します。

メッセージ body:

{
    "Filename": "AWESOME_VIDEO.mov",
    "Bucket": "nascar-test-bucket-name",
    "Path": "/test/path/to/file"
}

その後、API は Amazon Simple Queue Service (SQS) の Upload_Queue にメッセージを送信します。

Amazon SQS メッセージは、オンプレミスの Linux サーバーにある Python3 スクリプトによって消費され、SQS メッセージの json “Bucket” 要素に定義されている S3 バケットにアップロードされます。

S3 バケットにファイルが作成されると、アップロードプロセッサの AWS Lambda 関数がトリガーされ、ファイルのトランザクションログとなる Amazon DynamoDB テーブルが更新されます。

Lambda 関数:
Lambda function

NASCAR リストアプロセスの概要

すべてのデータを S3 に格納した後、AWS からノースカロライナ州シャーロットの NASCAR プロダクション施設にある SAN ボリュームに、メディアアセットをリストアして転送するワークフローを開発しました。

Figure 5: The NASCAR automated restore architecture

図 5：NASCAR の自動リストアアーキテクチャ

メッセージ body:

{  
 "Filename": "AWESOME_VIDEO.mov",  
 "Priority": "low",  
 "Path": "/stornext/TEST/AWS/Restore/TEST",  
 "Username": "speedy",  
 "workflowId": "27451458"  
}

API リクエストは AWS Step Function Restore_DynamoPull_To_SQS にメッセージを送信します。Step Function は DynamoDB の定義テーブルを確認し、DynamoDB にアセットがあるかどうかを確認します。DynamoDB の定義テーブルにアセットがある場合、API body で設定された優先度に基づいて、SQS の High_Priority または Normal_Priority キューにメッセージが送信されます。

NASCAR amazon SQS flow chart

SQS メッセージは Upload Processor Lambda 関数によって消費され、ファイルオブジェクトが現在 “S3 – Standard” または “S3 Glacier Instant Retrieval” ストレージに存在するかどうかを確認します。ファイルが S3 Standard ストレージにある場合、“Copy Job Queue” がファイル情報で更新されます。そして、DynamoDB のステータスは Standard Storage - Move to Copy SQS に設定されます。しかし、ファイルオブジェクトが S3 Standard または S3 Glacier Instant Retrieval にない場合、S3 Glacier Flexible Retrieval または S3 Glacier Deep Archive からファイルを復元するためにリストア要求が送信されます。さらに、リストアが送信されると、Lambda によってアセットの DynamoDB のステータスが In Progress - Priority SQS に更新されます。ファイルオブジェクトが S3 Glacier Flexible Retrieval または S3 Glacier Deep Archive から S3 Standard にリストアされると、Lambda 関数 “Update Copy SQS” がトリガーされます。Lambda 関数は、SQS の “Copy Job Queue” にメッセージを追加します。

最後に、オンプレミスで実行されている Python3 スクリプトは、10 秒ごとに Copy Job Queue をポーリングし、ダウンロード可能なファイルがあるかどうかを判断しています。スクリプトがキューからメッセージを消費すると、冗長化された 10 Gbps の AWS Direct Connect ネットワークパスを介して、オンプレミスの Quantum StorNext SAN ボリュームにファイルがダウンロードされます。ファイルが事前に定義されたパスに保存されると、スクリプトは DynamoDB のステータスを “Restore Completed” に更新し、リストア処理が完了したことを Avid に通知します。その後、エンドユーザーには、ファイルが Adobe Premiere プロジェクトで使用できるようになったことを通知するメールが送信されます。

おわりに

AWS Storage を使用して NASCAR の技術スタックをモダナイズすることは、NASCAR のクラウドジャーニーにおいて非常に重要な一歩です。私たちのすべてのビデオ、オーディオ、および画像ライブラリーを、業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを備えた Amazon S3 に移行することで、私たちのビジネスに役立つ追加のワークフロー開発に多くの時間を費やすことができるようになりました。NASCAR の歴史的なメディアアーカイブを維持しながら、Amazon S3 Glacier Flexible Retrieval、Amazon S3 Glacier Deep Archive、そして今回の Amazon S3 Glacier Instant Retrieval によって、LTO テープフォーマットの終わりのないライフサイクル管理は、過去のものになりました。そして、Amazon S3 ストレージは、私たちのビデオ、オーディオ、画像ベースのワークフローにコストとパフォーマンスを最適化するために、多くの有用な S3 ストレージクラスを使用することによって、大きなコスト削減を私たちにもたらしてくれます。また、すべてのストレージクラスでイレブンナインの耐久性を確保し、データを保護しながら、従来の LTO ストレージライブラリーから大幅に改善されています。

この投稿の内容や意見は、第三者の執筆者によるものであり、AWS はこの投稿の内容や正確性について責任を負うものではありません。

Chris Wolford

Chris Wolford は NASCAR のメディアおよびイベント技術担当シニアディレクターです。メディア＆エンターテインメント業界で 15 年以上の経験を持ち、メディアオーケストレーションに特化したソリューションアーキテクチャを構築しています。NASCAR テクノロジーとメディア・ベンチャーのビジネスラインにおけるクラウド移行と採用のイニシアチブをリードしています。ノースカロライナ州シャーロットに妻と 2 人の娘と住んでいます。

参考リンク
AWS Media Services
AWS Media & Entertainment Blog (日本語)
AWS Media & Entertainment Blog (英語)
AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp
※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

本記事は、NASCAR の Chris Wolford による寄稿であり、翻訳は SA 井村が担当しました。原文はこちらをご覧ください。

Amazon Web Services ブログ