462-AWS SAP AWS 「理論・実践・一問道場」フロントエンド AMI
理論
AWS 災害復旧とパフォーマンス最適化のポイント
1. RDSリードレプリカ
- 概要: Amazon RDSのリードレプリカは、読み取り専用のデータベースインスタンスを作成可能。
- 利点:
- 読み取りクエリを分散し、パフォーマンスを最適化。
- マルチリージョンのレプリケーションで災害復旧にも対応。
- 注意点: 災害時には手動でリードレプリカを昇格する必要がある。
2. S3クロスリージョンレプリケーション（CRR）
- 概要: S3バケット間でデータを自動的に複製し、別リージョンに冗長性を確保。
- 利点:
- リアルタイムでデータを同期。
- バケット間で災害対策が可能。
3. AMI（Amazon Machine Image）
- 概要: EC2インスタンスのスナップショットを作成し、他リージョンにコピー可能。
- 利点:
- 新しいインスタンスを迅速に起動。
- 災害時のリカバリーに有効。
4. 災害復旧の基本戦略
- RPO（Recovery Point Objective）: 許容できるデータ損失の最大値を定義。
- 例: S3のCRRやRDSリードレプリカを使えば、RPOを最小化可能。
- RTO（Recovery Time Objective）: システムを復旧させる目標時間。
- 例: AMIを使用すれば、短時間でシステムを復旧可能。
5. パフォーマンス最適化のアプローチ
- ElastiCache: クエリをキャッシュし、データベース負荷を軽減。
- リードレプリカ: 読み取り専用クエリを分離して、本番環境の性能を確保。
まとめ
AWSでは、RDSリードレプリカ、S3のCRR、AMIなどを組み合わせることで、災害復旧とパフォーマンス最適化を同時に達成できる。特にマルチリージョン構成は、データ損失を最小化し、迅速な復旧を可能にする強力なソリューションです。
実践
略
一問道場
問題 #462
ある企業が、単一のAWSリージョンで稼働している重要なアプリケーションの災害復旧を実装する必要があります。このアプリケーションのユーザーは、Application Load Balancer (ALB) の背後にあるAmazon EC2インスタンスにホストされたWebフロントエンドを介してアプリケーションとやり取りします。アプリケーションはAmazon RDS for MySQLデータベースに書き込みを行い、処理されたドキュメントをAmazon S3バケットに保存します。
この企業の財務チームは、データベースに直接クエリを実行してレポートを生成しますが、繁忙期にはこれらのクエリがリソースを消費し、アプリケーションのパフォーマンスに悪影響を与えています。
ソリューションアーキテクトは、災害時の復元性を提供するソリューションを設計する必要があります。このソリューションは、データ損失を最小限に抑え、財務チームのクエリによるパフォーマンス問題を解決する必要があります。
どのソリューションがこれらの要件を満たしますか？
A.
データベースをAmazon DynamoDBに移行し、DynamoDBグローバルテーブルを使用します。財務チームには、別のリージョンにあるグローバルテーブルをクエリするよう指示します。AWS Lambda関数を作成して、元のS3バケットの内容を別のリージョンにある新しいS3バケットに定期的に同期します。別のリージョンにEC2インスタンスを起動し、ALBを作成します。アプリケーションを新しいS3バケットに向けるように設定します。
B.
別のリージョンにアプリケーションをホストする追加のEC2インスタンスを起動します。それらのインスタンスを既存のALBに追加します。別のリージョンでRDS DBインスタンスのリードレプリカを作成します。財務チームには、このリードレプリカに対してクエリを実行するよう指示します。元のS3バケットから別のリージョンにある新しいS3バケットへのS3クロスリージョンレプリケーション（CRR）を設定します。災害時には、リードレプリカをスタンドアロンDBインスタンスに昇格させます。アプリケーションを新しいS3バケットと昇格したリードレプリカに向けるように設定します。
C.
別のリージョンでRDS DBインスタンスのリードレプリカを作成します。財務チームには、このリードレプリカに対してクエリを実行するよう指示します。アプリケーションフロントエンドをホストするEC2インスタンスのAMIを作成し、そのAMIを別のリージョンにコピーします。元のS3バケットから別のリージョンにある新しいS3バケットへのS3クロスリージョンレプリケーション（CRR）を設定します。災害時には、リードレプリカをスタンドアロンDBインスタンスに昇格させます。AMIからEC2インスタンスを起動し、ALBを作成してエンドユーザーにアプリケーションを提供します。アプリケーションを新しいS3バケットに向けるように設定します。
D.
RDS DBインスタンスのスナップショットを毎時作成し、それを別のリージョンにコピーします。既存のRDSデータベースの前にAmazon ElastiCacheクラスターを追加します。アプリケーションフロントエンドをホストするEC2インスタンスのAMIを作成し、そのAMIを別のリージョンにコピーします。元のS3バケットから別のリージョンにある新しいS3バケットへのS3クロスリージョンレプリケーション（CRR）を設定します。災害時には、最新のRDSスナップショットからデータベースを復元します。AMIからEC2インスタンスを起動し、ALBを作成してエンドユーザーにアプリケーションを提供します。アプリケーションを新しいS3バケットに向けるように設定します。
解説
設問のポイント
- 災害復旧 (Disaster Recovery)
- 別のAWSリージョンでアプリケーションとデータを冗長化する必要があります。
- データ損失を最小限に抑える設計が求められます。
- パフォーマンス問題の解消
- 財務チームのクエリがアプリケーション性能に悪影響を及ぼさないようにする必要があります。
選択肢の評価
A. DynamoDBに移行し、グローバルテーブルを使用する
- メリット
- DynamoDBはスケーラブルであり、グローバルテーブルによりデータの冗長化が簡単に可能。
- デメリット
- データベースをDynamoDBに移行するため、アプリケーションコードの変更が必要。この問題では「アプリケーションコードの変更なし」が前提条件。
→ 条件に合わないため、不適切。
B. 別リージョンにリードレプリカを作成し、RDSを昇格させる
- メリット
- RDSのリードレプリカを使用することで、財務チームのクエリを分離し、パフォーマンスを改善できる。
- クロスリージョンレプリケーションによりデータ損失を最小化。
- デメリット
- ALBに別リージョンのEC2インスタンスを追加するのは現実的ではない（異なるリージョン間でロードバランシングはサポートされていない）。
→ ALBの設計に不備があるため、不適切。
C. 別リージョンにリードレプリカを作成し、AMIをコピーする
- メリット
- RDSのリードレプリカを使用することで、財務チームのクエリを本番環境から分離できる。
- S3のクロスリージョンレプリケーションにより、ストレージデータの同期を確保。
- 災害発生時にはリードレプリカを昇格し、AMIから新しいEC2インスタンスを立ち上げることで復旧が可能。
- デメリット
- 災害発生時に手動でリードレプリカを昇格させる必要がある。
→ 条件を満たすため、適切。
D. RDSスナップショットとElastiCacheを使用する
- メリット
- ElastiCacheにより、クエリのパフォーマンス問題を解消可能。
- スナップショットを別リージョンにコピーすることでデータ損失を最小限に抑えられる。
- デメリット
- スナップショットの復元には時間がかかるため、RPO（復旧ポイント目標）が緩和される可能性がある。
- リアルタイムのデータ同期が行われないため、データ損失リスクが若干高い。
→ データ損失リスクがあるため、不適切。
正解: C
Cは災害復旧とパフォーマンス問題解消の両方に対応しており、要件を最も適切に満たします。
補足知識
- RDSリードレプリカ
- 読み取り専用のクエリを別のインスタンスにオフロード可能。マルチリージョンでのデータ同期も可能。
- S3クロスリージョンレプリケーション（CRR）
- S3バケット間でデータを自動的に複製し、冗長性を確保する機能。
- AMI（Amazon Machine Image）
- EC2インスタンスの状態を保存し、他リージョンにコピーすることで迅速な復旧が可能。
- Author:minami
- URL:https://www.minami.ac.cn/private-license/17bd7ae8-88e2-8051-bf02-d2eb662214b5
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
