HTTP 5xx サーバーエラー：意味、診断方法と対処法

このエラーの意味と見分け方

次のような症状が1つ以上現れることがあります。

• WebサイトまたはAPIが500〜599のHTTPステータスを返す。
• 汎用的なサーバーエラー、アプリケーションエラー、またはブランド付きのリバースプロキシ、ロードバランサー、CDNのページが表示される。
• 他のページが正常に動作している一方で、1つのルート、操作、またはAPIエンドポイントだけが失敗する。
• サービス全体が利用できなくなる、または断続的にエラーを返す。
• リクエストが遅くなった後、504または別のゲートウェイ関連の5xxレスポンスで終了する。
• レスポンスに、レスポンスを生成したレイヤーの特定に役立つリクエストID、アップストリーム識別子、またはサーバー固有のエラーヘッダーが含まれる。

可能性の高い順の主な原因

一般的なものから比較的まれなものまで、考えられる原因は次のとおりです。

1. アプリケーション例外またはリクエスト処理の失敗。 未処理のアプリケーションエラー、無効な入力経路、または不具合のあるコード変更により、500レスポンスが発生することがあります。
2. 最近のデプロイまたは設定変更。 リリース、環境変数の変更、ルーティング変更、またはサーバー設定のエラーが、特定のルートまたはサービス全体に影響することがあります。
3. バックエンドプロセスの異常。 停止、クラッシュ、過負荷、または到達不能なアプリケーションプロセスにより、プロキシが502または503を返すことがあります。
4. 依存サービスの障害。 データベースエラー、利用できない内部サービス、遅い外部サービス、または枯渇したコネクションプールが、複数の異なる5xxコードとして現れることがあります。
5. レイヤー間のタイムアウト。 アップストリームサービスが設定されたタイムアウト以内に応答しない場合、ゲートウェイは504を返すことがあります。根本原因は依存サービスの遅延である可能性があります。
6. リソース圧迫。 CPUまたはメモリの使用率が高い、ワーカーの飽和、ディスク容量の枯渇、接続数の上限などにより、サービスが利用できなくなったり、リクエストがタイムアウトしたりすることがあります。
7. メンテナンスまたは意図的な保護。 メンテナンス中、トラフィックの排出中、レート制限中、または過負荷から保護している間、サービスが503を返すことがあります。
8. レイヤー固有のステータス動作。 同じ根本的なインシデントでも、レスポンスを生成したのがアプリケーション、Webサーバー、リバースプロキシ、ロードバランサー、CDNのどれかによって、異なるコードになることがあります。

修正方法

1. 障害を正確に記録する

正確なステータスコード、影響を受けたURLまたはAPI操作、タイムゾーンを含む発生時刻、発生頻度、レスポンスボディ、関連するレスポンスヘッダーを記録します。リクエストIDやトレースIDがあれば保存してください。サイトを訪問しているだけの場合は、サーバー設定を変更せず、これらの詳細をサービス所有者に伝えてください。

2. レスポンスを生成したレイヤーを特定する

エラーページまたはJSONボディ、ヘッダー、Cookie、サーバー識別子を、既知の正常なレスポンスと比較します。フレームワーク固有のエラーボディはアプリケーションを示している可能性があります。ゲートウェイまたはCDNのブランド付きページは、オリジンがレスポンスを生成する前にリクエストが失敗したことを示す場合があります。オリジンのログに一致するリクエストがない場合は、リバースプロキシ、ロードバランサー、CDNのログを確認します。

3. 広範囲の障害と特定ルートの障害を切り分ける

許可された影響の小さいヘルスエンドポイントと、影響を受けていない既知のルートをテストします。1つのルートだけが失敗する場合は、そのアプリケーションコード、データアクセス、リクエスト固有の依存サービスを調べます。すべてのルートが失敗する場合は、プロセスの健全性、デプロイ状態、ルーティング、キャパシティ、共有依存サービスを優先して確認します。ヘルスチェックの代わりに、本番エンドポイントを繰り返し再読み込みしないでください。

4. 同じタイムスタンプのログを照合する

