Amazon RDS(Amazon Relational Database Service) について解説します。
オンプレミスで DB サーバーを設計／構築／運用／障害対応をするのは非常に高度なスキルを必要としますが、クラウド上で利用できるリレーショナルデータベースの「Amazon RDS」の登場によりある意味「何も気にせずに気軽に使える」ようになりました。
Amazon Web Services ガイドブック クラウドでWebサービスを作ろう!
Amazon RDS：クラウド上のリレーショナルデータベース
Amazon RDS(Amazon Relational Database Service)を利用すれば、クラウドでのリレーショナルデータベースのセットアップ、運用、 スケーリングを簡単に行うことができます。
その結果、インフラの設計／構築／運用／障害対応ではなく「開発」に（ほぼ）100% 集中することができます。
Amazon RDS(Relational Database Service)のメリット（長所）
Amazon RDS のメリット（長所）をまとめると以下のようになります。
- セットアップが簡単
- 選択肢が多い（Amazon Aurora、MySQL、PostgreSQL、Oracle、MariaDB、Microsoft SQL Server）
- スケーリングが簡単（ディスク拡張、インスタンスタイプの変更など）
- バックアップ＆スナップショットが簡単、復元も簡単
- 冗長構成、フェイルオーバーも自動的にやってくれる
- 運用コストの大幅な削減が可能
つまり最大限、開発に力を注げるようになります。
逆に言うと今まで当たり前のようにやっていた以下の作業コストが削減できます。
- サーバーの設計、調達、キッティングなどの事前準備
- オペレーティングシステム（OS）のインストール
- DB のインストール
- オペレーティングシステム（OS）やデータベース（DB）パッチの調査、検証とインストール
- サーバーやストレージのアップグレード
- フエイルオーバーの設計、動作検証、設定
- バックアップのスケジューリングとバックアップファイルの管理
Amazon RDS を利用することで、こうした作業工数を削減し、その分を開発に注入することができます。
RDS でも出来ないこと
さすがに後から「ストレージ割り当て」サイズを縮小することはできません。
DB インスタンスタイプをスケールダウンすることはできますが、物理的に確保したサイズを減らすことはできません。
サイズを増やすなら構築後でも簡単に増量することができます。（自動的にサイズを拡張することも可能です）
サービスに連動して DB インスタンスを自動的に作成することも可能
RDS を利用すると必要に応じて（オンデマンドで）DBインスタンスの作成、使用、終了、復元を行なうことができます。
アプリケーションも AWS 上で構築している場合、アプリケーションの自動的なデプロイに応じて DB インスタンスも同時に自動的に構築できます。
つまりアプリケーションと DB インスタンスの構築の工程が完全にリンクして自動化できます。
新しい顧客がサービスにサインアップするたびに、Amazon RDS API の CreateDBInstance を呼び出して新しいDBインスタンスを作成することができます。
月末月初だけ自動的にスケールアップさせることも可能
月末月初のみ請求書の処理でリソースが必要になるシステムがあるとします。
それ以外の期間はほとんど利用されていません。
かと言って DB インスタンスを停止するとたまにアクセスするユーザー利用できなくなります。
つまり、1ヶ月のうち約 6.6% だけそこそこのリソースが必要となり、それ以外の約 93.3% は低スペックでも問題ありません。
- 1ヶ月 ： 30日×24時間 ＝ 720時間 （100%）
- 月末月初 ： 2日×24時間 ＝ 48時間 （6.666%）
- それ以外 ： 28日×24時間 ＝ 672時間 （93.333%）
こんな時でも Amazon RDS を利用すれば、1ヶ月の約 93.3% は平均的な性能のシステムでデータベースを運用し、月に2日間だけ請求書の処理をサポートするためにスケールアップし、その後は元の状態にスケールダウンすることが可能となります。
ユーザーのニーズに合わせて、毎日、毎週、または四半期ごとに行うことができます。
RDS の構成
Amazon RDS のサービスは DB インスタンスを中心に行われます。
DB インスタンスは
- シングル AZ 配置
- Multi-AZ 配置
で構築できます。
AZ は Availability Zone（アベイラビリティゾーン）の略で、AWS は 1つの AZ での障害が他の AZ に影響を与えないように設計されています。
Multi-AZ 構成の DB インスタンスは、複数のアベイラビリティゾーン間でデータをレプリケートし、障害発生時に自動的にフェイルオーバーします。
そのため高可用性と持続性を実現できます。
DB インスタンスを作成する際に DB インスタンスクラスを指定します。
2018年5月現在、以下の DB インスタンスのクラスがあります。
DB インスタンスクラスの変更は数分で可能です。
そのため、設計にはそこまで時間を掛ける必要がなく、とりあえず構築をして検証をしてデータを集めた方が最終的に的確な RDS を構築することができます。
「シングル AZ 配置」と「マルチ AZ 配置」は約 2 倍料金が異なる
2018年5月現在ですが、「シングル AZ 配置」と「マルチ AZ 配置」では料金が約 2 倍くらい異なります。
■シングル ZA 配置
■マルチ AZ 配置
※上記は DB インスタンスを起動している場合の「時間当たりの料金」になります。
DB インスタンスのストレージサイズについて
DB インスタンスのストレージサイズは固定されていません。
DB インスタンスのエンジンタイプによりデフォルトのストレージサイズが決まります。
ストレージのサイズは、DB インスタンスの「ストレージ割り当て」と呼ばれます。
「ストレージ割り当て」はオンライン中（リアルタイム）に増やしたとしても、ダウンタイムは発生しません。
Oracle の場合はストレージタイプを選択できる
RDS のエンジンに「Oracle」を選択した場合、「ストレージタイプ」を以下の2つから選択することができます。
- 汎用 (SSD)
- プロビジョンド IOPS (SSD)
「汎用 (SSD)」と「プロビジョンド IOPS (SSD)」の違い
- 汎用（SSD） ← ボリュームのサイズによりパフォーマンスが決まる
- プロビジョンド IOPS（SSD） ← データベースのような大量アクセスがあり I/O のスループットが求められる環境に適している
ストレージエンジン
MySQL では「InnoDB」や「MyISAM」といったストレージエンジンのことを「エンジン」と言います。
MySQL インスタンスの各テーブルは特定のストレージエンジンを使います。
今まで様々な環境で MySQL を利用してきましたが、ほとんどが「InnoDB」を利用していました。（逆に「MyISAM」を利用している現場はほとんどなかったと思います）
その理由としては「InnoDB」が信頼性のあるバックアップをサポートしていることが挙げられます。（2018年5月現在）
「InnoDB」は「MyISAM」より運用管理がやりやすいということが挙げられます。
DB インスタンスのステータス（状態）
DB インスタンスは常に特定の状態にあります。
主なステータスは以下の5つです。
- creating
- backing-up
- available
- modifying
- deleting
ほとんどの時間は「available」であり、他の状態は一時的です。
2018年5月現在では下図のように24種類のステータスがあります。
DB インスタンスへのアクセス許可
アプリケーションプログラム（Webサーバーなど）は、DB インスタンスとネットワーク接続を確立できなければいけません。
そのために「DB セキュリティグループ」を「DB インスタンス」に関連付る必要があります。
EC2 インスタンスが所属している特定のネットワークアドレスから DB インスタンスへのアクセス（インバウンド）を許可します。
DB インスタンスへのアクセス許可の設定が完了したら、「DB インスタンス」の「エンドポイント」を使って接続します。
DB インスタンスの DB パラメータグループ
Amazon RDS では、「DB パラメータグループ」を利用してデータベースエンジン全体のパフォーマンスに影響を与えるパラメータの管理ができます。
DB パラメータグループにはデータベースエンジン固有の設定変数のリストが含まれています。
計算式で動的にパラメータを設定することもできる
例えば MySQL の DB パラメータグループには以下のパラメータがあります。
- innodb_buffer_pool_size
- innodb_buffer_pool_load_now
- innodb_buffer_pool_load_at_startup
これらは絶対値で指定されるか、式を使って指定されます。
たとえば、innodb_buffer_pool_size は {DBInstanceClassMemory*3/4} という式で指定されます。
式で設定するパラメータの場合は、パラメータの値がインスタンスクラスの設定に基づいて調整されるようになるため、DB パラメータグループをすべての DB インスタンスクラスに適用することが可能となります。
デフォルトの DB パラメータグループがある
もし特定の DB パラメータグループにパラメータ値が設定されていない場合は、データベースエンジン固有のデフオルト値が使われます。
初期構築段階ではデフォルトの DB パラメータグループが含まれているので、パラメータを変更する必要がないうちはデフォルトの「DB パラメータグループ」を使用することもできます。
DB パラメータグループ変更を適用するタイミングを選べる
DB パラメータグループを変更する際には、変更を適用するタイミングを以下の2つから選択することもできます。
- パラメータの変更を直ちに適用する
- DB インスタンスを次回再起動するときに適用する
新規 DB インスタンスを作成する際はマスタユーザーの作成が必要
新規 DB インスタンスを作成する際には、
- マスターユーザーの名前
- パスワード
を指定する必要があります。
構築後の最初のデータベースへの接続には、このアカウントを使います。
例えば MySQL の場合は、このマスターユーザーアカウントには以下の権限が割り当てられます。
- SELECT
- INSERT
- UPDATE
- DELETE
- CREATE
- DROP
- RELOAD
- PROCESS
- REFERENCES
- INDEX
- ALTER
- SHOW DATABASES
- CREATE TEMPORARY TABLES
- LOCK TABLES
- EXECUTE
- CREATE VIEW
- SHOW VIEW
- CREATE ROUTINE
- ALTER ROUTINE
- CREATE USER
- EVENTS TRIGGER
また、マスターユーザーには GRANT 権限も割り当てられるため、DB インスタンスの起動後に別途「CREATE USER」でユーザーアカウントを作成してアクセス権を割り当てることができます。
DB インスタンス作成時に DB 名を指定する
新規 DB インスタンスを作成する際に、データベース名を指定できます。
DB インスタンスにその DB 名が付いた空のデータベースが作成されます。
メンテナンスウィンドウの設定ができる
DB インスタンスには、メンテナンスウィンドウ（メンテナンスの時間枠）を設定できます。
メンテナンスウィンドウにより、以下のメンテナンス作業のタイミングを柔軟に制御できる。
- DB インスタンスを変更する（別の DB インスタンスクラスへのスケーリングなど）
- ソフトウェアパッチを適用する
メンテナンスイベントを特定の週にスケジュールされた場合は、メンテナンスの開始から終了までが、指定された時間の枠内で実施されます。
Amazon RDS はまだ適用していないパッチやパラメータの更新をその時間の間に実施します。
デフォルトでは、ウィンドウは各 AWS リージョンの「静かな」時間帯に設定されます。
特定のアプリケーションにとってもっと最適な時間帯、すなわち影響を受けるユーザーの数が最も少ない時間帯がわかっている場合は、ウィンドウを週のその時間帯に設定します。
DB インスタンスをオフラインにする必要があるメンテナンスイベントは「必須のソフトウェアパッチの適用」などです。
パッチの適用がスケジューリングされるのは、そのパッチがセキュリティや運用に重大な影響をおよぼす場合に限られます。
そうしたパッチはたまに（通常は数か月にー度）しか発生しないので、メンテナンスウィンドウの時間がそれほど取られることはありません。
Amazon RDS のバックアップが自動的に行われるので簡単
Amazon RDS API により、DB インスタンスのバックアップも簡単になります。
Amazon RDS は、DB インスタンスのバックアップウィンドウの枠内で、毎日自動的にバックアップします。
バックアップファイルは DB インスタンスのバックアップ保管期間で指定された日数だけ保存されます。
2018年5月現在では最長が「35日間」です。
また、DBスナップショットはいつでも作成することができ、削除するまで保存される。
DB スナップショットについて
DB スナップショットにはそれぞれ一意な名前を割り当てます。
Amazon RDS はデータベースごとに変更ログも記録します。
そのため、バックアップ保管期間内であれば、DB インスタンスの復元可能な最新時刻よりも前の任意の時点の状態にデータベースを戻すことができます。
DB インスタンスの復元可能な最新時刻は、現在の時刻から5分以内です。
Amazon RDS の監視
Amazon RDS は、以下の 4 つのソースに関するイベントを追跡します。
- DB インスタンス
- DB スナップショット
- DB セキュリティグループ
- DB パラメータグループ
各イベントには以下の情報が含まれます。
- 日付と時刻
- ソースのタイプ
- ソース名
各DBインスタンスは、Cloud Watch に以下のメトリックを報告する。
- CPU利用率
- 空きストレージ
- DB接続の数
- 1秒あたりの読み取り操作の数
- 1秒あたりの書き込み操作の数
- 読み取り遅延
- 書き込み遅延
- 読み取りスループット
- 書き込みスループット
上記メトリックに基づいて DB インスタンスのパフォーマンスを追跡できます。
CPU 利用率を監視して、より大きいまたは小さい DB インスタンスクラスへのスケーリングを行うための判断基準にすることができます。
また、空きストレージを監視して、DB インスタンスの 1 つに追加のストレージを割り当てることもできます。
Amazon RDS はプログラマブル（プログラムで指示を与えることができる）
Amazon RDS だけでなく AWS 全体の特徴ですが、RDS も API を通じてアクセスでき、コマンドラインや AWS Management Console を使って RDS にアクセスし操作することができます。
- CreateDBInstance 関数 ← 新しい DB インスタンスを作成する
DB インスタンスを操作する関数としては、以下があります。
- DescribeDBInstances
- ModifyDBInstance
- RebootDBInstance
- DeleteDBInstance
DB スナップショットの作成や操作に使われる関数としては、以下があります。
- CreateDBSnapshot
- DescribeDBSnapshots
- DeleteDBSnapshot
- RestoreDBInstanceFromDBSnapshot
- RestoreDBInstanceToPointInTime
DB パラメータグループを操作する関数tとしては、以下があります。
- CreateDBParameterGroup
- DeleteDBParameterGroup
- DescribeEngineDefaultParameters
- ModifyDBParaxneterGroup
DB セキュリティグループを操作する関数としては、以下があります。
- CreateDBSecurityGroup
- DescribeDBSecurityGroups
- DeleteDBSecurityGroup
- AuthorizeDBSecurityGroupIngress
- RevokeDBSecurityGroupingress
Amazon RDS の料金
Amazon RDS を利用するにあたっては以下の 5 つの次元で料金が発生します。
- DB インスタンス時間
- プロビジョニングされたストレージ
- ストレージ IO
- バックアップストレージ
- データ転送
DB インスタンス時間
Single AZ 配置 DB インスタンスの 1 時間あたりの料金は、Multi AZ 配置 DB インスタンスの 1 時間あたりの料金の 2 倍です。
この料金には
- プライマリ DB インスタンス
- スタンバイ DB インスタンス
の両方の料金が含まれています。
（そのため、1台あたりに換算すると同じ価格になります）
DB インスタンスを作成したときから終了するまで、1 時間ごとに料金が発生します。
これは Amazon SimpleDB の料金体系とは異なります。
DB インスタンスのクラスは数分で変更できるので、必要に応じていくらでもスケールアップとスケールダウンを行っても問題ありません。
むしろコスト面から言えば積極的に「スケールアップ」や「スケールダウン」を行なうべきです。
プロビジョニングされたストレージ
DB インスタンスに関連付けられた「プロビジョニング済みのストレージ」は、Single AZ 配置 DB インスタンスの場合、たとえ使わなくてもプロビジョニングした分の料金がかかります。
しかし追加のストレージをプロビジョニングするのは簡単（かつ迅速）なので、プロビジョニングをあらかじめ多めに行っておく必要はありません。
ストレージ I/O
DB インスタンスに対して「プロビジョニングされたストレージ」への I/O について料金がかかります。
この金額は実際の使用量に基づいて計算されます。
Multi AZ 配置 DB インスタンスはデータの書き込み時に同期的なレプリケーションを行うため、Single AZ 配置 DB インスタンスの 2 倍のリクエストになります。
バックアップストレージ
バックアップストレージは、以下のバックアップに使われます。
- スケジュールによる毎日の自動バックアップ
- ユーザーが手動で取得するスナップショットバックアップ
データ転送
計算が若干複雑です。
同じリージョン内の異なるアベイラビリティゾーンにある「EC2 インスタンス」と「DB インスタンス」の間でデータをやり取りする場合は、EC2 側でのデータ転送のみ有料になります。
Multi AZ 配置によるゾーン間のデータ転送は無料になります。
同じアベイラビリティゾーンにある「EC2インスタンス」と「DB インスタンス」間でのデータ転送は無料になります。
大雑把な RDS 料金計算方法
大雑把な計算としては「DB インスタンス時間」での計算が中心となると思います。
例えば「db.r4.large」インスタンスタイプを例に挙げると、1時間当たりの料金が「0.5704USD」であることが分かります。
この RDS を 1ヶ月利用した場合、
1時間 0.5704 USD × 24時間 × 30日 ＝ 410.688 USD/月
になります。
更に現在（2018年7月21日）の米ドル/円のレートで計算すると
410.688 × 111.39 ＝ 45,746円
になります。
単純にスペックが2倍になると料金も2倍になる
RDS の料金表をチェックすると「単純にスペックが 2倍になると料金も 2倍になる」ことが分かります。
RDS の注意点（インスタンスを停止しても7日後に自動的に起動して課金されるので注意）
RDS の注意点ですが、RDS DB インスタンスを停止しても、7日間後に自動的に起動するで注意しましょう。
以下の記事を参考にしてください。
【AWS】RDS(Amazon Relational Database Service)はインスタンスを停止しても7日間後(8日後)に自動的に起動するので注意【料金が発生する】
参考にした本
AWS エバンジェリストの Jeff Barr 氏著作の AWS ガイドブックです。業務で AWS を利用していますが、AWS の公式サイトのマニュアルでは理解が難しい部分を分かりやすく解説をしてくれています。（AWS 公式サイトのマニュアルは分かりにくい）
AWS は日々新しいサービスがリリースされてるので、基本的には AWS の公式サイトのマニュアルを確認しなければいけませんが、補完する垣外ブックとして手元に置いておきたい本です。
Amazon Web Services ガイドブック クラウドでWebサービスを作ろう!
コメント