Amazon CloudFront を活用したウェブサイトの可用性向上

Amazon CloudFront は、キャッシュ機能によるオリジンサーバー（CloudFront がコンテンツを取得する元のウェブサーバー）の負荷軽減とコンテンツ配信のパフォーマンス向上を実現できますが、可用性の向上もCloudFrontを活用することで得られる大きなメリットの1つです。CloudFront を利用する対象のウェブサイトのオリジンサーバーがAWS 上に存在する場合、オリジンサーバー側でもELB の活用や複数のアベイラビリティーゾーンの活用など可用性向上の為の様々なアプローチがありますが、CloudFront を利用することで更に高い可用性をウェブサイトにもたらすことが出来ます。

ウェブサイトの可用性を向上することは、ウェブサイトの応答速度の向上と同様にウェブサイトを運営する上で非常に重要な要素です。ウェブサイトの停止は、E コマースサイトでは売り上げに直接影響を及ぼしますし、コーポレートサイトや製品を扱うウェブサイトではブランドイメージや製品そのもののイメージ低下につながりかねません。

ウェブサイトの可用性に影響を及ぼす原因は様々なものがあります。例えば予期せぬハードウェア故障やネットワークの障害が原因となり、ウェブサイトが停止するリスクがあります。全てのコンポーネントを完全に冗長化することでリスクを軽減することが出来ますが、一般的なオンプレミス環境では冗長化の箇所が増える度にコストが大幅に増加する可能性があります。またウェブサイトオーナーは様々なキャンペーンなどの施策により、ウェブサイトのアクセス数の向上を目指しますが、予測を上回るアクセス増により、ウェブサーバーやネットワークが高負荷状態となりウェブサイトが停止するリスクがあります。

さらに外部からのDDoS 攻撃が原因となり、ウェブサイトの可用性に影響を及ぼすリスクがあります。攻撃者は複数のリソース (マルウェアに感染したコンピュータ、ルーター、IoT デバイスなどのエンドポイントで構成される分散グループ) を利用して、ターゲットのウェブサイトへの攻撃を実行します。攻撃者は侵害されたホストで構成されたネットワーク等を利用することにより、大量のパケットやリクエストを生成してターゲットのウェブサイトに過剰な負荷をかけます。たとえ正規のユーザーを想定したサイジングがきちんと出来ていても、悪意のあるトラフィックによる影響で、サーバーやネットワークのキャパシティが埋め尽くされ、ウェブサイトが停止してしまうリスクがあります。

今回はこのような予期せぬ障害やDDoS 攻撃による影響を回避し、ウェブサイトの可用性向上に役立つCloudFront の機能をまとめてご紹介致します。

オリジンフェイルオーバー

Amazon CloudFront はオリジンサーバーのフェイルオーバー機能を備えています。これは、プライマリのオリジンサーバーに障害が発生した場合に、事前に登録したセカンダリのオリジンサーバーにフェイルオーバーする機能です。フェイルオーバー機能を利用するには、オリジングループを作成し、CloudFront のプライマリオリジンが特定の HTTP ステータスコードのエラーレスポンスを返したときに自動的に切り替える先のセカンダリのオリジンを指定します。オリジングループの 2 つのオリジンは、Amazon S3 バケットまたは Amazon EC2 インスタンスなどの AWS オリジン、または独自の HTTP ウェブサーバーなどのカスタムオリジンから選択可能です。プライマリオリジンが予め設定された特定のエラーのステータスコードを返したとき、またはプライマリオリジンへの接続に失敗したりプライマリオリジンからの応答がタイムアウトした場合に、GET、HEAD、および OPTIONS HTTP メソッドでセカンダリオリジンにフェイルオーバーします。設定の詳細については、開発者ガイドを参照ください。

オリジンフェイルオーバーがトリガーされるタイムアウトに関わる設定には以下があります（2020年6月のアップデートにより、以前よりも細かい設定ができるようになりました）。

Origin Connection Attempts: オリジンへの接続を試行する回数（1-3回の範囲で変更可能）
Origin Connection Timeout: オリジンへの接続確立時に待機する時間（1-10秒の範囲で変更可能）
Origin Response Timeout: オリジンからの応答を待機する時間（1-60秒の範囲で変更可能）

データベースへのクエリなど時間のかかる処理がある場合はタイムアウトを長めに設定したり、動画配信などですぐにフェイルオーバーさせたい場合は、接続を試行する回数を減らしてタイムアウトを短く設定するなど、アプリケーションやオリジンサーバーの特性によって適切な値に調整することができます。設定の詳細については、開発者ガイドを参照ください。

Route 53 を利用したオリジンフェイルオーバー

オリジンサーバーでエラーが発生している間に CloudFront からの接続の再試行またはタイムアウトをトリガーとせずにセカンダリオリジンにステートフルに接続を継続したい場合、または、３つ以上のオリジンサーバーを重み付け等によって使用する場合、CloudFront とオリジンサーバー間で Route 53 を使用してフェイルオーバーを実行する方法があります。その場合は、Route 53 のヘルスチェック機能を使用してオリジンサーバのエンドポイントをモニタリング先として登録し、対象のオリジンサーバーの DNS レコードの TTL を短めに設定します。すべてのオリジンサーバーは、同じホストヘッダーで応答するように設定する必要があることに注意してください。

カスタムエラーページの表示

