REL01-BP01 サービスクォータと制約を認識する - AWS Well-Architected Framework
実装のガイダンスリソース

REL01-BP01 サービスクォータと制約を認識する

デフォルトのクォータに注意して、ワークロードアーキテクチャに対するクォータ引き上げリクエストを管理しましょう。ディスクやネットワークなど、どのクラウドリソースの制約が潜在的に大きな影響を与えるかを知っておきましょう。

期待される成果: 主要メトリクスのモニタリング、インフラストラクチャのレビュー、自動修復手順に適切なガイドラインを設けて、サービスの機能低下や停止につながるサービスのクォーターや制約に達していないことを検証することで、AWS アカウントのサービスの機能低下や停止を防止できます。

一般的なアンチパターン:

  • 使用しているサービスのハードまたはソフト上のクォータや制限を理解せずにワークロードをデプロイする。

  • 必要なクォータの分析と再設定、またはサポートへの事前連絡をせずに、代替ワークロードをデプロイする。

  • クラウドサービスには制限がなく、料金、制限、回数、数量を気にせずにサービスを使用できると考えている。

  • クォータは自動的に増加すると考えている。

  • クォータリクエストのプロセスやスケジュールを知らない。

  • クラウドサービスのデフォルトのクォータが、リージョン間で比較する各サービスで同一だと考えている。

  • サービスの制約は破ることが可能で、システムによりリソースの制約を超えて自動スケールまたは制限の増加が追加されると考えている。

  • リソースの使用率にストレスをかけるためにピーク時トラフィックでアプリケーションをテストしていない。

  • 必要なリソースサイズを分析せずにリソースをプロビジョニングする。

  • 実際に必要な分または予想されるピークを遥かに超えるリソースタイプを選択することでキャパシティを過剰プロビジョニングする。

  • 新規顧客イベントや新技術のデプロイに先駆けて、新しいレベルのトラフィックのキャパシティ要件を評価していない。

このベストプラクティスを活用するメリット: サービスクォータとリソースの制約をモニタリングおよび自動管理すると、エラーを予防できます。ベストプラクティスに従っていないと、顧客のサービスにおけるトラフィックパターンの変化により、停止または機能低下が起こる可能性があります。これらの値をすべてのリージョンとすべてのアカウントでモニタリングし管理することで、有害なイベントや計画外のイベントにおける、アプリケーションの回復力が向上します。

このベストプラクティスが確立されていない場合のリスクレベル: 高

実装のガイダンス

Service Quotas は、250 を超える AWS のサービスのクォータを一元的に管理するのに役立つ AWS のサービスです。クォータ値の検索に加えて、Service Quotas コンソールから、または AWS SDK を使用してクォータ増加をリクエスト、追跡することもできます。AWS Trusted Advisor には、あるサービスの一部の要素に関する使用状況とクォータを表示するサービスクォータチェックが用意されています。サービスごとのデフォルトのサービスクォータは、それぞれのサービスの AWS ドキュメントにも記載されています (例えば、Amazon VPC クォータを参照してください)。

スロットルされた API のレート制限など、一部のサービス上の制限は、Amazon API Gateway 内で使用量プランを変更することで設定できます。それぞれのサービス上の構成として設定される一部の制限には、プロビジョンド IOPS、割り当てられた Amazon RDS ストレージ、Amazon EBS ボリューム割り当てなどがあります。Amazon Elastic Compute Cloud には、インスタンス、Amazon Elastic Block Store、および Elastic IP アドレスの制限を管理するのに役立つ独自のサービスの制限ダッシュボードがあります。サービスクォータがアプリケーションのパフォーマンスに影響を及ぼし、ニーズに合わせて調整できないような事例が発生した場合は、サポート に連絡し、緩和策の有無についてお問い合わせください。

サービスクォータはその性質上、リージョン固有である場合も、グローバルである場合もあります。クォータに達している AWS サービスを使用すると、通常の使用で予想どおりに動作しないことや、サービスの停止や機能低下を招くことがあります。例えば、あるサービスクォータではリージョンで使用する DL Amazon EC2 数を制限しており、Auto Scaling グループ (ASG) を使用したトラフィックスケーリングイベント中にその制限に達する可能性があります。

各アカウントのサービスクォータについて、使用量を定期的に評価し、そのアカウントにおける適切なサービス制限を判断する必要があります。このようなサービスクォータは、意図せず必要以上のリソースをプロビジョニングすることを防止する運用上のガードレールとして存在しています。また、API オペレーションにおけるリクエスト率を制限し、不正使用からサービスを保護する役目も持っています。

