DMM.comの、一番深くておもしろいトコロ。

配信基盤を支えるオンプレ技術

配信基盤を支えるオンプレ技術

  • このエントリーをはてなブックマークに追加

はじめに

インフラ部 配信基盤グループ*1の佐藤です。
この記事では、「進化する動画配信基盤」についての連載第11回目として、動画配信基盤のインフラ部分について記載します。

目次記事はこちらです。inside.dmm.com

配信基盤全体について、またインフラと動画配信基盤のこれまでの連載との関連を含め、全体的な特徴が掴めるような内容として書いてみたいと思います。これまでの連載のAppendix的なものとしてゆるく読んでいただけたら幸いです。

DMMの動画配信の特徴とその基盤

昨今は各種クラウドやプライベートクラウド含め様々な環境が選択できる世の中となっていますが、動画配信基盤は各デバイス向けやストリーミング、ダウンロードなどの配信形式に合わせてそれぞれの基盤が用意されており、それらはほぼオンプレミスとなっています。 オンプレミスにて環境を持ち続ける理由としては、我々のサービスの特徴や規模感によるところが大きいです。 コンテンツ配信のトラフィック量が膨大、コンテンツ数を見てもロングテール型で過去作を保持したうえで新作が追加されていくモデルで、増加し続ける大量のデータを保持する必要があるため、オンプレミスのコストメリットがまだ出るところになります。

トラフィックはありがたいことに毎年増加傾向にあり、 2019年度ではDMMとしてオンプレミス387Gbpsものピークトラフィックを記録しています。それに加えてスパイク時にCDNオフロードもしているので、なかなかの数字ですよね。

f:id:yanoshi:20200410162331p:plain
トラフィック推移

5年で3倍となかなかの増加率です。 このDMMの総トラフィックのうち、8割が動画配信のVODストリーミング となり、1割がスマホダウンロード、その他が1割といったところでしょうか。

各基盤の構成と技術について

各デバイス向け、サービスごとにある程度基板は分かれていますが、 ここでは全体の8割のトラフィックを吐いている VODストリーミング基盤 についての構成を紹介いたします。

f:id:yanoshi:20200410163804p:plain
ストリーミング基盤

CDN、キャッシュサーバーのティア、オリジンサーバーのティア、ストレージのティアとなっています。基本的にはなるべくオンプレミスのリソースを利用し、コストパフォーマンスが出る形にしています。 メインのトラフィックアウトバウンドはキャッシュのティアで行っており、特定コンテンツがスパイクしたらCDNに流れていきます。

キャッシュサーバ

オリジンサーバへの負荷軽減と配信速度向上のため、SSDを一定数搭載したサーバを準備しています。
以下ざっくりしたスペック。

項目 内容
サーバソフトウェア nginx(openresty)
consul制御
OS CentOS
ケース 2U
CPU 10Core CPU *2
SSD 3.86TB〜7.68TB * 24本
Read Intensive
NIC 10GbE〜25GbE * n

コストの観点から、1台あたりの利用効率を上げてたくさん働いてもらうようにしています。冗長構成の余力も残しつつ、1台あたり月間1PB近くをサラッと吐いてくれるのが理想です。 inside.dmm.com
で記載があるとおり、実はサラッとダウンロード用のファイルも生成しているので、意外とCPUも頑張って働いてくれていたりします。

オリジンサーバ

ストレージのマウント、キャッシュサーバのオリジン、またアクセスの少ないコンテンツについてはここから直接レスポンスを返す役割も担っています。以下ざっくりスペック。

項目 内容
サーバソフトウェア Wowza Streaming Engine
OS CentOS
ケース 1U
CPU 10Core CPU *2
メモリ 128GB〜192GB
NIC 10GbE * n

基本的にはWowza Streaming Engineと、ストレージのキャッシュとして頑張ってもらっています。

ストレージ

過去にはそれぞれの時代に、以下のような構成でストレージを構成していました。

  • Windows + DAS
  • Isilonなどのアプライアンス
  • Windowsサーバ単体をストレージに
  • FreeBSD + GlusterFS

これらによってストレージサイロ化による構築運用の日々に疲弊した結果、ここ数年は大規模なSDS製品とIAサーバにてストレージを構築、集約する形にしています。 SDSは Scality を利用しています。フランス製です。

項目 内容
サーバソフトウェア Scality
OS CentOS
ケース 4U
CPU 10Core CPU *2
メモリ 256GB
HDD 12TB * 38
SSD 1.2TB
メタ情報
NIC 10GbE * n
パフォーマンス 5Gbps前後

