share facebook facebook facebook twitter twitter menu hatena pocket slack

2021.07.29 THU

Route 53 ヘルスチェックを使った死活監視

新川 貴章

WRITTEN BY 新川 貴章

はじめに

  • Route 53 は、AWSのDNSサーバーを提供するサービスとなりますが、他にもヘルスチェック機能があります。実は、AWS Shield Advanced を構築する際に初めてヘルスチェックの存在を知り、使用してみました。AWS Shield Advanced では、保護リソースにRoute 53 ヘルスチェックを関連付けることが可能です。(AWS Shield Advanced の構築はこちらを参照。)

Route 53 ヘルスチェックとは

  • Route 53 ヘルスチェックを作成することで、エンドポイントのモニタリングができます。作成されたヘルスチェックは、エンドポイントが正常であるかどうかを判断するために、指定したエンドポイントにリクエストを送信します。
  • モニタリングの対象は3種類あり、エンドポイント、他のヘルスチェックのステータス、CloudWatch アラームの状態が選べます。モニタリングはエンドポイントの利用が一般的かと思います。

Route 53 ヘルスチェックの仕組み

  • 一般的には、ロケーションが異なる約15個のヘルスチェッカーによって、正常性が確認されます。ヘルスチェックのリクエスト間隔は、スタンダード (30 秒) or 高速(10秒)が選択できます。計算上は、リクエスト間隔が30秒の場合、2秒に1回のヘルスチェックリクエストを受け取ることになります。ただし、ヘルスチェッカーは互いに調整しないため、1秒に複数のリクエストを受け取り、数秒間はヘルスチェックを受け取らない場合もあります。
  • ヘルスチェッカーのリージョンは、カスタマイズできます。
  • 各ヘルスチェッカーは、下記の 2つの値を基に、正常性を評価します。
    • 応答時間(サーバーのメンテナンスやネットワーク障害、DDoS攻撃などで応答が遅延します)
    • エンドポイントが指定した連続する回数のヘルスチェックに応答するかどうか (失敗しきい値: デフォルトは3)
  • ヘルスチェッカーから集計したデータは、下記の基準で評価されます。これは一部のロケーションのネットワーク障害によって、誤って異常と評価されないためです。
    • 18% を超えるヘルスチェッカーがエンドポイントを正常と報告した場合、正常と評価される。
    • 18% 以下のヘルスチェッカーがエンドポイントを正常と報告した場合、異常と評価される。
  • ヘルスチェックのプロトコルは、HTTP, HTTPS, TCP の3種類あり、プロトコルによって応答時間が変わります。
    • HTTP/HTTPS: エンドポイントとの TCP 接続を 4秒以内に確立、その後 2秒以内に、HTTP ステータスコード 2xx or 3xx で応答される必要があり。
    • TCP: エンドポイントとの TCP 接続を 10 秒以内に確立される必要あり。
  • HTTPS では、証明書は検証されず、証明書が無効または期限切れでも異常にはなりません。

Route 53 ヘルスチェックの設定

ヘルスチェックを作成する

  • Route 53 のコンソールを開き、ヘルスチェックを選択します。次に、[ヘルスチェックの作成]を押します。

  • ヘルスチェックの環境設定に、名前、モニタリングの対象に「エンドポイント」を設定します。
  • エンドポイントをIPアドレス or ドメイン名にて指定し、通信のプロトコル、ポート番号、パスを指定します。以下の例では、HTTP(Port 80)を選択していますが、TCPを選択し、他のサービス(例: SSH)をモニタリングすることも可能です。

  • 必要に応じて、高度な設定を変更します。

  • ヘルスチェックが異常となった場合のSNS トピックを作成します。

  • Route 53 ヘルスチェックを作成しました。

ヘルスチェッカーのリクエストは許可されている?

  • セキュリティグループなどでエンドポイントへのリクエストを制限している場合は、ヘルスチェッカーのリクエストを許可します。以下は、ヘルスチェッカーのリクエストが制限され、ヘルスチェックに失敗している様子です。

  • ヘルスチェッカーのリクエストを許可した後、ヘルスチェックは成功しました。

ヘルスチェッカーをテストしてみる

  • 試しに、エンドポイントから404 が返るように変更しました。ヘルスチェックは異常に変わりました。

  • CloudWatchにて、ALARM が検出されました。

  • SNS トピックで設定したメール通知が行われました。

Route 53 ヘルスチェックの補足

ヘルスチェックでエンドポイントをモニタリングする際の注意事項

  • Route 53 ヘルスチェックでは、HTTPステータスコードをカスタマイズすることはできず、200 OK の応答が返る必要があります。
  • Route 53 ヘルスチェックでは、GET メソッドのリクエストのみ対応しており、POST メソッドのリクエストは送ることができません。
  • Route 53 ヘルスチェックでは、クエリパラメータを指定したり、HTTPヘッダにパラメータを指定することはできません。

ヘルスチェックでCloudWatch アラームの状態をモニタリングする

  • モニタリングの対象は、エンドポイント以外にCloudWatch アラームの状態を選択できます。
  • 例えば、ApplicationELB のメトリクスである 「AppELB 別、AZ 別、TG 別メトリクス」 の「HealthyHostCount」のメトリクスを利用して正常性を判断することも可能です。必要に応じて、CloudWatch アラームの利用も検討ください。

参考資料

リソースの正常性をチェックし、正常なリソースのみを使用して DNS クエリに応答するように Route 53 を設定します。

元記事はこちら

https://oji-cloud.net/2021/07/22/post-6437/?utm_source=rss&utm_medium=rss&utm_campaign=post-6437

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。