• トップ
  • テクノロジー
  • DRMサーバー「mlic」
DMMグループの一番深くておもしろいトコロ。
テクノロジー

DRMサーバー「mlic」

DMMグループの一番深くておもしろいトコロ。

「進化する動画配信基盤」についての連載第３回目となるこの記事では、DRMサーバー「mlic」について記載します。

はじめに

動画配信事業部 配信基盤チームのまさきです。
「進化する動画配信基盤」についての連載第３回目となるこの記事では、DRMサーバー「mlic」について記載します。

目次記事はこちらです。

https://inside.dmm-corp.com/articles/02/04/evolving_content_delivery_platform_00

 

その前に、ちょっとだけ...
私たち配信基盤チームには東京と金沢のメンバーがいて、この連載の１回目の記事を書いた保月さんと私は金沢で業務を行っています。日本有数のトラフィックを誇る動画配信を金沢から支えることができるなんて、素敵ですね（採用情報はページの下に）

 

mlicとは

mlicは Multi-DRM License Server から、命名しました。 何がマルチなのか、DRMの説明も含め書きたいと思います。

DRM

DRM（Digital rights management）は、コンテンツ保護のための有効な方法の一つです。 ストリーミング配信のコンテンツ保護の方法としては、メディアデータを暗号化したHLS AESがよく利用されます。これは、メディアデータを暗号化し、再生時に復号する鍵を取得してメディアデータの復号を行う方法です。 メディアデータを暗号化する点ではDRMも同じなのですが、加えて以下の特徴があります。

  • メディアデータの復号鍵を保護する仕組みがあり、不正に鍵を取得することができない
  • 復号したメディアデータを再生デバイスまでの経路で不正に取得することができない
  • ライセンスの有効期限、再生時間の制御などができる

DRMライセンスサーバーは、DRMコンテンツを再生する際に必要なライセンス（鍵、有効期限等）を発行するサーバーになります。

HLS AESとDRMの比較表

  HLS AES DRM
メディアデータ暗号化 ○ ○
復号鍵保護 － ○
復号したメディアデータの保護 － ○
ライセンス有効期限 － 設定可能
HTML5対応 ○ ○
ブラウザにより対応しているDRMは異なる
ライセンス料 無料 ライセンスサーバー：無料
ただし、DRMベンダーと契約（有料）が必要

クライアント：無料
ただし、クライアントSDKを使用する場合、DRMによっては有料

DRMベンダー

DRMはいくつかのベンダーから提供されていて、主なDRMは以下になります。

  • Widevine（Google）
  • PlayReady（Microsoft）
  • FairPlay Streaming（Apple）
  • Primetime DRM（Adobe）

※Primetime DRMについては私たちのサービスでは扱っていないため、以降の記事内容は当てはまりません。

HTML5でブラウザ再生やアプリを用意することで、様々な環境でDRMコンテンツを再生できるようになりました。ただブラウザによって対応しているDRMが異なることや、アプリで使用するクライアントSDKが有料の場合もあり、再生環境に応じて適切なDRMを利用することが必要になります。

マルチDRM

このようにDRMは複数あり、ライセンスサーバーも各DRMに合わせたものが必要になります。 これら複数のDRMライセンスサーバーを一つのサーバーに統合したものが mlic です。
統合することにより、以下のメリットがあります。

  • ライセンス情報のフォーマットは各DRMで異なるが、DRMの処理フローは同じで共通化できる処理も多く効率的な開発ができる
  • サーバー運用コストが下がる

マルチサービス

mlicにはもう一つマルチがあります。
マルチサービスです。このサービスは商品を販売しているECサービスを指しています。 私たちが管理している動画配信プラットフォームは、DMMが運用しているいくつかのECサービスで利用されています。 mlicでは複数のECサービスでDRMライセンスサーバーが利用できるように設計しています。

mlic

mlicはマルチDRM、マルチサービスのライセンスサーバーなのです。

 

f:id:yanoshi:20200212205332p:plain
mlicの構成図

 

mlic処理フロー

HTML5で再生する場合のmlicの処理について説明したいと思います。

 

