超簡単!Apigeeでお手軽にトラフィック制御を実装しよう!

Author
kurata
Lv:2 Exp:402

システム開発部所属。バックエンドの開発を主に担当しています。
Apigeeを勉強中です。

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に適用することで、悩まずに実装することができます。今回の適用イメージは下図のようになります。
ApigeeAPIProxy

2-1.API Proxyを作成する

まずはAPI Proxyを新たに作成します。
Apigee Edgeにログインし、左側のメニューで [Develop] – [API Proxies] を選択します。

ApiProxy1p
そして、右端の「+Proxy」をクリックします。

ApiProxy2p
Reverse proxy が選択されている状態で「Next」をクリックします。

ApiProxy3p
Proxy Name に「Traffic-Example」と入力しています。Existing APIにはバックエンドAPIのURLを入力します。ここでは国立国会図書館サーチAPI(https://iss.ndl.go.jp/api/)を設定しています。これは国立国会図書館が提供しているサービスで、APIで所蔵資料の検索ができるものです。入力したら「Next」をクリックします。

ApiProxy4p
Authorization は「Pass through (none)」を選択し、「Next」をクリックします。

ApiProxy5p
全てチェックされている状態で「Next」をクリックします。

ApiProxy6p
Deploy Environments の test が選択されている状態で「Build and Deploy」をクリックします。

ApiProxy7p
API Proxy が作成できました。

2-2.SpikeArrest ポリシーを実装する

続いて、Trafiic-Example にSpike Arrest ポリシーを実装します。
API Proxy の一覧にて、先ほど作成したTraffic-Example を選択します。
DEVELOPタブをクリックします。

SpikeArrest1p
Spike Arrest ポリシーは通常、Proxy Endpoint のRequestのPreFlow の先頭に実装します。画面左側のNavigatorにてProxy EndpointsのPreFlowを選択した状態で、画面中央部分のREQUEST側(上側)の「+Step」をクリックします。

SpikeArrest2p
Add Step ダイアログで、「Spike Arrest」ポリシーを選択し、Display Name とName はデフォルトのまま「Add」をクリックします。

SpikeArrest3p
Spike Arrest ポリシーのXMLを編集し、Rate要素を「2pm」に設定します。これは、1分あたりのリクエスト数を2リクエストに制限することを意味します。その他不要な項目は削除します。「Save」をクリックして設定を保存します。

SpikeArrest4p
ProxyEndpointのXMLを確認してみましょう。PreFlowのRequest にSpike Arrest ポリシーのStepが追加されています。

2-3.SpikeArrest ポリシーの動作を確認する

SprikeArrest ポリシーの動作を確認します。
Apigeeでは、TRACE機能を使ってビジュアルにAPI Proxyの通信状況を表示することができます。

TraceStartp
TRACEタブをクリックした後、「Start Trace Sesstion」をクリックします。

Postmanp
API ProxyにHTTPリクエストを送信します。
上記はタイトルに”gafam”を含む資料を検索するためのGETリクエストです。

SpikeArrestTest1p
HTTPリクエストを5回連続して送信したところ、4回目まではステータスコード200が返りましたが、5回目のリクエストでSpileArrest ポリシー制限が適用され、ステータスコード429が返りました。SpikeArrest ポリシーの実装では、Rate要素を「2pm」に設定したので3回目のリクエストから制限されると考えるのが普通ですが、これにはApigeeのMessage Processor数(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」をクリックします。

Quota1p
Add Step ダイアログで、「Quota」ポリシーを選択し、Display Name とName はデフォルトのまま「Add」をクリックします。

Quota2p
Quota ポリシーのXMLを編集し、Allow要素のcountを「2」、Interval要素を「1」、TimeUnit要素を「minute」に設定します。これは、1分あたりのリクエスト数を2リクエストに制限することを意味します。また、メッセージプロセッサ間でカウンタを共有させるためにDistributed要素及びSynchronous要素を「true」に設定します。設定値を確認したら「Save」をクリックして設定を保存します。

Quota3p
ProxyEndpointのXMLを確認してみましょう。PreFlowのRequest にQuota ポリシーのStepが追加されています。

2-5.Quota ポリシーの動作を確認する

Spike Arrest ポリシーと同様にTRACE機能を開始後、API ProxyにHTTPリクエストを送信します。

QuotaTest1p
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」をクリックします。

Concurrent1p
Add Step ダイアログで、「Concurrent Rate Limit」ポリシーを選択し、Display Name とName はデフォルトのまま「Add」をクリックします。

Concurrent2p
Concurrent Rate Limit ポリシーのXMLを編集し、AllowConnections要素のcountを「1」に設定します。これは、バックエンドへの同時接続数を1つに制限することを意味します。また、TargetIdentifier要素のnameを「default」に設定します。これは適用対象のTarget Endpointのname属性の値です。設定値を確認したら「Save」をクリックして設定を保存します。

Concurrent3p
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に対して同時に送信しました。

ConcurrentTest1p
片方の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)
次の記事を読み込んでいます
次の記事を読み込んでいます
次の記事を読み込んでいます
次の記事を読み込んでいます