レート制限

概要

レート制限は、設定された時間枠内にユーザーまたは IP アドレスが行えるリクエスト数を制限することで、セキュリティとパフォーマンスを向上させる GitLab の重要な機能です。GitLab のレート制限アプローチは乱用を防ぎ、公平なリソース割り当てを確保し、システムの安定性を維持し、潜在的な攻撃から効果的に保護し、信頼性の高いユーザー体験を保証します。

レート制限されたリクエストは 429 - Too Many Requests レスポンスを返します。

プロセス

• レート制限の変更には変更リクエストが必要です。
• ユーザーのレート制限設定についてこの Issue テンプレートを使用して支援を要請してください。
• バイパスを求める内部チームはレート制限バイパスポリシーを参照してください。

GitLab レート制限アーキテクチャ

GitLab.com

flowchart TD
    A[Internet]
    A -->|gitlab.com| D(Cloudflare WAF)
    A -->|customers.gitlab.com| F
    subgraph ide3 [Cloudflare WAF]
        D[gitlab.com zone]
        F[customers.gitlab.com zone]
    end
    A -->|*.gitlab.io| K
    A -->|registry.gitlab.com| N
    D --> G
    F --> H
    G[https + ssh]
    subgraph ide2 [GitLab]
        subgraph ide1 [HAProxy]
            N[registry_https]
        end
        H[nginx]
        K[pages kubernetes limits]
        K-->M[pages application limits]
        I[Rack::Attack]
        J[Gitlab::ApplicationRateLimiter]
    end
    G --> I
    G --> J

Cloud Connector

flowchart LR
  A[Internet]
  subgraph cf [Cloudflare WAF]
      E[cloud.gitlab.com zone]
  end
  subgraph G [GitLab]
    subgraph cc_be [CloudRun / GKE]
      F[Cloud Connector backends]
    end

    subgraph GKE
      C[gitlab.com]
    end

    subgraph AWS
      D[GitLab Dedicated]
    end
  end

  E --> F
  A -->|cloud.gitlab.com| E
  C -->|cloud.gitlab.com| E
  D -->|cloud.gitlab.com| E

GitLab.com では複数のレイヤーにレート制限が存在し、上記のボックスで囲まれた各領域がレート制限が実装されている場所を表しています。

制限

重複を最小限に抑えるため、現在有効なレート制限を確認するには以下のソースを参照してください:

バイパス

公開されているレート制限はすべての顧客とユーザーに例外なく適用されます。

バイパスを求める顧客または内部チームはレート制限バイパスポリシーを参照してください。

トラフィック管理レート制限

Cloudflare

Cloudflare は、受信トラフィックのネットワークエッジに位置する「最外層」の保護として機能します。私たちは Cloudflare の標準的な DDoS（分散型サービス拒否）保護と、SSH 経由の git を保護するための Spectrum を使用しています。

Cloudflare でのレート制限の適用方法:

注: Cloudflare はアプリケーションを認識しておらず、ユーザーとグループへのマッピング方法を知りません。

Cloudflare はまた、以下からの一部のリクエストに X-GitLab-Rate-Limit-Bypass ヘッダーを適用する責任があります:

• レガシーの顧客 IP レート制限バイパス
• 統合を持つサードパーティベンダー
• 内部インフラ

ヘッダーが適用される条件の完全なリストについては、この設定を参照してください。

Cloudflare ランブックには、このインフラレイヤーの設定に関する詳細が含まれています。

Cloudflare レート制限の変更には変更リクエストが必要であり、実装前にプロダクションエンジニアリング::ネットワーキング & インシデント管理 SRE チームと議論する必要があります。

HAProxy

GitLab のトラフィック管理レート制限の大部分は HAProxy から Cloudflare に移行されています（詳細については機密 Issue を参照してください）。

ただし、HAProxy はそのコンポーネントが Cloudflare でフロントされていないため、レジストリのレート制限を引き続き担当しています。詳細については レジストリを参照してください。

現在 HAProxy は、限られた数の特殊なパスに X-GitLab-Rate-Limit-Bypass を適用することも担当しています。リストはここにあります。このロジックを Cloudflare に移行する作業が進行中です。

アプリケーションレート制限

アプリケーションがユーザー情報へのアクセスを持つため、Cloudflare で実装されたものと比較してより情報に基づいたトラフィック管理を可能にする複数のアプリケーションレート制限メカニズムが実装されています:

