【5分で出来る】Application Load Balancer だけで作る専用メンテナンスページ

どうも、クラウドエンジニアのオタユウです。

大変ありがたいことに、前回初投稿した記事「[IT未経験&インフラ知識0から50時間で合格するAWS認定ソリューションアーキテクト-アソシエイト-](https://qiita.com/yu40ta_engineer/items/0c23b3b47a1bee80005b)」 がたくさんの方々にいいね・ストックいただいております。

Qiitaビギナーではございますが、この勢いのまま、しばらくAWSの検証系記事をメインに書いていこうと思います。

#はじめに
さて、今回のテーマは「<strong>ALBだけでメンテナンス用ページを表示してみる</strong>」です。
Application Load Balancer（通称ALB）は、AWSが提供しているロードバランサの一種です。

ロードバランサってなんぞ？？という方は <a href="https://www.infraexpert.com/study/study24.html">ロードバランサをはじめから</a> という記事をご覧くださいませ。
上記リンクはやや分量が多いので、とにかくざっくり理解したい！という方は <a href="https://wa3.i-3-i.info/word11013.html">ロードバランサ（load balancer）｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典</a> の記事がオススメです。

現在、AWSには CLB（Classic） / ALB（Application） / NLB（Network）と3種類のロードバランサがありますが、<strong>固定レスポンスを設定できるのは ALB だけ</strong>（2019/10/13 執筆時点）なんですね。

このあたりの詳細は、下記リンクをご覧ください。
<a href="https://aws.amazon.com/jp/about-aws/whats-new/2018/07/elastic-load-balancing-announces-support-for-redirects-and-fixed-responses-for-application-load-balancer/">Elastic Load Balancing で Application Load Balancer のリダイレクトおよび固定レスポンスのサポートを発表</a>

それでは、本題に入っていきましょう。
ALBの設定自体はものすごくシンプルなので、５分ぐらいでさくっと作れちゃうと思います。

#専用メンテナンスページの一般的なニーズ

Webサイトを運用していく上でメンテナンスやサーバーの障害は不可避です。
万が一発生した時に自前の専用エラーページを返したいというニーズは少なくありません。

専用エラーページにおける一般的なニーズは以下のようなものでしょうか。

・<strong>暗号化通信</strong>も出来て
・できれば<strong>独自ドメイン</strong>で
・それでいてなるべく<strong>コストをかけず</strong>に
・<strong>手軽に</strong>メンテナンスページを用意したい！

ご安心ください。<strong>それ、AWSで出来ます。</strong>
「でもAWSでどうやるの？」とお悩みの方にお読みいただきたい記事です。

#AWSでメンテナンス専用ページを設定する方法

AWS上でメンテナンス用ページを表示するための手段はさまざまです。
代表的な構築パターンは4つぐらいでしょうか。

<ol>
  <strong><li>S3静的ウェブホスティング + Route53 フェイルオーバー</li></strong>
  <strong><li>CloudFront のカスタムエラーページ</li></strong>
  <strong><li>EC2でメンテナンスページを出す（IPアドレスによって出し分け）</li></strong>
  <strong><li>ALBのみ</li></strong>
</ol>

それぞれのメリット・デメリットを簡単ではありますが、まとめてみました。

<table>
<tbody>
<tr>
<td><strong>サービス</strong></td>
<td><strong>暗号化通信（HTTPS）</strong></td>
<td><strong>独自ドメイン</strong></td>
<td><strong>コスト</strong></td>
<td><strong>設定の手軽さ</strong></td>
</tr>
<tr>
<td><strong>S3(静的ウェブホスティング)</strong></td>
<td>☓ SSL証明書は割り当て不可（HTTPのみ）※1</td>
<td>○ 可能<br>
Route53や外部レジストラを使用</td>
<td>従量課金<br>
平均 0.50〜3USD/月 程度</td>
<td>○ CloudFrontと併用</td>
</tr>
<tr>
<td><strong>CloudFront(カスタムエラーページ)</strong></td>
<td>○ S3と併用で可能<br>
CloudFrontにACM SSL証明書を設定する</td>
<td>○ 可能<br>
Route53や外部レジストラを使用<br>
エラーコードごとにページをカスタムできる</td>
<td>従量課金</td>
<td>○ S3と併用</td>
</tr>
<tr>
<td><strong>EC2</strong></td>
<td>○ 可能<br>
EC2直でSSL証明書をインストールする</td>
<td>○ 可能<br>
Route53や外部レジストラを使用</td>
<td>従量課金</td>
<td>△ SSL証明書をサーバーにインストールする手間がある</td>
</tr>
<tr>
<td><strong>ALB</strong></td>
<td>○ 可能<br>
ALBにACM SSL証明書を設定する</td>
<td>○ 可能<br>
Route53や外部レジストラを使用</td>
<td>従量課金</td>
<td>◎ ALBのみで完結</span></td>
</tr>
</tbody>
</table>

<span style="font-weight: 400;">※1 HTTPS通信を可能にする場合、別途CloudFrontを立てた後にAmazon Certificate Managerで取得したSSL証明書を設定する必要があります。</span>
上記4つの中でも、<strong>ALBはEC2やS3すら不要になり、設定の煩雑さが少なくなった点がメリット</strong>だと言えます。

Webサイトの画像や動画等のデータ量、サイトへのトラフィック量にもよりますが
一般的な静的ウェブサイトの場合、①②の併用または④を選択されるケースが多いです。
（とにかくコストを抑えたい！というニーズだとS3のみの構成になりますが・・・）

#ALBだけでメンテナンス専用ページを設定してみる
それでは次に、どれぐらいお手軽に設定できるのか？を見ていきましょう。
ALBだけを使ってメンテナンス用ページを設定していきます。

なお、<strong>ALBは既に作成している状態からスタートします。</strong>

##■ルールの設定その１
作成したApplication Load Balancerを選択後、「リスナー」→「ルールの表示/編集」リンクをクリック

<img width="480" alt="1_ルール作成.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/26c4f209-3d6f-302a-a8eb-f4b61ab23aa5.png">

##■ルールの設定その２
「＋」ボタンまたは「＋ルールの挿入」ボタンを押す

<img width="480" alt="2_ルール作成２.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/5a4d41d0-e4d8-e3a6-72ca-35b9c9db3103.png">

##■ルールの設定その３
IF：
「条件の追加」→「パスが*」と条件指定

THEN：
「固定レスポンスを返す」を選択
レスポンスコード：デフォルト
Content Type：text/html
レスポンス本文：適当なhtml

<img width="480" alt="3_ルール作成３.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/7171f109-b657-7b0d-deb9-dc29990a93d7.png">
<img width="444" alt="4_ルール作成４.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/9291fa15-f153-9a14-fd98-76ab2bf2da7d.png">

##■表示確認
ALBのエンドポイントにアクセス
→設定したhtmlが表示されていればOK

![5_ページ表示確認.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/a728afc0-4051-12f6-e219-6a08e7ec92e9.png)

メトリクスから確認する場合は、ALBの「モニタリング」
→HTTP 503s (カウント)がカウントされていればOK

##■ルールの優先順位を適用する
リスナールールは上から順番に適用されます。
今回は「通常時は固定レスポンスの優先度を低めにし、メンテナンス時は固定レスポンスを表示させたい場合」の設定をしていきます。

赤枠の上下矢印ボタンを押す

![6_ルール優先順位適用.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/0189551d-c68a-563f-0ca1-535da67b00b9.png)

優先度を動かしたいルールを選択（今回の場合は固定レスポンス）

![6_ルール優先順位適用２.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/6aaebdd6-87b6-de81-2b6a-d75a9005fb7f.png)

優先度の変更が確認できたら、保存

![6_ルール優先順位適用３.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/b0656a80-e73f-e859-e969-149495c29588.png)

「〜正常に完了しました」とメッセージが表示されたらOK

![6_ルール優先順位適用４.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/fd024619-6544-bcae-63da-99e1952e2cf2.png)

メンテナンス時にはルールの優先度を変更して「固定レスポンス」が優先されるようにする

##■表示確認（固定レスポンスが優先度低である）
通常のロードバランシングが機能し、サイトが表示されていることを確認

![7_ページ表示確認.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347034/234fea5c-cbda-06c2-0b86-4e9740830b9a.png)

※キャプチャはターゲットグループを設定していないため、デフォルトのエラーメッセージが表示されています

設定もシンプルで、特にハマったポイントもなく、非常にお手軽な印象です。
なお、AWS CLI で実行する場合は set-rule-priorities コマンドでルールの優先順位を変更可能です。

#実運用の際の注意点
注意点は大きく2つです。

##リスナールールの優先順位を考慮する
ALBの<strong>リスナールールには、上から下の順に適用していく優先度がある</strong>ため、実運用の際は 固定レスポンス（Sorryページ）を返すルールと通常のコンテンツを返すルールの優先順位を都度変更する必要があります。

具体的には、<strong>通常運用時は固定レスポンスの優先順位を低めに設定しておき、障害発生時やメンテナンス時には固定レスポンス（Sorryページ）を返すルール の優先順位を高く設定してあげる</strong>ということですね。

##ヒューマンリスクを低減する
また、今回のデモではコンソール上から ALBリスナールールの適用優先順位を手動で変更しましたが、<strong>ALBリスナールールの登録/削除または優先度変更を予め用意したCLIコマンドで実行する</strong>ようにすれば、ヒューマンエラーのリスクを更に減らせるかと思われます。

リスナールール内にHTTPのルールだけでなく、HTTPSのルールもある場合は両方とも変更する必要がありますのでご注意ください。

以上、ご拝読ありがとうございました。
ご意見ご感想またはご指摘がございましたら、コメントくださいますようお願い申し上げます。

#参考記事
##ロードバランサ関連

<ul>
  <li><a href="https://www.infraexpert.com/study/study24.html">ロードバランサをはじめから｜ネットワークエンジニアとして</a></li>
  <li><a href="https://wa3.i-3-i.info/word11013.html">ロードバランサ（load balancer）｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典</a></li>
</ul>

##ELB(ALB)関連

<ul>
  <li><a href="https://aws.amazon.com/jp/about-aws/whats-new/2018/07/elastic-load-balancing-announces-support-for-redirects-and-fixed-responses-for-application-load-balancer/">Elastic Load Balancing で Application Load Balancer のリダイレクトおよび固定レスポンスのサポートを発表｜Amazon Web Services</a></li>
  <li><a href="https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-listeners.html#fixed-response-actions">Application Load Balancer のリスナー｜Elastic Load Balancing - Application Load Balancer</a></li>
</ul>

##他の構築パターン

###S3静的ウェブホスティング

<ul>
  <li><a href="https://qiita.com/t_okkan/items/edf531aac8cfe2ff41ab">Route53のフェイルオーバールーティングとS3の静的ウェブサイトホスティングでSorryページを作成</a>
<ul>
  <li><a href="https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/dns-failover-configuring.html">Route53のフェイルオーバールーティング</a></li>
  <li><a href="https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html">独自ドメインを使用してS3の静的ウェブサイトをセットアップする</a></li>
</ul>
</ul>

###CloudFront

<ul>
  <li><a href="https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html">CloudFrontのカスタムエラーページ</a>
<ul>
  <li><a href="https://aws.amazon.com/jp/about-aws/whats-new/2019/04/amazon-cloudfront-enhances-the-security-for-adding-alternate-domain-names-to-a-distribution/">CloudFrontにACM SSL証明書をCNAMEを使って追加する</a></li>
</ul>
</li>
</ul>