f:id:yanoshi:20200212205418p:plain
mlicの処理フロー図

 

  1. HTML5プレイヤーはCDM（Content Decryption Module）でライセンス発行に必要なメッセージを生成し、それをライセンスサーバーに送ってライセンス発行のリクエストを行う。
  2. ライセンスサーバーは受け取ったメッセージから、鍵の生成や再生可否に必要な情報を取り出す。
  3. 再生可否の判断に必要な情報（コンテンツID等）をECサービスに送り、再生可否の問い合わせを行 う。
  4. ECサービスはライセンスサーバーから送られた情報によって、再生可否を判断し、結果をライセンスサーバーに返します。
  5. 再生可であれば復号するための鍵を生成し、ライセンスを発行します。
  6. プレイヤーは受け取ったライセンス情報をCDMに渡し、CDMはメディアデータを復号して再生を行う。

※CDM等のプレイヤー処理はざっくりと説明しています。CDMのより詳細な挙動については以下を参照してみてください。

www.w3.org

mlic構成

PlayReadyがWindowsでしか動作しないため、サーバーOSは必然的にWindowsサーバーになります。 既存のPlayReadyライセンスサーバーはオンプレ環境でしたが、クラウドのほうが様々な点でメリットがあるため、mlicはAWSで構築しています。

AWS構成

Windowsコンテナでの構築も検討したのですが、mlic開発時点ではEKSのWindowsコンテナはプレビュー段階であり、ECSもFargateでWindowsコンテナを利用することができず、構成的にもコンテナにするメリットがあまりなかったので、シンプルにEC2で構築しました。

mlicの処理は以下の2つに分けることができます。

  • DRMライセンス処理(mlicの処理フロー2,5)
    • 各DRMのアプリケーションが必要でWindowsサーバー上で動作
    • ECサービス側の実装による影響は少ない
  • ECサービスへの再生可否の問い合わせ処理(mlicの処理フロー3)
    • 各DRMアプリが取り出した情報を処理するため、各DRMの仕様に依存しない。
    • 他のECサービスと連携するため、ECサービス側の実装次第で影響を受ける可能性がある

2つの処理は疎結合にできるため、処理を分離して以下の構成にしました。

処理 AWS 説明
DRMライセンス処理 EC2 IISで各DRMアプリが動作するカスタムAMIを作成
ECサービスに依存する処理がないため、頻繁な更新はない。
ただし、OSのパッチ、セキュリティアップデート等の更新は発生する
ECサービスへの再生可否確認 API Gateway
Lambda		 LambdaでECサービス側と柔軟に連携

 

f:id:yanoshi:20200212205545p:plain
アーキテクチャ図

 

アーキテクチャ

mlicを開発、構築、運用するうえでの技術について書きたいと思います。

DRMアプリケーション

処理共通化、Windows上での動作、Linuxへの展開、開発効率を考慮して、Microsoft Visual Studioを使用。以下の開発言語、フレームワークで実装を行いました。

DRM 開発言語 フレームワーク
Widevine C# (Pythonから移植） .NET Core
FairPlay Streaming C# (Cから移植） .NET Core
PlayReady C# .NET Framework

各アプリはVisual StudioでIISに簡単に配置できるようWebデプロイパッケージを作成することができ、サーバーへのデプロイが簡単にできます。

このDRMアプリケーションは、連載２回目の記事を書いた丸山さんが実装しました!!

Terraformによる環境構築

AWS構築はTerraformを使用しています。 mlicでは全設定が一つのtfstateにならないように、分割して構築しています。 tfstateが壊れた時、tfstateは修復に苦労することが多く、リソースを手動で削除して再構築するほうが早い場合があります。そこで構築処理を分割し、tfstate破損時の影響を小さくしています。 mlicでは以下のように分割しています。

  • AWSアカウント単位のリソース
    IAM role、Elastic IP 等
  • 本番/ステージング/開発 環境単位のリソース（構築したら削除しないもの）
    VPC、subnet、Internet Gateway、log関連 等
  • 本番/ステージング/開発 環境単位のリソース（環境が不要になったら削除する）
    NAT Gateway、 Application Load Balancer、Route53、Endpoint 等
  • Blue/Greenデプロイメントのステージ単位のリソース
    API Gateway、Auto Scaling 等
  • CodeBuild
  • Lambda

環境単位のリソースは、Terraform Workspaces を利用してtfstateを環境単位に管理し、更にデプロイステージ（blue/green）単位のリソースがある場合はblue用、green用に分けてtfファイルを用意し、共通のリソース設定はTerraformのModulesにより共通化しています。

開発環境は、不要時にEC2インスタンスはもちろんですが、NATも料金が高いので削除するようにしています。これらの起動、削除はRundeckでjobを作成し、簡単にできるようにしています。

