CDN の冗長化に関する検討

[Happy Elements 株式会社 カカリアスタジオ Advent Calendar 2016](http://qiita.com/advent-calendar/2016/hekk_cacalia_studio) の 4 日目です．本日の担当はインフラグループの @nagizero です．よろしくお願いします．



# はじめに

弊社ではアプリのデータ (e.g. AssetBundle) を配信するために CDN を利用しています．以前は CloudFront のみを利用していたのですが， SPOF となっていたので冗長化対応を行いました．プライマリ CDN を CloudFront, セカンダリ CDN を KeyCDN として， DNS ヘルスチェックによりフェイルオーバー・フェイルバックを実現しています．

今回の Advent Calendar では CDN の冗長化対応について 2 つの記事を投稿します．ひとつは本稿であり，冗長化対応の事前検討について記述します．もうひとつは明日投稿する予定の記事であり，実際の冗長化対応やテストの内容について記述します．



# フェイルオーバー案

## 要求

平時に参照する CDN (プライマリ) に障害が発生した際に，アプリが参照する CDN を自動的に予備の CDN (セカンダリ) に切り替えられる必要があります．

## DNS による対応

CDN 用の独自ドメインを用意し，そのドメインで解決されるアドレスを障害発生時に自動的に切り替えられるように設定できればよさそうです．アプリは独自ドメインにさえアクセスできればよい (あとは DNS がよしなに処理してくれる) ので，アプリ自体に変更を加える必要はありません．

具体的な他社事例として， Route53 にプライマリ CDN とセカンダリ CDN を登録し，ヘルスチェックの結果によって名前解決結果のアドレスを切り替える方法が挙げられます．

- [Amazon Web Services ブログ: 【AWS発表】Route53 に DNS フェイルオーバー機能が追加。 S3 のウェブホスティング機能と連携したバックアップサイトを作成可能に。](http://aws.typepad.com/aws_japan/2013/02/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting-.html)
- [\[AWS\] Route53 DNS フェールオーバー を試してみた。 | 公式ブログ | 株式会社プラウディット](http://www.proudit.jp/archives/771)
- [AWS - Amazon CloudFront の障害に備えてフェイルオーバーを設定する - Qiita](http://qiita.com/najeira/items/8e9e6f00394811b3f29c)
- [Route53 の Health Check ターゲットを ELB で試してみた - まめ畑](http://d.conma.me/entry/2013/06/02/183514)

## アプリによる対応

アプリ自身でプライマリ CDN のヘルスチェックを行い，異常が検知された際にセカンダリ CDN を参照するように実装すればよさそうです．作り込みが必要となりますが，参照する CDN をクライアント自身が直接指定するため， DNS で対応する場合に比べてダウンタイムは短縮できそうです．

## 結論

||利点|欠点|
|:--:|:--|:--|
|DNS による対応|アプリの変更なし，<br>Route 53 で手軽に実現可能|アプリに DNS キャッシュを持たせていると CDN 切替まで時間がかかる場合がある|
|アプリによる対応|CDN 障害時に即切替可能|アプリの作り込みが必要|

検討の結果， DNS による対応を採用しました．アプリに手を入れずに手軽に実現できることが大きな利点でした．



# 利用するセカンダリ CDN の検討

**2015 年 9 月現在の比較となります．現在は状況が変わっている可能性がありますのでご注意ください．**

## 要件と簡単な比較

次の要件を満足する CDN をピックアップします．

- 日本にエッジロケーションがあること
- 従量課金制であること
  - 待機系として利用するため，最低利用料金がないこと
- Amazon S3 をオリジンとして利用できること

以下に各 CDN の利点と欠点を簡単にまとめました．機能に決定的な差がなかったため，主に料金や実績の面で選定することにしました．

|CDN|利点|欠点|
|:--|:--|:--|
|[Akamai](https://www.akamai.com/)|業界最大手， SLA 100%|料金体系が不明瞭|
|[CDN77](https://www.cdn77.com/)|[技術的な質問への回答が迅速](http://blog.glidenote.com/blog/2015/08/17/move-to-akamai/)||
|[KeyCDN](https://www.keycdn.com/)|突出して安価 (CloudFront の 1/3)|[低信頼](http://takepara.blogspot.jp/2013/12/cdn.html) (現在は改善)|
|[CDNetworks](http://www.cdnetworks.co.jp/)|[日本語での 24/365 サポート](http://www.cdnetworks.co.jp/about/support.html)|料金体系が不明瞭|
|[Cachefly](https://www.cachefly.com/)|安価かつ[実績あり](https://www.cachefly.com/clients/)||
|[Fastly](https://www.fastly.com/)||高価|

## 料金比較

Akamai と CDNetworks は料金体系が不明瞭だったので除外しています．

### 最低利用料金

毎月必要となる料金です． Fastly のみ月額 50 USD であり，他の CDN は無料でした．

### 転送量あたりの料金

KeyCDN が突出して安価でした．

#### 転送量 10 TB 以下の場合

|CDN|料金 (USD/GB/month)|
|:--|--:|
|KeyCDN|0.040|
|CDN77|0.125|
|CloudFront|0.140|
|Cachefly|0.150|
|Fastly|0.190|

#### 転送量 50 - 100 TB の場合

|CDN|料金 (USD/GB/month)|
|:--|--:|
|KeyCDN|0.04|
|Cachefly|0.08|
|CDN77|0.12|
|CloudFront|0.12|
|Fastly|0.14|

### HTTP メソッドのリクエスト料金

|CDN|料金 (USD/10,000req/month)|
|:--|--:|
|KeyCDN|0|
|CDN77|0|
|Cachefly|0.008|
|CloudFront|0.009|
|Fastly|0.009|

CloudFront では HTTPS を用いると **0.012 USD** となるようです．

## 結論

KeyCDN を採用しました．待機系として用いるため，料金が安価であることが重要でした．また，[他社事例](https://nulab-inc.com/ja/blog/nulab/how-to-overcome-cloudfront-failure/)を参考にできる点も大きかったです．同様の理由により，次点として CDN77 を検討していました．



# おわりに

CDN の冗長化について検討し， CloudFront + KeyCDN + Route53 でシステムを構築することにしました．明日の記事では実際の導入作業やテストの内容について記述します．