AWS RDS、Aurora、RDS Proxy、ElastiCache

RDS とは

Amazon RDS（Relational Database Service） は SQL を使うエンジン向けのマネージドリレーショナル DB サービス。AWS が DB 層をプロビジョニング・運用；ホストに SSH しない（マネージドサービスの境界）。

対応エンジン（一覧を把握）

PostgreSQL、MySQL、MariaDB
Oracle、Microsoft SQL Server、IBM Db2
Amazon Aurora（AWS 独自；MySQL または PostgreSQL 互換ドライバ — 下記 Aurora 節参照）

RDS と EC2 上の自己管理

RDS には EC2 で自前になる運用作業が含まれる。

プロビジョニングと OS パッチの自動化（AWS が管理する DB スタック）
継続バックアップと ポイントインタイムリストア（PITR）
モニタリングダッシュボードとメトリクス
読み取りスケールのための read replica
高可用性 / DR の Multi-AZ
アップグレードの メンテナンスウィンドウ
垂直スケール（大きいインスタンスクラス）と水平読み取りスケール（レプリカ）
EBS 上のストレージ（性能/コストモデルが馴染みやすい）

トレードオフ：DB インスタンスへのシェルアクセスなし — RDS 機能、Parameter Group、モニタリングを使う。

RDS ストレージオートスケーリング

DB が満杯になるときの手動ストレージ拡張を避ける。

動作（コースのルール — 最新ドキュメントで確認）：

最大割り当てストレージ上限を設定。
オートスケーリングは次を満たすと発火しうる。
- 空き容量 < 現在割り当ての 10%、かつ
- 低容量状態が 5 分超続く、かつ
- 最後のストレージ変更から ≥ 6 時間。

用途： 予測しにくい成長ワークロード。RDS エンジンでサポート（研修の範囲）。

Read replica

目的： プライマリ（ライター）から読み取りをオフロード。

ソースあたり最大 15 個の read replica（試験で出る数）。
配置：同一 AZ、クロス AZ、クロスリージョン。
レプリケーションは非同期 → レプリカは最終的整合（すぐに read-your-writes は保証されない）。
レプリカは読み取り専用 SQL（例：SELECT）；INSERT / UPDATE / DELETE には使わない。
レプリカをスタンドアロンのプライマリに昇格（レプリカトポロジーを離れ、独自の読み書き DB になる）。

アプリ変更： リーダーはレプリカエンドポイント（接続文字列 / ルーティング層）を使う — プライマリ DNS だけでは読み取りは自動分散されない。

典型用途：レポーティング

OLTP をプライマリで守るため、分析/レポートをレプリカで実行。

データ転送コスト

同一リージョン、異なる AZ：レプリケーショントラフィックは多くの場合無料（コースのマネージドサービス例外）。
クロスリージョン レプリカ：クロスリージョンデータ転送課金。

Multi-AZ（高可用性 / DR）

目的： 可用性とフェイルオーバー — 読み取りスケールではない。

アプリ用の単一 DNS 名。
AZ A のプライマリから AZ B のスタンバイへの同期レプリケーション。
スタンバイは通常運用では読み書きに使わない — フェイルオーバー用。
プライマリ障害（AZ 障害、インスタンス障害、ストレージ障害、プライマリへのネットワーク分断など）で自動フェイルオーバーがスタンバイを昇格 → 新プライマリ。同じエンドポイントをリトライするアプリは多くの場合 DNS 変更なしで復旧。

Read replica + Multi-AZ

可： read replica 自体を Multi-AZ でデプロイし、そのレプリカの DR にも使う（試験でよくあるひねり）。

Single-AZ → Multi-AZ（試験）

利用者視点ではダウンタイムなし：インスタンスを変更し Multi-AZ を有効化（そのトグル単体ではアプリの stop/start は不要 — 例外は AWS ドキュメント参照）。

概念上の裏側： RDS がプライマイのスナップショットを取り、スタンバイをリストアし、同期レプリケーションで追いつくまで確立。

