Q: Amazon Aurora とは何ですか?

Amazon Aurora はリレーショナルデータベースエンジンで、高パフォーマンスの商業用データベースの速度や信頼性と、オープンソースデータベースの簡易性やコスト効率性を兼ね備えています。Amazon Aurora MySQL では、ほとんどの MySQL アプリケーションに何の変更を加えることなく、MySQL の最大 5 倍のパフォーマンスが実現されます。同様に Amazon Aurora PostgreSQL では PostgreSQL の最大 3 倍のパフォーマンスが実現されます。Amazon RDS はお客様の Amazon Aurora データベースを管理し、プロビジョニング、パッチの適用、バックアップ、リカバリ、障害検出、リペアなどの時間のかかるタスクを処理します。使用する各 Amazon Aurora データベースインスタンスに対して単純な月額方式の料金が発生します。最低利用料金や長期契約は必要ありません。

Q: 「MySQL 互換」とはどのような意味ですか?

これは、現在お客様が MySQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Amazon Aurora データベースエンジンは InnoDB ストレージエンジンを使用することで MySQL 5.6 と強い互換性があります。MyISAM ストレージエンジンなど、特定の MySQL の特徴は Amazon Aurora で使用できません。

Q: 「PostgreSQL 互換」とはどのような意味ですか?

これは、現在お客様が PostgreSQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Amazon Aurora データベースエンジンは、PostgreSQL 9.6 との強い互換性を持つよう設計され、RDS for PostgreSQL 9.6 でサポートされる PostgreSQL 拡張機能と同じセットをサポートしているため、両エンジン間でのアプリケーションの移行は容易です。 

Q: Amazon Aurora を試用するにはどうすればいいですか?

Amazon Aurora を試用するには、AWS コンソールにサインインし、[Database] カテゴリの [RDS] を選択して、データベースエンジンとして Amazon Aurora を選択します。

Q: Amazon Aurora の料金はどのくらいですか?

最新情報については、こちらの料金表ページをご覧ください。

Q: Amazon Aurora はデータベースの各単位を 3 つのアベイラビリティーゾーンにかけて 6 個レプリケーションするということですが、実際のストレージ料金は、料金表ページに書かれている料金の 3 倍または 6 倍になるということですか?

いいえ。Amazon Aurora のレプリケーションは料金に含まれています。料金はデータベースがデータベースレイヤーで消費したストレージに応じて発生します。Amazon Aurora の仮想化ストレージレイヤーで消費したストレージではありません。

Q: Amazon Aurora はどの AWS リージョンで使用できますか?

リージョンと料金の最新情報については、こちらの料金表ページをご覧ください。

Q: MySQL から Amazon Aurora に移行するには、またその逆をするにはどうすればよいですか?

これには複数の方法があります。標準の mysqldump ユーティリティを使用して MySQL からデータをエクスポートし、mysqlimport ユーティリティを使用して Amazon Aurora にデータをインポートします。同じ方法でこの逆も可能です。また、Amazon RDS の DB スナップショットの移行機能を利用して、AWS マネジメントコンソールで RDS MySQL DB スナップショットを Amazon Aurora に移行します。ほとんどの場合移行は 1 時間以内に完了しますが、データの形式およびデータセットのサイズにより時間が異なります。詳細については、Amazon Aurora のデータのエクスポートおよびインポートに関するガイドをご覧ください。

Q: PostgreSQL から Amazon Aurora に、またはその逆に移行するにはどうすればよいですか?

これには複数の方法があります。標準の pg_dump ユーティリティを使用して PostgreSQL からデータをエクスポートし、pg_restore ユーティリティを使用して Amazon Aurora にデータをインポートします。同じ方法でこの逆も可能です。また、Amazon RDS の DB スナップショットの移行機能を利用して、AWS マネジメントコンソールで RDS PostgreSQL 9.6 DB スナップショットを Amazon Aurora に移行します。ほとんどの場合移行は 1 時間以内に完了しますが、データの形式およびデータセットのサイズにより時間が異なります。詳細については、Amazon Aurora のデータのエクスポートおよびインポートに関するガイドをご覧ください。

Q: Amazon Aurora は AWS の無料利用枠で利用できますか?

現時点では利用できません。Amazon RDS の AWS 無料利用枠はマイクロ DB インスタンスに向けたオプションを提供していますが、Amazon Aurora は現時点ではマイクロ DB インスタンスをサポートしていません。最新情報については、こちらの料金表ページをご覧ください。

