DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

AWSサービス制限の増加を申請・管理するためのベストプラクティス

AWSサービスクォータを監視し、早期にキャパシティを計画し、スロットリングが本番環境に影響を与える前に明確なクォータ増加リクエストを送信します。

AWSサービス制限の増加を申請・管理するためのベストプラクティス

AWSサービスクォータは、サービスの暴走を防ぎますが、最悪のタイミングでスケーリング計画を止める可能性もあります。チームがローンチやトラフィックスパイクの前にクォータを監視していないと、アプリケーションコードが正常でも、スロットリング、デプロイの失敗、キャパシティエラーが発生する可能性があります。

Service Quotasコンソール、CloudWatch、明確なビジネス正当性を使用して、通常のキャパシティ計画の一部として制限を管理します。

AWSサービスクォータの理解

リクエストを開始する前に、AWSの制限の性質を理解することが不可欠です。これらの制限は通常、リソース（例：EC2インスタンス数）、スループット（例：IOPS）、またはAPIリクエスト毎秒（RPS）に基づいて分類されます。

ソフト制限 vs ハード制限

ほとんどのクォータは次の2つのカテゴリのいずれかに分類されます：

  • ソフト制限（調整可能なクォータ）： これらは大多数のクォータです。新しいアカウントにAWSが設定するデフォルト値であり、十分なビジネス正当性があれば、AWSサポートにリクエストを送信することで一般的に増加できます。
  • ハード制限（調整不可能なクォータ）： これらの制限は、サービス設計、安全性、またはインフラストラクチャの制約によって決まります。一般的に増加できないため、アーキテクチャ上の回避策が必要です。

ヒント： 最初にAWS Service Quotasコンソールを常に確認してください。そこにリストされている制限は通常ソフト制限であり、リクエストを送信する推奨方法です。

注意が必要な一般的な制限

スケーラブルな環境では、以下の制限が最初に達することが多く、注意深く監視する必要があります：

  1. EC2オンデマンドインスタンス数： リージョン内のすべてのEC2インスタンスタイプで実行されているvCPUの総数。
  2. EBSボリューム数/サイズ： アタッチされたボリュームの総数または累積サイズの制限。
  3. VPCリソース： VPC、インターネットゲートウェイ、NATゲートウェイ、Elastic IP（EIP）の数の制限。
  4. APIスロットリング制限： S3、DynamoDB、Lambda呼び出しレートなどのサービスのリクエスト毎秒（RPS）制限。

プロアクティブな監視と予測

スロットリングへの対応はコストがかかり、混乱を招きます。目標は、本番環境に影響を与えるずっと前に、制限違反をプロアクティブに予測することです。

1. Service Quotasコンソールの活用

AWS Service Quotasコンソールは、多くのサービスにわたる現在のクォータの表示と使用状況の追跡を行うための単一の信頼できる情報源です。これにより、さまざまなサービスコンソールで制限を確認する必要がなくなります。

実行可能な手順： Lambda、EC2、RDS、VPC、DynamoDBなど、アプリケーションにとって重要なサービスのクォータを定期的に監査します。着実に上昇している、またはすでにアラートしきい値に近いクォータを調査します。

2. CloudWatchアラームの実装

重要な制限については、使用量が危険なしきい値に近づいたときにチームに通知する自動アラームを設定します。

多くのリソースメトリクス（EC2 vCPU使用量、Lambda同時実行数など）はCloudWatchに公開されています。Service Quotasと直接統合されているクォータについては、Quotasコンソールから直接アラームを作成でき、通常は使用率80%に設定します。

# 例：Lambda同時実行数に対する80%使用率アラームの設定
# （多くの場合、Service Quotasコンソール統合またはCloudFormationを介して設定）

AlarmName: LambdaConcurrencyWarning
MetricName: ConcurrentExecutions
Namespace: AWS/Lambda
Statistic: Maximum
Period: 300
Threshold: [Current Limit * 0.80] 
ComparisonOperator: GreaterThanThreshold
EvaluationPeriods: 2
TreatMissingData: notBreaching

3. 予測と計画

クォータ管理を開発マイルストーンやマーケティングキャンペーンに合わせます。大規模なスケーリングイベントや製品ローンチが予定されている場合は、必要な最大キャパシティを計算し、十分に余裕を持って増加リクエストを送信します。一部のリクエストは迅速に完了しますが、他のリクエストは人間によるレビューや追加の正当性が必要です。

効率的なサービス制限増加リクエスト手順

