はじめに
試験対策に備忘録として、
分かりにくい
間違えやすい
箇所をメモを記載していく
目次
- 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 インスタンスプロファイル認証情報を使用してデータベースにアクセス可能
RDS作成時にバックアップ保持期間
コンソールを使用してDBインスタンスを作成
→ デフォルトのバックアップ保持期間は7日
Amazon RDS APIを使用してDBインスタンスを作成
→ デフォルトのバックアップ保持期間は1日
※Auroraのデフォルトのバックアップ保持期間は1日
RDSのリードレプリカ作成
- 作成方法
RDSはプライマリのDBインスタンスからスナップショットを作成して、リードレプリカを作成
※スナップショット作成時に、プライマリDBインスタンスのI/Oが一定時間停止
RDSのマルチAZ配置の場合
スタンバイDBインスタンスからスナップショットを作成するため、I/Oの停止を回避できる
- 自動バックアップを有効（保持期間を0以外の値に設定）
- 既存の第1層からリードレプリカ作成
RDS（MYSQL） → 既存リードレプリカのリードレプリカを作成可能
RDS（MYSQL）以外 → 既存リードレプリカのリードレプリカを作成不可
RDS（MySQL、PostgreSQL）をAuroraへ移行
Aurora Readレプリカを使用して、MySQL用のAmazonRDSDBインスタンスからAmazonAuroraに移行
①RDS(MySQL)でAuroraリードレプリカ作成
②Auroraリードレプリカを昇格
RDS（MySQL）のスキーマ変更
RDS（MySQL）のリードレプリカのスキーマ変更等ができるため、下記の手順でDDLを反映する
①リードレプリカ作成
②リードレプリカのDBパラメーターグループでread_onlyパラメーターを「0」に設定
①リードレプリカにDDL操作を実行
②リードレプリカをDBインスタンスに昇格
※昇格時、プライマリDBの書き込みを停止し、リードレプリカの更新を待つ
RDSのDR対策
- 目標復旧時間（RTO）
災害後に作業状態に戻るのにかかる時間 - 目標復旧時点（RPO）
RPOは時間単位でも表され、災害が発生したときに失われる可能性のあるデータの量
（例）RPOが1時間の場合、災害が発生したときに最大1時間分のデータが失われる可能性
自動バックアップ
- DBインスタンスの最初のスナップショットには、完全なDBインスタンス
※その後、増分スナップショット - 特定の時間指定ができない（8時間単位にランダム）
- マルチAZ構成の場合、プライマリへの影響を減らすために、スタンバイでバックアップが実行
- バックアップ保持期間は、PITR（ポイントタイムリストア）が可能
- DBインスタンス削除時、同時に削除される（※削除しない方法もあり）
- クロスリージョン自動バックアップをサポート
手動バックアップ
- リージョンごとに最大100スナップショット
- 自動的に削除されない
- 複数のリージョンでサポート
- 最大20のAWSアカウントと共有可能
RDSのモニタリング
- Amazon RDS Performance Insights
パフォーマンスの問題を分析し、解決するのに役立つ、データベースのパフォーマンス情報
- Trusted Advisor
RDSアイドルDBインスタンス、RDSセキュリティグループアクセスリスク、RDSバックアップ、RDSマルチAZをチェック
- Amazon RDS EnhancedMonitoring（拡張モニタリング）
DB インスタンスのオペレーティングシステムをリアルタイムでモニタリング
RDSのメンテナンス
-
ハードウェアのメンテナンス
シングル AZ 配置の場合、ダウンタイムあり。
マルチ AZ 配置の場合、メンテナンスのAZによって影響が変わる。セカンダリのAZメンテナンスであれば、影響なし。 -
OS のメンテナンス
延期可能
マルチ AZ 配置で対応し、セカンダリインスタンス適用後、フェールーバーし、プライマリインスタンス更新 -
DB エンジンレベルのアップグレード
プライマリ DB インスタンスとスタンバイ DB インスタンスの両方が同時にアップグレード
ダンタイム必要
RDSリソースの削除防止
CloudFormationの下記を設定し、リソースの削除を防止
-
RDSのインスタンス削除保護
DeleteProtectionが「true」設定 -
スタック削除時、RDSのインスタンス削除保護
DeletionPolicy属性に「Retain」設定 -
万が一削除された場合を考慮して、自動バックアップは削除しない
DeleteAutomatedBackups属性に「False」設定 -
スタックそのもの削除保護
・コンソールでスタックの「termination protection」を有効化 -
スタックが意図せずに更新または削除されるのを防止
・スタックポリシーを設定
RDSでTrustAdvisor
5カテゴリで問題を検知する
※メール通設機能設定、CloudWatchEvent(trustAdvisorEvent)→SNS通知
コストの最適化
- 長期間使用されていないDBインスタンスの検出
提案アクション：スナップショット作成後、インスタンス削除 - RDS の利用状況をチェック
提案アクション：リザーブドインスタンスの購入提案
セキュリティ
- RDSのセキュリティグループをチェック
- RDSのスナップショットが公開に設定されているチェック
耐障害性
- 自動バックアップのチェック
- 単一AZのRDSをチェック
Auroraの暗号化
Aurora → スナップショット → Aurora（暗号化）※リストア時にKMSキー指定可能
RDS → スナップショット → 暗号化スナップショット → RDS（暗号化）
Auroraのクローン
- クローンはコピーではない。
- 同一リージョン内の同一AZでのみ作成可能（※VPCは異なってもOK）
- Aurora Serverless v1 DBでクローン可能
- 最大15個まで
- クロスアカウントのクローン作成可能
Auroraのバックトラック
- クラスター作成時、リストア時のみ設定可能
- 最大72時間
- 既存のDBクラスターに反映
- 単一テーブルのみ選択し、戻すことは不可
Auroraの一時停止
すべてのリードレプリカを削除後、プライマリRDSDBインスタンスを停止する
※DB インスタンスは最大 7 日間停止。その後、自動起動
Auroraのリードレプリカが遅い原因
レプリケーションでタイムラグがあり、遅延する原因
- クラスターで書き込みアクティビティの突然の急増
- リードレプリカのクラスター内のインスタンスが小さい
- リードレプリカに複数のセッションが同時アクセス
- ネットワークの通信障害
調査
- AuroraReplicaLag メトリクスでタイムラグを測定可能
- 拡張モニタリングでCPU使用率、DBコネクションの監視
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パーティション
DynamoDBとQLDBはVPC 内にない
DynamoDB や Amazon QLDB などのデータベースサービスは VPC 内で実行されない
- QLDB はインターフェイスエンドポイント使用（ENI）
- DynamoDB はゲートウェイエンドポイント使用
DynamoDBグローバルテーブル
- テーブル名、LSI、GSIがリージョン間で一貫
- TTL設定がリージョン間で一貫
- 暗号化設定がリージョン間で一貫
- DynamoStreamが有効
- DynamoDB Auto Scaling有効またはオンデマンドキャパシティ有効
Redshiftへデータ移行
-
DMSでデータ移行
ダウンタイム最小限、ペタバイト規模のデータウェアハウスに統合可能
移行方法：データ元 → DMS → S3 → DMS → RedShift ※S3を使用 -
KinesisDataStreamsでデータ移行
１秒に数ギガバイトのデータをキャプチャし、移行可能
ただし、Redshift側で予想されるデータ処理のためにシャドーを手動でプロビジョニングが必要 -
EMRでデータ移行
大量のデータを処理可能。Redshiftにコピーするためのカスタム移行ジョブの開発が必要
ElastiCacheの用途
- 複雑な計算が必要となるデータをキャッシュ
- Pub/Sub
- ランキングボード
- 位置情報
- セッションストア
- リーダーボード
ElastiCache for Redisの不正アクセス保護
- auth-tokenを使用する
- 転送中と保存中のデータの暗号化
- セキュリティグループのインバウンド設定（指定のポート許可）
QLDBのリアルタイム検索
Amazon Kinesis Data Streamsにリアルタイム配信可能
- リアルタイム分析
- 履歴分析
- ワード検索（ElasticSearchに登録）
CloudFormationの複数リージョンでデプロイ
スタックセットを介してテンプレートを複数のリージョンにデプロイ
セキュリティ
保管中のデータの暗号化
- RDS ：任意
- Aurora：任意
- ElastiCache：任意
- DocumentDB：任意
- Neptune：任意
- Redshift：任意
- DynamoDB：デフォルトで暗号化
- QLDB：デフォルトで暗号化（※CMKのサポートなし）
転送中のデータの暗号化
- RDS ：任意（証明書の設定が必要）
- Aurora：任意（証明書の設定が必要）
- ElastiCache：任意（パフォーマンス影響有）
- DynamoDB：TLS
- DocumentDB：任意（TLS）
- DocumentDB：TLS
- Redshift
最後に
なかなかデータベースの勉強大変ですね。
ユースケース等を調べたり、違いを理解したり。。
実際にコンソール触って、RDSやAuroraのイメージを理解する必要があると感じました。