Q: IOs in Amazon Aurora とは何ですか? どのように計算されますか?

IOs は SSD ベースの仮想ストレージレイヤーに対して Aurora データベースエンジンによって実行される入力/出力オペレーションです。各データベースページ読み込みオペレーションは 1 IO とカウントされます。Aurora データベースエンジンは、バッファキャッシュ内に存在しないデータベースページを取得するためにストレージレイヤーに対して読み取りを発行します。各データベースページは、Aurora MySQL では 16 KB、Aurora PostgreSQL では 8 KB です。

Aurora はコストを削減し、リソースが読み込み/書き込みトラフィックを提供するために利用可能になるように不要な IO オペレーションを排除するよう設計されていました。書き込み IOs はストレージレイヤーが耐久性の高い書き込みを実現するためにトランザクションログレコードをプッシュする時にのみ消費します。書き込み IOs は 4 KB 単位でカウントされます。例えば、トランザクションログレコードが 1024 バイトの場合、1 IO オペレーションとカウントされます。ただし、同時書き込みオペレーションでトランザクションログが 4 KB 未満の場合、I/O 消費を最適化するため Aurora データベースエンジンによってまとめてバッチ処理されます。従来のデータベースエンジンと違い、Amazon Aurora はストレージレイヤーに更新データベースページをプッシュせず、結果的に I/O 消費を節約しています。

AWS コンソールで Aurora インスタンスがどれほど IOs を消費しているか確認できます。IO 消費を確認するには、RDS セクションのコンソールでインスタンスのリストから Aurora インスタンスを選び、モニタリングセクションの「課金読み取りオペレーション」と「課金書き込みオペレーション」メトリクスを確認します。

Q: Amazon Aurora PostgreSQL を使用するためにクライアントドライバーの変更が必要ですか?

いいえ、Amazon Aurora は標準の PostgreSQL データベースドライバーで動作します。

Q: 「MySQL の 5 倍のパフォーマンス」とはどんな意味ですか?

Amazon Aurora は、データベースワークロード用の SSD ベースの仮想化ストレージレイヤーとデータベースエンジンを完全に統合し、ストレージシステムに対する書き込みを削減し、ロックの競合を最小化し、データベースのプロセススレッドを排除することで、MySQL と比較して大幅に高いパフォーマンスを提供します。SysBench による r3.8xlarge インスタンスのテストの結果、Amazon Aurora は 500,000 SELECT/秒および 100,000 UPDATE/秒のパフォーマンスを示しました。これは同じハードウェアで実行する MySQL の 5 倍のパフォーマンスです。このベンチマークとその再現方法の詳細な手順は、Amazon Aurora MySQL パフォーマンスベンチマークに関するガイドに記載されています。

Q: 「PostgreSQL の 3 倍のパフォーマンス」とはどんな意味ですか?

Amazon Aurora では、データベースワークロード用の SSD ベースの仮想化ストレージレイヤーとデータベースエンジンを完全に統合し、ストレージシステムに対する書き込みを削減し、ロックの競合を最小化し、データベースのプロセススレッドを排除することで、PostgreSQL と比較して大幅に高いパフォーマンスが実現されています。SysBench による r4.16xlarge インスタンスのテストの結果、Amazon Aurora は SELECT/秒および UPDATE/秒で、同じハードウェアで実行する PostgreSQL の 3 倍のパフォーマンスを示しました。このベンチマークとその再現方法の詳細な手順は、Amazon Aurora PostgreSQL のパフォーマンスベンチマークに関するガイドに記載されています。

Q: Amazon Aurora MySQL でデータベースのワークロードを最適化するにはどうすればよいですか?

Amazon Aurora は MySQL 5.6 と互換性を持つように設計されているため、既存の MySQL アプリケーションおよびツールを修正することなく実行できます。一方で、Amazon Aurora が MySQL よりも優れている領域の 1 つが、ワークロードの同時実行数が非常に多い場合です。Amazon Aurora でワークロードのスループットを最大化するには、多数のクエリやトランザクションを同時実行するようにアプリケーションを作成することをお勧めします。

Q: Amazon Aurora PostgreSQL でデータベースのワークロードを最適化するにはどうすればよいですか?