CodeBuild ＋ HashiCorp Packer によるカスタムAMIの作成

カスタムAMIは、CodeBuild ＋ HashiCorp Packerで作成しています。 WindowsのAMIは毎月パッチが適用されたAMIがAWSから提供されています。Packerテンプレートで以下のように指定しておくことで、ビルド時点で最新のWindowsパッチが適用されたAMIを作成することができます。

    "source_ami_filter": {
        "filters": {
          "name": "Windows_Server-2019-Japanese-Full-Base-*"
        },
        "owners": ["801119661308"],
        "most_recent": true
    }

ミドルウェアのインストールやDRMアプリのデプロイはPackerのprovisionersで定義します。
provisionersではshellの実行やWindowsの再起動を行うことができます。 例えば、IISをインストールしてWindowsを再起動したい場合は以下のように指定します。

packerテンプレートのprovisioners

  "provisioners": [
        {
        "type": "powershell",
        "inline": [
          "Install-WindowsFeature Web-WebServer,Web-Asp-Net45"
          ]
        },
        {
          "type": "windows-restart"
        }
    ]

Blue/Greenデプロイメント

安全にリリースできるようにBlue/Greenデプロイメントでリリースを行っています。稼働している環境は変更せずに、リリースする環境を新規に構築して切り替える方法でダウンタイムなしに新規環境をリリースできます。また、新規環境で問題が発生した場合に、迅速に元の環境にロールバックすることができます。
Blue/Greenを切り替える方法はいろいろありますが、mlicではALBで向き先のターゲットグループを切り替えています。 新規リリースする環境を構築すると、検証用のALBの向き先として設定されるのでリリース前に動作検証を行います。 そこで問題がなければ、公開用のALBのターゲットグループの向き先を切り替えます。

LambdaはBlue/Green用でソースを分けると管理が煩雑になるので、Lambdaのバージョニング、エイリアスを使って行います。エイリアス名にblueとgreenを用意し、Lambdaにバージョンを付けてエイリアスが使用するバージョンを指定します。API GateweyからLambdaの呼び出しは、ファンクション名:エイリアス名 で実行することができます。

 

f:id:yanoshi:20200212205657p:plain
デプロイの流れ

 

mlicをリリースした時点では、ALBのターゲット切り替えだけではカナリアリリースをすることはできませんでしたが、現在はALBで加重ターゲットグループの指定ができるようになり、カナリアリリースが可能になりました。mlicもカナリアリリースに対応予定です。

今後

  • mlicの展開
    mlicは昨年秋にリリースし、現時点ではDMM Player v2のみで使用されていますが、今後は各ストリーミング配信でも使用される予定です。

  • アーキテクチャの見直し
    リリースしたばかりなのですが、既にリリース時から更新された技術があり、これからも適宜、見直す予定です。 主なものとしては以下になります。

    • PlayReady Server SDKのLinux対応
      なんとPlayReadyがLinuxに対応しました。試行錯誤しながらWindowsサーバー対応をしたのに...。もう少し早くリリースしてくれれば（泣）、と思いながらの今回の執筆になりました。 とはいえ、これでWindowsサーバーに縛られることがなくなり、構成の選択肢が増えました！
    • ALBでのカナリアリリース
      Blue/Greenデプロイメントのところで記載しましたが、ALBで加重ターゲットグループ指定ができるようになりました。 こちらは早めに対応したいと思っています。

  • CI/CD運用

現時点ではCI/CD運用をしていません。 DRMのテストがプレイヤーを使わないと難しいこともあり、実際にプレイヤーを使用して再生テストを行っていますが、自動化できるところもあるので見直していく予定です。
ただ、mlicは頻繁なコード変更が発生しないため、手動も含めた効率の良い運用で品質確保を検討したいと思っています。

最後に

CMAFの登場もあり、DRM技術は規格が統一される方向にあります。しかし、まだ統一化されていないところももちろんあり、ブラウザ、スマホ以外のデバイスも含めると、DRMサポート状況は様々です。
理想と現実をしっかりと見つめ、変化する環境に対応しながら、より快適な動画配信を目指したいと思いますので、引き続きよろしくお願いいたします。

採用情報

DMM Groupでは金沢採用も含めて新卒/中途問わず、一緒に働く仲間を募集しています！　少しでも興味を持っていただいたあなたのエントリーをお待ちしております。

新卒採用(金沢勤務)

新卒採用(採用ポータル)

dmm-corp.com

シェア