Freigeben über

Media Services のための Storage

  • Artikel

このポストは、7 月 1 日に投稿した Storage for Media Services の翻訳です。

Storage は、メディア ワークフローのコンポーネントとして不可欠な要素です。Media Services アカウントを作成すると、ストレージ アカウントを作成するか、既存のものを選択するように求められます。Media Services では、Asset という概念を用いてメディア コンテンツを管理します。Asset のメディア ファイルはストレージ アカウントに格納され、Asset のエンティティ メタデータは Media Services の内部リポジトリに格納されます。

このブログ記事では、Storage と Media Services を併用する場合に注意すべき次のトピックについてご説明します。

  • Storage の冗長性
  • ストレージ キー
  • Storage の拡張
  • Storage Analytics とログ記録
  • Storage 内のメディア資産
  • 資産のアップロード
  • Storage の料金

Storage の冗長性

Microsoft Azure のストレージ アカウントに格納されたデータは必ずレプリケートされ、一時的なハードウェア障害が発生した場合でも Azure Storage SLA を満たすように、耐久性と高可用性が保証されます。Azure Storage では、冗長性を実現するためにいくつかのオプションを利用できます。本番環境の Media Services アカウントに関連付けられたストレージ アカウントの場合は、そのアカウントを「地理冗長ストレージ (GRS)」または「読み取りアクセス地理冗長ストレージ (RA-GRS)」に設定することをお勧めします。これらのオプションでは、洪水や台風など、地域レベルの災害に対してデータが保護されるためです。データをレプリケートする方法はストレージ アカウントを作成した後でも変更できますが、LRS (ローカル冗長ストレージ) から GRS または RA-GRS に切り替えた場合、1 回分のデータ転送コストが追加で発生する可能性があるのでご注意ください。

ストレージ アカウントのレプリケーションを管理する方法の詳細については、ストレージ アカウントのレプリケーションを管理する方法 (英語) の記事を参照してください。LRS、GRS、RA-GRS の料金設定はそれぞれ異なります。詳細については、Storage サービスの料金詳細のページをご覧ください。

ストレージ キー

ストレージ アカウントを作成すると、512 ビットのストレージ アクセス キーが 2 つ生成されます。これらのキーは、ストレージ アカウントにアクセスする際の認証に使用されます。ストレージ キーは安全に保管してください。一部のコンプライアンス基準では、定期的なキーの再生成が求められます。お客様の企業が対応しているコンプライアンス基準に応じて、キーの再生成のポリシーを定義する必要があります。

Media Services では、ストレージ アカウントのメディア データの読み取りおよび書き込みに 1 つのストレージ キーを必要とします。Azure 管理ポータルを使用して Media Services アカウントを作成した場合、Media Services に格納されたストレージ キーがプライマリ ストレージ キーとなります。ストレージ キーを再生成する場合は、Media アカウントが引き続き想定されるとおりに機能するように、更新された有効なキーを入力する必要があります。Media Services ベースのアプリケーションが中断しないように、キーの再生成は 1 つずつ行ってください。

Media Services アカウントが中断しないようにキーを再生成する手順は、次のとおりです。

  1. Media Services でプライマリ ストレージ キーが参照されている場合、セカンダリ ストレージ アカウント キーを使用するように変更します (この一連の手順の後でご説明します)。
  2. Media Services を使用した操作を行う場合は、(サービス全体に更新されたキーが反映されるように) 30 分間待ってから実行します。この手順を省略しないでください。
  3. プライマリ ストレージ アカウント キーを再生成します (ストレージ アクセス キーを表示、コピー、再生成する方法 (英語) を参照してください)。
  4. 新しいプライマリ ストレージ アカウント キーを使用するように Media Services を更新します。
  5. 上記と同じ手順でセカンダリ アクセス キーを再生成します。

 

再生成したストレージ キーと Media Services を同期するには、次の 2 つのいずれかの方法を使用します。

  • Azure 管理ポータルを使用する: Media Services アカウントを選択し、ポータル ウィンドウの下部の [MANAGE KEYS] アイコンをクリックします。Media Services と同期するストレージ キーに応じて、 [synchronize primary key] または [synchronize secondary key] ボタンを選択します。

 

  • Media Services の管理 REST API を使用する: ストレージ アカウント キーを更新 (英語) します。
    次のコードは、https://endpoint/<subscriptionId>/services/mediaservices/Accounts/<accountName>/StorageAccounts/<storageAccountName>/Key 要求を構築し、指定したストレージ キーと Media Services と同期する方法のサンプルです。

public void UpdateMediaServicesWithStorageAccountKey(string mediaServicesAccount, string storageAccountName, string storageAccountKey)

{

    var clientCert = GetCertificate(CertThumbprint);

 

    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(string.Format("{0}/{1}/services/mediaservices/Accounts/{2}/StorageAccounts/{3}/Key",

        Endpoint, SubscriptionId, mediaServicesAccount, storageAccountName));

    request.Method = "PUT";

    request.ContentType = "application/json; charset=utf-8";

    request.Headers.Add("x-ms-version", "2011-10-01");

    request.Headers.Add("Accept-Encoding: gzip, deflate");

    request.ClientCertificates.Add(clientCert);

 

    using (var streamWriter = new StreamWriter(request.GetRequestStream()))

    {

        streamWriter.Write("\"");

        streamWriter.Write(storageAccountKey);

        streamWriter.Write("\"");

        streamWriter.Flush();

    }

 

    using (var response = (HttpWebResponse)request.GetResponse())

    {

        string jsonResponse;

        Stream receiveStream = response.GetResponseStream();

        Encoding encode = Encoding.GetEncoding("utf-8");

        if (receiveStream != null)

        {

            var readStream = new StreamReader(receiveStream, encode);

            jsonResponse = readStream.ReadToEnd();

        }

    }

}

Storage の拡張

1 つのストレージ アカウントには、Azure Storage のスケーラビリティおよびパフォーマンスのターゲットのページに記載されているように、拡張性およびパフォーマンスに関して一定の制約があります。メディア ファイルのサイズは非常に大きいため、ビジネスの規模によっては 1 つのストレージ アカウントでは不十分な場合があります。Media Services では、1 つの Media Services アカウントに複数のストレージ アカウントを関連付けることができます。そうすることで、次のようなメリットが生まれます。

  • 複数のストレージ アカウントで資産の負荷を分散します。
  • Media Services を拡張して、大量のコンテンツを格納、処理します。
  • 中間 (ソース) ファイル ストレージをストリーミング ファイル ストレージまたは DRM 保護されたファイル ストレージから分離します。

詳細については、次のトピックやサンプルを参照してください。

複数のストレージ アカウントでの Media Services 資産の管理

Azure Media Services での複数のストレージ アカウント間の資産の管理と負荷分散戦略の策定 (英語)

Media Services アカウントに関連付けられた複数のストレージ アカウントを管理する方法 (英語)

現時点では、複数のストレージ アカウントを関連付けるには Azure Service Management REST API (英語) を使用する必要があります。

Storage Analytics とログ記録

Azure Storage Analytics は、ストレージ アカウントのログを記録して、指標データを提供します。このデータを利用することで、ストレージ アカウントの要求のトレース、使用傾向の分析、問題の診断を行えます。Storage Analytics は Azure 管理ポータルから有効にすることができます。詳細については、ストレージ アカウントをモニターする方法 (英語) を参照してください。Media Services では、メディア データの格納に Blob サービスを使用しています。そのため、BLOB の詳細 (Verbose) 監視を有効にし、数日間の保持ポリシーを使用して BLOB のログ記録を構成することをお勧めします。Storage サービスでは、集計された分析データを BLOB および Table に格納します。これらは、それぞれ Blob サービス API および Table サービス API を使用してアクセスすることができます。このトピックの詳細については、Storage Analytics を参照してください。また、特に Metrics のテーブル スキーマおよびログの形式について、十分にご確認ください。Media Services では、ワークフローの統合、エンコード、配信に Storage が使用されます。Metrics のテーブル スキーマおよびログの形式を理解すれば、アプリケーションで発生した障害の分析にも非常に役立つでしょう。