Amazon Aurora は PostgreSQL 9.6 と互換性を持つように設計されているため、既存の PostgreSQL アプリケーションおよびツールを修正することなく実行できます。一方で、Amazon Aurora が PostgreSQL よりも優れている領域の 1 つが、ワークロードの同時実行数が非常に多い場合です。Amazon Aurora でワークロードのスループットを最大化するには、多数のクエリやトランザクションを同時実行するようにアプリケーションを作成することをお勧めします。

Q: Amazon Aurora データベースのストレージの下限と上限はどれくらいですか?

ストレージの下限は 10 GB です。データベースの使用量に応じて、Amazon Aurora ストレージは 10 GB 単位で最大 64 TB まで、データベースのパフォーマンスに影響を与えずに拡張されます。事前にストレージをプロビジョニングする必要はありません。

Q: Amazon Aurora DB インスタンスに関連するコンピューティングリソースはどのようにスケールしますか?

DB インスタンスに割り当てるコンピューティングリソースは、AWS マネジメントコンソールから任意の DB インスタンスを選択して [Modify] ボタンをクリックすることでスケールできます。メモリおよび CPU リソースは DB インスタンスのクラスを変更することで調整できます。

DB インスタンスのクラスを変更すると、その変更は指定したメンテナンスウィンドウの間に適用されます。あるいは、[Apply Immediately] フラグを使用して、スケーリングリクエストをすぐに適用することができます。これらのオプションはどちらも、スケーリング操作が実行されている数分間の可用性に影響を与えます。他の保留中のシステム変更も適用されることにご注意ください。

Q: DB インスタンスのバックアップはどうすれば有効にできますか?

Amazon Aurora DB インスタンスでは常に自動バックアップが有効です。バックアップはデータベースのパフォーマンスに影響を与えません。

Q: DB スナップショットを作成したあと、いつまでもスナップショットを保持できますか?

はい。また、スナップショットを作成する際にパフォーマンスに影響はありません。DB スナップショットからデータを復元する場合は新しく DB インスタンスを作成する必要があることに注意してください。

Q: データベースに障害が発生した場合、どのようなリカバリパスを利用できますか?

Amazon Aurora は自動的に 3 つのアベイラビリティーゾーンにかけて 6 個のデータコピーを保持するため、正常なアベイラビリティーゾーンでデータ損失のないデータベースを自動的にレプリケーションします。Amazon Aurora ストレージでデータが利用不可になるという稀なケースでは、DB スナップショットからレプリケーションするか、新しいインスタンスに任意の時点を指定したレプリケーションを実行できます。任意の時点でのレプリケーションを実行する場合、レプリケーションできる時点は直近で 5 分前までです。

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

DB インスタンスを削除する際に、最後の DB スナップショットを作成するか選択できます。作成した場合、この DB スナップショットを使用してあとから DB インスタンスをレプリケーションできます。Amazon Aurora は、DB インスタンスが削除されたあとも、このユーザーが作成した最終的な DB スナップショットと手動で作成されたその他の DB スナップショットをすべて保持します。DB インスタンスが削除された後は DB スナップショットのみが保持されます (任意の時点を指定したレプリケーションのための自動バックアップは保持されません)。

Q: 別の AWS アカウントとスナップショットを共有できますか?

はい。Aurora では、データベースのスナップショットを作成できます。これを使用して、後でデータベースを復元できます。スナップショットは別の AWS アカウントと共有でき、受取人アカウントの所有者は、そのスナップショットを使用して、お客様のデータを含む DB を復元できます。スナップショットを公開して、だれでもお客様の公開データを含む DB を復元できるように選択することもできます。この機能を使用して、別の AWS アカウントを持つさまざまな環境間 (本番、開発/テスト、ステージングなど) でデータを共有できます。また、メインの AWS アカウントが漏れた場合に備えて、別のアカウントにすべてのデータのバックアップを保護できます。

Q: 共有スナップショットに対して請求されますか?

アカウント間のスナップショットの共有に対して課金されることはありません。しかし、スナップショット自体、および共有スナップショットから復元するデータベースに対して課金される場合があります。詳細については、Aurora の料金表を参照してください。

Q: 自動的にスナップショットを共有できますか?

自動 DB スナップショットの共有はサポートされていません。自動スナップショットを共有するには、手動でスナップショットのコピーを作成してから、コピーを共有する必要があります。

Q: スナップショットをいくつのアカウントと共有できますか?

手動のスナップショットを、最大 20 個の AWS アカウント ID と共有できます。20 個を超えるアカウントと共有したい場合は、スナップショットを公開するか、クォータを引き上げるためにサポートにご連絡ください。

