【AWS認定】【DBS】二児のママが1か月でデータベース専門知識「AWS Certified Database - Specialty」に合格しました！！！

#はじめに
こんにちは。
３歳と1歳の子を持つママさんエンジニアです。
普段はOracleDatabaseのExadata運用保守を担当してます。

現在、長期的なプロジェクトとしてEXADATAをクラウド移行できないか検討を始めました。
クラウドと言えばAWSでしょ！でもどこから手を付けていいのやら・・・
と、いことでAWS認定試験の勉強を始めることにしました。

ですが、私は小さい子供が２人もいるので勉強時間は限らています。
夜は下の子の夜泣きで起こされるので、
あやしたり、ミルクを上げるついでに1~2時間起きて勉強してました。

夜中に起こされるのは眠くて辛いのですが、勉強したかったのでちょうど良いタイミングだったかもしれません。
今回は、覚えるためにメモした用語をここでご紹介したいと思います。

AWSデータベース専門知識(DBS)はリレーショナルデータベースサービスが5〜6割出題されるのでここでもAmazon RDSやAmazon Auroraを記載します。
##合格バッジ
AWS認定は合格したらバッジがダウンロードできるようになります。
デジタルバッジだけど、これもらえるとAWSの他資格も全部取って11冠目指したくなる気持ちがよくわかります(笑)
試験の申込やバッジのダウンロードはこちらから。

##受験前のスキル

• AWS業務未経験（AWSアカウントはあるけどプライベートでRDBやEC2構築を数回やったレベル）
• AWS認定ソリューションアーキテクト取得（DBS受験する1か月ほど前に合格しました）
• Oracle Database Exadata運用保守約６年（途中産休育休２回取得して合計1年半ほど休んでました。）

##学習に使ったツール

• AWSWEB問題集
  
  問題集はこれに尽きると思います。でもDBSは2022年2月時点でまだ問題数が少なかったので、
  これだけだと学習がたりないと思うので模擬試験や他の書籍と組み合わせた方がよいと感じました。
• AWS認定データベース専門知識
  
  この書籍のおかげでAWSのデータベース全体の基礎知識を身に付けることができました。
  DBSを受験するならこれは必読と言ってよいと思います。
  教科書として業務でも使えそうです。ただ、画面操作の説明は少な目なので実務に活かすなら他媒体で補う必要があります。

それではここからは用語についてご紹介していきます。
##リレーショナルデータベース

###Amazon RDS
Amazon Relational Database Serviceはリレーショナルデータベースを提供するサービス。
OSやデータベースエンジンの管理はAWS側で行われる。
#####可用性
RDSではメインとなるプライマリインスタンスのほかにスタンバイレプリカを別のAZに配置することで
マルチAZな高可用性を実現できる。
データおｎ同期がプライマリからスタンバイレプリカに行われプライマリインスタンスやAZに障害があった場合、
スタンバイレプリカにフェイルオーバすることができる。

• リードレプリカとの差異
  スタンバイレプリカは可用性向上が目的であり、読み取り性能UPが目的ではない。
  読み取り性能向上したい場合はリードレプリカを使用する。
• バックアップとの関係
  スタンバイレプリカが存在する場合、RDS標準のバックアップ機能であるスナップショット取得機能はスタンバイレプリカに対して実行されるため、プライマリへのデータベーストラフィック影響を与えない。
• シングルAZ配置とマルチAZ配置
  RDSの作成時、シングルAZとマルチAZを選択できる。
  最初にシングルAZ配置で作成したRDSも作成後にマルチAZ配置へ変更できる。構成変更時はパフォーマンスに影響を与える可能性があるため本番稼働中の変更はさける。

######パフォーマンス

• RDSインスタンスタイプ
  スペック(CPU、メモリ)は、インスタンスタイプを選択することによって決定する。

• ストレージタイプ
  RDSはインスタンスタイプだけでなく、ストレージタイプも選択できる。

• RDSのStorage Auto Scaling
  自動的に拡張するStorage AutoScaling機能がある。この機能を有効にすると空き容量が10%以下の状態が5分以上続いた場合、自動拡張される。

• リードレプリカ
  ・プライマリインスタンスから複製された読み取り専用のインスタンス。
  ・プライマリインスタンスから非同期でデータがコピーされプライマリと完全に同じではない。
  ・リードレプリカを手動操作でプライマリインスタンスに昇格できる。オンライン中のデータコピー、障害復旧を目的で使用する
  ・別のリージョンにリードレプリカを作成できる。マルチAZ配置も可能。ただし、SQL Serverはサポート対象外。
  ・自動バックアップを有効にして保持期間を0以外の値にする必要がある。

#####メンテナンス

• メンテンナンスウィンドウ
  
  OSやデータベースエンジンのバージョン更新、パッチ適用はAWS側で実施されるが、更新作業はメンテナンスウィンドウという利用者が設定した時間帯に実施される。
  いくつかのメンテナンス作業では、DBインスタンスが一時的にオフライン（利用不可）となるため、DB使用率が低い時間帯を設定するとよい。

