Power Unit Inc. | 想像力のない者に翼はない | Amazon CloudFront
17355
page-template,page-template-full_width,page-template-full_width-php,page,page-id-17355,qode-quick-links-1.0,woocommerce-no-js,ajax_fade,page_not_loaded,,side_area_uncovered_from_content,columns-4,qode-theme-ver-16.8,qode-theme-bridge,qode_header_in_grid,wpb-js-composer js-comp-ver-5.5.2,vc_responsive
 

Amazon CloudFront

Amazon CloudFront

高速で信頼性の高いグローバルなコンテンツ配信ネットワーク(CDN)サービス

Amazon CloudFront の特徴

高速

世界中に広がる「エッジロケーション」のネットワークを使用することで、Amazon CloudFront では「静的コンテンツ」「オリジン」のコピーをビューワー(エンドユーザー)の近くに「キャッシュ」し、オブジェクトをダウンロードする際のレイテンシー(遅延)を低減し、アクセスの集中するサイズの大きなオブジェクトをエンドユーザーへ大規模に配信するのに必要な高いデータ転送速度を維持することができます。

「動的コンテンツ」へのリクエストは、一貫した信頼性のあるサービスを提供するために、最適化されたネットワークパスを通じて AWS(例えば、Amazon EC2 や Elastic Load Balancing)で動作している「オリジンサーバー」に送られます。これらのネットワークパス(DNS リゾルブ)は自動的にモニタリングされ、CloudFront エッジロケーションからオリジンへの接続は、コンテンツ配信ネットワーク (CDN) から動的コンテンツを最良のパフォーマンスで提供するために再利用されます。

