Contents
Quota ポリシーの概要
Quota は「一定時間内に許容できる総リクエスト数」を管理するポリシーです。期間単位で上限を設定することで、課金モデルや SLA に合わせた安定運用が実現できます。
- 主なパラメータ
interval: 制御対象となる時間間隔（例:1 minute,1 hour,1 day）allow: 上限リクエスト数（整数）-
identifier: ユーザーやアプリを区別するキー（例:request.header.client-id） -
代表的な設定例
| 使用シーン | interval | allow | コメント |
|---|---|---|---|
| 1 分間に最大 500 件 | 1 minute |
500 | 短時間のトラフィック上限 |
| 月次で 10,000 件まで | 1 month |
10000 | ビジネス単位の課金枠 |
ポイント：Quota は期間ごとの総量を制御するため、長期的なリソース確保や利用料計算に最適です。
Spike Arrest ポリシーの概要
Spike Arrest は「秒単位」や「ミリ秒単位」で許容できるレートを設定し、瞬間的なトラフィック急増（スパイク）を平滑化します。バックエンドへの過負荷防止に特化した機能です。
- 主なパラメータ
-
rate: 許容リクエストレート（例:100ps＝100 リクエスト/秒、200pm＝200 リクエスト/分） -
設定例
| 使用シーン | rate | コメント |
|---|---|---|
| 1 秒間に最大 100 件 | 100ps |
高スループット API の保護 |
| 10 ミリ秒ごとに最大 2 件 | 200pm（＝1200 リクエスト/分） |
細かい粒度のレート制御 |
ポイント：Spike Arrest は瞬間的なバーストを抑えるため、フロントエンド保護層として Quota と併用することが推奨されます。
動的レート制限（Adaptive / Dynamic Quota）の現状と実装上の注意点
2026 年に「Dynamic Quota」や「Adaptive Quota」と呼ばれる概念がコミュニティで議論されていますが、公式ドキュメントに type="adaptive" といった属性は存在しません。そのため、動的な上限を実現したい場合は以下のような代替手段を取ります。
- KVM に上限値を格納し、ポリシー実行時に
VariableもしくはJavaScriptポリシーで取得。 - 取得した変数を通常の Quota ポリシーの
allow属性に参照させる（countRefではなくallowに動的値を代入）。
KVM を利用した可変上限値の取得例
|
1 2 3 4 5 6 7 8 |
# KVM の作成と上限値登録（gcloud CLI でも可） curl -X POST "https://apigee.googleapis.com/v1/organizations/${ORG}/environments/${ENV}/keyvaluemaps" \ -H "Authorization: Bearer $TOKEN" \ -d '{ "name":"dynamic-quota", "entry":[{"name":"rateLimit","value":"1200"}] }' |
|
1 2 3 4 5 |
<!-- JavaScript ポリシーで KVM から上限を取得 --> <JavaScript name="GetDynamicQuota"> <ResourceURL>jsc://get-dynamic-quota.js</ResourceURL> </JavaScript> |
get-dynamic-quota.js
|
1 2 3 4 5 6 7 8 9 |
var kv = context.getVariable('target.kvm.dynamic-quota.rateLimit'); if (kv) { // 取得した文字列を数値に変換して変数へ格納 context.setVariable('dynamic.quota.limit', parseInt(kv, 10)); } else { // デフォルト上限（例: 500）を設定 context.setVariable('dynamic.quota.limit', 500); } |
|
1 2 3 4 5 6 7 |
<!-- 通常の Quota ポリシーで動的変数を参照 --> <Quota name="DynamicQuota"> <Interval>1 minute</Interval> <Allow ref="dynamic.quota.limit"/> <Identifier ref="request.header.client-id"/> </Quota> |
注意：上記は「公式にサポートされた」構文ではなく、実装例として広く採用されている手法です。導入前にステージング環境で十分なテストを行ってください。
Envoy との連携具体例
Envoy 側でも同様の上限情報を利用したい場合は、Apigee が提供する HTTP ヘッダー を取得し、local_rate_limit フィルタに反映させます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
# envoy.yaml の filter_chain 例 filters: - name: envoy.filters.http.router typed_config: {} - name: envoy.filters.http.local_ratelimit typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.local_rate_limit.v3.LocalRateLimit stat_prefix: http_local_rate_limiter token_bucket: max_tokens: 1200 # デフォルト上限（Apigee が返すヘッダーで上書き可能） tokens_per_fill: 0 # 動的に更新されるため 0 に設定 fill_interval: 60s filter_enabled: runtime_key: local_rate_limit_enabled default_value: numerator: 100 denominator: HUNDRED request_headers_to_add: - header: key: x-apigee-dynamic-limit value: "%REQ(x-adaptive-limit)%" |
ポイント：Apigee 側で
x-adaptive-limitヘッダーを付与し、Envoy のlocal_rate_limitに動的に反映させることで、エッジ全体で統一したレート制御が可能です。
実践的なレート制限設計パターン
本セクションでは、バースト対応 と Spike Arrest の組み合わせ に焦点を当て、環境別に推奨される設定例とその根拠を示します。
バースト対応と Spike Arrest の組み合わせ
バースト（突発的なピーク）を吸収するための「バッファ」 Quota と、瞬間レートを抑える Spike Arrest を同時に適用します。実務で推奨される比率は バッファ上限の約 70% 程度です。
| 環境 | バッファ (リクエスト/分) | Spike Arrest レート |
|---|---|---|
| dev | 200 (= 1.5 × 133) | 90ps |
| staging | 300 (= 2 × 150) | 120ps |
| prod | 600 (= 1.5 × 400) | 280ps |
ポイント：バッファを余裕持たせることで、Spike Arrest が頻発するリスクを低減しつつ、全体スループットを確保できます。
環境別設定サンプル（prod 用）
以下はプロダクション環境での代表的な XML 設定です。コメントで各要素の意図を示しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<!-- Spike Arrest：瞬間レート上限 --> <SpikeArrest name="ProdSpikeArrest" async="false"> <Rate>280ps</Rate> </SpikeArrest> <!-- バッファ用 Quota（Burst） --> <Quota name="ProdBurstBuffer" async="false"> <Interval>1 minute</Interval> <Allow count="600"/> <Identifier ref="request.header.client-id"/> <DisplayName>ProdBurstBuffer</DisplayName> </Quota> |
モニタリング・アラートとキャパシティプランニング
レート制限の有効性は リアルタイムモニタリング と 適切な閾値設定 によってのみ検証できます。以下では Cloud Monitoring へのメトリクスエクスポート例と、推奨アラート条件を示します。
主要指標と推奨閾値
| 指標 | 推奨アラート条件 |
|---|---|
| Quota ヒット率（5 分平均） | > 85 % → warning、> 95 % → critical |
| Spike Arrest 発火回数（1 時間合計） | > 1,000 回/時 → warning、> 2,000 回/時 → critical |
| Edge CPU 使用率 | > 75 % → warning、> 90 % → critical |
キャパシティプランニング手順
-
ベースライン取得
過去 7 日間のリクエストレートと平均処理時間を Cloud Monitoring のクエリで集計します。 -
上限算出式（経験則）
AllowedRate = (EdgeCPU * 0.8) / AvgProcessingTime EdgeCPUは割り当てられた CPU コア数-
AvgProcessingTimeはミリ秒単位の平均処理時間 -
バッファ追加
想定される突発負荷を考慮し、AllowedRate * 1.2を上限として Quota と Spike Arrest に反映します。
注意：本式はあくまで目安です。実際のトラフィックパターンに合わせて係数を調整してください。
CI/CD でのポリシー管理とトラブルシューティング
自動デプロイと可視化を組み合わせることで、設定ミスや容量不足による障害を早期に検知できます。
ポリシーサンプル（JSON/YAML）
|
1 2 3 4 5 6 7 8 9 10 |
{ "name": "QuotaPolicy", "type": "Quota", "properties": { "interval": "1 minute", "allow": 500, "identifier": "${request.header.client-id}" } } |
|
1 2 3 4 5 6 7 8 |
# Spike Arrest の YAML 表記例（Envoy 用） apiVersion: apigee.googleapis.com/v1 kind: SpikeArrestPolicy metadata: name: spike-arrest-prod spec: rate: "280ps" |
GitHub Actions を用いた自動デプロイ例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
name: Deploy Apigee Proxy on: push: branches: [ main ] jobs: deploy-proxy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Authenticate to GCP uses: google-github-actions/auth@v1 with: credentials_json: ${{ secrets.GCP_SA_KEY }} - name: Deploy proxy bundle run: | curl -X POST "https://apigee.googleapis.com/v1/organizations/${{ env.APIGEE_ORG }}/environments/${{ env.APIGEE_ENV }}/apis" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -F "file=@apiproxy.zip" |
トラブルシューティングチェックリスト
| 項目 | 確認ポイント | 推奨アクション |
|---|---|---|
| Quota ヒット数が急増 | Analytics > API Proxy > Quota の時系列グラフ |
上限値再計算、バッファ拡張 |
| Spike Arrest が頻発 | Trace で SpikeArrest ステップの実行時間確認 |
レート緩和または Burst Quota 追加 |
| 504 エラーが多発 | Edge の CPU/メモリ使用率（Monitoring） | インスタンスタイプ拡張、レート制限見直し |
ポイント：ポリシー変更後は必ずステージング環境で負荷テストを実施し、トラフィックパターンが期待通りに抑制されていることを確認します。
まとめ
- Quota と Spike Arrest の役割分担
- Quota は期間ごとの総リクエスト上限を管理し、長期的なリソース確保や課金に最適。
-
Spike Arrest は瞬間的なバーストを抑制し、フロントエンドの安定性を担保。
-
動的レート制限の実装指針
-
公式には
type="adaptive"が存在しないため、KVM + JavaScript（または Variable）で上限値を取得し、通常の Quota に組み込む方法が現実的。 -
設計パターン
-
バッファ Quota と Spike Arrest の比率を約 70% 前後に設定し、環境別（dev / staging / prod）で上限を調整。
-
モニタリングとキャパシティプランニング
- Cloud Monitoring に主要指標をエクスポートし、Quota ヒット率・Spike Arrest 発火回数の閾値でアラートを構築。
-
CPU 使用率と平均処理時間から算出した上限式をベースに、1.2 倍のバッファを加えて設定する。
-
CI/CD とトラブルシューティング
- JSON/YAML のポリシー定義をコード管理し、GitHub Actions／Cloud Build で自動デプロイ。
- Trace と Analytics による可視化を活用し、障害時は上記チェックリストで迅速に原因切り分け。
以上のベストプラクティスを踏まえて、2026 年版 Apigee 環境に最適なレート制限を設計・実装してください。
情報源の信頼性について
本稿で参照した外部サイト（例：app‑tatsujin.com）は第三者が運営しているため、内容の正確性は保証できません。導入前に公式ドキュメントや社内レビューを必ず実施してください。