429 エラーの記事一覧

冒頭まとめ docker compose の実行中に現れる 429 Too Many Requests は、ほぼ例外なく Docker Hub の pull 回数制限です。制限そのものの仕組み（匿名は IP 単位、認証済みはアカウント単位）は Compose に固有の話ではありません（Docker の 429 の記事）。 Compose に固有なのは、同じ作業でも要求の回数と同時実行数が増えやすいという点です。増幅の要因は3つあります。 1つ目は並列度です。公式のリファレンスによれば、--parallel の既定値は -1、つまり無制限です。15 サービスの構成なら、15 件の取得要求がほぼ同時に飛びます。 2つ目はタグです。公式文書には、既定の missing という方針であっても latest タグだけは常に取得される、と明記されています。実装を読むと、手元にイメージがあるかを判定する関数が、タグが latest のときは「無い」と扱う作りになっています。image: nginx のようにタグを省略した記述は latest を指すため、up のたびにレジストリへ問い合わせが行きます。 3つ目は取得方針です。pull_policy: always や docker compose up --pull always を使っていると、手元にあっても毎回取得します。 さらに、Compose の取得処理には再試行の仕組みがありません。制限に当たれば、その場で失敗します。 したがって対処の順序は、上限を増やすことではなく、この3つの増幅要因を減らすことから始まります。 エラーの概要 docker compose pull や docker compose up の実行中に、次の形で現れます。 [+] Pulling 3/5 ✔ redis Pulled ✘ web Error toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: ... ✘ api Error toomanyrequests: You have reached your pull rate limit. Error response from daemon: toomanyrequests: You have reached your pull rate limit. 注目すべきは、複数のサービスが同時に失敗する点です。単発の docker pull なら1件で終わるところが、並列に走っているため、残り枠を一気に使い切ってまとめて弾かれます。 ...

冒頭まとめ Kubernetes の 429 Too Many Requests には、出どころの違う3つの系統があります。 1つ目は、API サーバーの過負荷保護です。優先度と公平性の仕組み（API Priority and Fairness）が、混雑時に要求を落とします。2つ目は、Pod の退避が PodDisruptionBudget に阻まれた場合です。これは過負荷とは無関係で、「今は許可できない」という意味の拒否です。3つ目は、API サーバー以外、たとえばイメージの取得元が返す制限です。 さらに厄介なのが、429 に見えて 429 ではないものです。ログに「client-side throttling, not priority and fairness」と出ている場合、要求はサーバーにまだ送られていません。クライアント側が自分で待っているだけです。この文言は、ソフトウェア側の実装で「優先度と公平性の仕組みではない」と明示的に書かれています。ここを取り違えると、サーバー側をいくら調べても何も出てきません。 したがって、429 に当たったら最初にやるのは原因の推測ではなく、どこが返したのかの確定です。応答の区分、details の内容、Retry-After の値、この3つで系統が決まります。 エラーの概要 過負荷保護による 429 は、素っ気ない応答です。優先度と公平性の仕組みが要求を落とすとき、実装は Retry-After ヘッダーを付けたうえで、本文に短い文言だけを返します。 HTTP/1.1 429 Too Many Requests Retry-After: 3 Too many requests, please try again later. 一方、退避が拒否された場合の応答は、構造化された情報を持ちます。 { "kind": "Status", "status": "Failure", "message": "Cannot evict pod as it would violate the pod's disruption budget.", "reason": "TooManyRequests", "details": { "causes": [ { "reason": "DisruptionBudget", "message": "The disruption budget web-pdb needs 7 healthy pods and has 6 currently" } ] }, "code": 429 } 同じ 429 でも、details.causes の有無で系統が分かれます。DisruptionBudget が入っていれば退避の拒否であり、混雑とは関係ありません。 ...

冒頭まとめ Nginx で 429 Too Many Requests に出会ったとき、最初に押さえるべき事実があります。Nginx はレート制限の拒否に、既定で 429 を使いません。 公式文書を見ると、頻度を制限する仕組みの応答コードは limit_req_status で指定し、その既定値は 503 です。同時接続数を制限する仕組みも同様で、limit_conn_status の既定値はやはり 503 です。実装を読んでも、どちらも既定値として「サービス利用不可」を表す定数が設定されています。 つまり、Nginx が返した 429 には次のいずれかの理由があります。誰かが limit_req_status 429 または limit_conn_status 429 を明示的に設定した。上流のアプリケーションが返した 429 を、Nginx がそのまま中継している。あるいは、Nginx より前段の仕組みが返している。 逆方向の混乱もよく起きます。「429 を返すよう設定したのに 503 のままだ」という状況です。これは多くの場合、頻度の制限と接続数の制限が別々の設定であることを見落としているために起こります。片方だけ 429 にしても、もう片方が発動していれば 503 が返ります。 もう1つ、実務で効く事実があります。Nginx はレート制限で拒否するとき、待つべき時間を示すヘッダーを付けません。実装を確認しても、頻度と接続数のどちらの仕組みにも該当する記述はありません。429 に設定したとしても、クライアントは「いつ再試行してよいか」を知る手段がないままです。 エラーの概要 まず、既定の設定でレート制限に当たった場合の記録です。応答は 503 ですが、記録の文言は制限によるものだと分かる形になっています。 2026/08/03 12:00:00 [error] 1234#1234: *56 limiting requests, excess: 0.622 by zone "one", client: 203.0.113.10, server: example.com, request: "GET /search/ HTTP/1.1" limiting requests が頻度の制限、limiting connections が接続数の制限です。どのゾーンで拒否されたかも同じ行に出ます。この文言は応答コードを 429 に変えても変わりません。記録の文言と応答コードは独立している、と押さえてください。 ...