Multi-AZ フェイルオーバーのトリガー（試験で暗記）

プライマリからスタンバイへのフェイルオーバーは次で起こりうる。

プライマリ DB インスタンスまたは下層ストレージの障害
プライマリ OS のソフトウェアパッチ（マネージドメンテナンス）
プライマリへのネットワーク接続喪失
置換を強制する手動操作：例 インスタンスタイプ変更、プライマリビジー/無応答
プライマリ AZ に影響する AZ 障害
手動フェイルオーバー： コンソール/CLI の Reboot with failover

自動バックアップ vs スナップショット（RDS）

自動バックアップ（継続 + PITR）

保持期間内の PITR 付き継続バックアップストリーム。
保持： 0～35 日（0 = 自動バックアップ無効）。
設定可能なバックアップウィンドウ（メンテナンススケジュールの一部）で実行。
インスタンス削除時、一定期間自動バックアップを保持できる（コンソールオプション）。
リストアは常に新しい DB インスタンスを作成 — 同一インスタンス ID へのインプレースリストアはない。

手動スナップショット

IO 影響： Single-AZ ではスナップショットで短い停止（数秒～数分）；Multi-AZ ではスタンバイから取得しプライマリへの影響を軽減。
初回スナップショットはフル；以降は増分（EBS に近い考え方）。
手動スナップショットは削除するまで期限切れにならない。
インスタンス削除時の最終スナップショットは任意。
クロスアカウント共有（EBS と同様）：手動スナップショットのみ（または自動を先に手動にコピー）。自動バックアップそのものはそのまま共有できない。
暗号化スナップショット： 共有には相手アカウントがスナップショットに使った CMK の KMS 権限が必要（EBS と同パターン）。

RDS イベント、サブスクリプション、DB ログ

イベント

RDS はインスタンス、スナップショット、パラメータグループ、セキュリティグループなどのイベントを記録（例：pending → running、バックアップ開始、変更）。

イベントサブスクリプション → SNS トピック；ソースタイプ（DB インスタンス、スナップショット、パラメータグループ、クラスター など）とカテゴリでフィルタ。
同じイベントを EventBridge に連携しルールベースの自動化に使える。

ログファイル → CloudWatch Logs

DB エンジンはログを公開（例：error、slow query、general、audit — エンジン依存）。インスタンスでログエクスポートを有効化し CloudWatch Logs に公開し、メトリクスフィルタ（例：ERROR をカウント）とアラーム → SNS でオペレーター通知。

コンソール： Events タブ（直近履歴）、インスタンスの Logs & events、Modify → ログエクスポートのチェック。

RDS の CloudWatch メトリクス

標準（ハイパーバイザレベル）

例：DatabaseConnections、SwapUsage、ReadIOPS / WriteIOPS、ReadLatency / WriteLatency、ReadThroughput / WriteThroughput、DiskQueueDepth、FreeStorageSpace、CPU。

トラブルシューティングの感覚： 遅延や DiskQueueDepth が高い → ストレージボトルネック；ReadIOPS 張り付き → IOPS/ボリューム拡大；CPU 高 → クラス拡大またはクエリチューニング。

Enhanced Monitoring

DB インスタンス上のエージェント（ハイパーバイザだけでない）：50+ OS メトリクス — プロセス/スレッド CPU、メモリ、ファイルシステム、ディスク I/O。
粒度は最大 1 秒（コースではデフォルト 60 秒）；モニタリングエージェント用 IAM ロールが必要。

コンソール： Monitoring ビュー → CloudWatch / Enhanced monitoring / OS process list のドロップダウン。

RDS Performance Insights

時間経過に沿ったデータベース負荷の可視化；次でスライス。

Waits — 支配的なリソース（CPU、I/O、locks など） → コンピュート vs ストレージ/IOPS のスケール判断。
SQL — 高コスト文をアプリオーナーと最適化。
Hosts — どのアプリサーバーが DB を叩いているか（read replica やスロットリングの要否）。
Users — どの DB ログインが負荷を押し上げているか。

