ロイターはどのように AWS 上で簡単にアクセスできる大規模なニュースアーカイブ環境を作ったか

UPDATE 2021/9/8: Amazon Elasticsearch Service は Amazon OpenSearch Service に名称変更されました。詳細はこちら。

私はロメオ・ラダニーです。グローバルマルチメディア通信社トムソン・ロイターのソリューションアーキテクトで、チームがクラウドテクノロジーを理解して採用できるよう支援しています。また、企業レベルの標準の設定、人工知能と機械学習の計画の推進、ロイター通信社の多くのシステムの構築にも携わっています。前回のブログ記事では、ロイターが最新ニュースの収集と配信システムの改善のためにコンテンツを Amazon S3 に移行した方法について説明しました。

このブログ記事では、トムソン・ロイターの AWS 導入の道のりと、 1896 年にさかのぼる動画を含む、世界で最もユニークなニュース動画アーカイブコレクションをデジタル化した方法について詳しく説明します。

テープや複数のデータサイロへのデータ保存で直面した課題

ご存知かもしれませんが、ロイターは幅広い種類のコンテンツを制作しています。特に誇りに思っているのは、受賞歴のあるデジタルプラットフォームである Reuters Connect から入手できるビデオアーカイブコレクションです。 Reuters Connect を使用すると、 BBC 、CNN 、ニューヨークタイムズ、ワシントンポストなどの顧客（放送局やオンライン出版社）がストーリーを購入できます。ストーリーは、1 つのクリップとして配信されるか、複数のクリップのコレクションとして配信されます。従来、ビデオアーカイブのコレクションは物理的なテープに保存され、当社に代わって第三者が管理していました。しかし長期的に見ると、管理が煩雑で、検索プロセスが遅いことによる制限があり柔軟性に欠けていました。また、クリップやストーリーを複数のビデオ出力形式で簡単に制作して配信するオプションがなかったため、スケーラブルではありませんでした。
この時点で 6 年分の処理済みコンテンツが 6 つのボールトに分散され、 Amazon Glacier Direct (Glacier Direct) に保存されていました。 Amazon Glacier Direct は S3 API をサポートする Amazon S3 ストレージクラスになる以前の Glacier サービスです。
Amazon Glacier Direct と Amazon S3 Glacier の違いについては、次のセクションで少し説明します。
とにかく、これらの制限のため、このモデルを変更しさまざまなストレージの場所にあるすべてのコンテンツを調整する必要があることは明らかでした。私たちはアーカイブコンテンツ専用のストレージを構築し、数分以内にお客様にコンテンツを提供できるメディア処理のシステムを構築することにしました。

Amazon Glacier Direct から Amazon S3 Glacier への進化

Amazon S3 は 2006 年に導入された安全で信頼性が高く、スケーラブルで低レイテンシーなデータストレージサービスです。AWS は安全で信頼性の高い、低コストのデータアーカイブとバックアップのための独立したストレージサービスとして、2012 年に Amazon Glacier を導入しました。 Amazon Glacier は大変低コストでシンプルなため、当社にとって非常に魅力的でした。そのため 6 年分の処理済みコンテンツを Amazon Glacier Direct に投入しました。その後、Amazon Glacier は正式に Amazon S3 Glacier (S3 Glacier) として知られる Amazon S3 ストレージクラスになりました。 Amazon S3 Glacier は、 S3 API 、 AWS ソフトウェア開発キット (SDK) 、および AWS マネジメントコンソールをサポートしています。私は元の Glacier サービスを Glacier Direct と呼んでいます。これは、既存の Glacier Direct API はすべて、現在のサービスでも同様に機能し続けるからです。

ロイターのビデオアーカイブの構築

時間が経ち、いくつかのプロジェクトが成功し大規模なコンテンツ移行が行われたことで AWS に関する知識と自信が高まりました。アーカイブされたすべてのコンテンツを、扱いにくい物理リニアテープオープン ( LTO ) テープ、または磁気テープデータストレージ、Amazon Glacier Direct から引き出そうと決心するところまで来ました。そのコンテンツは Amazon S3 とそのさまざまなコスト効率の高いストレージクラスに格納され、管理を完全に制御できるようになり、将来のロイター製品でより柔軟に使用できるようになります。
プロジェクトの目標について以下を合意しました。

