AWS Well-Architected Framework 信頼性の柱 実践編 サービスクォータを管理・モニタリングする

AWS

2023.6.27

Topics

はじめに

本記事では、「AWS Well-Architected Framework 信頼性の柱」で求められるベストプラクティスを実践するための具体的なアクションをご紹介します。

ベストプラクティスを実践する手段は一つではなく、様々な方法が考えられます。
ワークロードの要件や実装にかけられる工数に応じて、適切な方法を検討する必要があります。
今回は、実装するための労力が比較的少なく、まずは簡単にベストプラクティスを取り入れてみたい方向けの方法をピックアップします。

そもそも「AWS Well-Architected Framework 信頼性の柱」とは

AWS Well-Architected Framework とは、AWS と AWS を利用するユーザーが、長年の経験から導き出したクラウドを利用する上でのベストプラクティス集です。
2023年6月現在、以下 6 つのカテゴリから構成されており、それぞれのカテゴリを「柱」と表現します。

  • 運用上の優秀性
  • セキュリティ
  • 信頼性
  • パフォーマンス効率
  • コスト最適化
  • 持続可能性

このうち「信頼性の柱」は、障害に強いワークロードのために実践すべきベストプラクティスがまとめられています。
信頼性の柱における全てのベストプラクティスは、以下のホワイトペーパーで確認することができます。

信頼性の柱 – AWS Well-Architected フレームワーク

サービスクォータとは

AWS のサービスリソースには、誤って必要以上のリソースを立ててしまったり不正使用から保護することを目的として、クォータ(制限)が設けられています。
クォータの例として、「作成できる VPC や Elastic IP アドレスは、各リージョンごとに 5 まで」といったものが挙げられます。
これらのクォータを超えてサービスリソースを利用するためには、クォータの引き上げをリクエストする必要があります。

なぜ「信頼性の柱」で問われているの?

例えば、ワークロードの負荷に合わせてリソースを増減させる Auto Scaling を導入しているケースを考えます。
負荷が高まったため Auto Scaling でリソースを増やそうとするものの、クォータに達してしまい十分にリソースを増強できなかった場合、過負荷による機能低下やシステムダウンが発生する可能性があります。
また、クォータの引き上げリクエストが承認されるまでに、数日程度時間を要するケースもあります。
リソースが必要となったタイミングで、すぐに十分な量を供給し信頼性を担保する(システムが継続可能な状態にする)ために、クォータの存在を認識し、事前に引き上げをリクエストしておくことがベストプラクティスとなっています。

サービスクォータの状態を確認するには

Trusted Advisor が便利です。「サービスの制限」を確認することで、クォータに迫っているサービスの特定に役立ちます。

また、Service Quotasというサービスで現在のクォータを確認し、引き上げをリクエストすることが可能です。
以下の公式ドキュメントでも、AWSサービスごとのクォータを確認いただけます。

サービスエンドポイントとクォータ

サービスクォータの引き上げをリクエストするには

基本的には Service Quotas を利用してリクエスト可能です。
大幅なクォータ引き上げが必要なケースなど、場合によっては AWS Support でサポートケースを起票しリクエストが必要な場合もあります。

サービスクォータの状態をモニタリングするには

CloudWatch で Service Quotas のメトリクスをモニタリングするなど、方法は幾通りか考えられます。
今回は EventBridge を使用して Trusted Advisor 「サービスの制限」の状態が「ERROR」または「WARN」に変化したことを通知させる方法をご紹介します。
なお、今回ご紹介する方法はベーシックサポートプランではご利用いただけません。

① マネジメントコンソールの右上にあるリージョンセレクターを使用して、us-east-1 (米国東部:バージニア北部) を選択します。Trusted Advisor は グローバルサービス(リージョンをまたいで機能するサービス)となるため、本設定は us-east-1 リージョンで実施する必要があります。
② Amazon SNS で SNS トピックを作成し、通知先のサブスクリプションを設定します。メールや、AWS Chatbot と連携させて Slack チャンネルに投稿するといった通知方法が可能です。
③ EventBridge のコンソール画面にて、[ルールを作成]を選択します。

④ [ルールの詳細を定義]にて、ルールの名前と説明を入力します。

