keepalivedのヘルスチェックって80ポート(http)で行うのがデフォだと思うんですけど、なぜL7層で行うんですか？

質問

keepalivedのヘルスチェックって80ポート(http)で行うのがデフォだと思うんですけど、なぜL7層で行うんですか？ ICMPとかでやるのではなんでだめなの？

おもしろtシャツ みかん箱 闇落ち 【ギフト プレゼント 面白いtシャツ メンズ 半袖 文字Tシャツ 漢字 雑貨 名言 パロディ おもしろ 全20色 サイズ S M L XL XXL】 価格:2180円 (2026/6/4 20:11時点) 感想(0件)

解答

良い視点です。 結論から言うと、ICMPやTCP接続だけだと「サーバが本当にサービスを提供できるか」が分からないからです。 例えばKeepalivedでWebサーバを冗長化している場合を考えます。 ICMPだけの問題 サーバAで OS起動中 NIC正常 ping応答あり でも nginx停止 Apache異常終了 アプリケーション障害 DB接続エラー だったらどうでしょう。 pingは返るので、 Keepalivedは「正常」と判断してしまいます。 しかし利用者から見るとWebサイトは死んでいます。 TCP接続だけの問題 次に80/TCPの接続確認。 TCP SYN↓SYN/ACK が返れば正常と判断できます。 しかし、 nginxプロセスだけ生きている 全リクエスト500エラー アプリケーションがハング リバースプロキシの先が死んでいる という状態でもTCP接続は成功します。 HTTPチェックなら 例えば GET /health を実行して HTTP/1.1 200 OK を確認できます。 さらに レスポンスコード レスポンス内容 応答時間 まで見られます。 つまり 「ユーザー目線でサービスが使えるか」 を確認できます。 ただしL7が常に正解ではない 実はKeepalivedでもよくあるのは、 VRRP用のヘルスチェック vrrp_script で ping curl systemctl status など好きな判定を行う方法です。 例えば pidof nginx だけ見るケースもあります。 なぜデフォルトでHTTPが多いのか Keepalived自体のデフォルトというより、 Webサーバ冗長化のサンプル構成が curl http://localhost/ になっていることが多いです。 理由は単純で、 Webサービスの生死を最も正確に確認できるから です。 実務ではどこまで見る？ レベルごとに整理すると レベル1 ICMP 確認できる： OS NIC ネットワーク レベル2 TCP接続 確認できる： プロセスがListenしている レベル3 HTTP 200 確認できる： Webサーバ稼働 レベル4 専用ヘルスチェック 例えば /health で DB接続確認 Redis確認 外部API確認 まで行う 最近の本番環境はここまでやることが多いです。 逆にL7をやりすぎる問題 注意点もあります。 例えば /health が DB Redis 外部API LDAP 全部確認 になっていると、 外部APIが一時的に遅いだけでVIP切替が発生します。 これを過剰フェイルオーバーと呼びます。 そのため、 「そのサーバを切り離すべき障害か」 を意識してヘルスチェック項目を選びます。 まとめ ICMPやTCPチェックでは、 OSが生きている ポートが開いている ことしか分かりません。 一方HTTPチェックは、 「利用者が実際にサービスを使える状態か」 を確認できます。 そのためWebサービスの冗長化では、ICMPよりもL7（HTTP）のヘルスチェックが好まれることが多いのです。

apple watch スタンド apple watch 充電器 スタンド apple watch スタンド 充電 器 アップルウォッチ 充電スタンド アップルウォッチ スタンド 横置き レトロ パソコン デザイン おしゃれ かわいい シリコン 机 デスク ベッド 寝室 ナイトスタンドモード 送料無料 価格:1776円 (2025/9/26 09:28時点) 感想(6件)

にほんブログ村