サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2>はじめに</h2>

<p>インフラ部　配信基盤グループ*1の佐藤です。（*1:執筆当時）<br />
この記事では、「進化する動画配信基盤」についての連載第11回目として、動画配信基盤のインフラ部分について記載します。</p>

<p>目次記事はこちらです。</p>

<p><a href="https://inside.dmm.com/entry/2020/02/04/evolving_content_delivery_platform_00" target="_blank">連載、始めます ～進化する動画配信基盤～</a></p>

<p>配信基盤全体について、またインフラと動画配信基盤のこれまでの連載との関連を含め、全体的な特徴が掴めるような内容として書いてみたいと思います。これまでの連載のAppendix的なものとしてゆるく読んでいただけたら幸いです。</p>

<h2>DMMの動画配信の特徴とその基盤</h2>

<p>昨今は各種クラウドやプライベートクラウド含め様々な環境が選択できる世の中となっていますが、動画配信基盤は各デバイス向けやストリーミング、ダウンロードなどの配信形式に合わせてそれぞれの基盤が用意されており、それらはほぼオンプレミスとなっています。 オンプレミスにて環境を持ち続ける理由としては、我々のサービスの特徴や規模感によるところが大きいです。 コンテンツ配信のトラフィック量が膨大、コンテンツ数を見てもロングテール型で過去作を保持したうえで新作が追加されていくモデルで、増加し続ける大量のデータを保持する必要があるため、オンプレミスのコストメリットがまだ出るところになります。</p>

<p>トラフィックはありがたいことに毎年増加傾向にあり、 2019年度ではDMMとして<strong>オンプレミス387Gbps</strong>ものピークトラフィックを記録しています。それに加えてスパイク時にCDNオフロードもしているので、なかなかの数字ですよね。</p>

<div style="text-align:center">
<figure class="image" style="display:inline-block"><img alt="" height="375" src="https://image.dmm-corp.com/cerzdz4o6cvei1hdoin0vyxlyjge" width="800" />
<figcaption>トラフィック推移</figcaption>
</figure>
</div>

<p>5年で３倍となかなかの増加率です。 このDMMの総トラフィックのうち、<strong>８割が動画配信のVODストリーミング </strong>となり、１割がスマホダウンロード、その他が１割といったところでしょうか。</p>

<h2>各基盤の構成と技術について</h2>

<p>各デバイス向け、サービスごとにある程度基板は分かれていますが、 ここでは全体の８割のトラフィックを吐いている <strong>VODストリーミング基盤</strong> についての構成を紹介いたします。</p>

<p><img alt="" height="900" src="https://image.dmm-corp.com/wqghnbbcy82ubr1wronyu7wdsv4f" width="800" /></p>

<p>CDN、キャッシュサーバーのティア、オリジンサーバーのティア、ストレージのティアとなっています。基本的にはなるべくオンプレミスのリソースを利用し、コストパフォーマンスが出る形にしています。 メインのトラフィックアウトバウンドはキャッシュのティアで行っており、特定コンテンツがスパイクしたらCDNに流れていきます。</p>

<h3>キャッシュサーバ</h3>

<p>オリジンサーバへの負荷軽減と配信速度向上のため、SSDを一定数搭載したサーバを準備しています。<br />
以下ざっくりしたスペック。</p>

<table border="1" cellpadding="1" cellspacing="1" style="width:500px;">
	<thead>
		<tr>
			<th scope="col">項目</th>
			<th scope="col">内容</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>サーバソフトウェア</td>
			<td>nginx（openresty）<br />
			consul制御</td>
		</tr>
		<tr>
			<td>OS</td>
			<td>CentOS</td>
		</tr>
		<tr>
			<td>ケース</td>
			<td>2U</td>
		</tr>
		<tr>
			<td>CPU</td>
			<td>10Core CPU *2</td>
		</tr>
		<tr>
			<td>SSD</td>
			<td>3.86TB〜7.68TB * 24本<br />
			Read Intensive</td>
		</tr>
		<tr>
			<td>NIC</td>
			<td>10GbE〜25GbE * n</td>
		</tr>
	</tbody>
</table>

<p>コストの観点から、１台あたりの利用効率を上げてたくさん働いてもらうようにしています。冗長構成の余力も残しつつ、１台あたり月間1PB近くをサラッと吐いてくれるのが理想です。</p>

<p><a href="https://inside.dmm.com/entry/2020/02/13/evolving_content_delivery_platform_02" target="_blank">DMM Player v2を成し遂げるCMAF</a></p>

<p>で記載があるとおり、実はサラッとダウンロード用のファイルも生成しているので、意外とCPUも頑張って働いてくれていたりします。</p>

<h3>オリジンサーバ</h3>

<p>ストレージのマウント、キャッシュサーバのオリジン、またアクセスの少ないコンテンツについてはここから直接レスポンスを返す役割も担っています。以下ざっくりスペック。</p>

<table border="1" cellpadding="1" cellspacing="1" style="width:500px;">
	<thead>
		<tr>
			<th scope="col">項目</th>
			<th scope="col">内容</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>サーバソフトウェア</td>
			<td>Wowza Streaming Engine</td>
		</tr>
		<tr>
			<td>OS</td>
			<td>CentOS</td>
		</tr>
		<tr>
			<td>ケース</td>
			<td>1U</td>
		</tr>
		<tr>
			<td>CPU</td>
			<td>10Core CPU *2</td>
		</tr>
		<tr>
			<td>メモリ</td>
			<td>128GB〜192GB</td>
		</tr>
		<tr>
			<td>NIC</td>
			<td>10GbE * n</td>
		</tr>
	</tbody>
</table>

<p>基本的にはWowza Streaming Engineと、ストレージのキャッシュとして頑張ってもらっています。</p>

<h3>ストレージ</h3>

<p>過去にはそれぞれの時代に、以下のような構成でストレージを構成していました。</p>

<ul>
	<li>Windows + DAS</li>
	<li>Isilonなどのアプライアンス</li>
	<li>Windowsサーバ単体をストレージに</li>
	<li>FreeBSD + GlusterFS</li>
</ul>

<p>これらによってストレージサイロ化による構築運用の日々に疲弊した結果、ここ数年は大規模なSDS製品とIAサーバにてストレージを構築、集約する形にしています。 SDSは Scality を利用しています。フランス製です。</p>

<table border="1" cellpadding="1" cellspacing="1" style="width:500px;">
	<thead>
		<tr>
			<th scope="col">項目</th>
			<th scope="col">内容</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>サーバソフトウェア</td>
			<td>Scality</td>
		</tr>
		<tr>
			<td>OS</td>
			<td>CentOS</td>
		</tr>
		<tr>
			<td>ケース</td>
			<td>4U</td>
		</tr>
		<tr>
			<td>CPU</td>
			<td>10Core CPU *2</td>
		</tr>
		<tr>
			<td>メモリ</td>
			<td>256GB</td>
		</tr>
		<tr>
			<td>HDD</td>
			<td>12TB * 38</td>
		</tr>
		<tr>
			<td>SSD</td>
			<td>1.2TB<br />
			メタ情報</td>
		</tr>
		<tr>
			<td>NIC</td>
			<td>10GbE * n</td>
		</tr>
		<tr>
			<td>パフォーマンス</td>
			<td>5Gbps前後</td>
		</tr>
	</tbody>
</table>

<p>一般的に集約していくことで障害時のインパクト向上やハードウェアライフサイクルによるリプレイスの負荷も高まります。 しかしScalityはErasure Codingによるデータ保護やサーバの追加が柔軟にできる仕組みなので、今のところ運用工数削減のメリットが大きく出ている形です。 もちろん性能面の向上やセカンドチョイスの検討など、次への動きは続けなければならない箇所ではあります。</p>

<h3>コストの考え方</h3>

<p>上記VODストリーミングで考えた場合、規模感の観点から特に大きくコストを左右するポイントとして以下２点が挙げられます。</p>

<ul>
	<li>トラフィックを出すところ（キャッシュサーバのティア）</li>
	<li>ストレージ（毎日増加するコンテンツデータ格納箇所）</li>
</ul>

<p>現状として、DMMの動画配信ストリーミングはキャッシュのティアで月間数十PBのサービストラフィックが外部に出ていきます。 我々はこの月間で外に流したサービストラフィック量に対しての月額コストを意識して運用を行う必要があります。GB単価を出すイメージです。 オンプレミスの場合は主に以下がざっくりとコストとして上がってきます。</p>

<ul>
	<li>ハードウェア費用</li>
	<li>回線費用</li>
	<li>データセンター費用</li>
	<li>人件費</li>
