技術者ブログ

クラウド型WAF「Scutum(スキュータム)」の開発者/エンジニアによるブログです。
金床“Kanatoko”をはじめとする株式会社ビットフォレストの技術チームが、“WAFを支える技術”をテーマに幅広く、不定期に更新中!

2017年10月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
  • お問い合わせはこちら
Scutum開発者/エンジニアによる技術ブログ WAF Tech Blog

CDNはじめました

はじめに

私たちが提供するSaaS型のWAFサービス、Scutum(スキュータム)に、CDNオプションが追加されました(CDNオプションについて、くわしくはこちらのページを参照ください)。今回は、主に開発者の視点から、このCDNオプションサービスの紹介をさせていただきたいと思います。

AkamaiのCDNサービスを利用

ScutumのCDNオプションにおいて、実際のCDNのサービスとしては、Akamaiを利用しています。Akamaiは言わずと知れたCDN界の巨人で、日本国内にも数多くのCDNサーバ(CDNにおいてエンドユーザへのコンテンツ配信に使われるサーバはPoPサーバ、エッジサーバなどとも呼ばれますが、ここではCDNサーバで統一します)を持っています。既に多くのサイトで利用されており、国内の著名なマスメディアのサイトなどでも広く利用されています。

AkamaiはCDN業界では老舗的な存在ですが、CDN業界も最近の数年の間にAmazon(CloudFront)やCloudFlareが参戦するなど激戦が続いており、CDN Planetなどでその様子をうかがうことができます。


http://www.cdnplanet.comより (2012/11/29時点)

上記のように数多くのCDNサービスがしのぎを削っている状態となっていますが、この中でも筆者が特に注目しているのはCDN77.comで、APIをサポートしつつ、1TBで49ドルという破格の値段を提示しています。日本国内にもCDNサーバがあるようですが、残念ながら現状はおそらく東京の一箇所だけとなっているので、国内のユーザ向けのCDNとしてはまだまだ使えない(東京にウェブサーバを置いている状態と変わりない)という感触です。

しかし東京にCDNサーバがあるだけまだマシな方で、サービスによっては日本国内に1つもCDNサーバが無い、というケースもあります。CDNサービスを俯瞰すると、まだまだ国際的には、日本は単なる一地域でしかないんだな、と感じさせられます。

Amazon Web Services(CloudFront)との比較

Akamaiを利用していると書きましたが、形態としては、RackspaceCloudFilesという名前のサービスを経由してAkamaiを利用しています。Rackspaceは日本国内ではまだまだ名前が知られていませんが、英語圏ではAmazon Web Services(AWS)のクラウドへの対抗馬としてよく知られた存在で、EC2やS3と直接競合するタイプのサービスを展開しています。

このうちS3に競合するサービスがCloudFilesであり、クラウド上にファイルを置くと、それがAkamaiのCDN経由でアクセスできるようになるというサービスとなっています。つまり、Rackspaceのサービスを利用すると、自動的に老舗のCDNサービスであるAkamaiのCDNが使える形になっているのです。Akamaiのウェブサイトでは、このようなAPIベース+完全従量課金の利用方法については記載が無かった(見つけられなかっただけかもしれません)ことから、私たちのようにAPI経由でのCDNの利用を前提としている場合、CloudFilesは有力な候補となります。

Rackspaceはそのクラウド基盤技術をOpenStackという名前でオープンソースとして公開しており、国内でもいくつかの会社がOpenStackベースでIaaS型のクラウドサービスを展開したりしています。こちらのプレスリリースによるとAkamaiもOpenStackコミュニティに参加しており、その関係でCloudFiles経由でAkamaiのCDNが使えるようになっているのではないかと思われます。

RackspaceではウェブベースのAPIが整備されており、CloudFilesへのファイルのアップロードなどはすべてコードを書くことで実現することができ、アプリケーション内で完結させることができます。このような特徴はおそらく先行していたAWSのCloudFrontを模倣したものであり、価格体系が完全従量課金であることからも、CloudFrontを強く意識したものだろうと推測できます。