• マルチAZ配置のメンテナンス
  次の手順でメンテナンスが実行される。
  1,スタンバイに対してメンテナンスを実行する
  2,スタンバイをプライマリに昇格させる
  3,旧プライマリでメンテナンスを実行し、その旧プライマリが新スタンバイになる

• DBエンジンのバージョンアップグレード
  メジャーバージョンのアップグレード
  利用者が手動で実施する。変更タイミングは即時または、次のメンテナンスウィンドウを選択して決定する。
  マイナーバージョンのアップグレード
  メジャーバージョン同様に手動アップグレードも可能ですが、自動アップグレードを有効にしてAWS側で自動実行することもできる。
  有効にするとAWS側で推奨バージョンが更新された場合、メンテナンスウィンドウを使用して自動アップグレードされる。

###Amazon Aurora
クラウド向けにAWSが構築したデータベースでMySQLやPostgreSQLと互換性がある。
#####構造
AuroraのDBクラスターは１つ以上のDBインスタンスとデータを管理するクラスターボリュームで構成される。
インスタンスとストレージが分離しているのが特徴。
データボリュームは3AZに2個づつ合計6このコピーが作成され高い耐障害性を持つ。
#####可用性

• フェイルオーバーの優先度
  Auroraレプリカに優先度を割り当てどのレプリカが優先的に昇格するか設定できる
  1.指定した優先度が高い(より0に近い)リードレプリカ
  2.優先度が同じ場合はサイズの大きいリードレプリカ
  3.優先度とサイズが同じ場合は任意のリードレプリカ

• クラスターキャッシュ管理
  Aurora PostgreSQLにはフェイルオーバーのパフォーマンス影響を少なくするためのクラスターキャッシュ管理という機能がある。
  通常、プライマリインスタンスで使用していたキャッシュ情報は、フェイルオーバー時に昇格するレプリカには引き継がれないため一時的にパフォーマンスが低下する。
  クラスターキャッシュ管理を有効にすると、レプリカにキャッシュが同期されるためフェイルオーバー時のパフォーマンス影響を最低限に抑えられる。

• Auroraグローバルデータベース
  通常、Auroraクラスターは単一リージョン内に構築するが、複数リージョンにまたがるグローバルデータベースも構築できる。
  アプリケーションが複数のリージョンにある場合はレイテンシーが最短になるリージョンのデータベースに接続できる。

• クロスリージョンレプリケーション
  グローバルデータベースと同様に、他のリージョンにAuroraクラスターを作成し、そのクラスターを読み込み専用のクラスターとして使用できる。
  グローバルデータベースと比べてリージョン間のデータコピーに時間がかかる。
  #####パフォーマンンス

• インスタンスタイプ
  選び方は通常のRDSと同様になる。大きいサイズの方が高パフォーマンスで価格も高くなる。

• ストレージの選定
  通常のRDSではディスク性能要件に合わせてストレージタイプを選択する必要がある。また、確保する容量も利用者が決定する。Auroraではストレージタイプおよび容量の指定はAWS側で行われるため必要ない。

• Auroraレプリカを使用した読み込みパフォーマンス向上
  Auroraレプリカは最大15個作成でき、読み込み処理を分散できる。
  アプリケーションに読み込みエンドポイントのURLを指定することで各レプリカに分散したアクセスが可能。アプリケーションから見たアクセス先は1つ。

• Amazon Aurora Auto Scaling
  Auroraレプリカの増減は、手動で実行もできるが、Auto Scaling機能を使用して自動的にレプリカの追加と削除を実行できる。
  CPUまたは接続数を指定しその値に近づくようレプリカの数が自動調整される。

• Amazon Aurora Serverless
  DBインスタンスのサイズ指定が不要でCPUやメモリといったキャパシティを自動で管理してスケールアップ/ダウンしてくれる機能。

• カスタムエンドポイント
  読み書き関係なく設定したDBインスタンスのセットに対して負荷分散する接続を作成できる。読み書きの判別はしないため主に読み込みに使用されます。

• 読み込みエンドポイント
  すべての読み取り専用Amazon Auroraレプリカに負荷分散して接続する。Amazon Auroraレプリカがない場合はプライマリDBインスタンスに接続する。

• クラスターエンドポイント
  プライマリDBインスタンスに接続する。

• インスタンスエンドポイント
  プライマリDBインスタンスに接続する。　　　　

#####メンテナンス

• バックアップ
  Auroraには自動バックアップ機能があり、設定した保持期間分、継続的かつ増分的に取得される。
  つまり、保持期間中の任意の時点に復元できる。
  データのバックアップは日時ではなく継続的かつ増分です。保存期間は1～35日で指定できS3に保存される。
  この期間を超えて保存したい場合はスナップショットを取得する。
• スナップショット
  RDSと同じくAWS Backupで自動的なスナップショットの取得も可能で、Aurora側では手動スナップショットとして管理される。
