【AWS】外部サービスのメンテナンス画面をAWSで表示する方法

投稿 2024年8月31日

更新 2024年8月31日

専門用語の数:

【AWS】外部サービスのメンテナンス画面をAWSで表示する方法

~ 目次 ~

やりたいこと

前提

Route53のヘルスチェック作成

Route53のホストゾーン作成

Route53のホストゾーンにレコード作成

仕組み

ドメイン名ではなくIPアドレスを設定した理由

DNSキャッシュ

まとめ

やりたいこと

自宅に構築しているサーバーをAWSで監視し、ダウンしているとAWS側でメンテナンス画面を表示したい。


自宅でサーバーを立てている人だと、きっと理解してくれると思いますが、

直接自宅にアクセスが来るので、ルーター等を触る際にどうしてもアクセスできなくなってしまいます。


自宅だけだとメンテナンス画面を出すところもないので、その手前で止めてくれるようにしてみました。

前提

主にRoute53についての説明のため、下記のことは説明しません。

わかっている前提でお話しましますので、ご了承ください。

また今回の例では、このブログ「inkblogdb.com」で試しています。

ドメインは各自のドメインに置き換えて下さい。


それでは、どうぞ。

Route53のヘルスチェック作成

検索

AWSの画面上部にある検索画面に「route53」と入力します。


検索結果

入力して出てきた「Route53」をクリックします。


初期画面

左上のハンバーガーボタン(三)をクリックします。


ヘルスチェックメニュー

ヘルスチェックをクリックします。


ヘルスチェック作成

ヘルスチェックの作成をクリックします。

ヘルスチェックの作成

設定

ヘルスチェック設定

リソースはエンドポイントを選択します。

エンドポイントの指定はIPアドレスにします。

IPアドレスはHTTPSを選択し、各自のグローバルIPアドレス・443番ポート・各自で用意したヘルスチェックパスを入力します。

高度な設定

高度な設定

リクエスト間隔は各自であった方を選択します。

失敗しきい値は、どれくらいを問題とするかによって、各自調整してください。

数値が少なければより厳重になります。

タグ

タグ

必要であればタグを設定します。

コスト管理やアクセスコントロールに使用します。


最後に、ヘルスチェックの作成をクリックします。

Route53のホストゾーン作成

ホストゾーンメニュー

ホストゾーンをクリックします。


ホストゾーン作成

ホストゾーンの作成をクリックします。

ホストゾーンの作成

ホストゾーン設定

ホストゾーン設定

ドメイン名は各自のドメイン名を入力します。

タイプはパブリックホストゾーンを選択します。

タグ

タグ

必要であればタグを設定します。

コスト管理やアクセスコントロールに使用します。


最後に、ホストゾーンの作成をクリックします。

Route53のホストゾーンにレコード作成

先ほど作成したホストゾーンに、レコードを作成します。

プライマリレコードを作成

プライマリレコード作成

レコードを作成をクリックします。

レコードをクイック作成

セカンダリレコードをクイック作成

レコードタイプはAレコードを選択します。

値に各自のグローバルIPアドレスを入力します。

TTLは60と入力します。

ルーティングポリシーはフェイルオーバーを選択します。


プライマリレコードフェイルオーバー

フェイルオーバーレコードタイプは、プライマリを選択します。

レコードIDは一意になる文字列を入力します。

ヘルスチェックは先ほど作成したIDを選択します。


レコードを作成をクリックします。

セカンダリレコードを作成

セカンダリレコード作成

レコードを作成をクリックします。

レコードをクイック作成

プライマリレコードをクイック作成

レコードタイプはAレコードを選択します。

エイリアスにチェックを入れます。

トラフィックのルーティング先に、CloudFrontディストリビューションへのエイリアスを選択します。

そして各自で作成したディストリビューションを選択します。


セカンダリレコードフェイルオーバー

ルーティングポリシーはフェイルオーバーを選択します。

ヘルスチェックは先ほど作成したIDを選択します。

レコードIDは一意になる文字列を入力します。

フェイルオーバーレコードタイプは、プライマリを選択します。


レコードを作成をクリックします。

仕組み

ヘルスチェック

各リージョンにあるヘルスチェッカーが、特定の間隔で接続を試みてきます。


今回の設定でいうと、ヘルスチェッカーは全部の8つを選択しているため、8つすべてのリージョンからアクセスされます。

間隔はスタンダードの30秒間隔で、設定したURLにアクセスされます。


その際にHTTPステータスコードが、2xxか3xx以外を返した場合に、失敗とみなされます。

失敗が連続で発生すると、フェイルオーバーが発生します。


今回の設定でいうと、1回で失敗とみなすように設定しているため、1度でも2xxか3xx以外を返した時点で失敗扱いです。

フェイルオーバー

フェイルオーバーが発生するとどうなるかというと、

ホストゾーンで設定したプライマリレコードと、セカンダリレコードが切り替わります。


ヘルスチェックが成功しているときは、プライマリレコードに設定された宛先、

失敗しているときは、セカンダリレコードに設定された宛先に飛ばされます。

ドメイン名ではなくIPアドレスを設定した理由

ヘルスチェック作成時に、ドメイン名ではなくIPアドレスを設定した理由は、

シンプルにヘルスチェックが一度失敗すると成功に戻らないからです。


先ほどのフェイルオーバーの話の通り、ヘルスチェッカーのアクセスもフェイルオーバーのルール通りに飛ばされます。

ヘルスチェックが失敗になれば、S3をヘルスチェックすることになってしまいます。


S3に存在しなければ503が返り、一生失敗状態に陥ります。

(存在したところで逆に成功になってしまうので、成功と失敗の繰り返しになると思います)


そのためIPアドレスで直接ヘルスチェックしてもらうようにしています。

DNSキャッシュ

DNSにはキャッシュする機能が存在します。

非常にありがたい機能ですが、今回の場合は少し厄介です。


いくらフェイルオーバーでレコードが切り替わり、TTLを最短の60秒にしていても、

どうしてもキャッシュが強くて、うまく切り替わらないことがあります。


そのため、即効性が必要な場面ではおすすめはしません。

まとめ

AWSでヘルスチェックをして、メンテナンス画面を表示してみました。

キャッシュ問題はありつつも、ようやくメンテナンス画面を実現できました。

これで少しは安心できます…。


以上、ここまで見ていただきありがとうございます。

皆さまの快適な開発ライフに、ほんの少しでもお役に立てれば幸いです。

コメント一覧

コメントがまだありません

コメントを投稿してみる

コメント(必須※500文字以内)

お名前(必須※30文字以内)

※日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)