SW BBANG J

「インスタンスは起動しているのに、ASGが勝手に終了させる」——この現象に直面したとき、最初に疑うべきはヘルスチェックの設定だ。EC2タイプのヘルスチェックはインスタンスの 存在 しか見ていない。アプリケーションがクラッシュしていても、OSが起動していれば「正常」と判断される。Auto Scaling Groupのヘルスチェック設定を正しく理解することは、不要なインスタンス終了を防ぐだけでなく、本当に異常なインスタンスを確実に置き換えるためにも不可欠だ。 TL;DR — ヘルスチェックタイプの選択基準 状況 推奨タイプ 理由 ELBを使用していない EC2 ELBタイプはロードバランサーなしでは機能しない ELBを使用、アプリ死活監視が必要 ELB アプリレイヤーの応答をヘルスチェックに反映できる ELBを使用、インスタンス起動直後に終了される ELB + ウォームアップ期間の確認 ヘルスチェックグレースピリオドの設定ミスが原因のことが多い カスタムアプリ監視が必要 EC2 + カスタムスクリプト ASGのカスタムヘルスチェックAPIで外部から不健全マークを付与 Auto Scaling Groupのヘルスチェックの仕組み ASGのヘルスチェックを理解するには、 誰が ヘルス状態を判定するのかを明確にする必要がある。ASG自身がインスタンスをポーリングするわけではない。ASGは複数のソースからヘルス情報を受け取り、それを元に終了・置換の判断を行う。 graph LR EC2SVC["EC2サービス システムステータス監視"] -->|"Impaired / Stopped"| ASG["Auto Scaling Group ヘルス判定エンジン"] TG["ターゲットグループ アプリHTTPチェック"] -->|"Unhealthy"| ASG CUSTOM["外部スクリプト SetInstanceHealth API"] --...

ALBをデプロイしてドメインを向けようとしたとき、多くのエンジニアが最初にCNAMEレコードを設定しようとする。しかし example.com のようなゾーンの頂点（Zone Apex）でCNAMEを設定しようとすると、Route 53のコンソールがそれを拒否する。これはDNS仕様の制約であり、Route 53の Aliasレコード がその解決策として設計されている。 TL;DR — AliasとCNAMEの比較 比較軸 CNAMEレコード Route 53 Aliasレコード ゾーンの頂点（example.com）での使用 ❌ 不可（RFC 1034制約） ✅ 可能 DNSクエリ料金 通常のクエリ料金が発生 Route 53リソースへのクエリは無料 TTL制御 任意に設定可能 Route 53が自動管理（設定不可） ヘルスチェック統合 制限あり ターゲットリソースのヘルスチェックと統合可能 IPアドレスの自動追従 不可（CNAMEが指すホスト名のAレコードに依存） ALBのIPが変わっても自動的に追従 対応ターゲット 任意のホスト名 ALB、CloudFront、S3、API Gatewayなど特定AWSリソース Route 53 AliasレコードとCNAMEレコードの仕組み CNAMEレコードはDNSの標準機能で、あるホスト名を別のホスト名に対応付ける。クライアントがCNAMEを解決するとき、DNSリゾルバーは最終的なAレコード（IPアドレス）に到達するまで複数回のクエリを実行する。この仕組み自体は問題ないが、RFC 1034の規定により、ゾーンの頂点（ネイキッドドメイン）にはCNAMEを設定できない。ゾーンの頂点にはSOAレコードとNSレコードが必ず存在しなければならず、CNAMEは他のレコードと共存できないためだ。 Route 53のAliasレコードはAWSが独自に実装したDNS拡張機能で、外部から見るとAレコード（またはAAAAレコード）として振る舞う。Route 53の権威DNSサーバーがAliasを解決するとき、ターゲットリソース（ALBなど）の現在...

ターゲットグループのヘルスチェックは全台 Healthy なのに、ALB が 502 を返し続ける。このパターンは本番障害の中でも特に混乱しやすい。ヘルスチェックが通っているという事実が「アプリは正常」という誤った確信を生み、実際の原因であるHTTPプロトコル違反やコネクション管理の問題を見落とさせる。 TL;DR — ALB 502 の主要原因と対処 原因カテゴリ 具体的な症状 対処の方向性 不正な HTTP レスポンス ステータス行・ヘッダーの形式違反 アプリのレスポンス形式を修正 Keep-Alive タイムアウトのミスアライン 断続的な 502、ピーク時に増加 アプリ側の idle timeout を ALB より短く設定 接続リセット (RST) ALB がレスポンス受信前に RST を受け取る アプリのクラッシュ・OOM を調査 プロトコルミスマッチ HTTPS ターゲットに HTTP で応答、またはその逆 ターゲットグループのプロトコル設定を確認 レスポンスヘッダーサイズ超過 特定リクエストのみ 502 レスポンスヘッダーを削減 ALB 502 の仕組み — なぜ Healthy でも発生するか ALB のヘルスチェックとリクエスト転送は独立したコネクションで動作する。ヘルスチェックは設定したパス（例: /health ）に対して単純な HTTP GET を発行し、期待するステータスコードが返れば Healthy と判定する。これはアプリが 生きているか を確認するだけで、任意のリクエストに対して正しい HTTP レスポンスを返せるかは検証しない。 502 は ALB がバックエンドから有効な HTTP レスポンスを受け取れなかったことを意味する。具体的には以下のいずれかが発生している。 バックエンドが接続を確立したが、整形式の HTTP レスポンスを返さなかった バックエンドがレスポンスを返す前に接続をリセット (TCP RST) した ALB がレスポンスを受信する前にバックエンドが接続を閉じた sequenceDiagram ...