AWSで動くシステムの運用を引き継ぐと、エラーは見えているのに調査先が分からない状況に突き当たります。アプリのログに異常がないのにALBが502を返す。昨日まで動いていたバッチがAccessDeniedで止まる。RDSのCPUは低いのにレスポンスだけが遅い。エラーメッセージで検索しても、断片的な答えしか集まりません。
この記事は要約版です。症状別の確認手順、ALB・RDSの原因パターンごとの対処、監視とアラート設計の具体例は、ブログの完全版にまとめています: AWS運用・トラブル解決ガイド｜切り分けの型と監視設計
原因の仮説より先に、到達点を機械的に絞る
対応が長引くチームは、原因の仮説から入って、その仮説に合う証拠だけを探してしまいます。順番を逆にしてください。まず「リクエストがどこまで到達しているか」を絞り込みます。場所が決まれば見るログは1〜2種類に減り、原因候補も数個に収束します。
対応づけは単純です。接続自体が確立しないならDNS、セキュリティグループ、ネットワークACL、ルートテーブルを疑い、VPCフローログのREJECTを探します。接続はできてエラーが返るならALBアクセスログとアプリログ。権限で落ちているならCloudTrailのerrorCodeです。突き合わせのために、ALBが付与するX-Amzn-Trace-Idをアプリのアクセスログにも出力しておくと、ALBの1行とアプリのログ行を一意に紐づけられます。
ALBの502、503、504は原因が別です。502はターゲットに接続できたがレスポンスが不正か途中で切れた状態で、調査範囲はALBとターゲットの間。503は正常なターゲットが1つもない状態。504はターゲットがアイドルタイムアウト以内に応答しなかったケースです。502ではtarget_status_codeが数値か-かで分岐し、-ならALB〜ターゲット間の問題になります。
よく外す判断が2つあります。CPU使用率が低いから性能問題ではないという推定は、I/O待ちやロック待ちの場合に成り立ちません。待ちを見るにはPerformance InsightsのDBLoad内訳が必要です。もう一つは「昨日まで動いていたから設定は変わっていない」という前提で、IAMポリシーやSCP、証明書の有効期限はリポジトリの外側で変わります。CloudTrailやConfigで確認してから仮説にしてください。
タイムアウトの大小関係も再発防止に直結します。アプリのKeep-Aliveタイムアウトを、ALBのアイドルタイムアウトより長く設定します。ALB側60秒に対してアプリ側70秒という形です。短いままだと、ALBが再利用した接続をアプリ側が先に閉じ、アプリのログには何も残らないまま502が出ます。
接続が確立しないときの3ステップ
HTTPより下のレイヤは、次の順で潰さずに確認できます。
# 1. 名前解決は通るか、返るIPは想定どおりか
dig +short api.example.com
# 2. TCPは到達するか（ポートまで指定）
nc -zv api.example.com 443
# 3. TLSハンドシェイクは成立するか、証明書は正しいか
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject
2で止まるならセキュリティグループ、ネットワークACL、ルートテーブルのいずれかです。VPCフローログにREJECTが記録されていればパケットはENIまで届いています。レコード自体が無ければ、ルーティングで到達していません。
完全版で扱っている内容
- 症状と疑うレイヤ、最初に見るログを対応づけた早見表と、ALBアクセスログ・VPCフローログ・CloudTrail・CloudWatch Logsの役割分担、時刻のズレを避けるログ突合の注意点
- ALBの502で見るログ列の順番、ヘルスチェックのシャロー／ディープの分け方、
describe-target-healthでの状態理由の確認、デプロイ時のSIGTERMと登録解除の遅延の大小関係 - RDS/Auroraの接続枯渇の流れとプール設計、
pg_stat_activityやpg_stat_statementsでの待機イベントと重いSQLの特定、PostgreSQLのVACUUMとMySQLのUNDO、ロックタイムアウトの既定値の違い、フェイルオーバー後のDNSキャッシュ対策 - AccessDeniedをCloudTrailから逆算する3つの確認項目、権限評価の通過順序、ネットワーク設定を追う固定手順、パラメータグループの
pending-rebootとタイムアウト値の不等式 - CloudWatchアラームのノイズ削減（M out of N、欠損データの扱い、複合アラーム）、バッチ時間帯だけ通知を止めるコマンド、メトリクスフィルタとLogs Insightsの使い分け
- 運用スキルを固める順番、検証環境で意図的に障害を再現するシナリオ、障害対応の記録に残す項目