REL01-BP01 サービスクォータと制約を認識する - 信頼性の柱
実装のガイダンスリソース

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 アドレスの制限を管理するのに役立ちます。サービスクォータがアプリケーションのパフォーマンスに影響を及ぼし、ニーズに合わせて調整できないような事例が発生した場合は、Supportに連絡し、緩和策の有無についてお問い合わせください。

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

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

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

サービスクォータがアプリケーションのパフォーマンスに影響を及ぼし、ニーズに合わせて調整できないような事例がある場合は、Supportに連絡し、緩和策の有無についてお問い合わせください。修正されたクォータの調整に関する詳細は、「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 クォータをモニタリングおよび管理する」を参照のこと)。

  • サービスクォータが 1 つのリージョンで変更されたときに同一アカウント内の他のリージョンで変更されたかどうかを確認する、自動化されたプログラムによる方法を作成します (「REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する」および「REL01-BP04 クォータをモニタリングおよび管理する」を参照のこと)。

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

  • 特定のサービスでクォータの引き上げが必要であると判断された場合に、クォータに必要とされる変更を測定するための手順を作成します (「REL01-BP05 クォータ管理を自動化する」を参照のこと)。

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

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

サービス制約の場合:

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

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

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

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

リソース

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

関連ドキュメント:

関連動画:

関連ツール: