010-AWS SAP AWS 「理論・実践・一問道場」 CloudFrontにカスタムエラーページ

type

status

date

slug

summary

理論

AWSでのアプリケーション運用とALB (Application Load Balancer)

1. Application Load Balancer (ALB)

AWSのApplication Load Balancer(ALB)は、HTTPおよびHTTPSトラフィックを処理するためのマネージド型負荷分散サービスです。ALBは、リクエストをターゲットグループに分散させ、リクエストのルーティングを行います。ターゲットグループには、EC2インスタンス、コンテナ、IPアドレスなど、さまざまなリソースが含まれます。

502エラー (Bad Gateway): ALBがターゲット（EC2インスタンスやコンテナなど）から不正なレスポンスを受け取った場合に発生します。通常、ターゲットサーバーがリクエストを処理できない、またはエラーを返した場合に発生します。

ALBのエラーページ: ALBが502エラーを返すと、標準のエラーページ（AWSのデフォルトのエラーページ）が表示されます。これは、一般的なエラーメッセージしか提供せず、ユーザーに対して明確な解決策を示しません。

2. HTTPヘッダーの問題

ALBで502エラーが発生する原因の一つは、不正または不完全なHTTPヘッダーです。これらのヘッダーは、クライアント（ブラウザ）からサーバー（EC2インスタンスやアプリケーション）に送信される情報を含んでいます。例えば、アプリケーションの更新後にコードが変更され、不正なヘッダーを返すことが原因で502エラーが発生することがあります。

Malformed HTTP headers: HTTPヘッダーが不正な場合、ALBはターゲットからのレスポンスを処理できず、502エラーを返します。更新後に問題が発生するのは、新しいコードが不適切なヘッダーを送信することによって引き起こされます。

3. Amazon CloudFront

Amazon CloudFrontは、コンテンツ配信ネットワーク(CDN)サービスで、静的コンテンツや動的コンテンツを高速に配信するために使用されます。CloudFrontはALBの前に配置され、コンテンツをキャッシュして、ウェブサイトの応答速度を向上させることができます。

カスタムエラーページ設定: CloudFrontを使用する場合、特定のエラーページをカスタマイズすることができます。これにより、502エラーが発生した際にユーザーにカスタムメッセージを表示することが可能になります。

4. Amazon Route 53

Amazon Route 53は、AWSのDNSサービスであり、ドメイン名をIPアドレスに解決するために使用されます。また、ヘルスチェックを使用して、リソースが正常に動作しているかを監視することもできます。Route 53のヘルスチェックを利用すると、ALBのターゲットインスタンスが健康状態にない場合、トラフィックを他の健康なターゲットにリダイレクトすることができます。

5. カスタムエラーページの必要性

ALBの502エラーが発生した場合、標準のエラーページでは、ユーザーに何が起きているのかを詳しく説明できません。これに対して、カスタムエラーページを作成することにより、エラーが発生した理由や、次に取るべき行動（例えば、サポートへの連絡、サイトの再読み込み）を案内することができます。これにより、ユーザーエクスペリエンスを改善し、プロフェッショナルなブランドイメージを維持することができます。

カスタムエラーページの利点: ユーザーに対して適切なメッセージを提供し、エラー時にウェブサイトの他の部分へ誘導することができます。例えば、他の製品ページやサポートページへのリンクを表示することができます。

まとめ

ALBはAWS環境でのトラフィックの負荷分散に不可欠なサービスであり、502エラーが発生する場合、通常はターゲットインスタンスからの不正なレスポンスやアプリケーションの問題が原因です。このエラーに対してカスタムエラーページを設定することは、ユーザーに対してより良い体験を提供し、プロフェッショナルな印象を与えるために非常に重要です。また、Amazon CloudFrontやRoute 53といったAWSの他のサービスと連携することで、エラー時の応答を効率的に管理し、ユーザーへの影響を最小限に抑えることができます。

実践

このハンズオンでは、ALB（Application Load Balancer）、Amazon S3、CloudFront、Route 53などのAWSサービスを使用して、カスタムエラーページを設定する手順を学びます。

目的:

このハンズオンでは、502エラーが発生した場合に、ALBの標準エラーページの代わりにカスタムエラーページを表示する方法を学びます。具体的には、以下のステップを実行します：

ALBとEC2インスタンスのセットアップ

カスタムエラーページの作成とS3へのアップロード

CloudFrontを使用したカスタムエラーページの配信

ALBのエラー応答設定

今回の構成

以下、構成図になります。今回は、サーバーが停止した場合を想定し、その際のステータスコード504が発生した際に、AmazonS3から504エラー用のエラーページを返すよう設定します。

ステップ 1: ALBとEC2インスタンスのセットアップ

1.1 EC2インスタンスの作成

AWS Management ConsoleからEC2インスタンスを起動します。