負荷はアクティブセッションとして説明（エンジン依存）。オプションの有料層：プロアクティブな推奨。

サポート： すべてのインスタンスクラスではない（コース：db.t2.* は多く非対応）；対応クラスで Modify から有効化し履歴の保持期間を設定。

Amazon Aurora（高レベル）

AWS 独自エンジン；PostgreSQL または MySQL とワイヤ互換（それらのドライバ/クライアントを使用）。

なぜ Aurora（試験の枠組み）

クラウド最適化のストレージとレプリケーション — コースは同一エンジン RDS より大きな性能倍率を引用（ワークロードにより変化；速い/スケールしやすいという話として扱う）。
10 GiB から 128 TiB まで自動拡張ストレージ（コースは 256 TiB と言及 — 最新 Aurora 上限を確認）。
低いレプリカラグで最大 15 read replica（コース：10 ms 未満が典型）。
クラシック RDS Multi-AZ よりはるかに速いフェイルオーバー（コース：ライターフェイルオーバー平均 < ~30 秒）。
RDS よりリスト価格は高いがスケールではしばしば効率が良い（コスト/性能トレードオフの問題）。

ストレージトポロジー（概念）

3 AZ に6コピー；書き込み quorum（4/6）、読み取り （3/6） — AZ 損失に耐え自己修復/ピア修復をサポート。
論理共有クラスタボリュームが多数の小ボリュームにストライプ（セグメントは管理しない）。

クラスタエンドポイント（試験で重要）

Writer エンドポイント — 常に現在のプライマリ（読み書き）に解決。フェイルオーバー後もアプリ再設定なしで存続。
Reader エンドポイント — 接続単位で Aurora レプリカにロードバランス（文単位ではない）。読み取りスケール用。
個別インスタンスにもインスタンスエンドポイントがありターゲット接続に使う。

レプリカ： 最大 15；ライター障害時いずれのレプリカも昇格可能。クロスリージョン read replica 対応。CPU や接続に基づくオートスケーリングポリシー（最小/最大の範囲）。

Aurora 実習の要約（コンソール）

Standard create → Aurora MySQL または PostgreSQL；機能でエンジンバージョンをフィルタ（Global Database、Parallel Query、Serverless v2）。
Cluster storage： Standard vs IO-Optimized（高 I/O ワークロード）。
Instances： バースト/プロビジョンドクラス、または Serverless v2（固定クラスの代わりに ACU 最小/最大）。
Availability： HA + 読み取り容量のため別 AZ に reader を追加。
Endpoints： クラスタの writer + reader；3306（MySQL）などのセキュリティグループ。
オプション：IAM DB auth、Kerberos、Enhanced Monitoring、暗号化、backtrack、ログエクスポート、deletion protection、Local write forwarding（リーダーへの書き込みをライターへ転送 — 一部アプリパターンを簡素化）。
Global Database： Add AWS Region（コンソールで互換エンジン/インスタンスサイズが必要）。
削除順： 先に reader、次 writer、最後 cluster。

Aurora Serverless

Aurora Serverless（現行は v2 — コースは考え方を枠付け）— 固定インスタンスクラスではなく Aurora キャパシティユニット（ACU） で負荷に応じて容量をスケール。

断続的、スパイク、予測困難なワークロードに合い、容量計画が軽い。
使用容量に対して課金（マーケティングでは多く秒単位 — 料金を確認）。
依然として共有 Aurora ストレージモデル；DB 容量の前にマネージドプロキシ/ルーターフリートがありコンピュートのスケールはアプリから見えない（いつも通りクラスタに接続）。

Aurora Global Database

Global Database は Aurora をリージョン横断で拡張。

1 つのプライマリリージョン — すべての書き込みはそこへ。
最大 10 のセカンダリリージョン（ローカル読み取り用の読み取り専用コピー — 上限はドキュメントで確認）。
プライマリ → セカンダリのレプリケーションラグは典型的に < ~1 秒（コースの数値）。
セカンダリリージョンあたり最大 16 read replica（コースの数値）。
災害復旧： セカンダリリージョンを昇格すると研修例では RTO ~1 分未満。

アプリのルール： セカンダリは読み取り；書き込みはプライマリリージョンを指す必要がある。

Aurora の CloudWatch メトリクス（例）

AuroraReplicaLag — 特定レプリカインスタンスのラグ。
Replica lag min/max — クラスタ内インスタンス間の極値；高ラグ → リーダーが古いデータを返しうる（レプリカ間は最終的整合）。
DatabaseConnections — インスタンスあたりの現在接続数。
Insert latency など — INSERT の平均時間（性能トラブルシューティング）。

Aurora バックアップ、backtrack、クローン

機能	動作
自動バックアップ	保持 1～35 日；Aurora では無効化できない（コース）。PITR は新クラスタへ（RDS と同様）。
Backtrack	ウィンドウ内でクラスタをインプレースで巻き戻し（新クラスタ不要）（コース：最大 72 時間）。研修では Aurora MySQL のみ — エンジンサポートはドキュメントで確認。
データベースクローン	ソースと当初同じクラスタストレージボリュームを共有する新クラスタ；変更が分岐すると copy-on-write — 本番からステージングを速く立ち上げる手段。

RDS と Aurora のセキュリティ

保存時の暗号化

KMS CMK を使用；暗号化の選択はプライマリの初回起動時に固定。
Read replica： プライマリが暗号化されていないと、直接暗号化レプリカは作成不可 — 非暗号化 DB のスナップショット → 暗号化してリストア（新インスタンス）。
既存の非暗号化 DB を暗号化：スナップショット → 暗号化リストア。

転送中の暗号化（TLS）

クライアントは AWS RDS CA 証明書で TLS を使うべき（AWS ドキュメントからダウンロード）。

認証

ユーザー名/パスワード（デフォルト）。
IAM データベース認証 — 例：EC2 インスタンスロールがパスワードを埋め込まずトークンを取得（中央の IAM 制御）。

ネットワーク

セキュリティグループがポート/送信元 IP / 送信元 SG のアクセスを制御 — VPC 内 RDS/Aurora の主なネットワーク境界。

アクセスモデル

マネージド RDS/Aurora インスタンスへの SSH なし — RDS Custom（より OS にアクセスできる特別な製品）を除く。

監査

エンジン監査ログを有効化；長期保持と検索は CloudWatch Logs（必要に応じて S3/Athena/OpenSearch へ）。

Amazon RDS Proxy

RDS Proxy は VPC 内のフルマネージド、高可用（multi-AZ）、サーバレススケールのデータベースプロキシ。

使う理由

接続プーリング： 多数のアプリワーカー（または Lambda の同時実行）が短命接続を開く；プロキシが実 DB 接続のより小さい集合へ多重化 → RDS/Aurora の CPU/RAM 負荷軽減、タイムアウトと接続ストームの減少。
より速いフェイルオーバー： コースは RDS Multi-AZ または Aurora のフェイルオーバー混乱を最大 ~66% 削減と引用 — アプリはプロキシエンドポイントのまま；プロキシが新ライターへ付け替え。
IAM 認証 + Secrets Manager で資格情報（オプションの強いパターン）：試験の手がかり「IAM DB auth + secrets を強制」→ RDS Proxy。

互換性と接続

エンジン：MySQL、PostgreSQL、MariaDB、SQL Server、Aurora（MySQL/PostgreSQL 互換）。
DB エンドポイントの代わりにプロキシエンドポイントを使う以外、アプリロジックの書き換え不要（同じ SQL ワイヤプロトコル）。
パブリックに公開しない — VPC 内（および接続ネットワーク）からのみ。

Lambda + RDS

Lambda は多数の同時実行にスケール；プロキシなしでは各関数が新しい DB 接続を開き接続上限を枯渇。RDS Proxy を指しプールが fan-out を吸収。

Amazon ElastiCache

ElastiCache は Redis 互換エンジン（Redis OSS、コンソールでは Valkey が Redis 代替）と Memcached のマネージドサービス — 超低遅延のインメモリストア。

キャッシュの理由

RDS から読み取りをオフロード：キャッシュ確認 → ヒットで返す；ミスなら RDS を読み、後続のヒット用にキャッシュを埋める。
ステートレスアプリのセッションストア：ログイン後どのアプリインスタンスもキャッシュからセッションを読める。

現実： キャッシュにはアプリ変更が要る（ルックアップ戦略、TTL、ソース変更時の無効化 — 難しい部分）。

Redis vs Memcached（試験レベル）

	Redis	Memcached
レプリケーション / HA	Multi-AZ と自動フェイルオーバー；read replica（cluster-mode-disabled では最大 5）	古典モデル：レプリケーションなし；シャード化マルチノード；単純だが揮発的
耐久性	AOF 永続化、バックアップ/リストア（エンジン依存）	多くは純エフェメラル；デプロイモードによりバックアップ/リストアのニュアンスが異なる（コースの serverless vs 自己管理など）
データ構造	Sets、sorted sets（例：リーダーボード）	単純なキー/値
スレッド	簡略化：プロセスあたりほぼシングルスレッド	マルチスレッド構成がスループットに寄与しうる

クラスタ作成（コンソール要約）

エンジン：Valkey（Redis 互換）、Redis OSS、または Memcached；Serverless vs ノードベースクラスタ。
Cluster mode disabled — 1 シャード、1 primary、0～5 レプリカ；cluster mode enabled — 水平スケールアウトの複数シャード。
Multi-AZ + 自動フェイルオーバー（Redis）で HA（追加コスト）。
Subnet group、セキュリティグループ、保存時暗号化（KMS）、転送中暗号化（Redis AUTH トークンまたは ACL user groups を有効化）。
CloudWatch Logs へログ（slow log、engine log）。オンプレ足場の Outposts オプション。

エンドポイント： レプリカ付き Redis の primary と reader にアプリが接続。

Redis のスケール（SysOps / 試験）

Cluster mode disabled

水平： read replica の追加/削除（最大 5）。
垂直： ノードタイプ変更 — 裏で ElastiCache が新ノードグループをプロビジョニングしデータをレプリケート、DNS を更新 → アプリから透過的。

Cluster mode enabled

オンラインスケーリング： クラスタは稼働；変更中性能低下の可能性。
オフラインスケーリング： 変更中クラスタ利用不可；より大きな構造変更（例：一部エンジンアップグレード）を許容。
水平： リシャーディング — シャードの追加/削除；シャード間でキー空間をリバランス。
垂直： シャードのノードタイプ変更 — 多くの場合オンライン。

メトリクス： Evictions（期限切れでないキーを容量不足で落とす）→ エビクション方針、大きいノード、またはより多いシャード/レプリカの調整；CPUUtilization；SwapUsage（低く、コース例 < ~50 MB）；CurrConnections（接続の churn / プール問題）；DatabaseMemoryUsagePercentage；ReplicationLag / BytesUsedForReplication（低ラグが望ましい）。

Memcached のスケール

Cluster： 1～40 ノード（ソフト上限 — 増やすには引き上げ依頼）。
水平： ノードの追加/削除；クライアントはconfiguration endpoint + Auto Discovery で各ノード IP をハードコードせず学習。
垂直： より大きいノードで新クラスタを作成 → アプリを新エンドポイントへ向け替え → 旧クラスタを削除（手動カットオーバー）。新クラスタは空で開始 — アプリが再投入（Redis バックアップ/リストアの単純な話ほどデータの自動移動はない）。

Auto Discovery： クライアントが config endpoint にアクセス → 最初のノードがすべてのノード IP を列挙するメタデータを返す → クライアントがキーに応じたノードに接続。