Q: どのリージョンで Aurora スナップショットを共有できますか?

Aurora スナップショットは、Aurora が利用可能なすべての AWS リージョンで共有できます。

Q: Aurora スナップショットを異なるリージョン間で共有できますか?

いいえ。共有された Aurora スナップショットは、それを共有したアカウントと同じリージョン内のアカウントからのみアクセスできます。

Q: 暗号化された Aurora スナップショットを共有できますか?

はい。暗号化された Aurora スナップショットは共有可能です。

Q: Amazon Aurora はディスク障害に対するデータベースの耐障害性をどのように向上しますか?

Amazon Aurora はデータベースボリュームを自動で 10 GB のセグメントに分割し、多数のディスクに分散します。各 10 GB 単位のデータベースボリュームが、3 つのアベイラビリティーゾーンにかけて 6 個レプリケーションされます。Amazon Aurora は最大 2 つまでのデータのコピー損失をデータベースの書き込み能力に影響せずに透過的に処理し、最大 3 つまでのコピー損失を読み込み能力に影響せずに処理します。また、Amazon Aurora ストレージは自己修復機能を備えています。データブロックおよびディスクはエラー検出のために継続的にスキャンされ、自動的にリペアされます。

Q: Aurora はデータベースクラッシュ後のリカバリ時間をどのように向上しますか?

他のデータベースと違い、データベースクラッシュ後、Amazon Aurora はデータベースを利用できるようにする前に最後のデータベースチェックポイント(通常 5 分前)から再実行ログをリプレイし、すべての変更が適用されたか確認する必要はありません。これにより、たいていの場合データベースの再起動時間を 60 秒以内に短縮します。また Amazon Aurora はバッファキャッシュをデータベース処理から除外し、再起動時にすぐ利用できるようにします。これにより、ブラウンアウトを避けるためにキャッシュが再生成されるまでアクセスを調整する必要がありません。

Q: Aurora はどんなレプリケーションをサポートしていますか?

Amazon Aurora MySQL と Amazon Aurora PostgreSQL は、プライマリインスタンスと同じ基盤ボリュームを共有する Amazon Aurora レプリカをサポートしています。プライマリにより実行された更新は、すべての Amazon Aurora レプリカで確認できます。Amazon Aurora MySQL を使用すれば、MySQL の binlog ベースのレプリケーションエンジンに基づいて MySQL リードレプリカを作成することもできます。MySQL リードレプリカでは、プライマリインスタンスのデータはトランザクションとしてレプリカでリプレイされます。読み込みのスケーリングおよび高可用性など、ほとんどの使用目的では Amazon Aurora レプリカを使用することをお勧めします。

アプリケーションのニーズに応じてこれら 2 つのレプリケーションタイプを柔軟に組み合わせることができます。

特徴 Amazon Aurora レプリカ MySQL レプリカ
レプリケーション数 最大 15 最大 5
レプリケーションタイプ 非同期的(ミリ秒単位) 非同期的(秒単位)
プライマリへのパフォーマンスの影響
フェイルオーバーターゲットとして機能 はい(データ損失なし) はい(数分間データ損失の可能性)
自動フェイルオーバー はい いいえ
ユーザー定義のレプリケーション遅延サポート いいえ はい
プライマリに対する異なるデータまたはスキーマのサポート いいえ はい

Q: Amazon Aurora でクロスリージョンレプリカを作成できますか?

はい。Aurora MySQL を使用すれば、クロスリージョン Aurora レプリカを RDS コンソールから設定できます。クロスリージョンレプリケーションは、シングルスレッドの MySQL binlog レプリケーションを利用しています。レプリケーションラグは変更率または適用率、および選択された特定のリージョン間のネットワーク通信の遅延による影響を受けます。今のところ、Aurora PostgreSQL でクロスリージョンレプリカはサポートされていません。

Q: クロスリージョンレプリカクラスターで Aurora リードレプリカを作成できますか?
はい。Aurora レプリカを、クロスリージョンレプリカと同じ基盤となるストレージを共有するクラスターに追加できます。クロスリージョンレプリカはクラスターでプライマリとして機能し、クラスターの Aurora レプリカではプライマリよりも通常数十ミリ秒の遅延が発生します。

Q: 自分のアプリケーションを現在のプライマリからクロスリージョンレプリカにフェイルオーバーできますか?
はい。RDS コンソールから、クロスリージョンレプリカを新しいプライマリに昇格させられます。ワークロードに応じて、通常昇格プロセスには数分かかります。昇格プロセスを開始すると、クロスリージョンレプリケーションは停止します。

