はじめに

SAA試験勉強のうちDBに関して、個人的に何度も忘れてしまうものや分かりにくいものをまとめていきます！
試験範囲を網羅しているわけでは全くありませんのでご注意を！
その他の範囲まとめはこちら↓

RDS

インスタンスタイプ

ファミリー	特徴	主な用途
バーストパフォーマンス (t)	最低限のパフォーマンス。必要に応じてCPUをバースト可能。コスト効率重視。	小規模DB、開発/テスト環境、トラフィック変動の少ないワークロード
汎用 (m)	コンピューティング、メモリ、ネットワークなどのリソースがバランスよく提供される。	中規模DB、Webアプリケーションなど幅広く
メモリ最適化 (r)	大量のメモリを必要とするワークロード向け。高速な処理速度が必要な場合。	インメモリDB、メモリキャッシュ、リアルタイムデータ処理、大規模DB
エクストリームメモリ (x)	メモリ最適化 (r)よりもさらに大量のメモリと高パフォーマンスが必要な場合。	大規模インメモリDB、高パフォーマンスコンピューティング
高周波数 (z)	高いCPU周波数を必要とするワークロード向け。ライセンス料が高いソフトウェアの利用などに適している。	EDA（電子設計オートメーション）、ゲーム、特定の金融アプリケーション
ストレージ最適化 (d)	大容量のローカルNVMeSSDストレージを持つ。高いシーケンシャルスループットとランダムI/O性能を必要とするワークロード向け。	高速なローカルストレージを必要とするアプリケーション

ストレージオプション

-	汎用SSD (gp3)	プロビジョンドIOPS SSD (io1/io2)	マグネティック (Standard)
用途	ほとんどのワークロード	高いIOPS性能を必要とするワークロード（高負荷DBなど）	低頻度アクセス、テスト/開発
最大IOPS	16,000 IOPS	io1: 64,000 IOPS, io2: 256,000 IOPS	不明
最大スループット	1,000 MB/sec	io1: 1,000 MB/sec, io2: 4,000 MB/sec	不明

RDS Proxy

RDS ProxyはアプリケーションとRDSの仲介役としてコネクションを管理するプロキシ。
コネクションが非効率に乱立することなく、DB接続を最小限にとどめる。

フェイルオーバー時

RDS Proxyは、接続が失われることなくリードレプリカがプライマリに昇格するのを効率的に処理するため、フェイルオーバー時間を短縮するのに役立つ。

RDS DBインスタンスのメモリ使用率を常時モニタリングするには

RDSの拡張モニタリングを有効化する

フェールオーバーが実行されたらどうなるか

マルチAZ構成のRDSでは、プライマリDBのインスタンスがダウンした場合に自動的にフェールオーバーが実行される。
フェールオーバーが実行されると、RDSはDBインスタンスのCNAMEレコードをプライマリーからセカンダリーに切り替えることでセカンダリーを昇格させる。

セカンダリDBはホットスタンバイしている（実行できる状態で待機）

バックアップ

RDSの自動バックアップはポイントインタイムリカバリに使用されるが、保持期間は最大35日。
それ以上の期間保持する必要がある場合には、AWS Backupを使用する必要がある。

Schema Conversion Tool

既存のDBスキーマを別のDBエンジン用に変換するツール

ex.Microsoft SQL Server のスキーマをPostgreSQLに変換する

RDS Custom

RDS Customでは、通常のRDSではできないOSのカスタムやサードパーティとの連携などができる。
特権アクセスやサードパーティ機能も利用できる。

ブルー／グリーンデプロイ

現在の環境（ブルー環境）と別に新しい環境（グリーン環境）を準備でき、問題が発生しないことを確認してから更新を完了できる。
問題があればブルー環境に戻せばよいので安全に更新できる。
例えば、DBのバージョンアップグレードやインスタンスタイプの変更、スキーマ変更時などに利用される。

マルチAZ構成とマルチAZ DBクラスターの違い

