Azure Media Servicesとは何ですか？

いくつかの成功したトライアルを経て2013年にGA（一般提供）が発表されたAzure Media Servicesは、クラウドでのライブおよびオンデマンドコンテンツの配信に必要なすべてを提供していました。VODやリニアフィードのインジェストから、トランスコーディング、エンコーディング、カプセル化（パッケージング）、Azure CDN経由の配信に至るまで、AMSは比較的一般的な管理用API群を提供していました。最終的には、ビデオ・オーディオ処理の変更、FairPlay DRM処理、VODのハイアベイラビリティの変更を実装したV3 APIに集約されました。

なぜサービスが終了するのですか？

Microsoftは、ビジネスの他の領域に注力するためであると主張しています。さらに、Microsoftパートナーエコシステムによるソリューションを推進しています。メディアおよび放送分野をサポートするために必要な複雑な開発に追いつこうとするよりも、パートナーがクラウドに独自の環境を導入し、それをマーケットプレイスやサービスを通じて利用できるようにする方が、財務的に非常に理にかなっています。

奇妙なことに、これは2019年のAkamai Media Servicesの廃止とあまり変わりません。しかし、Akamaiが世界のOTTトラフィックの大部分を処理していた（そしておそらくFastlyの急成長前だった）当時、パブリッククラウドからAkamaiのオリジンへのエグレス（送信）コストを削減できることを考えれば、彼らのサービスにはもっと先があると思っていました。

最後に、AWSがElementalに投資する前のことを思い出してください。同社の独自のメディアスタックであるElastic Transcoderの機能は、少し物足りないものでした。競合して追いつこうとするよりも、買収やパートナーシップを結ぶ方が理にかなっていたもう一つの事例です。Amazonの予算をもってしてもそうだったというのは、多くのことを物語っています。

猶予はどれくらいありますか？

2024年6月です。長い時間があるように聞こえますが、その期日はあっという間に近づいてきます。すでにこの件に関するプロジェクトのスコープ設定を行っていますが、エンドツーエンドのサイクルを考慮すると、タイムラインは限界まで引き延ばされることを証言できます。

どのような選択肢がありますか？

良いニュースは選択肢がたくさんあることです。悪いニュースもまた、選択肢がたくさんあることです。

Azureパートナーネットワークのソリューション

Azure Blobにコンテンツをすでに保存している場合（移行に伴うその他のコストについては留意が必要ですが）、AWSにコンテンツを抽出するよりも、これが最も費用対効果の高いアプローチの一つになる可能性があります。メザニンアセットを保存している場合、テラバイト（TB）やペタバイト（PB）単位のコンテンツをAWSのような環境にエグレス（送信）するコストは、受け入れがたいものになる可能性があります。Bitmovin、Telestream、DolbyなどのベンダーはAzure上で優れたソリューションを提供していますが、後述するように、これらを接続するための開発作業が必要になります。

Amazon AWS

現在提供されている中で、おそらく最高の「クラウドネイティブ」なソリューションセットです。AWSはElementalのソリューションセットを自社システムに見事に統合しました。しかし、Azureから移行する場合は少しのハードルがあり、統合だけでなく単純なコンテンツ移行を容易にするためのコスト増が発生する可能性があります。非常に勇敢な方であれば、AWSスタックの下でAzure Blobを使用するという選択肢も常にあります！AWSは、機能の一部が重複する別々のスタックとしてソリューションを実行していますが、最高にスケーラブルで柔軟なソリューションを得るためには、いくつかの作業が必要になります。適切に構築すれば、優れたスループットと優れた機能を備えた、信じられないほど強力なワークフローになります。構築が不適切であると、コンテンツがどこにあるのか、何が起きているのか、なぜ拡張されないのかを見失うリスクがあります。

Google GCP

Googleはメディア＆エンターテインメント分野で進歩を遂げており、基本的なメディア準備と配信のための比較的優れたソリューションセットを持っています。GoogleはYouTube（間違いなく世界最大のメディア変換プラットフォームの一つであり、莫大な配信インフラを持っています）を所有しているため、書面上ではこれが最もスマートな選択肢であるように思われます。一部のトリミングを伴う基本的なHLS/DASHを生成するフリーミウムサービスであれば問題ありませんが、それ以上の高度な機能については、ワークフローにサードパーティの要素/ツール/サービスを繋ぎ合わせる必要がある、かなりのソリューションギャップが存在します。

他にはありますか？

はい、たくさんあります。大手パブリッククラウドプロバイダー以外にも、SaaSやPaaSベースのメディア変換・配信ツールを提供するベンダーが数多く存在します。マーケットプレイスを介してパブリッククラウドと高度に統合されているものもあれば、クラウドで非常にうまく動作するものの、周辺要素をデプロイ、設定、管理する必要があるものもあります。リストを作り始めると、書き終わる前に髭が伸びてしまうでしょう。しかし、重要なのは、移行にどのように取り組むかです。

移行前に何を評価すべきですか？

機能のギャップ分析

ここでの良いニュースは、非常に多くの選択肢が存在することです。移行によって、純粋な機能面では失うものよりも得るものの方が多いでしょう。しかし、これは慎重に比較・評価される必要があります。詳細は細部に宿ります。ミッドセグメントのスプライシング、マニフェスト操作、オーディオトラックのマッピング、またはHDRワークフローの処理といった複雑な処理を行っている場合は、処理を進める前にPOC（概念実証）を行って機能とアプローチを確認することを勧めます。クライアント側のテストの要素や、プレイヤーにおけるコンテンツの動作がどのようになるかが極めて重要であることを強調しておきます。サプライヤー間のスペックバージョンの違いは、多くの人が見落としがちなポイントです。

統合および移行コスト

Azureからワークフローやワークロードを移行することが、周辺の統合機能やシステムに大きな影響を与えないと考えるのはナイーブです。MAMソリューションからのアップロード、ワークフローの監視、ストレージ、サードパーティへの配信、あるいはQC（品質管理）などがこれに該当します。パッケージソリューションを使用している場合、これらのいくつかはサードパーティへの仕様変更要求が必要になる場合があります。そのコストと作業時間も全体のタイムラインに考慮する必要があります。遅延を考慮してバッファを設けるように注意してください。

コスト分析

正確で現実的な全体像を把握するためには、コスト分析に以下の項目を含める必要があります。

• コンピュートユニットの価格、

• ストレージの価格、

• 転送コスト、

• チェーン内の周辺システムとの統合コスト、

• 監視、運用、サポートのコスト、

• ドキュメントやプロセスの更新

その他多数あります。

AWSなどで提供されているマーケットプレイス環境からデプロイする場合は、コンピュートコストと、必要となる可能性のある追加のライセンスコストを比較するよう注意してください。マーケットプレイスのサービスの一部には、コンピュートインスタンスの1時間あたりのコスト内にソフトウェアライセンスが含まれているものもありますが、その他はBYOL（独自のライセンス持ち込み）です。アーキテクチャとデプロイをスマートに行えば、コンテンツを処理していないときのベースの運用コストを非常に低い数字に抑えることができます。通常の稼働率であれば、基本的にはストレージとネットワーク要素などのいくつかのサービスオーバーヘッドのみになります。

これはハイレベルな記事ですが、移行が必要な立場にある方にとって、どこに焦点を当てるべきかの有用な手引きとなることを願っています。最後に、正しい方向に進むためのサポートやヒントが必要でしたら、ぜひご連絡をお待ちしております。