私たちは当初、プログラミングとの親和性が高いことからAWSのCloudFrontを利用してCDNオプションを実装することを考えていましたが、以下の2つの理由から、最終的にはCloudFilesを選択しました。

  • 1GBあたりの単価が安い(AWSは0.201$、CloudFilesは0.18$)
  • 日本国内のCDNサーバの数が、CloudFiles(Akamai)の方が圧倒的に多い

とはいえ、どちらのサービスも私たちがCDNサービスに期待する以下の条件を満たしており、非常に高いレベルのサービスが揃って来ているな、という印象です。

  • APIのサポート
  • 完全従量課金制
  • SSLのサポート
  • 国内の複数箇所へのCDNサーバの配置

CloudFilesとAWSの両方について、APIを実際に使ってファイルのアップロードからCDN経由のアクセスまでを実装してみましたが、使いやすさはどちらもやや(必要以上に)複雑なところがあり、使いやすさとしては同点といったところでした。

Scutumでは現時点ではCDNサービスとしてCloudFilesを使っていますが、AWS等の競合サービスがさらに進化を遂げた場合には、柔軟に利用するCDNサービスを切り替え、より良いサービスを提供できるように変化していくことも考えています。

リダイレクト型のCDN

ScutumのCDNオプションは、一般的なCDNサービスとはやや異なる形で動作します。多くのCDNサービスでは、ウェブサイトのFQDN(www.example.jpなど)に紐づけられたIPアドレスはCDNサーバのものになっており、ユーザはウェブサイトを開く際に直接CDNサーバに接続します。そのため、下図のように、リクエストとレスポンスの2ステップで通信が完了します(コンテンツがキャッシュされていない場合はウェブサーバとの間で通信が発生するため4ステップになります)。

しかしScutumの場合には、ユーザがまずはじめにアクセスするサーバは、常にScutumのサーバとなります。リクエストされたファイルがCDNにキャッシュされている場合には、Scutumサーバはステータスコード302のリダイレクトを意味するレスポンスを送信します。ユーザはこれに従ってCDNサーバにアクセスを行い、結果としてCDNサーバから画像ファイル等のキャッシュ対象ファイルが配信されることになります。

ウェブサイトのホスト名が『www.example.jp』の場合、ユーザがアクセスするファイルのURLは、例として『http://www.example.jp/foo.gif』のようになります。一般的なCDNサービスではユーザはそのURLのままCDNサーバへとアクセスすることになり、キャッシュされている・されていないに関わらず、画像のURLはこの1通りになります。

これに対しScutumのCDNオプションでは、画像がCDNにキャッシュされている場合、302によってリダイレクトされ、『http://123(中略)789.rackcdn.com/foo.gif』のような、『www.example.jp』とは異なる、ユニークに生成されたCDN用のホスト上のURLによって、キャッシュされた画像が示されるようになります。

上記のような違いのため、ScutumのCDNオプションでは、(リダイレクト型ではない)一般的なCDNサービスに比べ、以下のようなメリット・デメリットが存在します。

メリット

  • CDNを使うかどうか、つまりCDN機能の有効・無効が即時に反映される
  • ネットワーク帯域の消費と連携し、サイトが混雑したときのみCDNを有効にする、ということが可能
  • 画像などの静的なコンテンツと動的なページのホスト名を分けるなど、ウェブサイト側におけるCDN導入に向けた変更が必要ない

デメリット

  • SSLでアクセスした場合に、ウェブページとそれに含まれる画像のホスト名が異なるため、一部携帯電話などでエラーが発生する可能性がある
  • コンテンツによってはSame Origin Policyとの関係で、うまく動作しない場合がある
  • 2ステップではなく4ステップのアクセスとなるため、画像が表示されるまでの速度がわずかに遅くなる

3点ほどデメリットを挙げましたが、1点目についてはCDNを『HTTPのみ有効』とすることで容易に回避できます。携帯電話からのアクセスが多いウェブサイトの場合には『HTTPのみ』についてCDNを利用いただくことをお奨めしています。

