次の方法で共有

Microsoft Azure

Microsoft Azure Media Services

Gregory Prentice

コード サンプルのダウンロード

長年にわたって、マイクロソフトは大規模なライブ ストリーミング ビデオ配信の設計を支援し、サポートを提供してきました。その大きな例の 1 つが 2014 年のソチ オリンピックです。このときは、サーバー ハードウェア、ソースとなるビデオ ストリーム、エンコーディング、冗長サーバー (二重化したデータセンター)、出力対応型のビデオ ストリーム、コンテンツ配信ネットワーク (CDN)、パートナー企業、そして当然マイクロソフトのスタッフなど、莫大な数の技術リソースを必要としました。

顧客のソフトウェア開発であっても、障害をほぼ発生させることなくエンド ツー エンドのライブ ビデオ イベントを成功させるには、このようなリソースがすべて必要になります。このようなリソースを編成するコストは、ライブ ストリーミング イベントの規模によって変わりますが、必要なサーバー、スイッチ、関連テクノロジの購入などにかかる資本支出は高額になります。これは明白なリスクにつながり、次のような疑問も生じます。

  • その規模のライブ イベントにしては購入したハードウェアが多すぎたのではないか
  • 次回のイベントまで購入したハードウェアをどのように扱えばよいか
  • 入手したテクノロジはどの程度の期間有効か
  • 問題なくイベントを編成するために適切なテクノロジ パートナーが参加していたか

それまでライブ ビデオ イベントにかかわったマイクロソフトの知識と成功体験を踏まえ、Microsoft Azure Media Services チームがこうしたリスクを緩和するライブ ストリーミングを開発しました。そして、2014 年ソチ オリンピックで同チームは、Microsoft Azure Media Services 上で実行するライブ グローバル ビデオ フィードのストリーミングに成功しました。きわめて大掛かりなイベントでしたが、Microsoft Azure はオンデマンドでハードウェアを提供し、スケーラビリティに対処しました。

Azure Media Services への要求は、ライブ ビデオ イベントの規模に応じて、大、中、小の単位で行うことができ、数十万の閲覧者からわずか数百人の閲覧者までライブ ビデオのストリーミングを可能にします。イベントの前にコストが分かっていれば、ライブ ストリーミング サービスの作成、使用、および配信に従量課金制モデルを利用することができます。ハードウェアとインフラストラクチャは、絶えずアップグレードされ、最新の状態に保たれます。マイクロソフトは、ライブ ストリーミング ソリューションの提供に関連する戦略的なリレーションシップも維持します。

今回は、Microsoft Azure Media Services チームの新しいライブ ストリーミング (現在はプライベート プレビュー版)を使用するサンプル シナリオを取り上げ、先ほど示したリスクに対処する方法について説明します。また、既存のビデオ オン デマンド (VOD) サービスへのライブ ストリーミングの提供に関するリレーションシップについても紹介します。

考え方と用語

Azure Media Services に関する一般的な考え方や用語を理解しておくことは重要です。「チャネル」とは、開発者から見た場合、1 つのライブ ビデオ ストリームが Azure Media Services を経由する際に通る完全なエンド ツー エンドの経路のことです。チャネルはさまざまな状態になりますが、「停止」と「実行中」が最も重要な状態です。チャネルには、次のコンポーネントが含まれ、各コンポーネントがシステムを経由するビデオ ストリームを調整します。

  • 取り込み URI (Ingest URI): チャネルが配信用に 1 つ以上のビデオ ビットレート ストリームを受信する取り込みポイントを表します。
  • プレビュー URI (Preview URI): チャネルが受信したライブ ストリームの出口ポイントを表します。監視目的にのみ使用します。
  • プログラム (Program): チャネルに関連付けられ、ライブ ストリームの中で Blob ストレージにアセットとして保存される各部分を表します。1 つのチャネルには少なくとも 1 つのプログラムを作成し、実行中状態になるとライブ ビデオ ストリームを有効にします。実行中状態のとき、プログラムはアクティブにビデオを取り込むことになります。
  • アセット (Asset): プログラムに関連付けられ、Blob ストレージに保存されたデータを表します。アセットは、ビデオ、オーディオ、画像、サムネイルのコレクション、マニフェストなどの、1 つ以上のファイルを保持します。アセットはプログラムを削除後も存在していることができます。
  • ロケーター (Locator): アセットと配信元に関連付けられます。ロケーターは、ライブ プログラム ストリームの出口ポイントとして使用される URI を提供します。
  • 配信元 (Origin): ロケーターと関連付けられ、ビデオ ストリームを配信するためのスケーラブルな出口ポイントを表します。配信は、Smooth、HTTP ライブ ストリーミング (HLS)、Dynamic Adaptive Streaming over HTTP (DASH) など、さまざまなマルチ ビット レート (MBR) 形式でアセットのロケーター URI から行われます。