冒頭まとめ OpenAI API の 429 Too Many Requests は、1つの意味を持つエラーではありません。性質のまったく違う2種類が、同じ状態コードで返ります。 1つ目はレート制限の超過です。応答の type は rate_limit_exceeded で、こちらは待てば通ります。 2つ目はクォータの不足です。type は insufficient_quota、文言は現在のクォータを超過したので契約と請求の設定を確認せよ、という趣旨になります。こちらは待っても永久に直りません。原因が送信の速さではなく、残高や請求の状態にあるためです。 公式文書はこの区別を明示しています。Retry-After ヘッダーは一時的なレート制限による 429 に付くことがあるが、クォータや請求など利用者側の対応が必要なエラーが再試行で解決することを意味しない、と書かれています。再試行の節にも、そうしたエラーは再試行するなと明記されています。 やっかいなのは、この2つをプログラムが区別しない点です。公式のソフトウェア開発キットは、429 を含む一部のエラーを既定で2回自動的に再試行します。つまりクォータ不足でも黙って3回投げられ、遅くなるだけで結果は変わりません。 したがって最初にやることは決まっています。応答の type を読むことです。 エラーの概要 レート制限の超過はこの形です。 { "error": { "message": "Rate limit reached for gpt-4o-mini in organization org-xxx on tokens per min (TPM): Limit 200000, Used 199200, Requested 1200.", "type": "rate_limit_exceeded", "param": null, "code": "rate_limit_exceeded" } } クォータ不足は、同じ 429 でも中身が違います。 { "error": { "message": "You exceeded your current quota, please check your plan and billing details.", "type": "insufficient_quota", "param": null, "code": "insufficient_quota" } } 判定は type の1語で終わります。文言の「quota」という単語に引きずられないでください。レート制限側の文言にも上限の話は出てきます。 ...

エラーの概要 GitLabの429エラー（Too Many Requests）は、GitLab APIのレート制限に達したことを示します。ユーザーまたはCI/CDパイプラインが短時間に許可された上限を超えるAPIリクエストを送信した場合に発生します。デフォルトのレート制限はエンドポイントやインスタンスの構成によって異なり、一般的には認証ユーザーは1分間に600リクエスト、未認証の場合は300リクエスト程度とされていますが、パッケージレジストリAPIなど特定のエンドポイントではより高い制限が適用される場合もあります。 実際のエラーメッセージ例 GitLab APIレスポンス： { "message": "429 Too Many Requests", "retry_after": 60, "ratelimit_limit": 600, "ratelimit_remaining": 0, "ratelimit_reset": 1699564800 } curlコマンドでのレスポンス： $ curl -H "PRIVATE-TOKEN: <your-access-token>" https://gitlab.example.com/api/v4/projects HTTP/1.1 429 Too Many Requests RateLimit-Limit: 600 RateLimit-Remaining: 0 RateLimit-Reset: 1699564800 Retry-After: 60 {"message":"429 Too Many Requests"} よくある原因と解決手順 原因1：短時間に多数のAPIリクエストを送出する処理 スクリプトやツールが迅速に連続したAPIコールを実行する際、GitLabのレート制限に即座に到達します。例えば、多数のプロジェクトやグループのメタデータを一括取得する場合、ループ処理で制限を超えやすくなります。 解決策：ページング機能を使用して効率的に取得する import requests import time TOKEN = "<your-access-token>" GITLAB_URL = "https://gitlab.example.com" headers = {"PRIVATE-TOKEN": TOKEN} # ページング機能を使用して効率的に取得 page = 1 while True: response = requests.get( f"{GITLAB_URL}/api/v4/projects", headers=headers, params={"page": page, "per_page": 100} ) if response.status_code == 429: reset_time = int(response.headers.get("RateLimit-Reset", 0)) current_time = int(time.time()) wait_seconds = reset_time - current_time print(f"Rate limit hit. Waiting {wait_seconds} seconds...") time.sleep(max(wait_seconds + 1, 0)) continue if response.status_code != 200: break for project in response.json(): print(f"Project: {project['name']}") if "next" not in response.links: break page += 1 原因2：CI/CDパイプラインが短時間に大量のAPIコールを実行している GitLabのCI/CDパイプラインで複数のジョブが並行実行される場合、各ジョブが独立してAPIを呼び出すと累積的にレート制限に達します。特に、依存関係の解決やアーティファクトダウンロードで多数のAPI呼び出しが発生する環境では顕著です。 ...