2点目については、JavaScriptのファイルをCDN上にキャッシュした場合にエラーが起こるケースが考えられます。CDNにキャッシュするファイルについては拡張子別に設定することが可能ですので、gifやjpeg、pngなどの画像のみをキャッシュするようにすることで、これを回避することができます。

3点目については、一般的な2ステップのCDNサービスに比べると遅くなるのは仕方がありませんが、元々Scutumでは通信は4ステップとなっているため、CDNの導入によって速度が遅くなることは、基本的にはありません。むしろCDNサーバはユーザのブラウザから見てScutumのサーバよりも近くにある場合が多いと考えられるため、4ステップとはいえ、CDNを導入することでレスポンスの速度は向上する可能性が高いと考えています。

料金体系

先述したようにCloudFilesではCDNで発生した転送量に対し完全従量課金がおこなわれるので、Scutumサービスとしては、CDN機能を定額で制限なく提供することはできません。現在は、まずはCDNを使えるようにし、お客様からどのような反応があるかどうかを探る段階と位置づけ、各ウェブサイトで毎月100GBを上限に、無料でCDN機能を使えるようになっています。

ぜひCDN機能をご利用頂き、ご希望やご感想などをお寄せ頂ければと思います。

余談:Rackspace/Akamaiとのトラブルシューティング

CDNサービスの開発において非常に印象が大きかったのが、RackspaceとAkamaiとのトラブルシューティングです。最初にRackspaceでCDNを実装した際、CDNの名前解決で問題がありました。

通常、CDNでは、『12345.rackcdn.com』のようなCDNサーバのホスト名について名前解決を行うと、ユーザから最も近くにあるCDNサーバのIPアドレスが返されます。Akamaiのサーバは日本国内にも非常にたくさん配置されており、通常pingを実行すると、日本全国どこでも、大体2ms〜10ms程度の距離にAkamaiのサーバが発見できます。

しかし私たちが各自の自宅や会社、モバイルルータなどを利用してさまざまなアクセスポイントからpingを実施してみると、5割程度の場所から、100ms以上かかる、海外のAkamaiのサーバのIPアドレスが返されてしまうという状態でした。

当初はこれでは使い物にならないのでAWSのCloudFrontで行くか、とも思ったのですが、とりあえずダメもとでRackspaceのサポートから問い合わせてみることにしました。実はRackspaceはユーザサポートに非常に力を入れているという特徴があり、ウェブサイトではチャットで手軽に質問ができる他、管理コンソールからチケットシステムを使って問い合わせを行うことができます。チケットシステムでは現在ボールを持っているのがユーザ側なのかRackspace側なのかがはっきりわかるようになっており、また、Rackspace側で進展があった場合にはメールで通知が飛んでくるようになっています。

Rackspace内のエンジニアは私からの問い合わせに対して簡単に切り分けを行い、すぐにAkamaiにエスカレーションしてくれました。Akamai側も私に効果的な質問を行い、結果として比較的短期間でこの現象が解消されました。チケットシステムが非常にうまく働き、またRackspaceもAkamaiもエンジニアが予想以上に素早く対応してくれたので、筆者としては願ってもない、非常にうれしい展開となりました。Akamaiのような巨人でも、比較的短期間で、ネットワーク上の大きな問題に対応してくれるというのは、とても興味深い事だなと感じました。技術力のあるエンジニアがサポートもきちんとこなしてくれるというのは非常にありがたいことです。Rackspace/Akamaiのこの高いサポート力は、AWSと競う上で、ひとつの大きなポイントになるだろうと思います。

おわりに

今回はScutumのCDNサービスについて、一般的なCDNとの違いや、実装する上での苦労話などについて、開発者の視点からお送りさせて頂きました。もしCloudFilesやAWS以上によいCDNサービスをご存じでしたら、@kinyukaまでお知らせ頂ければ幸いです。