プロジェクトではまず最初に当社のすべてのテープアーカイブ、約 750,000 件のニュース記事と 150 万件の個別のビデオクリップで構成される約 700TB のコンテンツを移行、デジタル化、処理します。また 6 年分の処理済みコンテンツを Amazon Glacier Direct から Amazon S3 ストレージクラスに移行することで、処理済みコンテンツの一部を保存します。
メタデータ形式をニュースメタデータ (ninjs) 用の IPTC 標準 JSON 形式に標準化します。 1896 年にコンテンツが最初にアーカイブされて以来、メタデータは大きく変化しました。
自分で管理するサーバーがない方が長期的には管理しやすいことがわかったため、可能な限りサーバーレスで構築します。
新たにアーカイブされたコンテンツ（ 5 日ごとに約 1 TB のコンテンツ）を毎日取り込むワークフローを作成します。
さまざまなメディアコンテナ形式をサポートするオンデマンドビデオ処理ワークフローを作成します。

データの移行

このプロジェクトを開始した時点では、データ移行に最適でセキュアなエッジコンピューティングおよびストレージデバイスである AWS Snowball はまだサービスとして提供されていませんでした。代わりに、AWS Direct Connect と Amazon S3 マルチパートアップロード API を使用して、テープからエクスポートされた約 700 TB のデータを Amazon S3 に移行しました。デジタル化したコンテンツの量が多いためこのプロセスには数週間かかりました。

この移行とアップロードのプロセス中に、 XML 、 NSML3 、 NewsMLG2 形式のメタデータを AWS Lambda 関数を使用して JSON 形式に標準化しました。メタデータは、一般的な NoSQL データベースである Amazon Elasticsearch Service に保存しました。私たちは AWS のマネージド Elasticsearch サービスを通じてこの課題を解決しました。これにより、 Elasticsearch を自分たちでセットアップして管理するのではなく、私たちはビジネス目標に集中することができました。また未加工の動画コンテンツを再エンコードして圧縮するバッチワークフローを作成したことで、ストレージと配信のコストを削減しました。さらにほとんどのストーリーが以前はテープに保存されていたため、ワークフローではさまざまなフレームが正確に切り取られました。数百の Amazon EC2 スポットインスタンスを数週間使って、誰もが気に入っているオープンソースツールである FFmpeg を使って、ほぼすべてをエンコードして切り抜きました。バッチ処理に EC2 スポットインスタンスを使用することで、AWS が提供する並列化とスケーリング性能により、多大な費用と時間を節約できました。

加えて6 つの Amazon Glacier Direct に 6 年分の処理済みコンテンツが保管されていました。このコンテンツでは、FastGlacier Windows クライアントを使用して Glacier Direct ジャーナルファイル (コンテンツのリスト) を取得して Amazon Glacier Direct からの並列検索と復元を効率的に管理し、ファイルをダウンロードしました。また復元されたコンテンツを取得し、それまで base64 でエンコードされたファイルをデコードして元のファイル名に戻す小さなアプリケーションを作成する必要がありました。そうしないとファイル名が競合することになるため、そのプロセスはアップロード時に必要なことでした。次に同じカスタムアプリケーションを使用して、取得したデータを Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) ストレージクラスに自動的にアップロードしました (カスタムアプリケーションは AWS CLI を利用していました)。

Amazon Glacier Direct の取得作業を開始する前に、ファイル取得にどれだけの時間と費用を投資できるかを慎重に計画しました。Amazon Glacier Direct は毎月のピーク取り出し率に基づいて価格設定されていたため、リクエストの量を管理してコストをできるだけ管理することが重要でした。Amazon Glacier Direct にコンテンツを保存する費用は安価でしたが、コンテンツを Amazon S3 に移動し、ストレージクラスと S3 ライフサイクルポリシーを使用してコンテンツを管理することを優先しました。ストレージクラスと S3 ライフサイクルポリシーは、複数の S3 ストレージクラスを使用してアクセスパターンに基づいてストレージコストを最適化できるようにした機能の例です。データの大部分は S3 にあり、Amazon Glacier Direct には S3 API とは異なる Glacier Direct API が必要だったため、 2016 年に Amazon Glacier Direct の使用を停止しました。 S3 Glacier は 2018 年に正式に S3 ストレージクラスになり、現在は S3 API をサポートしています。

