この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんばんは、三井田です。
今回は、Elastic Load Balancing (ELB)とRoute 53のヘルスチェックの仕様の違いについて簡単にまとめてみたいと思います。
ELBのヘルスチェックはご存知のとおり、ロードバランサがどのバックエンドインスタンスにトラフィックをルーティングするかを判断するために用いられます。
一方、Route 53のヘルスチェックは、重み付けラウンドロビンやDNSフェールオーバーで、どのIPアドレスを回答に含めるかを判断するために用いられます。
ヘルスチェック仕様早見表
まずは、以下の表にご覧下さい。
| サービス | ELB | Route 53 | |
|---|---|---|---|
|
ヘルスチェック元 （Health Checker） |
ELB自身 |
世界16ヶ所に分散したHealth Checker （GetCheckerIpRanges APIで取得されるIPレンジと対応している模様） |
|
| アクセス方法 | ELBから見たEC2のIPアドレス（推察） | IPアドレスまたはドメイン名を選択可 | |
| インターバル | 5秒〜300秒で設定可 |
30秒（デフォルト） または 10秒（追加料金あり） |
|
| 試行回数 |
2回〜10回を指定可 （Healthy Threshold、UnHealthy Thresholdをそれぞれ指定可） |
1回〜10回 （Failure Thresholdで指定） |
|
| タイムアウト閾値 | TCP | 2秒〜60秒で設定可 | 4秒（TCP接続） |
| HTTP/HTTPS |
6秒 （内訳： TCP接続: 4秒 HTTP/HTTPS応答: 2秒） |
||
| HTTP/HTTPS (文字列チェックあり） | ※ELBでは文字列チェック機能なし |
8秒 （内訳： TCP接続: 4秒 HTTP/HTTPS応答: 2秒 応答Body受信: 2秒） |
|
|
文字列チェック （HTTP/HTTPS） |
※ELBでは文字列チェック機能なし |
HTTP応答Bodyの冒頭5KB以内にある必要あり 最大255文字を指定可 |
|
|
HTTP応答コード （HTTP/HTTPS） |
200 | 200番台または300番台 | |
| User-Agent (HTTP/HTTPS) | ELB-HealthChecker/1.0 | Amazon Route 53 Health Check Service; ref:<Health CheckのID> | |
| 正常/異常の判断基準 | タイムアウト閾値・文字列チェック・応答コードが、Healthy Threshold、UnHealthy Thresholdで指定した試行回数連続で成功または失敗した場合 | Failure Thresholdで指定した試行回数（1〜10回）の失敗が、一定数のHealth Checkerで発生した場合 | |
| 切り離しの判断までの時間 |
最短で1分 （UnHealthy Threshold 2 × 30秒インターバルの場合） |
最短で10秒＋DNSのキャッシュが失効するまでの期間 （Failure Threshold 1 × 10秒インターバルの場合） |
|
| 正常/異常の監視手段 |
CloudWatch (AWS/ELB Namespace)
|
CloudWatch (AWS/Route53 Namespace)
|
|
| 切り離し方法 | 異常と判断したインスタンスにはトラフィックを流さない |
異常と判断した対象のIPアドレスをクエリ結果として返さない 注）但し全て異常の場合はIPアドレスを返します（クエリ結果は返す仕様） |
|
参考資料：
ポイント
それぞれのヘルスチェックの違いと考慮するポイントを以下にまとめてみました。
- ELB
- 同じVPC内からチェックするので、より直接的で切り離しもThresholdに基づいて迅速に行われます
- タイムアウト値の設定に柔軟性があるので、DBと連携する動的ページをチェック対象とすることも可能かと考えます
- チェックインターバルも最小2秒から最大5分と柔軟に設定できます
- 反面、正常とみなすHTTP応答コードは200のみであり、他の200番台やリダイレクト（300番台）は異常とみなされます
- また、IPアドレスによるチェックとなるため、VirtualHost設定している場合は、デフォルトのホストにチェック対象を配置する必要があります
- Route 53
- アクセス対象をIPアドレスでもドメイン名でも指定できます
- ELBで構成されたサイトに対してもヘルスチェックが可能です（マルチリージョン構成など）。この利点はDNSフェールオーバーを設定する際に有効な手段です
- 閾値が厳しめです。世界中からのアクセスとなるため、トラフィックのTTLも考慮し、HTTP/HTTPS監視では比較的軽目のコンテンツを対象とした方が良いかもしれません
- 数ヶ所のHealth Checkerからの疎通断や閾値オーバーでは正常とみなされます（この点は追加調査が必要ですね）。インターネットの遅延や経路障害を考慮した設計と推察します
- HTTP応答コード200番台と300番台を正常とみなすので、リダイレクトされるパスをチェック対象として指定することも可能です
- ドメイン名でのチェックとした場合、特定のVirtualHostをチェック対象とすることができます
- ヘルスチェックでのインスタンス切り離しを実現するには、Failure Thresholdの回数と対象レコードのTTLのバランスを考慮する必要があります
- その他
- どちらも、CloudWatchなどでヘルスチェックの状況をモニタリングすることが可能です
- 費用：ELBのヘルスチェックは無償で付属する機能ですが、、Route 53のヘルスチェックは有償の追加機能です
まとめ
以上、簡単に両者の違いを見てきました。ELBのヘルスチェックは既に皆様フル活用しているかと思います。Route 53のヘルスチェックは、DNSレベルでの切り離しなど活用できると非常に有効な手段です。今後、もう少し深いレベルの記事にして紹介できたらと思います。
4