AWSは、Service Quotasコンソールを介して制限増加リクエストを送信することを推奨しています。これによりルーティングが自動化され、承認プロセスが加速されます。

ステップ1：Service Quotasコンソールを介した送信（推奨）

  1. AWS Service Quotasコンソールに移動します。
  2. 特定のサービス（例：「Amazon EC2」）を検索します。
  3. 関連するクォータ（例：「Running On-Demand All Standard Instances」）をクリックします。
  4. Request increaseボタンをクリックします。
  5. 新しい希望する制限とリージョンを指定します。
  6. 詳細な正当性を提供します（ステップ3を参照）。

クォータがService Quotasコンソールにリストされていない場合は、従来のAWSサポートセンターで「Service Limit Increase」ケースタイプを使用してリクエストを送信する必要があります。

ステップ2：リクエストに含める重要な情報

AWSサポートとのやり取りを防ぐために、リクエストが包括的であることを確認します：

  • AWSリージョン： 増加が必要な正確なリージョン（例：us-east-1）を指定します。
  • 特定の制限名： クォータの正確な名前を提供します（例：実行中のFargateタスクの数）。
  • 現在の制限： （オプションですが役立つ）現在達している既存の制限を確認します。
  • 要求する新しい制限： 必要な正確な最終数値を記載します（例：100から500に増加）。
  • ビジネス正当性： これが最も重要な要素です。

ステップ3：強力なビジネス正当性の作成

AWSエンジニアは、要求された制限が必要で、持続可能で、正確であるという具体的な証拠を必要とします。曖昧なリクエストは遅延または拒否されることがよくあります。

使用しないでください： 「テスト用により多くのリソースが必要です。」 使用する： 「新しいECS Fargateワークロードをサポートするために、eu-west-1で合計750のvCPU、つまり500の追加vCPUが必要です。負荷テストでは、ローンチトラフィック中に100の同時タスクのピーク需要が示されています。スケジュールされたリリースウィンドウの前にキャパシティを利用可能にする必要があります。」

正当性の構成要素 例の詳細
ユースケース 新しいアプリケーションのローンチ、クライアントのオンボーディング、季節的なプロモーション、データベースの移行。
計算の根拠 負荷テストの結果、予測されるトラフィック成長（RPS）、ユーザー数、同時実行要件。
タイムライン キャパシティが必要な時期（例：2024年11月1日までにキャパシティを運用可能にする必要があります）。
期間 これは恒久的な増加ですか、それとも一時的なスパイクですか？

高度なベストプラクティスと拒否への対応

制限を回避するためのアーキテクチャ戦略

場合によっては、制限を増やすことが正しいアプローチですが、ボトルネックがアーキテクチャの非効率性を示していることもよくあります。非常に大きな増加をリクエストする前に、次の緩和手法を検討してください：

  1. 指数バックオフとジッターの実装： 失敗したAPI呼び出しの再試行にこのパターンを使用して（特にS3やDynamoDBの制限に関連）、サービスへの過負荷を防ぎ、スロットリングの影響を最小限に抑えます。
  2. バッチ処理の最適化： サポートされている場合（例：DynamoDB BatchWriteItem）、複数の個別のAPI呼び出しを単一のバッチ操作に統合します。
  3. キャッシングの活用： ElastiCacheやCloudFrontを実装して、バックエンドサービスへのリクエスト数を減らし、RPS制限に達する可能性を低減します。

拒否されたリクエストへの対応

AWSが要求した制限を拒否または大幅に引き下げた場合、通常は正当性が不十分であるか、リクエストが安全パラメータを超えていることを意味します。

拒否へのアクションプラン：

  • すぐに再送信しないでください。 AWSサポートから提供された拒否理由を確認します。
  • 正当性を改善する： より具体的なデータポイント、内部メトリクス、およびより明確な計算方法を提供します。
  • サポートに直接連絡する： 問題が緊急または複雑な場合は、サポートケースに返信して説明を求め、アーキテクチャ要件を確認するための電話をスケジュールすることを提案します。

増加後のレビュー

制限が増加した後、新しい80%しきい値を反映するようにCloudWatchアラームを更新します。単に増加を得るだけでは終わりではありません。継続的な監視により、将来予期せず新しい制限に達することを防ぎます。

まとめ

クォータ管理は、本番キャパシティ計画の一部です。アーキテクチャが依存するクォータを追跡し、余裕がなくなる前に警告し、スケーリングレビューで使用するのと同じ証拠（現在の使用量、予想ピーク、リージョン、タイムライン、計算方法）を使用して増加をリクエストします。