525-AWS SAP AWS 「理論・実践・一問道場」Auto Scaling

type

status

date

slug

summary

理論

AWSにおけるスケーラブルなアーキテクチャ設計とコスト効率の最適化

AWSでは、アプリケーションがスムーズに運用されるように、リソースのスケーラビリティとコスト効率を確保するためのさまざまな方法があります。特に、EC2インスタンスや負荷分散のリソースを適切にスケールさせることは、アプリケーションのパフォーマンス向上とコスト削減に重要です。

1. Auto ScalingとElastic Load Balancing (ELB)

Auto Scalingは、アプリケーションの負荷に応じてEC2インスタンスの数を自動的に増減させる仕組みです。これにより、トラフィックが増加しても、アプリケーションがスムーズにスケールアウトして、過剰にリソースを消費せずに効率的に処理できます。逆に、負荷が低くなると、リソースを自動で縮小し、コストを削減します。

*Elastic Load Balancer (ELB)**は、トラフィックを複数のインスタンスに分散させ、アプリケーションのパフォーマンスを向上させます。ネットワークロードバランサー（NLB）やアプリケーションロードバランサー（ALB）がよく使用され、適切な選択はアプリケーションの特性に応じて異なります。

2. EC2インスタンスの購入オプション

オンデマンドインスタンス: 必要なときにリソースを即座に使用できる柔軟な方法ですが、コストが高くなる可能性があります。

リザーブドインスタンス: 長期間（1年または3年）にわたって使用する予定のインスタンスに対して、事前に予約することで割引を受けられるオプションです。安定した使用が見込まれるリソースに最適です。

スポットインスタンス: 需要が低い時に、未使用のEC2インスタンスを割安な価格で購入できるオプションです。ただし、インスタンスが中断される可能性があるため、可用性が高いことが求められない場合に適しています。

3. Auto Scalingの設定

Auto Scalingグループを適切に設定することで、アプリケーションのリソースのスケーリングを効率的に管理できます。例えば、最小容量を低めに設定し、最大容量を高めに設定することで、通常の負荷に合わせてリソースを抑え、ピーク時に必要なインスタンス数を自動で増やすことができます。これにより、スケーラビリティを確保しつつ、無駄なコストを削減できます。

4. 価格最適化のための戦略

リザーブドインスタンスの活用: 長期間にわたって稼働する予定のアプリケーションに対しては、リザーブドインスタンスを利用することでコストを削減できます。定期的な使用が予測されるリソースには特に有効です。

スポットインスタンスの活用: 高度なスケーラビリティを必要とする一時的なタスクやワークロードには、スポットインスタンスを活用することでコストを削減できます。中断される可能性があるため、安定した稼働が必要な場合には適さないことを留意する必要があります。

5. パフォーマンスとコストのバランス

AWSでは、パフォーマンスとコストの最適化をバランスよく実現するために、さまざまなリソースとサービスを活用することが重要です。Auto Scalingや負荷分散の技術を組み合わせることで、トラフィックの増加に応じて適切にリソースを追加し、ピーク時でもパフォーマンスを維持しながらコストを最適化できます。

まとめ

AWSでのアーキテクチャ設計では、スケーラビリティとコスト効率の最適化が鍵となります。Auto ScalingやElastic Load Balancer、インスタンスの購入オプションを適切に活用することで、アプリケーションのパフォーマンスを維持しつつ、運用コストを最小限に抑えることができます。

実践

略

一問道場

質問 #525

ある企業がAWS上でプロジェクト用のアプリケーションをホスティングしています。このプロジェクトは今後3年間実行される予定です。アプリケーションは、ネットワークロードバランサー（NLB）のターゲットグループに登録された20のAmazon EC2オンデマンドインスタンスで構成されています。インスタンスは2つのアベイラビリティゾーンに分散されています。アプリケーションはステートレスで、24時間365日稼働します。

ユーザーからアプリケーションの応答が遅いという報告を受けています。パフォーマンスのメトリクスでは、通常のアプリケーション利用時にインスタンスのCPU使用率が10%であることが示されています。しかし、ピーク時にはCPU使用率が100%に達し、通常数時間続きます。

この企業はアプリケーションの応答が遅くなる問題を解決するための新しいアーキテクチャを必要としています。

最もコスト効率よくこの要件を満たす解決策はどれですか？

A. Auto Scalingグループを作成し、Auto ScalingグループをNLBのターゲットグループにアタッチします。最小容量を20、希望容量を28に設定します。20インスタンス分のリザーブドインスタンスを購入します。

