APIを運用するにあたっては乗り越えなければならないさまざまな課題がありますが、その中の一つにトラフィック管理があります。トラフィック管理とは、想定以上のHTTPリクエストを受信することでAPIサービスのシステムダウンやレスポンス遅延が発生しないように、リクエスト数を制限するしくみのことです。Apigeeにはトラフィック管理を実現するためのポリシーがいくつも用意されていて、トラフィック管理機能をお手軽に実装することができます。本記事では、Apigeeに用意されている3つのトラフィック管理ポリシーについて紹介し、実際の動作を確認します。Apigeeの概要についてはコチラをご覧ください。
1.トラフィックを管理する3つのポリシー
今回ご紹介するApigeeのトラフィック管理ポリシーは以下の3つです。
- Spike Arrest ポリシー
- Quota ポリシー
- Concurrent Rate Limit ポリシー
各ポリシーの使用目的と機能について以下に説明していきます。尚、トラフィック管理ポリシーには他にキャッシュ機能を実現するためのポリシーがありますが、本記事では割愛します。キャッシュ関連のポリシーについてはコチラの記事をご覧ください。
1-1.Spike Arrest ポリシーはバックエンドの保護
Spike Arrest ポリシーの目的は、悪意のある攻撃者によるDOS攻撃や、アプリケーションのバグ等による予期しないトラフィックの急上昇(スパイク)からバックエンドサービスを保護することです。具体的には、バックエンドサービスに送信される単位時間あたりのリクエスト数を制限します。「1秒間あたりのリクエスト数」もしくは「1分間あたりのリクエスト数」を指定することにより制限します。
1-2.Quota ポリシーは業務要件の実現
Quota ポリシーは、APIの使用制限などの業務要件やSLAの適用を実現します。具体的には、API プロキシが一定の期間内に処理できるリクエスト数を構成します。期間の指定は(数値+単位)の形式で記述します。単位は「分、時間、日、週、月」のいずれかを指定します。
1-3.Concurrent Rate Limit ポリシーは同時接続数制限
Concurrent Rate Limit ポリシーの目的は、バックエンドサービスへの同時接続数を制限することです。API プロキシとバックエンドサービス間の接続において許可する同時接続数を指定することにより制限します。
上記3つのポリシーは、使用目的が異なるため組み合わせて使用することが可能です。
2.トラフィック管理ポリシーを試してみる
各ポリシーの概要がつかめたところで、トラフィック管理ポリシーを実際に動作させてみましょう。今回は1つのAPI Proxyに先ほどご紹介した3つのポリシーを適用します。各ポリシーの適用先は、マニュアルの記載に従って推奨されるFlowに適用することで、悩まずに実装することができます。今回の適用イメージは下図のようになります。
2-1.API Proxyを作成する
まずはAPI Proxyを新たに作成します。
Apigee Edgeにログインし、左側のメニューで [Develop] – [API Proxies] を選択します。
そして、右端の「+Proxy」をクリックします。
Reverse proxy が選択されている状態で「Next」をクリックします。
Proxy Name に「Traffic-Example」と入力しています。Existing APIにはバックエンドAPIのURLを入力します。ここでは国立国会図書館サーチAPI(https://iss.ndl.go.jp/api/)を設定しています。これは国立国会図書館が提供しているサービスで、APIで所蔵資料の検索ができるものです。入力したら「Next」をクリックします。
Authorization は「Pass through (none)」を選択し、「Next」をクリックします。
全てチェックされている状態で「Next」をクリックします。
Deploy Environments の test が選択されている状態で「Build and Deploy」をクリックします。
API Proxy が作成できました。
2-2.SpikeArrest ポリシーを実装する
続いて、Trafiic-Example にSpike Arrest ポリシーを実装します。
API Proxy の一覧にて、先ほど作成したTraffic-Example を選択します。
DEVELOPタブをクリックします。
Spike Arrest ポリシーは通常、Proxy Endpoint のRequestのPreFlow の先頭に実装します。画面左側のNavigatorにてProxy EndpointsのPreFlowを選択した状態で、画面中央部分のREQUEST側(上側)の「+Step」をクリックします。
Add Step ダイアログで、「Spike Arrest」ポリシーを選択し、Display Name とName はデフォルトのまま「Add」をクリックします。
Spike Arrest ポリシーのXMLを編集し、Rate要素を「2pm」に設定します。これは、1分あたりのリクエスト数を2リクエストに制限することを意味します。その他不要な項目は削除します。「Save」をクリックして設定を保存します。
ProxyEndpointのXMLを確認してみましょう。PreFlowのRequest にSpike Arrest ポリシーのStepが追加されています。
2-3.SpikeArrest ポリシーの動作を確認する
SprikeArrest ポリシーの動作を確認します。
Apigeeでは、TRACE機能を使ってビジュアルにAPI Proxyの通信状況を表示することができます。
TRACEタブをクリックした後、「Start Trace Sesstion」をクリックします。
API ProxyにHTTPリクエストを送信します。
上記はタイトルに”gafam”を含む資料を検索するためのGETリクエストです。
HTTPリクエストを5回連続して送信したところ、4回目まではステータスコード200が返りましたが、5回目のリクエストでSpileArrest ポリシー制限が適用され、ステータスコード429が返りました。SpikeArrest ポリシーの実装では、Rate要素を「2pm」に設定したので3回目のリクエストから制限されると考えるのが普通ですが、これにはApigeeのメッセージプロセッサ数(以降MP数)が関係しています。デフォルトの動作では、Rate×MP数までリクエスト数が許容されます。尚、Apigee Edge クラウド環境のデフォルトMP数は2です。従って、4回までのリクエストが許容される実装となっています。
Spike Arrest ポリシーの動作が確認できたので、次のポリシー実装に備えて制限値を拡張しておきましょう。Spike Arrest ポリシーのXMLを編集し、Rate要素を「200pm」に変更して保存しておきます。
2-4.Quota ポリシーを実装する
続いて、Trafiic-Example にQuota ポリシーを実装します。
Quota ポリシーは通常、Proxy Endpoint のRequestのPreFlow に実装します。API Proxyに認証系のポリシーを実装している場合、その後に実装します。今回は認証系ポリシーが存在しないので、SpikeArrest ポリシーの後に実装することになります。画面左側のNavigatorにてProxy EndpointsのPreFlowを選択した状態で、画面中央部分のREQUEST側(上側)の「+Step」をクリックします。
Add Step ダイアログで、「Quota」ポリシーを選択し、Display Name とName はデフォルトのまま「Add」をクリックします。
Quota ポリシーのXMLを編集し、Allow要素のcountを「2」、Interval要素を「1」、TimeUnit要素を「minute」に設定します。これは、1分あたりのリクエスト数を2リクエストに制限することを意味します。また、メッセージプロセッサ間でカウンタを共有させるためにDistributed要素及びSynchronous要素を「true」に設定します。設定値を確認したら「Save」をクリックして設定を保存します。
ProxyEndpointのXMLを確認してみましょう。PreFlowのRequest にQuota ポリシーのStepが追加されています。
2-5.Quota ポリシーの動作を確認する
Spike Arrest ポリシーと同様にTRACE機能を開始後、API ProxyにHTTPリクエストを送信します。
HTTPリクエストを連続して3回送信したところ、2回目まではステータスコード200が返りましたが、3回目のリクエストでQuota ポリシー制限が適用され、ステータスコード429が返りました。
Quota ポリシーの動作が確認できたので、次のポリシー実装に備えて制限値を拡張しておきましょう。Quota ポリシーのXMLを編集し、Allow要素のcountを「200」に変更して保存しておきます。
2-6.Concurrent Rate Limit ポリシーを実装する
続いて、Trafiic-Example にConcurrent Rate Limit ポリシーを実装します。
Concurrent Rate Limit ポリシーは、Target Endpoint のRequestのPreFlowとTarget Endpoint のResponseのPostFlowに実装します。また、併せてDefaultFaultRuleを追加する必要があります。
画面左側のNavigatorにてTarget EndpointsのPreFlowを選択した状態で、画面中央部分のREQUEST側(上側)の「+Step」をクリックします。
Add Step ダイアログで、「Concurrent Rate Limit」ポリシーを選択し、Display Name とName はデフォルトのまま「Add」をクリックします。
Concurrent Rate Limit ポリシーのXMLを編集し、AllowConnections要素のcountを「1」に設定します。これは、バックエンドへの同時接続数を1つに制限することを意味します。また、TargetIdentifier要素のnameを「default」に設定します。これは適用対象のTarget Endpointのname属性の値です。設定値を確認したら「Save」をクリックして設定を保存します。
TargetEndpointのXMLを確認してみましょう。PreFlowのRequest にConcurrent Rate Limit ポリシーのStepが追加されています。また、PostFlowのResponseにConcurrent Rate Limit ポリシーのStepが自動追加され、DefaultFaultRuleも自動追加されていることが確認できます。
2-7.Concurrent Rate Limit ポリシーの動作を確認する
TRACE機能を開始後、API ProxyにHTTPリクエストを送信します。今回はHTTPクライアントを2つ用意し、API Proxyに対して同時に送信しました。
片方のHTTPリクエストに対してはステータスコード200が返りましたが、もう一方のHTTPリクエストに対してはConcurrent Rate Limit ポリシー制限が適用され、ステータスコード503が返りました。
3.まとめ
いかがだったでしょうか。Apigeeのトラフィック管理ポリシーを使うことで、短時間で簡単にトラフィック制御を実装することができました。最後に、今回取り上げたトラフィック管理ポリシーを表にまとめておきますのでポリシー検討時の参考にして下さい。
ポリシー | 使用目的 | 機能 | API Proxy への配置 |
制限到達時の HTTPステータスコード |
---|---|---|---|---|
Spike Arrest | バックエンドサービスの保護 | 単位時間あたりのリクエスト数制限 | ProxyEndpoint /Request /PreFlow |
429 (Too Many Requests) |
Quota | 業務的なリクエスト制限 | 一定期間内のリクエスト数制限 | ProxyEndpoint /Request /PreFlow |
429 (Too Many Requests) |
Concurrent Rate Limit |
バックエンドサービスの同時接続要件 | バックエンド同時接続数制限 | (1)TargetEndpoint /Request /PreFlow (2)TargetEndpoint /Response /PostFlow |
503 (Service Unavailable) |