374-AWS SAP AWS 「理論・実践・一問道場」高トラフィックイベント
理論
高トラフィックイベントにおけるAWSスケーリング戦略のポイント
高トラフィックが予想されるイベント（例: チケット販売）では、システムの可用性とスケーリングが重要です。以下は、関連する汎用的な知識をまとめたポイントです。
1. スケーリング戦略の選択
- スケジュールスケーリング:
- イベント日時が事前に分かっている場合に有効。
- 定時にリソースを増加させ、イベント後に縮小する。
- 使用例: Auto ScalingグループでのEC2インスタンスのスケールアウト。
- 予測スケーリング:
- 過去のデータをもとに需要を予測してスケールアウト。
- 不確定要素が多い場合に適用。ただし、販売イベントなど急激なトラフィック増加には不向き。
2. Amazon Auroraの選択理由
- スケーリングの柔軟性:
- Auroraはリードレプリカの作成が高速で、必要に応じてリソースを迅速に拡張可能。
- Multi-AZ構成により、高可用性を実現。
- コスト効率:
- AuroraはRDSよりもコスト効率が良い場合が多い。
- イベント後にリードレプリカを縮小することで運用コストを削減。
3. リードレプリカの活用
- リードレプリカは、読み取りトラフィックを分散させるために使用。
- 大規模イベントでは、事前に大きなリードレプリカを作成し、必要に応じてフェイルオーバー。
- イベント終了後はリードレプリカを縮小してコスト最適化。
4. イベントトリガーの自動化
- Amazon EventBridge:
- イベントスケジュールに基づいてAWSサービスをトリガー。
- Lambdaを利用して、スケーリングやフェイルオーバーの自動化を実現。
- AWS Step Functions:
- 複雑なワークフローを自動化し、複数のLambda関数を並列実行可能。
5. その他の考慮事項
- キャッシュ:
- Amazon CloudFrontやElastiCacheを利用して、データベースへの負荷を軽減。
- ヘルスチェック:
- ELBやRoute 53のヘルスチェックを使用して、異常検知とリソース切り替えを確実に行う。
まとめ
高トラフィックイベントには、スケジュールスケーリングとAurora Multi-AZ構成を組み合わせるのが効果的です。さらに、EventBridgeとLambdaを利用して、リソースの拡張・縮小を自動化することで、可用性とコスト効率を両立できます。
実践
略
一問道場
Question #374
あるライブイベント会社が、AWS上で運用するチケットアプリケーションのスケーリングソリューションを設計しています。このアプリケーションは、販売イベント中に利用率が非常に高くなります。各販売イベントは一度きりのイベントで、事前にスケジュールされています。このアプリケーションは、Auto Scalingグループ内のAmazon EC2インスタンスで実行されており、データベース層にはPostgreSQLを使用しています。
会社は、販売イベント中の最大限の可用性を確保するためのスケーリングソリューションを必要としています。
この要件を満たすソリューションはどれですか？
A. EC2インスタンスに予測スケーリングポリシーを使用する。データベースをAmazon Aurora PostgreSQL Serverless v2 Multi-AZ DBインスタンス（自動スケーリング可能なリードレプリカ付き）でホストする。販売イベント前にデータベースを事前ウォームアップするために、並列AWS Lambda関数を実行するAWS Step Functionsステートマシンを作成する。Amazon EventBridgeルールを作成して、ステートマシンを呼び出す。
B. EC2インスタンスにスケジュールスケーリングポリシーを使用する。データベースをAmazon RDS for PostgreSQL Multi-AZ DBインスタンス（自動スケーリング可能なリードレプリカ付き）でホストする。販売イベント前に、より大きなリードレプリカを作成するAWS Lambda関数を呼び出すAmazon EventBridgeルールを作成する。そのリードレプリカにフェイルオーバーする。販売イベント後にリードレプリカをスケールダウンする別のEventBridgeルールを作成する。
C. EC2インスタンスに予測スケーリングポリシーを使用する。データベースをAmazon RDS for PostgreSQL Multi-AZ DBインスタンス（自動スケーリング可能なリードレプリカ付き）でホストする。販売イベント前にデータベースを事前ウォームアップするために、並列AWS Lambda関数を実行するAWS Step Functionsステートマシンを作成する。Amazon EventBridgeルールを作成して、ステートマシンを呼び出す。
D. EC2インスタンスにスケジュールスケーリングポリシーを使用する。データベースをAmazon Aurora PostgreSQL Multi-AZ DBクラスターでホストする。販売イベント前に、より大きなAurora Replicaを作成するAWS Lambda関数を呼び出すAmazon EventBridgeルールを作成する。そのAurora Replicaにフェイルオーバーする。販売イベント後にAurora Replicaをスケールダウンする別のEventBridgeルールを作成する。
解説
Dの内容
- EC2: スケジュールスケーリングで事前にスケールアウトを計画。
- データベース: Aurora PostgreSQL Multi-AZ DBクラスタを使用。
- EventBridge: Lambdaを活用して事前に大きなリードレプリカを作成し、販売イベント中にフェイルオーバー。イベント終了後にリードレプリカを縮小。
Dが正解となる理由
- スケジュールスケーリングの有効性
- 販売イベントは日時が事前に分かっているため、予測スケーリングよりもスケジュールスケーリングが適切。
- これにより、イベント開始前に必要なリソースを確保できる。
- Aurora PostgreSQLの強み
- AuroraはRDSよりもスケーリングが柔軟で、高可用性や自動バックアップなどの利点がある。
- Multi-AZ構成により、フェイルオーバー時にも高い可用性が確保される。
- 事前リードレプリカ作成とフェイルオーバー
- EventBridgeとLambdaを使用することで、リードレプリカの作成を自動化。
- フェイルオーバーによって、より大きなリードレプリカを主要インスタンスとして利用可能。
- イベント後にリードレプリカを縮小することでコスト最適化も実現。
- 予測スケーリングより確実
- 販売イベントはトラフィックのピークが急激であるため、事前スケールアウトが必要。
- 予測スケーリングは履歴データに依存するため、イベント特有の急激な増加に対応しきれない可能性がある。
他の選択肢と比較
- A: Aurora Serverless v2は非常に柔軟だが、予測スケーリングの適用がイベントには向かない。
- B: RDSはAuroraに比べてスケールアウトが遅く、販売イベントのような即応性が求められる場面には適さない。
- C: Aと同様に予測スケーリングがボトルネックとなる可能性がある。
結論
- Dが正解である理由:
- 販売イベントの特性（日時が事前に決まっている、トラフィック急増）がスケジュールスケーリングとAuroraの組み合わせに最適である。
- リードレプリカを事前に拡張し、フェイルオーバーする戦略は、イベント中の可用性を最大化しつつ、コスト最適化も可能にする。
- Author:minami
- URL:https://www.minami.ac.cn/private-license/178d7ae8-88e2-80f9-ae8d-deca0e478c7f
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
