Q: Amazon RDS とは何ですか?

Amazon Relational Database Service(Amazon RDS)は、クラウドでのリレーショナルデータベースのセットアップ、運用、およびスケーリングを容易に行えるようにするマネージドサービスです。これにより、時間のかかるデータベース管理作業をお客様の代わりに実行して、お客様を管理業務から解放し、アプリケーションとビジネスに集中させることができます。このサービスはコスト効率もよく、データベース容量の変更にも柔軟に対応します。

Amazon RDS では、使いなれた MySQL、MariaDB、Oracle、SQL Server、または PostgreSQL データベースの機能を引き続き利用できます。つまり、既存のデータベースで現在すでに使用しているコード、アプリケーション、およびツールは、Amazon RDS でシームレスに機能します。Amazon RDS は、データベース ソフトウェアに自動的にパッチを当て、データベースをバックアップし、ユーザーが定義した保持期間バックアップを格納します。1回の API 呼び出しまたは AWS マネジメントコンソールの数回のクリックで、お客様の関係データベースに関連する計算リソースまたはストレージ能力を拡張することができ、この柔軟性から恩恵を受けることができます。さらに、Amazon RDS は、簡単にレプリケーションを使って、データベースの可用性を強化、データの耐久性を改善、ひとつのデータベースインスタンスの容量制限を拡張して読み込み付加を軽減することができるようにします。アマゾン ウェブ サービスのすべてのサービスと同様に、初期投資が不要であり、お支払いいただくのは使用したリソースの分のみです。

Q: データベースインスタンス (DB インスタンス) とは何ですか?

DB インスタンスを、お客様が指定したコンピュートおよびストレージリソースを備えた、クラウド内のデータベース環境であると考えることができます。お客様は、DB インスタンスの作成と削除ができ、DB インスタンスのインフラストラクチャ属性を定義/改良でき、AWS マネジメントコンソール、Amazon RDS API およびコマンド ライン ツールを通じてアクセスとセキュリティをコントロールできます。1 つ以上の DB インスタンスを実行でき、各 DB インスタンスは、1 つ以上のデータベースまたはデータベーススキーマをサポートできます(エンジンタイプによる)。

Q: Amazon RDS は私のために何を管理しますか?

Amazon RDS は、お客様が要求するインフラストラクチャ容量の準備からデータベースソフトウェアのインストールまで、リレーショナルデータベースのセットアップに関係する作業を管理します。お客様のデータベースがそれ自身の DB インスタンス上で動作を始めると、Amazon RDS によって、バックアップの実行やお客様の DB インスタンスを駆動するデータベースソフトウェアのパッチ適用などの一般的な管理作業は自動化されます。オプションの Multi-AZ 配備として、Amazon RDS はまた、Availability Zone全体への同期的データ複製と、自動フェイルオーバーを管理します。

Amazon RDS ではネイティブのデータベースアクセスが提供されるので、お客様は通常の場合と同様にリレーショナルデータベースソフトウェアを操作できます。つまり、お客様はお客様のアプリケーションに特有なデータベース設定の管理にまだ責任があります。お客様は、お客様のユースケースに最適なリレーショナルスキーマを構築する必要があり、アプリケーションのワークフローに対してデータベースを最適化するための、性能調整に責任があります。

Q: Amazon RDS、Amazon EC2 Relational Database AMI、Amazon DynamoDB をいつ使用しますか?

アマゾン ウェブ サービスでは、データベースに関して多数の選択肢があります。Amazon RDS では、リレーショナルデータベースのすべての機能を利用できるだけでなく、データベース管理作業を軽減できます。Amazon DynamoDB は完全マネージド型の NoSQL データベースサービスであり、高速で予測可能なパフォーマンスとシームレスな拡張性が特徴です。さらに、Amazon EC2 上で利用できる多数のリレーショナルデータベース AMI があり、お客様自身のリレーショナルデータベースをクラウド内で運用できます。これらの選択肢の間には大きな違いがあるため、実際のユースケースに応じて最適なものを選ぶときは、この違いを考慮する必要があります。どのソリューションがお客様にとってベストであるかに関する追加説明は、AWS でのデータベースの実行をご覧ください。

Q: Amazon RDS を開始するにはどうすればよいですか?

Amazon RDS にサインアップするには、アマゾン ウェブ サービスアカウントを持っている必要があります。まだ持っていない場合は、アカウントを作成してください。サインアップした後、Amazon RDS 資料をご覧ください。入門ガイドが含まれています。

AWS Management Console または Amazon RDS API を使用すると、DB インスタンスを分単位で起動できます。

Q: DB インスタンスはどのように作成しますか?

DB インスタンスは、AWS Management ConsoleAmazon RDS API、またはコマンドラインツールを使用して、簡単に作成できます。AWS マネジメントコンソールを使用して DB インスタンスを起動するには、[Amazon RDS] タブにある [RDS] をクリックし、次に [Launch DB Instance] ボタンをクリックします。ここでは、次のように DB インスタンスの基礎的なパラメータを指定できます。

  • DB エンジン: Amazon Aurora、MariaDB、MySQL、Oracle、Microsoft SQL Server、PostgreSQL
  • DB エンジンのバージョン(オプション)
  • ライセンスモデル(オプション)
  • DB インスタンスタイプ
  • 割り当てストレージサイズ(GB 単位)
  • DB インスタンスをマルチ AZ 配置として実行するかどうか
  • ストレージタイプ
  • DB インスタンス識別子
  • マスターユーザー名
  • マスターユーザーパスワード

お客様のDBインスタンスのバックアップ保持ポリシー都合のよいバックアップウィンドウ、および予定メンテナンスウィンドウを変更することも可能です。代わりに、CreateDBInstance API または rds-create-db-instance コマンドを使用して、DB インスタンスを作成することもできます。

Q: 自分が実行中の DB インスタンスにはどのようにアクセスしますか?

一旦お客様の DB インスタンスが利用可能になったら、AWS マネジメントコンソールまたは DescribeDBInstance API の DB インスタンスの説明を使用して、そのエンドポイントを取得できます。このエンドポイントを使用して、使い慣れたデータベース ツールまたはプログラミング言語により、DB インスタンスに直接接続するために必要な接続ストリングを作成することができます。お客様の実行中の DB インスタンスに対するネットワーク リクエストを許可するため、アクセスを認可する必要があります。接続ストリングの作成方法および開始方法についての詳細は、当社の入門ガイドをご覧ください。

Q: Amazon RDS でいくつの DB インスタンスを実行できますか?

デフォルトでは、Amazon RDS DB インスタンスを合計 40 個まで保有できます。この 40 インスタンスのうち、最大 10 インスタンスまでは「ライセンス込み」モデルの Oracle または SQL Server DB インスタンスとすることができます。40 個のインスタンスすべては、"BYOL" モデルで Amazon Aurora、MySQL、MariaDB、Oracle、SQL Server、または PostgreSQL に使用できます。アプリケーションにこれ以上の DB インスタンスが必要である場合、こちらの申請フォームで追加の DB インスタンスをリクエストできます。

Q: 1 つの DB インスタンスで何個のデータベースまたはデータベーススキーマを実行できますか?

  • RDS for Amazon Aurora: ソフトウェアによる制限はありません
  • RDS for MySQL: ソフトウェアによる制限はありません
  • RDS for MariaDB: ソフトウェアによる制限はありません
  • RDS for Oracle: インスタンスあたり 1 個のデータベース。データベースあたりのスキーマの数については、ソフトウェアによる制限はありません
  • RDS for SQL Server: インスタンスあたり 30 個のデータベース
  • RDS for PostgreSQL: ソフトウェアによる制限はありません

Q: Amazon RDS にデータをどのようにインポートしますか?

データを簡単に Amazon RDS にインポートする方法は多数あります。例えば、mysqldump または mysqlimport ユーティリティ(MySQL の場合)、Data Pump、Import/Export または SQL Loader(Oracle の場合)、インポート/エクスポートウィザードまたは一括コピープログラム(BCP)(SQL Server の場合)、pg_dump(PostgreSQL の場合)です。データのインポートとエクスポートの詳細については、MySQL のデータインポートガイドOracle のデータインポートガイドSQL Server のデータインポートガイド、または PostgreSQL のデータインポートガイドをご覧ください。

Q: Amazon RDS はどのリレーショナルデータベースエンジンをサポートしていますか?

Amazon RDS は Amazon Aurora、MySQL、MariaDB、Oracle、SQL Server、および PostgreSQL データベースエンジンをサポートしています。

Amazon RDS for MySQL は現在、InnoDB をデフォルトのデータベースストレージエンジンとして使用している MySQL 5.5、5.6、5.7 (Community Edition) をサポートしています。Amazon RDS for MariaDB は現在、MariaDB 10.0 および 10.1 をサポートしています。Amazon RDS for Oracle は現在、Oracle Database 11gR2 と 12c をサポートしています。 Amazon RDS for SQL Server は現在 2008 R2、SQL Server 2012 (SP2)、SQL Server 2014 をサポートしています。Amazon RDS for PostgreSQL は現在 PostgreSQL 9.3、9.4 および 9.5 をサポートしています。

MySQL を使用している場合は、DB Engine の MySQL マイナーバージョンへのオプションのコントロールとして、Amazon RDS MySQL DB Engine Version Management を使用することができます。

Oracle を使用している場合は、DB インスタンスのパッチレベルへのオプションのコントロールとして、Amazon RDS Oracle DB Engine Version Management を使用することができます。

SQL Server を使用する場合は、Amazon RDS SQL Server DB Engine Version Management を使用して DB インスタンスのパッチレベルを制御することができます。

Q: メンテナンスウィンドウとは何ですか?ソフトウェアメンテナンス中にも DB インスタンスを使用できますか?

リクエストされた、または必要なイベントにおいて、DB インスタンスの修正(DB インスタンスクラスの拡張など)やソフトウェアのパッチが発生する場合、コントロールを行う機会として、Amazon RDS メンテナンスウィンドウを利用できます。「メンテナンス」イベントが特定の週に予定されている場合、お客様が識別するメンテナンスウィンドウ中の一定の時点で、開始されて完了します。メンテナンスウィンドウは、30 分間です。

お客様のDBインスタンスをオフラインにする Amazon RDS を必要とする唯一のメンテナンスイベントは、スケール計算オペレーション(これは通常開始から終了まで数分のみを要します)。または要求されたソフトウェアパッチです。 安全性と堅牢性に関連するパッチに関してのみ、必須のパッチ適用が自動的にスケジューリングされます。このようなパッチは頻繁に発生するものではありません(通常数ヵ月ごとに一度です)。またお客様のメンテナンスウィンドウのごく一部以外を使用する必要があることは稀なはずです。DB インスタンスの作成時点で、希望する週間メンテナンスウィンドウが指定されていない場合は、30分のデフォルト値が割り当てられます。メンテナンスがお客様のために実行される際に修正を行いたい場合、AWS マネジメントコンソールで DB インスタンスを修正する、または ModifyDBInstance API を使用することでそれを行うことができます。お客様の各 DB インスタンスは、個々に異なるメンテナンス ウィンドウを選択することができます。

DB インスタンスをマルチ AZ 配置として実行すると、Amazon RDS は次のようにアクティビティを実行するので、メンテナンスイベントの影響をさらに軽減できます。

  1. スタンバイインスタンスでメンテナンスを実行する
  2. スタンバイを新しいプライマリに昇格する
  3. 旧プライマリでメンテナンスを実行し、その旧プライマリが新しいスタンバイになる

メンテナンスウィンドウを指定するための API またはコマンドラインインターフェイスの使用に関する詳細については、Amazon RDS 開発者ガイドをご覧ください。Multi-AZ モード配備についての詳細は、ここをクリックしてください。

Q: Amazon RDS は、新しいデータベースエンジンバージョンのサポートおよび/または現在サポートされているデータベースエンジンバージョンの廃止に関するガイドラインを提供しますか?

この説明は、Amazon RDS for Amazon Aurora、MySQL、MariaDB、Oracle、SQL Server、および PostgreSQL に適用されます。

今後、Amazon RDS のエンジンに対してさらに多くのデータベースバージョン、マイナーとメジャーの両方のサポートを計画しています。毎年サポートされる新しいバージョンリリースの数は、エンジンのベンダーやコアチームからのリリースやパッチの頻度とコンテンツ、および当社のデータベース技術チームのリリースおよびパッチの診断結果により異なります。ただし、一般的なガイダンスとして、当社では、一般公開の 3~5 か月以内に新しいエンジンバージョンをサポートできるよう取り組んでいます。

Amazon RDS の廃止のポリシーについての一般的な説明は以下の通りです。

  • メジャーバージョンリリース(MySQL 5.6 など)に対しては、Amazon RDS によるサポートが開始されてから、少なくとも 3 年間のサポートを予定しています。
  • マイナーバージョンリリース(MySQL 5.6.21 など)に対しては、Amazon RDS によるサポートが開始されてから、少なくとも1年間のサポートを予定しています。
  • 場合によっては、メジャー/マイナーバージョンを廃止することがあります。廃止の発表後、ユーザーがサポート対象バージョンにアップグレードするための猶予期間を 3 か月間設けます。この猶予期間の終了時の定期メンテナンス中に、アップグレードされていないインスタンスには自動アップグレードが適用されます。
  • これらのガイドラインを満たすための作業が行われていますが、特定のメジャーバージョンまたはマイナーバージョンにセキュリティの問題がある場合には、予定より早く廃止する可能性があります。

Q: クエリが遅いと思われる場合、どうするべきですか?

MySQL を使用している場合は、データベース用の MySQL スロー クエリ ログにアクセスして、実行速度の遅い SQL クエリが存在しているかどうかを判断し、存在している場合には各クエリの性能特性を判断します。「slow_query_log」DB パラメータを設定し、mysql.slow_log テーブルをクエリして、実行速度の遅い SQL クエリを確認することができます。詳細については、『Amazon RDS User Guide』をご覧ください。

Oracle を使用している場合は、Oracle トレースファイルデータを使用して、実行速度の遅いクエリを特定することができます。トレースファイルデータへのアクセスの詳細については、Amazon RDS ユーザーガイドをご参照ください。

SQL Server を使用する場合は、クライアント側 SQL Server トレースを使用して、実行に時間がかかるクエリを特定することができます。サーバー側トレースファイルデータへのアクセス方法については、Amazon RDS User Guideをご覧ください。

Amazon CloudWatchを通じて DB インスタンス用の CPU 利用メトリックスを確認したい場合もあります。ハイレベルの CPU 利用はクエリ性能を低下させる場合があり、その場合には DB インスタンス クラスの拡張を考慮したい場合があります。CPU 利用の監視に関する詳細については、Amazon RDS 監視ガイドをご覧ください。

Q: 各 RDS データベースエンジンの料金が異なる理由を教えてください。

RDS の各データベースエンジンの料金が異なるのは、それぞれにかかるコストが異なるからです。これらのコストにはソフトウェアライセンス以外の多数の運用コンポーネントが含まれます。これまで多くの値下げを行ってきたことからわかるように、AWS ではコストを削減して、その分をお客様に還元できるよう努めています。今後 PostgreSQL などの新しいエンジンについても同様に対応していきます。

Q: Amazon RDS の使用に対してどのように課金、請求されますか?