Azure Media Services は、適切な冗長性を確保して、スケールに応じた信頼性の高いビデオ配信を利用可能にします。配信には、Smooth、HLS、DASH など、さまざまなストリーミング形式を利用する多くのデバイスが関与する可能性があります。図 1 に、チャネルの構成要素を示します。

ライブ ビデオ ストリームの完全なエンド ツー エンドの経路を表す配信チャネル
図 1 ライブ ビデオ ストリームの完全なエンド ツー エンドの経路を表す配信チャネル

重要なのは、チャネルと、チャネル内に作成する 1 つ以上のプログラムの関係を理解することです。図 2 は、ライブ ビデオ イベントを、午後 5 時から午前 2 時までの実行中状態のチャネル表現に対応付けたものです。チャネルが停止状態から実行中状態に切り替わるのに 10 ～ 20 分必要になることが分かります。Concert1、Vip1、Act1、Act2、Vip2 などのマーカーがプログラムを表し、開始予定時刻と停止予定時刻が設定されます。Transition というマーカーは、現在のプログラムが停止されてから次のプログラムが開始されるまでの間隔を表します。

午後 5 時から始まり、午前 2 時に終了するライブ ビデオ イベント
図 2 午後 5 時から始まり、午前 2 時に終了するライブ ビデオ イベント

これは、プログラムを使ってチャネルにタイムラインをマップする方法を示す 1 つの例です。図 2 に示したように、イベント全体を表すプログラムが 1 つあります。

この Concert1 は、午後 5 時 15 分 ～ 午前 2 時まで実行中の状態になり、10 分間のスライド ビデオ バッファーがあります。スライド ビデオ バッファーを設けることで、ユーザーがメディア プレーヤーの表示を巻き戻せるようにしています。Concert1 プログラムは、イベント全体のプライマリ ライブ ビデオ ストリームを提供します。CDN には、イベントが始まる前にマッピングのために URI が提供されます。

Vip1、Act1、Act2、Vip2 などの残りのプログラムは、定義された開始時刻と停止時刻の間は実行中状態になりますが、切り替え時間のばらつきは許容されます。プログラムは即座に開始または停止することはありません。ライブ イベントを計画するときは、切り替え時間を考慮する必要があります。すべての取り込みビデオを同時に実行中状態にする複数のプログラムを用意することができます。Concert1 とその他のプログラムはイベントの進行中に開始および停止することになります。切り替えの使用方法を示すには、午後 6 時 45 分に Act1 プログラムの開始要求を発行してから、午後 7 時に Vip1 プログラムの停止要求を発行します。これにより、15 分の切り替え時間が用意されます。したがって、この 15 分の切り替え時間中は 3 つのプログラムが実行中状態になる可能性があります。

ここでは、一般的な考え方と用語について説明しましたが、ここからは図 2 で示したユーザー シナリオにマップされるイベントのタイムラインを中心に、Azure Media Services API を使用した開発コーディング例について説明します。

テーマ: Contoso 社のブルースバー

Contoso 社のブルースバーは、将来有望なミュージシャンに人気がある米国のコンサート会場です。同会場では、「Contoso and the Shock Wallets」というヨーロッパの人気バンドのライブ コンサートが予定されており、当日まであまり時間がありません。このバンドのファンの多くはヨーロッパにいます。ブルースバーでの公演がこのバンドの米国でのデビューになります。そのため、マネージャーは、ヨーロッパのファンが PC やモバイル デバイスでコンサートを視聴できるように、コンサートのライブ ストリーミングを考えています。

