RDSについて色々概要だけメモ
可用性
AZ障害対応
- AZ障害時にフェイルオーバーする。エンドポイントが切り替わる。60〜120秒。 Java仮想マシン利用時はDNSキャッシュがの起こる。キャッシュ残る時間TTLを60秒以下にするのを推奨。
- 可用性が目的であり、読み取り性能向上が目的じゃない。スタンバイ側でトラフィック処理は出来ない。
読み取り性能上げるならリードレプリカを使う。
※Auroraはスタンバイとリードレプリカ兼用。
- レプリケーションの関係上、シングルAZよりかは読み取り性能が劣る。
- シングルAZ、マルチAZ構成選択可能。後から変更も可能。
リージョン障害対応
○DBスナップショット、Lambdaを使用したクロスリージョン自動DR
CloudWatchのスケジュールされたイベントを基に、Lambdaでスナップショットの作成と別リージョンへのコピーを日々行う。RDSからのイベントを受けたらSNSをトリガーに別リージョンにコピーされたスナップショットを復旧させる流れ
- Amazon RDSイベント通知にサブスクライブするためのAmazon SNSトピックを作成
- プライマリデータベースでAmazon RDSイベント通知を有効
- 次の操作を実行するためのLambda関数を作成
- プライマリデータベースのスナップショット作成
- スナップショットをDRリージョンにコピー
- 障害が発生した場合、DRリージョンのコピーされたスナップショットを復元
- RTO（復旧目標時間）の要件に基づいて、初期スナップショットの作成をスケジュールするために、Amazon CloudWatch Eventsを有効化
- オプション：古いスナップショットを削除するための追加のLambda関数を作成。
パフォーマンス
ストレージのAutoScaling
空き容量10%以下の状態が5分以上
で、5GB or 割り当て容量の12% のどちらか大きい値で追加される。
ただし、変更後6時間の間隔が必要。
リードレプリカ
- 1プライマリにつき5個まで
- 手動操作でプライマリに昇格可能。
- 別リージョンに作成可能。(SQL Server以外)
- 自動バックアップを有効かつ保持期間を0以外にする必要あり。 プライマリのスナップショット取得し、スナップショットを基にレプリカへのレプリケーションを開始する為。 上記処理の流れ上作成直後はデータ差分の同期が発生してパフォーマンス低下する。
- リードレプリカの接続エンドポイントは独立してる。統合も可能。
RDS Proxy
DBへの接続で、通コネクションプーリングと呼ばれる、接続を維持する機能がある。
EC2はこれを実装可能だが、Lambdaなどのは採用難しい。
そこで本機能を使う事でエラー発生を抑止できる。書き込みのみサポート。
料金
○インスタンス
1時間単位で発生。停止してもストレージは料金別
○ストレージ
確保した容量と”I/O”に比例。
バックアップストレージにもかかるが、容量分100%は料金無し。
○データ転送
VPC外部かつ、データ送信のみに料金発生。
メンテナンス
メンテナンスウィンドウという利用者が設定したタイミングで実施される。
メンテナンスの状態
・必須
無期限延長不可。基本メンテナンスウィンドウ内だが、緊急時はそれ以外の場合もある。
・利用可能
手動適用可能。無期限延期可能。
・次のウィンドウ
次回メンテナンスウィンドウに予定のメンテナンス。延期可能。
・進行中
進行中のメンテ
マルチAZでのメンテ
以下の順序で実施される。
1.スタンバイで実施
2.スタンバイをプライマリへ昇格
3.旧プライマリをメンテ後、旧プライマリがスタンバイになる。
データベースエンジンのアップグレード
- プライマリスタンバイ両方同時に実施される。
- メジャーバージョンのアップグレード 利用者が手動にて、即時か次のメンテナンスウィンドウ
- マイナーバージョンのアップグレード 手動も自動も可能。
データベースの停止
リードレプリカ及び、リードレプリカを持つプライマリDBは停止出来ない。
もしプライマリDBを一時停止する場合は、リードレプリカを事前に削除する必要がある。
ストレージサイズ縮小
1.必要容量のストレージにて新しいインスタンスを作成
2.DMSにてデータ移動
バックアップ
自動バックアップ
- 保持日数を0〜35の間で指定。0だと無効。デフォルトは7
- 取得時間の指定が出来ない。時間を指定する場合はLambda+CloudWatchEventsが良いか。
もしくはAWS Backup - 差分によるバックアップ。
- シングルAZだと”I/O”の中断あり。マルチAZだと基本ない。
- スナップショットはS3の見えない領域に保管されている。
手動スナップショット
有効期限がない為、自動削除されない。
35日以上保管したい場合、Lambdaで手動スナップショットを取得する方法はあり。
AWS Backup
- 他サービスと一元管理できるサービス。これでもRDSバックアップ可能。
- コピー機能も自動実行可能
- 保持日数では無く時間単位
スナップショットコピー
- 自動・手動いずれでもコピーが可能。全て手動バックアップとして扱われる。
- 他リージョンへも可能。DRに利用。
デフォルトKMSキー(AWS管理CMK)で暗号化した自動スナップショットを別アカウントと共有する方法
注意事項：
・自動スナップショットは別アカウントに共有できない
・デフォルトKMSキー(AWS管理CMK)で暗号化されたスナップショットは別アカウントにコピーできない
・デフォルトKMSキー(AWS管理CMK)に権限付与はできない
①ソースアカウントと同じリージョンでカスタムKMSキー(カスタマー管理CMK)を作成し、コピー先アカウントの権限を付与する。
②①のKMSキーをマスターに指定し、コピーした手動スナップショットを作成して共有
③ターゲットアカウントでは共有されたスナップショットを権限付与されたKMSキーを使用してソースアカウントと同じリージョンへコピー。
復元する場合
- 新規DBの形でなら可能。既存DBへは不可。
- 接続エンドポイントも変更となる。
ポイントインタイムリカバリ
スナップショットとは別にトランザクションログがS3上に5分単位で保存されている。
自動バックアップで取得したデータと、S3のバックアップを合わせて新規にクラスターを作成する。
特定の時間での復元が可能。他のRDSにもある機能
S３へエクスポート
Amazon Athenaなどから検索、分析できる状態にできる。
エクスポートはスナップショットから行う。
モニタリング
CloudWatch
設定を行わず標準で監視可能。CloudWatchlogsへ連携
拡張モニタリング
OS内部のリソース収集可能。
パフォーマンスインサイト
CPU負荷の高いSQL文などを視覚的表示。
イベントサブスクリプション
再起動、フェイルオーバー等のイベントを通知する。
メンテナンス
パラメータグループ
設定値の集合。AWSが提供するデフォルトパラメータは変更不可
○パラメータの種類
・静的パラメータ
→変更後再起動にて適用。マルチAZでも自動で再起動されるわけでは無い。独自にメンテナンス時間を設ける必要がある。
・動的パラメータ
→変更後即適用。
セキュリティ
データ格納時の暗号化(KMSキー)
KMSキーを使用。インスタンスの暗号化に利用したキーを別管理にする事で、キーが
漏洩してもデータ保護が可能。
・暗号化はDBインスタンス作成時のみ。
・既存のインスタンスを暗号化する場合は、スナップショットを作成。そこからコピーする際に
暗号化し、そこからリストア。
・リードレプリカのみ、プライマリのみを暗号化は不可。
・リージョン間でのスナップショットコピーは、異なるKMSキーを指定する必要あり。
暗号化されていないインスタンスの暗号化
１.DBのスナップショット取得
2.スナップショットの暗号化されたコピーを作成
3.暗号化されたスナップショットから新しいDB作成
データ通信中の暗号化
SSL、または、TSLを使用。
証明書を接続する側で適用し、所定のコマンドで接続。
監査機能(Advanced Auditing)
独自の監査機能。
監査ポリシーを作成して、監査するアクション、条件、出力方法を指定
IAMでの認証
認証を行う方法はIAM認証を用いる。パスワードの代わりに認証トークンを使用。
認証トークンは15分のみ有効の文字列。
メリットは
・送受信はSSLで行われる
・DB個別で管理が不要で一元的に管理できる。
・EC2で実行するアプリの場合、EC2にプロファイル認証情報を置いてアクセス可能。
設定は以下の通り
1.DBでAIM認証を有効化し、AWSAuthenticationPluginオプションでユーザを設定。
2.1で設定したユーザのアクセスを許可するIAMポリシー作成
3.EC2インスタンスプロファイルに関連ずけされたIAMロールにポリシーをアタッチ
4.CLIでトークンを生成して接続