Q: 特定のレプリカをフェイルオーバーターゲットとして他のレプリカに優先できますか?

A: はい。クラスターの各インスタンスに昇格優先階層を割り当てることができます。プライマリインスタンスが失敗した場合、Amazon RDS は最も高い優先度のレプリカをプライマリに昇格します。複数のレプリカ間の競合が同じ優先度の層に存在する場合、Amazon RDS が同じサイズのそのレプリカをプライマリインスタンスとして昇格します。フェイルオーバーロジックの詳細については、Amazon Aurora ユーザーガイドをお読みください。

Q: インスタンスへの優先階層を作成した後に変更できますか?

A: インスタンスへの優先階層はいつでも変更できます。優先階層を変更するだけでは、フェイルオーバーはトリガーされません。

Q: 特定のレプリカがプライマリインスタンスに昇格することを防ぐことはできますか?

A: プライマリインスタンスに昇格させたくないレプリカを低い優先階層に割り当てることができます。しかし、クラスターの高い優先度のレプリカが正常でない、または何らかの理由により利用できない場合、Amazon RDS は低い優先階層のレプリカを昇格します。

Q: 単一の Amazon Aurora データベースの可用性をどのように向上できますか?

Amazon Aurora レプリカを追加できます。Amazon Aurora レプリカは基盤となるストレージをプライマリインスタンスと共有します。任意の Amazon Aurora レプリカをデータを損失することなくプライマリに昇格できるため、プライマリ DB インスタンスに障害が発生した際の耐障害性を向上するために使用できます。データベースの可用性を高めるためには、3 つのアベイラビリティーゾーンに任意に 1 から 15 個のレプリカを作成するだけで、Amazon RDS が自動でデータベースの機能停止時のフェイルオーバープライマリ対象としてそれらのレプリカを認識します。

Q: フェイルオーバー中はどのようなことが起き、どのくらいの時間がかかりますか?

フェイルオーバーは Amazon Aurora によって自動的に処理されるため、アプリケーションは管理上の手動介入なく、可能な限り迅速にデータベースオペレーションを再開することができます。

  • 同一の、または異なるアベイラビリティーゾーンに Amazon Aurora レプリカを作成している場合、障害が発生すると Amazon Aurora は DB インスタンスの正規名レコード(CNAME)を反転させ、正常なレプリカを指定します。指定されたレプリカは新しいプライマリに昇格されます。フェイルオーバーは開始から終了まで通常 30 秒以内に完了します。
  • Amazon Aurora レプリカを作成していない場合(単一のインスタンスの場合)、Aurora は元のインスタンスと同じアベイラビリティーゾーンに新しい DB インスタンスの作成を試します。この処理に失敗した場合、Aurora は異なるアベイラビリティーゾーンに新しい DB インスタンスの作成を試行します。通常フェイルオーバーは開始から完了まで 15 分以内に終了します。

接続が切断された場合、通常アプリケーションはデータベースへの接続を再試行します。

Q: プライマリデータベースと Amazon Aurora レプリカがアクティブに読み込みトラフィックを処理していてフェイルオーバーが実行された場合はどうなりますか?

Amazon RDS はプライマリインスタンスの問題を自動的に検知し、読み込み / 書き込みトラフィックを Amazon Aurora レプリカにルーティングします。このフェイルオーバーは平均で 30 秒以内に完了します。さらに、Amazon Aurora レプリカが処理していた読み込みトラフィックは一時的に中断されます。

Q: レプリカはどのくらいプライマリから遅れますか?

Amazon Aurora レプリカはプライマリインスタンスと同じデータボリュームを共有しているため、実質的にレプリケーションラグはありません。ラグは通常数十ミリ秒です。MySQL リードレプリカの場合、レプリケーションラグは変更率または適用率、およびネットワーク通信の遅延に応じて無制限に増大する可能性があります。ただし、通常の状況では数分のレプリケーションラグが一般的です。

Q: Amazon Aurora を Amazon Virtual Private Cloud (Amazon VPC) で使用できますか?

はい。すべての Amazon Aurora DB インスタンスが必ず VPC で作成されます。Amazon VPC では、お客様のデータセンターで運用されている従来型のネットワークを正確に模して、仮想ネットワークのトポロジーを定義することができます。これにより、どのユーザーが Amazon Aurora データベースにアクセスできるかを完全に管理できます。

