Amazon RDSとは

　Amazon Relational Database Service （以下、RDS）はリレーショナルデータベースを提供するサービスです。

　オペレーティングシステムやデータベースエンジンの管理はAWS側で行われ、利用者は数分でデータベースを起動してアクセスできます。Amazon EC2（EC2）同様、従量課金となっており、RDSインスタンスが起動している時間に対して利用料が発生します。

　現時点でRDSでは次の6つのデータベースエンジンをサポートしています。


　上記の内、Amazon Auroraは、クラウド向けにAWSが構築したデータベースです。MySQLおよびPostgreSQLと互換性があります。

　ほかのデータベースエンジンと比べて異なる部分が多いため、まずはAmazon Aurora以外のデータベースエンジンにおけるRDSの特徴を紹介し、後ほど（2ページ目で）Amazon Auroraの特徴を紹介します。

RDSの作成方法

　RDSを使うと、AWSマネジメントコンソール（GUI）またはAPIを使用してコマンドやプログラム経由で作成が可能です。

　マネジメントコンソールから作成する場合は、画面から以下の項目を指定することでRDSインスタンス（サーバ）が作成され起動します。


　このほかにもいくつか設定可能な項目がありますが、最低限これらの設定をしておけば作成が可能です。起動後、設定したマスターユーザー名とパスワードでデータベースへ接続ができるようになります。

　たとえば、データベースエンジンがMySQLの場合は次のコマンドでデータベースに接続できます。

mysql -h mysql instance1.123456789012.ap-northeast-1.rds.amazonaws.com -P 3306 -u masteruser -p

Amazon RDSの6つの特徴

　RDSの代表的な特徴を見ていきます。

●RDSインスタンスタイプ
　EC2と同じく、インスタンスのスペック（CPU、メモリ）は、インスタンスタイプを選択することにより決定します。インスタンスタイプのネーミングは次のようになっています。


　最初が「db」固定になっている以外は、EC2と同様のネーミングルールになっています。利用料は従量課金となっており、時間あたりの単価はインスタンスタイプにより異なります。高スペックなインスタンスタイプほど高料金となります。

　利用予定のインスタンス使用量を決定して先払いする方式である、リザーブドインスタンスにも対応しています。EC2で紹介したSavings Plansやスポットインスタンスは、現時点でRDSには対応していません。

●マルチAZ配置、スタンバイレプリカ
　RDSでは、メインとなるプライマリインスタンスのほかに、スタンバイレプリカを別のAZ（アベイラビリティーゾーン）に配置することでマルチAZな高可用性を実現できます。


　データの同期がプライマリインスタンスからスタンバイレプリカに行われており、プライマリインスタンスやAZに障害があった場合、スタンバイレプリカにフェイルオーバー（切り替え）することでDB接続を継続できます。

　アプリケーションからRDSへ接続する際はエンドポイントというDNS形式の接続情報を使用します。プライマリインスタンスに障害が発生した場合、このエンドポイントの向き先が自動的にスタンバイレプリカに切り替えられます。


　スタンバイレプリカは可用性向上が目的であり、性能向上が目的ではありません。読み取り性能を向上したい場合は、次に説明するリードレプリカを使用します。

●リードレプリカ
　リードレプリカは読み込み専用として利用できるプライマリインスタンスから複製されたインスタンスです。読み込み処理について、スケールアウトでパフォーマンスが向上できます。あくまで読み込み専用のため、書き込み性能についてはリードレプリカで向上できません。書き込み性能については、インスタンスサイズを変更してスケールアップさせることによりパフォーマンスを向上させます。


●VPCによるネットワーク制御
　RDSインスタンスは、AWS上に作成したネットワークであるAmazon Virtual Private Cloud (以下、VPC) 上で起動します。VPCの詳細については以前の記事をご確認ください。起動には少なくとも2つのサブネットが必要です。VPCのアクセス制御で使用するセキュリティグループやネットワークACLを使用してRDSへのアクセス制御を行えます。

●バックアップ
　RDSには自動バックアップ機能があり、これを有効にすることで利用者が指定した日数分のスナップショットが自動保持されます。保持日数は0～35の範囲で指定が可能で、0の場合は自動バックアップが無効となります。初回のスナップショットは、すべてのデータをバックアップしますが、2回目以降のスナップショットは差分（変更された）データのみ取得します。

　スナップショットの取得処理は、利用者が指定したバックアップウィンドウの時間帯で実行されます。

　シングルAZ配置の場合、バックアップ開始時に一時的にI/Oの中断が発生する可能性があります。マルチAZ配置の場合、バックアップはスタンバイインスタンスから取得されるため、I/Oの中断は発生しません（ただしSQL Serverを除く）。

　スナップショットのファイルはAmazon S3（以下、S3）上に格納されるため、ファイルの耐久性は非常に高いです。S3に保存されますが、利用者側からS3バケットのファイルとして見えるわけではありません。仕組み上、S3が使用されているとご理解ください。


　取得したスナップショットは、新しいDBインスタンスを作成するという形で復元でき、既存のDBインスタンスへは復元できないため注意が必要です。

　スナップショットは日次で取得されますが、それとは別にトランザクションログがS3に5分単位で保存されています。ポイントインタイムリカバリという機能を使用して、特定の時間（最短で5分前、保持期間内）を指定して復元できます。スナップショット同様、既存のDBインスタンスではなく新規インスタンスとして復旧することになります。

●メンテナンスウィンドウ
　OSやデータベースエンジンのバージョン更新、パッチ適用はAWS側で実施されますが、更新作業はメンテナンスウィンドウという利用者側が設定した時間帯に実施されます。いくつかのメンテナンス作業では、DBインスタンスが一時的にオフライン（利用不可）となります。そのため、DBの使用率が最も低い時間帯を設定すると良いでしょう。

　マルチAZ配置にしていた場合、スタンバイレプリカ→プライマリインスタンスと順にメンテナンスが実行されます。DBアクセスのないインスタンスをメンテナンスするため、DBがオフラインとなる影響を軽減できます。ただし、データベースエンジンのアップグレードはプライマリおよびスタンバイレプリカが両方同時にアップグレードされます。

【次ページ】RDSの責任範囲とSLA、DBエンジン「Amazon Aurora」の詳細説明