• Rack Attack
• Application Rate Limiter
• Plan Limits

アプリケーション制限を GitLab に貢献するにはアプリケーション制限開発を参照してください。

概要

レート制限期間は 1 分（60 秒）です。

RackAttack

GitLab は Rack リクエストをスロットリングするミドルウェアとして RackAttack を利用しています。これらは Gitlab::RackAttack と Gitlab::RackAttack::Request を拡張することで設定できます。

GitLab インスタンスのレート制限設定の詳細については、ユーザーおよび IP レート制限のドキュメントを参照してください。

GitLab.com 固有のレート制限に関する詳細情報と、ランブックでの RackAttack 設定ドキュメントを読むことができます。

ApplicationRateLimiter

GitLab アプリケーションは、Rack Attack が提供できる以上の柔軟性が必要な場合に使用される、特定のアクションをスロットリングできるシンプルなレート制限ロジックを持っており、コントローラーまたは API レベルでスロットリングできます。これらのレート制限は application_rate_limiter.rb で設定されています。スコープは個々の制限実装次第で、任意の ActiveRecord オブジェクトまたは複数の組み合わせにできます。一般的にはユーザーごとまたはプロジェクトごと（または両方）ですが、例えば RawController のようにプロジェクトとパスでも制限できます。

これらのレート制限をバイパスする方法はありません（特定のユーザー/グループ/プロジェクトに対しても）。レート制限に達すると、レート制限ヘッダーなしに 429 ステータスコードのプレーンレスポンスが発行されます。

これらのレート制限の設定方法については GitLab ドキュメントを参照してください。

GitLab に新しいレート制限を導入する詳細については、製品プロセスハンドブックページを参照してください。

その他のレート制限

GitLab Pages

GitLab Pages は CloudFlare の背後になく CDN サポートもないため、レート制限は複数の場所で設定されています:

1. GitLab.com の Kubernetes 設定内。
2. Pages 用の Go ratelimiter モジュール内。

詳細については Pages レート制限ドキュメントを参照してください。

レジストリ

レジストリは Cloudflare でフロントされていません（理由の詳細については機密 Issue を参照してください）。アプリケーションレベルの設定もありません（それを追加するオープンな機能リクエストはあります）。そのため、レジストリのレート制限が実装されている唯一の場所は HAProxy 内です。

レジストリについては利用可能なレート制限の例外はありません。

ヘッダー

半標準のレート制限応答ヘッダーのリストはここにあります。

• Cloudflare はどのリクエストにもレート制限応答ヘッダーを返しません。
• RackAttack はスロットリングされたリクエストにのみレート制限応答ヘッダーを返します。
• ApplicationRateLimiter はレート制限応答ヘッダーを返しません。
• GraphQL エンドポイントは現在レート制限応答ヘッダーを返しません。

レート制限応答ヘッダーの返却改善についてはこの Issue を参照してください。

クライアントサイドのベストプラクティス

レート制限に達するリスクを最小化するために、以下を試すことができます:

1. リトライロジックの実装
   • 失敗した試みに対して指数バックオフとリトライを設定します。
   • 429 レスポンスステータスと Retry-After ヘッダーを尊重します。
   • 持続的な失敗に対してサーキットブレーカーを実装します。
2. 自動化パイプラインのずらし実行
   • 同時に行われるリクエスト量を削減します。
3. リクエストバッチ処理
   • 可能な場合、複数の操作を単一のリクエストに結合します。
   • クライアントサイドのキュー管理を実装します。
4. キャッシングの実装
   • リクエスト頻度を削減するため可能な場合はレスポンスをキャッシュします。
   • 例えば If-Modified-Since を利用した条件付きリクエストを実装します。
5. レート制限されたレスポンスの監視
   • レート制限されたリクエストの予期しない増加をログに記録してアラートを発します。
   • 適用可能な場合はレート制限のレスポンスとヘッダーを追跡します。

トラブルシューティング

レート制限トラブルシューティングを参照してください。

重要なリンク

• ドキュメント: GitLab.com
• ドキュメント: セルフマネージド（および Dedicated）
• ランブック: GitLab.com レート制限
• ハンドブック: GitLab.com での IP ブロックの原因を特定する

ページのソースコードを見る - ページの編集 - please contribute.