項目	マルチAZ (DB インスタンス)	マルチAZ DBクラスター
インスタンス数	2	3
配置	2つのAZ	3つのAZ
フェイルオーバー	通常60～120sec	通常35sec以内
読み取り	プライマリのみ（必要ならば別途リードレプリカが必要）	スタンバイをリードレプリカとして使用可能
対応エンジン	MySQL、PostgreSQL、MariaDB、Oracle、SQL Server	MySQL、PostgreSQL

RDSその他

RDSではストレージエンジンとしてMyISAMを利用することはできない
RDSはファイルシステムへの直接のアクセスをサポートしていない
→ 直接アクセスしたいなら、EC2インスタンスにDBをインストールしてDBサーバーを構築する必要がある。
RDS for SQL Serverでは、例えばデータベースのログ配布やネイティブのスナップショット機能が利用できない。

Aurora

マルチAZで分散されたクラスター構成で、従来のRDSよりも高速で高性能
プライマリDBが配置されているAZに障害が発生したら、レプリカの1つをプライマリDBに昇格させることでダウンタイムを最小限にできる。
AutoScaling機能を利用すれば、負荷に応じて動的にレプリカインスタンスを増減できる。

グローバルDB
複数のAWSリージョンにわたってデータベースを複製し、高可用性と災害復旧を実現する。ログ転送ではなくストレージレベルのレプリケーション機能を利用してレプリケーションを実施。最大でも5秒ほどでレプリケーションが実行される。
Aurora Serverless
DBインスタンスの負荷状況に応じて、自動的にDBインスタンスの起動、停止、スケーリングを行う機能。通常のAuroraと異なり、インスタンスタイプを指定することなく、負荷状況に応じた性能で稼働する。

Aurora レプリカ

Auroraレプリカを作成している場合にはフェールオーバーは30秒以内に完了する。
Auroraレプリカを作成していない場合には15分以内（通常10分以内）で完了する。

カスタムエンドポイント

Auroraクラスター内の特定のDBのインスタンスのサブセットに接続するための方法を提供する機能。
デフォルトのクラスターエンドポイント（書き込み用）とリーダーエンドポイント（読み込み用）に加えて、特定のユースケースに合わせて独自のエンドポイントを作成できる。
例えば、分析用ワークロードを専用のレプリカに分離できる。

Babelfish

Aurora PostgreSQLの機能の一つで、Microsoft SQL Server向けのSQLクエリ（T-SQL）を解釈し、PostgreSQLで実行できるようにするもの。
これにより、SQL Serverアプリケーションをほとんど変更せずにAurora PostgreSQLへ移行できる。

AuroraとRDSのAutoScalingの違い↓

-	Aurora	RDS
AutoScalingの対象	リードレプリカの自動追加・削除	ストレージ容量の拡張（縮小は自動ではされない）

ブルー／グリーンデプロイ

RDSと同様に、ブルー／グリーンデプロイ機能が備わっている。

DynamoDB

1アイテムにつき最大400KBの制限がある。
それよりも大きなデータを保存する場合、要件にもよるがデータ自体はS3に保存し、DynamoDBにはS3 URLを格納する方法もある。

モード

キャパシティモード
- オンデマンドモード：利用するキャパシティが予測できないとき。自動でスケーリングされる。
- プロビジョニングモード：利用するキャパシティが予測できるとき。UpdateTableオペレーションを使用して必要な回数だけ読み込みユニットと書き込みユニットを増やすことができる。キャパシティ容量に近づくとHTTP400コードが発せられる
トランザクション機能
DynamoDBテーブルへの書き込みなどのトランザクション発生時に特定の処理を実行させることができる。例えば、書き込み前に機密性の高いデータを削除するアクションを設定できる。
DynamoDBストリーム
DynamoDBテーブルに保存された項目の追加、変更、削除の発生時の履歴をキャプチャできる機能。
DynamoDBストリームをトリガーとして、Lambda関数を実行することができる。
Time To Live (TTL) 機能
特定の時点で自動的にデータ項目を削除する機能。
項目にTTL属性を設定することで、その時刻が来たときにDynamoDBが自動的に項目を削除する。この機能は完全に自動化されており、追加の管理やコストが発生しない。不要なデータによるストレージコストの増加を防ぐことができる。

ポイントインタイムリカバリ

誤ってデータを削除したり、書き換えてしまった場合でも、過去の任意の時点にデータを復元できる機能。
DynamoDBは常にテーブルのバックアップを自動的に作成しており、これにより任意の時点のデータを復元できる。

過去35日以内の時点であれば復元できる

S3へのエクスポート機能

既存のテーブルデータをS3に直接エクスポートできる。
テーブルの可用性やパフォーマンスにも影響を及ぼさない。
この機能は内部的にポイントインタイムリカバリを使用しているので、これを有効にしておく必要がある。

DynamoDBにはスナップショットという機能はない。（RDS, Auroraにはある）

Redshift

拡張VPCルーティング
- Redshiftはクラスターとデータリポジトリ（S3など）の間のすべてのCOPYとUNLOADトラフィックがVPCを経由するように強制する
- VPCフローログを使ってCOPYとUNLOADトラフィックを監視する
- VPCにて設定しているルートテーブルに従った通信を行う
- COPY：Redshiftクラスターに、外部データソース（S3など）からデータをロードする際のネットワークトラフィック
- UNLOAD：Redshiftクラスターから、外部データソース（S3など）にデータをエクスポートする際のネットワークトラフィック

WLM(Work Load Management)

Redshiftのクエリ処理に対して割り当てるRedshiftのリソースを指定できる。
また、WLMを利用するとクエリ処理をキューに登録し、実行順序を指定することができる。

ElastiCache

キャッシュ戦略

ライトスルー戦略
DBへの書き込みや更新が行われると同時にキャッシュにも書き込みを行うため、データの整合性が保たれるが、書き込み性能が低下する可能性や、アクセスされないデータもキャッシュに蓄積されるというデメリットがある。
遅延読み込み戦略
DBへの書き込みを優先し、キャッシュへの書き込みは必要な時のみ行う。
データ読み込み時、最初にキャッシュを確認し、該当データがなければDBを確認、その後キャッシュにデータを書き込む。リソースの無駄遣いを防ぐことはできるが、一時的にデータの不一致が起きる可能性がある。

MemcachedはマルチAZ非対応。
RedisはマルチAZ対応可。

Lake Formation

データレイクを簡単に構築、運用するためのマネージドサービス。
Lake Formationでは、テーブル単位、列単位などのきめ細やかなアクセス制御を行うことができる。

アクセス制御の方法

名前付きリソースでのアクセスコントロール
LFタグベースのアクセスコントロール
DB、テーブル、カラムにLFタグを設定することでより柔軟に、効率的にアクセス制御ができる。

認証関連

IAMデータベース認証

IAM データベース認証をEC2インスタンスに付与することで、EC2インスタンスからIAMデータベース認証を利用してRDSのDBインスタンスにアクセスができるようになる。
この認証方法では、IAM内で管理される認証トークンにおいて管理されるため、ユーザー認証情報をデータベースに保存する必要はない。
（通常、DB認証はユーザーIDとパスワードで行われる）

移行関連

DMS

DMS Schema Conversion

テーブルスキーマ、インデックスなどの変換が可能（例えばMySQL→PostgreSQL）

変更データキャプチャ（CDC）

元のデータベースでの変更（挿入、更新、削除）を追跡し、それらの変更を新しいDBに反映できる

DMS Serverless

DB間のデータ移行をより簡単に行うサービス。
従来のDMSでは、移行を行うためのレプリケーションインスタンスを自らプロビジョニングする必要があったが、Serverlessではレプリケーションインスタンスを自分たちで用意する必要がない。

Neptune

フルマネージド型のグラフデータベースサービス。
グラフデータベースは複雑な関係性を表現するのに適しており、ソーシャルネットワーク、ネットワーク分析などに活用される。

Neptune Streams

Neptune データベースの変更をほぼリアルタイムでキャプチャし、ストリームとして外部システムに配信する機能。
一般的なユースケースとして、OpenSearch Serviceとの連携がある。
Neptuneは複雑な関係性の検索には適しているが、全文検索には適切ではないので、Neptune Streamsを利用してデータをOpenSearch Serviceに送信することで全文検索機能を補完できる。