SAP-C02-136 · セクション 15 / タスク 3.4

Service Quotas / Limitsによる障害を防ぐ

Service Quotas / Current Usage / Quota Limit / Capacity / Scaling / Quota Increase / Capacity Failure

サービスクォータと必要キャパシティの基本的な比較、調整可能 / 調整不可の違い、クォータ不足と実キャパシティ不足の違いは既習です。

このページでは、将来必要になるキャパシティがすでに分かっている既存環境について、

現在の適用クォータ
+
現在使用量
+
継続的な利用状況

を正しく取得し、

上限へ接近する前に検知
↓
必要な対応を開始
↓
スケーリング可能な状態を維持

する運用へ改善します。

ゴール

既存環境で、

適用クォータは確認している
しかし
現在使用量を正しく追跡できていない

または、

現在使用量は分かる
しかし
上限接近を継続監視していない

状態を見つけ、

現在使用量を正しい範囲で取得
↓
適用クォータと継続比較
↓
クォータ接近を事前検知
↓
必要な引き上げ運用へ接続

できるようにします。

1. AWSデフォルト値ではなく現在の適用クォータを使う

既存環境の監視では、対象クォータについて現在の適用クォータを基準にします。

例えば、

AWSデフォルトクォータ
100

現在の適用クォータ
300

なら、現在のアカウントで評価すべき上限は300です。

以前にクォータ引き上げが行われている環境では、

AWSデフォルト値
=
現在利用できる上限

とは限りません。

2. 現在使用量を取得できるとは限らない

Service Quotasでは、対応するクォータについて現在の利用状況を確認できる場合があります。

一方、クォータによっては、

利用率
Not available

となる場合があります。

これは、

現在使用量
=
0

を意味しません。

単にService Quotasから利用状況を取得できない場合があります。

3. 使用量が取得できない場合は別の情報源から確認する

Service Quotasで現在使用量を取得できない場合は、

対象サービスのAPI
サービス固有メトリクス
リソース一覧
AWS CLI

など、対象サービスで利用可能な方法から現在使用量を確認します。

重要なのは、

Service Quotasに表示されない
↓
使用していない

と判断しないことです。

クォータ障害を防ぐには、現在の適用クォータと比較できる現在使用量を別の方法でも確定できる状態にします。

4. 適用範囲を合わせて使用量を集計する

現在使用量を確認するときは、クォータの適用範囲と揃えます。

例えば対象クォータが、

特定AWSアカウント
+
特定リージョン

で共有されるなら、その範囲で消費しているリソースを集計します。

アプリケーションAだけ

を確認して、

まだ余裕がある

とは判断できません。

同じクォータを利用する他のワークロードも含めます。

5. ワークロード単位の利用率と共有クォータ利用率を混同しない

例えば、

適用クォータ
1000

アプリケーションA
420

アプリケーションB
470

その他
40

なら、アプリケーションAだけを見ると、

420 / 1000
=
42%

です。

しかし共有クォータ全体では、

420 + 470 + 40
=
930

930 / 1000
=
93%

です。

自分のワークロードは42%

という情報だけで、スケーリング余裕を判断してはいけません。

6. 現在使用量を継続的に追跡する

現在使用量を一度確認しただけでは、その後の急激な増加を検知できません。

対応するAWSサービスでは、使用状況メトリクスがAmazon CloudWatchの、

AWS/Usage

名前空間へ発行されます。

これを利用できる場合は、

現在使用量
↓
継続取得
↓
クォータ接近を監視

へ移します。

7. SERVICE_QUOTAで現在の適用クォータと対応付ける

CloudWatchでは、対応する使用状況メトリクスに対して、

SERVICE_QUOTA(m1)

を利用できます。

例えば、

m1
=
現在使用量

なら、

m1 / SERVICE_QUOTA(m1) * 100

によって、現在使用量が適用クォータの何%に達しているかを計算できます。

これにより、

使用量だけを監視

ではなく、

現在の適用クォータに対して
どの程度余裕が残っているか

を継続監視できます。

8. クォータ接近をCloudWatchアラームへ接続する

使用状況メトリクスを利用できる場合は、クォータ接近をCloudWatchアラームで検知できます。

現在使用量
↓
利用率上昇
↓
しきい値到達
↓
通知
↓
必要な対応を開始

という流れです。

AWS公式資料では、設定例として80%をしきい値にしたCloudWatchアラームが紹介されています。

このページでは特定のしきい値を選ぶ方法までは扱わず、クォータへ到達する前に通知できる状態へ移すことを中心にします。

9. Automatic Managementでクォータ運用を補助できる

Service QuotasのAutomatic Managementを利用できる対象では、クォータの利用状況監視を運用へ組み込めます。

Notify and Auto-Adjustを利用している場合は、

利用率上昇
↓
クォータ引き上げリクエスト作成

まで自動化できることがあります。

このページではAutomatic Managementの対応サービスや対応クォータ一覧そのものは扱わず、既存環境ですでに利用している、または利用可能な場合の運用判断に限定します。

10. 自動引き上げリクエストの結果を確認する

