「AWS認定 データベース-専門知識」の受験記録(DBS-C01)

カテゴリ: aws | タグ: , ,

前置き

  • AWS認定試験の[DBS-C01]データベース-専門知識(AWS Certified Database – Specialty)を勉強して合格した。
  • 新しく学んだことや、間違えやすい・忘れやすいポイントをメモしながら勉強していて、定期的に振り返るのが良かった。
  • せっかくメモをまとめたので、これから勉強する人のための助けになるかもしれないと思い、このドキュメントを作成した。

勉強開始時の知識

  • AWS認定のアソシエイトレベル3つのソリューションアーキテクト、デベロッパー、SysOpsアドミニストレーターは全部合格済み
  • 情報処理技術者試験のデータベーススペシャリスト 合格済み (だけど、この知識はDBS-C01の合格にはあまり関係しない)
  • AWSの実務経験は3年ぐらい。バックエンドエンジニアなのでAWSには精通してないけど、なんとなくで操作して0からシステム構築することはできる。

勉強期間

  • 勉強時間は当初１ヶ月ぐらいで考えていた

    • 勉強を始めるタイミングで先に受験の予約をしてしまい、試験を受けなければいけないプレッシャーをトリガに勉強していた。

  • だけど、途中で仕事が忙しくなって、１ヶ月ほど伸ばした

  • 一回で合格でき、かつ理解も深まったので、この決断は結果的には良かった

試験で問われるAWSサービス

何のサービスが問われるかは、後述の書籍とUdemy講座の目次を見るとだいたい分かる。

重点的に勉強すべきなのは下記のサービスで、後のものはざっと見ておけば良い。

  • RDS、Aurora
  • DynamoDB
  • DMS
  • SCT
  • Redshift
  • ElastCache
  • Cloud Formation

勉強で使った教材

書籍

要点整理から攻略する『AWS認定 データベース-専門知識』

AWS 認定試験は、AWSに関する知識・スキルを測るための試験です。レベル別・カテゴリー別に認定され、基礎コース・アソシエイト・プロフェッショナルの3つのレベルと、ネットワークやセキュリティなど分野ごとの専門知識（スペシャリティ）があります。
本書の対象であるAWS認定データベースのような専門知識を問う認定試験は年々増えています。これはAWSのサービスが多岐にわたり、一人の人間ですべてをカバーする事が難しくなっているためでしょう。専門分野の認定をすることにより、個人の得意とすることを客観的に証明できます。今後、ますます重要になってくるのが、この専門分野、スペシャリティでしょう。

  • 2021/12時点で、AWS認定 データベース-専門知識に関する書籍はこれしかない。
  • 試験まで書籍の通読を2回転した。
  • 巻末の模擬試験を3回解いた。
    • 1回のサイクルは、全部問題を解く -> 間違えた問題の番号を控える -> 日を改めて間違えた問題だけを解く -> 更に間違えたら番号を控え直す -> 全部、正解できるまで繰り返す。

Udemy[講座]

Ultimate AWS Certified Database Specialty

Pass the AWS Certified Database Specialty Certification DBS-C01. Learn RDS, Aurora, DynamoDB, DMS, ElastiCache in depth

  • Stephane Maarekさんが出している教材
  • このコースは、Riyaz Sayyadさんという別の人が行っている
    • ちょっと英語が聞きづらい時があるけど、しゃべるのがゆっくりなので1.25倍で再生して聞いていた
  • (自分としては珍しく)このUdemy教材は100%完走できた!!

Udemy[模擬試験]

Practice Exam | AWS Certified Database Specialty

Prepare for your DBS-C01 exam. 65 high-quality practice test questions written from scratch with detailed explanations!

  • こちらもStephane Maarekさんが出している教材
  • 問題をすべてAnkidroidに登録して繰り返し解いた
  • はじめのうちは英語のまま読んで解いていたけど、読むのに時間がかかるので面倒になってきた。なので途中からmac版Anki・DeepLを2つ横に並べて、翻訳しながら解いていた。

AWSチュートリアル

書籍の1回目の通読とUdemyの視聴が終わった後に、下記のチュートリアル一覧からカテゴリが"データベース"のものをいくつか実施した。

AWSで公開しているチュートリアルの一覧

  • 平日は10分チュートリアルを1つ実施して、土日に120分ぐらいのチュートリアルを1つすすめるペース感で実施。
  • RDSの起動・停止で待たされるので、意外と時間がかかる。
  • 複数のチュートリアルで学べる内容が重複しているしている場合があるので、チュートリアル全体をざっと見してから実際に取り掛かると良い。

学習メモ

ここに書いたのは、2021/12時点で学習した内容です。

AWSの機能は時とともに変わっていくので、参考程度にしてください。
もし内容が違っていたら(≒AWS機能が変わっていたら)本記事のコメントで指摘してもらえるとありがたいです。都度修正していきます。

RDS

RDS

  • CPU負荷が高いときの原因調査で使えるもの：クラウドウォッチの拡張モニタリングをオンにしてCPU負荷をみる、パフォーマンスインサイトの機能で発行されているクエリを確認
  • Multi-AZ
    • Multi-AZ構成の場合、それぞれのDBは同期レプリケーションとなる (Auroraの場合は非同期レプリケーション)
    • RDSにおけるMulti-AZ構成というのはスタンバイを別AZに置くことを意味する。リードレプリカの話ではない。
  • リードレプリカ
    • リードレプリカ起動直後にパフォーマンスが出ない場合、リードレプリカの情報を遅延読み込みしている可能性がある
      • プレウォーミングは必要ない
    • RDSのリードレプリカは、同じAZでも、別AZでも、別リージョンでも指定可能
    • リードレプリカを作る時、マスターインスタンスのスナップショットを取る必要があるため、短時間(１分以内ぐらい)サービスの停止が発生する。
      • マルチAZだとスタンバイDBからスナップショットを取るため、この小停止の発生を防ぐことができる。
    • リードレプリカをあえて遅延レプリケーションを有効にし、操作ミスによるデータ喪失に備えることができる。
    • プライマリの削除
      • RDS for MySQLのリードレプリカがあるときにプライマリインスタンを削除すると、レプリカは参照クエリのみ受け付ける。自動昇格しない。
      • RDS for PostgreSQLのリードレプリカがあるときにプライマリインスタンを削除すると、すべてのリードレプリカはスタンドアロンのDBに昇格し、読み書き可能になる。
  • Lambdaから大量のDB接続がある場合、下記の対策を検討する
    • RDSプロキシを利用する
    • Lamda側のConcurrent Execution数の引き上げを申請する
  • スナップショット
    • スナップショットを作ってインスタンスを作り直しても、肥大化したストレージを縮小できない
      • インスタンスを作り直して、AWS DMSなどでインポートし直す必要がある
    • 手動スナップショットは、リージョンごとに最大100まで取得できる。この上限数に自動バックアップの数は含まれない。自動バックアップの数に上限はない。
  • バックアップ
    • 自動バックアップをOffにすると、これまで取得していた自動バックアップも削除される
    • 手動バックアップが取れる件数に上限は無い
    • バックアップを24時間より短い周期で取りたい時は、自動スナップショットの機能は利用できない
    • スナップショットから復元する場合、RDSのパラメータグループとセキュリティグループは再設定する必要がある
  • IAMデータベース認証を使う場合、毎秒200回のコネクションが接続上限となる。
  • Multi-AZ構成の場合に、データベースのアップグレードされる時の要件は下記の通り
    • プライマリとスタンバイの両方のDBがアップグレードされる
    • アップグレードが完了するまで、サービスのダウンが発生してしまう
  • バックトラック
    • バックトラック機能を有効にして作成されたDBクラスターでは、バックトラック機能を有効にしてクローンDBクラスターを作成することができる。
  • ストレージ
    • RDSのストレージを増やしたい時は、Amazon RDS コンソール、AWS CLI、Amazon RDS API から設定値を変更できる
    • RDSのストレージ設定を変更するとステータスが一時的にstorage-optimizationになる。
  • gp2ボリュームの最大性能は16,000IOPS。これを超える場合はio1,io2を使う必要がある。
  • 開発用DBなどの目的でRDSを使っており利用頻度が低い場合は、スナップショットを作って未使用のDBインスタンスを終了すると、コスト削減できる。
  • 自動スナップショットを直接S3のバケットに移動させることはできない。手動スナップショットはS3へ移動できる。
  • DBをレプリケーションしていてネットワーク障害が発生している時、replicaLagの値は-1になる。(ラグが発生している秒数ではないので注意。master側の位置がわからないのでラグの度合いは算出できない)
  • RDSがパブリックアクセスできないことを監査・維持するためにAWS Configマネージドルールと、AWS Systems Manager Automationのrun bookが利用できる。
  • 未使用のRDSを特定したい場合、Trusted Advisorの「Amazon RDS のアイドル状態の DB インスタンス」をチェックすることで発見できる。
    • さらに、これをEventBridgeでトリガでき、SNS連携してメール通知できる。

RDS for PostgreSQL

  • オンプレミスの大量データをRDSにダウンタイムなしで移行するには下記の方法がある
    • pg_dump/pg_restreで一旦移行し、レプリケーションさせる。ラグがなくなったら移行完了。
    • データ量が大きすぎてネットワーク転送できない場合はSnowballでデータを送る。その後DMSのCDC(データ変更キャプチャ)で、差分を追従する。

RDS Aurora

  • クローン
    • クローン機能を利用して、本番サーバのデータを反映した開発用のDBを最小の手間で手に入れることができる。
    • データベースのクローン機能はAmazon Aurora DBでのみ利用可能、RDSでは利用できない
  • 複数のリードレプリカがある時、カスタムエンドポイントを利用することでエンドポイントごとに接続可能なリードレプリカ群を指定できる。
  • データベースアクティビティストリームを利用することで、DBのauditログを採取できる。これにより、データベース保護、コンプライアンスおよび規制要件をチェックできる。Kinesisと連携することでリアルタイムのチェックが行える。
  • 暗号化されていないAurora DBクラスタのスナップショットを、暗号化されたAurora DBクラスタに復元することができる。(RDSだとこれはできない)
  • クローン・スナップショット・PITRを行った時、バックトラック機能で巻き戻せるDBデータは引き継げない。
  • バックトラックは同一のDBクラスタ内のみで利用可能
  • グローバルデータベースの機能はマルチマスタではない。１つだけが書き込み可能
  • 並列クエリ機能を使うことで、１つのクエリを複数インスタンスで処理させることができる。

Aurora Serverless

  • AuroraがServerlessか否かは起動時に決定する。起動後に設定で有効化する性質のものではない。

RDS MySQLとAurora MySQLの違い

  • Multi-AZのレプリケーションは、RDS MySQLは同期だがAurora MySQLは非同期
  • リードレプリカからプライマリへの昇格は、RDS MySQLだと手動だがAurora MySQLは自動
  • インスタンスのアップグレードがある時、RDS MySQL Multi-AZはすべてのプライマリとセカンダリのインスタンスを同時にアップグレードする。Aurora MySQLはすべてのインスタンスを一度にアップグレードする。

DynamoDB

  • リードのキャパシティは1RCUで4kbyteの強い整合性があるリードが行える。結果整合性での読み込みはその2倍、トランザクション処理を入れるとその半分になる。
  • ライトのキャパシティは1WCUで1kbyteの書き込みが行える。トランザクション処理を入れるとその半分になる。
  • LSI, GSI
    • ローカルインデックス(LSI)を5個、グローバルインデックス(GSI)を20個まで作成できる
    • グローバルインデックスのキーは、元テーブルのパーティションキーと異なっていても良い
    • ローカルインデックスはテーブルの作成時に定義が必要。GSIはテーブルを作った後からでも定義できる
    • LSIはパーティションキーごとのテーブル＋インデックスのサイズは10GBが上限。GSIに容量制限は無い
    • GSIはすべてのパーティションでテーブル全体に対してクエリを実行できる
  • グローバルテーブルを使う時は下記の要件が必要
    • 書き込みキャパシティユニットがAutoScalingか、オンデマンドキャパシティ有効である
  • プロビジョンされたキャシティにはバースト機能がある。未使用のRCU,WCUは300秒分まで取り置きされて、バーストアクセス時に未使用分のユニットを消化できる。
  • プロビジョンされたキャシティにはオートスケール機能がある。ただしこれは急激なトラフィック上昇には対応できない。
  • GSIのパーティションキーに低いカーディナリティの項目を指定すると、性能の問題が発生する。(ホットキーパーティションが発生する)

