はじめに
AWS認定 データベース - 専門知識受験のために整理した勉強メモです。
- 受験当時の私の知識がベースになっているため、網羅的な内容になっていないことをはじめにお断りしておきます。
参考文献
各サービス
Amazon Aurora
- クエリ並列化するとパフォーマンス向上
- ストレージが分散されているため
- ストレージ自動縮小
- クラスターキャッシュ管理
- レプリカにキャッシュ情報が同期。フェイルオーバ時のパフォーマンス影響を低下
- グローバルデータベース
- 遅延は1秒以内
- リージョン間フェイルオーバは1分未満
- RDSのクロスリージョンレプリは1秒以上の遅延の可能性
- クロスリージョンレプリケーション
- グローバルデータベースの方が同期が高速
- クローン
- スナップショット復元より高速
- インスタンス部分のみコピー
- ソースデータベースとデータ共有、データの変更が発生したら別ストレージ領域を使用するため高速に作成できる
- 別アカウント、別VPCに共有可能。サブネットは同じAZである必要がある
- バックトラック
- ターゲットバックトラックウィンドウ
- データ更新量が多い場合設定時間以下になる可能性も
- 上限72時間
- MySQLのみ
- クラスタ作成時またはスナップショット復元時のみ設定可能
- ターゲットバックトラックウィンドウ
- S3エクスポート/インポート
select into outfile s3load data from s3
- データベースアクティビティストリーム
- Kinesis Data Streamsに連携
- Cloudwatch Logsよりリアルタイム
- データベース接続、SQLコマンド、監査ログ
- サードパーティサービスなどへ連携可能
- 監査
- 高度な監査
- ユーザー監査イベント
- CONNECT: 接続, 成功, 失敗
- QUERY: 全てのクエリ
- QUERY_DCL: GRANTなどデータ制御言語(DCL)
- QUERY_DDL: CREATE,ALTERなどデータ定義言語(DDL)
- QUERY_DML: INSERT,UPDATEなどデータ操作言語(DML)
- TABLE: クエリ実行の影響を受けたテーブル
- データベースアクティビティストリーム -> Kinesis data streams -> サードパーティ製ツール
- 意図的なフェイルオーバ
- フェイルオーバーアクション
- 障害挿入クエリ（内容によってはフェイルオーバにならないことも）
- DBインスタンスのクラッシュ
- レプリカ障害
- ディスク障害
- ディスク輻輳
- フェイルオーバ優先度
-
0が一番高い
-
- フェイルオーバ順
- 優先度が高い
- 優先度同じならインスタンスクラス大きい
- 優先度とクラス同じならランダム
-
ゼロダウンタイムパッチング
-
バックトラックとポイントインタイムリカバリ(PITR)の違い
- バックトラック：特定の時点まで巻き戻す。バックアップからの復元なし。新しいクラスターは作成されない
- 72時間が限度
- PITR：特定の時点の新しいクラスターを作成
- バックトラック：特定の時点まで巻き戻す。バックアップからの復元なし。新しいクラスターは作成されない
-
マルチマスタークラスター
- 単一リージョンのみ
- インスタンス障害時も書き込み継続可能。フェイルオーバがそもそもない
- MySQLのみ
- インスタンス数は最大
2 - インスタンス停止不可
- 通常クラスターより書き込みパフォーマンスが落ちることも
- バックトラック利用不可
- 書き込み性能向上ではなく、書き込み可用性向上が目的
-
ローカルストレージ不足
- セッションの一時テーブルやログはローカルストレージが使われる。インスタンスタイプによって固定
- FreeLocalStrageメトリクスを監視 -> 不足するようならインスタンスタイプ変更を検討
-
SQLでLambda関数実行
- MySQLのみ
- 同期、非同期呼び出し
SELECTでsagemaker,comprehend呼び出し
-
Amazon Aurora Serverless
- マネコンからSQL実行（Query Editor）
- APIでJSON形式でデータ取得（Data API）
- マルチAZ未対応
- グローバルデータベース未対応
- 1ACUは2GBメモリ
AWS CloudFormation
- deletionpolicy
- retainでスタック削除時にRDSインスタンス保持
- snapshotでスタック削除時にスナップショット取得
- deletionprotection
- trueでRDSインスタンス削除保護有効
- terminationprotectionはEC2
- deleteautomatebackups
- falseでRDSインスタンス削除時の自動バックアップ削除無効化
- 変更セットで事前確認
- スタックポリシーで変更拒否
- ドリフト検出は手動変更を検出
Amazon QLDB
- QLDBストリーム -> Kinesis Data Streams -> Amazon Elasticsearch Serviceで全文検索
AWS DMS
- 移行後のデータ検証が可能
- LOB移行
- 1つのレコードのLOB列もそれ以外の列も1つのタスクで移行される
- 完全LOBモード
- 全部移行するがパフォーマンスが悪化する可能性
- 制限付きLOBモード
- 最大サイズを指定することでパフォーマンス向上
- 指定サイズを超えるLOBは手動移行
- フルロードで既存データレプリケーション -> データキャプチャ（CDC）でフルロード中の差分をレプリケーション
AWS SCT
- 移行前評価レポート
- データ抽出エージェント
- 障害時は別サーバに同じ設定でエージェントをインストールすればジョブが再開
Amazon RDS
- リードレプリカ
- リードレプリカは一時停止できない
- リードレプリカを持つインスタンスは一時停止できない
- リードレプリカを作成するためにはソースインスタンスの自動バックアップを有効にする
- 暗号化されていないインスタンスの暗号化
- スナップショット作成 -> スナップショットコピー時に暗号化 -> 暗号化スナップショットから暗号化インスタンス作成
- 性能
- EBS最適化、プロビジョンドIOPSストレージ、インスタンスの最大帯域幅
- 意図的にフェイルオーバ
- フェイルオーバのオプションを指定して再起動
- セキュリティ
- IAM権限
- ディスク暗号化
- 通信暗号化
- パッチ適用
- マルチAZだとフェイルオーバのダウンタイムのみ
- レプリカ遅延
- マスター側の書き込みクエリが遅い、遅延ロード、メトリクス
ReplicaLagで確認
- マスター側の書き込みクエリが遅い、遅延ロード、メトリクス
- クロスリージョンスナップショット
- 従来：スケジューリングしたLambda関数でスナップショット取得 -> 別リージョンへコピー
- 現在：AWS Backupで可能
- Lambda関数のRDS接続の考慮ポイント
- Lambda関数の最大同時実行数
- DBの最大同時接続数
- Amazon RDS Proxy利用
- RDSインスタンスクラス（max_connectionsはインスタンスクラスに依存）
Amazon ElastiCache
- Redis
- スケーリング
- クラスターモード無効：ノードのスケールアップ
- クラスターモード有効：シャード追加（スケールアウト）とノードのスケールアップ
- クラスターモードはあとで変更できない
- セキュリティ
-
redis authによる認証
-
- バックアップパフォーマンス向上
- リードレプリカからバックアップする
-
reserved-memory-percent（デフォルトで25%）が使われるので、バックアップ時高負荷になる場合、増やす - https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/backups.html
- スケーリング
Amazon DocumentDB
- Auroraに似ている
- ストレージ自動拡張、10GBごと最大64TB
- リードレプリカ
- ストレージはプライマリDBと共有しているため読み取りリクエストの処理能力が高い
- エンドポイント
- クラスターエンドポイント
- プライマリDB
- 読み込みエンドポイント
- DNSラウンドロビンでリードレプリカへアクセス
- インスタンスエンドポイント
- 各DBインスタンスごと
- クラスターエンドポイント
- アクセス制御
- ユーザ名とパスワード
- データベースユーザごとにロールベースアクセスコントロール可能
- SecretsManagerを使用してパスワードの自動ローテーション可能
- ユーザ名とパスワード
- 監査
- パラメータグループで
audit_logsの値を1に - Cloudwatch Logsに送る
- パラメータグループで
- コスト
- 手動停止可能。1週間経ったら自動起動
- バックアップストレージ
- 容量が100%を超えるまでは追加料金はかからない。500GBのインスタンスなら500GBまでのバックアップは無料
- データ転送
- メンテナンス
- クラスター、インスタンスの設定変更
- ダウンタイムあり
- インスタンス識別子の変更
- インスタンスクラスの変更
- ダウンタイムあり
- クラスター、インスタンスの設定変更
- バックアップ
- 自動バックアップ
- 自動スナップショットとトランザクションログがバックアップウィンドウ中に取得される
- バックアップ保持期間（1-35日）分の増分バックアップ
- バックアップ開始の影響
- シングルAZ：数秒間のIO中断
- マルチAZ：数分間のレイテンシー上昇
- クラスター削除時に削除される
- 手動スナップショット
- 復元は新しいクラスターになる
- 自動バックアップ
- プロファイラー
- プロファイリングされたコマンド、時間、プランの概要、クライアントメタデータがCloudwatch Logsに
- DB変更ストリーム
- データベース内のコレクションに対する変更イベントのログを重複なく順序を維持
- 7日間保持
- Lambdaなどで取得してESに流すなど
Amazon DynamoDB
- パーティション
- データ領域
- 自動拡張
- テーブル内のパーティションキーから得られたハッシュキーをもとにデータを格納するパーティションが決まる
- プライマリキー
- テーブル全体で一意
- パーティションキー単体、パーティションキーとソートキーの複合
- ローカルセカンダリーインデックス
- 同一のパーティションキーを持つデータを別の基準で絞り込みたい場合
- テーブル作成時のみ
- パーティションキーのみのテーブルには定義できない
- ベーステーブルからキャパシティーユニットを消費
- テーブルとインデックスの合計が10GBまで
- https://dev.classmethod.jp/articles/conceptual-learning-about-dynamodb-lsi/
- グローバルセカンダリーインデックス
- 異なるパーティションキーを持つItemを含むデータ群から絞り込みたい場合
- パーティションキー単体、パーティションキーとソートキーの複合
- キーを一意にする必要がない
- プライマリキーで検索できないパターンのキーの組み合わせを用いる場合に使う
- サイズ制限なし
- テーブル作成時、作成後の追加も可能
- 結果整合性のみ
- キャパシティーユニットは元テーブルとは別。デフォルトでは元テーブルと同じだが1.5倍が推奨
- https://dev.classmethod.jp/articles/conceptual-learning-about-dynamodb-gsi/
- グローバルテーブル
- 名前が同じ
- 書き込みキャパシティー管理設定が同じ
- 同じパーティションキーがテーブルに含まれている
- DynamoDBストリームが有効
- 暗号化設定がリージョン間で一致
- TTL設定がリージョン間で一致
- グローバルセカンダリインデックスがリージョン間で一致（インデックス名、パーティションキー名、ソートキー名）
- 書き込みキャパシティーユニットで
autoscalingまたはオンデマンドが有効
- TTL
- 有効期限切れから48時間以内の削除
- トランザクションは最初に書き込みがあったリージョンのみ
-
トランザクション
- 複数の書き込み・読み込み処理をグループ化し、それらが全て正常に完了するかもしくは何も行わないか
- オールオアナッシングオペレーション
- TransactWriteItems(書き込み)
- TransactReadItems(読み込み)
- 最大25の処理をグループ化
-
リストア
- 以下は復元後に手動設定が必要
- AutoScalingポリシー
- IAMポリシー
- Cloudwatchのメトリクス、アラーム
- タグ
- ストリーム設定
- TTL
- PITR用バックアップは元テーブルが削除されると消える
- 以下は復元後に手動設定が必要
-
モニタリング
- AWS CloudTrailの設定でデータ操作の履歴も取得可能
-
キー・インデックス
Amazon Redshift
- 暗号化スナップショットを別リージョンにコピーする場合、コピー先リージョンのマスターキーに対するスナップショットコピー許可を指定
ソリューション
マルチリージョンソリューション
- DynamoDBグローバルテーブル
- 各リージョンのレプリカで読み書き可能。トランザクションは最初に書き込みがあったリージョン内のみサポート
- Auroraグローバルデータベース
- 各リージョンのレプリカで読み込み可能。トランザクションは1つのリージョンに存在するプライマリDBインスタンスのみサポート
EC2上のSQL Serverのモニタリング
-
CloudWatch Application Insightsを利用
自動スナップショットのクロスアカウントコピー
- 自動スナップショットは別アカウントに共有できないため、コピーした手動スナップショットを作成
- AWS管理CMKで暗号化されたスナップショットは別アカウントに共有できないため、コピー先アカウントの権限を付与したカスタマー管理CMKを指定してコピーした手動スナップショットを作成
オンプレからのデータベース移行
- SCTでスキーマ変換、DMDフルロード、差分データのCDC変更タスク
- 移行前の評価はSCT、移行後の検証はDMS
- AWS Direct Connectなどの専用NW経由
- SCTとDMSでNW経由で移行
- 1Gbpsで1日に最大約10TB
- AWS Snowball利用
- SCTとDMSでAWS SnowballからS3 -> DBにロード
- AWS SnowballEdgeは100TB(利用可能：83TB)で1週間
- SCTとDMSでAWS SnowballからS3 -> DBにロード