Amazon CloudFront はオリジンサーバーが何らかの原因で応答できない場合、Custom Error Response という機能を利用し、S3 上の代替コンテンツをユーザーへ応答することが可能です。もしエラーページが空白の背景でエラーメッセージだけが表示される場合、ユーザーによってはウェブサイトに対する不安を感じてしまうかもしれません。しかし、予めウェブサイトのデザインにあったカスタムエラーページを用意し、個別のHTTP エラーのステータスコード毎にCloudFront のCustom Error Response を設定しておくことで、そのリスクを軽減することが可能です。Custom Error Response は、オリジンサーバーのエラーのトリガーとなるHTTP ステータスコード毎にS3 に格納された異なる内容のカスタムエラーページを指定することができます。例えば、404 Not Found であれば、指定したコンテンツは見つからないか既に削除されている旨のメッセージを表示し、5xx 系のエラーコードの場合は、サーバーの混雑や一時的な問題である旨を表示することができます。あるいはすべてのステータスコードに同じカスタムエラーページを使用したり、一部のステータスコードだけにカスタムエラーページのコンテンツを指定して、それ以外には指定しないような設定も可能です。

Custom Error Response の設定の詳細については、開発者ガイドを参照ください。

オリジンフェイルオーバーとカスタムエラーページは、エラーのステータスコード毎に使い分けることも可能です。また、オリジンフェイルオーバーとカスタムエラーページのいずれも設定されていないケースにおいて、オリジンが 5xx のエラーコードを返した場合、もしキャッシュにリクエストされたコンテンツが存在する場合は、CloudFront はキャッシュの有効期限が切れていてもキャッシュに存在するコンテンツを応答することが出来ます。その応答はError Caching Minimum TTL（エラーステータスコードの応答のキャッシュ時間）で指定された時間（デフォルト60秒）継続します。Error Caching Minimum TTL はエラーのステータスコード毎に任意の時間を指定することが可能です。出来るだけエラーのステータスコードの応答のキャッシュ時間を短くしたい場合は、Error Caching Minimum TTL に小さい値を設定してください。その場合エラーステータスを引き起こすオリジンサーバーへのリクエストは増加することになりますので、アプリケーションやオリジンサーバーのリソースに合わせて適切な値に調整してください。こちらの動作の詳細については、開発者ガイドを参照ください。

フラッシュクラウドからのオリジンサーバーの保護

Amazon CloudFront は同一コンテンツに対するフラッシュクラウド（急激なリクエストの増加）に対して、最初のリクエストのみオリジンサーバーへ送り、後続のリクエストはそのレスポンスを活用することにより、同じ大量のリクエストをオリジンサーバーへ送信しないようにする負荷低減の仕組みを備えています。これにより、新しい製品やサービスのリリース時にフラッシュクラウドが発生した場合でも、オリジンサーバーが高負荷状態になり停止するリスクを低減することが出来ます。こちらの動作の詳細については、開発者ガイドを参照ください。

DDoS 攻撃からの保護

Amazon CloudFront はAWS Shield によるDDoS 保護機能が有効化されており、ネットワーク層およびトランスポート層のDDoS 攻撃に対する緩和が自動的に行われます。すべてのAWS 利用者は追加料金なしで、AWS Shield Standard の自動保護機能を活用できます。また、AWS WAF を併用することで、アプリケーション層のDDoS 攻撃に対する緩和も可能です。一般的なアプリケーション層の DDoS 攻撃である HTTP GET Flood は、プロトコル上では正常な通信との見分けがつかず、ウェブサイトは大量のHTTP GET を処理しきれずに停止するリスクがあります。AWS WAF はレートベースのルールにより、このような大量のHTTP GET による攻撃を緩和することが可能です。レートベースのルールで特定のリクエスト条件やウェブサイト全体のアクセスに閾値を定義することにより、5 分間あたりの同一IP アドレスからのリクエスト数が設定された閾値を超過した場合にそのIP アドレスからのリクエストをブロックすることができます。レートベースのルールの詳細については、開発者ガイドを参照ください。また、アプリケーション層に対するDoS 攻撃手法では、TCP セッションを長時間占有することで、ウェブサーバーのリソース枯渇させることを目的とした意図的にゆっくりと読み書きするタイプのSlow 攻撃 (例: Slowloris )がありますが、CloudFront はこのような攻撃に対し、自動的に接続を閉じるよう動作します。

さらに、AWS Shield Advanced をご利用頂くと、DDoS 攻撃の状況を可視化したり、AWS DDoS Response Team (DRT) にアクセスし、支援を求めることができます。DDoS 攻撃に対する対策のベストプラクティスについては、こちらのホワイトペーパーをご参照ください。

まとめ

本記事では、ウェブサイトの可用性向上に役立つAmazon CloudFront の機能についてご紹介いたしました。CloudFront はオリジンサーバーがオンプレミスなどのAWS 環境ではない場合でも利用できますので、様々な環境でサイトフェイルオーバーやDDoS 攻撃からの保護機能により、ウェブサイトの可用性向上が実現可能となります。
今回はウェブサイトの可用性向上に焦点をあててご説明しましたが、CloudFront を利用するメリットは可用性の向上だけではなく、ウェブサイトの応答性能の改善やキャッシュによるオリジンサーバーの負荷軽減等の多数のメリットがあります。CloudFront を活用頂くことで、可用性の高い安定したパフォーマンスのウェブサイト運営の一助となれば幸いです。

このブログの著者

岡　豊 (Yutaka Oka)
Solutions Architect, Edge Services

Amazon Web Services ブログ