</ul>

<p>VODストリーミングは、そのサービス性質上継続して一定量のトラフィックが外に流れ続けるので、なるべく回線コミット値の範囲でオンプレミスで流し、コミット値を超えてスパイクするところのみCDNにオフロードできるとコストメリットが出る形となります（コミット値までは定額のため）。<br />
昨今はCDNの単価も下がってきているので、サービスの成長率を見ながらそれぞれの利用割合を適切に見極めて変えていく必要があります。</p>

<p>ストレージ部分も同様です。当たり前ではありますが、増え続けていくデータ量に対しハードウェアのライフサイクルによる入れ替えとともに容量当たりの単価を下げていくことを意識しています。 複数ベンダーさんより提案をいただき、購入数をまとめることで価格を抑えながら購入を行っています。</p>

<h3>各ティアで共通すること</h3>

<ul>
	<li>コスト</li>
	<li>性能</li>
	<li>対障害性</li>
</ul>

<p>インフラとしてはこの３つのバランスを大事にしております。 前述したようにDMMの配信基盤はデータ、トラフィックともに量が多く、その増加ペースもなかなかのものがあります。 日々の運用をこなしつつ、ある一定の規模感を超えた時に構成や利用されている技術を見直す必要に迫られるところが、大変でもありやりがいも感じる部分です。 この規模感ではオンプレミスのDRはコスト的に現実的ではなく、AWSを利用されたものが構築されています。興味のある方はぜひ前回記事の10. もしもに備えた動画配信基盤のDRシステム　をご覧になっていただければと思います。</p>

<p><a href="https://inside.dmm.com/entry/2020/04/07/evolving_content_delivery_platform_10" target="_blank">もしもに備えた動画配信基盤のDRシステム</a></p>

<h2>運用面など　キャンペーン負荷との戦いとVODST</h2>

<p>DMMは年に数回、大規模なキャンペーンを行います。基本的にCDNも利用するので、お金をかければなんとでもなところはありますが、当然コスト抑えるためになるべくオンプレミスで対応する努力を行います。我々はキャンペーンが企画されるたびに事前に負荷対策を行い、前回キャンペーンのデータから増加するリソースを試算し、危ない箇所があればそこをスケールし、CDNの切り替え準備も行い、当日はトラフィックや負荷もモニターし、何かあったらCDNに切り替えて&hellip;と頑張っておりました。当時の構成上、コンテンツのキャッシュHIT率もそこまでではなく、スケールをメインの施策とせざるを得ない状況でした。たまにどこかが詰まってどうしようもなくなり、アクセスが収まるまで待つしかなかったこともあります。準備、キャンペーン中のモニター、障害対応と、なかなか負荷の高い運用を続けていました。</p>

<p>そんななか、2019年にVODSTというシステムが動画配信基盤のまさきさんにより、ほぼ前触れなくさらりと導入されます。</p>

<p><a href="https://inside.dmm.com/entry/2020/03/04/evolving_content_delivery_platform_05" target="_blank">配信サーバー「VODST」</a></p>

<p>コンテンツの同時視聴数を計算して自動でティアを変えてくれるのです。こいつ軽いからオリジンねー、この子はたくさん見られてるからCDNで出しましょうかーといった感じで。<strong>実際のところ、そのリソース適正化の効果は凄まじく、上手く使えずに燻っていた既存のオンプレ環境の能力、パワーを限界近くまで引き出し、その結果コストまで適正化されるというまさに光の連鎖が起こりました。 </strong>さらに、VODSTの導入に伴い、本当に冗談ではなく、VODストリーミングに対して<strong>我々インフラが行っていた負荷対策がほぼ不要となったのです</strong>。本当に感謝です。<br />
運用の話というよりはVODSTによって助かった話になってしまいましたが、優れたアイディア、システムが状況を一気に解決した一例として捉えていただけたらと思います。</p>

<h2>あとがき</h2>

<p>動画配信基盤のメイン部分であるVODストリーミング基盤に焦点を当てつつ、インフラの側面から見た動画配信基盤について、そしてアプリチームとの連携について記載してみました。読んでくださった皆様に少しでも中の雰囲気が伝われば良いなと思います。<br />
今後も動画配信基盤のアプリチームと良好な関係を保ち続け、より良いシステムを構築することを目指して頑張っていきたいと思います！</p>


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

シェア

関連する求人

関連する記事