目次
はじめに
どうも、SRE課の甫立です。
今日はAWSのメジャーなサービスの一つでもあるRoute53についてより理解を深めていこうと思い記事を書きました。
今回はヘルスチェックについての仕組みについてと簡単な検証も書いていきます。
Route53とは
Route53はドメインの管理に関する機能を提供しているサービスです。
主な機能は以下の通りです。
- ドメイン名の登録
- ドメインのリソースへのインターネットトラフィックのルーティング
- リソースの正常性のチェック
今回は3の機能に該当するHTTP/HTTPSに関する仕組みとヘルスチェックについて触れていこうと思います。
ヘルスチェックの概要
早速本題に入りますズバリヘルスチェックの仕組みは公式では以下のように解説されてます。
Amazon Route 53 がリソースの正常性をチェックする方法
画像は公式からそのまま引っ張ってきたものです。Route53からクエリを送信して応答があれば正常、応答がなければ異常のステータスとなり、CloudWatchとAmazon SNSを通じてアラート通知先へ送信されます。
これを見れば気付く方もいるかもしれませんが、ヘルスチェックにはそれを実行するヘルスチェッカーが外部にあることがわかります。
HTTP/HTTPSであればヘルスチェッカーがサイトのページにHTTP/HTTPSのリクエストを送り、応答があれば正常、応答がなければ異常と判断していることになります。
ヘルスチェッカーが正常性を判断する仕組み
AWSはヘルスチェッカーを世界各地に配置しています。
複数のヘルスチェッカーからのヘルスチェックはユーザの設定した間隔で実施されます。複数の機器から通信を送って応答があるか確認する動作を実施してます。
このヘルスチェックを複数あるヘルスチェッカーの18%以上が設定したしきい値で成功した場合にステータス正常となり、逆に18%以下が失敗した場合にステータス異常となります。
ネットワークACLやセキュリティグループを設定する場合はヘルスチェッカーを遮断しないように注意しましょう。
というのもAWSのヘルスチェッカーをセキュリティグループで拒否する設定にしてしまうと、ユーザからは正常にWEBページが見れているのにヘルスチェックでは異常のステータスになるという事態になるからです。実際どのような場合に起こるのかは次でサービスを扱いながら見ていきましょう。
参考:Amazon Route 53 がヘルスチェックの正常性を判断する方法
動作確認
準備
事前にヘルスチェックができるようにApacheの動作するEC2インスタンスを準備していきます。
インスタンスの細かい設定に関しては指定はないですが、以下の要件はクリアしましょう。
- パブリックサブネット内に作成
- セキュリティグループのアタッチ
- Apacheインストールおよび起動
インターネットからアクセスができるようにEC2のサブネットをインターネットゲートウェイを設定およびルートテーブルを作成します。
以下のルールでセキュリティグループをアタッチします。
[![セキュリティグループ1](https://blog.denet.co.jp/wp-content/uploads/2021/02/セキュリティグループ1-2021-01-30-200435.png)](https://blog.denet.co.jp/wp-content/uploads/2021/02/セキュリティグループ1-2021-01-30-200435.png)
カスタムとなっている分は自分のIPアドレスで指定します。マイIPでも構いません
作成したEC2インスタンスにSSHして以下のコマンドを実行します。
sudo yum update
sudo yum install httpd
sudo vi /var/www/html/index.html
→「アクセス成功」と入力
sudo systemctl start httpd
ブラウザで自分のインスタンスのIPアドレスで検索をかけて確認
先ほど入力した単語が表示していたら準備は完了です。
ヘルスチェックの作成
以下のURLからRoute 53のコンソールにアクセスします。
Route 53 コンソール
自分の認証情報でアクセスしたら、「ヘルスチェック」をクリックし、「ヘルスチェックの作成」をクリック
「高度な設定」も見ていきましょう。
デフォルトではリクエスト間隔が30秒で失敗しきい値が3になっています。これは「通信をサーバに向けて30秒間隔で発信し、3回サーバから応答がなかったらステータス異常として表示する」といった意味となっています。
今回はすぐにステータスが知りたいため失敗しきい値の方を1に設定します。こうすることで通信を1回失敗しただけでステータス異常として表示されるようになります。
設定できたら、「次へ」をクリック。
次に通知を受け取るかの確認がありますが、今回は動作確認なので「受け取らない」にチェックがついたままで大丈夫ですのでそのまま作成しましょう。
すると、ステータスが表示されましたが、最初は「不明」となります。
少し待ってブラウザに更新をかければステータス異常が表示されました。
これはセキュリティグループでAWSのステータスチェッカーが遮断されているためです。
もう一回自分からWEBページを確認しても閲覧はできるのにステータスでは異常になってしまっている状態です。
うっかり海外の知らないIPアドレスだと思って遮断したり、検証で自分のIPだけをHTTPアクセスを許可していた場合はステータスが異常になって通知が飛んできたりして焦りますね。
セキュリティグループでヘルスチェックを有効にする
先ほどの遮断されているIPアドレスを確認しましたが、ヘルスチェッカーのIPアドレスにはいくつか種類があります。
ヘルスチェッカーのIPアドレスは以下のURLから確認できます。
Amazon Route 53 サーバーの IP アドレス範囲
またはAWS CLIが使えるなら以下のコマンドでも確認してみましょう。
aws route53 get-checker-ip-ranges
{
"CheckerIpRanges": [
"15.177.2.0/23",
"15.177.6.0/23",
"15.177.10.0/23",
"15.177.14.0/23",
"15.177.18.0/23",
"15.177.22.0/23",
"15.177.26.0/23",
"15.177.30.0/23",
"15.177.34.0/23",
"15.177.38.0/23",
"15.177.42.0/23",
"15.177.46.0/23",
"15.177.50.0/23",
"15.177.54.0/23",
"15.177.58.0/23",
"15.177.62.0/23",
"54.183.255.128/26",
"54.228.16.0/26",
"54.232.40.64/26",
"54.241.32.64/26",
"54.243.31.192/26",
"54.244.52.192/26",
"54.245.168.0/26",
"54.248.220.0/26",
"54.250.253.192/26",
"54.251.31.128/26",
"54.252.79.128/26",
"54.252.254.192/26",
"54.255.254.192/26",
"107.23.255.0/26",
"176.34.159.192/26",
"177.71.207.128/26"
]
}
これらは全て許可する必要はありません。なぜなら、ヘルスチェッカーの18%が正常と判断すればステータスは正常となるからです。なのでセキュリティグループに以下の様にHTTPを「15.177.0.0/16」といったようにIPアドレスをレンジで指定していきます。
ステータスの確認
ルールを追加して少し待ってブラウザに更新をかけるとテータスが正常になりました。
サーバにSSHで入ってアクセスログをチェックしてみましょう。
例えば、以下の様なログが流れるはずです。
sudo tail -f /var/log/httpd/access_log | grep "15.177."
15.177.30.56 - - [30/Jan/2021:11:38:08 +0000] "GET / HTTP/1.1" 200 19 "-" "Amazon-Route53-Health-Check-Service (ref 6468c774-db71-43f6-82fa-a89f2a2aec7e; report http://amzn.to/1vsZADi)
ここで「Amazon-Route53-Health-Check-Service」と表示されています。
これはユーザエージェントと言ってアクセスもとのユーザを示していますので、AWSのヘルスチェッカーからのアクセスが成功していることが確認できました。
クリーンアップ
ヘルスチェックは残しておくと料金が発生するので削除しましょう。
今回作成したヘルスチェックのチェックボックスにチェックを入れて「ヘルスチェックの削除」をクリックし、「確認」をクリックします。
まとめ
- ヘルスチェックを行なっているのは世界各地にあるAWSの機器。
- ヘルスチェックを有効にするにはヘルスチェッカーからの通信を有効にする必要がある。
- 特にセキュリティグループの設定を変更する場合には遮断しないように注意する。
最後に
今回まとめてみて海外からの通信は不審な通信と思ってしまいがちなので気をつけたいと思いました。
アクセスログで見る場合は不審な通信かどうかの判断はIPアドレスの他にユーザエージェントやアクセス先から見れるのでちゃんとチェックするべきですね。
この記事がサイト運用上の参考になれば幸いです。
しばらくバリバリの新人、甫立です。
クラウドベリージャム:プロフィールページ