【AWS初学者向け】AWS認定資格DBS直前対策

対応している。

16000 IOPS。詳しくは下記記事を参照されたい。

DynamoDB

DynamoDB

GSI内の一部のパーティションにのみデータが集中する可能性が高まる。低カーディナリティの例としては，性別やステータス等が該当する。

カスタムエンドポイントを利用する。思考停止でインスタンスエンドポイントを選ばない。

Aurora Serverless DB

QLDB

強力な整合性が指定されたトランザクションをDAXが受け取ると，そのままDynamoDBに渡される。DAXはDynamoDBから返答を受け取っても，結果をキャッシュしない。

• DBパラメータグループのmax_connectionsパラメータの値を大きくする
• DBクラスタのインスタンスクラスをスケールアップする

DBクラスタのインスタンスクラスをスケールアップすると，max_connectionsパラメータのデフォルト値も大きくなるため，結果としてDBクラスタのコネクション数の最大値を増やすことができる。あくまでも，DBクラスタのコネクション数の最大値はmax_connectionsパラメータによって定められている。また，パラメータグループではなくconfファイルを編集するといった引っかけの選択肢にも注意する。

RDBMSはACIDを重視し，データの整合性とトランザクションの一貫性が担保する。DynamoDBはBASEを重視し，高可用性と結果整合性を担保する。

Amazon RDS Custom for SQL Server。IaaSとしてのEC2上に立てるDBよりもユーザ側の責任範囲が少し狭く，IaaSとPaaSの中間に位置しているサービス。

RDSからAuroraのレプリカを作成し，レプリケーションのラグがゼロであることを確認した上でレプリカを昇格させる。ポイントとしては，RDSからAuroraのレプリカを作成できる点。Schema Conversion Toolで前処理をしてDMSを使うこともできるが，データが大量に存在する場合は移行に時間がかかる点に注意する。

csv

• AutoScalingポリシーの設定
• IAMポリシーの設定
• CloudWatch設定
• タグ設定
• TTL設定

lambdaによりAurora上でSELECT INTO OUTFILE S3ステートメントを利用する。

Data Pipeline。ちなみに，S3へのデータ移行にもData Pipelineが利用できる。

Secrets Manager＋lambda。定期ローテーション自体はSecrets Managerの機能で実現可能だが，そのパスワードをRDSに設定するのはlambdaで行う。

Neptune Loader

DMSのロギングタスク設定で，TARGET_APPLYイベントに対してLOGGER_SEVERITY_DEBUGを設定する。

• rds_backup_databaseストアドプロージャによりデータベースをS3にバックアップする
• rds_restore_databaseストアドプロージャによりデータベースをS3からリストアする

Full LOBモードのタスクとLimited LOBモードのタスクの二つを用意する。

• Full LOB：最大許容サイズを指定しない。非常に低速になる可能性がある。
• Limited LOB：最大許容サイズを100MB程度に指定する。Full LOBよりもパフォーマンスが向上する。

• 頂点とエッジを別々のcsvファイルに格納する
• NeptuneインスタンスにS3へのアクセス許可を指定したRoleをアタッチする
• Neptuneローダを起動するためにPCエンドポイント経由でS3にHTTP POSTリクエストを送信する

ターゲットと同じリージョン・VPC・サブネット

プライマリ

ROW。変更行を矛盾なく検知するための設定。

自動バックアップは有効にする必要がある。バイナリログを有効にするため。

AWS SCTのマルチサーバアセッサー

Trusted Adviserのアイドルインスタンスレポートを利用する。

• Multi-AZ構成であること
• 自動バックアップが有効化されていること

• バックアップ保持期間を明示していること
• バイナリログが有効化されていること

ただし，バイナリログを有効化するためにはバックアップ保持期間を明示する必要がある。

• ソースリージョンでクロスリージョンスナップショットを有効化し，CMKを指定する
• ターゲットリージョンでCMKを利用する権限をRedshiftに付与する

• レプリカからバックアップを作成する
• reserved-memory-percentで25%程度のメモリを確保する

Amazon CloudWatch Application Insights

