Route 53の「算出されたヘルスチェック」で複数のパスをチェックしてフェイルオーバーする

2024.08.25
Route 53の「算出されたヘルスチェック」で複数のパスをチェックしてフェイルオーバーする
この記事をシェアする

こんにちは、社内でブログ執筆の波に置いて行かれているCloudbuildersのじんです。

今回は、Route 53のヘルスチェックで複数のパスに対するヘルスチェックを元に、レコードのフェイルオーバーを行ってみたいと思います。

Route 53ヘルスチェックの「算出されたヘルスチェック」

近頃Route 53のヘルスチェックのGUIが変更され、従来のコンソールは2024年9月15日に廃止されるそうです。更新されたGUIの眺めていて、対象のリソースとして選択できる「算出されたヘルスチェック」(従来コンソールの表記は「他のヘルスチェックのステータス」)が従来からあったものの、ユースケースが名前からでは少し想像しにくいので、使用例を紹介したいと思います。

想定しているケース

3つの機能(パス)から成り立っているwww.example.comというサイトがあるとします。

障害の切替先としてSorry用サイトを用意しておきますが、サービスの継続の考え方として、1つのパスの障害だけではフェイルオーバーさせたくない、とします。

2つ以上の障害が発生した場合にはフェイルオーバーさせたい、というケースを想定します。

サンプルサイト構成

サイトの例として、CloudFrontのディストリビューションで代替ドメイン名を持ち、ビヘイビアで3つのパスパターンがそれぞれ別のオリジンに設定されているようなサンプルを用意します。もちろん、ALBでもAPI Gatewayでも、オンプレのWebサイトでも構いません。