ブルースバーを運営する Contoso 社の CIO は会議を開き、次の要件を満たすソリューションを調査し、提案するようテクノロジ チームに求めました。

  • 簡単に実装できること
  • さまざまな構成の大量のデバイスにビデオをストリーミングできること
  • 想定外のスケーラビリティのニーズに対応できること
  • イベント中のコストは利用内容に応じた従量課金であること

ステップ 1

ブルースバーを運営する Contoso 社のイベント企画チームは、数日掛けて今回考え得るユーザー ストーリーをいくつか定義します。このユーザー ストーリーが、ライブ コンサートのビデオ ストリーミングを配信する短期計画の基礎になります。このステップ 1 の実行中に、チームは会議を重ねながら、多くのスパイク、つまり解決すべき問題点につながる認識のずれを確認します。ユーザー ストーリーのリストは、「～が～できるように、～する必要がある」という形式で定義します。

「Contoso and the Shock Wallets」のファンがバンドの米国デビューをエンジョイできるように、自分のデバイスを使って最高品質のビデオでライブ コンサートを視聴できるようにする必要がある。

「Contoso and the Shock Wallets」のファンが時間があるときに公演を視聴できるように、後日自分のデバイスを使って最高品質のビデオでライブ コンサートを視聴できるようにする必要がある。

Contoso 社のブルースバーの代表がコストを抑えてより多くのミュージシャンや観客を魅了できるように、コンサートのライブ ブロードキャスト配信と、会場からのライブ ストリーミング ビデオの配信コストの削減を実現する必要がある。

各ユーザー ストーリーと関連するスパイクの調査は以下のように行います。

ユーザー ストーリー 1.1: イベント製作スタッフがライブ コンサートを取り込めるように、カメラを 1 台以上用意する必要がある。

スパイク 1.1.1: 用意するカメラの種類と出力ビデオ ストリームの形式は何か。

製作スタッフは、Serial Digital Interface (SDI) 経由でハイビジョン (HD) ビデオ/オーディオ ストリームを生成するために、高解像度のビデオ カメラを購入する必要があると判断しました。

ユーザー ストーリー 1.2: イベント製作スタッフはファンがコンサートを視聴できるように、ライブ ビデオをインターネットにストリーミングする必要がある。

スパイク 1.2.1: カメラのビデオ フィードを製作現場にどのように配信するか。

製作スタッフは、Contoso Switch Company 社が HD SDI と光ファイバー間のビデオ スイッチを製造していることを調べ、最大 4 台のカメラをつなげることが分かりました。

スパイク 1.2.2: ビデオ フィードを IT 部門にどのように配信するか。

製作スタッフは、光ファイバーのビデオ スイッチから HD SDI ビデオ/オーディオ ストリームが出力され、オーディオ/ビデオ スイッチに接続できることを調べ、ブロードキャスト パネルを使って、どのカメラ信号をアクティブにするかを制御できることが分かりました。ライブ ビデオ フィードは、最終的にブロードキャスト パネルから HD SDI 接続によって送信されます。

ユーザー ストーリー 1.3: IT スタッフはコンサートのビデオをサポートするデバイスの種類が最大になるように、Windows デバイス、iOS デバイス、Android デバイスにビデオ ストリームを配信する必要がある。

スパイク 1.3.1: インターネットにビデオを配信するために IT 部門が受信するビデオ フィードの種類は何か。

HD SDI ビデオ フィードが IT 部門に送信されます。

スパイク 1.3.2: ターゲットとするデバイスに必要なビデオ フィードの種類は何か。

IT スタッフは、以下のアダプティブ ビデオ プロトコルを使用すれば、ターゲットとする各デバイスにビデオを配信できると判断しました。

  • Smooth Streaming: Windows 8 と Windows Phone 8
  • HLS: iOS と Android
  • DASH: Windows 8.1、Windows Phone 8、Xbox One

スパイク 1.3.3: スケーラブルな手法でインターネットにビデオを配信するにはどうすればよいか。

