# SUS02-BP01 ワークロードインフラストラクチャを動的にスケールする
クラウドの伸縮性を利用してインフラストラクチャを動的にスケールすることにより、需要に合わせてクラウドリソースを供給し、ワークロード容量の過剰なプロビジョニングを回避します。
**一般的なアンチパターン:**
+ ユーザーの負荷に合わせてインフラストラクチャをスケールしない。
+ 常に手動でインフラストラクチャをスケールする。
+ スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティーを増加させたままにする。
**このベストプラクティスを確立するメリット:** ワークロードの伸縮性を設定およびテストすることで、クラウドリソースの供給を需要に効率的に一致させ、容量の過剰なプロビジョニングを回避できます。クラウドの伸縮性を利用して、需要の急増時や急増後に容量を自動的にスケールすることにより、ビジネス要件を満たすために必要となる適切な数のリソースのみを運用できます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を提供します。最適な形で需要と供給を一致させることで、ワークロードに対する環境の影響を最小限に抑えることができます。
需要が一定の場合も変動する場合もあり、管理面の負担を回避するには、メトリクスと自動化が必要になります。アプリケーションのスケールは、インスタンスのサイズを変更して垂直方向 (スケールアップ/スケールダウン)、インスタンス数を変更して水平方向 (スケールイン/スケールアウト)、あるいはこれらの組み合わせで調整できます。
リソースの需要と供給は、さまざまなアプローチで一致させることができます。
+ **ターゲット追跡アプローチ:** スケーリングメトリクスを監視し、必要に応じて容量を自動的に増減します。
+ **予測スケーリング:** 日単位および週単位の傾向を見越してスケールします。
+ **スケジュールベースのアプローチ:** 予測できる負荷の変化に従って、独自のスケーリングスケジュールを設定します。
+ **サービススケーリング:** 設計によってネイティブにスケールされるか、機能として自動スケーリングを提供するサービス (サーバーレスなど) を選択します。
使用率が低い、または使用されていない期間を特定し、リソースをスケールして余分な容量を排除し効率性を改善します。
## 実装手順
+ 伸縮性は、持っているリソースの供給を、それらのリソースに対する需要と一致させます。インスタンス、コンテナ、機能には、伸縮性のためのメカニズムがあり、自動スケーリングと組み合わせて、またはサービスの機能として提供されます。AWS では、ユーザー負荷が低い期間には迅速かつ簡単にワークロードをスケールダウンできるように、幅広い自動スケーリングメカニズムを提供しています。自動スケーリングメカニズムの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_user_a2.html)
+ スケーリングに関する議論は、Amazon EC2 インスタンスや AWS Lambda 関数などのコンピューティングサービスに関連していることが一般的です。需要に合わせて、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/) の読み取り/書き込みキャパシティユニットや [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) シャードなどの非コンピューティングサービスに関する設定も検討してみてください。
+ スケールアップまたはスケールダウンのメトリクスが、デプロイされているワークロードのタイプに対して検証されていることを確認します。動画トランスコーディングアプリケーションをデプロイしようとする場合、100% の CPU 使用率が想定されるため、プライマリメトリクスにするべきではありません。必要に応じて、[カスタマイズされたメトリクス](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (メモリ使用率など) をスケーリングポリシーに使用することもできます。適切なメトリクスを選ぶには、Amazon EC2 の以下のガイダンスを考慮してください。
+ メトリクスは有効な利用率メトリクスでなければならず、インスタンスのどの程度ビジーかを記述する必要があります。
+ メトリクス値は、Auto Scaling グループ内のインスタンス数に比例して増減する必要があります。
+ Auto Scaling グループの[手動スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html)ではなく、[動的スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html)を使用します。また、動的スケーリングで[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)を使用することをお勧めします。
+ スケールアウトとスケールインの両方のイベントに対処できるようにワークロードをデプロイします。スケールインイベントのテストシナリオを作成して、ワークロードが期待どおりに動作し、ユーザーエクスペリエンスに影響しない (スティッキーセッションが失われない) ことを確認します。[アクティビティ履歴](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)を使用すると、Auto Scaling グループのスケーリングアクティビティを検証できます。
+ ワークロードを評価して予測可能なパターンを見つけ、あらかじめわかっていた、および計画的な需要の変化を予測してプロアクティブにスケールします。予測スケーリングを使用すると、容量を過剰にプロビジョニングする必要がなくなります。詳細については、[Amazon EC2 Auto Scaling を使用した予測スケーリングに関するブログ](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)を参照してください。
## リソース
**関連するドキュメント:**
+ [Amazon EC2 Auto Scaling の使用を開始する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [機械学習を利用した EC2 の予測スケーリング](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Amazon OpenSearch Service、Amazon Data Firehose、および Kibana を使用してユーザーの行動を分析する](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Amazon EC2 Auto Scaling での予測スケーリングのネイティブサポートの概要](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Karpenter の概要 - オープンソースの高性能 Kubermetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
+ [Amazon ECS クラスター Auto Scaling の詳細](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
**関連動画:**
+ [Build a cost-, energy-, and resource-efficient compute environment](https://www.youtube.com/watch?v=8zsC5e1eLCg) (コスト面、エネルギー面、リソース面で効率的なコンピューティング環境の構築)
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) (より良く、より速く、より安価なコンピューティング: Amazon EC2 でのコストの最適化 (CMP202-R1))
**関連する例:**
+ [ラボ: Amazon EC2 Auto Scaling グループの例](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)
+ [ラボ: Karpenter による自動スケーリングの実装](https://www.eksworkshop.com/beginner/085_scaling_karpenter/)