使用料金は従量課金制となっており、最低料金やセットアップ料金はありません。以下の内容に基づき、請求が行われます。

  • DB インスタンス時間 – 消費された DB インスタンスのクラス(例: スタンダードスモール、ラージ、エクストララージなど)に基づいています。1 時間に満たない DB インスタンスの利用は、1 時間として請求されます。
  • ストレージ(/GB /月)– DB インスタンスに対して準備したストレージ容量。準備したストレージ容量を当月以内に拡張した場合、請求は比例配分されます。
  • I/O リクエスト/月 – ストレージ I/O リクエストの合計(Amazon RDS Magnetic ストレージのみ)
  • プロビジョンド IOPS/月 – 消費 IOPS とは無関係な、プロビジョンド IOPS レート(Amazon RDS プロビジョンド IOPS(SSD)ストレージのみ)
  • バックアップ ストレージ – バックアップ ストレージは、お客様の自動データベース バックアップおよびお客様が取得した アクティブなデータベース スナップショットに関連するストレージです。バックアップ保持期間を増やしたり、追加のデータベーススナップショットを取得したりすれば、お客様のデータベースが使用するバックアップストレージは増大します。Amazon RDS は、お客様が準備したデータベース ストレージの100%まで追加料金なしでバックアップ ストレージを提供します。例えば、10GB・月のデータベース ストレージが準備されていると、当社は追加料金なしで最大 10GB・月のバックアップ ストレージを提供します。当社のデータベース管理経験を基にすると、ほとんどのデータベースでは、バックアップに必要となる raw ストレージは、プライマリデータセットに必要となる raw ストレージよりも少なくて済みます。つまり、ほとんどのお客様は、バックアップストレージのために料金を支払うことはありません。バックアップストレージは、アクティブな DB インスタンスの場合のみ無料です。
  • データ転送 – DB インスタンスのインターネット経由のデータ受信および送信です。

Amazon RDS の利用料金については、Amazon RDS 製品ページの料金表をご覧ください。

Q: Amazon RDS DB インスタンスへの請求はいつ始まり、いつ終わりますか?

DB インスタンスが利用可能になるとすぐに、DB インスタンスへの請求が始まります。削除またはインスタンス障害の際に発生する DB インスタンスの終了まで、請求が続きます。

Q: 請求対象の Amazon RDS インスタンス時間はどのように定義されていますか?

利用可能な状態で DB インスタンスが動作している各時間に対して、DB インスタンス時間が請求されます。DB インスタンスへの課金をもはや望まない場合、追加のインスタンス時間に対して請求されないよう、DB インスタンスを終了する必要があります。1 時間に満たない DB インスタンスの利用は、1 時間として請求されます。

Q: なぜ追加バックアップストレージは割り当てられた DB インスタンスストレージよりもコストがかかるのですか?

お客様の一次データ用の DB インスタンスに対して準備されたストレージは、単一の Availability Zone 内に存在しています。データベースをバックアップすると、(トランザクション ログを含む)バックアップ データは、より優れたレベルのデータ耐久性を提供するため、複数の Availability Zone に対して地理的な冗長性をもってレプリケーションされます。無料割当量を超えたバックアップ ストレージの価格は、クリティカル バックアップの耐久性を最大化するために発生する、この特別なレプリケーションを反映しています。

Q: マルチ AZ DB インスタンスのデプロイに対してどのように請求されるのですか?

お客様のDBインスタンスが Multi-AZ 配備となるよう指定する場合、Amazon RDS 料金ページに記載された Multi-AZ 料金設定に応じて料金を請求させていただきます。Multi-AZ の料金は以下に基づきます:

  • Multi-AZ DB インスタンス時間 – 消費された DB インスタンスのクラス(例: スモール、ラージ、エクストララージなど)に基づいています。単一の Availability Zone への標準配備と同様に、消費される1時間未満の DB インスタンス時間は1時間分として請求されます。特定の1時間以内に、標準と Multi-AZ 間で DB インスタンスの配備を交換する場合、その時間に対して該当する両方の料金を課金されることになります。
  • (Multi-AZ DBインスタンス用に)設定されたストレージ – 特定の1時間以内に標準と Multi-AZ 間でお客様の配備を交換する場合、その時間に該当するストレージ料金のうち高いほうの金額が課金されます。
  • I/O リクエスト/月 – ストレージ I/O リクエストの合計。Multi-AZ 配備は、お客様のデータベース書き込み/読み込み比率によっては、標準のDBインスタンス配備よりも大容量の I/O リクエストを消費します。データベース更新に伴う書き込み I/O 使用量は、Amazon RDS がお客様のデータをスタンバイの DB インスタンスに 同時にレプリケーションする場合の2倍になります。読み込み I/O 使用量は変わりません。
  • バックアップストレージ – お客様のバックアップストレージ使用量は、DB インスタンスが標準であろうと、Multi-AZ 配備であろうと変わりません。. バックアップは、DB インスタンスプライマリ上の I/O 中断を避けるため、単純にお客様のスタンバイから取得されます。
  • データ転送 – お客様のプライマリおよびスタンバイ間でデータをレプリケーションする際に発生するデータ転送に対しては課金されません。

Q: 料金は税込み価格ですか?

別途記載がない限り、表示される料金には VAT、売上税、その他取引に対して適用される一切の税金等および関税は含まれません。日本の居住者であるお客様が東京リージョンをご利用になった場合には、料金とあわせて別途消費税をご請求させて頂きます。詳細はこちらを参照してください

Q: Amazon RDS での AWS 無料利用枠は何を提供していますか?

Amazon RDS の AWS 無料利用枠では、MySQL、MariaDB、PostgreSQL、Oracle (「自分のライセンス使用 (BYOL)」ライセンスモデル)、および SQL Server Express Edition を実行する Single-AZ マイクロ DB インスタンスを無料でご利用いただけます。無料利用枠は、1 か月あたり 750 インスタンス時間までとなっています。また、1 か月につき 20 GB のデータベースストレージ、1,000 万 I/O、20 GB のバックアップストレージも無料で使用可能です。

Q: Amazon RDS での AWS 無料利用枠をどれくらいの期間、利用することができるのですか?

新しい AWS アカウントを取得すると、12 か月の AWS 無料利用枠をお使いいただけます。詳細については、AWS の無料利用枠のよくある質問ページを参照してください。

Q: Amazon RDS での AWS 無料利用枠において、複数の DB インスタンスを実行できますか?

はい。同時に複数の Single-AZ マイクロ DB インスタンスを実行でき、それらの使用量は Amazon RDS での AWS 無料利用枠内で計算されます。ただし、すべての Amazon RDS Single-AZ マイクロ DB インスタンスおよび、すべての対象データベースエンジンおよびリージョンについて 750 インスタンス時間を超えるご利用については、標準の Amazon RDS 料金が課金されます。

例: 1 か月で 2 つの Single-AZ マイクロ DB インスタンスをそれぞれ 400 時間実行した場合、累算で 800 インスタンス時間の使用量になり、そのうち 750 時間が無料になります。残りの 50 時間分については、標準の Amazon RDS 料金が課金されます。

Q: AWS 無料利用枠では、MySQL、MariaDB、PostgreSQL、Oracle、および SQL Server のマイクロ DB インスタンスについて、それぞれ 750 インスタンス時間アクセスできるのですか?

いいえ。AWS 無料利用枠へのアクセス権を持つお客様は、MySQL、PostgreSQL、Oracle、または SQL Server Express Edition のいずれかを実行するマイクロインスタンスを 750 インスタンス時間までご利用いただけます。すべての Amazon RDS Single-AZ マイクロ DB インスタンスおよび、すべての対象データベースエンジンおよびリージョンにおいて 750 インスタンス時間を超えるご利用については、標準の Amazon RDS 料金が課金されます。

Q: Amazon RDS の AWS 無料利用枠は、すべての AWS リージョンで利用可能ですか?

Amazon RDS の AWS 無料利用枠は、GovCloud(米国)を除き、すべての AWS リージョンで利用可能です。

Q: インスタンス時間の使用量が無料利用枠を超えると、どのように課金されますか?

無料利用枠が提供するインスタンス時間を超えた時間については、標準の Amazon RDS 料金が課金されます。詳細については、Amazon RDS 料金表のページを参照してください。

Q: リザーブドインスタンス (RI) とは何ですか?

リザーブドインスタンスとは、データセンター内にキャパシティーを予約できるもので、予約によってカバーされるインスタンスに対しては、見返りとして時間単位料金の大幅な割引が受けられます。RI の料金お支払い方法には「前払いなし」、「一部前払い」、「全前払い」の 3 つがあり、前払いする金額と実効時間単価とのバランスを取ることができます。

Q: リザーブドインスタンスはオンデマンド DB インスタンスとどのように異なりますか?

機能的には、リザーブドインスタンスもオンデマンド DB インスタンスもまったく同一のものです。唯一異なる点は、お客様の DB インスタンスが課金される方法です。リザーブド DB インスタンスでは、データセンター内のマシンのキャパシティーを予約し、その代わりに期間中は低料金の実行時間単価(オンデマンド DB インスタンスと比較した場合)が適用されます。

Q: リザーブドインスタンスはどのように購入/作成しますか?

AWS マネジメントコンソールの [リザーブド DB インスタンスの購入] オプションを使用できます。あるいは、API ツールを使用できます。DescribeReservedDBInstancesOfferings API メソッドで購入可能な予約を一覧表示し、PurchaseReservedDBInstancesOffering メソッドを呼び出して DB インスタンスの予約を購入します。

リザーブド インスタンスの作成方法は、オンデマンドインスタンスの起動方法と同じです。CreateDBInstance API の rds-create-db-instance コマンドを使う、または AWS マネジメントコンソールの DB インスタンスの作成オプションを選択して、予約した DB インスタンスのクラスとリージョンを指定します。予約購入が完了すれば、Amazon RDS は割引価格をお客様の新しい DB インスタンスに適用します。

Q: 購入可能な予約は常時ありますか?

はい。リザーブド インスタンスは、Availability Zone ではなくリージョンに対して購入します。つまり、1 つの Availability Zone の容量に限界があったとしても、そのリージョンで予約を購入することができ、そのリージョン内の異なる Availability Zone で使用することができます。

Q: 購入できるリザーブドインスタンスの数を教えてください。

リザーブド DB インスタンスは最大 40 個まで購入できます。40 以上の DB インスタンスを実行したい場合は、Amazon RDS DB インスタンス申請フォームにご記入ください。

Q: すでに持っている既存の DB インスタンスをリザーブドインスタンスに変換したい場合はどうしますか?

現在実行している、または予約したい DB インスタンスと同じリージョン内の同じ DB インスタンスのクラス、DB Engine、ライセンスモデルで、DB インスタンスの予約を購入します。予約購入が完了すると、Amazon RDS は既存の DB インスタンスに時間単位の新しい使用料を自動的に適用します。

Q: リザーブドインスタンスに登録すると、いつから期間が始まりますか?DB インスタンスの使用期限が過ぎるとどうなりますか?

支払い認証の処理中にお客様からのリクエストをいただけば、リザーブド インスタンスに関連する価格変更が有効になります。AWS アカウントアクティビティページまたは DescribeReservedDBInstances API を使って予約の状態を確認できます。次の請求期間に一括払いが承認されない場合は、割引料金が適用されません。

予約期限が過ぎると、リザーブド インスタンスは、お客様の DB インスタンスクラスとリージョンに該当するオンデマンド時間料金に変わります。

Q: リザーブドインスタンスの料金で請求される DB インスタンスはどのようにコントロールするのですか?

DB インスタンスの作成、変更、削除を行うための Amazon RDS API はオンデマンドインスタンスとリザーブドインスタンスを区別しないため、シームレスに使用できます。お客様への請求額を計算する時、当社のシステムは、お客様の予約状態を自動的に適用して、該当するすべての DB インスタンスに低料金のリザーブド DB インスタンス料金を適用します。

Q: 保有するリザーブドインスタンスのクラスを上下すると、その予約はどうなりますか?

それぞれの予約は、以下の一連の属性に関連付けられています。DB Engine、DB インスタンスのクラス、デプロイのタイプ、ライセンスモデル、およびリージョンです。各予約は、期間内、同じ属性を持つ DB インスタンスに適用することができます。予約期間が終了する前に実行中の DB インスタンスのクラスの属性を変更する場合は、その DB インスタンスに対する時間料金はオンデマンドの時間料金に切り替わります。その後、その実行中の DB インスタンスの属性を元の予約と同じ属性に変更する、または元の予約と同じ属性で新しい DB インスタンスを作成すると、予約期間が終了するまで予約された価格が適用されます。

Q: 1 つのリージョンまたはアベイラビリティーゾーンから、別のリージョンまたはアベイラビリティーゾーンへ、リザーブドインスタンスを移動できますか?

各リザーブド インスタンスは、特定のリージョンに関連づけられています。これはリザーブドインスタンスの存続期間中固定されており、変更できません。ただし、それぞれの予約は、そのリージョン内のどのアベイラビリティーゾーンでも使用できます。

Q: リザーブドインスタンスはマルチ AZ 配置で利用できますか?

はい。DescribeReservedDBInstancesOfferings API を呼び出した場合、購入時に利用可能な DB インスタンス構成にある Multi-AZ オプションを探します。複数の Availability Zones に対して同期レプリケーションされる DB インスタンスを購入したい場合は、PurchaseReservedDBInstancesOffering 呼び出しで提供される中から1つを指定します。

Q: リザーブドインスタンスは、リードレプリカでも利用可能ですか?

標準の DB インスタンス予約は、同じ DB インスタンスクラスとリージョンを提供するリードレプリカにも適用可能です。お客様の請求書を計算する時、当社のシステムは、お客様の予約状態を自動的に適用して、該当するすべての インスタンスに低料金のリザーブド DB インスタンス料金を適用します。

Q: 予約はキャンセルできますか?

いいえ。リザーブド DB インスタンスはキャンセルできず、一括払いは(該当する場合)返金不可能です。使用されたかどうかにかかわらず、リザーブド DB インスタンスの期間が終了するまで、毎時間の料金をお支払いいただきます。

Q: 支払い方法によって料金請求はどのように変わるのですか?

RI の購入時に、お支払い方法として「全前払い」を選択した場合は、RI の期間全体の料金を一括で前払いしていただきます。いっさい前払いなしにすることもでき、その場合は「前払いなし」を選択します。「前払いなし」の RI の価額総額が期間内の各時間に分配され、お客様へのご請求は使用の有無にかかわらず、期間内の 1 時間ごとに発生することになります。「一部前払い」は、「全前払い」と「前払いなし」の間をとったお支払い方法です。最初に少額をお支払いいただき、使用の有無にかかわらず、期間内の 1 時間ごとに低い時間単価で計算した料金請求が発生します。

Q: どの初期 DB インスタンスクラスおよびストレージ容量が私のニーズに適しているかはどのように判断できますか?

最初の DB インスタンスとストレージ容量を選択するため、アプリケーションのコンピュート、メモリ、およびストレージニーズを評価したいと考えます。正しい DB インスタンスクラスとストレージ容量の選択に関するガイドラインについては、Amazon RDS DB インスタンスサイズ設定ガイドをご覧ください。

Q: 私の Amazon RDS データベースインスタンスに関連するコンピューティングリソースまたはストレージ容量、またはその両方はどのようにスケーリングするのですか?

ModifyDBInstance API または AWS マネジメントコンソールを使用して、コンピュートリソースやストレージ容量を拡張できます。(お好みの DB インスタンスを選択して [Modify] ボタンを押します)。メモリおよび CPU リソースは、DB インスタンスを変更することにより修正され、ストレージ割り当てを修正すると、利用可能なストレージが変更されます。DB インスタンスクラスまたは割り当て済みストレージを修正すると、指定したメンテナンスウィンドウ期間にリクエストされた変更が適用されることにご注意ください。あるいは、「apply-immediately」フラグを使用して、拡張リクエストをすぐに適用することができます。他の未処理のシステム変更も適用されることにご注意ください。

