type
status
date
slug
summary
tags
category
icon
password
 

理論

Amazon API Gatewayにおけるスロットリングと制限の本質的な知識

Amazon API Gatewayは、サーバーレスのAPIを構築、管理、監視するための強力なサービスです。API Gatewayを使用する際に重要なのは、リクエストの処理能力やリソースの制限について理解することです。これらの制限に達した場合、リクエストはエラー(通常は 429 Too Many Requests)となり、Lambda関数やバックエンドサービスが呼び出されません。API Gatewayのスロットリングと制限について深掘りしてみましょう。

1. API Gatewayのスロットリング制限

API Gatewayは、APIの呼び出しを管理するためにスロットリング制限を設定しています。これにより、過負荷を防ぎ、リソースを保護することができます。主に2つのレベルで制限が設定されています:
  • アカウント単位のスロットリング制限: これは、全リージョンのAPI Gatewayに共通の制限です。デフォルトでは、1秒あたり10,000リクエストが許可されています。この制限は、API Gatewayアカウント全体に適用されるため、複数のリージョンでサービスを展開している場合でも、合計でこの制限を超えてリクエストを送ることはできません。
  • リージョンごとのAPI制限: 各リージョンにおいて、API Gatewayには独自の制限が設けられています。例えば、リージョンのAPIにはデフォルトで1秒あたり600リクエストまでという制限があり、これを超えるとリクエストは拒否されます。
  • エッジ最適化API: エッジ最適化APIは、ユーザーのリクエストを最寄りのCloudFrontエッジロケーションで処理するためのAPIですが、この場合、1秒あたり120リクエストとさらに厳しい制限があります。

2. トークンバケットアルゴリズムによるバースト容量

API Gatewayは、トークンバケットアルゴリズムを使用して、通常時のリクエスト制限を超えて一定量のバーストを許可します。これは、短期間に多くのリクエストが発生する場合でも、システムが過負荷にならないようにするための仕組みです。
  • 最大バースト容量: バースト容量は最大5,000リクエストまで対応可能です。これは、API Gatewayの通常のリクエスト制限(たとえば10,000リクエスト/秒)に追加される形で、急なリクエスト増加に対応します。
  • バースト容量の管理: バースト容量はAPI Gatewayサービスチームによって管理され、顧客がその容量を増加させるためのリクエストを出すことはできません。リクエストがバースト容量を超えると、429 Too Many Requests エラーが返されます。

3. API Gatewayの制限と料金

API Gatewayには、リクエスト数やトラフィック量に基づいた料金体系があります。制限を意識せずにトラフィックを増加させると、料金が予想以上に高額になる場合があります。制限を越えないように設計を行うことが、コストを抑えるために重要です。

4. 制限に達した場合の対策

API Gatewayの制限に達した場合、リクエストが失敗し、429エラーが返されます。これに対する一般的な対策には以下があります:
  • スロットリングの最適化: アプリケーションやAPIのトラフィックを適切に調整し、急激なトラフィックの増加を抑えるための調整が必要です。
  • リクエストの再試行: APIリクエストが失敗した場合、一定時間後に再試行するようにアプリケーションを設計することで、リソースが回復した後にリクエストを再度送信することができます。
  • スケーリングの検討: 高トラフィックが予想される場合は、API Gatewayの制限を上げる方法を検討したり、バックエンドのLambda関数やインフラをスケーリングすることが考えられます。

5. 制限とパフォーマンスのバランス

API Gatewayを利用する際には、パフォーマンスとコストをバランスよく管理することが求められます。スロットリング制限を超えないようにし、かつ、予測可能なトラフィックの増加に対応するためには、事前にトラフィックの予測とシステムの設計をしっかり行うことが不可欠です。

結論

Amazon API Gatewayは、柔軟でスケーラブルなAPI管理のソリューションを提供しますが、リクエスト制限を超えるとエラーが発生し、サービスに影響を与える可能性があります。これを回避するためには、API Gatewayの制限を理解し、アーキテクチャの最適化、スケーリングの計画、トラフィック管理を適切に行うことが必要です。
リソース/オペレーション
デフォルトのクォータ
引き上げ可能
アカウント単位のスロットリングクォータ
10,000リクエスト/秒(RPS)(バースト容量最大5,000リクエスト)
いいえ
リージョンのAPI
1秒あたり600リクエスト
いいえ
エッジ最適化API
1秒あたり120リクエスト
いいえ
バースト容量
最大5,000リクエスト(トークンバケットアルゴリズムに基づく)
顧客が制御できない

