はじめに

問題解いてて問われた内容の備忘録だったもの。

RDS（Relational Database Service）

サポートされているDBエンジン（※ エンジンネイティブの機能やオプションとは異なるので注意）

RDS for Db2
RDS for MariaDB
RDS for MySQL
RDS for Oracle
RDS for PostgreSQL
RDS for SQL Server

マルチAZでのフェールオーバー

ホットスタンバイ：
- セカンダリーDBインスタンスは最初から実行できる状態で待機されている（ホットスタンバイ）
CNAMEレコードの切り替え：
- RDSはDBインスタンスのCNAMEレコードをプライマリーからセカンダリーに切り替えることで、セカンダリーを新しいプライマリに昇格させる
- ユーザーやアプリケーションは同じホスト名を使ってデータベースに接続できるが、裏側では実際の接続先のIPアドレスは変更されている
セカンダリーDBは通常は利用不可：
- マルチAZ配置にしても、セカンダリーDBはフェイルオーバー時のバックアップとしてのみ機能する
- 通常の読み取り/書き込みリクエストには使用不可（ユーザーによる直接アクセスは不可！）
同期レプリケーション
- AZ間でデータを同期しているのでシングルAZ構成よりも書き込み処理などに時間がかかる

リードレプリカ

非同期レプリケーションによるレプリケーションラグ
- マスターとリードレプリカの動機は非同期レプリケーション
- 参照のタイミングによっては最新ではなく古いデータが表示されることがある

停止後も7日後に自動で起動するRDS

EC2とは違って停止した場合でも7日後に自動的に再起動する

バックアップとリストア

バックアップ
- 自動バックアップ：
  - バックアップウィンドウと保持期間を指定することで1日1回自動でバックアップを取ってくれる
  - バックアップのデータは、Amazon S3に保存される
  - 保持期間は最大35日
- 手動スナップショット：
  - 手動でデータベースのスナップショットを作成する
  - 1リージョンあたり100個までの制限がある
リストア
- 自動バックアップからのリストア（ポイントインタイムリカバリー）
  - 5分前 ~ 35日前までの任意のタイミングの状態でRDSを起動できる
  - 自動バックアップを有効化することで利用可能
- スナップショットからのリストア
  - 手動または自動で作成されたスナップショットからDBインスタンスを復元

AWSフルマネージドなバックアップソリューション

AWS Backup
- 各種AWSサービス（例：EC2、EFS、RDS、DynamoDB、Storage Gatewayなど）のデータを一元管理する
- cronでスケジューリング可能
- 保持期間でライフサイクルを作成
- クロスリージョンバックアップ可能
Amazon DML（Data Lifecycle Manager）
- 特にEC2インスタンスを対象に、スナップショットとAMIの作成・管理を可能にするツール
- cronでスケジューリング可能
- 保持期間でライフサイクルを作成
- クロスリージョンバックアップ可能
- EBSのスナップショット作成や削除の問題がちらほら出る

その他問われたもの

RDSプロキシ

RDSプロキシがコネクションプールを管理してくれるやつ
新しいコネクションを確立する際のオーバーヘッドを減らしてくれるので、DBのリソースを効率的に使用できる
ユースケース：
- Lambdaを利用してRDS DB に接続する際には、RDSのプロキシをエンドポイントの代わりに利用する
- DBに変更があった際に、更新情報を非同期で複数のターゲットシステムに配信するような構成
ちなみにLambda関数とRDSエンドポイントを接続する構成は非推奨アーキテクチャ

RDSイベント通知

RDSの各種イベントをSNSを利用して通知する機能
対象：インスタンスの変更やバックアップ、障害復旧などのイベントなど
対象外：RDSイベント通知は個別のテーブルデータ変更など

RDSの拡張モニタリング

DBインスタンスのOSレベルの情報（CPU使用率、メモリ使用量、ディスクI/Oなど）や実行中のプロセスやスレッドの情報をリアルタイムでモニタリングできる。

Amazon Aurora

MySQL および PostgreSQL との互換性があり、スループットがすごい
- MySQL のスループットの 5 倍
- PostgreSQL のスループットの 3 倍

マルチAZ構成

AuroraはデフォルトでマルチAZに分散されるDBクラスターを構成している
- DBインスタンス作成と同時にDBクラスターが作成される
- 1つ以上のDBインスタンスと各DBインスタンスから参照されるクラスタボリュームで構成されている

Auroraレプリカとフェールオーバー

DBクラスター内で最大で15のレプリカを作成でき、DBクラスターが使用している複数AZ間に分散できる
ダウンタイムが発生した場合には、Auroraレプリカを構成しておけば瞬時にフェールオーバーが実行できる
- レプリカがある場合：サービスは120秒未満、多くの場合60秒未満で復元
- レプリカがない場合：通常は 10 分未満
RDSとの違いは、プライマリの障害発生時にレプリカがプライマリに昇格することでフェールオーバーを実現する 点

Aurora グローバルデータベース（ Global Database ）

低レイテンシーのグローバル読み取りとDR対策が可能
- ライターインスタンスはプライマリクラスター側にある
- リーダーインスタンスはプライマリリージョン、セカンダリリージョンに配置が可能

Aurora Serverless

Amazon Aurora 用のオンデマンドのオートスケーリング設定のこと
- リソースの自動的なスケーリング
- DBのエンドポイントを変更することなく、最小限のダウンタイムで切り替えが可能

Amazon Redshift

特徴

列指向型（カラムナ）データベース