私たちが直面した最大の課題はメディア処理のビジネスロジックを企業間モデルで維持しながら、顧客の要求に応えることができるスケーラブルで低コストなサーバーレス中心の構成を迅速に作成することでした。卸売業者として、 IMX30 、 AVCi50 、 AVCi100 など、さまざまなメディア出力コンテナをお客様に提供しています。またさまざまなフレームレートでコンテンツを作成しています。最も一般的なものは、ヨーロッパ、アフリカ、アジアで使用される 25 フレーム/秒 (FPS) 、アメリカで使用される 29.97 FPS です。ロイターにはフレームレート変換に関する長い歴史と経験があります。このような変換は計算量の多い作業であり、人為的にフレームを作成するか、少なくともフレーム間の差分を作成する必要があるため困難です。

以下はお客様に提供する必要のあったメディアフォーマットに対応するために、このプロジェクトの時点でサポートしなければならなかったトランスコーディングジョブの概要です。

オンデマンドなアーカイブのクリップリクエストワークフローの作成

オンデマンドの顧客のリクエストを反映したさまざまな出力タイプをサポートするために、当初 Amazon Simple Workflow Service (Amazon SWF) を中心にアプリケーションを作成しました。Amazon SWF を何年も使用した後、新しいプロジェクトとの一貫性を保つために AWS Step Functions に移植しました。 Amazon SWF は、そのフレームワークとアプリケーションコンポーネントの分離、コーディネーション、またはビジネスロジックにより、開発を大幅に加速しました。AWS Step Functions は、主に Amazon SWF の基本的な API に依存していますが、ワークフローに関する柔軟性と視覚化機能を備えているため、 Amazon SWF の後のアップグレードとしては間違いなく素晴らしいものでした。

私たちのクリップのリクエストワークフローのアーキテクチャーを以下に記載します。

上の図の下部から私たちのワークフローを説明します。

お客様 (放送局やオンラインパブリッシャー) は Reuters Connect プラットフォームにアクセスして、アーカイブされたコンテンツと必要なレンディションを選択します。
Reuters Connect のバックエンド機能により、 Amazon API Gateway への API 呼び出しがトリガーされます。
API 呼び出しによって簡単な AWS Lambda 関数がトリガーされ、 AWS Step Functions ジョブが作成されます
Amazon CloudWatch カスタムメトリクスを使用して、現在のアクティブなジョブ数に基づいて十分なリソースがあるかどうかを判断します。十分なリソースがない場合は、インスタンスとコンテナがプロビジョニングまたはスケールアップされます。
Reuters Connect は Amazon S3 で動画の場所を見つけてダウンロードし、そのストーリーの Amazon Elasticsearch に保存されているメタデータに基づいてトランスコーディングジョブを開始します。
処理が完了すると、処理されたビデオは S3 に戻され、高速コンテンツ配信ネットワーク (CDN) である Amazon CloudFront を介して顧客に提供されます。
処理ジョブのステータスは、追加の API 呼び出しで追跡できます。呼び出しは、ビデオ処理ジョブのトリガーに使用されるのと同じ API ゲートウェイに対して Reuters Connect バックエンドアプリケーションによって行われます。
ジョブの規模にもよりますが、顧客は Amazon S3 イベント (s3: ObjectCreated: *) によってトリガーされ、 Amazon SNS を介して管理される E メール通知を受け取ります。

これらのプロセスはシンプルでありながら、柔軟でスケーラブルです。これは、 Amazon S3 からコンテンツを入手したことで、アクセスと使用の両方が簡単になったためです。

S3 ストレージクラスを活用したストレージコストの最適化

ニュース速報とアーカイブコンテンツの両方に Amazon S3 を使用するもう 1 つの主な利点は、ストレージクラスを使用してさまざまなアクセスパターンに対応するコストでサポートできることです。次の Amazon S3 ストレージクラスを使用しています。

S3 標準 : すべての最新ニュースは少なくとも 30 日間保存され、自動的にアーカイブの一部となり、 S3 標準 – IA に移行されます。また、お客様が購入したアーカイブコンテンツは、すべてオンデマンドで保管されます。
S3 標準 – IA : アーカイブされたビデオコンテンツはすべてこのクラスに保存されます。このコンテンツはすぐに処理でき、オンデマンドでの処理と利用をリクエストできます。
S3 Glacier Deep Archive : テープからデジタル化したオリジナルのソースコンテンツはすべて S3 Glacier Deep Archive に保存されます。このアーカイブはバックアップでもあり、別のバケットに安全に保存されます。

次のスクリーンショットのような単純な S3 ライフサイクルルールを使用すると、コンテンツをあるストレージクラスから別のストレージクラスにペタバイト規模で簡単に移行できます。これにより、 S3 標準で約 700 TB を保存する場合と比較して、毎月のストレージコストを約 95% 節約できます。

