Comments
Description
Transcript
クラウドを利用した 大規模動画配信システム
クラウドを利用した 大規模動画配信システム 菊池 正人＊ 岡村 基＊ 池原 勉＊ 細田 洋佑＊ 小池 重男＊＊ Large-scale Movie Streaming System Based on Cloud Service 要 旨 当社では，クラウド(AWS;Amazon Web Services)を利用する で通知する監視機能を実現し，従来の有人監視からシステ ことで大規模動画配信システムの構築を低コスト，かつ短 ムによる無人監視に切り替えている。 期間で実現した。 可用性では，目標稼働率である 99.99%を実現するために， 本システムの特長は，入力した 1 種類のライブ映像をシス クラウドのインスタンス（仮想サーバ）の稼働率（99.95%） テム内で 3 種類の配信方式に変換することにより，パソコ を,クラウド内のデータセンタ間で冗長化するシステムを構 ン／携帯電話／スマートフォン向けにライブ映像を提供で 築している。 きることである。 また，AWS サービスの特徴である利用時間による課金への対 また，パソコンライブ映像の最大同時視聴を 40,000 人とす 応として，時間帯による自動台数制御を行う方式を採用し る大規模配信を可能としている。 た。 運用面においては,クラウド内で持つ監視サービスに加えて その他，データベースフェールオーバの遅延，オンデマン オープンソフトウェアである Zabbix（注１）を併用することで ド配信，アクセス集計等，いくつかの課題に対応している。 システムの各種異常を自動で検知し，保守要員等にメール (注 1)Zabbix は，Zabbix SIA 社の登録商標である。 システムの概念図 ライブ映像の配信では，外部よりライブ映像のデータを受信し，EC2(Amazon Elastic Compute Cloud)の各インスタンス上で各メディア向けの変換 を行う。変換処理を行ったライブ映像データは，AWS（Amazon Web Services）の CDN(Contents Delivery Network)サービスである CF(Amazon CloudFront)を利用して配信する。一方，オンデマンド映像は，S3(Amazon Simple Storage Service)に一旦格納し，CF で配信する仕組みである。 *三菱電機インフォメーションシステムズ（株） **三菱電機（株）インフォメーションシステム事業推進本部 １． ま え が き により，初期設備は通信環境（回線・ルータ），運用・監 視用パソコン，入力画像エンコード機器のみとした。 当社は 2010 年 11 月にオンプレミスと社外 CDN サービスを (2)パッケージ利用とライセンス管理対策 組み合わせた大規模動画配信システムを開発し，ライブ映 構築スピードとコスト面から，携帯電話サービス対応，映 像／オンデマンド映像をパソコン／携帯電話向けに一般ユ 像視聴用画面処理，映像配信・変換処理にはクラウド上で ーザが視聴できるサービスを提供したが，これが本システ の動作検証，チューニングを実施した上で，既存パッケー ムの前身である。 ジを利用した。なお，一部パッケージのライセンス管理に 本システムでは，①システムコスト削減のため，オンプ おいて認証に物理メディアが必要であったが，パッケージ レミスからクラウドへの移行，②近年のユーザ数拡大への カスタマイズにより物理メディアでの認証を不要とし，ク 対応のため,パソコンライブの同時視聴者数を 20,000 人か ラウド上での利用を可能とした。 ら 40,000 人に拡張，③利用者が増加しているスマートフォ (3)クラウドサービス(AWS)停止時の対策 ン向けのライブ／オンデマンドサービスを追加の 3 つを目 クラウドサービス全体が停止した場合でも最小限のライブ 的としてシステムを短期間で再構築し，2014 年 8 月よりサ 映像サービスが継続できるように，オンプレミス環境上の ービス提供を開始している。 エンコード部から第三者の映像配信サービスへ映像を提供 本稿では，クラウド（AWS）を利用した大規模動画配信シ ステム構築における課題とその解決策について紹介する。 ２． システムの特長 本システムの特長は，20 種類の異なるライブ映像をパソコ できる機種を選定して，設計をおこなった。 (4)映像画質の HD(High Definition)化への対応 現状は縦横比 4:3 の SD(Standard Definition)画質での映像 サービスであるが，近い将来に 16:9 の HD 画質での映像サ ービス開始が想定されるため，映像入力インタフェース， ン／携帯電話／スマートフォン向けに提供できることである。 エンコード機器，WEB(World Wide Web)画面設計などで HD 配信方式として HDS（HTTP Dynamic Streaming）と HLS(HTTP 化対応を前提とした設計を行った。クラウド内のサーバリ Live Streaming)を用意することでパソコン／スマートフォ ソースについても，HD 化による負荷増加に柔軟に対応可能 ン（全ての Android(注２)端末／iOS 端末）をサポートしてい な構成とした。 る。また，携帯電話に関しては配信サーバと携帯電話側アプ (5)さらなる大規模動画配信への対応 リを一対とした独自方式とした。 今回構築したシステムでは，配信部からの同時配信数を最 一方，オンデマンド映像の配信に関しては，スマートフォン 大 40,000 人としているが，スマートフォンを中心とした同 での視聴を考慮して，前身のシステムが採用した WMV(注３) 時配信数のさらなる拡張にも耐えられる構成とした。 （Windows Media Video）形式から MP4（MPEG-4）形式に変 配信規模拡張への対応として実施した項目は以下のとおり。 更した。また，携帯電話への配信については，３キャリア ①配信部 （docomo （注４）／au （注５） ／SOFTBANK （注６））に対応するため， 現状でも十分な配信容量を保持しているが，バースト的な パソコン向けのオンデマンド映像から自動的にそれぞれの形 配信要求急増時に備え，配信部の利用制限値を見直してお 式に変換／蓄積することによりほとんどの携帯電話で視聴可 り，今後の定常的な要求増加にも対応可能である。 能となっている。 ②ポータル部 (注 2)Android は，Google Corp.の登録商標である。 クラウド内サーバリソースについてはスケールアップ（イ (注 3)Windows Media は，米国 Microsoft Corporation の米 ンスタンス増強），スケールアウト（インスタンス数増加） 国及びその他の国における商標又は登録商標である。 いずれの方法でも能力増強が可能な構成とした。 (注 4)docomo は，日本電信電話株式会社の登録商標である。 3.2 可用性向上への対策 (注 5)au は，KDDI 株式会社の登録商標である。 3.2.1 目標稼働率と設計・実装上の対処 (注 6)SOFTBANK は，ソフトバンク株式会社の登録商標である。 本システムの目標稼働率は，99.99％であるが，クラウド部 ３． クラウド化における課題と解決策 の公称インスタンス稼動率は 99.95％である。以下３項目の 本章では，前記システムの目的，特長を実現するために行 対策を実施することにより動画配信サービス全体としての った設計上の留意事項を 3.1 節で述べ，3.2 節以降で実装上 稼働率 99.99％を確保する設計を行った。 の主要課題と解決策について述べる。 (1)ポータル画面用 WEB サーバの耐障害性対策 3.1 設計上の留意事項 全体で最大 10 台の冗長構成を採用した。5 台ずつを異なる 設計時点で特に注力した留意事項は以下 5 項目である。 データセンタ上に分散して配置することで，WEB サーバ単位 (1)設備投資の最小化 での冗長構成のみではなく，クラウドで利用するデータセ エンコード部での最新機器の採用，クラウドサービス活用 ンタを含めて耐障害性を向上させた。 (2)ライブ配信用オリジンサーバ切り替え時の対策 部取得できないリソース情報があるが，監視対象インスタ 動画配信ソースデータの提供元となるオリジンサーバにつ ンスへ Zabbix エージェントをインストールすることで，こ いても，異なるデータセンタ上に分散配置したホットスタ れらリソース情報を監視可能にした。一方，RDS（Amazon ンバイ構成とし，障害発生などによる切り替え時の映像配 RDS for Oracle Database）など，OS へのログインができず， 信タイムラグの短縮を図った。 Zabbix エージェントを導入出来ないインスタンスについて (3)ポータル部用文字情報連携処理の二重化対策 は，Zabbix エージェントによるリソース情報を取得するこ 他システムとの通信を伴うポータル部の文字情報連携処理 とができないため，CloudWatch 経由で情報を取得すること については，接続先システム側の制約によりプライベート で対応を図った。このように，CloudWatch と Zabbix を併用 IP(Internet Protocol)での通信が必要であったが，クラウ することで，両者単独では監視できない，保守サポートに ド側の制約もあり，完全な二重化構成での実装ができなか 必要となる監視データを取得できるようにした。実際に監 った。対応策として，稼動系と待機系を別データセンタ上 視している項目の一部を表 1 に示す。 に配置するコールドスタンドバイ構成を採用した。 表1 3.3 監視項目 ○：監視可 ×：監視不可 監視の無人化（自動化）に向けた対策 本システムでは，24 時間無人監視とすることを目的に，自 動監視機能を搭載する設計とした。AWS には監視サービス （CloudWatch）が提供されているため，AWS 上のサーバイン スタンスの稼働状況を監視することでメトリクスを取得す ※CPU の全体使用率については，CloudWatch，Zabbix とも ることができる。メトリクスとは，サーバのリソース値を に監視可であるが，CPU の詳細情報 意味し，CPU(Central Processing Unit)使用率，ディスク (user,system,iowait,load average 等)に関しては， I/O(Input/Output)回数，ネットワーク流量，データベース CloudWatch は監視不可，Zabbix は監視可である。 コネクション数などを取得できる。取得されたメトリクス (2)メトリクス保存期間の拡大 については AWS コンソールに蓄積され，閾値を超えている CloudWatch で取得されたメトリクスを AWS 上で保存する場 場合にアラートメールを自動送信する。また AWS コンソー 合，最長 2 週間までしか保存されない。そのため．本シス ルにログインすることにより，これらのメトリクスを，図 1 テムでは CloudWatch で取得されたメトリクス，及び， のようなグラフ上で確認することができる。 Zabbix エージェントにより取得された監視データを Zabbix サーバに接続された RDS インスタンスに一元的に保存する 設計とした。その結果，最長 5 年間保存できるようになり， 稼働状況調査や障害調査時に，過去の監視データを遡って 参照できることとなった。 (3)障害検出時のインスタンスの自動制御 Zabbix では外部チェックと呼ばれる機能により，監視デ 図1 AWS マネジメントコンソール上でのメトリクスグラフ ータが閾値を超過した場合等をトリガ条件に設定して，外 （CPU 使用率） 部コマンドを実行することができる。また，AWS には AWS 本システムでは，CloudWatch に加え，統合監視ミドルウェ CLI と呼ばれるコマンドラインベースの API(Application アである Zabbix との連携による監視も行っている。 Programming Interface)が提供されており，API の呼び出し 監視の構成図を図 2 に示す。 によりインスタンスの制御が可能である。本システムでは Zabbix の外部チェック機能を用いて AWS CLI を呼び出すス クリプトを実行するようにした。これにより表 2 に示すよ うなインスタンスの自動制御が可能となった。 図2 表2 Zabbix によるインスタンス制御（一部の例） 3.4 データベース フェールオーバ遅延対策 監視システム構成 CloudWatch と Zabbix を併用し連携することにより以下(1) ～(3)の機能を実現した。 (1)CloudWatch と Zabbix 併用による監視対象の拡大 CloudWatch では，メモリ使用率やディスク使用率など，一 本システムでは，外部システムから送信される文字情報を 都度データベースに格納し，１分周期で表示情報を更新し 解析することにより統計情報を算出する仕組みを構築する て提供する必要があった。 ことで対応を図った。 本システムでのデータベースは，AWS の RDS サービスを信頼 また，このログ収集は，AWS の仕様では 60 分程度で配信部 性向上のため Multi-AZ 配置(Availability Zone)オプショ の各サーバから S3 に格納されるとされていたが，実際には， ンを利用して構築したが，この RDS の冗長化構成ではフェ 24 時間以降に格納されるサーバ分があることが判明したた ールオーバ時に DNS(Domain Name System)への付け替え等が め，本システムでは，72 時間後にログ解析を行う仕組みと 発生する関係でフェールオーバに数分かかることがあり， している。 情報更新が滞るという課題があった。 3.7 そこで，WEB サーバ側の処理を見直して，データベースから 本章では，多彩な機種での動画視聴を可能とするために行 情報取得して表示データを生成する部分については，最後 った設計上の留意事項について述べる。 に受け取った情報を再利用して情報表示を継続する仕組み 3.7.1 にすることで対応した。 3.5 インスタンスの稼働制御による AWS 課金対策 AWS ではインスタンスを利用した時間に応じて課金される。 ライブ／オンデマンド映像の多様な配信形式への対応 ライブ配信形式 本システムは SD-SDI で受け取った映像・音声を最終的に 表 3 に示す形式で視聴者へサービス提供を行っている。 表3 ライブ映像サービス提供対象と配信形式 そのため，システムの負荷に関係なく常に全てのインスタ ンスを稼働させてしまうと，無駄なランニングコストが掛 かるという課題があった。必要な時に必要な数だけインス タンスを使用するための AWS の標準機能として，自動スケ ーリング機能がある。これは，インスタンスの負荷が予め 設定した基準に達した場合に，EC2 インスタンスの負荷に合 わせてインスタンスのスペックを上下させ，インスタンス 数を増減させるものであるが，このスケーリングは起動開 始から起動完了となるまでに数分を要していた。 また，本システムには，1 日を通して定期的に視聴者数が急 増して負荷が高くなる時間帯があり，その時間帯に限りイ ンスタンス数を増やしたいが，急激な負荷増大には，自動 スケーリング機能のスピードが追い付けないという課題が あった。その対策として，AWS の API にインスタンスを起動 ／停止できるものがあり，これを用いてインスタンス数を 増減させる方式を採用することとした。 1 日 24 時間を 3 パターンに分け，日中を全てのインスタン ス稼働，夜間を半数のインスタンス稼働，深夜を必要最低 限のインスタンス稼働とした。これにより，常に全てのイ ンスタンスをフル稼働させることが無くなり，ランニング コストを削減し，AWS の無駄な課金が生じないようにした。 3.6 アクセス数カウント集計の精度向上への対策 本システムでは同時視聴者数の把握として 5 分毎に視聴さ れたアクセス数から同一 IP アドレスでアクセスされた場合 と同一チャネルをアクセスした場合は，1 回とカウントする 仕様で統計情報を収集する仕組みが要求されていた。 HDS での提供先については規格としての定義がなく，構築作 業の中で代表的な Android 搭載機器での検証を実施し，ユ ーザエージェントによる対象機器の判定と配信形式の選択 を実施している。 携帯電話は既述のとおり，ライブ配信パッケージのクラウ ド上での動作確認および入力映像対応カスタマイズを経て docomo 製品のみに対応した。 なお，パソコン，携帯については配信形式に合わせた再生 プレーヤーアプリの更新も実施している。 主にスマートフォン向けに配信している HLS についてはク ライド内インスタンスに HDS からの変換処理を実装してお り，変換が不要な HDS に比べて即時性が損なわれる面があ るが，変換処理に利用するインスタンスのチューニングお よび無線環境での利用が大多数であることなどから，パソ コンライブとの差異は目立つものとはなっていない。 3.7.2 オンデマンド配信形式 ライブ配信に対して，オンデマンド配信では元映像はライ ブ映像からの取得ではなく，ダイジェスト版への編集後に MP4 ファイルとして本システムへ登録後，配信する方式とし ており，基本は MP4 ファイルをそのまま配信しているが， 携帯電話のみ表 4 に示す通り機種個別対応の変換を実施後 に配信している。 表4 オンデマンド映像サービス提供対象と配信形式 また，ライブ映像に関しては，外部システムが直接配信ポ イントを参照してライブ視聴する仕組みを提供するが，シ ステム内でのアクセス数をカウントする方法では，そのよ ４． む す び うな直接参照されるアクセス数が除外されてしまうという クラウドサービスを利用したシステムの構築は，今後のビ 課題があった。この課題に対しては，AWS が提供するサービ ジネスシーンにおいて要求が高まってきている分野である。 スの一つである，配信部（CF）の各サーバのアクセスログ 今回の事例・構築ノウハウが，今後のシステム構築に際し を S3 に収集する機能を利用して，それらのアクセスログを ての一助になることを願う。