一般的に集約していくことで障害時のインパクト向上やハードウェアライフサイクルによるリプレイスの負荷も高まります。 しかしScalityはErasure Codingによるデータ保護やサーバの追加が柔軟にできる仕組みなので、今のところ運用工数削減のメリットが大きく出ている形です。 もちろん性能面の向上やセカンドチョイスの検討など、次への動きは続けなければならない箇所ではあります。

コストの考え方

上記VODストリーミングで考えた場合、規模感の観点から特に大きくコストを左右するポイントとして以下2点が挙げられます。

  • トラフィックを出すところ(キャッシュサーバのティア)
  • ストレージ(毎日増加するコンテンツデータ格納箇所)

現状として、DMMの動画配信ストリーミングはキャッシュのティアで月間数十PBのサービストラフィックが外部に出ていきます。 我々はこの月間で外に流したサービストラフィック量に対しての月額コストを意識して運用を行う必要があります。GB単価を出すイメージです。 オンプレミスの場合は主に以下がざっくりとコストとして上がってきます。

  • ハードウェア費用
  • 回線費用
  • データセンター費用
  • 人件費

VODストリーミングは、そのサービス性質上継続して一定量のトラフィックが外に流れ続けるので、なるべく回線コミット値の範囲でオンプレミスで流し、コミット値を超えてスパイクするところのみCDNにオフロードできるとコストメリットが出る形となります(コミット値までは定額のため)。
昨今はCDNの単価も下がってきているので、サービスの成長率を見ながらそれぞれの利用割合を適切に見極めて変えていく必要があります。

ストレージ部分も同様です。当たり前ではありますが、増え続けていくデータ量に対しハードウェアのライフサイクルによる入れ替えとともに容量当たりの単価を下げていくことを意識しています。 複数ベンダーさんより提案をいただき、購入数をまとめることで価格を抑えながら購入を行っています。

各ティアで共通すること

  • コスト
  • 性能
  • 対障害性

インフラとしてはこの3つのバランスを大事にしております。 前述したようにDMMの配信基盤はデータ、トラフィックともに量が多く、その増加ペースもなかなかのものがあります。 日々の運用をこなしつつ、ある一定の規模感を超えた時に構成や利用されている技術を見直す必要に迫られるところが、大変でもありやりがいも感じる部分です。 この規模感ではオンプレミスのDRはコスト的に現実的ではなく、AWSを利用されたものが構築されています。興味のある方はぜひ前回記事の10. もしもに備えた動画配信基盤のDRシステム をご覧になっていただければと思います。inside.dmm.com

運用面など キャンペーン負荷との戦いとVODST

DMMは年に数回、大規模なキャンペーンを行います。基本的にCDNも利用するので、お金をかければなんとでもなところはありますが、当然コスト抑えるためになるべくオンプレミスで対応する努力を行います。我々はキャンペーンが企画されるたびに事前に負荷対策を行い、前回キャンペーンのデータから増加するリソースを試算し、危ない箇所があればそこをスケールし、CDNの切り替え準備も行い、当日はトラフィックや負荷もモニターし、何かあったらCDNに切り替えて…と頑張っておりました。当時の構成上、コンテンツのキャッシュHIT率もそこまでではなく、スケールをメインの施策とせざるを得ない状況でした。たまにどこかが詰まってどうしようもなくなり、アクセスが収まるまで待つしかなかったこともあります。準備、キャンペーン中のモニター、障害対応と、なかなか負荷の高い運用を続けていました。

そんななか、2019年にVODSTというシステムが動画配信基盤のまさきさんにより、ほぼ前触れなくさらりと導入されます。 inside.dmm.com

コンテンツの同時視聴数を計算して自動でティアを変えてくれるのです。こいつ軽いからオリジンねー、この子はたくさん見られてるからCDNで出しましょうかーといった感じで。実際のところ、そのリソース適正化の効果は凄まじく、上手く使えずに燻っていた既存のオンプレ環境の能力、パワーを限界近くまで引き出し、その結果コストまで適正化されるというまさに光の連鎖が起こりました。 さらに、VODSTの導入に伴い、本当に冗談ではなく、VODストリーミングに対して我々インフラが行っていた負荷対策がほぼ不要となったのです。本当に感謝です。
運用の話というよりはVODSTによって助かった話になってしまいましたが、優れたアイディア、システムが状況を一気に解決した一例として捉えていただけたらと思います。

あとがき

動画配信基盤のメイン部分であるVODストリーミング基盤に焦点を当てつつ、インフラの側面から見た動画配信基盤について、そしてアプリチームとの連携について記載してみました。読んでくださった皆様に少しでも中の雰囲気が伝われば良いなと思います。
今後も動画配信基盤のアプリチームと良好な関係を保ち続け、より良いシステムを構築することを目指して頑張っていきたいと思います!

*1:執筆当時