AWSは2008年から、自社のバックボーンネットワークを使ったワールドワイドのCDN(Content Delivery Network)である「Amazon CloudFront」を提供している。

 動画のような大きなサイズのデータの配信に限らず、画像とHTMLで構成する一般的なWebサイトでも、スケーラビリティーの向上という面で利用価値が高い。たとえ自社サイトがテレビ番組で取り上げられて想定外にアクセスが急増した場合でも、負荷に耐えられる。

 しかもEC2やS3などと同じように、マネジメントコンソールからすぐに利用を開始でき、運用作業の負担は重くない。CloudFrontを導入したほうがWebサイトの運用や障害対応は軽減されることが多い。AWSの大半のユーザー企業にとって、導入を検討する価値が高いサービスといえる。

 本稿では、HTTP(S)でコンテンツを配信するWeb配信を前提に、CloudFrontの機能を解説する。そのうえで検証として、Webサイトのファイルを更新するたび必要になるインバリデーション(キャッシュ無効化)の所要時間と、Webサーバーがダウンした際のCloudFrontの挙動について試す。

2段階のキャッシュ機構

 まずCloudFrontのネットワーク構成について説明する(図1)。

図1 CloudFrontの構成
[画像のクリックで拡大表示]

 CloudFrontは、Webサーバーのようなコンテンツ配信元(オリジンサーバーと呼ぶ、以下オリジン)とクライアントの間に位置し、ファイルをキャッシュ。クライアントからのリクエストを受け付け、キャッシュしてあるファイルを配信する。リクエストされたファイルがなければオリジンから取得し、クライアントに送る。

 CloudFrontの内部は「エッジサーバー」と「リージョン別エッジキャッシュ」という2段階のキャッシュ機構になっており、前者のほうがクライアントの近くに位置し数が多い。エッジサーバーが配置された地域は「エッジロケーション」と呼び、26カ国59都市の計121カ所に上る(2018年10月時点、画面1)。日本だけでも、東京9カ所、大阪1カ所の合計10カ所にエッジロケーションが設けられている。

画面1 CloudFrontのエッジサーバーは世界展開されている
[画像のクリックで拡大表示]

 クライアントからのリクエストは、ネットワーク的に近い場所にあるエッジサーバーに自動的にルーティングされる。

 エッジロケーションのエッジサーバーとオリジンの間にあるのが、リージョン別エッジキャッシュだ。2016年11月から導入され、2018年10月時点で日本を含む世界11カ所に配置されている。

 エッジサーバーよりキャッシュ容量が大きく、エッジサーバーが1次キャッシュだとすると、2次キャッシュの役割を果たす。エッジサーバーはクライアントからリクエストされたファイルをキャッシュしていない場合、リージョン別エッジキャッシュにリクエストし取得する。リージョン別エッジキャッシュもそのファイルをキャッシュしていない場合は、オリジンから取得してキャッシュし、エッジサーバーに渡す。

 このように2段階のキャッシュを実現し、できるだけクライアントに近い場所からコンテンツを配信して応答性能を高めている。

この先は有料会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら