Jのブログ

人生の記録

AWS Certified Database - Specialty Practice 勉強しました記録

AWS Certified Database - Specialty Practice 受験しました。 勉強したことをメモしておきます。

ToDo

よくある質問、Blackbelt、AWSドキュメントを読む

  • [x] DMS・SCT(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] KMS(blackbelt未、よくある質問する未、AWSドキュメント未)
  • [x] DynamoDB(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] Neptune(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] DocumentDB(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] Elasticache(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] Aurora/Global/Serverless(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] パフォーマンスインサイト(blackbelt無、よくある質問済、AWSドキュメント未)
  • [x] RDS(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] AWS Backup

後で読む

AWS環境操作

RDS/Aurora

  • [x] DBへの接続方法(認証方式、IAM認証、Lambda実行、SSL)
  • [x] aurora IAM認証
  • [x] aurora パラレルクエリー
  • [x] aurora バックトラック
  • [x] 暗号化スナップショットのリージョン間コピー
  • [x] Aurora Multi Master/Global/Serverless/リードレプリカ論理/Parallel Query
  • [x] DBエンジン間の移行、EC2からの移行、mysqlからauroraへの移行
  • [x] バックアップリストア、rds、dynamo 、 elasticach
  • [x] aurora グローバルデータベースの作成(別リージョンへの物理的なリードレプリカ)
  • [x] Auroraクロスレプリケーションインスタンスに対するリードレプリカの追加
  • [x] Auroraクロスレプリケーション(物理/論理)
  • [x] aurora サーバーレス作成
  • [x] 別リージョンへのリードレプリカ作成
  • [x] 別リージョンへの移行、暗号化インスタンス
  • [x] 拡張メトリクス有効化、cwlogs確認

インスタンス構築、バックアップ、冗長化、暗号化、DR

  • [x] SCT
  • [x] DMS
  • [x] Elasticache
  • [x] Neptune
  • [x] DocumentDB
  • [x] DynamoDB

DynamoDB

  • [x] Dynamodb オンデマンド
  • [x] ローカルセカンダリインデックスの作成とGetItem
  • [x] グローバルテーブル
  • [x] GSIの設定
  • [x] LISの設定

ElastiCache

  • [x] アプデ、アプグレ(エンジンはサービス更新、インフラは継続的な管理メンテナンスで必須)
  • [x] ノードが置き換え対象となった場合に実行可能なアクション
  • [x] 通信暗号化
  • [x] データ暗号化
  • [x] バックアップ・リストア

模擬試験

Udemyの正解が間違っているケースがたくさんありました。自分を信じていきましょう。

試験の時間配分

  • 180分
  • 65問
  • 2分/1問 + 見直し50分
  • 悩んだ問題はフラッグ立てて、後から新しい目で見直す

勉強ノート

RDS

  • DBプロキシ: プーリング機能の保持、フェイルオーバーの高速化
  • リードレプリカ、ソースDB削除
  • シャーディング: 1インスタンス以上のパフォーマンスを得たいばい
  • 移行
  • ポイントインタイムリカバリ。戻したい時間を指定して、インスタンスを新規作成

Aurora

  • Auroraへの移行
    • mysqldump
    • RDS スナップショット
    • Aurora リードレプリカ作成、昇格
    • DMS
    • S3インポート
  • リージョンレベルのフェイルオーバーは手動
  • フェイルオーバー動作
    • 読み込み：一時中断、新プライマリへ割り当て。障害発生したノードが復旧後、リードエンドポイントは復旧ノードへ
    • 書き込み：フェイルオーバーし、昇格した新プライマリノードへ
  • レプリケーション
  • MultiMaster： 複数のAZに渡って、書き込み性能をスケールアウトできる
  • Aurora Serverless
    • コスト効率、予測不能なスケール、不定期利用などがメリット
    • Auroraクラスタからの移行は、スナップショットを利用
    • VPC内からのみ接続可能
    • 事前に特定のキャパシティを明示できる
    • ロングトランザクションや、テーブルロックなどにより自動スケールできない時がある
  • Database Cloning: コピーオンライト方式でクローン。完全なコピーではないので、データ容量への影響がほぼない、本番への影響もない。本番データを使った、検証、分析、DBの再構成などに利用
  • Parallel Query
    • 分析クエリ(OLAP)の高速化
    • 分析クエリの処理をストレージレイヤ内の数千ものCPU分散する。インスタンスへのデータ転送量も減るため高速化される。また既存のOLTPへの影響は出ない。
    • Aurora MySQLのみ対応
  • バックトラック：戻したい時間を指定して復元、インスタンスが新規作成されず既存のデータベースのデータが戻る。テーブル単位での巻き戻しはできない。
  • RDS MySQL/Aurora MySQLは、S3上のバックアップデータ(Percona XtraBackup )からリストアが可能
  • AuroraではRAMを利用した、アカウント間でのインスタンスをクローン化(データ更新した分だけ料金が発生する)
  • グローバルデータベース
  • IAM認証
    • RDSへユーザー追加、aws rds generate-db-auth-tokenでトークン取得、mysql コマンドに証明書とcleartext-pluginを指定し接続する

