AWSサービス制限への対応：予防、監視、解決戦略

AWSは急速にスケールできますが、アカウントには依然としてクォータがあります。デプロイメントが突然EC2キャパシティを作成できなくなったり、IPを追加できなくなったり、Lambdaの同時実行数を増やせなくなったりした場合、アプリケーションのバグではなく、AWSサービスクォータに達している可能性があります。

クォータをアーキテクチャの一部として扱ってください。クォータはサービス、アカウント、リージョンによって異なり、増加できるものもあれば、設計変更が必要なものもあります。

AWSサービス制限について

AWSサービスクォータは、アカウント内のリソースまたは操作に対する制限です。これらは、AWSサービスと顧客アカウントを暴走使用から保護するのに役立ちますが、計画を立てていない場合、正当な成長を妨げる可能性もあります。

調整可能なクォータと固定クォータ

AWSサービス制限には主に2つのタイプがあることを区別することが重要です。

調整可能なクォータ： これらは多くの場合、Service QuotasコンソールまたはAWSサポートケースを通じて増加できます。
固定クォータ： これらはアカウントで増やすことができません。これらを回避するために再設計するか、ワークロードを分割するか、別のサービスパターンを使用する必要があります。

サービス制限が重要な理由

クォータを超えると、通常、リソース作成の失敗、APIコールのスロットリング、または予想よりも早くスケーリングが停止するという形で現れます。たとえば、Auto Scalingグループは正常でも、そのリージョンでアカウントに十分なEC2 vCPUクォータがない場合、インスタンスを起動できません。

AWSサービス制限のプロアクティブな監視

クォータの問題を見つける最適なタイミングは、リリースやトラフィックイベントの前です。AWSは、クォータ値を確認する方法と、一部のサービスでは現在の使用状況を確認する方法をいくつか提供しています。

AWS Trusted Advisor

AWS Trusted Advisorは、使用量が制限に近い一部のサービスクォータをフラグ付けできます。可用性と詳細はサポートプランとサービスによって異なるため、唯一の情報源としてではなく、有用なシグナルとして使用してください。

AWS Service Quotasコンソール

AWS Service Quotasは、多くのアカウントクォータを表示し、調整可能なクォータの増加をリクエストするための主要な場所です。

Service Quotasコンソールの使用：

AWSアカウントでService Quotasコンソールに移動します。
特定のサービス（例：「EC2」、「RDS」、「S3」）を検索できます。
多くのクォータについて、適用値、デフォルト値、調整可能かどうか、場合によっては使用率を確認できます。
調整可能なクォータの場合は、クォータ詳細ページから直接増加をリクエストします。

例：特定のリージョンでのEC2 vCPU制限を確認するには：

Service Quotasに移動します。
サービスリストから「EC2」を選択します。
関連する実行中のオンデマンドvCPUクォータ（標準インスタンスファミリーのクォータなど）を探します。
コンソールに現在の使用量と最大制限が表示されます。

CloudWatchアラーム

一部のクォータでは、Service Quotasが使用状況メトリクスをCloudWatchに公開します。他のサービスでは、サービス固有のメトリクスまたはカスタムインベントリジョブが必要になる場合があります。たとえば、Lambdaには、スロットリングがリクエストに影響を与える前に警告できる同時実行メトリクスがあります。

AWS CLIチェック

デプロイメントパイプラインでクォータチェックをスクリプト化できます。

aws service-quotas list-service-quotas --service-code ec2 --region us-east-1

本番ロールアウトの場合は、Terraform、CloudFormation、またはCDKがリソースの作成を試みる前に、予想されるリソース増加を適用済みクォータと比較してください。

サービス制限管理の戦略

制限を監視する方法を理解したら、それらを効果的に管理するための戦略を実装できます。

1. アプリケーションのニーズを理解する

アプリケーションをデプロイまたはスケーリングする前に、そのリソース要件を分析します。これには以下が含まれます。

ピーク負荷の考慮事項： 予想される最大同時ユーザー数またはリクエストレートは？
リソースタイプ： 使用される特定のAWSサービスとリソースタイプ（例：EC2インスタンスタイプ、RDSデータベースサイズ、Lambda同時実行数）は？
リージョン分散： リソースはどこにデプロイされますか？

この分析は、どの制限に遭遇する可能性が高いかを予測するのに役立ちます。

2. スケーラビリティと弾力性を考慮した設計

垂直スケーリング（より大きなインスタンス/ユニット）のみに依存するのではなく、水平スケーリング（より多くのインスタンス/ユニットを追加）できるようにアプリケーションを構築します。このアプローチは負荷を分散し、単一リソースの制限に達するリスクを軽減します。

Auto Scalingグループ： 需要の変化に応じてEC2 Auto Scalingを使用しますが、アカウントに最大キャパシティに十分なvCPUクォータがあることを確認します。
サーバーレスアーキテクチャ： LambdaとAPI Gatewayはサーバー管理を排除しますが、同時実行数、ペイロード、タイムアウト、リクエストクォータは依然として存在します。

3. リソース使用量の最適化