Notify and Auto-Adjustでリクエストが作成されても、必ず承認されるとは限りません。

例えば、

自動引き上げリクエスト
↓
NOT_APPROVED

となる場合があります。

この状態で、

自動化しているので
ピーク時には増えているはず

とは判断しません。

必要なキャパシティが迫っているなら、手動のクォータ引き上げを検討します。

11. 「自動化したこと」ではなく現在の適用値を確認する

重要なのは、

アラームを設定した

Automatic Managementを有効化した

引き上げリクエストが作成された

という操作履歴ではありません。

最終的には、

現在の適用クォータ

が必要なキャパシティを収容できる値になっていることを確認します。

ただし、このページではクォータ引き上げの基本手順そのものは再講義しません。

12. 既存環境の確認表

確認対象	確認すること
適用クォータ	現在のアカウント・リージョンへ実際に適用されている値
現在使用量	Service Quotasまたはサービス固有の方法で取得できるか
集計範囲	同じクォータを共有する他ワークロードを含めているか
継続監視	一時点ではなく利用増加を追跡できるか
CloudWatch	`AWS/Usage`と`SERVICE_QUOTA`を利用できるか
Automatic Management	既存環境で利用している場合、その結果を確認できるか
自動調整結果	自動リクエストが承認されたか
最終確認	現在の適用クォータが必要量を収容できるか

13. 改善の流れ

将来必要量は既に把握済み
↓
現在の適用クォータを確認
↓
現在使用量を取得できる？
│
├─ はい
│   ↓
│   クォータの適用範囲で集計
│
└─ いいえ
    ↓
    サービス固有の方法で
    現在使用量を取得
↓
同じクォータを使う
他ワークロードも含める
↓
継続監視できる？
│
├─ AWS/Usageあり
│   ↓
│   SERVICE_QUOTAと組み合わせ
│   CloudWatchアラーム
│
└─ 利用不可
    ↓
    別の監視方法を用意
↓
Automatic Managementを
利用している場合は結果を確認
↓
自動引き上げが不承認なら
手動対応を検討
↓
現在の適用クォータを再確認

14. 混同ポイント

誤った判断	改善時の判断
AWSデフォルト値が現在の上限	現在の適用クォータを見る
利用率が`Not available`なら使用量0	別の方法で現在使用量を取得する
自分のワークロードだけ見ればよい	共有クォータ全体の使用量を集計する
月1回確認すれば十分	継続的にクォータ接近を監視する
CloudWatchアラームを設定すれば対策完了	通知後に必要な運用対応へ接続する
Auto-Adjustなら必ず引き上げ成功	`NOT_APPROVED`などの結果を確認する
リクエスト作成済みなら利用可能	現在の適用クォータを確認する

15. SAP-C02での判断フロー

既存システムを
さらにスケールさせる必要あり
↓
現在の適用クォータは？
↓
現在使用量は取得できる？
│
├─ できる
│   ↓
│   適用範囲全体で集計
│
└─ できない
    ↓
    サービス固有の方法で取得
↓
共有クォータなら
他ワークロードも含めた？
↓
継続監視できる？
│
├─ AWS/Usage利用可能
│   ↓
│   CloudWatchアラーム
│
└─ 利用不可
    ↓
    別の監視方法
↓
Automatic Managementを
利用している場合は
自動処理結果を確認
↓
必要なら手動対応
↓
現在の適用クォータが
必要キャパシティを収容できる状態を維持

16. このページで扱わないこと

ここでは、

利用増加そのものの予測方法

Auto Scalingポリシーの設計

サービスクォータの基本定義

調整可能 / 調整不可の基本比較

クォータと物理キャパシティの基本比較

Automatic Managementの
対応サービス / 対応クォータ一覧

ブルー / グリーン時の
重複キャパシティ計算

DRリージョンのクォータ設計

マルチアカウント分離

依存先データベース接続数の設計

最終的な信頼性改善策の横断選択

は扱いません。

このページで完成させるのは、

現在の適用クォータ
+
現在使用量
↓
正しい範囲で継続監視
↓
上限接近を事前検知
↓
必要なクォータ運用へ接続
↓
スケーリングに必要な余裕を維持

という判断です。

まとめ

クォータ起因の障害を防ぐには、

上限値を一度確認する

だけでは不十分です。

現在の適用クォータ
+
現在使用量
+
共有範囲
+
利用状況の変化

を継続的に把握します。

さらに、

AWS/Usage
+
SERVICE_QUOTA
+
CloudWatchアラーム

や、

Service Quotas
Automatic Management

を既存環境で利用できる場合は運用へ組み込みます。

最も重要なのは、

現在使用量を
正しい範囲で把握できる
↓
クォータ接近を
障害になる前に検知できる

状態を維持することです。

主要AWS公式資料

AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.4
AWS Service Quotas — Viewing service quotas
Amazon CloudWatch — AWS usage metrics
Amazon CloudWatch — Visualizing service quotas and setting alarms
AWS Service Quotas — Automatic Management

理解確認

このページの内容を4問で確認します。

理解確認4問へ →