下の 3 つ図は、CDN のキャッシュとオリジン(オリジナルの Web リソース)がどう機能するか、エッジロケーションと  DNS リゾルブがどう機能するか、静的コンテンツ(/images/*)と動的コンテンツ(*.php)の AWS の扱いの違いを表しています。

コンテンツ配信ネットワークの基本機能は、キャッシュによるネットワークアクセスの最適化です。もっとも基本的なケースで、「静的なコンテンツ」を取得する場合、クライアントはサーバにアクセスしてコンテンツを取得しようとします。この時 Amazon CloudFront が仲立ちして、オリジンサーバーにコンテンツの取得を要求する前にエッジロケーションのキャッシュにすでに対応するコンテンツがあるかどうか検証します。キャッシュにない時は、オリジンサーバーにアクセスしてコンテンツを取得し、キャッシュに登録して、クライアントにコンテンツを返します。既にキャッシュにあれば、オリジンサーバーに問い合わせることなくコンテンツをクライアントに返します。

コンテンツ配信における上記のようなネットワークアクセスの最適化によって、クライアントに対するレスポンスを向上するとともに、オリジンサーバーの負荷を軽減することができます。

コンテンツ配信ネットワークでは、最適なエッジロケーションにクライアントからのリクエストを割り振ることが重要です。Amazon CloudFront は、CloudFront DNS と エッジロケーションがクライアントからは透過的に機能します。クライアントからのリクエストの URL アドレスから IP アドレスを解決するために DNS に問い合わせる時に、CloudFront DNS は地理的な位置情報のデータベースに問い合わせて(EDNS Client Subnet Option によってより正確に)クライアントに IP アドレスをレスポンスします。クライアントは、最適なエッジロケーションに対してリクエストを送信できます。

Amazon CloudFront は、「静的コンテンツ」と「動的コンテンツ」を適切にサポートします。同じドメインへコンテンツをアクセスした時、イメージや動画のように変化しない「静的なコンテンツ」とウェブサーバーのバックエンドにあるアプリケーションサーバー経由でデータベースに問い合わせて生成する「動的コンテンツ」ではコンテンツ配信ネットワークは区別する必要があります。

図のように、静的コンテンツ(/images/*)は Amazon S3 に保存し、CloudFront が直接キャッシュを管理します。一方、動的コンテンツ(*.php)は、ロードバランサー ELB を経由してバックエンドの仮想サーバ EC2 のアプリケーションに処理を割り振ります。ユーザーは、静的コンテンツはエッジロケーションの(あれば)キャッシュを、動的コンテンツは(負荷分散された)オリジンサーバーにアクセスします。

シンプル

API を 1 回呼び出すだけで、Amazon CloudFront ネットワークを通じて、Amazon S3 バケットまたは Amazon EC2 インスタンス、他のオリジンサーバからのコンテンツ配信を開始することができます。静的コンテンツと動的コンテンツ用に別々のドメインを作成する必要はありません。CloudFront を使用すれば、同じドメイン名を使用してすべてのウェブサイトコンテンツにポイントできます。既存の設定に対する変更はすべて、数分以内にグローバルネットワーク全体で有効になります。

他の AWS サービスと共に使用できる設計

Amazon CloudFront は他の AWS サービスと組み合わせて使用できるようになっています。既に紹介したように、静的ファイルの最終バージョンを格納する Amazon S3 や、動的に生成されたコンテンツ用のアプリケーションサーバを実行する Amazon EC2 などです。Amazon CloudFront は、Elastic Load Balancing とも連携しています。例えば、Elastic Load Balancing の後方で Amazon EC2 サーバーでウェブアプリケーションをデプロイし、Amazon CloudFront を使用してウェブサイト全体を配信することができます。

Amazon CloudFront がないアーキテクチャーでは、ユーザーからのリクエストに対していずれかの Amazon EC2 インスタンスの Web サーバーもしくはアプリケーションサーバがデータベース Amazon RDS に問い合わせた結果をレスポンスとして返します。このアーキテクチャーの最大の問題点は Amazon EC2 インスタンスのロードアベレージに柔軟に最適化された負荷分散ができないことです。

Amazon CloudFront を利用したより柔軟で最適化されたアーキテクチャーは以下のようになります。静的なコンテンツは Amazon S3 でホストすることによって Web サーバーやアプリケーションサーバの負荷をオフロードできます。これによって、Amazon EC2 インスタンスは動的コンテンツの処理やデータベース Amazon RDS への問い合わせに集中することが可能でスケールダウンする(より少ないインスタンスで処理可能)ことができます。

以下の図は、お客様の Web サービスの負荷のオフロードの最適化を表しています。Amazon CloudFront がないときは、Web サービスを実行している Amazon EC2 インスタンスに対して最も負荷がかかります。静的なコンテンツの配信を Amazon CloudFront でオフロードすると、Amazon EC2 インスタンスに対する負荷が軽減されます。さらに、動的なコンテンツの配信に対しても Amazon CloudFront でオフロードされると、システム全体の負荷を最適化可能です。

2 層 Web サービスのより進した(実際のプロダクトユースの)アーキテクチャーは以下のようになります。Amazon Route 53 は DNS サービスです。これによっていわゆるドメインと IP アドレスの対応を関連付けます。Amazon CloudFront は、Amazon Route 53 の関係で便宜上省かれていますが、基本的には Elastic Load Balancer (ELB) の前に配置されます。ELB は、AZ A と AZ B という異なるアベイラビリティーゾーンをまたいで分散的に Amazon EC2 の負荷分散をサポートします。Amazon EC2 は、Amazon CloudWatch をつかさどるデーモンとマネージャーでサーバーの状態を監視することで自動的にスケール可能です。システムが正常な場合は、AZ A にあるマスターデータベースに読み込み・書き込み・問い合わせなどを実行します。このとき、AZ B のデータベースはレプリカ(バックアップコピー)になります。さらに、Amazon EC2 とデータベース Amazon RDS 間に Amazon ElasticCache を配置して、データベースのアクセスをメモリー内のキャッシュを利用することでさらに高速化します。

コスト効率

Amazon CloudFront では、Amazon のスケーリングメリットをそのまま享受できます。ネットワークを通じて配信するコンテンツに対してのみお支払いいただきます。最小限のコミットメントや料金の前払いはありません。これは、配信するコンテンツの種類が静的コンテンツ、動的コンテンツ、ストリーミングメディア、ウェブアプリケーション、またはこれらの組み合わせのいずれの場合であっても同じです。

スケーラビリティ

Amazon CloudFront を使用すれば、コンテンツへのトラフィックのスパイクから生じる需要に対応するために、高価なウェブサーバーのキャパシティを維持もしくはプロビジョニング(準備)することについて心配する必要はありません。アクセスの増減に応じて、サービスが自動的にスケーリングします。お客様が介入する必要はありません。

また、Amazon CloudFront は複数のレイヤーを使用して各エッジロケーションでキャッシュし、同じオブジェクトに対する同時リクエストを減らしてからオリジンサーバーにアクセスします。こういった最適化が行われるため、お客様のウェブサイト利用が増えても、オリジンインフラストラクチャを拡張する必要性を抑えることができます。

信頼性

Amazon CloudFront は、Amazon の極めて信頼性の高いインフラストラクチャを使用して構築されています。Amazon CloudFront で使用するエッジロケーションは分散特性を備えており、エンドユーザーは、ネットワーク状況によって利用可能な最寄りのロケーションに自動的にルーティングされます。エッジロケーションから AWS オリジンサーバー(例えば、Amazon EC2 や Amazon S3)へのオリジンリクエストは、Amazon が継続的にモニタリングして可用性とパフォーマンスを最適化しているネットワークパス上で伝送されます。

Amazon CloudFront のユースケース

ウェブサイトまたはウェブアプリケーション全体を配信

一般的なウェブサイトには、通常、静的なコンテンツと動的なコンテンツが混在しています。静的なコンテンツには画像やスタイルシートが含まれ、動的、つまりアプリケーションによって生成されるコンテンツには、画面に応じてパーソナライズされたサイト要素が含まれます。ウェブサイトには、ユーザーがログインしたり、検索やコメントを投稿するためのフォームもあるかもしれません。

単一の CloudFront ディストリビューションをコンテンツ配信ネットワークとして使用して、静的、動的、およびインタラクティブなコンテンツを含むウェブサイト全体をエンドユーザーに配信したり、エンドユーザーが配信元にコンテンツをアップロードしたりすることができます。これは、静的コンテンツと動的コンテンツを分割する必要がないため、ウェブサイト全体で 1 つのドメイン名(例えば “www.mysite.com”)を使えることを意味します。

ウェブサイト上の異なる種類のコンテンツに別個のオリジンサーバーを使うことも可能です。Amazon CloudFront が提供する詳細なコントロールを使用すれば、複数のオリジンサーバーを設定し、サイト上の異なる URL のプロパティをキャッシュすることが可能です。こういったパフォーマンス最適化と機能はお客様のウェブサイト全体のダウンロードを高速化し、サイトの利用低下を防止するのに役立ちます。

Amazon CloudFront は、各エッジロケーションに静的コンテンツをキャッシュします。つまり、お客様のサイトでよく使われる静的コンテンツ(サイトのロゴ、ナビゲーション画像、カスケーディングスタイルシート、JavaScript コードなど)を近くのエッジロケーションで利用できるため、ブラウザへのダウンロードに要する時間が短くなり、性能が向上します。

Amazon CloudFront を利用して、よく使われる静的コンテンツをキャッシュすると、オリジンサーバーにあるファイルへのリクエスト負荷をなくすこともできます。CloudFront は、キャッシュされたコピーを使用できる場合はこれを提供し、ブラウザのリクエストを受信したエッジロケーションにファイルのコピーがない場合にのみ、オリジンサーバーにリクエストを送信します。

上の図の ① – ② – ③ の経路です。

Amazon CloudFront は動的またはインタラクティブコンテンツ(例:ウェブフォーム、コメント、ログインボックスなど)のリクエストを AWS のリージョンで稼働するオリジンまたは他のオリジンに対してプロキシします。各エンドユーザーは、インターネット待ち時間に基づいて、それぞれ最も近いエッジロケーションに割り当てられます。Amazon は接続のパフォーマンス監視と最適化を行っており、ユーザーのリクエストは、最適化された接続上にある AWS で稼動するオリジンサーバーに送られます。

また、CloudFront エッジとオリジンサーバー間の既存の接続は再利用され、オリジンへの各リクエストの接続セットアップ待ち時間が短縮されます。他にも接続最適化策が採用されており、インターネットの障害を回避し、エッジロケーションとユーザーの間で利用できる帯域幅を最大限に活用します。

つまり、Amazon CloudFront により動的コンテンツの配信が高速化され、ユーザーによるウェブアプリケーション操作において、一貫していて信頼性の高い、なおかつパーソナライズされた閲覧が可能となります。

上の図の ① – ② – ④ – [ ⑤ – ⑥ ] – ⑦ の経路です。

Amazon CloudFront では、コンテンツをオリジンサーバーへアップロードすることもできます。コンテンツのアップロードのリクエストはすべて、Amazon CloudFront エッジロケーションによりオリジンに対してプロキシされます。Amazon CloudFront では、動的コンテンツのダウンロードを求めるリクエストに適用されるのと同じパフォーマンス上の利点が、アップロードリクエストにも提供されます。

Amazon CloudFront エッジロケーションを使用して、大容量ファイル(ファイルあたり 20GB まで)を PUT HTTP メソッドによりオリジンへアップロードすることもできます。さらに、GET、HEAD、POST、PUT、DELETE、PATCH、および OPTIONS などの HTTP メソッドを使用して API を配信するために、Amazon CloudFront を使用することもできます。

ソフトウェアやその他の大容量ファイルの配布

Amazon CloudFront は、アプリケーション、アップデート、またはその他ダウンロード可能な大容量ファイルをエンドユーザーに配信したいソフトウェア開発者にとって、優れた選択肢の一つです。Amazon CloudFront の高速なデータ転送により、お客様のアプリケーションのダウンロードが高速化され、カスタマー体験が改善され、コストが削減されます。また、使用量が多い場合は、Amazon CloudFront は Amazon S3 よりも低い料金でご利用いただけます。

メディアファイルの配信

お客様のアプリケーションに、頻繁にアクセスされるリッチメディア(音声や動画)が含まれる場合、Amazon CloudFront を使用することにより、より低額なデータ転送料金およびデータ転送速度の改善というメリットを活用できます。Amazon CloudFront には、メディアファイル配信のための複数のオプションがあります。事前に作成されたメディア(オンデマンド)にもライブメディア(ストリーミング)にも対応します。

  1. シンプルで安全 … Amazon S3 は、耐久性、可用性、低コストを兼ね備えた最もシンプルなデータストレージサービスです。Web サイトの静的なコンテンツのホストに最適でしょう。Web サイトの静的なコンテンツを S3 でホストすることによって、Web サーバ本体のワークロードを大幅に削減することができます。また、コンテンツを HTTPS で保護することもできます。
  2. 高速でかつ制御可能なエッジ … 顧客の増加し裾野が広がると地理的な分散が起こるでしょう。Amazon CloudFront なら、レイテンシー(遅延)を改善し、フォールトトレランスで、コストが安い高性能なエッジキャッシュに対応できます。Amazon S3 を Amazon CloudFront 配信ネットワークのオリジンサーバーにすれば、高速なネットワーク内のデータ転送レートの優位性を増大したり、シンプルな配信・キャッシングのワークフローを実現し、統合された安全性のフレームワークを提供します。
  3. 柔軟なオリジンサーバー … 別の方法では、静的なコンテンツのための Amazon S3 のためのオリジンサーバとして Amazon EC2 を使用することもできます。Amazon EC2 を使用すれば、より柔軟な制御、ログ収集、コンテンツの高度なサービスを実現できます。静的なコンテンツのオリジンとして、オンプレミスもしくは完全にプライベートなサーバーを Amazon CloudFront のオリジンサーバーに指定することもできます。
  4. ライブストリーミング … Amazon EC2 上でホストする Adobe Flash Media Server とストリーミング配信とキャッシュのための Amazon CloudFront を組み合わせると、AWS プラットフォームでライブストリーミングがシームレスに機能します。注意:Adobe Flash はすでに古い技術です。Web 標準の HTTP Live Streaming (HLS) を考慮してください。

オンデマンド配信メディアおよびライブ配信メディアのワークフローを融合したアーキテクチャーを詳細にした図が以下です。例えば、テレビ局のメディア配信の基幹業務システムだとお考えください。非常に複雑なダイアグラムですが、大きく分けて 5 つのワークフローから構成されています。

  1. 左側の黒い領域は企業内メディアライブラリ(AWS ではなく完全にプライベートな領域)です。上側がオンデマンド配信メディアのオリジナルデータで、下側がライブ配信メディアとエンコーダー(エンドユーザーの環境に最適なメディア形式を複数の形式に変換します)です。
  2. 企業内メディアライブラリと AWS のブリッジ領域があります。オンデマンド配信メディアに対しては AWS Inport/Export Snowball で丸ごと Amazon S3 にコピーする方法、AWS Storage Gateway 経由で S3 に読み込む方法、3rd パーティーのファイル転送アクセラレータなどで S3 にコピーする方法があります。ライブ配信メディアはAWS 内部に読み込んだデータを Amazon EC2 インスタンスで動作しているメディアストリーミングサーバーで配信します。
  3. オンデマンド配信メディアに対しては、S3 に読み込まれると SQS に対しトリガーが発生します。AWS Elastic Transcoder でメディアを様々な形式に変換します。その結果が SQS に対してトリガーを発生し、Amazon CloudFront で配信する変換済みのデータとして S3 に保存されます。データは、あらかじめ設定されたライフサイクルに基づいて Amazon Glacier に退避することもできます。一方、ライブ配信メディアは EC2 のストリーミングサーバが配信するデータをそのまま Amazon CloudFront に渡します。
  4. オンデマンド配信メディアは、S3 から CloudFront に渡されたデータが世界中のエッジに配信されます。ライブ配信メディアも同様に CloudFront に渡されたデータが世界中のエッジに配信されます。
  5. エンドユーザーは、モバイルデバイス、ゲームコンソール、PC などに最適化されたメディアコンテンツを最もレスポンスがいいエッジロケーションから受信して再生することができます。

Amazon CloudFront を使用すると、世界中の視聴者を対象にしたオンデマンドでの可変長ビットレートメディアコンテンツの大規模配信が可能です。Microsoft Smooth Streaming フォーマットを使用して Microsoft Silverlight プレーヤー(PC)にコンテンツをストリーミングするか、HTTP Live Streaming(HLS)フォーマットを使用してモバイルデバイスにストリーミングするかにかかわらず、Amazon CloudFront を使用すればサードパーティのメディアサーバーの設定や管理は不要です。

さらに、Amazon CloudFront の標準的なデータ転送とデータリクエストに課される料金以外の追加料金は発生しません。お客様は、使用するフォーマットに応じたメディアファイルをエンコードし、使用するオリジンにアップロードするだけで済みます。

Amazon CloudFront には、Wowza、Adobe および Microsoft のサードパーティメディアサーバーに簡単に統合でき、複数のデバイスで視聴している世界中の視聴者にコスト効率の高い HTTP 経由(Amazon CloudFront ウェブディストリビューションを使用して)のライブイベント配信ができる複数のオプションが用意されています。

音声や動画のライブイベントを全世界に配信する必要がある場合、Amazon CloudFront は、ライブメディアを短期間キャッシュし、同じメディアフラグメントへの同時リクエストについて、オリジンに送信されるリクエスト数を減らします。これにより、パフォーマンスが改善され、オリジンのインフラストラクチャへのリクエスト負荷が軽減されます。

Amazon CloudFront のライブ HTTP ソリューションを使用すると、PC およびモバイルデバイスの両方を含め、さまざまなデバイスプラットフォームを使用するユーザーへのライブイベントの配信が可能です。

メディアコンテンツのオリジナルバージョンを Amazon S3 に保管し、動画と音声ファイルのプログレッシブダウンロード向けに Amazon CloudFront ダウンロードディストリビューションを設定できます。よく使われるメディアファイルはエッジでキャッシュされるため、スケールすることが可能であり、ユーザーに最大限のパフォーマンスを提供します。