Storage Client 2.1 リリース (英語) 以降では、要求実行および REST 要求に対してクライアント側のトレースを有効にすることができます。さらに、Azure Diagnostics (英語) ではトレース リスナーが提供され、これらのトレースをクラウドに保持する場合に、クライアントのトレース メッセージを WADLogsTable にリダイレクトすることができます。ログ データの形式の詳細については、Storage Client 2.1 リリース (英語) を発表したブログ記事の「クライアントのトレース」のセクションを参照してください。クライアント側のトレースと Storage のログ記録を併用することで、アプリケーションと Storage のやり取りを全体的に把握することができます。

Storage Analytics の関連情報

Storage 内のメディア資産

前述したように、Asset は 1 つのオーディオ ビジュアル プレゼンテーションを表す論理ユニットです。Asset には、AssetFile というエンティティによって表される 1 対多のメディア ファイルのコレクションが含まれます。Media Services では、Storage のコンテナーを使用して Asset を表します。AssetFile はブロック BLOB として Asset コンテナーに格納されます。Storage エクスプローラー アプリケーションを使用すると、Storage のデータを確認することができます。これらのアプリケーションの詳細については、Azure Storage エクスプローラーを参照してください。Media Services API の外部のコンテナーでは、Asset コンテナーまたは BLOB を追加、編集、削除しないでください。これらの操作を行うと、Media Services API を使用して構築されたメディア アプリケーションに含まれる Asset にアクセスする際に問題が発生する可能性があります。

また、現時点では、ブロック BLOB の上限は 200 GB となっているため、 AssetFile も 200 GB 以上とすることはできません。

資産のアップロード

メディア ファイルのサイズは非常に大きいため、Azure データセンターへのネットワーク接続によっては、ストレージ アカウントにメディア コンテンツをアップロードするために、Aspera (英語) が提供する転送テクノロジなどの UDP ベースの転送テクノロジの使用を検討することをお勧めします。Aspera では、Azure 上の Aspera fasp 高速転送ソフトウェアにアクセスできる Aspera On Demand for Microsoft Azure (英語) と呼ばれるサービスを提供しています。このサービスのサブスクリプションは Azure ストア (英語) から購入可能です。Azure に関する Aspera のサービスの詳細については、Aspera On Demand for Microsoft Azure (英語) を参照してください。また、よくある質問に対する回答については、Aspera On Demand for Microsoft Azure の FAQ (英語) をご覧ください。Aspera のサービスと Media Services の一括インジェスト API を併用すると、メディア コンテンツのカタログを一括でインジェストすることができます。詳細については、「Media Services SDK for .NET を使用して資産を一括インジェストする」のページを参照してください。.NET を使用する代わりに、一括インジェスト REST API を使用してプログラミングすることも可能です。

このトピックの詳細については、MSDN のトピック「メディアのアップロード」を参照してください。

Storage の料金

Storage サービスの料金詳細のページでは、Storage の料金に関する情報を提供しています。Media Services の場合、Azure アカウントの課金額はブロック BLOB によって決まります (前述のとおり、各 Asset はコンテナーとして表され、AssetFile はブロック BLOB として Asset コンテナーに格納されます)。そのため、Asset を作成して 1 GB の AssetFile を 1 つ追加すると、1 GB のブロック BLOB ストレージの料金が課されます。料金は、ストレージ アカウントを LRS、GRS、RA-GRS のどれに設定するかによって変わります。また、ブロック BLOB 以外にストレージ トランザクションの料金が適用されます。その他、ストレージ アカウントが存在するリージョンの外部にデータを転送する場合は、データ転送の料金が発生します。Azure データセンター内でのデータ転送には料金がかかりませんが、異なるリージョンの Azure サービスにデータを転送する場合にはデータ転送の料金がかかります。データセンター内でのデータ転送が発生するのは、Media Services でエンコード処理を実行する場合に、実際にエンコード処理が行われる VM に対してストレージ アカウントからデータがコピーされる際です。