メトリクス： 同様のテーマ — Evictions、CPUUtilization、SwapUsage、CurrConnections、FreeableMemory。

RDS インスタンスの作成と運用（実習要約）

コンソール： RDS → Databases → Create database。

Easy create vs フル構成 — フルは本番風の Multi-AZ テンプレート（例：2 インスタンス Multi-AZ DB、3 インスタンスクラスタ）を公開；無料枠は多くSingle-AZ のみ。
Engine（例：MySQL）、version、instance class（無料枠例：db.t4g.micro）。
認証情報： 自己管理パスワードまたは Secrets Manager（より安全、追加コスト）。
Auth： パスワードと任意の IAM DB authentication。
Storage： サイズ（例：20 GiB）+ 任意の storage autoscaling と max 上限。
Connectivity： VPC、subnet group、public access（はい/いいえ）、新規または既存のセキュリティグループ（デモでは MySQL 3306 を自分の IP から）。
Port（MySQL デフォルト 3306）。
Monitoring： Standard vs Enhanced Monitoring；任意の CloudWatch へのログエクスポート。

クライアント： endpoint、port、user、password、database 名で任意の SQL クライアントが接続。

実演した操作： CloudWatch メトリクス（CPU、接続）、手動スナップショット、PITR リストア、クロスリージョンスナップショットコピー、read replica 作成、レプリカで Multi-AZ を変更。

クリーンアップ： deletion protection を無効化（modify → apply）し、delete（任意の最終スナップショット）。

要点

RDS = マネージド SQL；エンジンに Aurora、Postgres、MySQL、MariaDB、Oracle、SQL Server、Db2。
Storage Autoscaling は空き容量しきい値、継続時間、クールダウン、最大サイズ上限を使用。
Read replica = 非同期、最終的整合、読み取りスケール / レポート / 昇格；同一リージョン AZ 間レプリケーション無料、クロスリージョンは有料転送。
Multi-AZ = 同期スタンバイ、単一エンドポイント、自動フェイルオーバー；読み取りプールではない；レプリカの Multi-AZ と組み合わせ可能。フェイルオーバーのトリガーを把握（障害、パッチ、ネットワーク、クラス変更、無応答、ストレージ障害、AZ 障害、reboot with failover）。
既存 DB で Multi-AZ 有効化はオンライン；内部は snapshot + restore + sync。
自動バックアップ： 保持 0～35 日、PITR、リストア → 新インスタンス。スナップショット： 手動で永続、共有可能（暗号化は KMS）、Multi-AZ ではスタンバイからスナップショット。
イベント → SNS サブスクリプションまたは EventBridge；ログ → CloudWatch Logs + メトリクスフィルタ / アラーム。
CloudWatch 標準 vs Enhanced Monitoring（OS レベル）；Performance Insights は Waits/SQL/users/hosts（すべてのインスタンスファミリーではない）。
Aurora： MySQL/Postgres 互換、自動拡張共有ストレージ、6/3 AZ quorum の話、writer + reader エンドポイント、高速フェイルオーバー、backtrack（インプレース、コースでは MySQL）、クローン（COW）、クロスリージョン レプリカ / Global Database（プライマリへの書き込み、レプリケーション <~1 秒、DR RTO の話）。
Aurora Serverless： ACU 型スケール、従量、スパイクワークロード向け；プロキシ層がコンピュートスケールを抽象化。
RDS Proxy： プーリング、Lambda 向け、フェイルオーバー ~66% 改善（コース）、IAM + Secrets Manager、VPC のみエンドポイント。
ElastiCache： Redis vs Memcached のトレードオフ；cache-aside + セッション；cluster mode on/off のスケールパターン；Memcached の垂直 = 新クラスタ + 向き先変更；Memcached クライアントの Auto Discovery。
セキュリティ： 作成時の KMS 保存時暗号化；暗号化は snapshot-restore；転送は TLS；IAM DB auth；SG；RDS Custom を除き SSH なし；監査ログ → 保持/分析は CloudWatch Logs。

Claudeによる翻訳