デプロイされたリソースを定期的にレビューして、効率的に使用されていることを確認します。未使用のインスタンスをシャットダウンし、データベースのサイズを適正化し、未接続のEBSボリュームを削除します。

タグ付け： リソースに堅牢なタグ付け戦略を実装します。これにより、所有権、コスト、使用状況の追跡が容易になり、十分に活用されていないリソースを特定するのに役立ちます。
コストと使用状況レポート： AWS Cost and Usage Reportsを分析して、プロビジョニング過剰の可能性がある領域を特定します。

4. プロアクティブに制限増加をリクエストする

制限に達してから増加をリクエストするのではなく、事前に行ってください。アプリケーションの予想される成長や計画されたイベント（マーケティングキャンペーンや製品ローンチなど）がソフト制限を超える可能性を示している場合は、事前にリクエストを送信します。

制限増加のリクエスト方法：

AWS Service Quotasコンソールに移動します。
増加が必要な特定のサービスとクォータに移動します。
クォータを選択し、**「クォータ増加のリクエスト」**ボタンをクリックします。
リクエストフォームに詳細情報を提供します。
- 新しいクォータ値： 希望する制限。
- リクエストの理由： なぜ増加が必要かを説明します。ユースケース、予想使用量、期間について具体的に記述します。
- AWSリージョン： 増加が必要なリージョンを指定します。
リクエストを送信します。

AWSは一部のリクエストを迅速に承認する場合がありますが、他のリクエストはレビューが必要で、時間がかかる場合があります。特にローンチ、移行、負荷テストの場合は、必要になる前に増加をリクエストしてください。

増加リクエストのヒント：

正確に： 正確なクォータと必要な正確な数を記載します。
必要性を正当化する： データ（予想使用量、現在の使用率）を用いた十分な理由のある説明は、承認の可能性を大幅に向上させます。
事前にリクエストする： レビューと承認後のチームのテストに十分な時間を確保します。

5. ハード制限を理解する

固定クォータの場合は、それらを回避するようにアーキテクチャを設計します。一般的なオプションには、複数のアカウントへのワークロード分散、複数のリージョンの使用、作業のキューイング、APIコールのバッチ処理、またはより適切なサービスの選択が含まれます。

一般的なAWSサービス制限とその管理方法

よく遭遇するサービス制限と管理戦略をいくつか見てみましょう。

Amazon EC2

クォータ： インスタンスファミリー別の実行中のオンデマンドvCPU、Elastic IPアドレス、EBSボリューム、EBS IOPS、VPC、サブネット、セキュリティグループ、ネットワークインターフェイス。
管理： リージョンごとのvCPU使用量を監視し、スケーリングイベントの前に増加をリクエストし、未使用のElastic IPとボリュームを削除します。

Amazon S3

クォータ： S3には、アカウントあたりのバケット制限などのサービスクォータがあり、高スループットワークロードのためのプレフィックスあたりのリクエストレートガイダンスが文書化されています。
管理： 非常に高いリクエストレートには複数のプレフィックスを使用し、読み取りが多いパブリックコンテンツにはCloudFrontを使用し、可視性のためにS3メトリクスを使用します。

Amazon RDS

クォータ： DBインスタンス、クラスター、スナップショット、ストレージ、パラメータグループには、アカウントまたはリージョンのクォータがあります。接続制限はエンジンとインスタンスクラスに大きく依存します。
管理： インスタンスのサイズを適正化し、読み取りが多いワークロードにはリードレプリカを使用し、移行や環境拡張の前にクォータ増加をリクエストします。

AWS Lambda

クォータ： アカウントの同時実行数、予約済み同時実行数、プロビジョニングされた同時実行数、ペイロードサイズ、タイムアウト、メモリ、デプロイメントパッケージの制限。
管理： 同時実行数とスロットルを監視し、重要な機能には予約済み同時実行数を設定し、トラフィック急増の前にアカウントの同時実行数増加をリクエストします。

サービス制限超過エラーの解決

「Service Limit Exceeded」エラーが発生した場合：

特定のサービスと制限を特定します： エラーメッセージは通常、この情報を提供します。
現在の使用状況を確認します： Service QuotasコンソールまたはTrusted Advisorを使用して、制限に対する使用状況を確認します。
調整可能か固定かを判断します： 調整可能な場合は、増加をリクエストします。
制限増加リクエストを送信します： 「プロアクティブに制限増加をリクエストする」セクションで概説した手順に従います。詳細情報を提供できるように準備してください。
固定クォータの場合： ソリューションを再設計します。以下を検討します。
- 複数のAWSアカウントにワークロードを分散する。
- 同じハード制限がない可能性のある別のAWSサービスを使用する。
- 制限を超える操作を処理するためのキューイングシステムまたはバッチ処理を実装する。

まとめ

主要なローンチや移行の前に、スケールするサービスのクォータを確認してください。調整可能なクォータの増加を早期にリクエストし、重要な制限にアラームを追加し、固定クォータの再設計パスを文書化してください。クォータ作業は、早期に行えば静かですが、障害中に発見されると苦痛を伴います。