Q: Amazon Aurora は移動中と保存中にデータを暗号化しますか?

はい。Amazon Aurora では、SSL (AES-256) を使用してデータベースインスタンスとアプリケーションの間の通信が保護されています。Amazon Aurora では、AWS Key Management Service (KMS) で管理されるキーを使って、データベースを暗号化できます。Amazon Aurora 暗号化を使って実行するデータベースインスタンスでは、基盤となるストレージに保存される保管中のデータが、同じクラスター内の自動バックアップ、スナップショット、レプリカと同様に暗号化されます。暗号化と復号はシームレスに処理されます。Amazon Aurora での KMS の使用に関する詳細は、Amazon RDS ユーザーガイドを参照してください。

Q: 暗号化されていない既存のデータベースを暗号化できますか?

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

Q: Amazon Aurora データベースにはどのようにアクセスするのですか?

Amazon Aurora データベースのアクセスには必ずデータベース作成時に入力したデータベースポートを使用します。これを行うことで、データに対するセキュリティが一層強化されます。Amazon Aurora データベースに接続する際の詳細な手順は、Amazon Aurora の接続に関するガイドに記載されています。

Q: パフォーマンスインサイトはどのようなインスタンスサイズで利用可能になりますか?

micro 以外のインスタンスサイズすべてです。RDS に新しいインスタンスサイズが導入される場合、それらの十分なパフォーマンスを備えたインスタンスでもパフォーマンスインサイトが利用できるようになります。

Q: パフォーマンスインサイトは、PostgreSQL、Aurora MySQL、RDS for MySQL、RDS for Oracle、RDS for SQL Server、RDS for MariaDB でいつ使用可能になりますか?

パフォーマンスインサイトは Aurora PostgreSQL で最初に使用可能になり、すぐ後に Aurora MySQL が続きます。他のエンジンにも順次追加されます。

Q: パフォーマンスインサイトではどのようにパフォーマンスの問題の原因が示されますか?

パフォーマンスの問題は、データベース負荷グラフのスパイクとして、RDS コンソールのパフォーマンスインサイトのセクションに表示されます。このグラフを見ることで、アプリケーションのどのようなタイプのリソースによってデータベース内で時間とリソースが消費されているか、すばやく知ることができます。コンソールを使用して、保持期間内の任意の期間にズームインできます。高い負荷の期間を選択することで、全体的な負荷の順序に並んだ SQL ステートメントのリストを表示できます。

Q: パフォーマンスインサイトは、RDS DB インスタンスの負荷をどのように把握しますか?

パフォーマンスインサイトでは、DB インスタンス内の接続されたすべてのセッションの状態が毎秒サンプリングされます。あるセッションでデータベース関連のオペレーションに時間がかかっている場合、パフォーマンスインサイトによって、サンプル時間、操作のタイプ (I/O、CPU、ロックなど)、現在の SQL ステートメントおよびその他のセッション属性が記録されます。時間の経過と共に、このサンプリングされたデータが、セッションがデータベースインスタンスの負荷にどのように影響しているかを特定するために使用されます。

Q: RDS インスタンス内部からパフォーマンスデータをクエリできますか?

いいえ。パフォーマンスインサイトのサンプリングプロセスでは、データベース内のどのテーブルにもデータは入力されず、SQL を介してデータベース内から取り出されるデータも提供されません。

Q: 自分のインスタンスで何が起こっているのかをリアルタイムで確認できますか?

はい。デフォルトでは、パフォーマンスインサイトによって 1 時間分のパフォーマンスデータウィンドウが表示されます。この機能は、リアルタイムから数秒以内に最新のパフォーマンス情報を表示するように設計されています。

Q: パフォーマンスインサイトのコストはどれくらいですか?

パフォーマンスインサイトには、24 時間保持されるデータとコンソールアクセスが含まれます。プレビュー期間中、パフォーマンスインサイトでは直近 24 時間のパフォーマンスデータ保持を含む無料利用枠が提供されます。これより長い時間データを保持する場合の料金は、今後発表されます。

Q: パフォーマンスインサイトに保存されているパフォーマンスデータはどの程度まで見ることができますか?

24 時間分のパフォーマンス履歴を表示できます。これより長い保持期間のオプションについては、後日発表されます。

Q: 新しいインスタンスのパフォーマンスインサイトはデフォルトで有効になっていますが、無効にできますか?