また、シンプルなバケットポリシーでは、読み取り専用のクロスアカウント権限を設定することで、下位環境 (開発、QA、運用前環境など) で本番データを再利用できます。これにより、同じデータセットのコピーを 2 つ以上用意する必要がなくなるため、ビデオアーカイブ全体のストレージコストを 75% 節約できます。さらに良いことに、バケットポリシーにより、開発と品質保証を目的とした本番環境のようなシステムを維持できます。

Reuters Audio のローンチ

ロイター研究所の最近の調査によると、 2019 年以降、ニュースポッドキャストの数は 32% 増加しています。その増加傾向の中で、最も人気のあるポッドキャストの 20% が「ニュース」に分類されました。消費者の声がかつてないほど高まる中、ロイターは今こそオーディオのルネッサンスを取り入れる時だと判断し、2020 年 6 月 17 日に Reuters Audio を発表しました。ロイターのオーディオ処理バックエンドは、前のセクションで説明したように、ロイターのビデオアーカイブ用に設計したワークフローを再利用できました。出力リストにレンディションタイプを追加するだけで、顧客の要求に応じてサウンドバイトやオーディオファイルを簡単に作成できます。

そこで生じた複雑さは、主にオーディオを含むビデオアーカイブ内のクリップをすべて見つけることにありました。機械学習を使って動画内の音声や自然な音を簡単に識別できるワークフローをすでに構築していたことを思い出してください。私たちがしなければならなかったのは、バッチ処理を開始して、すべてのコンテンツにオーディオに基づく追加のメタデータをタグ付けすることだけでした。コンテンツを、音声が含まれるか、自然音を含むか、まったく聞こえないかのいずれかに分類しました。これは販売するオーディオがあるかどうかを判断するうえで役立ちます。 AWS Elasticsearch に保存したニュースメタデータ JSON ファイルに、すべての追加メタデータを追加しました。これにより、どのアーカイブクリップのオーディオトラックを Reuters Connect 経由で利用できるかが決まります。そして、クライアントがそれらのサウンドバイトを購入したい場合、前述のクリップリクエストワークフローを開始します。オーディオトラックは数秒で制作・配信され、Amazon S3 に保存されます。

以下は、ロイターコネクトで購入可能なオーディオトラックを含むアーカイブクリップの例です。

まとめ

2015 年以降、Amazon S3 が当社のコアマルチメディアストレージソリューションとなったことにより、サーバーレステクノロジーとマネージドサービスを使用してから 1 年後、 AWS にアーカイブソリューションを移行して構築する作業ははるかに簡単になりました。700 TB のコンテンツの大規模なバッチ処理を、オンプレミスで行う場合の数分の 1 のコストと時間で行うことができました。新しくアーカイブされたコンテンツの毎日の取り込みワークフローに加えて、お客様が使用できる幅広い出力を使用して、スケーラブルでコスト効率が高く、迅速なクリップリクエストワークフローを設定することができました。内容をまとめますと、非常にユニークなコンテンツでお客様により良いサービスを提供するために、より堅牢でコスト効率が高く、機能豊富なソリューションを作成しました。

Amazon S3 、 AWS Lambda 、 Amazon API Gateway 、 AWS Step Functions などの AWS サービスを使用および統合することで、ビジネスの複雑さや要件に関係なく、迅速な開発とイノベーションが可能になりました。これにより、当社のアーカイブ機能を強化し、将来お客様のためにさらに多くの機能を追加するための基礎が築かれました。初期のソリューションの多くを再利用して、100 年以上にわたるサウンドバイトの世界的なコレクションである Reuters Audio 製品に適用することができました。さらに、 Amazon S3 のさまざまなストレージクラス、 Amazon EC2 のさまざまなインスタンスタイプとスケーリングオプションなどの機能により、コストを抑えることができました。これらはオンプレミスで構築するとなると、コストが大幅に高くなります。

ロイターでの AWS クラウドの経験を共有することで、お客様自身の AWS ジャーニー、コンテンツの構築と管理、お客様への最高のサービスの提供に役立つことを願っています。読んでいただきありがとうございます。ご不明な点がございましたら、コメントしてください。 AWS re:Invent 2019 での私のプレゼンテーションの次のビデオ録画には、ロイターのビデオアーカイブ用に Amazon S3 を使用した事例に関する詳細が記載されています。

How Thomson Reuters built the Reuters video archive on AWS:

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

本ブログの翻訳はソリューションアーキテクトの紙谷が担当しました。

原文はこちらです。

Amazon Web Services ブログ