エラーの概要 HTTP 429 エラーは「Too Many Requests」を意味し、Terraform の実行時にクラウドプロバイダーの API レート制限に達したことを示します。AWS・Google Cloud・Azure など複数のプロバイダーが API 呼び出しの頻度を制限しており、Terraform がこの上限を超えたときに発生します。特に大規模なインフラストラクチャをコード化する際に、並列処理による過度な API 呼び出しが原因となることが多くあります。 実際のエラーメッセージ例 Terraform 実行時に以下のようなエラーが出力されます。 { "error": "error creating Security Group: RequestLimitExceeded: Request limit exceeded", "status_code": 429 } また、Terraform の標準出力では以下のように表示されることもあります。 Error: Error creating load balancer: InvalidParameterValue on main.tf line 42, in resource "aws_lb" "example": 42: resource "aws_lb" "example" { 429 Too Many Requests よくある原因と解決手順 原因 1：Terraform の並列実行数が多すぎる Terraform はデフォルトで 10 個のリソースを同時に作成する設定になっており、これが API レート制限に抵触します。特に AWS や Google Cloud のプロバイダーでは、単位時間あたりの API 呼び出し数に制限があり、デフォルトの並列度では超過しやすくなります。 修正前： terraform apply -auto-approve # デフォルトの並列度 10 で実行 修正後： ...

エラーの概要 429 Too Many Requests エラーは、Azure API がスロットリング制限に達したことを示す HTTP ステータスコードです。Azure では、各サブスクリプションと API に対して一定期間内のリクエスト数に上限を設定しており、この制限を超えたときに発生します。特に、自動化スクリプトやバッチ処理でループ内から大量のリクエストを送信する場合に頻繁に見られます。 実際のエラーメッセージ例 Azure REST API の直接呼び出しで見られる典型的なレスポンス： { "error": { "code": "SubscriptionThrottled", "message": "The subscription is throttled for the following operation: Microsoft.Compute/virtualMachines/write. Please try after 30 seconds." } } Azure SDK（Python）で発生した場合のコンソール出力： azure.core.exceptions.HttpResponseError: (429) Throttling error. Subscription has exceeded throttling limits for operation 'Microsoft.Storage/storageAccounts/write'. Retry after 60 seconds. よくある原因と解決手順 原因1：リクエストレートが上限を超えている Azure には、API ごと・操作ごと（例：仮想マシン作成、ストレージ読み書き）に一定秒あたりのリクエスト数制限があります。制限値はサブスクリプション、リージョン、リソースの種類によって異なり、ループ内で連続して API を呼び出すと瞬時に制限に達します。 Before（エラーが起きるコード）： from azure.identity import DefaultAzureCredential from azure.mgmt.compute import ComputeManagementClient credential = DefaultAzureCredential() client = ComputeManagementClient(credential, "<subscription_id>") # 50 台の VM を一気に作成しようとする for i in range(50): client.virtual_machines.begin_create_or_update( "<resource_group>", f"vm-{i}", vm_config ) After（修正後）： ...

冒頭まとめ GCP の 429 Too Many Requests は、何かの上限を使い切ったことを示します。エラー区分の定義ファイルでは、利用者ごとの割り当てかもしれないし、ファイル置き場の空き容量かもしれない、という書き方になっています。つまり「要求の回数が多すぎる」とは限りません。量や個数の上限も同じ区分に入ります。 このエラーの扱いやすさは、応答に付く details にあります。上限に関する情報が、機械が読める形で定義されています。何に対する上限か（対象）、どの指標か、上限の識別子、上限の値、上限が適用される条件、そして違反の説明です。さらに、待つべき時間を示す構造も別に定義されています。 したがって、どの上限に当たったかを推測する必要はありません。応答に書かれています。旧来の対処のように、待ち時間を適当に入れて様子を見る、という進め方は不要です。 もう1つ、見落としやすい重要な点があります。上限の出どころが、呼び出したサービスとは限りません。定義には具体例が添えられていて、ある管理サービスを呼び出したときに、その内部で別の計算資源のサービスを使い、そちらの上限に当たる場合がある、と説明されています。この場合、応答にはその依存先のサービス名が入ります。呼び出した先の上限だけを調べても見つからないのは、このためです。 エラーの概要 応答の形は次のようになります。上限に関する詳細と、待ち時間の指示が別々に入ります。 { "error": { "code": 429, "message": "Quota exceeded for quota metric 'Requests' and limit 'Requests per minute'", "status": "RESOURCE_EXHAUSTED", "details": [ { "@type": "type.googleapis.com/google.rpc.QuotaFailure", "violations": [ { "subject": "project:my-project", "description": "Quota 'CPUS' exhausted. Limit: 24 in region asia-northeast1.", "apiService": "compute.googleapis.com", "quotaMetric": "compute.googleapis.com/cpus", "quotaId": "CPUS-per-project-region", "quotaDimensions": { "region": "asia-northeast1" }, "quotaValue": "24" } ] }, { "@type": "type.googleapis.com/google.rpc.RetryInfo", "retryDelay": "30s" } ] } } 読むべき項目を順に挙げます。 ...

冒頭まとめ AWS の 429 Too Many Requests は「呼び出しすぎ」を示しますが、絞り込みを行った層によって、見えるエラーも対処も変わります。代表は3層です。第一に API Gateway で、レートとバーストの超過、または利用計画（usage plan）の割当量の超過で 429 を返します。第二に Lambda で、同時実行の枠が尽きると TooManyRequestsException（Rate exceeded）の 429 を返します。第三に、Lambda などのコードの中から呼び出している AWS の各サービス API のスロットリングで、こちらは SDK 上では 429 ではなく 400 の ThrottlingException 系として現れることもあります。 共通の第一手は、正しい再試行（ジッター付き指数バックオフ）です。ただし1つ重要な例外があります。利用計画の割当量（1日1万回など期間あたりの上限）を使い切った 429 は、待って再試行しても期間が切り替わるまで直りません。「再試行が効く429」か「割当が尽きた429」かの見極めが、最初の分岐になります。 エラーの概要 3層それぞれの典型的なエラーの形です。 API Gateway が絞り込んだ場合（レート超過、または割当超過）： { "message": "Too Many Requests" } { "message": "Limit Exceeded" } Lambda の同時実行が尽きた場合（呼び出し元に返るエラーの例。実際の報告の形式）： Rate Exceeded. (Service: AWSLambda; Status Code: 429; Error Code: TooManyRequestsException; Request ID: ...) コード内の AWS API が絞り込まれた場合（SDK のエラー。この例では HTTP は 400）： An error occurred (ThrottlingException) when calling the <操作名> operation (reached max retries: 4): Rate exceeded 3つ目のように、AWS のサービス API のスロットリングは HTTP 429 とは限らず、400 の ThrottlingException や TooManyRequestsException として記録されることがあります（SDK の内部では retryable、つまり再試行してよいエラーとして扱われます）。「429」という数字だけを探すと見落とすため、Rate exceeded・Throttling という文言で探すのが確実です。 ...

冒頭まとめ Docker の 429 Too Many Requests は、そのほとんどが Docker Hub の pull 回数制限です。公式文書に明記された現行の制限は、匿名（未認証）が6時間あたり100回、認証済みの Docker Personal が6時間あたり200回、Pro・Team・Business の有料プランはフェアユースの範囲で無制限です。ここで最も重要なのは回数の数字ではなく、数える単位です。匿名の枠は IPv4 アドレス（または IPv6 の /64 サブネット）単位で数えられるため、同じ NAT の下にいる社内の全マシン、CI の全ジョブ、Kubernetes クラスタの全ノードが1つの枠を共有します。自分はほとんど pull していないのに突然429になる場合、枠を使い切ったのは同じ IP を共有する誰かです。認証すると枠がアカウント単位に変わるため、対処の第一歩は回数を増やすことではなく、帰属を IP からアカウントに切り替えることです。 数えられ方も公式に定義されています。ローカルの確認だけで済む version check は消費に数えられず、通常のイメージの pull はマニフェスト1つで1回、マルチアーキテクチャのイメージは取得したアーキテクチャごとに1回と数えます。対処は3方向に整理できます。認証してアカウント単位の枠にする（原因1）、ミラーやキャッシュで pull の回数自体を減らす（原因2）、そして帰属や別種の制限を確認する（原因3）です。 エラーの概要 制限を超えた状態でマニフェストを要求すると、Docker Hub は 429 と次の本文を返します。この文言は公式文書に掲載されているものです。 You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limits CLI や Docker Engine のログでは toomanyrequests: を先頭に付けた形で現れます。Kubernetes 経由では、kubelet のイベント（ErrImagePull / ImagePullBackOff の理由）に同じ文言が記録されます。 ...