Contents
Apigee ポリシー レート制限 設定 手順を初心者向けに解説
APIの運用において、レート制限はサービスの安定性を保つために不可欠な仕組みです。Apigeeでレート制限ポリシーを設定することで、不正アクセスや過剰なリクエストを防ぎ、APIの信頼性向上が可能になります。本記事では、初心者でも理解しやすいステップバイステップガイドを通して、Apigeeでのレート制限設定の実装方法とその意義を解説します。
Apigeeのレート制限ポリシーとは？
APIの呼び出し数に上限を設けることで、過剰なアクセスや不正利用を防ぐ仕組みが「レート制限ポリシー」です。Apigeeではこの機能を活用することで、APIのパフォーマンスを維持しながら、ユーザーごとの使用量を管理できます。
具体的には以下のようなシーンで有効です：
- 特定の時間帯に集中したアクセスを防ぐ
- 無料APIでの利用制限を設定する
- サードパーティアプリケーションの呼び出し頻度を調整する
このポリシーは、Apigee管理コンソールで簡単に作成・適用可能で、初心者でも導入が可能です。
レート制限ポリシーをAPIプロキシに追加する手順
ポリシーの作成
レート制限ポリシーは、Apigee管理コンソール上で以下のように作成します。
- Apigee管理コンソールにログインし、「Develop」タブを選択します。
- 「Policies」メニューから「Create New Policy」をクリックします。
- 「Rate Limiting」を選択し、ポリシー名（例：
rate-limit-policy-01）を入力して作成します。
注意点：ポリシー名は一意に設定してください。複数のAPIプロキシで使用する場合は、共通の命名規則を採用すると管理がしやすくなります。
APIプロキシへの適用
ポリシーを作成した後は、以下のようにAPIプロキシに適用します。
- 作成したAPIプロキシを選択し、「Edit」をクリックします。
- 「Target Endpoints」タブに移動し、「Policies」セクションで先ほど作成したポリシーを選択します。
- ポリシーの配置位置（例：
PreFloworPostFlow）を設定して保存します。
補足：レート制限は通常、API呼び出しの前段階（PreFlow）で実施することが多いため、そこへの適用が推奨されます。
パラメータ設定のポイント
レート制限ポリシーでは以下のパラメータを設定します。
- クライアントID指定：特定のユーザーにのみ制限をかける場合は「Client ID」パラメータを使用します。このパラメータは、API呼び出し元の識別子（例：
client_id=123456）を指定するものです。 - 制限値と期間：1秒あたりの許容リクエスト数（例：
10 requests/second）や、時間単位での上限（例：100 requests/hour）を設定できます。 - リセットポリシー：制限を超えた場合の処理（例：503エラーを返す）を指定します。
| 設定項目 | 説明 |
|---|---|
| クライアントID | 特定ユーザーに適用するか否か |
| リクエスト制限値 | 単位時間あたりの最大数（例：10 requests/second） |
| エラー応答種別 | 制限超過時のレスポンスコード（例：503 Service Unavailable） |
補足：クライアントID指定は、認証後に取得されるAPIキーの形式が一般的です。Postmanでのテストでは、リクエストヘッダーに
Authorization: Bearer <token>やClient-ID: 123456を追加します。
クォータ制限とレート制限の違いを理解する
レート制限 vs クォータ制限：主要な違い
APIプロキシでは、「クォータ制限」と「レート制限」の2つのポリシーが存在します。どちらもアクセス量を管理するものですが、適用タイミングや用途に違いがあります。
比較表
| 項目 | レート制限 | クォータ制限 |
|---|---|---|
| 対象 | 秒単位でのリクエスト数 | 日単位・月単位の総量 |
| 適用タイミング | 1秒ごとにチェックされる（リアルタイム） | 設定期間終了時にチェックされる |
| 用途例 | 不正アクセスの即時制御 | サービス利用量の上限設定 |
注意点：Apigeeでは「レート制限」が秒単位で設定可能であり、クォータ制限は日・月単位の総リクエスト数を管理します。時間単位（例：1時間）でのクォータ制限もサポートされています。
初心者が混同しやすいポイント
- レート制限は「短時間の集中リクエスト」を防ぐために使われます。たとえば、1秒間に20回以上のアクセスがあった場合に即座に制限が適用されます。
- クォータ制限は「長期間の総使用量」の管理用です。例えば、月間5,000リクエストを超えるユーザーに対して制限をかけるケースがあります。
両方を使い分けることで、APIの運用コストと安全性のバランスが取りやすくなります。
テスト環境での動作確認手順
テスト用APIの準備
レート制限ポリシーの動作を検証するためには、テスト用のAPIが必要です。
- ApigeeでサンドボックスAPIを作成し、テスト用に公開します。
- PostmanやcURLを使用して、リクエストを送信する準備を行います。
おすすめツール：Postmanの「Collection Runner」機能で連続リクエストを送信できます。これにより、レート制限が適切に動作しているかを確認可能です。
Postmanによる負荷テスト
以下のようにPostmanで連続リクエストを送信し、レート制限の動作を検証します。
- リクエストURLを指定します（例：
https://sandbox-api.example.com/users）。 - 「Tests」タブで、レスポンスコードやヘッダー情報を検証するスクリプトを作成します。
- 例:
pm.test("Should return 429 Too Many Requests", function () { pm.expect(pm.response.code).to.eql(429); }); - 「Runner」で連続リクエストを送信し、制限が適用されるか観察します。
パラメータ例：レート制限は1秒につき5リクエストの設定で、6回目以降に
429 Too Many Requestsが返ってくるか確認します。
-GET /usersに対して「Runner」で10回リクエストを送信し、5回目に制限が発生するか観察します。
cURLによる負荷テストの手順
cURLでも同様に連続リクエストを送信できます。以下は例です。
- リクエストURLを指定します（例：
https://sandbox-api.example.com/users）。 curlコマンドでリクエストを送信するスクリプトを作成します。-
例:
bash
for i in {1..10}; do
curl -X GET "https://sandbox-api.example.com/users" -H "Client-ID: 123456"
sleep 0.1
done -
リクエスト結果を確認し、制限が適切に動作しているか観察します。
制限適用の検証方法
レート制限ポリシーの検証には以下の手段があります。
| 検証項目 | 確認方法 |
|---|---|
| リクエスト数カウント | Apigeeの監視ツールで確認 |
| 制限超過時のエラーコード | PostmanやcURLのレスポンスコード確認 |
| ログ情報 | Analyticsで詳細なアクセス履歴取得 |
補足：Apigee Analyticsでは、リクエスト数が上限に達した場合の「503 Service Unavailable」をフィルタリングして解析可能です。
設定後の検証と次のステップ
レート制限ポリシーの設定が完了したら、実際にAPIを呼び出して動作を検証することが重要です。Postmanや負荷テストツールを使って、レート制限が正しく適用されるか確認してください。
実際の運用では、以下の点にも注意が必要です：
- 監視とログの確認：Apigeeの「Analytics」機能を活用し、不正アクセスの傾向を把握します。
- ポリシーの最適化：使用状況に応じて制限値を調整していきます。
設定完了後は、「実際にAPIコールで制限が適用されるか検証してみましょう」というCTA文にも記載した通り、テスト環境での確認が不可欠です。その結果をもとに運用ポリシーを最適化してください。