必要なAMI（Amazon Linux 2023）を選択します。

セキュリティグループの設定で、HTTP（80）ポートを開放します。

ユーザーデータを追加

1.2 ALB（Application Load Balancer）の作成

EC2インスタンスの前にALBを配置します。

ALBのリスナーとしてHTTPを設定します。

ターゲットグループを作成し、EC2インスタンスをターゲットとして追加します。

1.3 ALBの動作確認

ALBのDNS名を使用して、EC2インスタンスが正常に表示されるかを確認します。

ステップ 2: カスタムエラーページの作成とS3へのアップロード

2.1 カスタムエラーページの作成

任意のエディタを使用して、502エラー時に表示するカスタムエラーページ（HTMLファイル）を作成します。

エラーページには、エラーの説明と、再試行の指示、サポートへのリンクなどを含めます。

2.2 S3バケットの作成

S3バケットを作成し、作成したカスタムエラーページをアップロードします。

バケットの公開設定を変更して、静的ウェブホスティングを有効にします。

2.3 S3のパブリックアクセス設定

アップロードしたカスタムエラーページがパブリックにアクセスできるよう、適切なアクセス許可を設定します。

ステップ 3: CloudFrontを使用したカスタムエラーページの配信

3.1 CloudFrontディストリビューションの作成

オリジンドメイン名 (Origin Domain Name) に、ALBのDNS名を指定（例: my-alb-123456789.us-west-2.elb.amazonaws.com）。

CloudFrontディストリビューションを作成

3.2 カスタマエラーPAGE設定

AmazonS3をAmazon CloudFrontのオリジンに追加

ビヘイビアとして、カスタムエラーページのリクエストがルーティングされる場所を指定します。今回設定するS3のパスパターンは/error.htmlです。

「エラーページ」タブをクリックし、「カスタムエラーレスポンスの作成」をクリックします。

「HTTPエラーコード」にカスタマイズしたいHTTPステータスコードを入力します。今回は「503」を選択します。

「エラーコードのTTL」にエラーページがキャッシュされる時間（秒）を入力します。

「カスタムエラーレスポンス」を「Yes」に設定します。

「応答ページパス」に、S3バケット内のカスタムエラーページへのパスを入力します。今回は「/error.html」とします。

「HTTPレスポンスコード」に、カスタムエラーページを返す際のHTTPステータスコードを入力します。

「作成」ボタンをクリックして設定を保存します。

ステップ 4: ALBのエラー応答設定

4.1 ALBのカスタムエラーページ設定

ALBの「エラー応答」設定を開き、「502エラー」時にCloudFrontのカスタムエラーページを表示するように設定します。

この設定を行うことで、502エラーが発生した際に、ALBが自動的にCloudFront経由でS3のカスタムエラーページを表示するようになります。

ステップ 5: 確認テスト

5.1 サーバー（EC2）を停止してみる

EC2インスタンスのアプリケーションを停止し、ALB経由でアクセスすると502エラーが発生します。

5.2 ALB-URLでアクセス、デフォルトのエラーペーが表示

5.3 CloudFrontのキャッシュを削除する