• RDS Enhanced Monitoring：インスタンス全体の性能メトリクス
• RDS Performance Insights：特定のクエリレベルのパフォーマンス

-1

DBへのコミット数が多く，書き込みトランザクションが待機しているイベントを表す。なお，Xactはトランザクションのことを指す。

• CPUのスケールアップ
• ネットワーク帯域幅の拡大
• トランザクションブロックの利用

フォールトインジェクション

0を設定する。performance_schemaは特定のSQLクエリの実行に要する時間，テーブルへのアクセス回数，ロック状態などのメトリクスを取得して管理する機能であり，Performance Insightsはperformance_schemaのパラメータを自動的に管理するため，1に設定すると重複してしまう。そのため，0を設定するようにする。

SQLのダイジェスト統計を収集するテーブル。digestはハッシュのダイジェストではなく「要約」を意味する。

レプリカがプライマリに対して同期が遅れること。レプリケーションでは二つのスレッドタイプを利用する。

• IO_THREAD：通常は遅延しない。ネットワーク帯域の使用量によっては遅延する。
• SQL_THREAD：プライマリDBで長時間実行しているクエリやストレージ不足が原因。

RDSはプライマリのスナップショットからリードレプリカを作成する。そのため，リードレプリカの作成には時間を要する。具体的には，レプリケーション開始時のスナップショットからレプリカを作成し，その時点からの増分バックアップによりプライマリと同期させる。

クラスタキャッシュ管理（CCM）機能。レプリカをプライマリと同じインスタンスクラスに設定し，プライマリとレプリカにフェールオーバー優先順位tier0を付ける。tierは0が一番優先度が高い。

• 同期モード：ワークロードへの影響を犠牲にしてストリーミングの精度を担保する
• 非同期モード：ストリーミングの精度よりもパフォーマンスを担保する

PostgreSQLの場合は両方とも利用でき，MySQLの場合は非同期モードのみが利用できる。

QUERY_DCL。DCLはデータ制御言語（Data Control Language）のことを指していて，GRANTやREVOKEなどが含まれている。

IAMのConditionでdynamodb:LeadingKeysを利用する。policyによって特定のKeyにLeadされるイメージ。

• クライアント・インスタンス間：パラメータグループのrequire_secure_transportをONに設定する
• RDSプロキシ・インスタンス間：プロキシ作成時にRequire Transport Layer Securityを有効化する

不要。

ストレージ

EventBridgeで6時間おきにRDSからスナップショットを取得するlambdaを呼び出す。lambdaを使わなければ，RDSの自動スナップショットはデフォルトで1日おきに起動するため，要件と満たすことができない。

有する。EC2やECSと同様に，プロビジョニングされたキャパシティの最小値と最大値を指定できる。

DynamoDB Accelerator。DAXという文字が見えないからといって，他の選択肢に食いつかないように注意。DAXはDynamoDB Acceleratorの略称であることを忘れずに。また，読み取り性能から思考停止でRedisを選ばないように注意。DAXの方がシンプルでよいソリューションとなる。

作成できる。

できない。リードレプリカを削除してからプライマリを停止するしかない。

1時間

できない。

有効ではない。クラスタがノードに割り当てるメモリが不足していることが原因である。TTLが設定されていることを確認するほか，既存のキーを手動で削除することや，大きなノードタイプにスケールアップする対策が考えられる。

利用できない。

利用されない。

サポートしていない。

実現できない。AWSアカウントかグループを制限する。

Redshift Concurrency Scaling

できない。

変わる。

DynamoDB Global Table。Aurora Global DatabaseやRDSクロスリージョンリードレプリカはあくまでもリードレプリカの作成なので，アクティブ・スタンバイ構成となる。アクティブというのは，書き込みができる状態であることに注意する。

RDSインスタンスを手動でフェールオーバーする。フォールトインジェクションよりも手動フェールオーバーの方が最速な手段として適切。手動というのは，例えばマネコンからの操作を表す。

自然ではない。DynamoDBではDAXが利用できるため，そちらを利用する方が自然。

Performance Insightsを利用する。Enhanced Monitoringはあくまでもリソース監視のイメージ。

プラグインや拡張機能を利用するための設定。

• S3へのアクセスを付与するIAMロールを作成する
• RDSオプショングループで保存先のS3と作成済みのIAM Roleを指定する
• 作成したオプショングループをRDSに適用する

カスタムパラメータグループでserver_audit_loggingをONに設定する。SQL Serverの監査ログの有効化とは異なり，オプショングループを利用する訳ではないことに注意する。

スナップショット復元

利用できない。プロビジョニングモードを利用する。

高可用性と災害復旧を実現するための機能で，下記の二つから構成される。

• AG（可用性グループ）
• FCI（フェールオーバークラスインスタンス）

AGは災害復旧にも効果があるが，ミラーリングを行うためネットワーク性能を求められる。十分な性能を担保できない場合は，FCIを利用する方が無難。

• ソースのインスタンスで自動バックアップが有効化していること
• AlwaysOn AGを設定したマルチAZ配置であること
• パラメータグループでread_onlyの値が1であること，または0である場合は即座に1に戻すこと

• DeleteProtection：各サービスが保護対象
• TerminationProtection：スタック全体が保護対象

小さなファイルを64MB以上の大きなファイルにマージする。そうすることで，GETリクエストやHEADリクエストの無駄なオーバーヘッドを削減できる。

できない。Numberパラメータなどで定義してRef組み込み関数で参照する。

できない。スケールアップするしかない。

検知できる。

ある。最大7日間停止できる。7日を過ぎると自動で再開する。

取得できない。CloudTrailを利用する。

DMSの方がダウンタイムは小さい。

利用できない。AD ConnectorはあくまでもAWSからオンプレのADにリダイレクトするサービスであり，直接ログイン機能を提供するサービスではない。

Aurora ServerlessのACU（Aurora許容単位）調整機能を利用する。

どちらでもよい。一方向の場合は，AWS側で設定する方式が一般的。

自動で再起動されないので反映されない。

プロビジョンドモード。プロビジョンドモードの方が「性能を担保する代わりに高い」というイメージがあるが，ある程度安定したワークロードに対してはプロビジョンドモードでオートスケーリングした方が安くなる。

担保できない。強い整合性を必要とする要件にはLSIを利用する。

クロスリージョンレプリカの方が，1分未満のレプリケーションラグが発生する可能性がある。

対応していない。Global Database等を利用してアーキテクチャを工夫することにより，クロスリージョンでDMSを利用することが可能になる。

DMSデータ検証。Schema Conversion Toolではないため注意する。

存在する。例えば読み取りスループットで大きなレイテンシーを示している場合は，より高い最大帯域幅をもつインスタンスクラスにスケールアップすることを考える。

できない。スナップショットのコピーをKMS暗号化キーと併せて共有する。

6時間に1回しかストレージ容量は変更できない。

設定できない。

SSMを利用する。例えば，オンプレミスとAWS側のEC2にSSM Manager Agentをインストールし，SSMのRun Commandでインストールされたアシスタントを利用する。この場合，RDSへの移行ではなくEC2への移行となる。また，RDSへの移行であればDMSが利用できるが，EC2への移行なのでDMSは利用しない。

35日間

あり得る。TTl期限が過ぎたアイテムは，通常数日以内に削除される。そのため，クエリフィルタ式を利用してTTL期限が過ぎていないアイテムだけをGetする必要がある。

新しいNeptuneクラスタにデータをエクスポートする。スナップショットからの復元は未使用領域をそのまま保持するため不適切。同様に，レプリカからの昇格でも未使用領域をそのまま保持するため不適切。

適していない。

できる。ReplicationLatencyが増加した場合はオートスケーリングが有効化されていないことを疑う。

できる。RDS for MySQL ServerからAuroraへの移行では，Auroraのレプリカを作成する。

パラメータグループのoptimizer_switchでhash_join=onに設定することで，ハッシュ結合を有効化する。

LSIが設定されたテーブルにおいて，同じパーティションキーを持つItemの占めるサイズが10GBの上限を超えたことを表している。テーブルを分けてパーティションキーを再設計し，LSIの使用を避ける必要がある。

妥当な選択である。