はじめに
AWSのサービスクォータ、意識していますか?
小規模なシステムであれば、意識していなくても問題になることはないかもしれません。
しかし、大規模なシステムではアーキテクチャ設計からサービスクォータを意識していないと痛い目に遭うことがあります。
本記事では、サービスクォータを意識する必要性を解説します。
合わせて、全サービスクォータを一覧化するCLIスクリプトも紹介します。
2022/02/28 追記
続編書きました。↓
サービスクォータとは?
一言で言えば**「AWSのサービス毎に定められた制限」**です。
以下はVPCのクォータです。
「リージョンあたりの VPC の数」はデフォルトで「5」となっています。
「デフォルトで」というのは調整できる=引き上げ可能ということです。
「VPC 当たりの IPv6 CIDR ブロック」のように引き上げ不可のクォータもあります。
引き上げ不可のクォータは特に注意が必要です。
なぜ、サービスクォータを意識しないといけないのか?
結論から言うと、サービスクォータを意識していないと、システムの信頼性・可用性が低下してしまう可能性があるためです。
例えば、Aさんが API Gateway - Lambda - DynamoDB を用いてサーバーレスなAPIサービスを作ったとしましょう。
Aさんは「Lambdaは自動でスケーリングしてくれるから利用者が増えても大丈夫」と考えています。
このAPIサービスは好評を博し、順調に利用者が増えていきました。
すると、ある日突然、このAPIでエラーが頻発するようになりました。
なぜでしょう?
原因は、利用者増加に伴い、Lambdaの同時実行数が増え、同時実行数が「1,000」を超えた=Lambdaのサービスクォータに引っ掛かってしまったためでした。
つまり、Aさんはサービスクォータを意識していなかったため、このAPIサービスの信頼性・可用性の低下を招いてしまったわけです。
こういった事態を引き起こさないよう、アーキテクチャ設計からサービスクォータを意識しておきましょう。
ここでは Lambdaの同時実行数のクォータを例にしましたが、場合によっては API Gateway や DynamoDB のクォータが問題になっていた可能性もあります。
つまり、サービスクォータはシステムを構成するすべてのサービスについて意識する必要があります。
AWS Well-Architected Framework にも書かれている
サービスクォータを意識しよう、という話は AWS Well-Architected Framework にも書かれています。
AWS Well-Architected Framework は簡単に言うと**「AWS アーキテクチャ設計のベストプラクティスを体系化したもの」**です。
AWS Well-Architected Framework は、以下の6つの柱で構成されています。
- オペレーショナルエクセレンス(運用上の優秀性)
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
- サステナビリティ(持続可能性) 1
サービスクォータは信頼性に影響するので**「信頼性の柱」**として定義されています。
- サービスクォータと制約を認識する
- アカウントおよびリージョンをまたいでクォータを管理する
- アーキテクチャを通じて、固定サービスクォータと制約に対応する
- クォータをモニタリングおよび管理する
- クォータ管理を自動化する
- フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
クォータのモニタリングと管理の自動化については、また別の機会に書こうと思います。
↓
続編「続・AWSのサービスクォータをなめてると痛い目に遭うぞ!(自動化CloudFormation付き)」書きました。(2022/02/28 追記)
サービスクォータはどうやって確認すればよいのか?
「サービスクォータを意識しないといけないことはわかった」
「じゃあ、どうやって確認すればいいんだ?」
「引き上げはどうやるんだ?」
答えは「Service Quotas コンソールで確認・リクエストする」です。
詳細は以下の記事を読んでみてください。
でも、ひとつひとつ確認するのは面倒じゃないですか?
私は面倒ですw
前述のとおり、サービスクォータはシステムを構成するすべてのサービスについて意識する必要があります。
例として挙げたサーバーレスAPIでも、実際には API Gateway, Lambda, DynamoDB だけではなく、セキュリティやモニタリングのために WAF, KMS, CloudWatch Logs, Alarm, SNS, S3, ... と多くのサービスを使う必要があります。
私はアーキテクチャ設計を担当することが多いので、毎回、それらすべてのクォータを確認するのは面倒なんです!
なので、すべてのサービスクォータを一括出力するCLIスクリプトを作ってみました。
AWS CLI スクリプト
#!/bin/sh
# 引数から対象リージョンを取得(未指定の場合、$AWS_REGIONを対象リージョンとする)
region=${1:-$AWS_REGION}
echo "Target region: $region"
# すべてのデフォルトクォータ
all_default_quotas='[]'
# サービスコード一覧を取得
services=`aws service-quotas list-services --region $region --query Services[*].ServiceCode --output text`
for service in $services
do
# デフォルトクォータを取得
echo "Getting default service quotas: $service"
quotas=`aws service-quotas list-aws-default-service-quotas --region $region --service-code $service`
# すべてのデフォルトクォータに追加
all_default_quotas=`echo $all_default_quotas $quotas | jq -s '.[0] + .[1].Quotas'`
done
# JSONファイル出力
echo $all_default_quotas > all_default_quotas_$region.json
コピペして、CloudShellなどで実行してみてください。
やっていることはシンプルで、これだけです↓
-
list-services コマンドでサービスコード一覧を取得
-
サービス毎にループ
2-1. list-aws-default-service-quotas コマンドでサービスクォータを取得
2-2. 取得したクォータを結合 -
JSONファイルとして出力
なお、list-aws-default-service-quotas コマンドは名前のとおり、デフォルトのクォータを取得するコマンドです。
これを list-service-quotas コマンドに置き換えると、現在のクォータ(引き上げた場合、引き上げ後のクォータ)を取得することができるので、目的に応じて使い分けてください。
IAM や CloudFront などグローバルサービスのクォータを取得するには、バージニア北部リージョン(us-east-1)を指定する必要があります。
一覧化
JSONのままでは確認しづらいので適当なツールを使って、CSV化しましょう。
私は Visual Studio Code の以下のプラグインを使わせていただきました。便利ですね。感謝。
あとは Excel なり Spreadsheets なりで取り込めば、全サービスクォータ一覧のできあがり!
こんな感じになります↓
これでサービスクォータをさくっと確認することができるようになりました。
まとめ
- AWSのサービスクォータを意識しよう
- サービスクォータを意識しないと信頼性が低下してしまう可能性がある
- サービスクォータはシステムを構成するすべてのサービスについて意識しよう
最後まで読んでいただき、ありがとうございます。
この記事が少しでも役に立てば幸いです。
-
サステナビリティ(持続可能性)の柱は、2021年12月に AWS re:Invent 2021 で発表・追加されました。https://aws.amazon.com/jp/blogs/news/sustainability-pillar-well-architected-framework/ ↩