はじめに
出版物の海賊版をネット上で公開したとして逮捕された"漫画村"の事件は
みなさん記憶に新しいかと思います。
昨今、ネット上で動画や音楽などさまざまなものを楽しめる時代です。出版物のサブスクというのもくるのではないかといわれています。
以下"海賊版"のWikipediaより一文引用します。
海賊版（かいぞくばん）は、法律上の権利を無視して諸権利を有しない者により権利者に無断で発売または流通される非合法商品である。
権利の生じているものを無断でネット上に公開することは確かに問題だと思います。
ただ、この問題はここで止まりませんでした。
まずは以下の記事を読んでみて欲しいです。（無料公開部分だけでも良いかと思います。）
"小学館、集英社、講談社、ＫＡＤＯＫＡＷＡの大手出版４社"がCDN事業者を提訴するに至りました。今回、この問題を技術的に考えてみたいです。
モチベーション
背景として、私はインターン生時代にCDNを使って某コンテンツを配信しておりました。
なのでそこそこ知識はあると思います。
CDNサービス、知名度は高いのですが、意外と実際に運用経験のある人は少ないかと思います。CDNというサービスは"巨大な数のコンシューマをもつコンテンツ事業者向け"のサービスであり、サービス立ち上げ当初の会社や社内システムなどでは絡みづらいサービスだからです。
今回は、読者としてプログラミングに興味あります！くらいの人を想定して書いてみたいと思います。
CDN(Content Delivery Network)とは何か？
CDNとはWebコンテンツをデリバリーするための独自ネットワークを提供するサービスです。
ここで言う「コンテンツ」は何を指すかと言うと、誤解を恐れずに言うのならば、WebブラウザにURLを入力して表示できるものほぼ全てを指します。
今のChromeなどのWebブラウザは凄くて、jpegやpngはもちろんのこと、例えばpdfも見れますし、mp３などのファイルもURLを叩くとダウンロードしたりできますよね。htmlの中にこれらのjepgやpng, pdfなどが埋め込まれているようなページもあります。全て合わせてコンテンツです。
なぜCDNが必要なのか？
なぜCDNが必要かについて、上に掲載した記事リンクは非常に適切に説明しているなと思いました。
記事中に以下の文があります。
インターネットは距離が長くなると通信速度が遅くなり、コストも高くなる。
出版社側の分析では、今回の訴訟に関わる海賊版サイトは月間3億回のアクセスがあり、配信されているデータの量は少なくとも210億メガバイトに上る。
これだけ膨大なデータを送信する設備を海賊版サイトの運営者が自ら用意することは難しく、用意できたとしてもデータ通信料だけで年間10億円を超えるという。
従って、海賊版サイトが技術的にも経済的にも運営できているのは、クラウドフレアのCDNがほとんどの配信を肩代わりしているからだというのだ。
ここで「これだけ膨大なデータを送信する設備を海賊版サイトの運営者が自ら用意することは難しく、」 と掲載があります。これについて少し深掘りして考えてみます。
いろいろメリットがあるCDNですが、今回は以下2点の観点から捉えてみます。
- サーバー負荷の肩代わり
- ネットワーク負荷の肩代わり （+エコ）
実際の例で考えてみる
ちょうどこれを書いている時には某女性プロゲーマーが不適切発言(170cm)で炎上し、所属していたプロゲームチームのWebサイトがダウンしておりました。
ページでは以下のように出ていました。
Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
例えばある会社AのWebページに普段訪れる人の数はだいたい1日あたり500人程度だったとして、このくらいなら大丈夫だと思いインフラエンジニアはサーバ1台でこれを運用していたとします。このサーバは1台で500のリクエストを処理していることになります。
今回の例のように、ある日、突然アクセス者が1万人になったら、このサーバは10000リクエストを処理しないといけません。これは無理!! となり、上のサイトのように突然サーバが落ちるわけです。このようにWebサービスの運用はユーザ数の予測が鍵になります。
サーバー負荷の肩代わり
では、CDNは何をしてくれているのかというと、我々の住んでいる各々のマンションなどから**"インターネット的に"近い場所に代理のサーバをたて、前述の会社Aのサーバの代わりに、このCDN事業者がもっているサーバからコンテンツを我々に配信してくれる**サービスを提供してくれています。
肩代わりしている以上、大元の会社Aのサーバマシンは肩代わりしてくれるサーバとの通信のみすれば良いわけです。つまりCDNサービスが19台のサーバを貸してくれたら1+19で20台分の処理ができます。これならA社が管理するサーバは1台のままでも10000リクエストを捌けそうです。
実世界で考えてみると以下の様になります。
- 商品が置いてある倉庫と本店 →A社の用意したWebサーバとその上のコンテンツ(html, js, css, jpeg...) →オリジンサーバといいます。
- 各地に置かれた配送する支店→CDNの提供した肩代わりサーバ →エッジサーバといいます。
- 消費者→アクセス元となる私たちのPC→Webブラウザ
この"エッジサーバ"と"オリジンサーバ" と言う用語、後でまた出てきますので覚えておいてください。
ネットワーク負荷の肩代わり (+エコ)
ここまでで、サーバからのWebページの配信を肩代わりしてくれるサービスなのはわかったかと思います。
では、これがどう美味しいのでしょうか。自分がもっているサーバ数を1台から20台にふやせばいいんじゃないの？と思われる方もいると思います。
配信に関するもう一点の要素が運ぶ時間と距離です。
先ほどの例で
商品が置いてある倉庫と本店 (オリジンサーバ) vs 各地に置かれた配送する支店 (エッジサーバ)
を例に出しました。
本店から沖縄と北海道に物を運ぶためには早いトラック数十台の非常に強固な足を用意する必要があります。Webコンテンツを配信するネットワーク上でも同じで、大量のリクエストを受け付けるには会社Aのサーバ周りのネットワーク機器も大容量のコンテンツを流せるくらい強固にしないといけません。
同じ道のりを何度も同じ物を運ぶのは無駄が多いです。例えばりんご100個の注文が入ったと思い、トラックにのせて沖縄までりんご100個を送ったと思ったら、その次の日にまたりんご100個が注文されたらまた本店からトラックが出動することになります。高速道路(インターネット)は混み、みんなに迷惑がかかります。これをやる会社が1000社あったら、高速道路もかなり迷惑かと思います。単純に、りんごの人気があるのだから、支店にたくさん置いておきませんか？ という提案がでるかと思います。
これを愚直にやってくれるのがCDN事業者であり、
人気のあるコンテンツは常にCDNが管理するエッジサーバ上に保存しておくことで、何度も何度も同じコンテンツに対して足(ネットワーク)を圧迫することなくコンテンツを配信することができるようになるのです。
これはインターネットに対しての"エコ活動"とも言えます。
【新しい用語】 キャッシュヒット率
いきなりですが、ここで新しい用語です。人気のあるコンテンツ（りんご）はエッジサーバに置いておき、といいましたが、このおいておくことをIT用語ではキャッシュといいます。
エッジサーバにないものはもちろんオリジンサーバ(本店)に問い合わせることになります。言い換えるとキャッシュにヒットしなければそれは負荷になるということです。
CDNの有効性を判断する指標の一つにこのキャッシュにどのくらいヒットするかの比率 キャッシュヒット率 があります。100リクエストのうち、99%のコンテンツはエッジサーバにあったのならば、キャッシュヒット率は99%になります。
今回の記事で書いてある
「クラウドフレアからの配信がデータ量の９９％以上」
という一文はあながち間違いではなく、実際にキャッシュヒット率が99%程度はサービスを運用しているとよくあることです。みんなが見ているコンテンツというのは、基本的にキャッシュされ続けるため、キャッシュヒット率が非常に高くなります。データの配信元もCDNになるので、このキャッシュヒット率は配信データ量の割合ともほとんど同義と言えます。
CDNの運用について
CDNの運用について少し語ります。
まず、CDNを運用するのはサービス提供者になります。この運用する内容について
どのWebページを助けてもらうか
のみです。細かい設定はありますが、基本的にはどのサイトのどのコンテンツに対してのアクセスを助けてもらうかを細かく定義していく作業になります。
webのレスポンスなどをみると結構いろんな情報が載っていて、CDN系の情報も見たりできます。試しにgoogle mapにアクセスし、一緒にダウンロードされた ja.js というファイルのレスポンスを見てみました。
Request URL: https://ssl.gstatic.com/inputtools/js/ln/17/ja.js
...
cache-control: public, max-age=86400
server: sffe
レスポンスを見ながらきちんとCDN経由で配信がされているかどうか、設定がうまくいっているかどうかを確認していくのが運用です。
運用していく上で見極めないといけないのは、コンテンツの特性です。
例えば、コンテンツが更新されやすいようなページだった場合、キャッシュに残っているとコンテンツがずっと古いままになってしまいます。これを防ぐためにキャッシュにはコンテンツの更新頻度に合わせた生存期間(TTL)を指定することが多いです。
例えば漫画の海賊版サイトについて考えてみると、ある漫画のページはコンテンツとして完成しているため、他のコンテンツに差し代わることがないと思われます。そのためこのTTLはかなり長めに取れるはずです。CDNとは相性がいいコンテンツと言えます。
また、これらのキャッシュをCDN事業者側で消すことは基本的にはありえません。例えば秒間100万アクセスきているコンテンツをCDN事業者がいきなり消すと、100万アクセスが同時にA社のサーバに行くことになります。確実にWebサーバはキャパオーバーし、サービス停止になります。
一方で、"どうしても権利面でコンテンツをネット上から配信できなくしたい"という場面などに備え、CDN上のサーバから特定のコンテンツのキャッシュを削除する手段も用意されています。あくまでコンテンツ提供者のA社の判断で実施するものです。一応、コンテンツの権利を守るために手段を用意してくれているのです。
CDN事業者に求められるリテラシーとは
これらの海賊版の配信に対して、CDNを提供するのは確かに問題かもしれません。
今回のようにサービス提供するCDN側にも問題はあるという考えもあるし、各企業も「自社のコンテンツをどうやって守るか」を真剣に考えることも大事です。
また、個人的にはBtoBのCDNサービスは付き合う顧客を選べるのでまだ対応できるかと思いますが、これがBtoCも提供可能なクラウドサービスなどになると話が変わってきます。
例えばCloud FrontというAWSのサービスはまさにCDNのサービスをクラウド上で提供するためのものです。利用開始まで2時間かからずにCDNを含めたサービス展開ができます。
コンテンツの保護という観点ではネットは弱いと言わざるを得ないです。業界大手のAkamaiなどは権利あるコンテンツを配信するソリューションとして、自社のコンテンツの権利保護のための取り組みを積極的に主張しています。
多分IT系の会社の方にはCDNを提供していただけでこのような裁判になるのか..と驚く方もいると思います。
現状ではネット上のコンテンツ提供者は何のコンテンツを提供しているかのリテラシーも気にする時代になっていると思います。一方で、ネットワークやサーバなどを提供するインフラ企業も同様のリテラシーをもてと言われるのは（現状では）少し疑問もあります。
例えば、通信事業者はこの情報は秘匿に扱うというのが決まっています。NTTが私たち一人ひとりの通信内容を細かく把握していたら怖いなと思うと思います。これが禁止されている以上、扱う場を提供したからといって責められても..と思います。
インフラ(通信)とコンテンツサービス事業社の間に位置しているCDN事業者というのは、このリテラシーについてまさに間の立ち位置にいるかと思います。今後も私個人として記事の裁判の結果には注目したいと思います。
おわりに
今回は用語解説を踏まえてCDNの技術を考えてみました。