サービスの制約は、サービスクォータとは異なります。サービスの制約は、リソースタイプごとに決まっている特定のリソースの制限を表します。ストレージキャパシティ (例: gp2 のサイズ制限は 1 GB～16 TB) だったりディスクスループット (10,0000 iops) だったりします。制限に達する可能性のある使用量について、リソースタイプの制約を監督し定期的に評価することが不可欠です。予期せず制約に達した場合、アカウントのアプリケーションまたはサービスが機能低下または停止する恐れがあります。

サービスクォータがアプリケーションのパフォーマンスに影響を及ぼし、ニーズに合わせて調整できないような事例がある場合は、サポート に連絡し、緩和策の有無についてお問い合わせください。修正されたクォータの調整について詳しくは、REL01-BP03 アーキテクチャを通じて、固定サービスクォータと制約に対応する を参照してください。

Service Quotas をモニタリングおよび管理できる AWS のサービスやツールが多数用意されています。これらのサービスやツールは、クォータレベルの自動または手動チェックの提供に活用するものです。

  • AWS Trusted Advisor は、いくつかのサービスの一部の側面に対する利用状況とクォータを表示する、サービスクォータチェックを提供しています。クォータに迫っているサービスの特定に役立ちます。

  • AWS Management Consoleでは、サービスのクォータ値の表示、管理、新しいクォータのリクエスト、クォータリクエストのステータスのモニタリング、クォータの履歴の表示を行う手段を提供しています。

  • AWS CLI および CDK は、サービスクォータのレベルと使用量を自動で管理およびモニタリングする、プログラムによる手段を提供します。

実装手順

Service Quotas の場合:

  • AWS Service Quotas をレビューします。

  • 既存のサービスクォータを把握し、使用されているサービス (IAM Access Analyzer など) を判断します。サービスクォータで制御されている AWS のサービスは約 250 あります。次に、各アカウントとリージョンで使用されている可能性のある特定のサービスクォータ名を判断します。リージョンごとに約 3,000 のサービスクォータ名があります。

  • このクォータ分析を AWS Config で強化して、AWS アカウントで使用されているすべての AWS リソースを見つけます。

  • AWS CloudFormation データを使用して、使用されている AWS リソースを判断します。AWS Management Consoleまたは list-stack-resources AWS CLI コマンドを使用して作成されたリソースを見つけます。テンプレート自体にデプロイされるように設定されたリソースも確認できます。

  • デプロイコードを見て、ワークロードに必要なすべてのサービスを決定します。

  • 適用されるサービスクォータを決定します。Trusted Advisor および Service Quotas を使用してプログラムでアクセスできる情報を使用します。

  • サービスクォータが制限に近づいたか達した場合にアラートを発して知らせる自動モニタリング手段を作成します (REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する および REL01-BP04 クォータをモニタリングおよび管理する を参照)。

  • 同一アカウント内のあるリージョンでサービスクォータが変更されたが他のリージョンでは変更されていない場合を確認する、自動またはプログラムによる手段を作成します (REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する および REL01-BP04 クォータをモニタリングおよび管理する を参照)。

  • アプリケーションログやメトリクスのスキャンを自動化して、クォータまたはサービス制約のエラーが発生しているか判断します。エラーが発生している場合は、モニタリングシステムにアラートを送信します。

  • 特定のサービスでクォータの引き上げが必要であると判断された場合に、クォータで必要な変更を計算するエンジニアリング手順を作成します (REL01-BP05 クォータ管理を自動化する を参照)。

  • サービスクォータの変更をリクエストするプロビジョニングおよび承認ワークフローを作成します。これには、リクエストが拒否または一部承認された場合の例外ワークフローを含めます。

  • 本稼働環境またはロード済み環境にロールアウトする前に、新しい AWS サービスをプロビジョニングして使用するにあたって、サービスクォータをレビューするエンジニアリング手段を作成します (例: ロードテストアカウント)。

サービス制約の場合:

  • 読み取りがリソースの制約に近づいているリソースについてアラートを発報するモニタリングおよびメトリクス手段を作成します。必要に応じて CloudWatch を活用して、メトリクスまたはログをモニタリングします。

  • 制約のある各リソースについて、アプリケーションまたはシステムにとって有意なアラートのしきい値を設定します。

  • 制約が使用量に近い場合、リソースタイプを変更するワークフローまたはインフラストラクチャ管理手順を作成します。このワークフローには、ベストプラクティスとして負荷テストを含め、新しいタイプが新しい制約のある適切なリソースタイプであることを検証します。

  • 既存の手順やプロセスを使用して、特定したリソースを推奨の新しいリソースタイプに移行します。

リソース

関連するベストプラクティス:

関連するドキュメント:

関連動画:

関連ツール: