AWS 認定 データベース – 専門知識（AWS Certified Database - Specialty）の試験対策

## はじめに
試験対策に備忘録として、
　分かりにくい
　間違えやすい
箇所をメモを記載していく



## 目次
- RDSをIAMデータベース認証
- RDS作成時にバックアップ保持期間
- RDSのリードレプリカ作成
- RDS（MySQL、PostgreSQL）をAuroraへ移行
- RDS（MySQL）のスキーマ変更
- RDSのバックアップ
- RDSのモニタリング（拡張モニタリング）
- RDSのメンテナンス
- RDSリソースの削除防止
- RDSでTrustAdvisor
- Auroraの暗号化
- Auroraのクローン
- Auroraのバックトラック
- Auroraの一時停止
- Auroraのリードレプリカが遅い原因
- DynamoDBのキャパシティユニット
- DynamoDBとQLDBはVPC 内にない
- DynamoDBグローバルテーブル
- Redshiftへデータ移行
- ElastiCacheの用途
- ElastiCache for Redisの不正アクセス保護
- QLDBのリアルタイム検索
- CloudFormationの複数リージョンでデプロイ

## RDSをIAMデータベース認証
- IAM データベース認証
　MySQL　　：可能
　PostgreSQL：可能
　それ以外（oraclesqlServer）：不可

- IAM データベース認証の制限
　DBインスタンスごとに１秒当たりの最大接続数あり
　 MySQL、推奨1 秒あたり 200 未満
- 認証トークンには 15 分の有効期間
- 複数のIAMユーザーまたはロールを同じデータベースユーザーアカウントにマップ可能

その他
- EC2上のアプリケーションからは、EC2 インスタンスプロファイル認証情報を使用してデータベースにアクセス可能

https://aws.amazon.com/jp/premiumsupport/knowledge-center/users-connect-rds-iam/

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html#UsingWithRDS.IAMDBAuth.Availability

## RDS作成時にバックアップ保持期間

コンソールを使用してDBインスタンスを作成
　→　デフォルトのバックアップ保持期間は7日

Amazon RDS APIを使用してDBインスタンスを作成
　→　デフォルトのバックアップ保持期間は1日

※Auroraのデフォルトのバックアップ保持期間は1日

## RDSのリードレプリカ作成
- 作成方法
RDSはプライマリのDBインスタンスからスナップショットを作成して、リードレプリカを作成
※スナップショット作成時に、プライマリDBインスタンスのI/Oが一定時間停止

::: note warn
RDSのマルチAZ配置の場合
　スタンバイDBインスタンスからスナップショットを作成するため、I/Oの停止を回避できる
:::

- 自動バックアップを有効（保持期間を0以外の値に設定）
- 既存の第1層からリードレプリカ作成
RDS（MYSQL）　　　→　既存リードレプリカのリードレプリカを**作成可能**
RDS（MYSQL）以外　→　既存リードレプリカのリードレプリカを**作成不可**

https://aws.amazon.com/rds/faqs/

## RDS（MySQL、PostgreSQL）をAuroraへ移行
Aurora Readレプリカを使用して、MySQL用のAmazonRDSDBインスタンスからAmazonAuroraに移行
①RDS(MySQL)でAuroraリードレプリカ作成
②Auroraリードレプリカを昇格

https://aws.amazon.com/jp/blogs/aws/new-create-an-amazon-aurora-read-replica-from-a-mysql-db-instance/

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Migrating.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Migrating.html

## RDS（MySQL）のスキーマ変更
RDS（MySQL）のリードレプリカのスキーマ変更等ができるため、下記の手順でDDLを反映する

①リードレプリカ作成
②リードレプリカのDBパラメーターグループでread_onlyパラメーターを「0」に設定
①リードレプリカにDDL操作を実行
②リードレプリカをDBインスタンスに昇格
　※昇格時、プライマリDBの書き込みを停止し、リードレプリカの更新を待つ


https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Promote

## RDSのDR対策

- 目標復旧時間（RTO）
　災害後に作業状態に戻るのにかかる時間
- 目標復旧時点（RPO）
　RPOは時間単位でも表され、災害が発生したときに失われる可能性のあるデータの量
　（例）RPOが1時間の場合、災害が発生したときに最大1時間分のデータが失われる可能性

自動バックアップ
- DBインスタンスの最初のスナップショットには、完全なDBインスタンス
　※その後、増分スナップショット
- 特定の時間指定ができない（8時間単位にランダム）
- マルチAZ構成の場合、プライマリへの影響を減らすために、スタンバイでバックアップが実行
- バックアップ保持期間は、PITR（ポイントタイムリストア）が可能
- DBインスタンス削除時、同時に削除される（※削除しない方法もあり）
- クロスリージョン自動バックアップをサポート

手動バックアップ
- リージョンごとに最大100スナップショット
- 自動的に削除されない
- 複数のリージョンでサポート
- 最大20のAWSアカウントと共有可能


https://aws.amazon.com/jp/blogs/database/implementing-a-disaster-recovery-strategy-with-amazon-rds/

## RDSのモニタリング

- Amazon RDS Performance Insights
パフォーマンスの問題を分析し、解決するのに役立つ、データベースのパフォーマンス情報

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/MonitoringOverview.html

- Trusted Advisor
RDSアイドルDBインスタンス、RDSセキュリティグループアクセスリスク、RDSバックアップ、RDSマルチAZをチェック

https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/best-practice-checklist/

- Amazon RDS EnhancedMonitoring（拡張モニタリング）
DB インスタンスのオペレーティングシステムをリアルタイムでモニタリング

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html

# RDSのメンテナンス
- ハードウェアのメンテナンス
シングル AZ 配置の場合、ダウンタイムあり。
マルチ AZ 配置の場合、メンテナンスのAZによって影響が変わる。セカンダリのAZメンテナンスであれば、影響なし。

- OS のメンテナンス
延期可能
マルチ AZ 配置で対応し、セカンダリインスタンス適用後、フェールーバーし、プライマリインスタンス更新

- DB エンジンレベルのアップグレード
プライマリ DB インスタンスとスタンバイ DB インスタンスの両方が同時にアップグレード
ダンタイム必要

https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-required-maintenance/

## RDSリソースの削除防止
CloudFormationの下記を設定し、リソースの削除を防止

- RDSのインスタンス削除保護
　DeleteProtectionが「true」設定

- スタック削除時、RDSのインスタンス削除保護
　DeletionPolicy属性に「Retain」設定


- 万が一削除された場合を考慮して、自動バックアップは削除しない　　 
　DeleteAutomatedBackups属性に「False」設定


- スタックそのもの削除保護
　・コンソールでスタックの「termination protection」を有効化

- スタックが意図せずに更新または削除されるのを防止
　・スタックポリシーを設定

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/APIReference/API_DeleteDBInstance.html

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/protect-stack-resources.html

## RDSでTrustAdvisor
5カテゴリで問題を検知する　
※メール通設機能設定、CloudWatchEvent(trustAdvisorEvent)→SNS通知

コストの最適化
- 長期間使用されていないDBインスタンスの検出
　　提案アクション：スナップショット作成後、インスタンス削除
- RDS の利用状況をチェック
　　提案アクション：リザーブドインスタンスの購入提案

セキュリティ 
- RDSのセキュリティグループをチェック
- RDSのスナップショットが公開に設定されているチェック

耐障害性
- 自動バックアップのチェック
- 単一AZのRDSをチェック

https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/best-practice-checklist/

# Auroraの暗号化
　　Aurora →　スナップショット →　Aurora（暗号化）※リストア時にKMSキー指定可能
　　RDS →　スナップショット　→　暗号化スナップショット　→　RDS（暗号化）

# Auroraのクローン
- クローンはコピーではない。
- 同一リージョン内の同一AZでのみ作成可能（※VPCは異なってもOK）
- Aurora Serverless v1 DBでクローン可能
- 最大15個まで
- クロスアカウントのクローン作成可能

# Auroraのバックトラック
- クラスター作成時、リストア時のみ設定可能
- 最大72時間
- 既存のDBクラスターに反映
- 単一テーブルのみ選択し、戻すことは不可

# Auroraの一時停止
すべてのリードレプリカを削除後、プライマリRDSDBインスタンスを停止する
※DB インスタンスは最大 7 日間停止。その後、自動起動

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_StopInstance.html

## Auroraのリードレプリカが遅い原因
レプリケーションでタイムラグがあり、遅延する原因
- クラスターで書き込みアクティビティの突然の急増
- リードレプリカのクラスター内のインスタンスが小さい
- リードレプリカに複数のセッションが同時アクセス
- ネットワークの通信障害

調査
- AuroraReplicaLag メトリクスでタイムラグを測定可能
- 拡張モニタリングでCPU使用率、DBコネクションの監視

https://aws.amazon.com/jp/premiumsupport/knowledge-center/aurora-mysql-read-replicas/

## DynamoDBのキャパシティユニット
- パーティションのサポートされる最大サイズ：10GB
- 単一項目のプライマリキーに対して、下記のスループットを提供
　最大RCU：3,000
　最大WCU：1,000

（例）16KB/秒 強力整合性 で 読み取り10回を行いたい
　強力整合性　1RCU　＝　4 KB/秒

　1回 ：16KB/秒　/ 4KB/秒　= 4RCU 
　10回：4RCU  × 10　= 40RCU

（例）10WCU 10WCU
 　Read
　　　強力整合性　1RCU　＝　4 KB/秒
　　　強力整合性 4 KB/秒 × 10RCU = 40KB/秒
　　　結果整合性 40KB/秒 × 2倍 = 80KB/秒
　　　トランザクション 40KB/秒 × 1/2倍 = 20KB/秒
　Write
　　　強力整合性　1WCU　＝　1 KB/秒
　　　強力整合性 1 KB/秒 × 10RCU = 10KB/秒
　　　トランザクション 10KB/ × 1/2倍 = 5KB/秒

(例)5,000RCU 500WCU　テーブル：50GB
　(500/1000）+（5000/3000）= 2.1〜3 ≒ 3パーティション
　50GB  / 10GB = 5パーティション
　MAX(3,5) = 5パーティション


https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/ProvisionedThroughput.html

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-partitions-adaptive

## DynamoDBとQLDBはVPC 内にない
DynamoDB や Amazon QLDB などのデータベースサービスは VPC 内で実行されない

- QLDB はインターフェイスエンドポイント使用（ENI）
- DynamoDB はゲートウェイエンドポイント使用

## DynamoDBグローバルテーブル
- テーブル名、LSI、GSIがリージョン間で一貫
- TTL設定がリージョン間で一貫
- 暗号化設定がリージョン間で一貫
- DynamoStreamが有効
- DynamoDB Auto Scaling有効またはオンデマンドキャパシティ有効

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/V2globaltables_upgrade.html

## Redshiftへデータ移行
- DMSでデータ移行
　ダウンタイム最小限、ペタバイト規模のデータウェアハウスに統合可能
　移行方法：データ元　→　DMS　→　S3　→　DMS　→　RedShift　※S3を使用

- KinesisDataStreamsでデータ移行
　１秒に数ギガバイトのデータをキャプチャし、移行可能
　ただし、Redshift側で予想されるデータ処理のためにシャドーを手動でプロビジョニングが必要

- EMRでデータ移行
　大量のデータを処理可能。Redshiftにコピーするためのカスタム移行ジョブの開発が必要

https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.Redshift.html

https://aws.amazon.com/jp/premiumsupport/knowledge-center/dms-redshift-target-endpoint/

## ElastiCacheの用途
- 複雑な計算が必要となるデータをキャッシュ
- Pub/Sub
- ランキングボード
- 位置情報
- セッションストア
- リーダーボード

## ElastiCache for Redisの不正アクセス保護
- auth-tokenを使用する
- 転送中と保存中のデータの暗号化
- セキュリティグループのインバウンド設定（指定のポート許可）


https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-vpc-accessing.html

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/encryption.html

## QLDBのリアルタイム検索
Amazon Kinesis Data Streamsにリアルタイム配信可能
- リアルタイム分析 
- 履歴分析
- ワード検索（ElasticSearchに登録）

https://docs.aws.amazon.com/ja_jp/qldb/latest/developerguide/streams.html

## CloudFormationの複数リージョンでデプロイ
スタックセットを介してテンプレートを複数のリージョンにデプロイ

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html

## セキュリティ

保管中のデータの暗号化
- RDS　 ：任意
- Aurora：任意
- ElastiCache：任意
- DocumentDB：任意
- Neptune：任意
- Redshift：任意
- DynamoDB：デフォルトで暗号化
- QLDB：デフォルトで暗号化（※CMKのサポートなし）

転送中のデータの暗号化
- RDS　 ：任意（証明書の設定が必要）
- Aurora：任意（証明書の設定が必要）
- ElastiCache：任意（パフォーマンス影響有）
- DynamoDB：TLS
- DocumentDB：任意（TLS）
- DocumentDB：TLS
- Redshift

## 最後に
なかなかデータベースの勉強大変ですね。
ユースケース等を調べたり、違いを理解したり。。
実際にコンソール触って、RDSやAuroraのイメージを理解する必要があると感じました。