190-AWS SAP AWS 「理論・実践・一問道場」S3にエラーページ

type

status

date

slug

summary

理論

1. CloudFrontとオリジンフェイルオーバー

Amazon CloudFrontは、エンドユーザーにコンテンツを低レイテンシーで配信するためのCDN（コンテンツ配信ネットワーク）です。CloudFrontは複数のオリジン（ソース）を設定でき、オリジンフェイルオーバー機能を使って、プライマリのオリジンが利用できない場合に自動的にバックアップのオリジンに切り替えることができます。

オリジングループを使用すると、メインのオリジンがダウンした場合に、事前に設定されたセカンダリのオリジン（例えば、S3バケット）にリクエストをフォールバックさせ、カスタムエラーページなどを表示できます。これにより、サービスの中断を最小限に抑えることができます。

2. Application Load Balancer (ALB)と503エラー

*ALB (Application Load Balancer)**は、アプリケーション層でのトラフィック分散を行うサービスです。通常、アプリケーションが高負荷で応答できない場合やインスタンスの健康状態が悪化すると、HTTP 503 Service Unavailableエラーが発生します。

503エラーが発生した場合、ユーザーがそのページにアクセスできない状態になるため、エラーハンドリングが重要です。ユーザーに適切なエラーページを表示することで、利用者体験を改善できます。

3. Route 53とフェイルオーバールーティング

Amazon Route 53は、AWSのDNSサービスで、トラフィックのルーティングを行います。フェイルオーバールーティングポリシーを使用することで、ALBがダウンした際に他のエンドポイントにトラフィックを切り替えることができます。

ただし、Route 53によるフェイルオーバーは、設定によっては切り替えに時間がかかることがあり、即座のエラーページ表示には不向きな場合があります。

4. S3静的ウェブサイトとカスタムエラーページ

S3バケットを静的ウェブサイトホスティングとして使用することで、エラーページをホストできます。これにより、503エラー発生時にCloudFrontがS3のカスタムエラーページを返すことができます。S3は高可用性と耐障害性を備えているため、エラーページのホスティングに適しています。

まとめ：

この問題では、CloudFrontオリジングループとS3静的ウェブサイトの組み合わせが最適な解決策です。ALBの503エラーが発生した場合に、S3バケットにホストされたカスタムエラーページに迅速にフォールバックし、エラーをユーザーに即座に通知できます。

実践

略

一問道場

問題 #190

トピック

ある企業がAWSでウェブアプリケーションを実行しています。このウェブアプリケーションは、Amazon S3バケットから静的コンテンツを配信し、Amazon CloudFrontディストリビューションを通じて提供されています。動的コンテンツは、アプリケーションロードバランサー（ALB）を使用して配信され、ALBはAmazon EC2インスタンスのAuto Scalingグループにリクエストを分散します。アプリケーションはAmazon Route 53で設定されたドメイン名を使用しています。

ピーク時にユーザーがウェブサイトにアクセスしようとするときに、時折問題が発生するという報告があります。オペレーションチームは、ALBが時折HTTP 503 Service Unavailableエラーを返すことがあると確認しました。企業は、これらのエラーが発生したときにカスタムエラーページを表示したいと考えています。このページは、エラーコードが発生した際に即座に表示される必要があります。

どのソリューションが最も運用上の負担を少なくして、この要件を満たすでしょうか？

A. Route 53のフェイルオーバールーティングポリシーを設定し、ALBエンドポイントの状態を確認するためのヘルスチェックを構成し、フェイルオーバー先としてS3バケットのエンドポイントに切り替えます。

B. 2つ目のCloudFrontディストリビューションを作成し、カスタムエラーページをホストするためのS3静的ウェブサイトを設定します。Route 53でフェイルオーバールーティングポリシーを設定し、2つのディストリビューション間でアクティブ-パッシブ構成を使用します。

C. CloudFrontオリジングループを作成し、2つのオリジンを設定します。ALBエンドポイントをプライマリオリジンとして設定し、セカンダリオリジンとして静的ウェブサイトをホストするS3バケットを設定します。CloudFrontディストリビューションに対してオリジンフェイルオーバーを設定し、S3静的ウェブサイトを更新してカスタムエラーページを組み込みます。

D. CloudFront関数を作成して、ALBが返す各HTTPレスポンスコードを検証します。S3バケットにS3静的ウェブサイトを作成し、カスタムエラーページをアップロードします。関数を更新してS3バケットから読み込み、エラーページをエンドユーザーに提供します。

解説

この問題では、HTTP 503 Service Unavailableエラーが発生したときに、最小限の運用負荷でカスタムエラーページを表示する方法を選択する必要があります。

以下、選択肢ごとの解説です：

A. Route 53のフェイルオーバールーティングポリシーを設定し、ALBエンドポイントの状態を確認するためのヘルスチェックを構成し、フェイルオーバー先としてS3バケットのエンドポイントに切り替えます。

Route 53のフェイルオーバールーティングポリシーは、ALBのステータスに基づいてリクエストを切り替える方法ですが、503エラーが発生した場合に即座にエラーページを表示するという要件には直接対応していません。エラーページを即座に表示するには、フェイルオーバーの遅延を最小化する方法が必要ですが、Route 53の切り替えにはタイムラグが生じることがあります。したがって、この選択肢は不適切です。

B. 2つ目のCloudFrontディストリビューションを作成し、カスタムエラーページをホストするためのS3静的ウェブサイトを設定します。Route 53でフェイルオーバールーティングポリシーを設定し、2つのディストリビューション間でアクティブ-パッシブ構成を使用します。

これはカスタムエラーページのホスティングのための方法として有効ですが、アクティブ-パッシブ構成には複雑さと追加の管理負荷が伴います。さらに、CloudFrontを2つ設定する必要があり、管理のオーバーヘッドが増加します。このため、最小の運用負荷でエラー時に即座に対応するという要件には適していません。

C. CloudFrontオリジングループを作成し、2つのオリジンを設定します。ALBエンドポイントをプライマリオリジンとして設定し、セカンダリオリジンとして静的ウェブサイトをホストするS3バケットを設定します。CloudFrontディストリビューションに対してオリジンフェイルオーバーを設定し、S3静的ウェブサイトを更新してカスタムエラーページを組み込みます。

オリジンフェイルオーバーは、CloudFrontがALBの応答がない場合に自動的にS3バケットに切り替える方法です。これにより、ALBが503エラーを返したときに、即座にS3バケットのカスタムエラーページが表示されます。この方法は、最も簡潔で運用負荷も少なく、要件を満たします。エラーページが即座に表示され、運用の管理も比較的少なくて済みます。

D. CloudFront関数を作成して、ALBが返す各HTTPレスポンスコードを検証します。S3バケットにS3静的ウェブサイトを作成し、カスタムエラーページをアップロードします。関数を更新してS3バケットから読み込み、エラーページをエンドユーザーに提供します。

CloudFront関数を使ってレスポンスコードを検証し、エラーページを提供する方法ですが、このアプローチは他のオプションに比べて実装が複雑で、関数の管理が追加されるため、運用負荷が増えます。即座にエラーページを表示するという要件に対しても、他の方法に比べて最適ではありません。

結論：

最も運用負荷が少なく、503エラー発生時に即座にエラーページを表示するための最適解は、選択肢 C です。CloudFrontオリジングループを利用することで、ALBがダウンした際に自動的にS3バケットにフォールバックし、エラーページを即座に表示することが可能です。