B. リクエストタイプを「request」とするSpot Fleetを作成します。TotalTargetCapacityパラメータを20に設定し、DefaultTargetCapacityTypeパラメータを「On-Demand」に設定します。Spot Fleet作成時にNLBを指定します。

C. リクエストタイプを「maintain」とするSpot Fleetを作成します。TotalTargetCapacityパラメータを20に設定し、DefaultTargetCapacityTypeパラメータを「Spot」に設定します。NLBをアプリケーションロードバランサー（ALB）に置き換えます。

D. Auto Scalingグループを作成し、Auto ScalingグループをNLBのターゲットグループにアタッチします。最小容量を4、最大容量を28に設定します。4インスタンス分のリザーブドインスタンスを購入します。

解説

この問題は、アプリケーションのパフォーマンス向上とコスト効率を最適化するために、スケーラブルなソリューションを導入する方法を尋ねています。アプリケーションのインスタンスは、通常時には低いCPU使用率（10%）で動作し、ピーク時にCPU使用率が100%になることがわかっています。問題は、ピーク時に十分なリソースを提供しつつ、コストを抑える方法です。

各選択肢を見ていきましょう：

A. Auto Scalingグループを作成し、Auto ScalingグループをNLBのターゲットグループにアタッチします。最小容量を20、希望容量を28に設定します。20インスタンス分のリザーブドインスタンスを購入します。

評価: Auto Scalingグループを使用して、需要に応じてインスタンスの数を自動的に調整するアプローチです。最小容量を20、希望容量を28に設定することで、通常の利用時とピーク時の負荷に対応できます。また、リザーブドインスタンスを購入することで、長期的にコストを削減できます。

問題点: 希望容量が28に設定されているため、常に28インスタンス分のリソースを使用することになります。これではピーク時を除いてオーバープロビジョニングとなり、コスト効率が悪化します。

B. リクエストタイプを「request」とするSpot Fleetを作成します。TotalTargetCapacityパラメータを20に設定し、DefaultTargetCapacityTypeパラメータを「On-Demand」に設定します。Spot Fleet作成時にNLBを指定します。

評価: Spot Fleetを使用して、インスタンス数を必要に応じて調整する方法です。TotalTargetCapacityが20に設定されており、オンデマンドインスタンスを使用するため、ピーク時のリソース需要に対応できます。しかし、Spotインスタンスはコスト効率が良いものの、価格が変動するため、安定したリソース供給には向いていません。また、Spotインスタンスは中断されるリスクもあります。

問題点: 本番環境では、Spotインスタンスの中断リスクがアプリケーションのパフォーマンスに影響を与える可能性があるため、安定性が必要なシステムには向いていません。

C. リクエストタイプを「maintain」とするSpot Fleetを作成します。TotalTargetCapacityパラメータを20に設定し、DefaultTargetCapacityTypeパラメータを「Spot」に設定します。NLBをアプリケーションロードバランサー（ALB）に置き換えます。

評価: maintain リクエストタイプでは、Spotインスタンスを使用して、所定のリソース数を維持するように設定できます。しかし、Spotインスタンスは中断される可能性があり、NLBをALBに変更することが要件に関係ないので、コスト効率に寄与しない可能性があります。

問題点: Spotインスタンスの使用は依然として中断リスクがあり、ALBへの変更がアーキテクチャに影響を与える可能性があります。従って、信頼性の高い解決策ではありません。

D. Auto Scalingグループを作成し、Auto ScalingグループをNLBのターゲットグループにアタッチします。最小容量を4、最大容量を28に設定します。4インスタンス分のリザーブドインスタンスを購入します。

評価: この方法では、Auto Scalingグループを使用して、最小容量を4、最大容量を28に設定することで、ピーク時に柔軟に対応できます。4インスタンス分のリザーブドインスタンスを購入することで、最も安定したリソース供給ができます。オートスケーリングにより、リソースの過剰プロビジョニングを避けつつ、ピーク時に必要な容量を確保できます。

最もコスト効率的な解決策: リザーブドインスタンスを購入することでコスト削減が可能です。また、最小容量を4に設定することで、通常時にはリソースを節約し、ピーク時には最大容量を28に拡張して対応します。これにより、スケーラビリティとコスト効率が最適化されます。

結論:

最もコスト効率的で柔軟に対応できる解決策は D です。Auto Scalingを使用して、最小容量を4、最大容量を28に設定し、リザーブドインスタンスを購入することで、通常時のコストを抑えつつ、ピーク時の需要にも対応できます。