IT スタッフが、インターネット経由のライブ ビデオのストリーミングに特化した Azure の新機能をマイクロソフトが発表したことを調べました。少し調査したところ、チームは Azure Media Services を使用して講演会場とターゲットとするデバイスの間に中間層を用意できることが分かります。最も重要なのは、Azure Media Services について以下の詳細を理解したことです。

  • Azure アカウントにサインアップして Media アカウントを追加すれば、ライブ ストリーミング チャネルを作成できる。ライブ チャネルは TV チャネルに相当します。割り当てられるすべてのサーバー リソースはそのチャネル専用になり、プログラムの配信に使用されます。チャネルには多くのプログラムを含めることができます。プログラムは、時間帯と関連するアセットを定義します。アセットは、Azure Media Services におけるストリーム ビデオの保存場所です。
  • サーバーの割り当てでは、ビデオ パスに冗長性が組み込まれ、単一障害点がなくなることが保証される。
  • ライブ ビデオ ストリームは、取り込み URI 経由で Azure Media Services によって、RTMP または MPEG TS として受信できる。
  • デバイスからは、そのデバイスがネイティブにサポートするビデオ ストリームを要求できる。Microsoft Azure Media Services は、デバイス固有の URI を基に適切な形式でビデオをパッケージ化することを保証します。
  • Akamai Technologies などの CDN プロバイダーが安全にアクセスするためのサポートが、ライブ ストリーミングの配信元サーバーに組み込まれている。

スパイク 1.3.1 と 1.3.2 の追加の結果: IT スタッフは、HD SDI ビデオ/オーディオ ストリームを受信するエンコーダーを選択できることが分かりました。このエンコーダーは、HD SDI ストリームから複数のビットレート ストリームを動的に作成して、Azure Media Services に配信できます。Azure Media Services は、入力形式として RTMP または MPEG TS を受け取る取り込み URI を提供します。

ステップ 2

いつものようにモーニング コーヒーを飲んだ後、開発者はライブ ストリーム イベントをサポートするコードの開発に取り掛かります。

ユーザー ストーリー 1.4.1: 開発者はビデオをストリーミングするコードの作成に着手できるように、適切な Azure アカウントを作成する必要がある。

Azure Web サイト (azure.microsoft.com) に移動し、[無料で試す] ボタンをクリックして表示される手順に従います。アカウント設定の詳細については、bit.ly/1mfacft (英語) を参照してください。サインアップ プロセス中に、管理者の資格情報として使用する Windows アカウントを作成することができます。ライブ イベントのビデオ アセットは Blob ストレージに保存することになるので、まず Azure Storage アカウントを作成してから、Azure Media Services カウントを作成します。Azure Media Services のドキュメントでは、Azure Media Services アカウントを作成したのと同じデータセンターでストレージ アカウントを作成することが推奨されています。たとえば、US-WEST データセンターでストレージ アカウントとメディア アカウントを作成します。

ユーザー ストーリー 1.4.2: 開発者がライブ ストリーミング イベントを配信できるように、チャネルを管理するコードを作成する必要がある。

Visual Studio 2012 を使用してベース プロジェクトを作成します。次に、Azure Media Services 用の NuGet パッケージをインストールします。CreateContosLiveEvent という関数を作成し、ライブ ストリームを管理するために使用する CloudMediaContext オブジェクトから作業に着手します。