www.example.com/api1/*
www.example.com/api2/*
www.example.com/api3/*

切替先のSorryコンテンツは、S3直接でも良いですが、今回は、画面のようなAPI Gatewayを切替先として用意します。

なお、スクリーンショット上のURLは、テスト環境の都合上「www.example.com」が「www.xxxxx.click」となっていますので申し訳ありませんが読み替えてご覧ください(以下同様です)。

実現したい機能

前述の「www.example.com」(画面では「www.xxxxx.click」)をRoute 53に登録し、3つのパスそれぞれにヘルスチェックを行い、2つ以上のヘルスチェックが失敗した場合に、Route 53のレコードをフェールオーバーさせたいと思います。

その際に使用するのがRoute 53ヘルスチェックの 「算出されたヘルスチェック」となります。

パスのヘルスチェック設定

それでは具体的に設定していきましょう。

Route 53のヘルスチェックから[ヘルスチェックの作成]をクリックします。

まずは、想定しているケースに従い、3つのパスに対応したRoute 53のヘルスチェックを作成します。

名前は任意ですが今回は「HealthCheckPath1」として、下記のように設定します。
リソースは、[エンドポイント]を選択します。
エンドポイントはIPアドレスかドメイン名(URL)を指定できるので、[ドメイン名]を選択します。
ドメイン名で、httpsのURLを指定します。今回の例では、CloudFrontで使っている代替ドメイン名にポート番号(443)を加え、ビヘイビアのパスパターンで指定しているサービス(API)のパス、/healthcheck/index.htmlというヘルスチェック用のパスを加えて下記のように指定しています。
www.example.com:443/api1/healthcheck/index.html
ここで指定するパスは、ヘルスチェックに対してHTTPステータスコードが2xxまたは3xxを応答する必要があります。サービスそのもののパスか、またはヘルスチェック用に応答するパスを指定して下さい。

ちなみに従来の画面はこんな感じです。意外とエンドポイント指定部分は従来のほうが親切な画面かも知れません。

他はデフォルトとしますので、詳細が知りたい場合は、下記の公式ドキュメントを参照してみて下さい。

これが1つめのパスの設定です。

同様に名前とエンドポイントの指定を変えて、合計3つのヘルスチェックを作成します。
エンドポイントのドメイン名はそれぞれ下記を指定します。
名前:HealthCheckPath2、エンドポイントのドメイン名:www.example.com:443/api2/healthcheck/index.html
名前:HealthCheckPath3、エンドポイントのドメイン名:www.example.com:443/api3/healthcheck/index.html

マルチパスのヘルスチェック設定

ここで今回のポイントとなる、3つのパスを監視するヘルスチェックを作成します。

名前は任意ですが今回は「HealthCheckMultiPath」として、リソースは、[算出されたヘルスチェック]を選択します。

するとモニタリングするヘルスチェックを選択できるようになるので、この前の手順で作成した3つのヘルスチェックにチェックを入れます。

正常とレポート部分は、正常とするしきい値の設定となります。今回は3つのヘルスチェックが対象ですが、[すべてのヘルスチェックが正常です]とすると、3つのヘルスチェックのうち1つでも失敗すると異常と見なされるので、実現したい2つ以上のパスのヘルスチェックが失敗した場合異常とするには、[正常とみなす必要のあるヘルスチェックの最小回数]を指定して、[ヘルスしきい値]に「2」を設定します。

ちなみに従来の画面を見るとこんな感じです。こちらも従来のほうが、説明としては分かりやすかった気がするので、参考までに。

一覧で、算出されたヘルスチェックはしきい値が表示されています。ステータスは、作成直後は「不明」となっていますが、時間を置くとヘルスチェック結果の状態となります。

(参考)CloudFormationテンプレート

参考にCloudFormationで作成する場合は、下記のようになります。

最後のリソースCalculatedHealthCheckが「算出されたヘルスチェック」の部分となります。[Type: CALCULATED]を指定し、対象のヘルスチェックは[ChildHealthChecks]として指定します。

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  HealthCheck1:
    Type: AWS::Route53::HealthCheck
    Properties: 
      HealthCheckConfig:
        Type: HTTPS
        FullyQualifiedDomainName: "www.example.com"
        ResourcePath: "/api1/healthcheck/index.html"
        Port: 443
        RequestInterval: 30
        FailureThreshold: 3
      HealthCheckTags:
        - Key: Name
          Value: "HealthCheckPath1"

  HealthCheck2:
    Type: AWS::Route53::HealthCheck
    Properties: 
      HealthCheckConfig:
        Type: HTTPS
        FullyQualifiedDomainName: "www.example.com"
        ResourcePath: "/api2/healthcheck/index.html"
        Port: 443
        RequestInterval: 30
        FailureThreshold: 3
      HealthCheckTags:
        - Key: Name
          Value: "HealthCheckPath2"

  HealthCheck3:
    Type: AWS::Route53::HealthCheck
    Properties: 
      HealthCheckConfig:
        Type: HTTPS
        FullyQualifiedDomainName: "www.example.com"
        ResourcePath: "/api3/healthcheck/index.html"
        Port: 443
        RequestInterval: 30
        FailureThreshold: 3
      HealthCheckTags:
        - Key: Name
          Value: "HealthCheckPath3"

  # Calculated Health Check
  CalculatedHealthCheck:
    Type: AWS::Route53::HealthCheck
    Properties:
      HealthCheckConfig:
        Type: CALCULATED
        HealthThreshold: 2  # At least 2 of the 3 health checks must be healthy
        ChildHealthChecks: 
          - !Ref HealthCheck1
          - !Ref HealthCheck2
          - !Ref HealthCheck3
      HealthCheckTags:
        - Key: Name
          Value: "HealthCheckMultiPath"

Route 53のフェイルオーバー設定

今回はCNAMEでCloudFrontを登録します。フェイルオーバーの設定としては、ルーティングポリシーを[フェイルオーバー]と指定し、フェイルオーバーレコードタイプを[プライマリ]と指定、ヘルスチェックIDは先ほど最後に作成した[HealthCheckMultiPath]を指定します。なお、Aレコードでエイリアスを使用しても構いません。今回は後の確認を分かりやすくするために、CNAMEにしています。

フェイルオーバー先のレコードも登録します。こちらはルーティングポリシーを[フェイルオーバー]と指定し、フェイルオーバーレコードタイプを[セカンダリ]と指定します。なお、ヘルスチェックIDは指定しません。ヘルスチェックしたい場合は、上記で設定したものとは別でエンドポイントタイプのヘルスチェックを作成して指定して下さい。

2つのレコードを設定した状態です。プライマリをCloudFront、セカンダリをAPI Gatewayのアドレスにしています。後の動作確認で、どちらの値が応答されるかで、フェイルオーバーしているかを確認します。

上記でレコード登録の細かい点は省略しましたので、詳細は下記を参照して下さい。

動作確認

設定が終わりましたので、動作を確認してみます。

まずは、curlコマンドで各パスの正常応答を確認します。

次にヘルスチェックの状態を確認します。いずれも正常にとなっています。

名前解決の結果もコマンドで確認しておきましょう。返って来るのはプライマリ側のCloudFrontのアドレス(xxxx.cloudfront.net)なので、フェイルオーバーはしていない状態です。

このうちの1つのパスで疑似的に障害を発生させます。

ヘルスチェックはデフォルトで30秒間隔でしきい値3でチェックしていますので、1分半待つと、1つが異常になりますが、マルチパスチェックをしているヘルスチェックは正常のままです。

Route 53の応答もコマンドで確認しておきましょう。返って来るのはプライマリ側のCloudFrontのアドレス(xxxx.cloudfront.net)なので、フェイルオーバーはしていない状態です。

2つめパスで疑似的に障害を発生させます。

2つめのパスのヘルスチェックが異常になり、同時にマルチパスチェックをしているヘルスチェックも異常となりました。

名前解決の結果もコマンドで確認しておきましょう。返って来るのはセカンダリ側のAPI Gatewayのアドレス(xxxxx.execute-api.ap-northeast-1.amazonaws.com)なので、期待通りフェイルオーバーしています。

改めてサイトの各パスにアクセスし、応答される内容もSorryページになったことを確認します。

Route 53ヘルスチェックの一般的な注意事項

以下は「算出されたヘルスチェック」の話ではありませんが、参考に記載しておきます。

ヘルスチェックのリクエスト間隔、失敗しきい値

デフォルトのリクエスト間隔は30秒で失敗しきい値は3、となっていますので、検出に30秒x3回=1分30秒かかります。検出に許容されるタイムラグを考慮し、適宜リクエスト間隔やしきい値を修正しましょう。

ヘルスチェッカーのIPアドレス

WAFなどで送信元に制限をしている場合は、ヘルスチェッカーのIPアドレスを許可する必要があります。IP範囲としては、昨年からプレフィックスリストとしても提供されています。

ヘルスチェックの無効化、反転

フェイルオーバーのテストとしては、ヘルスチェックの無効化や反転も可能なので、Route 53のみでの動作確認や構築時の誤動作防止に利用できます。

まとめ

想定しているケースで、実現したいマルチパスのヘルスチェックを行い、Route 53のレコードを切替えることができました。

Route 53のヘルスチェックだけで実現できる機能で、コントロールプレーンを介さずにフェイルオーバーできるため、ユースケースが合えば使ってみて下さいませ!

この記事をシェアする
著者:じん
長らくインフラエンジニアをやっています。古楽、カメラ好き。2023/2024 Japan AWS All Certifications Engineers