# REL 7 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか? スケーラブルなワークロードには、リソースを自動で追加または削除する伸縮性があるので、リソースは常に、現行の需要に厳密に適合します。 **Topics** + [REL07-BP01 リソースの取得またはスケーリング時に自動化を使用する](rel_adapt_to_changes_autoscale_adapt.md) + [REL07-BP02 ワークロードの障害を検出したときにリソースを取得する](rel_adapt_to_changes_reactive_adapt_auto.md) + [REL07-BP03 ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得する](rel_adapt_to_changes_proactive_adapt_auto.md) + [REL07-BP04 ワークロードの負荷テストを実施する](rel_adapt_to_changes_load_tested_adapt.md) # REL07-BP01 リソースの取得またはスケーリング時に自動化を使用する 障害のあるリソースを交換したり、ワークロードをスケーリングしたりする場合は、Amazon S3 や AWS Auto Scaling などのマネージド型の AWS のサービスを使用してプロセスを自動化します。サードパーティのツールや AWS SDK を使用して、スケーリングを自動化することもできます。 マネージド型の AWS のサービスとしては、Amazon S3、Amazon CloudFront、AWS Auto Scaling、AWS Lambda、Amazon DynamoDB、AWS Fargate、および Amazon Route 53 があります。 AWS Auto Scaling では、障害のあるインスタンスを検出して置き換えることができます。また、以下を含むリソースのスケーリングプランを構築することもできます。 [Amazon EC2](https://aws.amazon.com/ec2/) インスタンスとスポットフリート、 [Amazon ECS](https://aws.amazon.com/ecs/) タスク、 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) テーブルとインデックス、および [Amazon Aurora](https://aws.amazon.com/aurora/) レプリカ。 EC2 インスタンスをスケーリングする場合は、複数のアベイラビリティゾーン (できれば少なくとも 3 つ) を使用し、容量を追加または削除して、これらのアベイラビリティゾーン間のバランスを維持します。ECS タスクまたは Kubernetes ポッド (Amazon Elastic Kubernetes Service を使用しているとき) も複数のアベイラビリティゾーンに分散してください。 AWS Lambda を使用しているときには、インスタンスは自動的にスケーリングされます。AWS Lambda は、関数のイベント通知を受信するたびに、コンピューティングフリート内の空き容量をすばやく見つけ、割り当てられた同時実行数までコードを実行します。特定の Lambda とService Quotas で、必要な同時実行数が確実に設定されているようにしてください。 Amazon S3 は、高いリクエスト頻度を処理できるように自動的にスケーリングします。たとえば、アプリケーションはバケット内のプレフィックスごとに 1 秒あたり 3,500 件以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 件以上の GET/HEAD リクエストを送信できます。バケット内のプレフィックス数に制限はありません。読み取りを並列化することで、読み取りまたは書き込みのパフォーマンスを向上させることができます。例えば、Amazon S3 バケットに 10 個のプレフィックスを作成して読み取りを並列化する場合、読み取りパフォーマンスを 1 秒あたり 55,000 件の読み取りリクエストにスケーリングできます。 Amazon CloudFront または信頼できるコンテンツ配信ネットワーク (CDN) を設定して使用します。CDN は、より迅速なエンドユーザーレスポンスタイムを提供でき、コンテンツのリクエストをキャッシュから処理できるため、ワークロードをスケーリングする必要性が少なくなります。 **一般的なアンチパターン:** + 自動ヒーリングのために Auto Scaling グループを実装しますが、伸縮性は実装しません。 + トラフィックの大幅な増加に対応するために自動スケーリングを使用する。 + ステートフル性が高いアプリケーションをデプロイし、伸縮性を排除する。 **このベストプラクティスを活用するメリット:** 自動化により、リソースのデプロイと廃棄で手動エラーが発生する可能性がなくなります。自動化は、デプロイや廃棄のニーズへの応答が遅いことによるコストの超過やサービス拒否のリスクを排除します。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス + AWS Auto Scaling を設定して使用します。これにより、アプリケーションをモニタリングし、安定した予測可能なパフォーマンスを可能な限り低いコストで維持するためのキャパシティーを自動的に調整します。AWS Auto Scaling を使用すると、複数のサービスにまたがる複数のリソースに対してアプリケーションのスケーリングをセットアップできます。 + [「AWS Auto Scaling とは何ですか?」](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) + Amazon EC2 インスタンスとスポットフリート、Amazon ECS タスク、Amazon DynamoDB のテーブルとインデックス、Amazon Aurora のレプリカ、および AWS Marketplace アプライアンスなど、該当する者に対して Auto Scaling を設定します。 + [DynamoDB Auto Scaling によるスループットキャパシティの自動管理](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + サービス API を操作して、アラーム、スケーリングポリシー、ウォームアップ時間、およびクールダウン時間を指定します。 + Elastic Load Balancing を使用します。ロードバランサーは、パスまたはネットワーク接続ごとに負荷を分散することができます。 + [「Elastic Load Balancing とは何ですか?」](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) + Application Load Balancers は、負荷をパスごとに分散できます。 + [Application Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) + Application Load Balancer を設定して、ドメイン名の下のパスに基づいてトラフィックをさまざまなワークロードに分散します。 + Application Load Balancers を使用すると、AWS Auto Scaling と統合して需要を管理するという方法で負荷を分散できます。 + [Auto Scaling グループでロードバランサーを使用する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) + Network Load Balancers は、接続ごとに負荷を分散することができます。 + [Network Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) + Network Load Balancer は、TCP を使用してトラフィックをさまざまなワークロードに分散するか、ワークロードの IP アドレスの一定のセットが含まれるように設定します。 + Network Load Balancer を使用すると、AWS Auto Scaling と統合して需要を管理するという方法で負荷を分散できます。 + 可用性の高い DNS プロバイダーを使用します。DNS 名により、ユーザーは、IP アドレスの代わりに DNS 名を入力してワークロードにアクセスでき、この情報を、定義されたスコープ (通常はワークロードのユーザーに対してグローバルに定義されたスコープ) に分散できます。 + Amazon Route 53 または信頼できる DNS プロバイダーを使用します。 + [「Amazon Route 53 とは何ですか?」](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + Route 53 を使用して、CloudFront ディストリビューションとロードバランサーを管理します。 + 管理する予定のドメインとサブドメインを決定します。 + ALIAS レコードまたは CNAME レコードを使用して適切なレコードセットを作成します。 + [レコードの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) + AWS グローバルネットワークを使用して、ユーザーからアプリケーションへのパスを最適化します。AWS Global Accelerator は、アプリケーションエンドポイントの状態を継続的にモニタリングし、トラフィックを 30 秒未満で正常なエンドポイントにリダイレクトします。 + AWS Global Accelerator は、ローカルまたはグローバルユーザーが使用するアプリケーションの可用性とパフォーマンスを向上させるサービスです。Application Load Balancers、Network Load Balancer、Amazon EC2 インスタンスなど、単一または複数の AWS リージョンのアプリケーションエンドポイントへの固定エントリポイントとして機能する静的 IP アドレスが提供されます。 + [AWS Global Accelerator とは?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) + Amazon CloudFront または信頼できるコンテンツ配信ネットワーク (CDN) を設定して使用します。コンテンツ配信ネットワークは、エンドユーザーの応答時間を短縮し、ワークロードの不要なスケーリングを引き起こす原因となるコンテンツのリクエストを処理できます。 + [「Amazon CloudFront とは」](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) + ワークロード用の Amazon CloudFront ディストリビューションを設定するか、サードパーティの CDN を使用します。 + エンドポイントセキュリティグループまたはアクセスポリシーで CloudFront の IP 範囲を使用することで、ワークロードへのアクセスを CloudFront からのみに制限できます。 ## リソース **関連するドキュメント:** + [APN Partner: partners that can help you create automated compute solutions](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) + [AWS Auto Scaling: スケーリングプランの仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [AWS Marketplace: Auto Scaling で使用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) + [Managing Throughput Capacity Automatically with DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [Auto Scaling グループでロードバランサーを使用する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) + [AWS Global Accelerator とは?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) + [「What Is Amazon EC2 Auto Scaling?」](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + [「AWS Auto Scaling とは何ですか?」](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) + [「Amazon CloudFront とは」](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected) + [「Amazon Route 53 とは何ですか?」](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) + [「Elastic Load Balancing とは何ですか?」](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) + [Network Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) + [Application Load Balancer とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) + [レコードの操作](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) # REL07-BP02 ワークロードの障害を検出したときにリソースを取得する 可用性が影響を受ける場合、必要に応じてリソースをリアクティブにスケールし、ワークロードの可用性を復元します。 まず、ヘルスチェックとこのチェックの基準を設定して、リソースの不足が可用性に影響を与えるタイミングを示す必要があります。次に、適切な担当者に通知してリソースを手動でスケーリングするか、自動操作をトリガーしてリソースを自動的にスケーリングします。 スケーリングはワークロードに合わせて手動で調整できます。例えば、Auto Scaling グループの EC2 インスタンスの数の変更や、DynamoDB テーブルのスループットの変更は、AWS マネジメントコンソール または AWS CLI で行うことができます。ただし、可能な限りオートメーションを使用する必要があります (詳細は **リソースの取得またはスケーリング時に自動化を使用する**) を指定する必要があります。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + ワークロードの障害を検出したときにリソースを取得します。可用性が影響を受ける場合、必要に応じてリソースをリアクティブにスケールし、ワークロードの可用性を復元します。 + AWS Auto Scaling のコアコンポーネントであるスケーリングプランを使用して、リソースをスケーリングするための一連の指示を設定します。AWS CloudFormation を操作する場合や、タグを AWS リソースに追加する場合、アプリケーションごとに、さまざまなリソースセットのスケーリングプランをセットアップできます。AWS Auto Scaling は各リソースに応じてカスタマイズされたスケーリング戦略についてレコメンデーションを提供します。スケーリングプランを作成すると、AWS Auto Scaling は、動的スケーリングと予測スケーリング方法を組み合わせて、スケーリング戦略をサポートします。 + [AWS Auto Scaling: スケーリングプランの仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + Amazon EC2 Auto Scaling を使用すると、アプリケーションの負荷を処理するための正しい数の Amazon EC2 インスタンスを利用できます。Auto Scaling グループと呼ばれる EC2 インスタンスのコレクションを作成します。各 Auto Scaling グループのインスタンスの最小数を指定でき、Amazon EC2 Auto Scaling では、グループがこのサイズを下回ることはありません。各 Auto Scaling グループのインスタンスの最小数を指定でき、Amazon EC2 Auto Scaling では、グループがこのサイズを上回ることはありません。 + [「What Is Amazon EC2 Auto Scaling?」](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) + Amazon DynamoDB Auto Scaling は、AWS Application Auto Scaling サービスを使用して、実際のトラフィックパターンに応じて、お客様に代わってプロビジョニングされたスループットキャパシティを動的に調整します。これにより、テーブルまたはグローバルセカンダリインデックスは、プロビジョニングされた読み込みおよび書き込みキャパシティーを増やすことができ、スロットリングなしでトラフィックの急激な増加を処理できます。 + [Managing Throughput Capacity Automatically with DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) ## リソース **関連するドキュメント:** + [APN Partner: partners that can help you create automated compute solutions](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) + [AWS Auto Scaling: スケーリングプランの仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [AWS Marketplace: Auto Scaling で使用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) + [Managing Throughput Capacity Automatically with DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [「What Is Amazon EC2 Auto Scaling?」](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) # REL07-BP03 ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得する 需要に合わせてリソースをプロアクティブにスケールし、可用性への影響を回避します。 多くの AWS サービスは、需要に合わせて自動的にスケールします。Amazon EC2 インスタンスまたは Amazon ECS クラスターを使用している場合、ワークロードの需要に対応する使用状況のメトリクスに基づいて Auto Scaling を実行するように設定できます。Amazon EC2 では、平均 CPU 使用率、ロードバランサーリクエスト数、またはネットワーク帯域幅を使用して、EC2 インスタンスをスケールアウト (またはスケールイン) できます。Amazon ECS では、平均 CPU 使用率、ロードバランサーリクエスト数、およびメモリ使用率を使用して、ECS タスクをスケールアウト (またはスケールイン) できます。AWS で Target Auto Scaling を使用すると、オートスケーラーは家庭用サーモスタットのように機能し、指定したターゲット値 (例えば、CPU 使用率 70%) を維持するためにリソースを追加または削除します。 AWS Auto Scaling はまた、 [Predictive Auto Scaling ](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)も実行できます。これは、機械学習を使用して各リソースの過去のワークロードを分析し、次の 2 日間の負荷を定期的に予測します。 リトルの法則は、必要なコンピューティングインスタンス (EC2 インスタンス、同時実行の Lambda 関数など) 数を計算するのに役立ちます。 *L* = *λW* L = インスタンス数 (またはシステムの平均同時実行数) λ = リクエストが到着する平均レート (リクエスト/秒) W = 各リクエストがシステムで費やす平均時間 (秒) 例えば、100 rps では、各リクエストの処理に 0.5 秒かかる場合、需要に対応するには 50 インスタンスが必要です。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + ワークロードにより多くのリソースが必要であることを検出した時点でリソースを取得します。需要に合わせてリソースをプロアクティブにスケールし、可用性への影響を回避します。 + 特定のリクエストレートを処理するために必要なコンピューティングリソースの数 (コンピューティングの同時実行) を計算します。 + [リトルの法則について語る](https://brooker.co.za/blog/2018/06/20/littles-law.html) + 使用状況の履歴パターンがあるときには、Amazon EC2 Auto Scaling のスケジュールされたスケーリングをセットアップします。 + [Amazon EC2 Auto Scaling のスケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) + AWS 予測スケーリングを使用します。 + [機械学習を利用した EC2 の予測スケーリング](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) ## リソース **関連するドキュメント:** + [AWS Auto Scaling: スケーリングプランの仕組み](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) + [AWS Marketplace: Auto Scaling で使用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) + [Managing Throughput Capacity Automatically with DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) + [機械学習を利用した EC2 の予測スケーリング](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) + [Amazon EC2 Auto Scaling のスケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) + [リトルの法則について語る](https://brooker.co.za/blog/2018/06/20/littles-law.html) + [「What Is Amazon EC2 Auto Scaling?」](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) # REL07-BP04 ワークロードの負荷テストを実施する 負荷テスト手法を採用して、スケーリングアクティビティがワークロード要件を満たすかどうかを測定します。 持続的な負荷テストを実行することが重要です。負荷テストによって、ブレークポイントを発見し、ワークロードのパフォーマンスをテストします。AWS は、生産ワークロードのスケールをモデル化する一次的なテスト環境のセットアップを容易にします。クラウド上では、本稼働スケールのテスト環境をオンデマンドで作成し、テスト完了後にリソースを解放できます。テスト環境の⽀払いは実⾏時にのみ発⽣するため、オンプレミスでテストを実施する場合と比べてわずかなコストで、本番環境をシミュレートできます。 本番環境での負荷テストは、ゲームデーの一部として考える必要もあります。その中で、顧客の使用率が低い時間帯に本番システムに負荷をかけ、担当者全員がテスト結果を解釈して発生した問題に対処できるようにします。 **一般的なアンチパターン:** + 本稼働環境と同じ設定ではないデプロイで負荷テストを実行する。 + ワークロード全体ではなく、ワークロードの個々の部分に対してのみ負荷テストを実行する。 + 実際のリクエストの代表的なセットではなく、リクエストのサブセットを使用して負荷テストを実行する。 + 予想される負荷を超える小さな安全率に対して負荷テストを実行する。 **このベストプラクティスを活用するメリット:** 負荷がかかっているときにアーキテクチャのどのコンポーネントが失敗するかを把握し、問題に対処すべく、その負荷が近づいていることを示すために監視するメトリクスを特定し、その障害の影響を防ぐことができます。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 負荷テストを実行して、キャパシティを追加または削除する必要があるワークロードの側面を特定します。負荷テストには、本稼働環境で受け取るものと同様の代表的なトラフィックを用いる必要があります。設定したメトリクスを監視しながら負荷を増やし、リソースを追加または削除する必要があるタイミングをどのメトリクスが示唆しているのかを判断します。 + [AWS での分散負荷テスト: 接続された数千のユーザーをシミュレートする](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) + リクエストの組み合わせを特定します。なされるリクエストの組み合わせはさまざまであるため、トラフィックの混在を組み合わせを特定する際は、さまざまな時間枠を確認する必要があります。 + ロードドライバーを実装します。カスタムコード、オープンソース、または商用ソフトウェアを使用して、ロードドライバーを実装できます。 + 最初は小さなキャパシティを使用して負荷テストを実施します。1 つのインスタンスまたはコンテナと同じくらいの少なさのキャパシティーに負荷をかけることで、すぐに効果が現れます。 + 大きなキャパシティに対して負荷テストを実施します。この効果は分散された負荷によって異なるため、できるだけ製品環境に近いに対してテストする必要があります。 ## リソース **関連するドキュメント:** + [AWS での分散負荷テスト: 接続された数千のユーザーをシミュレートする](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)