はい。インスタンス作成ウィザードを使用する場合、AWS コンソールでパフォーマンスインサイトのオプションがデフォルトで選択されます。ウィザード内でオプションの選択をオフにすることで、パフォーマンスインサイトを有効化しないことができます。または、パフォーマンスインサイトが有効化されているインスタンスで、インスタンスを編集して無効化することもできます。

Q: パフォーマンスインサイトは、暗号化されたストレージを使用する RDS データベースインスタンスで動作しますか?

はい。パフォーマンスインサイトでは、データベースに保存されているデータは読み込まれません。

Q: DB 負荷とは何ですか? また、DB 負荷がパフォーマンスの問題を検出するためにパフォーマンスインサイトで使用される主要な手段である理由を教えてください。

DB 負荷とは、お客様のアプリケーションがデータベースに費やしている時間と、その内訳を示す時系列のことです。DB 負荷は Average Active Sessions (AAS) 単位で測定されます。アクティブなセッションとは、データベースエンジンに作業を送信し、そこからの応答を待っている接続 (セッション) です。例えば、SQL ステートメントをデータベースインスタンスに送信すると、インスタンスがそのクエリを処理している間、そのセッションは「アクティブ」とみなされます。特定の瞬間にインスタンス内でアクティブになっているセッション数をカウントし、時間内の平均を出すことで、あるインスタンスがどれほどビジーであるか、セッションでどれほどの時間がインスタンスの応答待ちに費やされているかを示すメトリクスが得られます。これが DB 負荷です。パフォーマンスインサイトではアクティブなセッションをカウントし、軽量のサンプリングメカニズムを使用して毎秒セッションごとの属性を記録します。サンプリングされたデータは暗号化され、さまざまな単位に集約され、[DB Load] グラフで提供されます。コンソールユーザーは、表示するタイムフレームを選択できます。

Q: パフォーマンスインサイトを有効にするためにデータベースに何か特別な処理を行わなければなりませんか?

いいえ。ただし、一部のデータベースエンジンでは、追加のパフォーマンス追跡を有効にすることで、パフォーマンスインサイトがさらに効果的に機能します。例えば、pg_stat_statement 拡張機能が RDS PostgreSQL や Aurora PostgreSQL で有効化されている場合、パフォーマンスインサイトではステートメントの判別に PostgreSQL ネイティブの SQL 識別子が使用されるようになり、長いステートメント全文の収集が可能になります。MySQL では、パフォーマンススキーマを有効にすることで、パフォーマンスインサイトがデータベースに影響を与える待機イベントについて、より豊富で詳細な情報を収集できます。

Q: パフォーマンスインサイトを有効にするとデータベースのパフォーマンスに影響が及びますか?

パフォーマンスインサイトのエージェントは、データベースのワークロードを邪魔しないように設計されています。パフォーマンスインサイトはインスタンス上の他のプロセスより低い優先度で実行され、ホストとデータベースの状態をモニタリングします。パフォーマンスインサイトでは、過大な負荷やリソースの枯渇が検出された場合、収集頻度が下げられ、データの収集は継続されるものの、安全なときにのみ実行されるようになります。RDS PostgreSQL や Aurora PostgreSQL の pg_stat_statement、および MySQL のパフォーマンススキーマなどのデータベースの設定は、一部のデータベースリソースを使用するため、パフォーマンスに影響する可能性があります。アプリケーションのワークロードによっては、これらのオプションを有効にするかどうかが一部のシステムに影響します。AWS では、本番稼働用システムで有効にする前に、ワークロードに対してデータベースオプションをテストすることを推奨します。

Q: 拡張モニタリングを使用し続けるべきですか、それともパフォーマンスインサイトを使用するべきですか?

O/S メトリクスのモニタリングのために拡張モニタリングをご使用のお客様は、引き続き拡張モニタリングでデータを取得してください。このデータは、データベースメトリクスの豊富なコレクションと共に、今後数か月間で、パフォーマンスインサイトのコンソールや API 経由で使用可能になる予定です。その時点で、お客様はすべてのパフォーマンスデータをパフォーマンスインサイトから取得できるようになります。使用継続を希望するお客様は引き続き拡張モニタリングを利用できますが、パフォーマンスインサイトでデータベースのモニタリングを標準化することを推奨します。

Q: パフォーマンス情報に格納されたデータは暗号化されていますか?