⑤ [イベントパターンを構築]にて、以下のとおり設定します。

  • イベントソース:「AWS イベントまたは EventBridge パートナーイベント」
  • 作成のメソッド:「カスタムパターン (JSON エディタ)」
  • イベントパターン:以下のJSONを入力
{
  "source": ["aws.trustedadvisor"],
  "detail-type": ["Trusted Advisor Check Item Refresh Notification"],
  "detail": {
    "status": ["ERROR", "WARN"],
    "check-name": ["Auto Scaling Groups", "Auto Scaling Launch Configurations", "CloudFormation Stacks", "DynamoDB Read Capacity", "DynamoDB Write Capacity", "EBS Active Snapshots", "EBS Cold HDD (sc1) Volume Storage", "EBS General Purpose SSD (gp2) Volume Storage", "EBS General Purpose SSD (gp3) Volume Storage", "EBS Magnetic (standard) Volume Storage", "EBS Provisioned IOPS (SSD) Volume Aggregate IOPS", "EBS Provisioned IOPS SSD (io1) Volume Storage", "EBS Provisioned IOPS SSD (io2) Volume Storage", "EBS Throughput Optimized HDD (st1) Volume Storage", "EC2 On-Demand Instances", "EC2 Reserved Instance Leases", "EC2-VPC Elastic IP Address", "ELB Application Load Balancers", "ELB Network Load Balancers", "IAM Group", "ActiveMQ Availability Zone Redundancy.", "IAM Instance Profiles", "IAM Policies", "IAM Roles", "IAM Server Certificates", "IAM Users", "Kinesis Shards per Region", "RDS Cluster Parameter Groups", "RDS Cluster Roles", "RDS Clusters", "RDS DB Instances", "RDS DB Manual Snapshots", "RDS DB Parameter Groups", "RDS DB Security Groups", "RDS Event Subscriptions", "RDS Max Auths per Security Group", "RDS Option Groups", "RDS Read Replicas per Master", "RDS Reserved Instances", "RDS Subnet Groups", "RDS Subnets per Subnet Group", "RDS Total Storage Quota", "Route 53 Hosted Zones", "Route 53 Max Health Checks", "Route 53 Reusable Delegation Sets", "Route 53 Traffic Policies", "Route 53 Traffic Policy Instances", "SES Daily Sending Quota", "VPC", "VPC Internet Gateways"]
  }
}

⑥ [ターゲットを選択]にて、以下のとおり設定します。

  • ターゲットタイプ:AWS のサービス

  • ターゲットを選択:SNS トピック

  • トピック:② で作成した SNS トピックを選択

⑦ 任意でタグを設定し、[ルールの作成]を行います。

Trusted Advisor 「サービスの制限」の状態が「ERROR」または「WARN」となると、以下のような通知が来ます。こちらは AWS Chatbot と連携させて Slack チャンネルに投稿した場合の例となります。

通知を受信しましたら Trusted Advisor を確認し、Service Quotas からクォータの引き上げをリクエストしてください。
なお、本設定では、以下のサービスクォータが検知可能です。

検知可能なサービスクォータ一覧
  • Auto Scaling Groups
  • Auto Scaling Launch Configurations
  • CloudFormation Stacks
  • DynamoDB Read Capacity
  • DynamoDB Write Capacity
  • EBS Active Snapshots
  • EBS Cold HDD (sc1) Volume Storage
  • EBS General Purpose SSD (gp2) Volume Storage
  • EBS General Purpose SSD (gp3) Volume Storage
  • EBS Magnetic (standard) Volume Storage
  • EBS Provisioned IOPS (SSD) Volume Aggregate IOPS
  • EBS Provisioned IOPS SSD (io1) Volume Storage
  • EBS Provisioned IOPS SSD (io2) Volume Storage
  • EBS Throughput Optimized HDD (st1) Volume Storage
  • EC2 On-Demand Instances
  • EC2 Reserved Instance Leases
  • EC2-VPC Elastic IP Address
  • ELB Application Load Balancers
  • ELB Network Load Balancers
  • IAM Group
  • ActiveMQ Availability Zone Redundancy.
  • IAM Instance Profiles
  • IAM Policies
  • IAM Roles
  • IAM Server Certificates
  • IAM Users
  • Kinesis Shards per Region
  • RDS Cluster Parameter Groups
  • RDS Cluster Roles
  • RDS Clusters
  • RDS DB Instances
  • RDS DB Manual Snapshots
  • RDS DB Parameter Groups
  • RDS DB Security Groups
  • RDS Event Subscriptions
  • RDS Max Auths per Security Group
  • RDS Option Groups
  • RDS Read Replicas per Master
  • RDS Reserved Instances
  • RDS Subnet Groups
  • RDS Subnets per Subnet Group
  • RDS Total Storage Quota
  • Route 53 Hosted Zones
  • Route 53 Max Health Checks
  • Route 53 Reusable Delegation Sets
  • Route 53 Traffic Policies
  • Route 53 Traffic Policy Instances
  • SES Daily Sending Quota
  • VPC
  • VPC Internet Gateways

簡易なモニタリングではありますが、まずは気がつける仕組みを整えることが大切です。
できるところからベストプラクティスを実践していきましょう!

GENSAI

2014年入社。 関東近郊の山と銭湯と飲み屋を巡り歩いてます。

Recommends

こちらもおすすめ

Special Topics

注目記事はこちら