アプリケーション、Webサーバー、プロキシ／ロードバランサー、依存サービスのログをまとめて確認します。まずリクエストIDで検索し、次にタイムスタンプとエンドポイントで絞り込みます。スタックトレース、プロセスの再起動、接続拒否メッセージ、アップストリームのステータスコード、タイムアウトメッセージ、データベース呼び出しの失敗、拒否された接続を探します。ログを共有する前に、認証情報、トークン、機密性の高いリクエストデータをマスキングしてください。

5. 最近の変更とサービスの健全性を確認する

障害が始まる直前に行われたデプロイ、フィーチャーフラグ、設定変更、証明書またはルーティングの更新、メンテナンス、依存サービスの変更を確認します。バックエンドプロセスが稼働し、ヘルスチェックに合格していることを確認してください。最近の変更とインシデントに強い相関がある場合は、サービスで承認されたロールバック手順と承認プロセスを使用します。運用上の承認なしに、本番システムを再起動またはロールバックしないでください。

6. 依存サービスとリソース圧迫を確認する

データベースへの到達性とレイテンシ、内部サービスの健全性、外部依存サービスのレスポンス、コネクションプールの使用量、キューの深さ、CPU、メモリ、ディスク容量、利用可能なワーカー、接続数の上限を確認します。アプリケーションプロセス自体が稼働していても、単に遅い依存サービスによって504が発生することがあります。タイムアウトを無計画に延長して症状を隠すのではなく、制約または障害のあるコンポーネントを修正してください。

7. ステータスコードを使って調査対象を絞り込む

• 500 Internal Server Error: アプリケーションログ、サーバーエラー、失敗しているルート、最近のコードまたは設定変更から調査を始めます。
• 502 Bad Gateway: プロキシからアップストリームへの接続と、アップストリームのレスポンスを確認します。バックエンドが停止していないか、接続を閉じていないか、不正なデータを返していないか、誤ったルート経由で到達していないかを調べます。
• 503 Service Unavailable: メンテナンス状態、レディネスまたはヘルスチェック、過負荷制御、プロセスの稼働状況、共有依存サービスを確認します。
• 504 Gateway Timeout: どの処理に時間がかかっているかを測定します。アップストリームのレイテンシ、データベースまたは外部サービスの呼び出し、コネクションプール、各レイヤーのタイムアウト設定を確認します。
• その他の5xxステータス: 正確なステータスの定義と、それを出力したコンポーネントを確認します。すべての5xxレスポンスの原因が同じだと決めつけないでください。

8. 承認された最小限の修正を行い、安全に検証する

特定したアプリケーション、設定、依存サービス、またはキャパシティの問題を、環境の変更管理プロセスに従って修正します。その後、単純なヘルスエンドポイント、先ほど失敗した操作、代表的な依存機能を検証します。重複書き込みや追加の負荷を発生させずに、5xx率とレイテンシが通常に戻ったことを確認してください。プロセスの再起動、トラフィックの排出、タイムアウトの変更など、状態を変更する操作を伴う場合は、想定される影響を記録し、事前に承認を得てください。

予防と修正確認

• ルート、サービス、レスポンスを生成したレイヤーごとに、5xx率、レイテンシ、可用性を監視します。
• 過剰な負荷を発生させず、実際の依存要件を反映したレディネスチェックとライブネスチェックを使用します。
• プロキシ、アプリケーション、依存サービス間でリクエストIDまたはトレースIDを一貫して引き継ぎます。
• 各サービス境界に上限を設け、レビュー済みのタイムアウトと接続数の上限を設定します。遅い外部呼び出しによってすべてのワーカーが占有されないようにします。
• 広範囲の障害になる前に、リソースの飽和、プロセスのクラッシュ、データベースのレイテンシ、コネクションプールの枯渇、ディスク圧迫を検知してアラートを出します。
• 段階的なデプロイ、ヘルスチェックに基づくトラフィック切り替え、テスト済みのロールバック手順を使用します。
• 各プロキシ、アプリケーション、依存サービスが出力し得る5xxコードを文書化し、対応者が500、502、503、504を同じものとして扱わないようにします。
• 承認された環境で、依存サービスの劣化や過負荷が発生した場合の動作を定期的にテストします。

よくある質問