DynamoDB

  • 1キャパシティ：リード4KB、ライト1KB
    • 強い結果整合性の場合は、キャパシティを2倍使う
  • パーティションキー設計をうまくやらないと、偏りが発生してパフォーマンスが出ないことがある
  • キャパシティは過去300秒までリザーブする。このリザーブを使ってバーストすることができる
  • LSI(Local Secondary Indes)：キーは固定、ソートキーを追加できる
  • GSI(Global Secondary Indes)：キー自体を追加できる
  • Point in Recoveryに対応している。復元したい時間を指定して、新しいテーブルを作成
  • AWS Backupによるバックアップに対応している
  • アダプティブキャパシティ：アクセス頻度の高いデータは別パーティションに自動で分離する
  • DynamoDB オンデマンド：既存テーブルの移行可能、事前のキャパシティ設計不要でプロビジョニング。クエリごと単位での確認

mamcached

  • コンフィグレーションエンドポイントにノードリスト。aouto discovery ライブラリで、アプリ側でノードの追加削除を自動検知
  • マルチコア

redis

  • クラスター無の場合は、RDS同様なフェイルオーバー方式
  • バックアップ リストア
    • スナップショット
    • スナップショットからRDBファイルをS3へエクスポート
    • スナップショット、RDEファイルからリストア
  • シングルコア
  • 監視: CPU、メモリ使用率、Eviction(キャッシュアウト数)、キャッシュヒット率、swap、レプリカラグ
  • redisクラスター
    • シャード単位で分散、最大15シャードまでスケール
    • クラスタ専用のライブラリ、クライアント側でマッピンを保持
    • シャードごとに最大5つのリードレプリカ
    • プライマリノード障害時は、リードレプリカがプライマリへ昇格、フェイルオーバー
    • ダウンタイム0で、シャードの増減が可能、オンラインリサイズ機能
  • 暗号化: クライアント間通信、S3とディスク上のバックアップファイルを暗号化

DocumentDB

Neptune

  • アーキテクチャはAurora
  • データ移行は、S3またはDMS
    • S3:ノード用のCSV、エッジ用のCSVをそれぞれ用意する
  • 対応言語
    • Apache TinkerPop Gremlin (ノード、エッジ、プロパティ)
    • RDF(主語、述語、目的語)、プロパティは述語と目的語で追加していく
    • 両方のエンドポイントポイントをそれぞれ用意されているが、データは共通ではない
  • インデックスは自動管理、ユーザーで変更できない
  • OLTP、OLAP両方対応できる
  • クロスリージョンレプリカは非対応
  • 暗号化されてないデーベースの移行には、新規インスタンス作成後、データ移行が必要
  • リーダーエンドポイントには負荷分散機能がない。アプリ側で分散するか、Route53を利用する

DMS

  • フルロード
    • DBソース：1万行8テーブルのSELECT > INSERT
    • To Redshift：1万行8テーブルのSELECT > CVS to S3 > Redshift Copy
    • S3ソース：
  • フルロードの監視：CPU、Swap、メモリ、ストレージの空き、ネットワーク帯域
  • CDC(変更データキャプチャ)
    • CDCの開始時間を指定する
    • ソースDBのトランザクション(バイナリログ、WAL、REDOログ)を5秒間隔でキャプチャ
    • DMSがSQLへ変換、トランザクションコミット順にターゲットDBへ実行
    • 接続できな、遅い、フルロードが未だなどの場合は、DMSでキューイング
    • the_endなどマーカーを入れておくと、同期の確認ができる
  • フルロード + CDC
    • フルロード中の更新をキャプチャ
    • フルロード完了後、キューイングした1の更新を適用
    • 完了後は、トランザクションとして更新を適用
  • CDCの監視：
    • CDCChangeDiskSource(ソースのコミット待機数)が多い場合は、ディスクサイズをあげる(キューイングが多く発生するため)
    • CDCChangesDiskTarget(ターゲットのコミット待機数)はターゲットの処理能力が原因の可能性
    • CDCLatencySource(ソースDB実行完了から、DMSがキャプチャするまでのラグ)
    • CDCLatencyTarget(キャプチャからターゲットへ適用するまでのラグ)
  • 暗号化されたデータの読み書きが可能
  • SCT
    • スキーマ変換、複雑性分析、RDSでの制約、アプリのSQL変換、プロシージャの変換、データウェアハウスをRedshiftへ移行