RDS Aurora ElastiCache
大前提として、VPCの DNS解決を有効 DNSホスト名を有効 にしていないとDBを立ち上げることができない
DBのパブリックアクセス可能だと、ローカルからSqlectronで接続してDBをいじれる
RDSへの接続がめちゃくちゃ早い！
※Server Adressには、「エンドポイント」のURLを入力する
Amazon RDS（Relational Databese Service）
SQLでアクセスするマネージドDBサービス
PostgreSQL, MySQL, MariaDB, Oracle Database, MS SQL Server, Aurora
専用インスタンスが建つ 自動プロビジョニング、OSパッチの自動更新
EBS（gp2 or io1）で自動バックアップ
毎日フルバックアップ（メンテナンスウィンドウ中）
５分毎にトランザクションログをバックアップ
タイムスタンプでリストア（Point in Time Restore）最古～5分前まで
バックアップは 1 ～ 35日間 保持できる
DBスナップショット（手動）
オートスケーリング
Maximum Storage Threshold（DBストレージの上限）を設定する
トリガー：前回の変更から6時間経過していて、ストレージの空きが10%以下の状態が5分以上続いた時
マルチAZ（同期）でDR（Disaster Recovery）に対応できる
インスタンスにSSH接続することはできない
RDSリードレプリカ（読み専の非同期レプリカDB）
最大5台のリードレプリカを建てることができる
AZ内、複数AZ分散、リージョン分散 なんでもござれ
レプリケーションは非同期だが、Masterに書き込みがある度にレプリカにも反映される
（タイミングによっては、ちょい古データが返ってくるかもしれないね）
SELECT命令のみ使える（更新系のINSERT, UPDATE, DELETEは使えない）
用途：分析や報告の時に便利だね
リードレプリカへの非同期データ伝送は、同一リージョン内であれば、マルチAZであってもコストはかからない
クロスリージョンだとお金が発生するからね！
マルチAZ（ディザスタリカバリ）
同期複製（同期レプリケーション）
DNS名で自動フェイルオーバー（だからVPCのDNS解決/DNSホスト名が有効になっていないといけないのか！）
※リードレプリカもマルチAZ設定ができる
シングルAZからマルチAZへの移行
ゼロダウンタイムで移行できる（DB停止する必要なし）
データベースの変更をクリックするだけ 簡単
裏側の動き
スナップショットの撮影
スナップショットから新しいDBを新しいAZに復元（EC2の複製に似てるね）
2つのデータベースの間に同期が確立される
RDSのセキュリティ
データの暗号化
AWS KMS（Key Management Service）を使ってマスターとリードレプリカを暗号化することが可能 AES-256
起動時に暗号化を定義する必要がある
マスターが暗号化されていないと、リードレプリカも暗号化できないが・・・
暗号化されていないRDSのDBを暗号化する方法があるっちゃある（EBSの暗号化と同じ方式） 元DBのスナップショットを作成
スナップショットをコピーする時に暗号化を有効にする
そのコピースナップショットからDBを復元する
アプリを新しいDBに移行して、古いDBを削除する これで完成ｗ
OracleDBとMS SQLでは透過的データ暗号化（TDE）が利用できる
通信の暗号化
SSL証明書でRDSの送受信データを暗号化（いわゆるHTTPS通信）
DB接続時に信頼証明書付きのSSLを使うオプションがある
SSLを強制させるために
PostgreSQL：AWS RDSコンソール（パラメータグループ）で rds.force_ssl=1
MySQL：DBの中でSQLコマンドを実行 grant usage on *.* to ‘mysqluser’@’%’ require ssl;
ネットワークセキュリティ
そもそも、RDS DBインスタンスはプライベートサブネット内に配置される
セキュリティグループをアタッチしてセキュリティを担保している
デフォinboundルール proto：TCP port：3304 source：マイIP/32
※マネジメントコンソールにアクセスしているPCのWAN側IPアドレスを自動判別してるっぽ
アクセス管理
従来のユーザー名とパスワード認証でログイン制御に加え、
IAMポリシーで（RDS APIを通じて）AWS RDSを管理できる人を制御することができる
IAM認証
MySQLとPostgreSQLで動作する
PW不要、IAMとRDS API呼び出しで取得した認証トークン（15分有効）だけでOK
メリット：入出力がSSLで暗号化される、IAMで認証ユーザーを一元管理できる、IAMロールやEC2プロファイルを活用して簡単に統合可能
Amazon Aurora
AWS独自技術（OSSではない）
MySQL / PostgreSQLを、AuroraDBとしてサポート
AWSクラウドに最適化されており、RDS上のMySQLより5倍 / PostgreSQLより3倍速い
Auroraストレージは 10GB単位で 最大64TBまで自動的に増加する
最大15のレプリカを持てる(RDSは最大5だけ) レプリケーションプロセスはより高速（10ms以下）
フェイルオーバーは瞬時に行われる High Availabilityネイティブ 高可用性
RDSよりは若干高額（それでも約20%高いだけ）
3つのAZに6つのデータコピー
6つ中4つのデータコピーに書き込み
6つ中3つのデータコピーから読み込み
ピアツーピア・レプリケーションによる自己ヒーリング
ストレージは100個のボリュームでストライピング
1つのAurora Instance（マスター）が書き込みを行う
マスターは30秒以内の自動フェイルオーバー
マスター＋最大15台のレプリカ（Aurora Read Replicas）がリードを担当
クロスリージョンレプリケーションのサポート
Aurora DB Cluster
書き込みエンドポイント 読み込みエンドポイント
マスター レプリカ（オートスケーリング）
←ーーーーーーーーーーーーーーーーーーーーーーーーーーー→
共有ストレージボリューム（10G～64TBまで自動拡張）
その他の特徴としては・・
バックアップ＆リカバリー（Backtrack：バックアップを使わずに任意の時点のデータを復元）
隔離とセキュリティ
業界標準のコンプライアンス
ゼロダウンタイムの自動パッチ適用
高度なモニタリング
定期メンテ
セキュリティ
RDSと同じ（RDSと同じエンジンを使っている）
KMSを利用したデータの暗号化→自動バックアップ/スナップショット/レプリカにも適用
インスタンスの作成にはけっこう時間がかかる（5分以上）
レプリカオートスケーリング
レプリカが増えると、エンドポイントも増える（自動的に拡張される）
・・・って、利用者はどうやってそのエンドポイントを知るの？
カスタムエンドポイント（読み込み用）
これを使うと、通常のリーダーエンドポイントは使わない
Aurora Serverless
実際の使用状況に応じたデータベースの自動生成と自動スケーリング（キャパシティ計画が不要）
Auroraが管理するプロキシフリートというIFの下にAuroraDBがぶら下がる形態
秒単位の支払いで、より高い費用対効果が期待できる
マルチマスター
ライトノードの即時フェイルオーバー（HA）が必要な場合に
すべてのノードがR/Wを行う – リードレプリカを昇格させる仕組みとは全く異なる
グローバルAurora
Aurora Cross Region Read Replicas これ手動？
ディザスターリカバリーに有効 設定が簡単
Aurora Global Database（推奨）リージョン単位のDR＆昇格
1プライマリリージョン(R/W)
最大5つのセカンダリ(RO)リージョン レプリケーションラグは1秒以下 最大16個のリードレプリカ
プライマリリージョン側で障害が発生すると、セカンダリリージョンのレプリカROがマスターR/Wに自動で昇格する仕組み
ディザスタリカバリの為に別のリージョンをメインに切り替える場合、RTO(Recovery Time Objective：目標復旧時間)は1分未満
ElastiCache
インメモリーDB「Redis」、「Memcached」のマネージドサービス
非常に高い性能と低レイテンシー 読み取りが多いワークロードでDBの負荷を軽減
アプリケーションのステートレス化に貢献
使用するには、アプリケーションのコードをElastiCache専用に書き換えなくてはならない
DBキャッシュ
アプリ — ElastiCache — RDS アプリとDBの間に置いとくもの
RDSが生きているときにキャッシュを受け取るので、RDSが死んでいるとElastiCacheも動かないらしい（AWS SUMMITで言ってた）
キャッシュには、最新のデータだけが使われるようにするための無効化戦略（Neutralization Strategies）が必要
ユーザーセッションストア
ユーザーのログイン状態をElastiCacheに保持しておく仕組み
アプリケーションの別インスタンスにヒットした場合でもログインセッションを保持する
キャッシュのセキュリティ
IAM認証に対応していない
ElastiCacheのIAMポリシーは、AWSのAPIレベルのセキュリティにのみ使用される（RDSとの大きな違い）
パターン
レイジーローディング
読み込まれたデータはすべてキャッシュされるが、キャッシュのデータが古くなる（データが無効になる）可能性あり
キャッシュミス時はDBから読み出し、最新データをキャッシュに書き込む
ライトスルー
DBに書き込まれた際に、キャッシュ内のデータを追加・更新する（無効なデータが発生しない）
セッションストア
一時的なセッションデータをキャッシュに保存（TTL機能を使用）
Redis – レプリケーション
オートフェイルオーバー付きマルチAZ
リードレプリカによるリードの拡張と高可用性の確保
AOFパーシスタンスによるデータの耐久性
バックアップ・リストア機能
Redis認証：
Redisクラスタの作成時に「パスワード/トークン」を設定することができる
（セキュリティグループに加えて）キャッシュのセキュリティレベルを向上させられる
SSLによる通信の暗号化
使用例：ゲームのリーダーボード
Sorted Set利用で一意性と要素の順序付けの両方を保証
新しいスコアが追加されるたびにリアルタイムでランキング更新、正しい順番で追加されていく
Memcached – シャーディング
データを分割するためのマルチノード（シャーディング）
ハイアベイラビリティー（レプリケーション）がない
非永続的
バックアップ・リストアなし
マルチスレッド・アーキテクチャ
Memcached認証：
SASLベースの認証に対応（上級）