DynamoDB Accelerator (DAX)

  • インメモリでのデータ保持を行っており、応答速度が早い(DynamoDB自体はインメモリDBではないが、DAXはインメモリで保持)

ElasticCache for Redis

  • クラスタモードを変更したいときは、クラスタ自体の再構成が必要
    • クラスタモードが無効なときに書き込み性能をアップしたいときは、インスタンスタイプを変更する必要がある
      • リードレプリカがある場合は、変更に伴って数秒のダウンタイムが発生する

RedShift

  • クロスリージョンでスナップショットを取るときは、スナップショット取得の設定でターゲットリージョンのKMSマスターキーに対してコピー許可を与える
  • RedShiftはマルチAZをサポートしていない
  • RedShiftのRA3ノードはS3に保存されたデータにクエリを発行する。このS3はユーザからは見えない
  • RedShiftのSpectrumはユーザがおいたS3上のファイルに対してクエリが発行できる。更新処理は行えない。処理は少し遅くなるが安価で手間をかけずにDWHが実現できる。
  • テーブルを作成する時、AUTO、EVEN、KEY、ALLの分散スタイルのいずれかを指定する。デフォルトはAUTO。
  • 同時実行スケーリングを有効にすると、Readの負荷が高くなったときに自動スケールできる

DocumentDB

  • DocumentDBはMongoDBと互換性がある
  • DocumentDBはVPC経由でアクセスする。外部からはアクセスしない。
  • DocumentDBはデータをコレクションの単位で管理する(RDBだとtableに相当する)
  • クラスタモードが有効な時、サーバのディスカバリはクラスタエンドポイントを使うことで行える
    • Auroraと異なり、カスタムエンドポイントはない。
  • (RDSなどと異なり)暗号化されていないスナップショットから、暗号化されたクラスタを作成できる
  • Auroraとは異なり、バックトラック機能は存在しない。
  • DocumentDB profilerを使うことで、クエリの確認はパフォーマンスの問題をチェックできる。ログはCloudWatchLogsへ送られる
    • プロファイラには、profiler_threshold_ms, profile_sampling_rateというパラメータがある
  • 通信を暗号化したい場合はAuroraと同じく、パラメータグループのTLS暗号化をONにする(デフォルトでON)
  • 監査ログを有効にするためには、audit_logsをenabledにして、かつ、ログのCloudWatchLogsエクスポートを有効化する。
    • Auroraだとパラメータ名がserver_audit_loggingで名前が違うことに注意!!

AWS Config

  • AWS Configのrds-instance-public-access-checkを利用することで、RDSがパプリックアクセス可能となっていないかチェックできる。
  • Systems Manager AutomationのRun bookで、もしパブリックになっていたら修正するように自動化できる。
    他のAWSアカウントへのデータ移行
  • 移行先のアカウントでカスタムマネージドキーを発行する。移行元ではそのキーでスナップショットを作る。その後スナップショットを移行先のアカウントにコピーする。

CloudFormation

  • スタック更新で、意図しない変更から防ぐためには以下の方法がある
    • スタックポリシーによる変更拒否
    • 変更セットを作って実行前に確認する

Neptune

  • バルクローダでS3からデータ投入するときは、S3にVPCエンドポイントが必要。これはNeptuneのインスタンスがVPC上に生成されるため。
  • Gremlinはcsvファイルを使用して、データをインポートできる
  • SPARQLはrdf、xmlファイル形式を使用できる
  • Gremlinコンソールというのは、cliのコマンドのこと。
    その他
  • IAMでのMFA認証有効化は、意図しない誤操作の防止に有効
  • S3にIAMロールは適用できない
  • 各設問で"可用性が高い"という文言がないか注意深くチェックする。高可用な構成が要求される時、シングルAZ構成は誤答になる。
Amazonでおトクに買い物する方法
AmazonチャージでポイントGET


Amazonは買いもの前にAmazonギフト券をチャージしてポイントをゲットしないと損！
こちらもおススメ

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です