注意点:

  • バーストクォータ(最大5,000リクエスト)は、リージョンごとのアカウント単位の制限(10,000RPS)に基づいており、API Gatewayサービスチームによって決定されます。
  • 引き上げ可能な項目は、アカウント単位のスロットリングクォータのみですが、これに関しては顧客が直接変更をリクエストすることはできません。
この表を基に、API Gatewayの制限やバースト容量について把握できます。

実践

一問道場

質問 #120
トピック 1
ある企業がAWS上でソフトウェア・アズ・ア・サービス(SaaS)ソリューションを構築しています。この企業は、複数のAWSリージョンで、同じ本番アカウント内でAWS Lambda統合を伴うAmazon API Gateway REST APIを展開しています。
この企業は、顧客が1秒あたり一定数のAPI呼び出しを行うための容量に対して支払うことができる階層型価格設定を提供しています。プレミアムプランは最大3,000回の呼び出しを提供し、顧客は一意のAPIキーで識別されます。
ピーク使用時間中に複数のリージョンでいくつかのプレミアムプラン顧客が、複数のAPIメソッドから「429 Too Many Requests」のエラーレスポンスを受け取っていることを報告しています。ログによると、Lambda関数は一度も呼び出されていません。
これらの顧客に対するエラーメッセージの原因として考えられるものは何ですか?
A. Lambda関数が同時実行数の制限に達した
B. Lambda関数がリージョンごとの同時実行数制限に達した
C. 企業がAPI Gatewayアカウントの1秒あたりの呼び出し制限に達した
D. 企業がAPI Gatewayのデフォルトのメソッドごとの1秒あたりの呼び出し制限に達した
 

解説

C. 企業がAPI Gatewayアカウントの1秒あたりの呼び出し制限に達した です。

詳細な解説:

API Gatewayには、アカウント全体での制限があり、1秒あたりのAPI呼び出し回数には制限があります。企業が複数のリージョンでAPI Gatewayを使用しており、プレミアムプランの顧客が多く、特にピーク時に大量のリクエストがある場合、アカウント全体でこの制限を超えると、429 Too Many Requests エラーが発生します。このエラーは、リクエストが許容範囲を超えた場合に返されるもので、Lambda関数が実行される前にAPI Gatewayでブロックされるため、Lambdaが呼び出されないことが確認されている点も合致しています。

他の選択肢について:

  • A. Lambda関数が同時実行数の制限に達した: この場合、Lambda関数の呼び出しが多すぎる場合に発生しますが、ログによるとLambdaは呼び出されていないため、この問題は該当しません。
  • B. Lambda関数がリージョンごとの同時実行数制限に達した: 同様に、Lambdaの呼び出しが実行されていないため、この選択肢も不正解です。
  • D. API Gatewayのデフォルトのメソッドごとの1秒あたりの呼び出し制限に達した: この制限はメソッドごとに設定されていますが、アカウント全体の制限が超過した場合に問題が発生しているため、選択肢Cが正解です。
したがって、正解は C です。
相关文章
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
EKSでのWordPressデプロイ:KCNA-JP試験対策 (Kubernetes実践編)
Lazy loaded image
初心者向け!コンテナ化WordPressサイト構築ガイド(超詳細版)
Lazy loaded image
EFSを活用!AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
Lazy loaded image
528-AWS SAP AWS 「理論・実践・一問道場」Migration Evaluator
Lazy loaded image
121-AWS SAP AWS 「理論・実践・一問道場」GWLB119-AWS SAP AWS 「理論・実践・一問道場」インスタンス自動再開
Loading...
みなみ
みなみ
一个普通的干饭人🍚
最新发布
02-生成AIパスポート試験対策:第2章「生成AI」
2025-2-1
01-生成AIパスポート試験対策:第1章「人口知能」
2025-2-1
究極のAWS認定 AI 実践者 AIF-C01 - 学習メモ
2025-1-27
不要再傻傻的直接买NISA啦
2025-1-27
Kubernetes、仮想マシンとコンテナの概念を超簡単に解説!
2025-1-24
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
2025-1-22
公告
🎉欢迎访问我的博客🎉
- 感谢您的支持 --
本站点于2024/09/01建立
👏主要分享IT相关主题👏
系统管理:
Redhat…
容器和编排:
Kubernetes、Openshift…
云计算:
AWS、IBM…
AI入门
以及技术笔记和考证经验
定期更新,欢迎互动。
感谢访问!
快速浏览相关标签