• データの復元
  バックアップデータ、スナップショットのいずれも復元する場合は既存のAurora DBクラスターではなく、新しいAurora DBクラスターを作成することになる。
  バックアップデータから復元する場合は、保持期間内の任意の時点（ポイントインタイム）を指定して復元できる。
• Auroraクローン
  データストレージのコピーは行われず、インスタンス部分のコピーのみが行われるため、高速に同じデータを扱うコピークラスターが作成できる。
  
  ・データのエクスポートや分析など読み込みオペレーションを実行する
  
  ・本番稼動のデータを開発やテスト用途で使用できる
  
• バックトラック
  
  Aurora DBクラスターの「巻き戻し」機能で、既存のクラスターを巻き戻しできる。
  スナップショットやバックアップデータからの復旧とは異なり以下の操作も可能となる。
  
  ・直前で実行したDELETE処理などの取り消し
  
  ・直前の操作前に戻してまた進めることで、その時間でどのようなデータ変更があったか調べる。
  
  制限
  
  ・時間の上限は72時間
  
  ・クラスター作成時またはスナップショット復元時に有効にできる
  
  ・Aurora MySQLでのみ使用可能

#####モニタリング
Auroraでは通常のRDSと同様、以下機能を使用してモニタリングが可能
・CloudWatchによるCPU、メモリなどのリソース監視
・拡張モニタリングによるOS部分のリソース情報を含めた監視
・パフx－マンスインサイトによるCPUの負荷状況やSQL分析

• 障害挿入クエリ
  以下の状況をシュミレーションできる。
  ・DBインスタンス障害
  ・Auroraレプリカの障害
  ・ディスク障害

• データベースアクティビティストリーム
  CloudWatch logsよりリアルタイムに情報連携を行い監視できる機能。
  この機能を有効にするとAuroraクラスターで行われたアクティビティがリアルタイムでAmazon Kinesisデータストリームに連携される。
  アクティビティにはデータベース接続、実行されたSQLコマンド、監査ログ情報が含まれる。

#####移行

• Auroraリードレプリカを使用した移行
  RDSからAuroraへ移行する場合、移行元のDBインスタンスの画面からAuroraリードレプリカを作成することで、まず移行元のRDSスナップショットを作成する。作成したスナップショットからAuroraリードレプリカにデータがコピーされる。一度コピーされた後、継続してレプリケーションが行われる。接続元クライアントアプリケーションも移行準備完了したらAuroraリードレプリカをAurora DBクラスターに昇格させデータベース移行を完了させる。
  ダウンタイムは少なく済むし、昇格するまで非同期レプリケーションをしているのでデータ差分も最小限にできる。

• スナップショットを使用した移行
  RDSからAuroraへ移行する場合、RDSから作成したスナップショットからAurora DBクラスターとして復元できる。ある時点でのデータでAuroraへ移行、データベースの一時的な利用停止が許容される場合はこちらがやりやすい。

• AWS SCT(Schema Conversion Tool)
  移行前に自動的なスキーマ変換の可否など移行評価レポートを生成する機能がある

• AWS DMS(Database Migration Service)
  移行後に正確な移行ができているかを確認するデータ検証の機能がある

• AWS SnowballEdge
  100TB（83TB使用可能）の容量のデバイスを安全な手法で直接AWSに配送するサービスで約1週間程度でAmazonS3にロードされる。

#####セキュリティ

• AWS Secrets ManagerとAWS Systems Managerパラメータストア
  
  AWS Secrets Managerはデータベースの認証情報管理の設定がしやすい。
  
  Auroraを含むAmazon RDS、Amazon DocumentDB、Amazon Redshiftで使用する認証情報の自動ローテーションをネイティブにサポートする。
  
  AWS Secrets Managerに総合機能が備わっているため、比較的少ない開発で自動ローテーションを実現できる。

##まとめ
今回受験したデータベース専門知識「AWS Certified Database - Specialty」は、
実際の受験時間は見直し込みで2時間半くらいで終わりました。試験時間は3時間です。
出題数はRDSが5～6割でDynamoDBは2割ほど。残りがその他って感じでしたが、その他はAmazon Neptuneくらいだったように思います。

また、他のAWS認定試験より簡単だと思いました。
私は他にはソリューションアーキテクトだけ取得していますが、私がデータベースエンジニアだからなのかSAAより簡単な気がしました。
Oracle Databaseだったらこんな仕様だなとか、うちの会社はこんな運用してるな、AWS的にこんな回答だと正解だろうな、という考えのもと問題を解くと結構と正解を選ぶことができました（笑）
なので、少ない勉強時間で合格することができたのだと思います。
ただ、上記のような考えのまま受験するのは不安でしたし、暗記に頼ってしまうと後々身につかないと感じたので、
問題を解く際に本当に正解はこれで正しいのか、なぜ他の選択肢は間違えなのかを考えながら学習するよう気を付けていました。
データベースエンジニアとして無事合格できて嬉しいです。

今後の課題として、今回は夜中子供を抱っこしながら勉強していたので、あまりハンズオンで手を動かすことができなかったのが心残りです。
今後は資格勉強で得た知識を活かし実践して技術力を高めていきたいと思います。