ALB で Sorry ページを実装する方法と運用上の考慮点

AWS運用自動化サービス「Cloud Automator」

2月も終わりますね、技術4課の多田です。

Web サイトを運用するケースでメンテナンスやサーバーの障害が発生した時に Sorry ページを返したいという要件って一般的にあると思います。

今回、構成上 ALB と EC2 がいる状況でEC2 で障害が発生した場合に Sorry ページを返すことを検証する機会がありましたので記事にまとめていきます。

ALB の固定ページとして Sorry ページを表示させる

ALB のアップデートでロードバランサーからHTTP エラーレスポンスコードとカスタムエラーメッセージを返すことができるようになりました。

Elastic Load Balancing で Application Load Balancer のリダイレクトおよび固定レスポンスのサポートを発表

具体的には、リスナーのルールで制御を行います。ルールにHTTP エラーレスポンスコードとカスタムエラーページを設定します。

今回は、HTTPエラーレスポンスコードとして「503」を返し、カスタムエラーページとして「Sorry Page Test」と返す設定を行いました。

設定後に、ブラウザからアクセスしてみます。想定通りのページが表示されました。

運用上の考慮点

ALB のルールでは、優先度に応じて挙動が変わります。

そのため、運用する際は Sorry ページを返すルールと、通常のコンテンツを返すルールの優先順位をコントロールする必要があります。

例えば、EC2 に障害が発生し、ターゲットグループのヘルスチェックが通らない状況になった場合にSorry ページを返したい、といったケースを考えます。

ルールとしては以下の画像のようにセットします。

障害が発生した時は、Sorry ページを表示するルールを、通常のコンテンツを返すルールより優先順位を上にします。

実現方法

GUI で行う場合の手順としては、次のように行います。

まず、上部のボタンの中で「Recorder Rules」を押します。

次に、優先度を変更したいルールの横にチェックボックスがあるためチェックを入れて、優先度を下げるボタンを押します。

最後に、「Save」ボタンを押して終了です。操作としては簡単ですね。

また、AWS CLIでは、set-rule-priorities というコマンドで優先度を変更可能です。

set-rule-priorities

EC2 に障害が発生後、Sorry ページを表示するルールを優先するように変更する際のコマンド例としては以下のコマンド打ちます。

ちなみに、上記の引数であるRuleArnは GUI からですと以下のように調べることが可能です。

今回紹介したのは、HTTP のルールだけでしたが、HTTPS のルールもあればそのルールも変更する必要があります。

まとめ

Sorry ページをALB 単体で表示できるアップデートは便利だと思います。

運用にあたっては優先度を変更するオペレーションがあると思うので、手動で変更するフローかAPI 経由で自動化するフローかを検討すると思いますが本番化する前のテストして想定の挙動かは確認するのが良いでしょう。

参考

固定レスポンスアクション

AWS運用自動化サービス「Cloud Automator」