処理に使われるデータをまとめて列単位で管理し、効率化されたデータ取得を実現
複数ノードによる分散並列実行が可能
- Redshiftクラスタ（複数ノードのまとまり）
  - リーダーノード：司令塔（1つ）
  - コンピュートノード：実行クエリを処理する（複数）
  - ノードスライス：分散並列処理の最小単位
ゾーンマップ
- データの最小値・最大値を持っているのでデータがない場合にスキップできる（クエリの読み込み時間を短縮）
MPP（Massively Parallel Processing）
- １回の集計処理を福栖ノードに分散して処理する仕組み
シェアードナッシング
- 全体でディスクを共有せず、ノードごとにディスクを持つことで性能向上

コスト

性能に応じて料金が上がり、常時起動させておくとその分コストもかかる
- 主にクラスターの起動時間に応じて課金が発生
- バックアップとなるスナップショットも含めたデータ量に応じても課金が発生

Work Load Management（WLM）

実行するクエリ処理に対して、割り当てるRedshiftのリソースを指定する管理機能
- タスクを定義したクエリ処理をキューに登録して、実行順序を定義するなど
自動WLMと手動WLMの両方をサポートしている

Amazon Redshift Spectrum

そのままではS3バケットにクエリを投げられないのでSpectrumを使う
S3バケット上に保存されたファイルに対して直接、高度なクエリ処理を実行できる

拡張VPCルーティング

VPCに出入りするRedshiftクラスターのすべての COPY および UNLOAD トラフィックを監視できるようになる
VPCエンドポイントやNATゲートウェイの設定が必要

Amazon DynamoDB

DynamoDBのバックアップ方法

AWS Backup：
- いろいろバックアップのオプションがある
オンデマンドバックアップ：
- マネジメントコンソールやSDKなどのAPIを利用してバックアップ可
ポイントインタイムリカバリー（PITR）：
- 有効化で直近5分前から35日間の任意の時点のテーブル状態へ復元できる

※ ちなみにDynamoDBはスナップショットという機能を提供してない

テーブルのスループットキャパシティモード

オンデマンドモード
- 利用されるキャパシティが 予測できない場合 に選択する
- スループットを事前設定する必要がないので、AutoScalingの設定も不要
プロビジョニングモード
- 利用されるキャパシティが 予測できる場合 に選択する
  - スループットキャパシティ（読み込み/書き込みキャパシティユニット）を設定できる
  - Auto Scalingを使うことで、指定した範囲内で自動的にスループットを調整可能

グローバルテーブル

選択するAWSリージョン全体でDynamoDBテーブルを自動的にレプリケート

DynamoDBトランザクション機能

トランザクションのグループ化
- TransactWriteItems API：
  - 最大 100 の書き込みアクションを 1 つの All or Nothing にグループ化できる
    - Put：アイテムの作成、置き換え
    - Update：アイテムの更新
    - Delete：アイテムの削除
    - ConditionCheck：アイテムの存在確認、属性の条件確認

DynamoDBストリーム

テーブル内の項目レベルの変更（挿入、更新、削除）をキャプチャして、それを時間順に並べて保存しておく機能
DynamoDBストリーム自体はデータ処理を動的に実行しないので、動的な処理を実現したいならほかのAWSリソースとの組み合わせが必要
- Lambda関数をDynamoDBストリームのコンシューマーとして設定しておいて、データ変更がストリームに書き込まれた直後にLambdaで処理を行う、など
- あくまでイベント起動なので定期実行はできないよ！
保存した変更履歴は24時間で消える

DynamoDB Accelerator(DAX)

有効化することで、DynamoDBにキャッシュレイヤーを追加するサービス
もともとミリ秒単位でのレスポンスを返すけどマイクロ秒単位でのレスポンスを返すようになる（最大 10 倍のパフォーマンス向上）

読み取り整合性を選択できる

強い整合性モデル
- データ更新の反映に読み込み処理と書き込み処理に誤差が生じることはない
結果整合性モデル
- 可用性とスケーラビリティを維持できる一方、データの更新でデータベースがロックされないので誤差が生じる可能性がある

TTLの使用

不要になった項目を削除するために有効期限を項目ごとに定義できる
- テーブルでTTLを有効にしてから、TTL有効期限タイムスタンプを保存する特定の属性を定義する

Amazon ElastiCache

ざっくり、どっちかの選択を迫られたときの選び方の例。

Redis
- データの永続化やバックアップが求められている
- 複雑なデータ操作（例：リスト、セット等）が求められている
- 高可用性と自動フェールオーバーが求められている
Memcached
- 高いスループットと低遅延が求められ、シンプルなキャッシュとして使用する
- 容易なスケーリングが求められている

その他、データベース関連

いろいろなデータベース概要

たまに問われるので概要だけ知っておいた方がいい。

Amazon Nepture：グラフデータベースサービス
Amazon DocumentDB：MongoDB互換のドキュメントデータベース
Amazon KeySpaces：Apache Cassandra互換のNoSQLデータベース
Amazon Timestream：時系列データベース（IoTおよび運用アプリケーション向け）
Amazon QLDB：台帳データベース
Amazon MemoryDB for Redis：Redis互換のインメモリデータベース

AWS Data Pipeline

データベース間のデータ転送パイプラインを構成するサービス
- 様々なAWSデータベースやストレージ間のデータの移動と変換を自動化する
- データ駆動型のワークフロー
  - タスクの正常な完了をトリガーにして、データ変換と送信タスクを実行可能
- 定期実行できる