503 Service Unavailable

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

• ブラウザー、APIクライアント、または監視ツールに 503 Service Unavailable または Service Temporarily Unavailable と表示される。
• 高トラフィック時にエラーが発生し、需要が下がると解消する。
• CMSの更新またはデプロイ後、メンテナンスモードが解除されず、サイトが利用できない状態が続く。
• 必須のデータベース、キャッシュサービス、または上流APIが利用できない間、エラーが継続する。
• レート制限、WAFルール、ルーティング、または異常なロードバランサーのヘルスチェックにより、特定のURL、クライアント、リクエストパターン、バックエンドだけが503を受け取る。
• レスポンスヘッダーまたはプロキシが生成したエラーページから、リクエストがアプリケーションまで到達していない可能性が分かる。

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

1. サーバーの過負荷 — 通常の需要またはトラフィック急増により、CPU、メモリ、アクティブ接続数、Webサーバーのワーカー、PHP-FPMワーカー、またはデータベース接続が枯渇している。
2. メンテナンスモードの解除漏れ — CMSの更新またはデプロイによってメンテナンスフラグが有効になったものの、中断後に削除されていない。WordPressでは、残存した .maintenance ファイルが原因になることがあります。
3. 必須の依存サービスが利用できない — アプリケーションが、リクエストの処理に必要なデータベース、キャッシュレイヤー、または内部APIに接続できない。依存サービス自体は稼働していても、アプリケーションのホストまたはネットワークからアクセスできない場合があります。
4. 意図したレート制限またはWAFの動作 — レートリミッターまたはWebアプリケーションファイアウォールが、トラフィックがしきい値を超えた場合やセキュリティルールに一致した場合に503を返すことがあります。
5. ロードバランサーのヘルスチェック不良 — 誤ったパスを使用している、または誤ったレスポンスコードを想定しているために、正常なバックエンドインスタンスを利用不可と判定することがあります。
6. プロキシまたは上流サービスの設定問題 — リバースプロキシ、CDN、または上流サービスが、アプリケーションにリクエストが届く前に503を生成することがあります。

修正方法

1. 503を生成したレイヤーを特定する

レスポンスヘッダーを確認し、アプリケーション、Webサーバー、リバースプロキシ、CDNまたはWAF、ロードバランサーの各ログを比較します。レスポンスがアプリケーションから返されたのか、それともリクエストがアプリケーションに到達する前に生成されたのかを判定してください。これにより、ブロックしているレイヤーが別にあるのにアプリケーション設定を変更する事態を防げます。

2. 障害発生時点のリソース使用量を確認する

CPU、メモリ、アクティブ接続数、Webサーバーのワーカー、該当する場合はPHP-FPMワーカー、データベース接続数を確認します。top や htop、ホスティングのダッシュボード、インフラ監視などの読み取り専用の監視ツールを使用し、上限に達していないかを調べてください。

• いずれかのリソースが容量近くまで使用されていた場合は、インシデントを過負荷または容量不足の問題として扱います。
• リソース使用量が正常な場合は、メンテナンス状態、依存サービス、レート制限、WAFルール、ヘルスチェックを調べます。

3. 不完全なメンテナンス状態を解除する

WordPressでは、更新が完了していること、またはサイトがメンテナンスを実行してよい状態であることを確認します。そのうえでSFTP接続し、サイトのルートに .maintenance という名前のファイルがないか確認してください。更新が完了しているのにこのファイルが残っている場合は削除し、サイトを再度テストします。ファイルを削除するとサイトのメンテナンス状態が変わるため、更新またはデプロイの実行中には削除しないでください。

その他のプラットフォームやデプロイツールでは、フラグファイルや環境変数を使用することがあります。更新またはデプロイのプロセスを確認し、メンテナンスモードを有効にするものと、中断後のプロセスで解除処理が実行されたかを特定してください。

4. アプリケーションサーバーから依存サービスをテストする

データベース、RedisやMemcachedなどのキャッシュレイヤー、必須の内部サービスが稼働しており、アプリケーションサーバーから到達可能であることを確認します。接続エラー、認証失敗、タイムアウト、サービスログの記録を確認してください。

依存サービス全体としては稼働していても、ネットワークアクセス、認証情報、ルーティング、サービスレベルの障害により、特定のアプリケーションホストからは到達できない場合があります。

5. 実際の過負荷に対処する

設定を増やす前に、制限となっているリソースを特定してください。ボトルネックは、CPU、メモリ、データベース接続、Webサーバー接続、またはPHP-FPMワーカーである可能性があります。

短期的な緩和策として、高コストな処理を減らす、ホストに十分な余力があり変更が承認されている場合に限り制限を引き上げる、または適切なページにキャッシュを追加します。需要が繰り返し発生する場合は、制限を何度も引き上げるのではなく、CDNやキャッシュレイヤー、バックエンド容量の追加を検討してください。

6. レート制限、WAFルール、ロードバランサーのヘルスチェックを確認する

Nginx、Apache、CDN、その他のプロキシやセキュリティのログを確認し、意図的に503を返すルールがないか調べます。ヘルスチェックのパス、想定するステータスコード、バックエンドの登録状態を確認してください。特定のURL、クライアント、またはバックエンドだけが失敗している場合、その証拠から、サイト全体の停止ではなくトラフィック制御やルーティングが原因かどうかを判断できます。

7. 修正を検証する

失敗したリクエストを再実行し、アプリケーション、プロキシ、依存サービスのログを確認します。通常のリクエストが成功することを確認し、可能であれば同程度のトラフィック量または同じ時間帯の条件でテストしてください。一時的な症状を解消しただけでなく、発生条件そのものに対処できていることを確認します。

予防と修正確認

• 部分的な失敗の後も含め、デプロイおよび更新スクリプトがクリーンアップまたは finally ステップでメンテナンスフラグを削除するようにします。
• CPU、メモリ、アクティブ接続数、ワーカー使用量、データベース接続数を監視し、容量が枯渇する前にアラートを設定します。
• 適切なページとデータベース処理をキャッシュし、トラフィック急増によるバックエンド容量の消費を抑えます。
• ロードバランサーのヘルスチェックが正しいパスと想定するレスポンスコードを使用するようテストします。
• レート制限とWAFの変更を確認し、意図した503レスポンスとサービス障害を区別できるようにします。
• 同じ時間範囲のアプリケーション、プロキシ、依存サービス、インフラのログを利用できる状態にして、障害を相関分析できるようにします。
• 修正後は、元のエラーを引き起こした状況に近い条件でサイトを検証します。

よくある質問