Amazon RDSとは ― マネージド型RDBの仕組み
RDSは、
Amazon RDSとは、AWSが管理を代わりに行うリレーショナルデータベースサービス
EC2にデータベースソフトを自分で入れると、OSの更新やバックアップまで自分で受け持つことになります。Amazon RDS(Relational Database Service)を使うと、その作業の多くをAWSが代わりに行います。リレーショナルデータベースの管理は、OSのインストールからデータベースソフトの運用まで、利用者からAWSへ移ります。
AWSはRDSをマネージド型データベースサービスと呼びます。利用者は、OSやデータベースソフトの保守に時間を取られず、アプリケーションの開発に時間を使えます。
EC2に自分でデータベースを立てる場合と、RDSを使う場合の違い
データベースをAWS上で動かす方法は、RDSのほかにもあります。Amazon EC2という仮想サーバを借り、その上に自分でデータベースソフトを入れる方法です。この場合、OSとデータベースソフトのインストール・パッチ適用・バックアップは、利用者が自分で行います。AWS公式ガイドは、手動での更新作業がアプリケーションの停止につながる場合があると述べています。
RDSを使う場合は、これらの作業をAWSが代わりに行います。次の図で、担当する作業がどう入れ替わるかを確かめられます。
EC2に自分でDBを立てる:OSからデータベースソフトまで、利用者が自分で用意する
- サーバの保守
- ハードウェアの入れ替え
- 電源・ネットワーク・冷却などの基盤
- OSのインストールとパッチ適用
- データベースソフトのインストールとパッチ適用
- データベースの自動バックアップの仕組み自体を用意すること
- 高可用性(フェイルオーバー)の仕組み自体を用意すること
- スケーリング(性能を上げる・下げる作業)
- SQLクエリのチューニング
RDSを使う:OSからデータベースソフトの運用まで、AWSが管理する
- サーバの保守
- ハードウェアの入れ替え
- 電源・ネットワーク・冷却などの基盤
- OSのインストールとパッチ適用
- データベースソフトのインストールとパッチ適用
- データベースの自動バックアップ
- 高可用性(マルチAZ配置によるフェイルオーバー)
- スケーリング
- SQLクエリのチューニング
次の表は、オンプレミス・EC2・RDSの3パターンを並べたものです。オンプレミスは、自社でサーバを持つ使い方です。性能を上げるためにSQLの問い合わせを調整する作業は、どのパターンでも利用者が担当します。この作業をクエリのチューニングと呼びます。
| 担当する | オンプレミス | EC2に | RDSを |
|---|---|---|---|
| OSのインストール・パッチ適用 | 利用者 | 利用者 | AWS |
| DBソフトのインストール・パッチ適用 | 利用者 | 利用者 | AWS |
| バックアップ | 利用者 | 利用者 | AWS |
| 高可用性(フェイルオーバー) | 利用者 | 利用者 | AWS |
| スケーリング | 利用者 | 利用者 | AWS |
| サーバの保守・ハードウェアの入れ替え | 利用者 | AWS | AWS |
| 電源・ネットワーク・冷却 | 利用者 | AWS | AWS |
| アプリケーションの最適化(クエリのチューニング) | 利用者 | 利用者 | 利用者 |
マスターユーザーは、データベースの管理に使う最初のアカウントです。そのパスワードの管理も、Secrets Managerに任せられます。RDSがパスワードを作ってSecrets Managerに保管し、既定で7日ごとに更新します。
マルチAZ配置とは、別のAZにスタンバイを置く仕組み
マルチAZ配置とは、プライマリのDBインスタンスとは別のAZに、スタンバイのDBインスタンスを置く仕組みです。プライマリは、通常の処理を受け持つインスタンスです。スタンバイは、障害に備えて待機するインスタンスです。AWSが自動でスタンバイを用意し、プライマリの内容を同期でコピーします。
マルチAZ配置には、スタンバイの台数が違う2つの構成があります。スタンバイが1台の構成を、マルチAZ DBインスタンス配置といいます。このスタンバイは、読み取りの問い合わせに使えません。
スタンバイが2台の構成を、マルチAZ DBクラスター配置といいます。2台のスタンバイも読み取りに使えます。以降の説明は、スタンバイが1台の構成を対象にしています。
プライマリのDBインスタンスやそのAZに障害が起きると、スタンバイがプライマリに切り替わります。この切り替えをフェイルオーバーと呼びます。マルチAZ配置には、バックアップ中のI/Oの一時停止や遅延の急増を抑える利点もあります。
次の節で説明するリードレプリカも、プライマリのコピーを別の場所に置く仕組みです。スタンバイが1台のマルチAZ配置とは、コピーの方式と、読み取りに使えるかどうかが違います。
リードレプリカとは、読み取り専用の問い合わせに使えるコピー
リードレプリカとは、プライマリのDBインスタンスを非同期でコピーした、読み取り専用のDBインスタンスです。読み取りの問い合わせだけを別のインスタンスへ振り分けることで、プライマリの負荷を減らせます。スタンバイが1台のマルチAZ配置と比べると、違いは2つです。コピーの方式が同期ではなく非同期であること、読み取りの問い合わせに使えることです。データを別のサーバに複製するレプリケーションの考え方と、同期・非同期の違いは分散データベースの記事にまとめています。
リードレプリカは、障害からの復旧にも使えます。プライマリが使えなくなったとき、利用者の操作でリードレプリカを単独のDBインスタンスに昇格させられます。リードレプリカは、利用者が手動で作ります。需要に応じて台数を自動で増減する仕組みには対応していません。
読み取りの負荷を減らす別の方法として、Amazon ElastiCacheがあります。よく読むデータをメモリに置き、RDSに問い合わせる前に返すサービスです。
自動バックアップとは、設定した期間、毎日自動でバックアップを取る機能
自動バックアップとは、RDSが毎日決まった時間帯に、DBインスタンス全体のスナップショットを取る機能です。この時間帯をバックアップウィンドウと呼びます。個別のデータベースだけではなく、DBインスタンス全体を保存します。
バックアップは、利用者が指定した保持期間だけ保存されます。その期間内であれば、任意の時点の状態にDBインスタンスを復元できます。保持期間は0〜35日で指定し、0日にすると自動バックアップは止まります。
最初のバックアップは、データベース全体を保存します。以降のバックアップは、前回から変わった部分だけを保存します。全体と変わった部分を組み合わせる考え方は、フル・差分・増分バックアップの記事で説明しています。自動バックアップのほかに、利用者が手動でスナップショットを作ることもできます。
RDSが対応するデータベースエンジン
RDSは、複数のデータベースエンジンに対応しています。IBM Db2・MariaDB・Microsoft SQL Server・MySQL・Oracle Database・PostgreSQLの6種類です。
利用者は、使い慣れたデータベースエンジンをそのままRDS上で動かせます。Amazon Auroraは、MySQLやPostgreSQLと互換性を持つ、AWS独自のデータベースエンジンです。AuroraもRDSの一部ですが、RDSのユーザーガイドではなく、Aurora専用のガイドで説明されています。インスタンスが1つのストレージを共有するAuroraの仕組みは、Amazon Auroraの記事で説明しています。
大量の行を集計する分析には、列ごとにデータを保存するAmazon Redshiftを別に用意します。
参考にした資料
- AWS「What is Amazon Relational Database Service (Amazon RDS)?」(RDSの定義、Comparison of responsibilities表、対応エンジン)
- AWS「Configuring and managing a Multi-AZ deployment for Amazon RDS」(マルチAZ配置の構成)
- AWS「Working with DB instance read replicas」(リードレプリカの仕組みと用途)
- AWS「Introduction to backups」(自動バックアップの仕組み)
- AWS「Password management with Amazon RDS and AWS Secrets Manager」(マスターユーザーのパスワードの管理)
練習問題(全4問)
正解:OSの
Amazon RDS User Guideは、
正解:RDSでは
RDS User Guideの
正解:通常時は
RDS User Guideに
正解:プライマリと
RDS User Guideは、
選んでから「採点する」を押すと、解説つきで答え合わせができます。