Amazon CloudWatch により、追加料金なしで DB インスタンスのコンピュートおよびストレージ リソースの利用を監視します。AWS マネジメントコンソールで DB インスタンスの [Monitoring] タブをクリックすることで、または Amazon CloudWatch API を使用して、CPU 使用量、ストレージ使用量、ネットワークトラフィックなどのメトリックスにアクセスすることができます。アクティブな DB インスタンスの監視についての詳細は、Amazon RDS 監視ガイドをご覧ください。

なお、SQL Server については、Windows Server 環境に接続されるストライプ化ストレージの伸張性の制約が理由で、Amazon RDS でのストレージの増量は現時点ではサポートされていません。この機能は今後サポート対象となる予定ですが、ストレージのプロビジョニングは将来のストレージ成長を見越して行うことをお勧めします。当面は、SQL Server DB インスタンスのストレージ増量が必要になった場合に、データをエクスポートし、ストレージを増量した新しい DB インスタンスを作成し、そのインスタンスにデータをインポートする必要があります。詳細については、Data Import Guide for SQL Server を参照してください。

Q: Amazon RDS ストレージのハードウェア構成はどのようなものですか?

Amazon RDS は、データベースとログの格納に EBS ボリュームを使用します。要求されるストレージのサイズによって、Amazon RDS は自動的に複数の EBS ボリューム全体をストライプして、IOPS パフォーマンスを向上させます。MySQL と Oracle については、ストレージをスケールアップすると、既存の DB インスタンスの I/O キャパシティがある程度向上することがあります。AWS マネジメントコンソールrds-modify-db-instance コマンド、または ModifyDBInstance API を使用して、DB インスタンスに割り当てられたストレージ容量を拡張することができます。

ただし、SQL Server については、Windows Server 環境に接続されるストライプ化ストレージの伸張性の制約が理由で、Amazon RDS でのストレージの増量は現時点ではサポートされていません。

詳細については、Amazon RDS のストレージを参照してください。

Q: スケーリング中の DB インスタンスは使用できますか?

DB インスタンスに割り当てたストレージ容量は、DB インスタンスの可用性を維持しながら増加できます。しかし、DB インスタンスに対して利用可能なコンピュートリソースの増加または減少を決定すると、DB インスタンスクラスが修正されている間にデータベースは一時的に利用不能になります。この利用不能期間は、一般的に数分で終了し、修正をすぐに適用することを指定しなかった場合、DB インスタンス用のメンテナンス ウィンドウ期間に発生します。

Q: 最大 DB インスタンスクラスおよび最大ストレージ容量を超えて DB インスタンスを拡張するには、どのようにしたらよいですか?

Amazon RDS は、様々なアプリケーション ニーズを満足するため、様々な DB インスタンス クラスおよびストレージ割り当てをサポートしています。アプリケーションが最大 DB インスタンスクラスよりも多くのコンピュートリソースを必要としているか、最大割当量よりも大きなストレージを必要としている場合、パーティション化を実施可能であり、複数の DB インスタンスにデータを分散することができます。

Q: Amazon RDS 汎用(SSD)ストレージとは何ですか?

Amazon RDS 汎用(SSD)ストレージは、I/O 要件が中程度の幅広いデータベースワークロードに適しています。このストレージの選択肢は基準が 3 IOPS/GB で、最大 3,000 IOPS までバーストでき、ほとんどのアプリケーションのニーズに対応する予測可能なパフォーマンスを提供します。

Q: Amazon RDS プロビジョンド IOPS(SSD)ストレージとは何ですか?

Amazon RDS プロビジョンド IOPS(SSD)ストレージとは、SSD ベースのストレージの選択肢の 1 つです。I/O のパフォーマンスが高速で、予測可能で、一定となるよう設計されています。Amazon RDS プロビジョンド IOPS(SSD)ストレージを使用する場合は、お客様が DB インスタンス作成時に IOPS レートを指定します。その IOPS レートは、DB インスタンスを終了させるまで維持されます。Amazon RDS プロビジョンド IOPS(SSD)ストレージは、大量の I/O が発生する、トランザクション指向(OLTP)のデータベースワークロードに最適です。詳しくは、Amazon RDS User Guide をご覧ください。

Q: Amazon RDS Magnetic ストレージとは何ですか?

Amazon RDS Magnetic ストレージは、以前はスタンダードストレージと呼ばれていました。このストレージは、データへのアクセスがあまり頻繁ではない軽度のデータベースワークロードに適しています。

Q: Amazon RDS ストレージタイプはどのように選択すればよいですか?

ワークロードに最も適したストレージタイプを選択してください。

  • 高パフォーマンスの OLTP ワークロード: Amazon RDS プロビジョンド IOPS(SSD)ストレージ
  • 中程度の I/O 要件のデータベースワークロード: Amazon RDS 汎用(SSD)ストレージ
  • I/O が頻繁に行われない小規模なデータベースワークロード: Amazon RDS Magnetic ストレージ

Q: Amazon RDS でサポートされる IOPS の最小値と最大値はどれくらいですか?

Amazon RDS でサポートされる IOPS は、データベースエンジンによって異なります。詳しくは、Amazon RDS User Guide を参照してください。

Q: 自動化バックアップと DB スナップショットの違いは何ですか?

Amazon RDS は、DB インスタンスのバックアップと復旧を行うための 2 つの方法、つまり自動化バックアップとデータベース スナップショット(DB スナップショット)を提供しています。

Amazon RDS の自動化バックアップ機能によって、お客様の DB インスタンスを特定時点から復旧することができます。DB インスタンスに対して自動化バックアップがオンになっている場合、Amazon RDS はお客様のデータを 1 日 1 回自動的に、(任意のバックアップウィンドウで)完全なスナップショットを作成し、(DB インスタンスに対する更新を作成中)トランザクションログを捕捉します。特定時点への復旧を開始する際、DB インスタンスをリクエストされた特定の時刻の状態に復元するために、最も適切なデイリーバックアップにトランザクションログを適用します。Amazon RDS は、DB インスタンスを、ユーザーが指定した限られた期間(保持期間と呼ぶ)保持します。これはデフォルトでは1日ですが、最大35日間に設定可能です。保持期間中、特定時点への復旧を開始して、最大で復元可能な最新時刻(Latest Restorable Time)まで、任意の秒数を指定することができます。DescribeDBInstances API を使用して、DB インスタンスの復元可能な最新時刻まで戻ることができます。これは通常過去5分以内です。 代わりに、AWS マネジメントコンソールで DB インスタンスを選択し、コンソールの下にあるパネルの [Description] タブでこれを閲覧することによって、その DB インスタンスの「復元可能な最新時刻」を知ることもできます。

DB スナップショットはユーザーにより開始され、指定した頻度で既知の状態で DB インスタンスをバックアップすることができ、その後いつでもその特定の状態に復旧することができます。DB スナップショットは、AWS マネジメントコンソールまたは CreateDBSnapshot API で作成可能であり、コンソールまたは DeleteDBSnapshot API で明示的に削除するまで保持されます。

自動バックアップを有効にするために Amazon RDS が実行するスナップショットは、コピー(AWS Console または rds-copy-db-snapshot コマンドを使用します)またはスナップショットの復元機能で使用できます。スナップショットは、「自動」のスナップショットタイプを使用して探すことができます。また、「スナップショット撮影時刻」フィールドを確認すると、スナップショットが撮影された時刻を特定できます。また、"自動" スナップショットの識別子にも、スナップショットが作成された時刻 (UTC) が含まれます。

注意: 期間内のある時点へ、または DB スナップショットから復旧動作を実行すると、新しいエンドポイントを持つ新しい DB インスタンスが作成されます(必要な場合、古い DB インスタンスは AWS Management Console または DeleteDBInstance API で削除できます)。これが行われることにより、特定の DB スナップショットまたはポイントインタイムから、複数の DB インスタンスを作成できるようになります。

Q: DB インスタンスのバックアップは手動で有効にする必要がありますか? それとも自動でしょうか?

