レート制限に対するデータドリブン アプローチについて
レート制限がなければ、1 時間に数万件の要求を行う 1 つの CI 統合によって、すべてのユーザーのインスタンス全体が遅くなる可能性があります。 ただし、制限を積極的に設定しすぎると、チームが依存する統合が損なえる可能性があります。 データドリブンアプローチは、実際の使用パターンを観察することから始めて、収集したデータに基づいて徐々に制限を適用することで、適切なバランスを見つけるのに役立ちます。
このアプローチは、次のフェーズに従います。
-
**監視**: ログ転送を有効にし、API トラフィック パターンを分析します。 -
**ベースライン**: 高い初期値でレート制限を有効にして、レート制限データの収集を開始します。 -
**絞り込み**: 観察された使用状況に基づいて制限を調整し、影響を受けるチームと通信します。 -
**維持**: 時間の経過に伴う制限を継続的に監視および調整します。
[Management Console] を使用してレート制限を有効にする方法については、 Configuring rate limits (レート制限を構成する) を参照してください。
前提条件
開始する前に、以下の項目があることを確認します:
- [Management Console] への管理者アクセス
- ログ転送構成へのアクセス
- 一元化されたログを分析する機能
- 組織の API の使用パターンと重要な統合に関する理解
手順 1: ログ転送を有効にする
ログ転送を使用して、監視と分析のために API 要求ログを一元化します。 詳細については、「ログの転送」を参照してください。
転送されたログを分析する場合は、次の重要なフィールドに注目してください。
| フィールド | 説明 |
|---|---|
Timestamp | 要求が行われた日時を追跡します |
user / gh.actor.login | 要求を行うユーザーまたは統合を識別します |
path_info / gh.request.api.route | アクセスされる API ルート |
status | HTTP 応答コード (成功の 200 やレート制限がある場合の 429 など) |
user_agent | 要求を送信するクライアントまたは統合を識別します |
手順 2: 制限を有効にする前に API の傾向を分析する
レート制限を有効にする前に、全体的な使用状況の傾向を分析してベースラインを確立します。
-
**上位のコンシューマーを特定します。** 要求の数が最も多いユーザーまたは統合を検索します。 -
**需要の高いエンドポイントを確認します。** 最も多くのトラフィックを受信し、最適化の恩恵を受ける可能性がある API ルート (`path_info`) を強調表示します。 -
**非効率的なパターンを検出します。** キャッシュを使用せず頻繁にポーリングすることや、冗長な要求など、高負荷や非効率的な使用の兆候を探します。
このベースライン データは、推測ではなく実際の使用状況によって通知されるレート制限を設定するのに役立ちます。
手順 3: 高い初期値でレート制限を有効にする
レート制限を有効にする準備ができたら、既存のワークフローを中断することなく追加のデータを収集できるように、高いしきい値から始めます。
-
[Management Console] で、プライマリ API レートの制限を高い値 (1 時間あたり 25,000 要求など) に設定します。 詳細については、「Configuring rate limits (レート制限を構成する)」を参照してください。
-
レート制限を有効にした後、転送されたログに表示される
gh.rate_limitフィールドを監視します。フィールド 説明 gh.rate_limit.primary.max許可される最大要求数 gh.rate_limit.primary.remaining現在の期間の残りの要求 gh.rate_limit.primary.used期間内に既に行われた要求 gh.rate_limit.primary.resetレート制限期間がリセットされたときの Unix タイムスタンプ
手順 4: 制限を調整し、大量の使用量に対処する
`gh.rate_limit` フィールドのデータを使用して、情報に基づいた意思決定を行います。
* 制限に近いユーザーを特定します。 しきい値に頻繁に近づいている、またはしきい値を超えているユーザーまたは統合を見つけます。 * 適切な制限を決定します。 任意の値ではなく、観察された使用傾向に基づいてレート制限を設定します。 * 影響を受けるチームと通信します。 チームと協力して、要求のバッチ処理、応答キャッシュ、条件付き要求などの手法を使用して API の使用を最適化します。
手順 5: 制限を減らし、時間の経過と同時に維持する
API の使用状況を明確に把握したら、インスタンスの容量と実際の使用パターンに合わせてレート制限を徐々に減らします。 各調整後に意図しない中断を監視します。
制限を調整するときは、統合が影響を受けるチームと連携します。 要求のバッチ処理、応答キャッシュ、条件付き要求などの手法は、チームが API の使用を減らすのに役立ちます。
ghe-config ユーティリティを使用して、特定のユーザーをレート制限から除外することもできます。 詳細については、「コマンド ライン ユーティリティ」を参照してください。
新しい統合が追加され、ワークフローが進化すると使用パターンが変化するため、レート制限データを定期的に確認します。
その他の考慮事項
-
**GraphQL API の制限。** GraphQL API には、除外リストではバイパスできない個別のレート制限 (既定: 1 時間あたり 5,000 ポイント) があります。 詳細については、「[AUTOTITLE](/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api)」を参照してください。 -
**2 次レート制限。** セカンダリ レート制限を有効にして、サービスの全体的なレベルを保護することもできます。 詳細については、「[AUTOTITLE](/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-rate-limits#enabling-secondary-rate-limits)」を参照してください。
詳細については、次を参照してください。
-
[AUTOTITLE](/rest/overview/rate-limits-for-the-rest-api)