プロンプトとコンテキスト
この HTTP および API の基礎に関する設問は、バックエンド、プラットフォーム、SRE、インフラストラクチャの職種に適しています。リクエスト自体は原則として有効ですが、クォータ、ファイルシステム、メモリバジェット、またはアプリケーションの制限が枯渇しているため、サーバーは結果として生じるリソース状態を保存できません。507 が適切であるケース、別のステータスの方が正確であるケース、および書き込みを重複させずに回復する方法を説明してください。
面接官が評価している点
- サーバー側の容量枯渇と、本質的に大きすぎるリクエストを区別できるか？
- 507 が WebDAV に由来し、一般的なバリデーションエラーではなく一時的なサーバーの状態であることを知っているか？
- 原因を隠蔽することなく、リトライ、バックオフ、冪等性、およびユーザー向けの対処策を定義できるか？
- アプリケーション、ストレージ、クォータ、プロキシ、キャッシュの各レイヤーにわたって制限を追跡できるか？
確認すべき質問
どの操作が失敗したか、要求された表現が有効であるか、どのリソース制限に達したか、その制限はテナント固有であるか、そして操作がすでに部分的な状態をコミットしているかを確認します。クライアントが安全にリトライできるか、サービスがクォータや容量のシグナルを公開しているかを確認してください。空き容量に関係なくペイロードがポリシーやパーサーの制限を超えている場合は 413 を使用します。より広範な処理上の理由でサービスが一時的に利用できない場合は、503 の方が適している可能性があります。フリートのどこかでディスクアラートが存在するという理由だけで 507 を選択しないでください。
30秒の回答フレームワーク
要求された操作自体は有効であるものの、利用可能なストレージまたは該当するサーバー制限が枯渇しているためにサーバーが結果のリソース状態を記録できない場合に 507 を返します。リクエストが大きすぎることを示す 413 や、より広範な一時的利用不可を表す 503 と区別します。レスポンスには、内部パスを漏洩することなく安定したエラータイプとリクエスト ID を含める必要があります。クライアントは、操作が冪等であるか冪等性キーを持つ場合にのみ、有界なバックオフを伴ってリトライします。運用担当者は枯渇した正確なディメンションを測定し、容量を解放または拡張し、完全な書き込みを検証してから復旧を宣言します。
段階的な詳細解説
- 障害を分類する。 RFC 4918 では、送信先に十分なスペースがないために実行後のリソース状態を記録できないメソッドに対して 507 を定義しています。MDN では、実装が枯渇したサーバーリソースやアプリケーション制限に対してもこれを使用することを記載しています。重要な条件は、サーバー側の容量境界によってブロックされた有効なアクションであることです。
- 近接するステータスと分離する。 現在の容量に関係なくコンテンツが大きすぎる場合は 413 を返します。状態の競合や前提条件が失敗した場合は 409 または 412 を返します。サービスが一般的にリクエストを処理できず、
Retry-Afterを提供する可能性がある場合は 503 を返します。507 レスポンスがあらゆる書き込み障害の汎用エラーになってはなりません。 - 障害に対処可能にする。 安定した問題タイプ、人間が読めるタイトル、リクエスト ID を使用し、容量の回復が見込まれる場合にのみリトライのヒントを含めます。テナントクォータには安全なクォータ識別子や修復リンクを含めることができますが、ファイルシステムパス、ホスト名、秘密のポリシー詳細は内部に留めます。
- リトライを保護する。 タイムアウトしたアップロードはコミット状態が不明な場合があります。冪等性キーまたは再開可能なアップロードトークンを要求し、操作状態を永続化し、クライアントが再実行する前にステータスを問い合わせるようにします。デッドラインを設定した指数バックオフを適用します。無制限のリトライは満杯のシステムをさらに悪化させる可能性があります。
- リソース境界を追跡する。 空きバイト数または inode 数、オブジェクトストレージのクォータ、データベース/BLOB のステージング使用量、メモリ制限、テナントの割り当て、および 507 を発行したレイヤーを記録します。アプリケーションログをストレージメトリクスおよびリクエスト ID と照合し、プロキシが生成したエラーがオリジンの決定と誤認されないようにします。
- 回復と検証。 必要に応じて新しい書き込みをドレインまたは拒否し、容量を拡張または回収して、元の冪等性キーを使用して有界な書き込みを再実行します。オブジェクトのチェックサム、メタデータ、可視性、およびクォータの計上を検証します。再発に対してアラートを設定し、満杯のテナントが別のテナントの予約枠を消費できないことをテストします。
優れた回答例
リクエスト自体は有効であるものの、ストレージまたはサーバーリソースの制限が枯渇しているためにサーバーが結果の状態を永続化できない場合にのみ 507 を使用します。常に大きすぎるペイロードには 413 を、広範なメンテナンスや過負荷状態には 503 を使用します。安定した問題タイプとリクエスト ID を返し、回復が妥当な場合にのみリトライのヒントを提供します。
HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 120
{
"type": "https://api.example.com/problems/storage-exhausted",
"title": "The resource could not be stored",
"status": 507,
"detail": "The workspace storage limit prevented this operation.",
"request_id": "req-7f2"
}クライアントは、コミット状態が不明なアップロードを無差別に再送信してはなりません。同じ冪等性キーでリトライするか、まず操作ステータスを問い合わせます。運用担当者はリクエストをクォータ、ステージング、オブジェクトストレージ、データベース、および inode のメトリクスと関連付け、容量が復元された後にチェックサム、可視性、計上を検証します。オリジンが 200 を返す一方でゲートウェイが 507 を発行した場合、ゲートウェイを発行レイヤーとして扱い、各ホップを個別にテストします。
よくある間違い
- サイズ超過のリクエストに対して 507 を返す → 容量を変更してもそのペイロードが有効になることはない → 固定のリクエストサイズポリシーには 413 を使用する。
- すべての 507 に対して即座にリトライする → 満杯のリソースの競合がさらに激しくなる → 有界なバックオフと操作のデッドラインを使用する。
- タイムアウト後にアップロードを再実行する → 元の書き込みがコミットされている可能性がある → ステータスを問い合わせるか、冪等性キーを再利用する。
- 境界を特定せずに「ディスクが満杯」と言う → クォータ、inode、ステージング、オブジェクトストレージは個別に失敗する可能性がある → 発行レイヤーと枯渇したディメンションを特定する。
- 生のパスやホスト名をクライアントに報告する → 内部トポロジやテナントデータが漏洩する可能性がある → 診断情報は保護されたログに保持し、安定した問題タイプとリクエスト ID を返す。
フォローアップの質問と回答
クライアントは HTTP 507 をリトライすべきですか？
操作を安全にリトライでき、容量の回復が見込まれる場合にのみ行います。書き込みには冪等性キーまたはステータスルックアップを使用し、指数バックオフとデッドラインを設けます。エラーがテナントのハードクォータを表している場合は、リトライするのではなく対処方法を提示してください。
507 と 503 をどのように区別しますか？
507 は、ストレージまたはサーバーの制限が枯渇しているために有効なリソース状態を記録できないことを特定します。503 は、リクエストを処理できないより広範な一時的状態であり、メンテナンスや過負荷を対象とする場合があります。HTTP レイヤーだけで推測するのではなく、測定された障害境界と一貫したサービスポリシーを使用してください。
オリジンは成功したがプロキシが 507 を返した場合はどうなりますか？
リクエスト ID をキャプチャし、オリジン直接、プロキシ経由、およびキャッシュコールドのリクエストを比較します。プロキシが発行レイヤーであり、独自のバッファやクォータを持っている可能性があります。オリジンにはすでにリソースが存在している可能性があるため、リトライする前にクライアントの最終状態を調整してください。