過剰コストやDDoS攻撃の対策に有効、「Amazon API Gateway」でAPI実行数を管理、制限するには:AWSチートシート
AWS活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。今回は「Amazon API Gateway」のみでできるアクセス元ごとのAPI実行数管理のポイントをする。
「Amazon Web Services」(AWS)活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。今回は「Amazon API Gateway」(以下、API Gateway)のみでできるアクセス元ごとのAPI実行数管理のポイントを紹介します。
APIの実行数を適切に管理することで、バックエンドのシステムへの影響を最小限にすることや、意図しないリクエスト増によるコスト過剰が起こらないようにすることができます。
API実行数を管理する理由
API Gatewayでアクセス元ごとにAPI実行数を適切に管理することで、想定以上のアクセスがあった場合にAPI Gatewayで「429 To Many Request」を返却して以降の処理を中断させることができます。その理由としては、大きく3つ挙げられます。
- 使う分だけのリソースを確保するため
- 悪意のあるアクセス増(DDoS攻撃など)の影響を最小限にするため
- アクセス元の利用傾向を把握し、分析にも利用できるため
1つ目については、AWSのリソースはアーキテクチャをしっかり設計しておけば、使われるだけスケールできます。ただし、スケールするとコストもかさんでいくので、悪意がなくても想定以上のアクセスは防いでおき、アクセス元で制御した方がよい場合があります。
2つ目については、アクセス元ごとにAPI実行数を管理するので、攻撃を受けているアクセス元からのリクエストのみ、以降の処理を中断させることができます。その他のアクセス元は正常に処理するので、被害を最小限に抑えることができます。
3つ目については、直接APIの実行数管理がメリットになるわけではないのですが、アクセス元ごとに管理する使用量プランを設定するので、APIキーごとのリクエスト状況が確認できるようになり、分析しやすくなります。
Amazon API GatewayのAPI実行数管理の概要
API GatewayでAPI実行数管理を行うには使用量プランとAPIキーを使って設定します。
使用量プランではアクセス元に許容するAPIの実行数を「スロットリング」と「クォータ」という2種類の制限を設定でき、ステージされているAPI Gatewayと関連付けることができます。関連付けた使用量プランをAPIキーにひも付けることで、そのAPIキーを利用したリクエストはひも付けられた使用量プランにのっとって実行数が制限されます。
Amazon API GatewayのAPI実行数管理の方法
順番に細かい設定を解説します。
使用量プラン
まずは使用量プランの設定イメージです。使用量プラン「SampleA」にスロットリングとクォータを設定し、以前の記事で作成したMock用のAPI Gatewayの「v1」ステージに関連付けています。
スロットリングの考え方
レートは許容するリクエストの平均アクセス数です。上記の画像の場合、現在実行中のリクエストに関係なく、毎秒5リクエストずつ新しくリクエストを受けることができる設定となります。
バーストは実行中における全体のリクエスト数の合計です。APIによっては3秒以上かかるもの、1秒で終わるものもありますが、そのリクエストされたタイミングに関係なく、同時に実行中におけるAPIの合計の上限値です。
つまり、上記の例の場合、毎秒5リクエストずつ受けることができ、同時に最大10リクエストまでは処理できる設定です。
仮に、1回の実行に3秒かかるAPIで、毎秒5リクエストずつAPIを実行した場合、3秒目に同時実行数の最大10を超えてしまうので429エラーが返却されます。また、実行にかかる秒数は関係なく、瞬間的に10リクエストを送った場合も毎秒新しく実行できる数の最大5を超えてしまうので429エラーが返却されます。
また、スロットリングは関連付けたAPIのメソッド単位でも設定できます。
上記画像の場合、「/mock/systema/userinfo」のGETメソッドだけでレート5、バースト10の利用を許容する設定となります。
ただし、メソッドに設定したスロットリングはAPIのステージに設定したスロットリングの内訳を設定するので、ステージに設定したスロットリングの合計値を超えての設定は予期しない429エラーを発生させる原因となります。
クォータの考え方
クォータ制限については指定した一定期間内に許容するリクエスト数の合計の最大を設定します。前述の画像例の場合、1月当たり100リクエストまで許容している設定となります。仮に1月の間に101回目のリクエストを送った場合、そのリクエスト以降はクォータ期間が過ぎるまでは429エラーが返却されます。
APIキーとの関係
作成した使用量プランはアクセス元に公開するAPIキーにひも付けます。
今回新規に設定した「test」APIキーの関連付けられた使用量プランに先ほどの「SampleA」が設定されています。この状態で「test」APIキーを利用すると「SampleA」の設定にのっとって実行数が管理されます。
サービスとしての利用シーン
システム/サービスを運用していると1つの公開しているAPI機能群に対して複数のアクセス元がある場合も多いです。その場合、アクセス元ごとにAPIキーと使用量プランを設定し、必要なリクエスト数分だけ適切に許容してあげることで前述の実行数を管理する理由にも記載したように悪意のある攻撃を最小限にしたり、想定外のコスト増を防いだりすることができます。
終わりに
今回はAmazon API GatewayでできるAPI実行数管理の方法を紹介しました。
意外と見落としがちなAPIの実行数制限。複数システムからアクセスされる場合、設定しておくことで予期せぬ事態の被害を最小限に抑えることができる簡単な方法の一つです。ぜひ、いま一度しっかり考えられて設定されているかどうかを見直してみてはいかがでしょうか。
筆者紹介
金光 適(かなみつ かなう)
株式会社システムシェアード システム開発事業部所属
最高の貢献を最高の仲間と届けることをミッションに普段はWebアプリケーションの開発を実施。API基盤開発、「AWS IoT Core」を利用した基盤構築とIoT機器から収集したデータを利用した機械学習によるレコメンドシステム開発、VM環境からAWS環境へのリプレースやAWS環境上で実施する性能試験など先端技術を用いた開発に従事。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- KongがAPI管理やサービスメッシュをマルチクラウドで統合するサービス「Kong Konnect」を発表
Kongは、モノリシック/マイクロサービス、Kubernetes/仮想マシンと、多様なアプリケーション形態とオンプレミスやパブリッククラウドなど多様な稼働場所に対応し、API管理やサービスメッシュを一括制御できる「Kong Konnect」をプライベートβとしてリリースしたと発表した。 - 手作業でAPIキーを発行、請求書は手で書き起こし――「駅すぱあとWebサービス」が取り組んだWeb API改善施策
「Google Cloud Next '18」でヴァル研究所 ナビゲーション開発部テックリードの田辺純一氏は、「駅すぱあとWebサービス」の開発や運用を振り返り、企業がWeb APIを提供する際のポイントを紹介した。 - Google、「Apigee APIプラットフォーム」にAPI監視やサービス拡張などの機能を追加
Googleは、ライフサイクルAPI管理に役立つ「Apigee APIプラットフォーム」について、新機能である「Apigee APIモニタリング」「Apigeeエクステンション」「Apigeeホステッドターゲット」の正式提供を開始した。