private void CreateContosLiveEvent()
{
  string liveAccount = "yourAzureMediaAccount";
  string liveKey = "yourAzureMediaAccountKey";
  CloudMediaContext LiveServices = new CloudMediaContext(
    liveAccount,  // URI created earlier
    liveKey );    // Account name

配信元サービスが確実に実行中になるようにコードを記述します。配信元サービスがライブ ストリームを CDN プロバイダーに配信します (図 3 参照)。

図 3 コンテンツ配信ネットワーク プロバイダーにライブ ビデオ ストリームを配信する配信元サービス

string originName = "abcdefg";
IOrigin origin = LiveServices.FindOrigin(originName);
if (origin == null)
{
  Task<IOrigin> originTask = 
    LiveServices.Origins.CreateAsync(originName, 2);
  originTask.Wait();
  origin = originTask.Result;
}
if (origin.State == OriginState.Stopped)
{
  origin.StartAsync().Wait();
}

次に、チャネルを作成するコードを作成する必要があります (図 4 参照)。チャネルでは、着信するビデオ ストリーム ソースの認証を許可できるようにセキュリティを構成する必要があります。通常、ソースは IP 構成のエンコーダーで、HDI SDI 信号を必要な MBR ビデオ ストリームに変換します。

図 4 ビデオ フィード用チャネルの作成

string channelName = "ContsoBluesChannel";
IChannel channel = LiveServices.FindChannel(channelName);
if (channel != null)
{
  Debug.WriteLine("Channel already exists!");
  return;
}
ChannelSettings settings = new ChannelSettings();
Ipv4 ipv4 = new Ipv4();
// Currently setting IP to 0.0.0.0/0 allows all connections
//  Don't do this for production events
ipv4.IP = "0.0.0.0/0";
ipv4.Name = "Allow all connections";
// Protect the ingest URI
settings.Ingest = new IngestEndpointSettings();
settings.Ingest.Security = new SecuritySettings();
settings.Ingest.Security.IPv4AllowList = new List<Ipv4>();
settings.Ingest.Security.IPv4AllowList.Add(ipv4);
// Protect the preview URI
settings.Preview = new PreviewEndpointSettings();
settings.Preview.Security = new SecuritySettings();
settings.Preview.Security.IPv4AllowList = new List<Ipv4>();
settings.Preview.Security.IPv4AllowList.Add(ipv4);
// Create the channel
Task<IChannel> taskChannel = LiveServices.Channels.CreateAsync(
  channelName, "video streaming", ChannelSize.Large, settings);
taskChannel.Wait();
channel = taskChannel. Result;

このサンプル コードは、"0.0.0.0/0" に設定されたクラスのないドメイン間ルーティング (CIDR) 形式の IP アドレスを使用して、取り込み URI とプレビュー URI を構成しています。これにより、すべての IP アドレスから取り込み URI とプレビュー URI にアクセスできるようになります。実運用するチャネルでは、エンコーダーの IP アドレスや認証トークンの IP アドレスなどの既知の値を使用して、アクセスを制限するようにします。チャネル名は一意にします。同じ名前のチャネルがあると、例外がスローされます。

プログラム、関連アセット、およびロケーターを作成するコードを記述します (図 5 参照)。名前とタイムラインに使用する値は 図 2 に示す値と同じものにします。Concert1 を除くすべてのプログラムの作成中は、enableArchive フラグを true に設定します。値 true は、プログラムが実行中状態の間はライブ ビデオ ストリームが取り込まれることを示し、後で VOD として使用するために関連アセットと共に保持されている間はこの値が保持されます。アセットのマニフェスト ファイルに 30 日間のアクセス ポリシーが付属するロケーターを作成します。これはストリーミング ビデオへの URI を提供します。

図 5 フィード中に実行するプログラムの作成

// Define the program name, DVR window and estimated duration in minutes.
// NOTE: DVR window value most likely will be removed when service 
// reaches public preview.
Tuple<string, int, int>[] programSettings = new Tuple<string, int, int>[]
{
  new Tuple<string,int,int>( "Concert1", 60, 60 ),
  new Tuple<string,int,int>( "Vip1", 75, 75 ),
  new Tuple<string,int,int>( "Act1", 90, 90 ),
  new Tuple<string,int,int>( "Act2", 165, 165 ),
  new Tuple<string,int,int>( "Vip2", 120, 120 ),
};
foreach (Tuple<string, int, int> programSetting in programSettings)
{
  IAsset asset = null;
  // To persist specific program's asset for Video on Demand (VOD) this
  // code tests if the DVR window and Event duration equal in length.
  // If true it sets the enable archive flag to true, which tells the
  // system a program's asset should not be deleted automatically.
  bool enableArchive = programSetting.Item2 == programSetting.Item3;
  try
  {
    // Create the asset that is used to persist the video streamed
    // while the program is running and VOD.
    asset = LiveServices.Assets.Create(programSetting.Item1 + "_asset",
      AssetCreationOptions.None);
    Task<IProgram> taskProgram = channel.Programs.CreateAsync(
      programSetting.Item1,
      "program description",
      // Enable archive note forcing to true for now
      true, // enableArchive,
    // NOTE: DVR window value most likely will be removed
    // This is not used
    TimeSpan.FromMinutes(programSetting.Item2),
    // Estimated duration time
    TimeSpan.FromMinutes(programSetting.Item3),
      asset.Id);
    taskProgram.Wait();
    LiveServices.CreateLocators(asset, TimeSpan.FromDays(30));
  }
  catch (Exception exp)
  {
    Debug.WriteLine(exp.Message);
  }
}

Azure Media Services の VOD アセットと同様に、ロケーターから配信元 URI を取得できます。取得した URI は選択した CDN プロバイダーに提供することになります。enableArchive フラグを設定したので、プログラムが停止した後、同じ配信元 URI を使用してライブ ストリームを VOD アセットとして配信できます。

残っているのは、必要に応じてチャネとプログラムを開始するコードの作成です。チャネルを開始する要求によって Azure Media Services へシグナルが送られ、取り込みサービス、冗長性、負荷分散へのリソース割り当てが始まります。チャネル開始時には、開始状態から実行中状態になるまでには 10 ～ 20 分かかる可能性があります。

イベントの開演前に余裕を持って早めにチャネルを開始することで、ライブ ビデオ ストリームの表示機能に悪影響を及ぼさないようにします。また、チャネルを開始すると、課金が開始されることにも注意が必要です。年中無休の 24 時間のライブ チャネルを予定していない場合は、使用しなくなったチャネルと関連プログラムを停止します。チャネルを開始するのに実際に必要なコードはかなりシンプルです。

// Start channel
Task start = channel.StartAsync();
start.Wait();

プログラムの開始に必要なコードもシンプルです。

start = program.StartAsync();
start.Wait();

イベントの主な要件の 1 つは、チャネルと各プログラムの開始時刻と停止時刻を制御できることでした。したがって、次に開発するのは、CreateContosLiveEvent を呼び出してイベントそのものを作成するシンプルな UI です。これにより、必要に応じて、チャネルとチャネルに対応するプログラムを開始および停止できるようになります。

Azure Media Services を使用するアプリを開発すると同時に、他のチーム メンバーも、シナリオを完結させるためにカメラの設定、ケーブルの配線、ビデオ エンコーダーのインストール、CDN の構成などに忙しく働きます。最後に、製作スタッフは一連のテストを実行して、エンド ツー エンドのシナリオが機能することを保証します。

実際のコンサートが開演する直前にライブ ビデオのストリーミングが開始され、さまざまなユーザー デバイス、デスクトップ、およびタブレットから Azure Media Services に接続してライブ ビデオ ストリームを視聴できるようになります。テストの実行で発見できない問題は常に存在しますが、スタッフは絡み合う問題を解決し、困難なすべての作業を時間どおりに完成させて、コンサートのライブ ビデオ ストリーミングを配信することができました。

手間が掛かる作業を容易にする

ライブ ビデオ イベントを実際にホストするのは手間が掛かる作業です。Azure Media Services などのソリューションが提供される以前は、ライブ ストリーミング ビデオを配信するのに、インフラストラクチャに膨大な設備投資が必要になることがよくありました。また、サイズや規模が異なるさまざまなイベントをサポートするのに必要なシステムの量も重要な決断事項の 1 つでした。このようなシステムの購入では、購入不足に陥ったり、購入過多になることもよくありました。Microsoft Azure Media Services を使用すれば、このような複雑性やコストの問題に対処できるようになります。このライブ サービスは Azure Media Services VOD 機能セットを土台に構築されており、適正規模で業界にライブ コンテンツと VOD コンテンツの両方を配信するための単一で統一されたプラットフォームと API を提供します。

Gregory Prentice iは、経験豊かなソフトウェア アーキテクトとして、多くの新興企業用アプリケーションを 25 年以上にわたって設計および作成しています。彼はマイクロソフトに勤務し始めて、Locadio、Microsoft Hohm、および Microsoft Utility Rates Service といったプロジェクトを開発しました。最近では、Microsoft Azure Media Services チームおよび Delta Tre チームによる、2014 年ソチ オリンピックのライブ ビデオ ストリーム配信をサポートしました。現在、彼はマイクロソフトの開発者およびプラットフォーム エバンジェリズム グループのエバンジェリストです。彼のブログは、blogs.msdn.com/b/greg-prentice (英語) で公開されています。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Steven Goulet (Live Services の主任 PM) および Jason Suess (前回オリンピックの Live Services) に心より感謝いたします。