参考書を1周した. 普段RDSを道具として使っているだけでは経験しない知識を得ることができた.
インフラ系の仕事をしないと使わない可能性がある知識もあるが、アプリケーションエンジニアとしては、
RDSがここまでやってくれると知っていることで無駄な機能を作り込んだり、余計な心配をしなくて済む.
可用性
スケールアウトすることで何が冗長化されるのか.
いざフェイルオーバーが発生したときどういう挙動になるのか.
まとめ
- プライマリインスタンスとスタンバイレプリカを別AZに配置することで可用性を得る
- プライマリとスタンバイの間で常にデータ同期がおこなわれる
- プライマリに障害が発生した場合スタンバイにフェイルオーバーすることでDB接続を継続する
- スタンバイはトラフィック処理しない. 読み取り性能を上げるためにはリードレプリカを追加する
- スタンバイがある場合、スタンバイを対象にRDSのスナップショット取得がおこなわれ、プライマリのトラフィックに影響を与えない
- マルチAZの場合、スタンバイとのデータ同期によりシングル構成よりも書き込み・コミットでわずかにレイテンシが上がる
AZの変更
- プライマリのスナップショットを作成後、セカンダリとして復元し同期
- AZ変更時はプライマリのパフォーマンスに影響する
フェイルオーバー
- RDSの外からはエンドポイントでつなぐ
- プライマリに障害が発生した場合、エンドポイントの先が自動的にスタンバイにつなぎ変わる
- 切り替えにかかる時間は60秒-120秒.
- DNSキャッシュのTTLを60秒以内にしておくことが推奨されている
- AWSコンソールから手動でフェイルオーバー時の挙動を確認できる
パフォーマンス
スケールアップで何が良くなるのか。スケールアウトではどうか。
スケールアップさせることを前提にできるのか。
まとめ
- データベースのパフォーマンスは主にデータの読み書きのパフォーマンス
- 汎用SSD.3IOPS/GB. バースト(一時的に)100-10,000IOPS.
- プロビジョンドIOPS. 常に1,000-30,000IOPS.
- ストレージ容量の残量が10%以下の状態が5分以上続いた場合、5GBまたは割り当て容量の12%のどちらか大きい方が自動的に追加される
- 容量を頻繁に拡張できるわけではない.1度変更すると6時間変更できない. Storage Auto Scalingに頼るべきではない
リードレプリカ
- 読み込み性能は、プライマリを複製したリードレプリカを増やすことで対応. トラフィックがリードレプリカに分散される
- 書き込み性能は、スケールアップにより対応
- プライマリとリードレプリカの同期は非同期. 微妙に異なる.
- プライマリのスナップショットからリードレプリカが作成され複製される.従って作成直後は異なる
- リードレプリカは最大5個
- プライマリとリードレプリカのインスタンスサイズは異なっていても良い
- 手動でリードレプリカをプライマリに昇格可能
- マルチAZ可能. DR対応で別リージョンにリードレプリカを作成可能.
- リードレプリカのエンドポイントはそれぞれ異なる.負荷分散する場合、Route53等で1つのDNSレコード先を分散させる
RDBMSごとの制約
- SQLServerの場合、特定エディション以上でリードレプリカを使用可能
- SQLServerの場合、マルチリージョン、マルチAZリードレプリカを作成不可
- Oracleの場合、特定エディション以上でリードレプリカを使用可能
- Oracleの場合、OracleのActiveDataGuargeにより同期がおこなわれる
RDS Proxy
- アプリケーションがDBにアクセスする際、一度作成したコネクションをプーリングして使い回す機能
- 昔、LambdaからRDSにつなぐ際、コネクションがプールされずすぐに最大接続数を超過していたがこれで解決した
- RDS Proxyはプライマリインスタンスのみ対応
セキュリティ
アプリケーションが個人情報の暗号化を意識する必要があるのか。RDSが透過的に面倒を見てくれるのか。
まとめ
- RDSを設置するVPCには少なくとも2つのサブネットが必要
- VPCのACL、SGでアクセス制御する
- SGの送信元にはSGを指定できる.SGとSGの接続を定義できる
暗号化
- データ格納時の暗号化と通信時の暗号化の2つ
- KMSのキーを使用して格納するデータを暗号化. KMSキーを別管理することでRDS内のデータが漏れても保護できる
- KMS暗号化は透過的におこなわれる. アプリケーションは特に意識しなくても良い
- 暗号化の対象は以下の通り
- DBインスタンスに格納するデータ
- 自動バックアップ
- リードレプリカ
- スナップショット
- ログファイル
- DBインスタンス作成時にのみ暗号化可能. 未暗号化インスタンスのスナップショットを作成して復元時に暗号化
- プライマリだけ、リードレプリカだけ、のように非対称に暗号化することはできない
- KMSはリージョンを跨げないためリージョン間スナップショットを取る場合はコピー先のリージョンでコピー元とは異なるKMSキーを指定する必要がある
- SSL/TLSにより伝送中データの暗号化
- AWSからルート証明書をDLしアプリケーション側でSSL/TLS通信時に取得したルート証明書を使う
- ルート証明書は定期的に失効する. 都度ダウンロードして更新すること
IAMによるDBアクセス認証
MySQLとPostgreSQLに限り、IAMを使用したDBアクセス認証を利用できる.
- RDSへアクセス可能なIAMロールを作成. アプリケーション側は作成されたIAMロールを使ってRDSにアクセス
- アプリケーション側で接続情報を管理しなくてもよい
監査ログ
- DBエンジンがもつ監査ログ機能を利用できる. 監査ログはCloudWatchに転送され、管理・監視できる
コスト
アプリケーション側をチューニングする人的コストと、インスタンスに使うコスト。
何に料金がかかるということを把握して、アプリケーション側でやるべきこと/AWS側に振ることを意識する.
まとめ
- RDSで発生するコストはインスタンス料金、ストレージ料金、データ通信料金
- インスタンス料金
- コストは1秒単位.ただし1時間未満は最低10分から.
- 2AZに配置した場合、リードレプリカを設置した場合、インスタンス数が2倍になるのでインスタンス料金も2倍になる
- DBエンジンの種類によって若干インスタンス料金が異なる.MySQL
- 1年または3年の前払い制(リザーブドインスタンス)により割安になる.損益分岐点あり
- インスタンスを停止するとインスタンス料金の課金は止まる.ただし1週間止めておくと自動的に起動してしまう.
- ストレージ料金
- インスタンスを止めていてもストレージ料金の課金は止まらない
- 利用中のストレージサイズと同サイズまでのバックアップには課金されない.それを超えたところから課金される.ただし超えた分は安い
- データ転送料金
- RDSへのINは無料
- RDSからVPC外部、またはインターネットへの通信は課金される.
- 通常VPC内部でEC2とやりとりする場合は無料だが、VPC外部とやりとりする場合注意
メンテナンス
作ったアプリが保守フェーズに移行した後、アプリケーション側は何を意識しなければならないか.
まとめ
- AWSが実施するメンテナンスの実行時間を指定できる.(メンテナンスウインドウ)
- 22:00-06:00の間の30分. 大きなメンテナンスの場合1時間かかる場合がある.余裕をみて1時間設定する
- メンテナンスウインドウ期間中、いくつかのメンテナンスによりインスタンスが一時的にオフラインになる
- メンテナンス種別は「必須」と「利用可能」. 「必須」は無期限延期できない. 「利用可能」はできる.
- アプリケーションの動作に影響がありそうなものは開発環境で事前に検証すること
- マルチAZのメンテナンス
- まずスタンバイについてメンテナンスを実行
- スタンバイをプライマリに昇格. 降格した元プライマリにメンテナンスを実行.そのままスタンバイになる
- 全体としてインスタンスがオフラインになることがない.
- ストレージ追加、インスタンスタイプの変更は任意またはメンテナンスウインドウ
- DBエンジンのアップグレード
- メジャーバージョンアップはユーザ自身が実施
- マイナーバージョンアップは設定次第で自動でやってくれる. 手動でも可.
パラメータグループ
- 設定値(パラメータ)のグループ. 例えばMySQLのconfに書くような設定値が集まったもの.
- DBエンジンごとに様々なパラメータが存在する
- デフォルトパラメータグループ
- ユーザは変更できない.
- ユーザが独自のパラメータグループを作成しデフォルトパラメータをオーバーライド
- すぐに適用される「動的パラメータグループ」.再起動が必要な「静的パラメータグループ」
- 追加設定はオプショングループ.デフォルトのパラメータは変更できず,ユーザが作成してオーバーライド
バックアップ
これも, 保守フェーズに移行した後アプリケーション側で何を意識しないといけないか.
自動バックアップと手動バックアップ
- 自動バックアップ
- 自動的にスナップショットを保存. 保存日数はデフォルト7日.0(無効)-35日.
- スナップショットは不可視のS3に保存される.
- 初回のスナップショットはフル. 2回目以降は差分.
- バックアップはメンテナンスウインドウで作成される.
- シングルAZの場合一時的にオフラインになる. マルチAZの場合オフラインにならない
- 手動バックアップ
- 任意のタイミングでバックアップできる. 手動バックアップは自動的に削除されない.
DR目的で別リージョンへのスナップショットコピー
- 別リージョンに手動でスナップショットをコピーできる
- 暗号化用KMSキー、オプショングループは自動でコピーされないので自力でコピー先に作る
別アカウントとスナップショット共有
- 手動バックアップしたスナップショットを別アカウントと共有できる
- 暗号化済みの場合、KMSキーを共有先にアクセス許可する
- 暗号化していない場合、格納された個人情報にアクセス可能となる
スナップショットの復元
- 既存のRDSインスタンスに復元できない.新しいRDSインスタンスを復元する
- エンドポイントが変わるのでアプリケーション側の再設定が必要
- パラメータグループはインスタンスに紐づくため復元時に復元元のパラメータグループを使用する
PITR(ポイントインタイムリカバリ)
- スナップショットとは別にトランザクションログがS3に5分単位で保存される
- スナップショット復元と合わせて最短で5分前までの状態に復元が可能.
S3へのエクスポート
- スナップショットからS3にエクスポートできる
- 不可視のS3ではなく、Amazon Parquet形式でS3バケットにデータをエクスポートできる
- Athena、Redshift等別サービスからS3上のファイルを検索、分析できる
モニタリング
作ったアプリがショボすぎて速度が出ない! ピンチを救うAWSの機能.
保守フェーズ移行, 劣化やユーザ数増加により受けた影響の調査. 他.
- インスタンスが効率的に使われているかを調べるためにリソース使用状況を監視できる
- CloudWatchにメトリクスが展開される.
- CloudWatchAlarmによりメトリクスの変化に伴ってSNS通知などアクションを実行できる
- DBエンジンが出力するログはCloudWatchLogsに転送できる
- ログに含まれる特定のエラー文字列を見つけてSNS通知するなどのユースケース
- 拡張モニタリングにより詳細なリソースデータを監視できる.
- パフォーマンスインサイト. パフォーマンスに関するデータを可視化する. ユーザ自身が可視化ツールを用意しなくてもある程度は確認できる
- スロークエリ、実行計画の確認などができる. パフォーマンスチューニングの初手に使える
- フェイルオーバーや再起動などをトリガーとしてSNS通知できる