Aurora
Q1. マルチAZ構成でAutoScalingを構築している。このシステム中のAuroraのプライマリーDBインスタンスに障害が発生した場合、フェイルオーバの最中には何が発生するか？
A1. 場合分けして考える。
- Aurora Replicaが存在する場合（同 or 別AZ）
- CNAMEをHealthyなレプリカに付け替える。一般的に約30秒で完了。
- Aurora Serverlessを利用している場合
- 別AZにDBインスタンスを再構築
- シングルインスタンスの場合（Replicaがない）
- 同一AZにインスタンスを再構築しようと試みる。不可能な場合、別AZに再構築する。
DynamoDB
Q1. ゲームのアプリケーションでAPI GatewayとDynamoDBを利用している。Dynamoは読み込み書き込みのキャパシティを設定している。Dynamoのロードがピークになった時、リクエストをスロットリングしており、ゲームのパフォーマンスが低下していることに気づいた。これを改善するにはどうすればよいか。
- DynamoDBのテーブルをAutoScalingGroupに追加する
- SQSキューをDynamoDBテーブルの前に配置する
- DynamoDBテーブルとALBを統合する
- DynamoDB Auto Scalingを利用する
A1. 4
- DynamoDB auto scalingを利用すると、実際のトラフィックに合わせてスループットが自動で調節される
- トラフィック増加に合わせてスケーリングされることで、tableやglobal secondary indexがプロビジョニングされた読込書込キャパシティを増加させる
- SQSはリクエストをキューイング・ポーリングするので、スループット向上を実現できるわけではない
Redshift
Q1. Redshiftを利用している。AWSのリージョン障害が発生した場合でも復旧ができるよう準備をしなければならない。何が必要か。
- Redshiftのsnapshotを作成するジョブをスケジューリングし、取得したsnapshotをS3に格納する。
- Redshiftはフルマネージドな高可用DWHのため何もしなくてよい
- Automated snapshotsを利用する
- Cross-Region snapshots copyをRedshiftで有効にする
A1. 4
- 1は可能だが、作業のハードルが高いので推奨できない
- 別リージョンに復旧するためにはCross-Region snapshots copyを有効にしとかなければならないので、2はNG
- AWSリージョンがダウンした場合はAutomated snapshotsは利用できないのでNG
Database Migration
Q1. アプリケーションとDBをAWSにマイグレーションする要件がある。オンプレのOracleをAWSのPostgreに移行する必要があるため、この移行にはスキーマやコード修正が伴う。AWSのどオプションが最もフィットするか。（２つの組み合わせ）
A1.
- AWS Schema Conversion Tool
- AWS Database Migration Service
- AWS DMS
- 同種・異種のDB移行のいずれにも対応
- オンプレ to RDS(on EC2含む)、EC2 to RDS, RDS to RDSそれぞれ対応
- SQL, NoSQL, text based target間のデータ移行にも対応