Service QuotasとCapacity Failure

ゴール

Auto Scalingを設定していても、

負荷増加
↓
スケールアウトが必要
↓
追加リソースを作成
↓
上限やキャパシティ不足
↓
必要量まで増やせない

ことがあります。

重要なのは、

Auto Scalingできる
=
必要なキャパシティを
必ず確保できる

ではないことです。

設計時には、

スケーリング側の最大値
サービスクォータ
固定された制約
実際の利用可能キャパシティ
依存先の上限

を分けて確認します。

このページでは、必要な最大キャパシティを先に計算し、その量が各種上限の内側で本当に成立するか判断することを完成させます。

1. サービスクォータは「使用を許可される上限」

AWSサービスには、リソース数や処理量などに上限があります。

AWSではService Quotasを使用して、対応するサービスのクォータや適用値を確認できます。

例えば、

現在使用量
70

適用クォータ
100

追加予定
40

なら、

70 + 40 = 110

となるため、現在のクォータ100では計画した追加量を収容できません。

つまりサービスクォータは、そのAWSアカウントで利用を許可されている最大量です。

2. スケーリング側の最大値とサービスクォータは別

Auto Scalingグループに、

最大キャパシティ
200

と設定しても、AWSサービス側で200台分に相当する利用量が許可されているとは限りません。

Auto Scaling
最大キャパシティ 200
        ↓
200まで増やしたい

しかし

AWSサービス側
利用可能上限 100相当
        ↓
必要量まで作成できない

ということがあります。

逆に、AWSサービス側のクォータに十分な余裕があっても、

Auto Scaling
最大キャパシティ 50

なら、Auto Scaling側の設定が50より先へのスケールアウトを止めます。

したがって、

スケーリング設定上の最大値
≠
AWSサービス側の利用上限

として別々に設計します。

3. 調整可能なクォータは必要になる前に引き上げる

サービスクォータによっては引き上げをリクエストできます。

例えば、

現在のクォータ
100

予想最大使用量
150

なら、実際に150必要になってから対応するのではなく、

需要予測
↓
必要最大量を計算
↓
余裕を加える
↓
事前にクォータ引き上げを申請
↓
利用可能な値を確認
↓
本番イベント

とします。

クォータ引き上げは、

申請した
=
その場で希望値が利用可能になる

とは限りません。

したがって、イベントや移行の直前ではなく、必要になる時点から逆算して準備することが重要です。

4. 調整できない上限はアーキテクチャで回避する

すべての上限を引き上げられるわけではありません。

例えば、

設計上必要
500

変更できない上限
300

なら、

引き上げ申請

では解決できません。

この場合は、

• リソースを分割する
• 構成単位を変更する
• 別のサービスや方式を使用する
• 必要なリソース量そのものを削減する

などを検討します。

つまり、固定された上限を超える前提で設計しないことが必要です。

5. 平常時だけでなく一時的な重複キャパシティを計算する

必要なクォータを考えるとき、

通常時の最大使用量

だけを見ると不足することがあります。

例えば現在の環境が80で動作しており、ブルー/グリーンデプロイで新環境を80追加するとします。

切り替え前には、

旧環境 80
+
新環境 80
=
160

が同時に存在します。

さらに設計上20の余裕を持たせるなら、

必要上限
180以上

が必要です。

同じ考え方は、障害時の代替リソース、ブルー/グリーン、大規模な置き換え、移行、急激なスケールアウトにも使います。

平常時に足りる = 障害時や変更時にも足りるではありません。

6. 障害時は既存リソースと代替リソースが重複する場合がある

障害したリソースへアクセスできなくなっても、それが直ちに削除されるとは限りません。

例えば、

正常時
80

障害後も残る既存リソース
80

復旧のため追加
40

なら、一時的に120相当の利用量が必要になる可能性があります。

したがってフェイルオーバー設計では、

通常時に使用する量
+
復旧時に追加する量

がサービスクォータ内に収まるか確認します。

7. クォータに余裕があっても実キャパシティ不足は起こる

サービスクォータに十分な余裕があっても、必要なリソースをその場所・種類で実際に提供できるかは別問題です。

Amazon EC2では、要求したオンデマンドキャパシティをその時点で確保できない場合、

InsufficientInstanceCapacity

が発生することがあります。

例えば、

EC2サービスクォータ
十分

↓
特定AZ
+
特定インスタンスタイプ
+
大量起動

↓
InsufficientInstanceCapacity

というケースです。

これはサービスクォータ不足とは異なります。

8. クォータ引き上げは実キャパシティの予約ではない

例えばEC2のサービスクォータを大きく引き上げても、

その値まで
EC2を利用することが許可された

という意味です。

その値と同量の
特定インスタンスが
自分専用に確保された

という意味ではありません。

したがって、

クォータに余裕あり
↓
それでも
InsufficientInstanceCapacity

は成立します。

設計では、

サービスクォータ
=
利用を許可される上限

実キャパシティ
=
その時点で実際に提供できる量

を分けます。

9. 実キャパシティ不足では配置の柔軟性を考える

クォータには余裕があるのに、特定のEC2キャパシティを確保できない場合は、

• 別のアベイラビリティーゾーン
• 別のインスタンスタイプ
• 一度に要求する量
• 配置条件

などを評価します。

つまり、

特定AZ
+
特定インスタンスタイプ
+
必要台数

へ設計を固定しすぎると、実キャパシティ不足に弱くなります。

可用性を高めるには、要件を満たせる範囲でキャパシティ取得経路に柔軟性を持たせることも重要です。

10. 依存先上限は「目標スケールから必要量を逆算」する

複数階層のシステムでは、依存先にも上限があります。

設計時には、目標とするスケール量から依存先に必要な量を計算します。

例えば、

アプリケーションサーバー
目標最大数 = 100台

1台当たり
DB接続 = 最大20

なら、

100 × 20
=
最大2,000接続

を要求する可能性があります。

ところが、

データベース
最大接続数 = 1,000

なら、アプリケーションを100台まで増やせるという設計だけでは成立しません。

必要なのは、

目標スケール
↓
依存先消費量を計算
↓
依存先上限と比較

です。

11. 依存先にはDB以外もある

スケール時に確認する依存先はデータベースだけではありません。

例えば、

コンピューティング
↓
サブネットIPアドレス

アプリケーション
↓
データベース接続

アプリケーション
↓
外部サービス

各リソース
↓
関連するAWSサービスの上限

があります。

設計時には、スケールさせるリソースだけでなく、そのリソースが増えることで消費するものまで確認します。

12. キャパシティ計画は最大シナリオから逆算する

必要量を計算するときは、現在値ではなく、将来どこまで増える必要があるかから逆算します。

例えば、

通常最大
60

イベントピーク
90

障害時に追加
30

デプロイ時に一時追加
20

だからといって、すべてを無条件に足すわけではありません。

重要なのは、どのシナリオが同時に発生する前提なのかを整理することです。

例えば、

イベントピーク中でも
1AZ障害から復旧できる必要がある

なら、イベントピークと障害時の追加量を同時に成立させます。

同時発生を要件としていないデプロイ分まで加算する必要があるかは、システム要件によって判断します。

13. クォータちょうどではなく設計上の余裕を持たせる

例えば、

予想最大使用量
100

適用クォータ
100

では、計算上は上限内です。

しかし、予測誤差、成長、障害時の一時重複、リソース置き換えを吸収できません。

したがって、

必要最大量
<
利用可能上限

となるよう余裕を持たせます。

ただし、常に固定割合を機械的に使うのではなく、成立させる障害・変更・成長シナリオから余裕量を決めることが重要です。

14. 設計時の確認順序

必要な最大キャパシティを決める
↓
同時に成立させる
障害・変更シナリオを確認
↓
必要総量を計算
↓
スケーリング設定上の最大値を確認
↓
サービスクォータを確認
↓
調整可能か固定か確認
↓
実キャパシティ不足の可能性を確認
↓
依存先消費量を計算
↓
すべての制約内で
目標キャパシティが成立するか確認

「どこか1つだけ余裕がある」ではなく、すべての制約を通過できることが必要です。

15. 混同ポイント

16. SAP-C02判断フロー

必要な最大キャパシティは？
↓
障害・変更時を含めた
必要総量を計算
↓
スケーリング設定上の
最大値は足りる？
│
├─ いいえ
│   → スケーリング設定を見直す
│
└─ はい
    ↓
サービスクォータは足りる？
│
├─ いいえ
│   ↓
│  調整可能？
│   ├─ はい
│   │   → 事前に引き上げを準備
│   │
│   └─ いいえ
│       → 上限内に収まる設計へ変更
│
└─ はい
    ↓
必要な実キャパシティを
確保できる設計か？
│
├─ 不足する可能性あり
│   → AZやリソースタイプの
│      柔軟性を評価
│
└─ 成立
    ↓
依存先消費量は
各上限内か？
│
├─ いいえ
│   → 依存先または接続方式を再設計
│
└─ はい
    ↓
必要キャパシティが成立

まとめ

信頼性のあるキャパシティ設計では、

Auto Scalingを設定した

だけでは不十分です。

必要なのは、

必要最大量
↓
スケーリング設定
↓
サービスクォータ
↓
固定された上限
↓
実キャパシティ
↓
依存先上限

のすべてを通過できることです。

特に、

サービスクォータ
=
利用を許可される上限

実キャパシティ
=
その時点で実際に提供できる量

を混同しません。

また、

平常時
+
同時に成立させる障害・変更条件
+
必要な余裕

から設計上の最大量を求めます。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド（SAP-C02）
• AWS Service Quotas — Service Quotasとは
• AWS Service Quotas — クォータ引き上げのリクエスト
• AWS Well-Architected Framework — サービスクォータと制約
• AWS Well-Architected Framework — フェイルオーバー時のクォータ余裕
• Amazon EC2 — インスタンス起動問題のトラブルシューティング