タブのキャッシュ削除で、/* を設定

5.4 CloudFront-URLでアクセス、カスタマのエラーペーが表示

カスタムエラーページが正常に表示されることを確認します。

まとめ

このハンズオンを通じて、AWSのALB、S3、CloudFront、Route 53を連携させ、502エラーが発生した場合にユーザーにカスタムエラーページを表示する方法を学びました。ALBやCloudFrontを活用することで、エラー時のユーザー体験を改善し、運用の効率化を図ることができます。

一問道場

問題

ある小売業の企業が、AWS上でECサイトアプリケーションを運営しています。アプリケーションは、アプリケーションロードバランサー（ALB）の後ろにAmazon EC2インスタンスで動作しています。企業はAmazon RDS DBインスタンスをデータベースバックエンドとして使用しています。Amazon CloudFrontは、ALBを指す1つのオリジンで構成されており、静的コンテンツがキャッシュされています。Amazon Route 53は、すべてのパブリックゾーンをホストしています。

アプリケーションの更新後、ALBは時々502ステータスコード（Bad Gateway）エラーを返します。エラーの根本原因は、ALBに返された不正なHTTPヘッダーです。ウェブページは、ソリューションアーキテクトがウェブページをリロードした後に正常に表示されます。

企業が問題に取り組んでいる間、ソリューションアーキテクトは、標準のALBエラーページの代わりにカスタムエラーページを訪問者に提供する必要があります。

運用負荷が最も少ない方法でこの要件を満たす手順を選択してください（2つ選んでください）。

選択肢

A. Amazon S3バケットを作成し、S3バケットを静的ウェブページとしてホストするように設定し、カスタムエラーページをAmazon S3にアップロードする。

B. Amazon CloudWatchアラームを作成し、ALBの健康チェックレスポンスでTarget.FailedHealthChecksが0より大きい場合、AWS Lambda関数を呼び出す。そのLambda関数でALBの転送ルールを変更し、公開Webサーバーにポイントさせる。

C. 既存のAmazon Route 53レコードを修正し、ヘルスチェックを追加して、ヘルスチェックに失敗した場合にフォールバックターゲットを設定する。DNSレコードを変更して、公開Webページにポイントさせる。

D. Amazon CloudWatchアラームを作成し、ALBの健康チェックレスポンスでElb.InternalErrorが0より大きい場合、AWS Lambda関数を呼び出す。そのLambda関数でALBの転送ルールを変更し、公開Webサーバーにポイントさせる。

E. CloudFrontのカスタムエラーページを設定し、DNSレコードを変更して公開Webページにポイントさせる。

解説

この問題では、AWS上で運用されているECサイトアプリケーションにおいて、ALB（アプリケーションロードバランサー）が時々502エラー（Bad Gateway）を返します。このエラーの原因は、ALBに送られた不正なHTTPヘッダーです。エラーが発生した際、ソリューションアーキテクトがウェブページをリロードすると問題が解決します。現在、標準のALBエラーページではなく、カスタムエラーページを訪問者に表示する方法を求められています。

要件：カスタムエラーページを提供するため、最も運用負荷が少ない方法を選択します。

選択肢の日本語での整理

Amazon S3 バケットを作成し、S3 バケットを静的ウェブページとしてホスティングする設定を行い、カスタムエラーページを S3 にアップロードする。

→ この方法では、ALBがエラーを返す際に、S3でホスティングされたカスタムエラーページが表示されるため、運用負荷は低く、簡単に設定可能です。

Amazon CloudWatch アラームを作成し、ALB 健康チェックのレスポンスで Target.FailedHealthChecks の値が 0 より大きい場合に AWS Lambda 関数を起動する。そのLambda 関数を使って、ALBの転送ルールを変更し、パブリックにアクセス可能なウェブサーバーに指示を出す。

→ Lambda を使用するため、運用が複雑になり、過剰な対応となる可能性があります。

既存の Amazon Route 53 レコードを修正し、ヘルスチェックを追加して、ヘルスチェックに失敗した場合にフォールバックターゲットを設定する。DNS レコードを変更して、パブリックにアクセス可能なウェブページにポイントさせる。

→ Route 53 を使ったフォールバック設定は、エラー処理には適していますが、ALB エラーに対する直接的な対応策としては過剰であり、最適ではありません。

Amazon CloudWatch アラームを作成し、ALB 健康チェックのレスポンスで Elb.InternalError の値が 0 より大きい場合に AWS Lambda 関数を起動する。その Lambda 関数を使って、ALB の転送ルールを変更し、パブリックにアクセス可能なウェブサーバーに指示を出す。

→ Lambda 関数を使う方法は運用負荷が高く、ALBエラーへの対応としては過剰な対策となります。

CloudFront のカスタムエラーページを設定し、エラー発生時に表示されるカスタムエラーページを設定する。DNSレコードを変更して、パブリックにアクセス可能なウェブページに指示を出す。

→ CloudFront のカスタムエラーページを設定することで、ALBがエラーを返した場合にカスタムエラーページを表示でき、運用負荷も低くなります。

最小の運用負荷で目的を達成するための手順

A: S3にカスタムエラーページをアップロードし、静的ウェブサイトとしてホスティングする。

E: CloudFront のカスタムエラーページを設定する。

これらの手順を選ぶことで、ALB のエラー発生時にカスタムエラーページを表示し、最小限の運用負荷で問題を解決できます。

💡

なぜリロードした後に正常に表示されます

ALBのターゲットインスタンスの変動: アプリケーションが更新された直後、ALBが一部のEC2インスタンスに対して502エラーを返すことがあります。このエラーは、更新に伴って一時的に発生した問題（例えば、アプリケーションの不具合や依存関係の問題など）が原因です。しかし、ALBは複数のEC2インスタンスにリクエストを分散させるため、リロード時にはエラーを返すインスタンスではなく、正常に動作している別のインスタンスにリクエストが転送され、ページが正常に表示されることがあります。

💡

なぜ標準のALBエラーページの代わりにカスタムエラーページが必要？

プロフェッショナルなブランドイメージの維持: ALBの標準エラーページはAWSのデフォルトのものです。これが表示されると、ユーザーに対して問題が発生していることが示されますが、企業のブランドやプロフェッショナリズムが欠けている印象を与えることがあります。カスタムエラーページを設定することで、企業はエラーメッセージを自社のデザインに合わせ、ユーザーに対して統一されたブランド体験を提供することができます。