はじめに
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 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のカスタムやサードパーティとの連携などができる。
特権アクセスやサードパーティ機能も利用できる。
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の対象 | リードレプリカの自動追加・削除 | ストレージ容量の拡張（縮小は自動ではされない） |
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を確認、その後キャッシュにデータを書き込む。リソースの無駄遣いを防ぐことはできるが、一時的にデータの不一致が起きる可能性がある。
認証関連
IAMデータベース認証
IAM データベース認証をEC2インスタンスに付与することで、EC2インスタンスからIAMデータベース認証を利用してRDSのDBインスタンスにアクセスができるようになる。
この認証方法では、IAM内で管理される認証トークンにおいて管理されるため、ユーザー認証情報をデータベースに保存する必要はない。
（通常、DB認証はユーザーIDとパスワードで行われる）
移行関連
DMS
DMS Schema Conversion
テーブルスキーマ、インデックスなどの変換が可能（例えばMySQL→PostgreSQL）
変更データキャプチャ（CDC）
元のデータベースでの変更（挿入、更新、削除）を追跡し、それらの変更を新しいDBに反映できる
DMS Serverless
DB間のデータ移行をより簡単に行うサービス。
従来のDMSでは、移行を行うためのレプリケーションインスタンスを自らプロビジョニングする必要があったが、Serverlessではレプリケーションインスタンスを自分たちで用意する必要がない。