目次
RDS の特徴
- リードレプリカ、マルチ AZ 配置、およびマルチリージョン配置が可能です。
- Storage Auto Scaling（オートスケーリング）のサポートが開始され、増加するデータベースのワークロードに応じて、RDS のストレージ容量がダウンタイムなしで自動的にスケール（増加）されます。
- RDS は利用している途中でインスタンスタイプを縮小することができます。
- RDS はリードレプリカによって、データベース (DB) インスタンスのパフォーマンスと耐久性が向上します。
- RDS は ACID トランザクションをサポートする、可用性が高く一貫性のあるデータベースです。
Amazon RDSの全体図
Amazon RDS の全体図です。Aurora は RDS の一部です。しかし RDS と Aurora はアーキテクチャが異なります。
Amazon RDS
├─ RDS for MySQL
├─ RDS for PostgreSQL
├─ RDS for MariaDB
├─ RDS for Oracle
├─ RDS for SQL Server
├─ RDS for Db2
└─ Amazon Aurora
├─ Aurora MySQL-Compatible
└─ Aurora PostgreSQL-Compatibleクロスリージョンリードレプリカ
- リージョン間でリードレプリカ（クロスリージョンリードレプリカ）を作成できます。その結果、災害復旧機能が向上しグローバルにスケールアウトできます。
- クロスリージョンリードレプリカは MySQL、MariaDB、PostgreSQL、Oracle(EE+ADG)で利⽤可能です。
- SQL Server の場合クロスリージョンでバックアップをコピーするなどの対応が必要です。
クロスリージョン自動バックアップ
- ⾃動バックアップのバックアップデータを別リージョンに⾃動で転送します。
- 転送されたリージョンでPITRで復元することが可能です。
- Oracleの場合、BYOLまたはライセンス込みで、バージョン12.1.0.2.v10以降で利⽤可能。SE2も可能です。
- RDS for PostgreSQL にも対応します。
スナップショット
- 個々のデータベースだけではなく、その DB インスタンス全体がバックアップされます。
- DB インスタンスを復元するとき、復元の元となる DB スナップショットの名前を指定し、復元オペレーションから作成される新しい DB インスタンスの名前を指定します。（つまり、別の DB を構築することになります）
- スナップショットと自動バックアップは S3 に保存されます。
- RDS のスナップショットは手動で取得することができます。
- RDS のスナップショットは自動手動の設定ができます。
- RDS はクロスリージョン（マルチリージョン）でのスナップショットをサポートしていません。
RDS の暗号化について
RDS の暗号化対象
- DB インスタンス
- 自動バックアップ
- リードレプリカ
- スナップショット
RDS プライマリストレージサービスタイプ
- Amazon RDS は 3 種類のストレージタイプを提供します。
- ①汎用 SSD (別名 gp2)
- ②プロビジョンド IOPS SSD (別名 io1)
- ③マグネティック (別名標準) ← 旧世代の HDD。下位互換性のため。
RDS のサーバーサイド暗号化（SSE）について
RDS インスタンスのサーバーサイド暗号化は、ざっくり言うと RDS のディスク上に保存されるデータを AWS 側で暗号化してくれる機能です。RDSでは encryption at rest / 保存時の暗号化として説明されることが多いです。
RDS インスタンスで暗号化を有効にすると、主に以下が暗号化されます。
- DB インスタンスのストレージ … 暗号化される
- 自動バックアップ … 暗号化される
- 手動スナップショット … 暗号化される
- リードレプリカ … 暗号化される
- トランザクションログなどの保存データ … 暗号化される
- 通信経路 … 別途 TLS/SSL 設定が必要
保存データの暗号化と通信の暗号化は別物になります。
暗号化は KMS を利用する
RDS の暗号化では AWS KMS キーを使います。AWS マネージドキーとカスタマー管理キーを利用できます。より厳密にアクセス制御・監査・ローテーション管理したい場合はカスタマー管理キーを使う必要があります。
何から守れるか
RDS の保存時暗号化で守れるのは、主に以下です。
・ストレージが不正に読み取られた場合
・スナップショットが流出した場合
・バックアップデータが不正に取得された場合
・KMS 権限のない人が復元しようとした場合特にスナップショットを保護できるのが大きいです。スナップショットを暗号化することで、勝手にスナップショットを復号しようとしても KMS キーの権限がない人は復号できません。
ただし、以下については SSE では防げません。
- DBユーザーでログインされる … 防げない
- アプリケーション経由でSQL実行される … 防げない
- SELECT権限でデータを見られる … 防げない
- 通信経路の盗聴 … TLS未使用なら防げない
- IAM/KMS権限の誤設定 … 防げない
RDS 暗号化は 保存データの保護であって、DBアクセス制御そのものではありません。
リードレプリカとスレーブの違いについて
- リードレプリカ ← 読み込み専用のデータベース。利用者が直接アクセス可能。
- スレーブ ← マスターのバックアップ。セカンダリ。同期レプリケーション。利用者は直接アクセスできない。マルチ AZ 構成で、マルチリージョン構成ではない。
Amazon Aurora
■Aurora の特徴について
- RDS はマネージド型サービスであるため、インフラ管理やDBソフトウェアのバージョン管理などは AWS 側で実行されます。（パッチの適用は管理できません。）
- マルチマスタークラスター機能とシングルマスタークラスター機能の 2 つがある。
- マルチマスタークラスター機能は、別 AZ のすべてのインスタンスに読み書き機能（Write）がついています。（リードレプリカだけではありません）
- AWS がマネージメントをしている為、最新バージョンの DB が直ぐに利用できるわけではありません。
- Aurora クラスターボリュームは、マルチ AZ（複数のアベイラビリティゾーン）に跨り仮想ボリュームを構成しています。
- Aurora の可用性は 99.99% です。（年間で 秒停止、月間では 秒停止）
マルチマスター構成（Aurora Multi-Master 構成）
Aurora のマルチマスター構成は複数ノードに書き込みが行える高可用性なクラスタ構成です。
1つのリージョンで複数のAZにまたがって構成できます。
そもそも Amazon Aurora はシングルマスタ・クラスタでも SLA が 99.99%ですが、マルチマスター構成により更に高い可用性を構成できます。
■マルチマスター構成の特徴
- すべての DB インスタンスに読み書き機能がついています。
- 単一の読み書きプライマリインスタンスと、複数の読み取り専用 Aurora レプリカとは異なります。
- マルチマスタークラスターには、プライマリインスタンスまたは読み取り専用の Aurora レプリカはありません。
RDS のフェイルオーバーについて
- Amazon RDS は、マルチ AZ 配置を使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。
- Amazon RDS のマルチ AZ 配置では、異なるアベイラビリティーゾーンに同期スタンバイレプリカが自動的にプロビジョニングされて維持されます。
- RDS コンソールを使用すると、DB インスタンスを作成する際にマルチ AZ を指定するだけでマルチ AZ 配置を作成できます。
※RDSはマルチ AZ のフェイルオーバーをサポートしていますが、マルチリージョンのフェイルオーバーはサポートしていません。
■参考（RTOとRPO）
Aurora のリードレプリカの特徴について
- パフォーマンスと耐久性が向上します。
- 読み込み処理の負荷を下げることができます。
- リードレプリカは最大で15個まで追加可能です｡
- リードレプリカは、①アベイラビリティゾーン内、②マルチ AZ（AZ間）、③リージョン間で構成することができます。
- Aurora DB クラスター内の独立したエンドポイントであり、読み取りオペレーションのスケーリングと可用性の向上に最適です。
- 1 つの AWS リージョンの中で DB クラスターが処理するアベイラビリティーゾーン全体に分散できます。
- DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。
- クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。
- リードレプリカはシングルマスターです。
- マスタスレーブ構成のスレーブに対するリードレプリカも構築することができます。
- リードレプリカは非同期レプリケーションです。
Amazon Aurora Serverless
■Amazon Aurora Serverless の特徴
- 管理する DB インスタンスはありません。データベースは、アプリケーションニーズに応じて、容量を自動的に起動、停止、および拡大または縮小します。
Amazon Aurora Serverless の使いどころ
Aurora Serverless の使いどころとしては一定した高負荷な使用状況ではなく、低負荷、低頻度、断続的な使用、予測不可能な使用状況が考えられます。
実際にデータベースを運用してみると机上の計算とは違い、実際はリソースをほとんど使用しないケースが多いです。
つまり無駄にハイスペックな環境であることが多いです。
しかし Aurora Serverless にすることで使用していない時はコストが発生しない、使用している時だけコストが発生することでコスト削減が可能になります。
また、開発用のデータベースは週末や夜間は使用されません。
データベースが使用されていない状況では Aurora Serverless は自動的にシャットダウンして使用され始めると起動されることでコスト削減ができます。
拡張モニタリング
- インスタンス上のさまざまなプロセスまたはスレッドが CPU をどのように使用しているかをモニタリングできます。
- 拡張モニタリングメトリクスは Cloudwatch メトリクスではなく CloudWatch ログに保存されます。
- CloudWatch は DB インスタンスのハイパーバイザーから CPU 使用率のメトリクスを収集し、拡張モニタリングはインスタンス上のエージェントからそのメトリクスを収集します。
CloudWath と拡張モニタリングの違い
拡張モニタリングは直接 OS 上で動作しているエージェントから情報を収集しているようです。
そのためより正確にメトリクスを収集できるのではと思います。
- CloudWatch は DB インスタンスのハイパーバイザーから CPU 使用率のメトリクスを収集
- 拡張モニタリングはインスタンス上のエージェントからそのメトリクスを収集
コメント