はい。パフォーマンスインサイトでは、機密性を持つ可能性があるすべてのデータを、所有する KMS キーで暗号化します。データは、転送中と保管中のいずれも暗号化されます。AWS の従業員は、機密性を持つ可能性があるパフォーマンスデータへのアクセスや表示を実行できません。RDS にフルアクセス可能な AWS アカウントのユーザーのみがパフォーマンスインサイトを表示できます。RDS の KMS キー付与は取り消すことができます。これにより、いつでもパフォーマンスデータの処理や表示が行えます。

Q: パフォーマンスインサイトを無効にすると AWS はデータを保持しますか、それとも削除しますか?

パフォーマンスデータの保持無料利用枠は 1 日に制限されています。あるインスタンスのパフォーマンスインサイトを無効にすると、そのインスタンスのパフォーマンスデータは削除されます。

Q: RDS データベースインスタンスを停止した場合、パフォーマンスインサイトデータの保持期間はどうなりますか?

パフォーマンスインサイトが有効になっている RDS インスタンスを停止しても、インスタンスの履歴データ保持期間や可視性には影響しません。インスタンスの停止期間中はデータなしになります。

Q: パフォーマンスインサイトと既存のパフォーマンスツールをどのように結合できますか?

今後数か月間のうちに、パフォーマンスインサイトでは、お客様とサードパーティがパフォーマンスインサイトの貴重なデータを活用できるよう設計された API が公開される予定です。

Q: サードパーティのパフォーマンスツールをパフォーマンスインサイトと統合する方法はありますか?

今後数か月間のうちに、パフォーマンスインサイトでは、お客様とサードパーティがパフォーマンスインサイトの貴重なデータを活用できるよう設計された API が公開される予定です。

Q: パフォーマンスインサイトは RDS のすべての AWS リージョンで利用できるようになりますか?

はい。パフォーマンスインサイトは、最初に米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド) の 4 リージョンで利用可能になります。今後、この機能は RDS をサポートするすべてのリージョンで使用可能になる予定です。

Q: パフォーマンスインサイトは既存のインスタンスにも有効化できますか? それとも新規インスタンスのみですか?

はい。パフォーマンスインサイトは、パフォーマンスインサイトを有効化するようインスタンスを変更すれば、既存のインスタンスでも使用できます。新しいインスタンスでは、インスタンスの作成時にパフォーマンスインサイトを有効化するよう指定することで、この機能を使用できます。

Q: パフォーマンスインサイトではデータベースインスタンスのストレージが使用されますか?

いいえ。パフォーマンスインサイトは RDS インスタンスのストレージ領域を使用しません。

Q: パフォーマンスインサイトでは、どのような点が対象データベースエンジンにより違うのですか?

パフォーマンスインサイトは、RDS のすべてのデータベースエンジンで共通のアプローチ、外観、および調整感が得られるよう設計されています。待機イベントや SQL 識別子などの特定の属性はエンジンの種類によって異なるため、パフォーマンスインサイトでもデータベースエンジンにより異なります。パフォーマンスインサイトの基本原則の 1 つは、データベースエンジンの既存の概念、識別子、および属性をそのまま維持することです。通常、パフォーマンスインサイトでは待機イベントの他のエンジン固有属性への再解釈や名前変更は行わず、データベースエンジンによってレポートされたものをそのまま表示します。

Q: パフォーマンスインスタンスはマルチ AZ インスタンスとリードレプリカのインスタンスで動作しますか?

はい。RDS データベースがマルチ AZ を使用し、パフォーマンスインサイトが有効になっている場合、そのインスタンスが他のアベイラビリティーゾーンにフェイルオーバーした場合でも、パフォーマンスインサイトは引き続き有効です。リードレプリカは独立したインスタンスなので、お客様がそれらのインスタンスでのパフォーマンスインサイトを有効または無効にできます。

Q: パフォーマンスインサイトからデータをエクスポートできますか?

今後、パフォーマンスインサイトにデータエクスポート機能が追加される予定です。

Q: パフォーマンス分析のために、データを後でパフォーマンスインサイトに再インポートできますか?

いいえ。パフォーマンスインサイトでは、インスタンスから直接収集されたデータのみ表示されます。今後数か月のうちに、パフォーマンスインサイトで取得したデータを API 経由で利用し、Amazon Athena、Amazon Redshift、Amazon Redshift Spectrum、Amazon Quicksight など AWS の分析向けサービスで分析することが可能になる予定です。