デフォルトでは、追加料金なしで、Amazon RDS により、1日の保持期間で DB インスタンスの自動化バックアップを行うことができます。無料のバックアップ ストレージは準備したデータベースのサイズに限定されており、アクティブな DB インスタンスのみに適用されます。例えば、10GB/月の準備済みデータベース ストレージがある場合、追加料金なしで最大10GB/月のバックアップストレージを提供します。バックアップ保持期間を 1 日以上に延長したい場合、(新しい DB インスタンスの作成時には CreateDBInstance API または(既存 DB インスタンスに対しては)ModifyDBInstance API で延長することができます。 これらの API を使用して、1日から希望する日数まで RetentionPeriod パラメータを変更することができます。自動化バックアップの詳細については、Amazon RDS 開発者ガイドをご覧ください。

Q: バックアップウィンドウとは何ですか? なぜそれが必要ですか?バックアップウィンドウ期間で私のデータベースは利用できますか?

任意のバックアップウィンドウは、DB インスタンスをバックアップする、ユーザーが定義した期間です。Amazon RDS が、トランザクションログと併せてこれらの定期データバックアップを使用することにより、 お客様は、最大で復元可能な最新時刻 (LatestRestorableTime) (一般的には最大数分前) まで、保持期間中の任意の瞬間で DB インスタンスを復元できます。バックアップウィンドウ中に、バックアッププロセスの初期化が行われている間にストレージ I/O が一時中断 (通常 2~3 秒未満) することがあり、レイテンシーが短期間増加する可能性があります。マルチ AZ DB 配置では I/O 中断はありません。なぜならバックアップがスタンバイから取得されるためです。

Q: 自動バックアップと DB スナップショットの保存場所と保存内容を管理する方法について教えてください。

Amazon RDS DB スナップショットと自動バックアップは S3 に保存されます。

AWS Management Console または ModifyDBInstance API を使用して、RetentionPeriod パラメータを修正することにより、自動化バックアップが保持される期間を管理することができます。自動バックアップをすべて無効にしたい場合、保持期間を 0 に設定します (非推奨)。AWS Management Console の DB スナップショット セクションを使用して、ユーザー作成 DB スナップショットを管理できます。代わりに、DescribeDBSnapshots API を使用して、指定 DB インスタンスのユーザー作成 DB スナップショット一覧を表示でき、DeleteDBSnapshot API を使用して、スナップショットを削除できます。

Q: DB インスタンスを削除した場合、バックアップと DB スナップショットはどうなりますか?

DB インスタンスを削除するときに、最終的な DB スナップショットを作成できます。その場合、この DB スナップショットを使用して、削除された DB インスタンスを後日復元できます。Amazon RDS は、DB インスタンスが削除された後に、このユーザーが作成した最終的な DB スナップショットと、手動で作成されたその他の DB スナップショットをすべて保持します。バックアップストレージコストの詳細については、料金ページをご覧ください。

自動化されたバックアップは、DB インスタンスが削除されるときに削除されます。DB インスタンスの削除後に保持されるのは、手動で作成された DB スナップショットのみです。

Q: Amazon Virtual Private Cloud (VPC) とは何ですか? Amazon RDS を使用するメリットは何ですか?

Amazon VPC を使用すると、Amazon Web Services(AWS)クラウドの非公開の隔離されたセクションに仮想ネットワーキング環境を作成できます。この環境では、プライベート IP アドレスの範囲、サブネット、ルーティングテーブル、ネットワークゲートウェイなど、さまざまな点を完全にコントロールして演習できます。Amazon VPC では、仮想ネットワークトポロジを定義し、従来の IP ネットワークと同じようにネットワーク設定をカスタマイズできるため、独自のデータセンターで運用できます。

VPC で Amazon RDS を使用する事例の 1 つとして、パブリックに公開されているウェブアプリケーションを実行し、同時にプライベートサブネットではパブリックからアクセスできないバックエンドサーバーを保守する場合があります。インターネットにアクセスできるウェブサーバ用にパブリック側のサブネットを作成し、インターネットアクセスできないプライベート側のサブネットにバックエンド RDS DB インスタンスを配置することができます。Amazon VPC の詳細については、Amazon Virtual Private Cloud ユーザーガイドを参照してください。

Q: Amazon RDS を VPC 内で使用することは、それを EC2-Classic プラットフォーム(非 VPC)上で使用することとどのように違いますか?

Amazon RDS の基本機能は VPC を使用するかどうかにかかわらず同じです。Amazon RDS は、DB インスタンスが VPC 内外どちらにデプロイされるかにかかわらず、バックアップ、ソフトウェアのパッチ適用、自動障害検出、リードレプリカ、および復元を管理します。

VPC 以外に展開した Amazon RDS DB インスタンスには (エンドポイント/DNS 名を解決できる) 外部 IP アドレスが割り当てられ、EC2 またはインターネットから接続できます。Amazon VPC では、Amazon RDS DB インスタンスには (定義したサブネット内の) プライベート IP アドレスのみが割り当てられます。VPC 内の Amazon RDS DB インスタンスが公開されるよう、VPC を設定できます。詳細については、VPC のドキュメントを参照してください。EC2-Classic と EC2-VPC の相違点の詳細については、EC2 のドキュメントを参照してください。

Q: DB サブネットグループの概要とそれが必要な理由は何ですか?

DB サブネットグループとは、VPC 内で RDS DB インスタンス用に指定するサブネットのコレクションです。各 DB サブネットグループには、特定の Region 内の Availability Zone ごとに 1 つ以上のサブネットを指定する必要があります。VPC 内に DB インスタンスを作成するときに、DB サブネットグループを選択する必要があります。選択すると、Amazon RDS は、その DB サブネットグループと設定した Availability Zone を使用し、サブネットとそのサブネット内の IP アドレスを選択します。Amazon RDS によって Elastic Network Interface が作成され、その IP アドレスを持つ DB インスタンスに関連付けられます。

基になる IP アドレスは変わる可能性があるので(フェイルオーバーなどの理由で)、DB インスタンスに接続するときは DNS 名を使用することを強くお勧めします。

Multi-AZ 配備の場合、Region 内のすべての Availability Zone 用にサブネットを定義すると、必要に応じて Amazon RDS で別の Availability Zone に新しいスタンバイを作成できるようになります。Single-AZ 配備の場合も、どこかの時点で Multi-AZ 配備に変換する場合に備えてこのように定義する必要があります。

Q: VPC では Amazon RDS DB インスタンスをどのように作成しますか?

VPC 内に DB インスタンスを作成する手順については、Amazon RDS ユーザーガイドを参照してください。

以下に、VPC 内に DB インスタンスを作成するために必要な前提条件を示します。

  • VPC で、DB インスタンスを展開する Region 内のすべての Availability Zone に、1 つ以上のサブネットを指定する必要があります。Amazon VPC およびサブネット作成の詳細については、Amazon Virtual Private Cloud 入門ガイドを参照してください。
  • VPC 用に DB サブネットグループを定義する必要があります。
  • VPC 用に DB セキュリティグループを定義する必要があります(デフォルトで定義されているグループを使用することもできます)。
  • また、各サブネットには適度な大きさの CIDR ブロックを割り当てて、コンピュータの拡張やフェイルオーバーなどの保守作業で使用できる Amazon RDS 用の予備の IP アドレスを確保するようにします。

Q: DB インスタンスへのネットワークアクセスをどのようにコントロールしますか?

DB インスタンスのアクセスを制御する別の方法について詳しくは、Amazon RDS ユーザーガイドの「セキュリティグループ」を参照してください。

Q: VPC 内で実行されている Amazon RDS DB インスタンスはどのように保護すればよいでしょうか?

VPC セキュリティグループを使用すると、Amazon VPC 内の DB インスタンスを保護できます。また、各サブネットに出入りするネットワークトラフィックは、ネットワークアクセスコントロールリスト(ACL)を使用して許可または拒否することができます。IPsec VPN 接続を介する VPC へのすべてのネットワークトラフィックの出入りは、ネットワークファイアウォール、侵入検知機、防止システムなど、社内のセキュリティインフラストラクチャによって監視することができます。

Q: VPC 内の RDS DB インスタンスにはどのように接続しますか?

VPC 内に展開した DB インスタンスには、同じ VPC に展開した EC2 インスタンスからアクセスできます。Elastic IP が関連付けられたパブリックサブネット内にこのような EC2 インスタンスをデプロイしている場合は、インターネットから EC2 インスタンスにアクセスできます。

VPC 内に展開した DB インスタンスには、インターネットからアクセスできるだけでなく、VPN またはパブリックサブネットで起動できる踏み台ホストを介して VPC 以外にある EC2 インスタンスからアクセスすることができます。また、Amazon RDS の Publicly Accessible オプションを使用してアクセスすることもできます。

  • 踏み台ホストを使用するには、SSH の踏み台として動作する EC2 インスタンスを使用してパブリックサブネットを設定する必要があります。このパブリックサブネットには、SSH ホストを介してトラフィックを制御できるインターネットゲートウェイまたはルーティングルールが必要です。また、その SSH ホストから RDS DB インスタンスのプライベート IP アドレスに要求を転送できる必要があります。
  • パブリックな接続を使用するには、Publicly Accessible オプションを yes に設定して DB インスタンスを作成します。Publicly Accessible をアクティブにすると、デフォルトにより、VPC の外部から VPC 内の DB インスタンスでアクセス可能になります。つまり、DB インスタンスへのアクセスを許可するように VPN または踏み台ホストを構成する必要はありません。

社内ネットワークを VPC に拡張する VPN ゲートウェイを設定して、その VPC 内の RDS DB インスタンスにアクセスできるようにする方法もあります。詳細については、Amazon VPC ユーザーガイドをご参照ください。

基になる IP アドレスは変わる可能性があるので(フェイルオーバーなどの理由で)、DB インスタンスに接続するときは DNS 名を使用することを強くお勧めします。

Q: VPC 以外にある既存の DB インスタンスを自分の VPC に移動できますか?

VPC 以外にある DB インスタンスのスナップショットを作成し、VPC に復元することができます。それには、使用する DB サブネットグループを指定します。または、「以前の状態に復元」操作も可能です。

Q: VPC 内にある既存の DB インスタンスを VPC 以外に移動できますか?

現在、VPC 内から VPC 以外へ DB インスタンスを直接移行する操作はサポートされていません。セキュリティ上の理由から、VPC 内の DB インスタンスの DB スナップショットを VPC 以外の場所に復元することはできません。「以前の状態に復元」機能も同様です。DB インスタンスを VPC 内から VPC 以外へ移行する必要がある場合は、VPC 内のソース DB インスタンスのデータを、VPC 以外に展開したターゲット DB インスタンスにエクスポートする必要があります。

Q: VPC 内にある DB インスタンスをアプリケーションからアクセスできるようにするには、どのような注意事項がありますか?

ルーティングテーブルと VPC 内のネットワーキング ACL を変更して、VPC 内のクライアントインスタンスから DB インスタンスに到達できるようにする必要があります。

Multi-AZ 配備の場合、フェイルオーバー後に、クライアントの EC2 インスタンスと RDS DB インスタンスは異なる Availability Zone に属する可能性があります。そのため、AZ 間の通信が可能になるようにネットワーキング ACL を設定する必要があります。

Q: DB インスタンスの DB サブネットグループを変更できますか?

既存の DB サブネットグループを更新して、既存のアベイラビリティーゾーン用、または DB インスタンスの作成後に追加した新しいアベイラビリティーゾーン用にサブネットを追加できます。既存の DB サブネットグループからサブネットを削除すると、サブネットグループから削除される特定の AZ で実行されているインスタンスが利用できなくなります。

現時点では、既存の DB サブネットグループを更新しても、デプロイされた DB インスタンスの現在のサブネットは変更されません。インスタンスタイプのスケーリングオペレーションが必要です。現時点では、デプロイされた DB インスタンスの DB サブネットグループの明示的な変更は許可されていません。

Q: Amazon RDS マスターユーザーアカウントとは何であり、AWS アカウントとはどのように違っていますか?

Amazon RDS の使用を始めるには、AWS 開発者アカウントが必要です。Amazon RDS のサインアップの前にアカウントを持っていない場合、サインアップ プロセスの開始時にアカウントを作成するよう要求されます。マスターユーザー アカウントは、AWS 開発者アカウントとは異なっており、DB インスタンスへのアクセスをコントロールするため、Amazon RDS の範囲内でのみ使用します。マスターユーザー アカウントは、DB インターフェイスへの接続に使用できる固有のデータベース ユーザー アカウントです。DB インスタンスの作成時に、各 DB インスタンスと関連付けたいマスターユーザー名とパスワードを指定することができます。一旦 DB インスタンスを作成すると、マスターユーザー証明書を使用してデータベースへ接続することができます。後で、追加のユーザー アカウントを作成したい場合があるので、DB インスタンスへアクセスできる人を制限することができます。

Q: 私の DB インスタンスについてマスターユーザーにどのような特権が認められていますか?

MySQL の場合、マスターユーザーのデフォルトの特権は、create、drop、references、event、alter、delete、index、insert、select、update、create temporary tables、lock tables、trigger、create view、show view、alter routine、create routine、execute、trigger、create user、process、show databases、grant option です。

Oracle の場合、マスターユーザーには「dba」の役割が付与されます。マスターユーザーは、ほとんどの役割に関連付けられた特権を継承します。制限された特権のリスト、およびその特権を必要とする管理タスクを実行するための代替方法については、Amazon RDS User Guide をご覧ください。

SQL Server の場合は、データベースを作成したユーザーに db_owner ロールが付与されます。制限された特権のリスト、およびその特権を必要とする管理タスクを実行するための代替方法については、Amazon RDS ユーザーガイドを参照してください。

Q: Amazon RDS によるユーザー管理について何か違いがありますか?

いいえ、お客様がリレーショナルデータベースを管理するときと同じ方法ですべて機能します。

Q: 自分のデータセンターのサーバー上で動作しているプログラムは Amazon RDS データベースにアクセスできますか?

はい。インターネットを介してデータベースにアクセスする機能は、セキュリティグループを設定して手動で有効にする必要があります。特定の IP、IP 範囲、またはお客様自身のデータセンターにあるサーバーに該当するサブネットに対してのみアクセスを認可することができます。

Q: SSL を用いて、アプリケーションと DB インスタンスの間の接続を暗号化できますか?

はい。このオプションは現在 MySQL、MariaDB、SQL Server、PostgreSQL、および Oracle エンジンでサポートされています。

Amazon RDS は、各 DB インスタンスに対して SSL 証明書を生成します。暗号化された接続が確立されたら、DB インスタンスとお客様のアプリケーション間で転送されるデータは、転送中に暗号化されるようになります。

SSL がセキュリティ上の利点を提供する一方で、SSL 暗号化がかなりの計算処理を必要とするオペレーションであり、お客様のデータベース接続の待ち時間を増加させることにご注意ください。また、Amazon RDS 内での SSL サポートは、アプリケーションと DB インスタンス間での接続暗号化のためにあることにご注意ください。これは DB インスタンスそのものの認証には使用しないでください。

Amazon RDS との暗号化された接続の確立について詳しくは、Amazon RDS の MySQL ユーザーガイドMariaDB ユーザーガイドSQL Server ユーザーガイドPostgreSQL ユーザーガイド または Oracle ユーザーガイド を参照してください。これらのエンジンでの SSL の動作について詳しくは、MySQL のドキュメントMariaDB のドキュメントMSDN SQL Server のドキュメントPostgreSQL のドキュメント、または Oracle のドキュメントを直接参照してください。

Q: DB インスタンスに対して、暗号化された接続のみを受け付けるよう要求できますか?

MySQL の場合、マスターユーザー名とパスワードで DB インスタンスに接続後、GRANT ステートメントを使用して、特定のユーザーアカウントに対して SSL 接続を要求できます。 例えば、以下のステートメントを使用して、ユーザーアカウントにSSL接続を要求できます。 encrypted_user:

GRANT USAGE ON *.* TO ‘encrypted_user’@’%’ REQUIRE SSL

Q: Amazon RDS データベースで保管中のデータを暗号化できますか?

Amazon RDS では、AWS Key Management Service (KMS) で管理されるキーを使って、すべてのデータベースエンジンで保管時の暗号化をサポートしています。Amazon RDS 暗号化を使用して実行するデータベースインスタンスでは、基盤となるストレージに保管されるデータが、自動バックアップ、リードレプリカ、スナップショットとして暗号化されます。暗号化と復号は透過的に処理されます。Amazon RDS での KMS の使用に関する詳細は、Amazon RDS User's Guide を参照してください。

現在、既存の DB インスタンスの暗号化はサポートされていません。既存のデータベースで Amazon RDS 暗号化を使用するには、暗号化を有効にした新規 DB インスタンスを作成し、データを移行してください。

Oracle および SQL Server 用 Amazon RDS では、それぞれのエンジンの Transparent Data Encryption テクノロジーがサポートされます。Oracle の Transparent Data Encryption は、AWS CloudHSM と統合されています。これにより、AWS クラウド内のシングルテナントの Hardware Security Module (HSM) アプライアンスで安全に暗号化キーを生成、保管、管理できます。詳細については、Amazon RDS User's Guide の OracleSQL Server の各セクションを参照してください。

Q: 特定の RDS リソースに対してシステムとユーザーが実行できるアクションを制御するには、どうすればよいですか?

RDS リソースに対して AWS IAM ユーザーとグループが実行できるアクションを制御できます。制御するには、ユーザーとグループに適用している AWS IAM ポリシーの RDS リソースを参照します。AWS IAM ポリシーで参照できる RDS リソースには、DB インスタンス、DB スナップショット、リードレプリカ、DB セキュリティグループ、DB オプショングループ、DB パラメータグループ、イベントサブスクリプション、DB サブネットグループが含まれます。また、これらのリソースにタグを付けて、追加のメタデータをリソースに追加できます。タグを使用すると、リソースを分類し(「開発用」DB インスタンス、「本稼働用」DB インスタンス、「テスト用」DB インスタンスなど)、同じタグが設定されたリソースに対して適用する権限を登録した AWS IAM ポリシーを作成することができます。詳細については、 Managing Access to Your Amazon RDS Resources and Databases および Tagging Amazon RDS Resources をご覧ください。

Q: RDS デプロイメントに関するセキュリティ分析またはオペレーションのトラブルシューティングを実行したいと考えています。自分のアカウントで実行したすべての RDS API 呼び出しの履歴を取得することはできますか?

はい。AWS CloudTrail はアカウントに対する AWS API 呼び出しを記録し、ログファイルを配信するウェブサービスです。CloudTrail で生成される AWS API の呼び出し履歴を利用して、セキュリティの分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。CloudTrail の詳細については、AWS CloudTrail の詳細ページを参照してください。CloudTrail を有効にするには、CloudTrail の AWS マネジメントコンソールのホームページにアクセスしてください。

Q: DB インスタンス用に適切な設定パラメータを選択するには、どうすればよいですか?

Amazon RDS は、DB インスタンスのコンピュートリソースとストレージ容量を考慮して、デフォルト値として DB インスタンス用に最適の設定パラメータを選択します。しかし、それらを変更したい場合には、当社の設定管理 API を使用します。推奨値からの設定パラメータの変更は、性能の低下からシステムクラッシュまで、予期しない影響を生じる場合があり、これらのリスクを想定した高度なユーザーのみが行うべきであることにご注意ください。パラメータ変更に関する詳細については、『Amazon RDS User Guide』をご覧ください。

Q: DB パラメータグループとは何ですか?それらはどのように役立ちますか?

データベース パラメータグループ(DB パラメータグループ)は、1つ以上の DB インスタンスに適用可能なエンジン設定値の「容器」として動作します。DB パラメータのグループを指定せずに DB インスタンスを作成する場合、デフォルトの DB パラメータグループが使用されます。このデフォルト値のグループは、お客様が実行している DB インスタンス用に最適化されたエンジンデフォルト値と Amazon RDS システムデフォルト値を持っています。しかし、カスタム指定のエンジン設定値で DB インスタンスを実行したい場合、新しい DB パラメータグループを作成し、必要なパラメータを修正し、新しい DB パラメータグループを使用するため DB インスタンスを修正するだけで十分です。一旦関連付けが行われると、特定の DB パラメータグループを使用するすべての DB インスタンスは、その DB パラメータグループへのすべてのパラメータアップデートを取得します。DB パラメータグループの設定に関する詳細については、「DB Parameter Group Deployment Guide」をご覧ください。

Q: 指定された RDS DB パラメータグループに対して私のパラメータの現在の設定をどのように知ることができますか?

AWS マネジメントコンソール、Amazon RDS API またはコマンドラインツールを使用して、DB パラメータグループおよび該当するパラメータ設定についての情報を知ることができます。

Q: Amazon RDS がサポートしているのはどのタイプのレプリケーションですか? また、各タイプはどんなときに使用すべきですか?

Amazon RDS は、使用目的が異なる 2つのレプリケーションオプションを提供しています。

予期しない電源障害などが発生した時にデータベースの最新更新状態を保ちながらデータベースの可用性を高めたい場合は、DB インスタンスを Multi-AZ 配備として実行することを考慮します。DB インスタンスを作成または修正してマルチ AZ 配置として運用する場合、Amazon RDS は異なるアベイラビリティーゾーンに "スタンバイ" レプリカを自動的にプロビジョニングして管理します (各インフラストラクチャが物理的に離れた場所に存在)。予定されたデータベースメンテナンスまたは予期せぬサービス障害時、Amazon RDS は自動的にスタンバイに対してフェイルオーバーを行い、データベース運用を手動の管理介入なく速やかに再開できます。Multi-AZ 配備は、同期レプリケーションを活用して、データベースへの書き込みをプライマリとセカンダリで同時に行い、フェイルオーバーが発生した場合にスタンバイが最新の状態を保つようにしています。Multi-AZ DB インスタンスに対する当社の技術革新により障害発生時のデータ耐久性を最大化したことで、スタンバイに直接アクセスしたり、読み込み操作に使用されなくなりました。耐障害性を高めるマルチ AZ 配置は、本運用環境に最適です。マルチ AZ 配置の詳細については、こちらの「よくある質問」セクションをご覧ください。

マルチ AZ 配置は MySQL、Oracle、PostgreSQL、および SQL Server データベースエンジンでサポートされています。現在、SQL Server の マルチ AZ 配置を利用できるのは、米国東部(バージニア北部)、米国西部(オレゴン)、EU(ダブリン)の各 AWS リージョンです。

読み込み負荷の高いデータベースワークロードに単一 DB インスタンスの能力が対応しきれない場合にキャパシティの制約を超えてスケーリングできるように、Amazon RDS にはリードレプリカが用意されています。AWS マネジメントコンソールまたは CreateDBInstanceReadReplica API を使うと、与えられたソース DB インスタンスのリードレプリカを作成できます。リードレプリカを作成すると、データベースがソース DB インスタンスを更新して、リードレプリカにプロパゲートされます。1 つのソース DB インスタンスに対して複数のリードレプリカを作成して、アプリケーションの読み込みトラフィックをこれらのレプリカに分散させます。

リードレプリカは、Amazon RDS for MySQL および PostgreSQL でサポートされています。Multi-AZ 配置とは異なり、これらのエンジンのリードレプリカは、各エンジンに組み込まれているレプリケーションテクノロジーを使いますが、これには、その長所と制限が反映されます。特に、ソース DB インスタンスに更新が発生した後にリードレプリカにも更新が適用されます(「非同期」レプリケーション)。つまり、レプリケーションに大幅な遅延が生じます。つまり、スタンダード(Multi-AZ でない)ソース DB インスタンスに対する最新のデータベース更新は、ソース DB インスタンスで計画外の停止が発生した場合に、対応するリードレプリカには存在しなくなる可能性があります。そのような場合、リードレプリカは、Multi-AZ 配備が提供するものと同じデータ耐久性を提供できません。リードレプリカによって読み取りの可用性は高まりますが、書き込みの可用性を提供するよう設計されたものではありません。

Multi-AZ 配備とリードレプリカを組み合わせると、それぞれの特長の相乗効果が得られます。与えられた Multi-AZ 配備がお客様のリードレプリカのソース DB インスタンスであることを指定するだけです。この方法により、Multi-AZ 配備のデータ耐久性と可用性、およびリードレプリカの読込み能力の拡大という両面の利点を得ることができます。

Q: DB インスタンスをマルチ AZ 配置として実行することにどのような意味がありますか?

DBインスタンスを作成または修正して Multi-AZ 配備として実行する場合、Amazon RDS は別の Availability Zone において同期する、「スタンバイ」レプリカを自動的に設定して管理します。DB インスタンスに対する更新は、別の利用可能ゾーンにあるスタンバイに同時にレプリケートされるので、同期が維持されるとともに、最新のデータベース更新が DB インスタンスの障害から保護されます。特定の種類のメンテナンス中、またはDBインスタンス障害もしくは Availability Zone の障害といった予期せぬイベント時に、Amazon RDS はスタンバイに対して自動的にフェイルオーバーし、スタンバイが昇格し次第データベースの読み込みと書き込みを再開できるようにします。DB インスタンスの名前レコードは変化しないので、アプリケーションでのデータベースオペレーションは、管理者による手動での介入なしで再開できます。Multi-AZ 配備を使うと、レプリケーションが透過的になります。スタンバイを直接操作しなくなり、読み込みトラフィックには使えなくなります。Amazon RDS for MySQL を使用する場合に、単一 DB インスタンスのキャパシティ制限を超えるスケールアウトを検討している場合は、リードレプリカをデプロイできます。

Q: アベイラビリティーゾーンとは何ですか?

Availability Zones とは、別の Availability Zone で発生した障害から隔離するために作られたリージョン内の場所です。各 Availability Zone は、その独自の、物理的にはっきりと独立したインフラストラクチャ上で稼動しています。また高い信頼性を保つように設計されています。発電機や冷却装置などの障害対策用装置がアベイラビリティーゾーン間で共有されることはありません。さらに、これらは物理的にそれぞれ別々の場所にあるため、火災、竜巻、または洪水などの極めて稀な災害でも、影響を受けるのは1つの Availability Zone のみです。同一リージョンにある Availability Zone は、待ち時間が短いネットワーク接続を提供します。

Q: マルチ AZ 配置のコンテキストにおいて "プライマリ" と "スタンバイ" は何を意味しますか?

DBインスタンスを Multi-AZ 配備として実行する場合、「プライマリ」はデータベースに読み込みと書き込みの機能を提供します。さらに、Amazon RDS は、背後で「スタンバイ」を設定して管理します。これはプライマリの最新レプリカになります。スタンバイはフェイルオーバー時に(プライマリに)「昇格」します。フェイルオーバー後、スタンバイはプライマリとなり、お客様のデータベースオペレーションを受け付けるようになります。昇格前には、どの時点においても、スタンバイと直接やりとり(例: 読み込みオペレーション)することはありません。単一の DB インスタンスの容量制限を超えて読込みトラフィックをスケーリングする方法に関心のあるお客様は、リードレプリカの FAQ をご覧ください。

Q: マルチ AZ 配置の利点は何ですか?

DBインスタンスを Multi-AZ 配備として実行することの主な利点は、データベースの堅牢性と可用性を強化することです。Multi-AZ 配備によって提供される可用性とフォールト・トレランス(障害体制)の強化は、重要な運用環境に対して間違いなく適合するものです。

DB インスタンスを Multi-AZ 配備として運用すると、万一 DB インスタンスコンポーネントの障害が発生したときや、利用可能ゾーンの1つが利用できなくなったような場合でも、データの安全が守られます。例えば、プライマリ上のストレージボリュームが障害を受ける場合、Amazon RDS はスタンバイに対して自動的にフェイルオーバーを開始し、お客様のデータベース更新はそのスタンバイですべて完全な状態に保たれます。 これは、単一のAZにおける標準配備と比較した場合、さらなるデータ堅牢性を提供するものです。単一の AZ における標準配備では、ユーザーによって開始される復元オペレーションが必要で、復元可能な最新時刻(一般的には過去5分以内)後に発生した更新は利用できません。

データベース可用性の向上も、DB インスタンスを Multi-AZ 配備として運用するときのメリットの1つです。アベイラビリティーゾーンの障害または DB インスタンスの障害が発生する場合、自動フェイルオーバーが完了するまでの間のみ、可用性が影響を受けます。Multi-AZ の可用性に対する恩恵は、計画されたメンテナンスにも拡大されます。例えば、自動バックアップでは、バックアップがスタンバイから取得されるため、お好みのバックアップウィンドウで、プライマリ上での I/O アクティビティが中断されることはありません。パッチングまたは DB インスタンスクラスの拡張を行う場合、これらのオペレーションは、自動フェイルオーバーの前にスタンバイで最初に行われます。結果的に、可用性に対する影響は、自動フェイルオーバーを完了するのに必要な時間に限定されます。

DB インスタンスを Multi-AZ配備として実行することの別の目立たない恩恵として、DB インスタンスのフェイルオーバーが自動であり、手動管理が必要ないことがあります。Amazon RDS のコンテキストでは、これは Availability Zone 障害または DB インスタンスの障害時に、(RestoreDBInstanceToPointInTime または RestoreDBInstanceFromSnapshot API を使用して)DB インスタンスのイベントを監視し、手動で DB インスタンスの復旧を開始する必要がないことを意味します。

Q: DB インスタンスをマルチ AZ 配置として実行と、パフォーマンス上の意味がありますか?

お客様のために実行される同期的データレプリケーションの結果として、単一のアベイラビリティーゾーンにおける標準 DB インスタンスのデプロイと比較した場合、レイテンシーが増加する可能性があります。

Q: DB インスタンスをマルチ AZ 配置として実行する場合、読み込みまたは書き込みを行う操作のためにスタンバイを使用できますか?

いいえ。スタンバイのレプリカは読み込みリクエストに対応していません。Multi-AZ 配備は、読み込み機能の拡張による恩恵よりも、データベースの可用性と堅牢性の強化を提供するよう設計されています。そのため、この機能はプライマリとスタンバイの間で同期するレプリケーションを行います。当社の実装では、プライマリとスタンバイが常に同期するようにしてありますが、スタンバイを読み込みまたは書き込みオペレーションのために使用する機能は除外しています。読み込みのスケーリングソリューションに興味がある場合は、リードレプリカに関するよくある質問をご覧ください。

Q: マルチ AZ DB インスタンス配置の設定はどのように行うのですか?

Multi-AZ DB インスタンス配備を作成するには、AWS Management Console で DB インスタンスを起動する際に、[Multi-AZ 配備] で [はい] のオプションをクリックするだけです。 代わりに、Amazon RDS API を使用している場合、CreateDBInstance API を呼び出して [Multi-AZ] パラメータの値を [true] に設定することもできます。既存の標準(単一 AZ)DB インターフェイスを Multi-AZ に変換するには、AWS Management Console で DB インスタンスを修正するか、ModifyDBInstance API を使用して Multi-AZ パラメータを真に設定します。

Q: RDS インスタンスをシングル AZ からマルチ AZ に変換すると何が発生しますか?

RDS MySQL、MariaDB、PostgreSQL、および Oracle のデータベースエンジンについては、RDS インスタンスを Single-AZ から Multi-AZ に変換すると、次のことが発生します。

  • プライマリインスタンスのスナップショットが取得されます。
  • そのスナップショットから新しいスタンバイインスタンスが別のアベイラビリティーゾーンに作成されます。
  • 同期レプリケーションがプライマリインスタンスとスタンバイインスタンスとの間に構成されます。

結果として、インスタンスが Single-AZ から Multi-AZ に変換される際には、ダウンタイムは発生しません。

Q: Amazon RDS によるスタンバイレプリカへのフェイルオーバーは、どのようなイベントのときに発生しますか?

Amazon RDS では、マルチ AZ 配置における一般的な障害シナリオの検出とリカバリが自動的に行われるので、管理者の介入は不要でデータベース操作を可能な限りすみやかに再開できます。Amazon RDS によって自動的にフェイルオーバーが実行されるのは、次のことが発生したときです。

  • プライマリ利用可能ゾーンの可用性損失
  • プライマリに対するネットワーク接続の喪失
  • プライマリ上でのコンピュートユニット障害
  • プライマリへのストレージ不良

注: DB インスタンスの拡大/縮小やシステムアップグレード(OS パッチ適用など)がマルチ AZ 配置に対して行われるときは、可用性を高めるために、これらが最初にスタンバイに適用されて、その後で自動フェイルオーバーが実行されます。したがって、可用性への影響が現れるのは自動フェイルオーバーを完了するのに必要な時間までとなります。なお、Amazon RDS マルチ AZ 配置での自動フェイルオーバーは、データベース操作におけるエラー(長時間実行クエリ、デッドロック、データベース破損など)の発生に対しては行われません。

Q: 自動フェイルオーバーが発生するときに警告がありますか?

はい。Amazon RDS は DB インスタンス イベントを発行し、自動フェイルオーバーが発生したことを知らせます。DescribeEvents を使用して、お客様の DB インスタンスに関連するイベントについての情報を返すことができます。または、AWS Management Console の [DB イベント] セクションをクリックします。

Q: マルチ AZ のフェイルオーバー中どのようなことが起き、どれくらいの間継続しますか?

フェイルオーバーは Amazon RDS によって自動的に処理されるため、管理上の手動介入なく、可能な限り迅速にデータベースオペレーションを再開することができます。フェイルオーバー時、Amazon RDS は単純に DB インスタンスの正規名レコード(CNAME)を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。ベストプラクティスに従い、アプリケーションレイヤーでデータベース接続のリトライを実施することを推奨いたします。

フェイルオーバーは、プライマリで障害が検出されてからスタンバイでトランザクションが再開されるまでの間隔として定義され、通常 1 ~ 2 分以内に完了します。コミットされていない大きなトランザクションを回復させる必要があるかどうかによっても、フェイルオーバー時間は異なります。最適の結果を得るには、マルチ AZ では十分に大きなインスタンスタイプを使用することをお勧めします。また、高速かつ予測可能で、安定したスループットパフォーマンスを得るには、マルチ AZ インスタンスとともにプロビジョニングされた IOPS を使用することをお勧めします。

Q: マルチ AZ DB インスタンス配置に対して "強制フェイルオーバー" を開始できますか?

Amazon RDS は、さまざまな障害状態のときにユーザー介入なしで自動的にフェイルオーバーを行います。さらに、Amazon RDS ではインスタンスが再起動されたときにフェイルオーバーを開始することもできます。この機能にアクセスするには、AWS マネジメントコンソールを使用するか、RebootDBInstance API 呼び出しを使用してください。

Q: マルチ AZ の同期的レプリケーションはどのようにコントロール/設定するのですか?

Multi-AZ 配備を使用する場合、[Multi-AZ] パラメータを真に設定するだけです。スタンバイ、同期的レプリケーションおよびフェイルオーバーの作成は、すべて自動的に処理されます。つまり、スタンバイが配備されている Availability Zone を選択したり、利用可能なスタンバイ数を変更したりすることはできません(Amazon RDS は、1 DB インスタンス プライマリごとに1つの専用スタンバイを設定します)。また、スタンバイは、データベースの読み取りアクティビティを許可するよう設定できません。マルチ AZ 配置の詳細についてはこちらをご覧ください。

Q: 私のスタンバイは私のプライマリと同一のリージョンになりますか?

はい。お客様のスタンバイは、同一リージョン の異な るAvailability Zone において、DB インスタンス プライマリとして自動的に設定されます。

Q: 私のプライマリが現在どのアベイラビリティーゾーンなのかを確認できますか?

はい。AWS マネジメントコンソールまたは DescribeDBInstances API を使用することで、現在のプライマリロケーションを視認することができます。

Q: フェイルオーバー後、私のプライマリは、私の他の AWS リソース (例: EC2 インスタンス) とは異なるアベイラビリティーゾーンに所在しています。レイテンシーについて心配する必要がありますか?

Availability Zones は、同一リージョンの別の Availability Zones に対して、待ち時間が短いネットワーク接続を提供するよう設計されています。さらに、1つの Availability Zone でのサービス障害時にお客様のアプリケーションが回復力を持つように、複数の Availability Zone 全体で冗長性を持つアプリケーションや他AWリソースの設計を考慮したいかもしれません。Multi-AZ 配備は、お客様サイドでの管理作業なく、データベースに対するこのニーズを解決します。

Q: DB スナップショットと自動バックアップは、マルチ AZ 配置とどのように連携するのですか?

自動バックアップと DB スナップショットの機能の扱い方は、単一 AZ での標準的な配置とマルチ AZ 配置のどちらで実行するかにかかわらず同一です。マルチ AZ 配置で実行している場合は、自動バックアップと DB スナップショットはスタンバイから取得されます。これは、プライマリでの I/O 中断を避けるためです。なお、単一 AZ とマルチ AZ のどちらの配置の場合も、バックアップ取得中は I/O レイテンシーが増加する可能性があることにご注意ください(一般的には数分で元に戻ります)。

復元操作(特定時点への復元または DB スナップショットからの復元)についても、マルチ AZ 配置での機能は標準の単一 AZ 配置の場合と同じです。新しい DB インスタンス配備は、RestoreDBInstanceFromSnapshot または RestoreDBInstanceToPointInTime API のどちらかで作成できます。 これらの新しい DB インスタンス配備は、ソースバックアップが標準配備で開始されていようと、Multi-AZ 配備で開始されていようと、それとは無関係に標準または Multi-AZ のどちらかに設定できます。

Q: DB インスタンスをリードレプリカとして実行することに、どのような意味がありますか?

リードレプリカは、サポートされるエンジンに組み込まれているレプリケーション機能を使って、単一の DB インスタンスの容量制限を弾性的に拡大してデータベースの読み込み負荷を緩和させることができます。ユーザーは、AWS マネジメントコンソールで数回クリックするか、CreateDBInstanceReadReplica API を使って、リードレプリカを作成できます。リードレプリカを作成すると、データベースは、サポートされるエンジンのネイティブ非同期レプリケーション機能を使ってソース DB インスタンスを更新します。1 つのソース DB インスタンスに対して複数のリードレプリカを作成して、アプリケーションの読み込みトラフィックをこれらのレプリカに分散させます。リードレプリカは、サポートされるエンジンに組み込まれているレプリケーション機能を使用するため、その長所と制限が反映されます。特に、更新は、ソース DB インスタンスを更新した後にリードレプリカに反映されるため、レプリケーションが大幅に異なる場合があります。リードレプリカは、Multi-AZ 配備に関連付けて、Multi-AZ 配備が提供するデータの書込み可用性と耐用性に加え読込み性能を拡大することができます。

Q: Amazon RDS リードレプリカの使用を検討すべきなのはどのような場合ですか?

与えられた DB インスタンスで正しく機能するためにリードレプリカを配備する場所は様々です。リードレプリカを配備する一般的な理由:

  • 読込みが多いデータベースに対して1つの DB インスタンスの処理または入出力機能を拡張します。これにより過度の読込みトラフィックを1つまたは複数のリードレプリカに誘導することができます。
  • ソース DB インスタンスが利用可能でない場合に読込みトラフィックを誘導します。お客様のソース DB インスタンスが入出力リクエストを取ることができない(バックアップまたは定期メンテナンスによる入出力一時停止のため)、読込みトラフィックをリードレプリカに誘導することができます。このような使用の場合、リードレプリカのデータは、ソース DB インスタンスが利用可能でないために、「古い」場合があるため注意が必要です。
  • ビジネスレポーティング、またはデータウェアハウジングでは、プライマリプロダクション DB インスタンスではなく、ビジネスレポーティングクエリーをリードレプリカに対して実行します。

Q: リードレプリカを作成する前に、DB インスタンスで自動バックアップを有効にする必要がありますか?

はい。リードレプリカを追加する前に、バックアップ保持期間を 0 以外の値に設定して、DB インスタンスの自動バックアップを有効にします。リードレプリカを動作させるには、バックアップを有効にする必要があります。

Q: Amazon RDS リードレプリカをサポートするのはデータベースエンジンのどのバージョンですか?

Amazon RDS for MySQL: リードレプリカを動作させるには、バックアップを有効にする必要があります。自動バックアップは、MySQL 5.6 以降 (5.1 と 5.5 は対象外) を実行する Amazon RDS リードレプリカでのみサポートされます。

Amazon RDS for PostgreSQL: PostgreSQL バージョン 9.3.5 以降のインスタンスのみ、リードレプリカの作成をサポートします。Amazon RDS リードレプリカを利用するには、バージョン 9.3.5 より前の既存の PostgreSQL インスタンスを PostgreSQL バージョン 9.3.5 にアップグレードする必要があります。

Amazon RDS for MariaDB: リードレプリカを動作させるには、自動バックアップを有効にする必要があります。

Q: Amazon RDS for MySQL リードレプリカの使用はどのストレージエンジンでサポートされていますか?

Amazon RDS for MySQL リードレプリカにはトランザクションストレージエンジンが必要であり、InnoDB ストレージエンジンでのみサポートされています。MyISAM などの非トランザクション MySQL ストレージエンジンでは、リードレプリカが意図したとおりに動作しない可能性があります。それでも MyISAM でリードレプリカを使用する場合は、Amazon CloudWatch の「レプリカラグ」の計測値(AWS Management Console または Amazon CloudWatch API を介して取得できます)を注意して監視し、レプリケーションエラーが原因でリードレプリカが停止した場合は再作成することをお勧めします。一時テーブルや他の非トランザクションエンジンを使用する場合も、同様の注意事項が適用されます。

Q: 与えられた DB インスタンスにリードレプリカをどのようにデプロイしますか?

標準の CreateDBInstanceReadReplica API を使う、または Amazon RDS Management Console を数回クリックするだけで数分でリードレプリカを作成することができます。リードレプリカを作成する時は、SourceDBInstanceIdentifier を指定してリードレプリカを特定することができます。SourceDBInstanceIdentifier は、レプリケーションしたい「ソース」DB インスタンスを特定する DB インスタンス識別子です。標準 DB インスタンスと同様に、Availability Zone、DB インスタンスのクラス、推奨するメンテナンスウィンドウも指定できます。エンジンのバージョン(PostgreSQL 9.3.5 など)とリードレプリカの記憶域割り当ては、ソース DB インスタンスから継承されます。リードレプリカの作成を開始すると、Amazon RDS は、お客様のソース DB インスタンスのスナップショットを撮り、レプリケーションを開始します。その結果、スナップショットを撮る間、ソース DB インスタンスに軽度の入出力停止が発生します。入出力の一時停止は、通常 1 分程度です。ソース DB インスタンスがマルチ AZ 配置の場合は、回避されます(マルチ AZ 配置の場合は、スタンバイのスナップショットがあります)。Amazon RDS は、現在、最適化が行われています。(近日中に公開予定)複数のリードレプリカを30分の範囲で作成した場合、すべてのリードレプリカのソーススナップショットは同じとなり、入出力の影響を最小限にします。(それぞれのリードレプリカに対する「キャッチアップ」レプリケーションは作成後に開始します)。

Amazon RDS リードレプリカでは、簡単に削除できます。Amazon RDS Management Console を使う、または DeleteDBInstance API(削除したいリードレプリカに対する DBInstanceIdentifier を指定)を呼び出します。

リードレプリカの作成をリクエストする場合は、以下の事柄に注意してください。

  • MyISAM などの非処理エンジンを使う場合は、以下の手順に従ってリードレプリカを設定する必要があります。この手順は、リードレプリカがお客様のデータと一致するために必要です。ただし、すべてのテーブルが InnoDB などのトランザクションを管理するエンジンを使用している場合にはこの手順は必要ありません。1. 非トランザクション テーブルのすべての DML および DDL 操作を停止して、それらが完了するまで待ちます。SELECT 記述で実行を続けます。2. それらのテーブルをフラッシュしてからロックします。3. CreateDBInstanceReadReplica API を使ってリードレプリカを作成します。4. DescribeDBInstances API を使ってレプリカの作成状況を確認します。レプリカが利用可能となったら、テーブルをアンロックして、通常のデータベース操作を再開します。
  • お客様のソース RDS インスタンスにトランザクションの実行が長い物がある場合は、そのトランザクションが完了するのを待ってから、そのソースを基にしたリードレプリカの作成をリクエストしてください。

Q: 自分のリードレプリカにどのように接続しますか?

DescribeDBInstance API または AWS Management Console を使ってリードレプリカに対するエンドポイントを読み出して標準 DB インスタンスと接続するのと同じようにリードレプリカを接続します。リードレプリカが複数ある場合、読込みトランザクションがどのように誘導されるかはアプリケーションに依存します。

Q: 与えられたソース DB インスタンスに対して、いくつのリードレプリカが作成可能ですか?

現在、Amazon RDS for MySQL およびPostgreSQL では、特定のソース DB インスタンスに対して最大 5 個までのリードレプリカを作成できます。

Q: ソース DB インスタンスとは異なる AWS リージョンにリードレプリカを作成できますか?

Amazon RDS for MySQL および Postgre SQL は、リージョンが異なるリードレプリカをサポートしています。 

Q: Amazon RDS リードレプリカは同期レプリケーションをサポートしますか?

いいえ。Amazon RDS for MySQL および PostgreSQL のリードレプリカは、これらのエンジンのネイティブの非同期レプリケーションを使用して実装されています。

Q: リードレプリカを使って、障害が発生した場合のデータベースを書き込んだり、自分のソース DB インスタンスの保護を強化することはできますか?

レプリケーションを使ってデータベースの書き込み性能を強化し、さまざまな障害条件に対してデータベースの最新状態を保護するためには、DB インスタンスをマルチ AZ 配置として実行することをお勧めします。サポートされるエンジンのネイティブな非同期レプリケーションを使用する Amazon RDS リードレプリカでは、データベースの書き込みがソース DB インスタンスで既に発生した後にリードレプリカで発生するため、このレプリケーションの「遅延」は状態に応じてかなり異なります。その反面、Multi-AZ 配備が使うレプリケーションは同期しています。つまり、すべてのデータベース書込みはプライマリとスタンバイで同時に行われます。こうしてデータベース更新の最新状態を保護し、障害が発生した場合にスタンバイが利用可能であるようにします。さらに、Multi-AZ 配備のレプリケーションは、完全に管理されています。Amazon RDS は、DB インスタンスの障害状態または Availability Zone の障害を自動的にモニタリングして、停電などが発生した場合に、自動的にフェイルオーバーを開始します。

Q: リードインスタンスのソースとしてマルチ AZ DB インスタンス配置を持つリードレプリカを作成できますか?

はい。Multi-AZ DB インスタンスはリードレプリカとは異なるニーズに対処するため、プロダクション展開で双方を使用して、リードレプリカを Multi-AZ DB インスタンスに関連付けることは理にかなっています。「ソース」 Multi AZ-DB インスタンスは、書込み可用性とデータの耐久性を強化し、関連するリードレプリカは、読込みトラフィックの拡張性を向上します。

Q: Amazon RDS リードレプリカ自体を Multi-AZ にできますか?

Amazon RDS for MySQL および PostgreSQL は、現在この機能をサポートしていません。

Q: 自分のリードレプリカがマルチ AZ DB インスタンス配置をソースとして使用する場合、マルチ AZ フェイルオーバーが発生した場合にどうなりますか?

マルチ AZ フェイルオーバーが発生した場合、関連するリードレプリカ、および利用可能なリードレプリカは、フェイルオーバーが完了すると、自動的にレプリケーションを再開します (新たに昇格したプライマリから更新を取得します)。

Q: Multi-AZ フェイルオーバー後、Amazon RDS for MySQL リードレプリカの状態が「スタック」と表示され、ソース DB インスタンスから更新を受信または適用できません。どうしたらよいですか?

Multi-AZ フェイルオーバーが発生した後、Amazon RDS for MySQL リードレプリカがソース Multi-AZ DB インスタンスから更新を受信または適用できない場合があります。これは、いくつかの MySQL バイナリログ イベントがフェイルオーバーの時点でディスクにフラッシュされていないからです。フェイルオーバーの後、リードレプリカは、存在しないソースからバイナリログを要求している可能性があります。このクラッシュによる MySQL バイナリログの損失については、この MySQL 文書に記されています。

この問題に関する情報は、MySQL sync-binlog パラメータを説明している行の下に説明されています。このパラメータは、MySQL バイナリログをディスクにフラッシュする方法をコントロールし、InnoDB を使うタイミング、バイナリログと InnoDB ログを同期する方法をコントロールします。

現在の問題を解決するためには、リードレプリカを削除して、代わりとなる新しいリードレプリカを作成する必要があります。今後この問題を回避するためには、sync-binlog=1 に設定すると、クラッシュやフェイルオーバーが発生した際にリードレプリカが要求する MySQL バイナリログを損失する可能性が大幅に減ります。MySQL 文書が説明する通り、上述を行っても完全にこの問題を解決することはできません。さらにこの問題に遭遇する可能性を減らすには、innodb_support_xa=1 を設定します。これらの変数を設定すると、パフォーマンスに影響が出る場合があります。sync_binlog と innodb_support_xa は双方ともに動的変数であるため、パフォーマンスへの影響が大きすぎる場合は、停止しなくてもそれらをリセットできます。

これは、パフォーマンスまたはソース Multi-AZ のフェイルオーバーが発生した後のリードレプリカの自動再同期の改善のどちらを優先するかという究極の選択です。Amazon RDS Read Replicas を使う利点の1つは、削除による同期の問題が発生した時に迅速に再度インスタンスの作成を行うことができます。それ自体は、同期リードレプリカを手動で中断し、自分のニーズに合うリードレプリカを再作成する場合に、同期バイナリログおよび/または innodb_support_xa の設定がパフォーマンスに影響することはありません。 

Q: 別のリードレプリカのリードレプリカを作成できますか?

Amazon RDS for MySQL: 既存の第 1 層リードレプリカから第 2 層リードレプリカを作成できます。第 2 層リードレプリカを作成すると、マスターデータベースインスタンスからのレプリケーション負荷の一部を第 1 層リードレプリカに移動することができます。ただし、トランザクションはマスターから第 1 層レプリカにレプリケートされてから、第 2 層レプリカにレプリケートされ、レプリケーションのレイテンシーが増えるため、第 2 層リードレプリカはマスターよりも遅延する可能性があります。

Amazon RDS for PostgreSQL: 現在、リードレプリカのリードレプリカはサポートされていません。

Q: リードレプリカでデータベースの読み取りオペレーションのみを受け付けるようにすることはできますか?

リードレプリカは、読込みトラフィックを誘導するためのものです。ただし、上級ユーザーがリードレプリカに対してデータ定義言語(DDL) SQL 記述を完了したい場合があります。例えば、同じインデックスに対応するソース DB インスタンスに追加せずに、ビジネスレポーティングに使用されるリードレプリカにデータベースインデックスを追加する場合などです。

Amazon RDS for MySQL は、リードレプリカに対する DDL SQL ステートメントを許可するように設定できます。与えられたリードレプリカに対して読み込み以外の操作を有効にする場合は、リードレプリカに対してアクティブ DB パラメータグループを変更し、「read_only」パラメータを「0」に設定します。

現在、Amazon RDS for PostgreSQL はリードレプリカに対する DDL SQL ステートメントの実行をサポートしていません。

Q: リードレプリカを "スタンドアロン" DB インスタンスに昇格できますか?

はい。詳細については、『Amazon RDS User Guide』をご覧ください。

Q: リードレプリカはソース DB インスタンス最新状態と同一に保たれますか?

ソース DB インスタンスの更新は、あらゆる関連したリードレプリカに対して自動的にレプリケーションされます。ただし、サポートされているエンジンの非同期レプリケーションテクノロジーを使うと、様々な理由によりリードレプリカがソース DB インスタンスより遅れることがあります。一般的な理由:

  • ソース DB インスタンスへの書込みの入出力量が設定した値を超えた場合の変更がリードレプリカに適応されることがあります。(この問題は、リードレプリカの処理能力がソース DB インスタンスより低い場合に発生する場合があります)
  • ソース DB インスタンスへの複雑または長期間のトランザクションがリードレプリカのレプリケーションを発生させる
  • ネットワーク パーティションまたはソース DB インスタンス間の待ち時間とリードレプリカ

リードレプリカには、サポートされるエンジンのネイティブなレプリケーションの長所と短所が反映されます。リードレプリカを使う場合は、リードレプリカとそのソース DB インスタンスの間に遅延または「矛盾」が発生する可能性があることを理解していなければなりません。リードレプリカとソース間の遅延が大きくなった場合にどうすべきかに関するガイダンスは、ここをクリックしてください。

Q: アクティブなリードレプリカのステータスはどのように表示されますか?

標準の DescribeDBInstances API を使用すると、デプロイ済みのすべての DB インスタンス(リードレプリカを含む)のリストが返されます。または Amazon RDS Management Console の [DB Instances] タブをクリックします。

Amazon RDS には、リードレプリカがそのソース DB インスタンスからどの程度遅れているかを知るための機能があります。リードレプリカがマスターより遅れている秒数は Amazon CloudWatch メトリックス(「レプリカラグ」)として公開され、AWS マネジメントコンソールまたは Amazon CloudWatch API から閲覧できます。Amazon RDS for MySQL の場合、この情報ソースは、リードレプリカに対して標準の「Show Slave Status」 MySQL コマンドを発行することで表示されるものと同じです。Amazon RDS for PostgreSQL の場合、ソース DB インスタンスで pg_stat_replication ビューを使用して、レプリケーションのメトリックスを調べることができます。

Amazon RDS がリードレプリカのレプリケーション状態をモニタリングします。AWS マネジメントコンソールの [Replication State] フィールドが [Error] に更新された場合は、レプリケーションが何らかの理由で停止していることを示します(例: レプリカに対して試みた DML クエリが、マスターデータベースインスタンスでの更新と競合する場合は、レプリケーションエラーとなることがあります)。MySQL エンジンによってスローされた、対応するエラーの詳細を確認するには、[Replication Error] フィールドを調べます。この情報に基づいて、回復のための適切な措置をとります。レプリケーションの問題のトラブルシューティングの詳細は、Amazon RDS for MySQL または PostgreSQL のユーザーガイド「リードレプリカの問題のトラブルシューティング」セクションを参照してください。

レプリケーションエラーが解決すると、[レプリケーションの状態] は [レプリケーション中] に変化します。

Q: リードレプリカがソース DB インスタンスから大幅に遅れています。どうすればよいですか?

前の質問で説明した通り、リードレプリカとそのソース DB インスタンス間の「矛盾」または遅延は、非同期レプリケーションでも同様です。既存のリードレプリカで、お客様の要求に対して大幅な遅延が発生した場合は、そのリードレプリカを削除してから、同じ DB インスタンス識別子およびソース DB インスタンス識別子を削除したリードレプリカとして使用して同じエンドポイントを持つ新しいリードレプリカを作成します。この時、この再生プロセスは、遅延が小さい場合(5分以下の遅延など)では非生産的であるため、注意して使用する必要があります。(例えば、リードレプリカがそのソース DB インスタンスから大幅に遅延した場合のみに使用する、など)また、レプリカの遅延は、ソース DB インスタンスの定常状態の使用パターンにより自然に成長し、時間と共に収縮することも留意してください。

リードレプリカの DB インスタンスクラスを拡張すると、同じ状態、特に、ソース DB インスタンスのクラスがリードレプリカ DB インスタンスのクラスより大きい場合のレプリケーションラグを減少します。ただし、リードレプリカは、すべての状況下で機能するとは限りません。また、リードレプリカを作成してから絶対にそのソースに追いつけない、またはお客様のユースケース要件を満たす状態から大幅に遅れてしまうシナリオおよび使用パターンがあります。

Q: 使用するソース DB インスタンスの処理およびストレージ容量を拡張しました。それに伴い、関連するリードレプリカのリソースも拡張すべきですか?

レプリケーションが正しく機能するためには、リードレプリカに可能な限り多くの対応するソース DB インスタンスのコンピュートとストレージリソースを持たせてください。そうしないと、レプリケーションラグが増加する可能性が増える、またはリードレプリカがレプリケーションした更新を格納するスペースが足りなくなります。

Q: Amazon RDS for MySQL の DB インスタンスと行ベースのレプリケーションを使うリードレプリカの間のレプリケーションを設定できますか?

MySQL バージョン 5.6 以降では、バイナリログフォーマットを行ベースに設定できます。デフォルトでは、レプリケーションは混合フォーマット (行ベースと記述ベースのレプリケーション) で設定されます。これは、ほとんどのユースケースを満たすことができます。MySQL のドキュメントに、混合フォーマットと行ベースのレプリケーションの違いに関する詳細情報が記載されています。

Q: DB スナップショットまたは自動化バックアップはリードレプリカに対して実行できますか?

いいえ。ソース DB インスタンスではなくリードレプリカのバックアップを取ることでデータベースの書込み能力を強化したい場合は、DB インスタンスを Multi-AZ 配備として実行することにより、同じ目的が達成できます。バックアップは、Multi-AZ スタンバイから起動され、可用性の影響を最小限にすることができます。

Q: リードレプリカはどのように削除しますか? ソース DB インスタンスを削除すると自動削除されますか?

AWS マネジメントコンソールで数回クリックするか、DB インスタンスの識別子を DeleteDBInstance API に渡すと、簡単にリードレプリカを削除できます。

Amazon RDS for MySQL のリードレプリカは、アクティブ状態のままとなり、対応するソース DB インスタンスが削除された後も読み込みトラフィックを受け入れ続けます。ソース DB インスタンスと同時にリードレプリカも削除する場合は、DeleteDBInstance API または AWS マネジメントコンソールを使って明示的に行う必要があります。

リードレプリカがある Amazon RDS for PostgreSQL の DB インスタンスを削除すると、すべてのリードレプリカがスタンドアロン DB インスタンスに昇格されて、読み込みトラフィックと書き込みトラフィックの両方を受け付けることができるようになります。新しく昇格された DB インスタンスは、相互に独立して動作します。元のソース DB インスタンスに加えてこれらの DB インスタンスを削除する場合は、DeleteDBInstance API または AWS マネジメントコンソールを使って明示的に行う必要があります。

Q: データベースインスタンスのイベントログに直接アクセスして自分のレプリケーションを管理できますか?

Amazon RDS for MySQL は、現在データベースインスタンスのバイナリログへのアクセスを提供していません。同様に、Amazon RDS for PostgreSQL は、現在データベースインスタンスの WAL ファイルへのアクセスを提供していません。

Q: リードレプリカの価格はいくらですか? 請求はいつ開始され、いつ終了しますか?

リードレプリカは、標準 DB インスタンスと同じ料金で請求されます。DB インスタンスの請求に関する情報については、この FAQ をご参照ください。標準 DB インスタンスと同様、リードインスタンスに対する "DB インスタンス時間" ごとの料金は、リードレプリカの DB インスタンスクラスで決まります。最新の料金情報については、Amazon RDS 詳細ページを参照してください。ソース DB インスタンスとリードレプリカ間のデータレプリケーションに発生したデータ転送に対しては請求されません。

リードレプリカの請求は、リードレプリカを作成(一覧のステータスが「アクティブ」になるなど)してから開始します。リードレプリカは、削除するコマンドを発行するまで標準 Amazon RDS DB インスタンスの時間料金で請求されます。

Q: リードレプリカのサポートは、その機能をサポートする Amazon RDS エンジン間でどのように異なりますか?

Amazon RDS for PostgreSQL および MySQL のリードレプリカは、読み込み負荷の高いデータベースワークロードに単一 DB インスタンスの能力が対応しきれない場合、弾力的にスケールアウトできます。これらはエンジンのネイティブ機能を使用するので、実装には同じ部分と異なる部分があります。詳細については次の表を参照してください。

機能 PostgreSQL MySQL
ソース DB インスタンスごとに許される最大リードレプリカ数
5 5
レプリケーション方法 非同期
物理
非同期
論理
リードレプリカをサポートするために自動バックアップを有効にする必要があるか? はい はい
リードレプリカを使用できるエンジンのバージョン 9.3.5 以降 5.6 以降
新しいスタンドアロン DB インスタンスへのリードレプリカの昇格 サポート対象 サポート対象
リードレプリカでのインデックスの作成 現在は非サポート サポート対象
リードレプリカのバックアップの作成 現在は非サポート サポート対象
リードレプリカのチェーン
(つまり、リードレプリカのリードレプリカ)
現在は非サポート サポート対象
リージョン間のリードレプリカ サポート対象 サポート対象

Amazon Aurora エンジンでのレプリケーションサポートの詳細については、Amazon RDS for Aurora のよくある質問を参照してください。

Q: RDS の拡張モニタリングとは何ですか?

A: RDS の拡張モニタリングによって、RDS インスタンスの状況をより詳細に可視化できます。RDS インスタンスの [拡張モニタリング] オプションを有効にし、詳細度を設定すれば、指定された間隔でオペレーティングシステムの重要なメトリックスとプロセス情報が拡張モニタリングによって収集されます。

Q: 拡張モニタリングではどのようなメトリックスとプロセスをモニタリングできますか?

A: 拡張モニタリングでは、特に CPU、メモリ、ファイルシステム、およびディスク I/O といった、RDS インスタンスのシステムレベルのメトリックスが収集されます。メトリックスのリストはここからご覧ください。

Q: 拡張モニタリングではどのようなエンジンがサポートされていますか?

拡張モニタリングでは、すべての RDS データベースエンジンがサポートされています。

Q: 拡張モニタリングではどのようなインスタンスタイプがサポートされていますか?

A: 拡張モニタリングでは、t1.micro と m1.small を除くすべてのインスタンスタイプがサポートされています。このソフトウェアは、少量の CPU、メモリ、および I/O を消費します。一般的な目的でのモニタリングでは、ミディアム以上の規模のインスタンスに対して高い詳細度を有効にすることをお勧めします。拡張モニタリングはデフォルトでオフに設定されています。そのまま無効にしておくことも、必要なときに詳細度を変更することも可能です。

Q: RDS ダッシュボードにはどのような情報が表示されますか?

A: RDS インスタンスについてのすべてのシステムメトリックスとプロセス情報を、コンソールのグラフィック形式で見ることができます。各インスタンスについてモニタリングするメトリックスを管理し、必要に応じてダッシュボードをカスタマイズすることができます。

Q: RDS アカウント内のすべてのインスタンスの詳細度が同じになるのですか?

A: いいえ。RDS アカウント内のそれぞれのインスタンスに、個別に詳細度を設定できます。どのインスタンスに対して拡張モニタリングを有効にするかも選択でき、必要なときにはいつでも各インスタンスに対する詳細度を変更できます。

Q: RDS コンソールではメトリックスの履歴をどれほど前までさかのぼれますか?

A: すべてのメトリックスのパフォーマンス値を最大 1 時間前まで参照できます。詳細度は設定に基づいて最高 1 秒間です。

Q: RDS 拡張モニタリングで生成されたメトリックスを CloudWatch 内でどのように視覚化できますか?

A: RDS 拡張モニタリングからのメトリックスは、CloudWatch Logs アカウントに配信されます。CloudWatch 内で、CloudWatch Logs からメトリックスフィルターを作成し、CloudWatch ダッシュボードに表示できます。詳細については、Amazon CloudWatch のページにアクセスしてください。

Q: RDS コンソールダッシュボードではなく CloudWatch を使用するのはどのようなケースですか?

A: RDS コンソールダッシュボードで利用できる履歴データよりも前のデータがが必要な場合、CloudWatch の使用が必要です。RDS インスタンスを CloudWatch でモニタリングすることで、AWS スタック全体の状況について 1 つの場所で診断できます。現在のところ、CloudWatch でサポートされている詳細度は最高 1 分間隔で、それよりも詳細度の短い場合は平均値になります。

Q: 特定のメトリックスに基づいてアラームと通知をセットアップすることはできますか?

A: はい。アラームの状態が変化したときに通知を送信するアラームを CloudWatch に作成できます。アラームは、指定期間にわたって単一のメトリックスを監視し、その値と複数期間に対するしきい値との比較結果に基づいて 1 つ以上のアクションを実行します。CloudWatch アラームの詳細については、Amazon CloudWatch 開発者用ガイドをご覧ください。

Q: 現在使用中のツールに拡張モニタリングを統合するにはどのようにすればよいですか?

A: RDS 拡張モニタリングでは、CloudWatch Logs アカウントに配信される JSON ペイロードとして形成されるメトリックス一式が提供されています。JSON ペイロードは、その RDS インスタンスに最後に設定された詳細度で配信されます。

サードパーティー製のダッシュボードやアプリケーションでそれらのメトリックスを利用するには、2 種類の方法があります。モニタリングツールでは、CloudWatch Logs Subscriptions を使用することで、メトリックスについてリアルタイムに近いフィードをセットアップできます。別の方法として、CloudWatch Logs のフィルターを使用してメトリックスを CloudWatch にブリッジし、アプリケーションを CloudWatch と統合することもできます。詳細については、Amazon CloudWatch のドキュメントを参照してください。

Q: 履歴データはどのようにしてし消去できますか?

A: 拡張モニタリングでは JSON ペイロードが CloudWatch Logs アカウントのログに配信されます。このため、他の CloudWatch Logs ストリームと同じように保持期間を制御できます。CloudWatch Logs では、拡張モニタリングのデフォルト保持期間が 30 日間に設定されています。保持期間の変更方法の詳細については、Amazon CloudWatch 開発者ガイドをご覧ください。

Q: 拡張モニタリングを利用すると、毎月の料金にどのような変化が発生しますか?

A: メトリックスは CloudWatch Logs に取り込まれるため、CloudWatch Logs 無料利用枠を超過した部分の料金については、CloudWatch Logs のデータ転送レートおよびストレージレートに基づいて決まります。料金の詳細については、こちらをご覧ください。ある RDS インスタンスについて転送される情報の量は、拡張モニタリング機能に設定された詳細度に直接比例します。管理者はアカウント内の各インスタンスの詳細度を個別に設定して、コストを管理できます。

1 つのインスタンスに対する拡張モニタリングによって CloudWatch Logs に取り込まれるデータ量の概算を以下に示します。

詳細度

60 秒

30 秒

15 秒

10 秒

5 秒

1 秒

CloudWatch Logs に取り込まれるデータ* (GB/月)

0.27

0.53

1.07

1.61

3.21

16.07

Q: Amazon RDS DB インスタンスの MySQL バージョンを新しくサポートされたバージョンにアップグレードするかどうか、およびその実行時期をコントロールできますか?

Amazon RDS を使うと、お客様の DB インスタンス(MySQ など)を強化するリレーショナルデータベースソフトウェアを Amazon RDS でサポートする新しいバージョンにアップグレードすべきか、およびそのタイミングをコントロールします。 これにより、特定の SQL バージョンとの互換性を維持する、プロダクションに展開する前にアプリケーションで新しいバージョンをテストする、ユーザー独自の条件とタイムラインでバージョンのアップグレードを実行する柔軟性を提供します。

お客様が指定しない限り、お客様の DB インスタンスは、新しい MySQL マイナーバージョン(Amazon RDS がサポートするバージョン)に自動的にアップグレードされます。このパッチは、予定されているメンテナンスウィンドウで行われ、事前に Amazon RDS フォーラムで告知されます。マルチ AZ インスタンスであっても DB エンジンバージョンのアップグレードにあたってはダウンタイムが発生するため、お客様が対応を計画できるようにアップグレードをスケジュールしています。自動バージョンアップグレードをオフにしたい場合は、AutoMinorVersionUpgrade パラメータを「false」に設定します。メジャーバージョンアップグレードには互換性のリスクが伴います。したがって、自動的には行われません。ご自分の責任で実施してください。

このデータベースソフトウェアのパッチは、管理面でのバージョンアップグレードが行われますが、Amazon RDS に対するアプリケーションのパッチを手動で行う必要もあります。バージョン管理について詳しく知るには、該当する FAQ をご覧ください。また、当社の開発者ガイドもご参照ください。

DB Engine バージョン管理機能では、パッチ発生を可能な限りお客様が管理できるようにしていますが、データベースソフトウェアにおいて重要なセキュリティ脆弱性が発生した場合は、お客様に代わって Amazon RDS が DB インスタンスをパッチする可能性があります。

Q: サポートされている MySQL バージョンのうち、DB インスタンスで実行するものをどのように指定しますか?

ユーザーは、CreateDBInstance API を使って新しい DB インスタンスを作成する時に現在サポートされているバージョン(マイナー、またはメジャー)ならどれでも指定することができます。作成時に希望するバージョンを EngineVersion パラメータに渡します。バージョンを指定しない場合は、Amazon RDS がデフォルトのバージョン(通常は最新のバージョン)を指定します。マイナーバージョンではなく、メジャーバージョン(MySQL 5.1など)を指定した場合は、Amazon RDS は、お客様が指定したメジャーバージョンの最新リリースをデフォルトに設定します。サポートされているバージョンの一覧と新しく作成される DB インスタンスのデフォルトを見るには、DescribeDBEngineVersions API を使います。

AutoMinorVersionUpgrade パラメータを false に設定して自動アップグレードを行わないようにして、手動でサポートされているマイナーバージョンまたはメジャーバージョンへのアップグレードを実行したい場合は、ModifyDBInstance API を使います。EngineVersion パラメータにアップグレードしたいバージョンを指定します。これにより、アップグレードを即時に実行する(ApplyImmediately フラグが true に設定されている場合)、または DB インスタンスの次の予定メンテナンスウィンドウで実行されます。

Q: アップグレード前に自分の DB インスタンスを新しいバージョンでテストできますか?

はい。これは次の手順で行います。まず、既存の DB インスタンスの DB スナップショットを作成、DB スナップショットから新しい DB インスタンスをリストア、その後その新しい DB インスタンスに対してバージョンアップグレードを実施します。その後で、オリジナルの DB インスタンスをアップグレードするかどうかを決める前に、コピーした DB インスタンスで安全性を確かめることができます。

Q: Amazon RDS はどのように "メジャー" および "マイナー" バージョンリリースを区別しますか?

MySQL においてバージョン番号は以下のように整理されています。

MySQL バージョン = X.Y.Z

X = メジャーバージョン、Y = リリースレベル、Z = リリースシリーズ内のバージョン番号

Amazon RDS では、メジャーバージョンまたはリリースレベルが変更されると、バージョン変更がメジャーであると判断されます。例: 5.1.X -> 5.5.X. の場合。同じリリースでバージョン番号が変更されていれば、バージョン変更は、マイナーであると判断します。例: 5.1.45 -> 5.1.49。

現在、Amazon RDS は、MySQL メジャーバージョン MySQL 5.1、5.5 および 5.6 をサポートしています。今後もさらに多くの MySQL メジャーバージョンのサポートを予定しています。

Q: Amazon RDS は、新しい MySQL バージョンのサポートおよび現在サポートされている MySQL バージョンの廃止に関するガイドラインを提供しますか?

はい。このページの Amazon RDS バージョニングに関するガイドラインをご覧ください。

Q: MySQL を別のメジャーバージョンにアップグレードするにはどのように行いますか?

Amazon RDS ユーザーガイドの「DB インスタンスのアップグレード」の項を参照してください。

Q: MySQL の Amazon RDS はどのストレージエンジンをサポートしていますか?

MySQL の Amazon RDS における特定時点の復元およびスナップショット復元機能には、クラッシュからの回復可能なストレージエンジンが必要で、InnoDB ストレージエンジンのみがサポートされています。MySQL は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、MyISAM ストレージエンジンは、信頼性の高いクラッシュ回復をサポートしておらず、MySQL がクラッシュ後に再起動した時、特定時点の復元およびスナップショット復元が意図通りに機能せず、データが紛失または破損する可能性があります。それでも、Amazon RDS で MyISAM を使用する場合は、このステップに従ってください。スナップショット復元機能において特定のシナリオで役立つ可能性があります。

既存の MyISAM テーブルを InnoDB テーブルに変換したい場合は、alter table コマンド (たとえば、alter table TABLE_NAME engine=innodb;) を使用できます。MyISAM と InnoDB の長所と短所は異なっているため、アプリケーションで切り替えた際の影響を切り替え前に十分に評価しておく必要があることを念頭に置いてください。

フェデレーティッドストレージエンジンは、現在 MySQL の Amazon RDS ではサポートされていません。

Q: Oracle 用 Amazon RDS では、どのようなタイプのライセンスオプションを利用できますか?

Oracle 用 Amazon RDS を使用するために利用できるライセンスオプションには 2 つのタイプがあります。

  • 自分のライセンス使用(BYOL): このライセンスモデルでは、既存の Oracle データベースのライセンスを使用して Amazon RDS で Oracle を実行することができます。BYOL モデルの DB インスタンスを実行するには、DB インスタンスのクラスと実行する Oracle Database のエディションに適切な Oracle Database のライセンス(ソフトウェア更新のライセンスとサポート付き)を持っている必要があります。また、クラウドコンピューティング環境での Oracle Database ソフトウェアのライセンス化に関する Oracle のポリシーに従う必要があります。Amazon EC2 環境における DB インスタンスおよび Amazon EC2 用の Oracle のライセンスポリシーはここでご覧になれます。
  • ライセンス込み: 「ライセンス込み」サービスモデルでは、Oracle のライセンスを個別に購入する必要はありません。Oracle データベースのソフトウェアは、AWS によってライセンス化されています。"ライセンス込み" 料金には、ソフトウェア、ハードウェアリソース、および Amazon RDS 管理機能の使用料金が含まれています。

Q: Amazon RDS for Oracle では、Oracle データベースのどのエディションを利用できますか?

Amazon RDS は現在、下の各ライセンスモデルにおいて、以下の Oracle データベースのエディションをサポートしています。

  • BYOL: Standard Edition Two (SE2)、Standard Edition One (SE1)、Standard Edition (SE)、および Enterprise Edition (EE)
  • ライセンス込み: スタンダードエディション1(SE1)

Q: Amazon RDS for Oracle のライセンスポリシーはどのようなものですか?

  • BYOL: BYOL モデルの DB インスタンスを実行するには、DB インスタンスクラスおよび実行する Oracle データベースのエディション用の適切な Oracle データベースのライセンス(ソフトウェアアップデートのライセンスおよびサポート付き)を持っている必要があります。また、クラウドコンピューティング環境での Oracle データベースのソフトウェアのライセンス化に関する Oracle のポリシーに従う必要があります。Amazon EC2 環境における DB インスタンスおよび Amazon EC2 用の Oracle のライセンスポリシーはここでご覧になれます。
  • ライセンス込み: 「ライセンス込み」サービスモデルでは、Oracle のライセンスを個別に購入する必要はありません。Oracle データベースのソフトウェアは、AWS によってライセンス化されています。

Q: Amazon RDS for Oracle はどのようにサポートされていますか?

  • BYOL: このモデルでは、アクティブな Oracle サポートアカウントを継続してご使用いただけます。Oracle データベースの特定のサービスリクエストに関しては、直接 Oracle にご連絡ください。アクティブな AWS Premium Support のアカウントをお持ちの場合、Amazon RDS 固有の問題については、AWS Premium Support にご連絡ください。Amazon Web Services と Oracle には、両方の組織からの援助が必要な場合のために、マルチベンダーサポートプロセスがあります。
  • ライセンス込み: このモデルでは、アクティブな AWS Premium Supportのアカウントをお持ちの場合は、Amazon RDS と Oracle データベース両方の特定のサービスリクエストに関しては、AWS Premium Supportにお問い合わせください。

Q: DB インスタンスのライセンスオプションを変更 (例えば、「BYOL」から「ライセンス込み」に) できますか?

はい、ライセンスのオプションは変更することができます。ただし、最後のスナップショットで現在の DB インスタンスを削除し、必要な新しいライセンスオプションを指定して、そのスナップショットから新しい DB インスタンスを作成する必要があります。

Q: Oracle 用にどのような Amazon RDS DB Engine Version のバージョンがあり、どのように Oracle Patch Set に関連付けられますか?

Oracle のコンテキストでは、Amazon RDS DB Engine バージョンは次のように構成されています:

Oracle 用 DB Engine バージョン= X.Y.Z

X=メジャーバージョン(例: 11.2)、Y=リリースレベル(例: 0.2)、Z=リリースシリーズのバージョン番号(例: V2)。例えば、Oracle 用 DB Engine バージョンは 11.2.0.2.v2 のようになります。

Oracle は、四半期ごとにサポートされているリリースレベルでデータベースパッチセット更新(PSU)をリリースします(例: 11.2.0.2.1)。PSU には、セキュリティの修正と Oracle が推奨する追加のセキュリティ関連以外の修正が含まれています。

Amazon RDS DB Engine バージョンは、ベースラインとして指定された PSU で構築されており、それ以外の追加の修正が含まれている場合があります。

Amazon RDS では、メジャーバージョンまたはリリースレベルが変更されると、バージョン変更がメジャーであると判断されます。例: 11.2.0.2.Z -> 11.2.0.4.Z の場合。同じリリースでバージョン番号が変更されていれば、バージョン変更は、マイナーであると判断します。例: 11.2.0.2.v2 -> 11.2.0.2.v3 の場合。

現時点では、Amazon RDS はメジャーバージョン 11.2(11g リリース 2)および 12c をサポートしています。将来的には、追加のメジャーバージョンをサポートする予定です。

Q: Oracle 用の DB Engine バージョンのパッチセットはどのような構成になっていますか?

Oracle の各 DB Engine バージョンのパッチセットの構成に関する詳細については、Amazon RDS User Guideをご参照ください。

Q: DB インスタンスを Oracle の新しい DB Engine バージョンにアップグレードする時期をコントロールできますか?

Amazon RDS では、DB インスタンスを駆動しているリレーショナルデータベースソフトウェアを Amazon RDS でサポートされている新しいバージョンにアップグレードする時期をコントロールできます。これにより、特定の Oracle データベースバージョンとの互換性を維持する、プロダクションに展開する前にアプリケーションで新しいバージョンをお客様のアプリケーションでテストする、独自の条件とタイムラインでバージョンのアップグレードを実行する柔軟性が提供されます。

指定がない限り、お客様の DB インスタンスは、Amazon RDS のマイナーバージョンアップグレードのスケジュールに従って、新しい DB Engine バージョンに自動的にアップグレードされます。このパッチは、予定されているメンテナンスウィンドウで行われ、事前に Amazon RDS フォーラムで告知されます。バージョンの自動アップグレードをオフにしたい場合は、[マイナーバージョンの自動アップグレード] フィールドを [いいえ] に設定してください。メジャーバージョンアップグレードには互換性のリスクが伴います。したがって、自動的には行われません。ご自分の責任で実施してください。

このデータベースソフトウェアのパッチは、管理面でのバージョンアップグレードが行われますが、Amazon RDS に対するアプリケーションのパッチを手動で行う必要もあります。バージョン管理について詳しく知るには、該当する FAQ をご覧ください。また、当社の開発者ガイドもご参照ください。

DB Engine バージョン管理機能では、パッチ発生を可能な限りお客様が管理できるようにしていますが、データベースソフトウェアにおいて重要なセキュリティ脆弱性が発生した場合は、お客様に代わって Amazon RDS が DB インスタンスをパッチする可能性があります。

「ライセンス込み」モデルでは、「ソフトウェアライセンスの更新」コストは、Oracle データベースのソフトウェア更新へのアクセスを可能にし、時間単位の価格に埋め込まれています。しかし BYOL モデルでは、Oracle からの「ソフトウェア更新のライセンスとサポート」があり、Oracle データベースに Amazon RDS を使用します。

Q: サポートされている中でどの DB Engine バージョンを DB インスタンスで実行するかはどのように指定しますか?

AWS マネジメントコンソールまたは CreateDBInstance API の「Launch DB Instance」オプションを介して新しい DB インスタンスを作成する際に、現在サポートされているすべてのバージョンを(マイナーおよび/またはメジャー)を指定することができます。

AutoMinorVersionUpgrade パラメータを false に設定して自動アップグレードを行わないようにして、手動でサポートされているマイナーバージョンまたはメジャーバージョンへのアップグレードを実行したい場合は、ModifyDBInstance API を使います。EngineVersion パラメータにアップグレードしたいバージョンを指定します。アップグレードはお客様の代わりに即時に実行される(「ApplyImmediately」フラグが設定されている場合)か、または DB インスタンスの次の予定されているメンテナンスウィンドウで実行されます。

Q: アップグレード前に自分の DB インスタンスを新しいバージョンでテストできますか?

はい。これは次の手順で行います。まず、既存の DB インスタンスの DB スナップショットを作成、DB スナップショットから新しい DB インスタンスをリストア、その後その新しい DB インスタンスに対してバージョンアップグレードを実施します。その後で、オリジナルの DB インスタンスをアップグレードするかどうかを決める前に、コピーした DB インスタンスで安全性を確かめることができます。

Q: Amazon RDS では、Oracle の新たな DB Engine バージョンをサポートするガイドラインや、現在サポートされている Oracle の DB Engine バージョンの廃止に関するガイドラインを提供していますか?

はい。このページの Amazon RDS バージョニングに関するガイドラインをご覧ください。

Q: DB インスタンスはスケーリングすることができますか?

BYOL モデルでは、Oracle のライセンスの条件に従って、DB インスタンスを縮小・拡張することができます。

ライセンス込みモデルでは、Oracle を実行している DB インスタンスは、いつでも縮小・拡張することができ、各 DB インスタンスのクラスの存続している時間単位の料金の対象となります。

リザーブド DB インスタンスの縮小・拡張の影響の詳細については、当社のリザーブド DB インスタンス FAQ をご参照ください。

Q: DB インスタンスで実行している Oracle エディションを変更 (例えば、Oracle 11g R2 SE1 から EE へ) できますか?

BYOL モデルでは、実行する予定の DB インスタンスのエディションおよびクラスに適切な未使用の Oracle ライセンスを保有している限り、1つの Oracle ソフトウェアのエディションから別のエディションに移行することができます。エディションを変更してデータを保持するには、実行中の DB インスタンスのスナップショットを取り、そのスナップショットから希望するエディションの新しい DB インスタンスを作成する必要があります。適切な Oracle データベースのライセンスを持っていて、それを実行し続けることを希望する場合を除き、その後、古い DB インスタンスは削除します。

ライセンス込みモデルの場合は、現在、Oracle のスタンダードエディション1のみがサポートされています。

Q: Amazon RDS は、Oracle のどのような種類のレプリケーションをサポートしていますか?

Amazon RDS for Oracle では、マルチ AZ 配置 は「ライセンス込み」と「自分のライセンス使用(BYOL)」のどちらのライセンシングモデルでもサポートされます。

Q: Amazon RDS では Oracle Data Guard がマルチ AZ 配置に対して使用されますか?

Oracle Data Guard は、Oracle Database Enterprise Edition で利用できる高可用性機能です。Amazon RDS では、現時点では別の同期レプリケーションテクノロジーと自動フェイルオーバー機能が Oracle DB インスタンスの Multi-AZ 配備に対して使用されています。Multi-AZ 配備は、Amazon RDS でサポートされるすべての Oracle データベースエディションでご利用いただけます。

Q: マルチ AZ 配置を Oracle DB インスタンスに対して「BYOL」ライセンシングモデルで使用する場合に、追加ライセンスは必要ですか?

はい。Multi-AZ 配備に必要なライセンスの数は、対応する Single-AZ 配備に必要なライセンスの2倍になると考えられます。これは、スタンバイ DB インスタンスの分も含まれるからです。ただし、Oracle ソフトウェア使用許諾契約書を確認のうえ、Oracle のライセンシングポリシーに従ってください。

Q: Oracle RAC は Amazon RDS でサポートされていますか?

いいえ、RAC は現在サポートされていません。

Q: Amazon RDS では、どのエンタープライズエディションのオプションがサポートされていますか?

以下のエンタープライズエディションのオプションが、現在 BYOL モデルでサポートされています。

  • 高度なセキュリティ(Transparent Data Encryption、Native Network Encryption)
  • パーティション
  • 管理パック(診断、調整)
  • 高度な圧縮
  • トータルリコール

Q: どの文字セットが Amazon RDS for Oracle でサポートされますか?

Amazon RDS でサポートされるのは、Oracle の「推奨する ASCII データベース・キャラクタ・セット」リストにある30種の文字セットです。文字セットの指定は、新しいデータベースインスタンスを作成するときに行います。これは省略可能であり、デフォルトの文字セットは AL32UTF8 です。詳細については、Amazon RDS のドキュメントを参照してください。

Q: Amazon RDS で Transparent Data Encryption を使用する場合、Oracle Wallet とマスター暗号化キーは誰が管理しますか?

DB インスタンス用の Oracle Wallet とマスター暗号化キーは Amazon RDS によって管理されます。

Amazon RDS が Oracle Database の特定の機能をサポートするかどうかは、どうすればわかりますか?

Oracle データベースはいくつかの機能をサポートしていますが、それは実行する Oracle データベースのエディションによって異なります。Amazon RDS が現在サポートしている Oracle の機能については、Amazon RDS ユーザーガイドをご参照ください。