AWSのデータベースサービス比較

## 概要
- SAAの勉強をしていてAWSのデータベースの違いが曖昧だったのでざっくり特徴をまとめてみる
- 参考書とネットの情報を元に自分なりにまとめたので認識違う部分があったらゴメンナサイ

## AWSの主要なDBサービス
- 試験で問われる主要なサービスは大きく下記の通り
    - Amazon RDS
    - Amazon Aurora
    - Amazon Redshift
    - Amazon DynamoDB
    - Amazon ElastiCache
- 今回はこれらのDBサービスの特徴を比較する
- ざっくりとしたサマリは下記の通り
※列数が多くて表にすると見づらいので画像貼ったけどそれでも見づらい。。。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757184/382369e1-415a-4c74-9095-3143c396c0ff.png)

## Amazon  RDS
### 概要
- マネージドで提供されるRDBサービス
- 下記のような様々なDBエンジンを利用可能
    - Aurora
    - MySQL
    - PostgreSQL
    - Oracle
    - Microsoft SQL Server
※一部機能によっては制限があるため、個別でEC2にエンジンをインストールする等の対応が必要な場合もある
- DBインスタンスを作成すると接続用のエンドポイント(FQDN)が作成される

### ストレージ
- ストレージはEBSを利用
- タイプは下記から選択
    - 汎用SSD
    - プロビジョンドIOPS SSD
    - マグネティック
- 容量は最大64TB(Microsoft SQL Serverのみ16TB)
- 拡張中はパフォーマンス劣化が見られるため、タイミングを考慮する必要あり

### 可用性
- マルチAZ構成対応なのでマスターと異なるAZにスタンバイを作成可能
- マスターとスタンバイは同期レプリケーション
- フェイルオーバーには60～120秒ほど必要
- リードレプリカの作成も可能
- マスターとリードレプリカは非同期レプリケーション
- DBクラスターオプションを使用すると下記を実現可能
    - スタンバイインスタンスがリードレプリカとして機能
    - プライマリインスタンスへの書き込みは準同期レプリケーション
    - フェイルオーバー時は通常35秒未満で切り替わる

### バックアップ/リストア
- 自動 or 手動でバックアップを取得可能
- 保持期間は最大35日
- 取得したバックアップからのみリストアが可能
    - リストア時は新規のRDSを作成

### セキュリティ
- EC2と同様にセキュリティグループによる通信制御が可能
- 各DBエンジンが提供するSSL/TLSを使用した通信の暗号化も対応
- 暗号化オプションを有効化することで下記の暗号化に対応
    - データ(リードレプリカ含む)
    - スナップショット
    - ログなど

※RDS関連は全て暗号化可能
※途中から暗号化を有効化した場合、既にあるデータに対しては暗号化されないため、スナップショットから新たにDBインスタンスを作成することで全てのデータを暗号化することが可能

## Amazon Aurora
### 概要
- Amazonが独自に開発したDBエンジン
- MySQLとPostgreSQLとの互換性を持つ
- DBインスタンスを作成すると、下記から構成されるDBクラスタが作成される
    - 1つ以上のDBインスタンス
    - 各DBインスタンスが参照するクラスタボリューム(SSDベースのストレージ)

### ストレージ
- クラスタボリューム作成時に容量の指定は不要
- 保存されるデータ量に応じて自動で拡張される(最大128TB)

### 可用性
- クラスタボリュームは単一リージョン内の3つのAZにそれぞれ2つずつ(計6つ)のデータコピーで構成
- 各ストレージのデータは自動で同期される
- プライマリインスタンスに障害が発生した際は参照用のレプリカインスタンスが自動でプライマリインスタンスに昇格しフェイルオーバーを実現

### エンドポイント
- クラスタエンドポイント
    - プライマリインスタンスへの接続用
    - DBへの全ての操作が可能
- 読み取りエンドポイント
    - レプリカインスタンスへの接続用
    - 複数のレプリカインスタンスがある場合は負荷分散が可能
- インスタンスエンドポイント
    - クラスタを構成する各DBインスタンスへの接続用
    - プライマリインスタンスの場合は全ての操作が可能で、レプリカインスタンスの場合は参照のみ可能
- カスタムエンドポイント
    - クラスタを構成するインスタンスのうち任意のインスタンスをグループ化してアクセス可能とする

## Amazon Redshift
### 概要
- DWH向けのRDBサービス
- Redshiftノードと呼ばれる複数ノードのまとまりによる分散並列実行が可能
- Redshiftノードは1つのリーダーノードと複数のコンピュートノードから構成される
    - リーダーノード
        - 実行クエリを受けてクエリの解析を実施
        - コンピュートノードの数に応じて最適な分散処理を実施
        - 各コンピュートノードからのレスポンスを返す
    - コンピュートノード
        - リーダーノードからの実行クエリを処理するノード
        - ストレージとセットになっており、コンピュートノードを追加することでCPUやメモリ、ストレージなどのリソース追加が可能
    - ノードスライス
        - 分散処理を行う最小単位
        - コンピュートノードのインスタンスタイプによってスライス数が異なる
- 列指向型(カラムナ)DBのためデータ取得の効率化を実現

### ストレージ
- 容量はノード次第
- 追加したい場合はコンピュートノードを追加する必要がある

### Redshift Spectrum
- S3に置かれたデータを外部テーブルとして定義し、クエリの実行が可能
- S3からRedshiftへデータをコピーする必要がないため効率的にデータの分析が可能

## Amazon DynamoDB
### 概要
- マネージド型のNoSQLサービス
- Key-Value型のデータベース
- プライマリキーによってデータを一意に特定
    - プライマリキーはインデックスとしても利用されデータ検索の高速化も実現
- プライマリキーだけではデータ検索を高速化できない場合はセカンダリインデックスも使用
    - ローカルセカンダリインデックスとグローバルセカンダリインデックスの2種類が存在
- TTL機能(Time To Live)により指定した有効期限を過ぎたデータは自動的に削除が可能

### ストレージ
- 保存するデータ容量に応じてディスク容量は自動で拡張

### 可用性
- 単一障害点(SPOF)を持たない構成のため可用性に優れる
    - 障害対応やメンテナンス時の運用を考慮する必要もなし

### スループット
- 読み取りと書き込みに必要なスループットをキャパシティユニットとして指定可能
- 指定したスループットはダウンタイムなしに変更可能
    - 1日での増加回数に制限はないが、減少は9回まで
- EC2のAuto Scalingのように、負荷状況に応じてキャパシティを自動で増減させることも可能

### DynamoDB Streams
- 直近24時間の追加や更新、削除といった変更履歴を保存可能

### DynamoDB Accelerator（DAX）
- DynamoDBの前段にキャッシュクラスタを構成
- もともとミリ秒単位での読み取りが可能だが、DAX利用により毎秒数百万単位の読み取り処理でもマイクロ秒単位でレスポンス可能
- DynamoDBへの直接読み込み回数が減るためRCUの確保を抑えることも可能

## Amazon ElastiCache（ElastiCache）
### 概要
- Key-Value型のインメモリデータベース
- シンプルなデータ構造が特徴で、データ処理やパフォーマンス向上に特化したキャッシュシステム
- データの永続性はないため再起動が行われるとデータは削除される

### クラスタ
- クラスタは最大40のElastiCacheインスタンスで構成される
- クラスタ内に保存されるデータは各インスタンスに分散される
- クラスタ作成時は下記の2種類のアクセス用エンドポイントが作成される
    - ノードエンドポイント
        - クラスタ内の各ノードに直接アクセスするためのエンドポイント
    - 設定エンドポイント
        - クラスタ全体に割り当てられるエンドポイント
        - クラスタ内のノード増減を管理したり、構成情報を自動的に更新
        - アプリケーションからElastiCacheへアクセスする際はこのエンドポイントへアクセスする

### スケーリング
- スケールアウト/イン(ノード数を増減させる)の際は、正しいノードにデータが再マッピングされるまで一時的にキャッシュミスが増加する可能性があるため注意
- スケールアップ/ダウンの際は、新規のクラスタを作成する必要がある
    - その際、それまでのデータは全て失われるため注意

### セキュリティ
- MemcachedクライアントとElastiCache間の通信の暗号化は可能
- ElastiCache内に保存するデータの暗号化は非対応

## Amazon ElastiCache（Redis）
### 概要
- Key-Value型のインメモリデータベース
- 文字列やリスト、セット、ハッシュなどの多くのデータ型を扱うことが可能
- キャッシュ用途だけでなくメッセージブローカーやキューを構成する要素としても利用可能
- データの永続性あり
- 障害発生時の自動フェイルオーバーやバックアップ/リストアを提供

### クラスタ
- クラスタモードの有効/無効を選択可能
    - どちらの場合でもマルチAZ構成は可能
    - マスターインスタンスでの障害発生時はスタンバイインスタンスがマスターインスタンスに昇格（Memcachedとの相違点の1つ）
- クラスタモード無効時
    - キャッシュデータは全て1つのインスタンスに保存
    - 同じデータを持つリードレプリカは最大5つまで作成可能
    - 1つのマスターインスタンスとリードレプリカのまとまりをシャードと呼ぶ
- クラスタモード有効時
    - 最大500のシャードにデータを分割して保存可能
    - リードレプリカは1つのシャードに対して最大5つまで作成可能
    - データを分散することで書き込み/読み込みの負荷分散を実現
- 下記のエンドポイントが作成される
    - ノードエンドポイント
        - クラスタ内の各ノードへ個別にアクセスするためのエンドポイント
        - クラスタモードが無効/有効どちらでも作成される
    - プライマリエンドポイント
        - 書き込み処理用のインスタンスへアクセスするためのエンドポイント
        - クラスタモードが無効の場合に使用
    - 設定エンドポイント
        - クラスタモードが有効の場合はこのエンドポイントを使用してElastiCacheクラスタに対する全ての設定を行うことが可能

### スケーリング
- リードレプリカの追加/削除やシャードの追加/削除といった変更が可能
- ただし、スケーリング中は処理の大部分がオフラインとなるため注意が必要

### セキュリティ
- RedisクライアントとElastiCache間の通信、およびElastiCache内に保存するデータの暗号化は可能