blog

DeNAのエンジニアが考えていることや、担当しているサービスについて情報発信しています

2019.12.19 DeNAインフラノウハウ発信プロジェクト

DeNA の CDN 利用と取り組み状況

by Daisuke Yajima

#cdn #infrastructure #cost-optimization #stabilization #technical-verification #IaC #monitoring #infra-quality #infra-cost

はじめに

こんにちは、IT 基盤部の矢島です。
ネットワーク全般 (DataCenter / 本社や拠点及び子会社オフィス)の設計・構築・運用・保守、そして CDN (Content Delivery Network) を主に担当しています。

今回は、DeNA の CDN 利用状況や取り組み状況などについて、お話しします。

CDN の利用状況について

弊社は、ゲームを主力とし、他にヘルスケア、ソーシャル LIVE 、スポーツなど、多くの事業やサービスが存在します。
サービスによって、サーバや DB などのインフラ構成は異なりますが、共通しているのは、CDN を利用している、ということになります。

ご存知の方もいるかと思いますが、CDN の大きな特徴は、以下の通りです。

  • CDN 業者が提供しているサーバ (一般的には、Edge サーバと呼ばれる)で、画像ファイルなどのコンテンツをキャッシュし、ユーザにレスポンスすることができる
  • Edge サーバがキャッシュ及びレスポンスすることで、コンテンツを提供している大本のサーバ (一般的には、Origin サーバと呼ばれる)の負荷を減らすことができる
  • ユーザに極力、近い Edge サーバがレスポンスすることで、コンテンツ提供の高速化を図ることができる

弊社では用途に応じて、様々な CDN サービスを利用しており、外部公開している事例もあります。

CDN の管理について

基本的に、IT 基盤部では、 全社の CDN を集中管理しています。 目的としては、大きくは以下の通りです。

  • 包括的な契約を締結することで、コストメリットが生じやすくなる
  • 設定やアカウントを集中管理することで、全社的に様々なガバナンスを効かせることができる
  • 各サービスで、毎月 どのくらいの CDN トラフィック量が発生したか?を観測し、その理由などを分析することで、契約内容の見直しなどが容易になる

CDN では、提供業者様と「コミット契約」を締結することが一般的です。

例えば、「年間の CDN トラフィック量は、xx TB を出すことを確約するので、費用や条件などを xx にして下さい」 というような内容です。

特に、弊社では、「コストメリット」を重要視しています。 集中管理することで、各サービスの過去の CDN トラフィック量や今後の予測を、徹底的に分析することが容易となるため、最も「コストメリット」がある内容で契約締結することが可能となります。

また、締結した「コミット契約」に対して、どのくらい達成しているか?を可視化しています。

可視化の例

Multi CDN の取り組みについて

弊社では、毎年 CDN 業者様の選定を実施しています。 先に記載した通り、「コストメリット」がある CDN サービスは何か?が、選定する上での主軸の一つとなります。

ただし、CDN サービス間のコスト比較だけでなく、移行コストや工数なども加味する必要があります。

毎年、この移行コストや工数が懸念点となっていたため、2018 年度に大規模な移行検証を実施しました。
前提や検証の流れは、以下の通りとなります。

前提

  • メインの CDN サービス(以下、CDN-A) のコミット契約があるため、そのコミットに影響を及ぼさないこと
  • 検証を実施する CDN サービス(以下、CDN-B) と、より安価に検証できるようにするために、検証目的のコミット契約を締結すること

検証の流れ

  1. CDN-A の設定をベースに、移行用設定を CDN-B に作成する
  2. サービス側で、CDN-B の事前動作テストを実施してもらう
  3. 2が問題無ければ、DNS の重み付け機能を利用して、徐々に CDN-A から CDN-B に切替える

各 CDN サービスの特性やアーキテクチャの違いによって、四苦八苦した部分はありましたが、結論、以下の結果となりました。

  • 一部 例外はあるが、CDN-B への移行設定は問題が無いこと
  • Cache 率などの性能は、CDN-A と比較して、遜色が無いこと

また、検証を実施することで、大きく以下の点を学ぶことができました。

  • 各 CDN サービスの特性やアーキテクチャの違いを十分に理解する
  • 極力、CDN サービス側に依存せず、対処できることは Origin サーバ側で対処する (Cache-Control など。依存すると、移行時の弊害となり得る可能性がある)
  • 実際に、本番動作させないと判明しない部分もある (CDN-A 側のドキュメントにも公開されていない仕様があることが分かった)

移行検証を実施して終了するだけでなく、現在は、CDN-A 及び CDN-B 間で設定を同期させる「Multi CDN」構成を取っています。

常に設定を同期させておくことによって、CDN サービスの選定結果次第で、柔軟に切替えることが可能です。また、万一 CDN-A で大規模な障害が発生したとしても、即座に別の CDN-B に切替えて、サービスを継続させることが可能となります。

「Multi CDN」構成をシステム的にどうやって担保しているか?などの具体的な話は、後日 公開予定です。

最後に

以上、「DeNA の CDN 利用と取り組み状況」を記載しました。
各企業によって、CDN の利用状況などは異なるかと思いますが、本内容が何かしらの参考になれば幸いです。

最後まで読んでいただき、ありがとうございます!
この記事をシェアしていただける方はこちらからお願いします。

recruit

DeNAでは、失敗を恐れず常に挑戦し続けるエンジニアを募集しています。