全般

Q: Amazon Aurora とは何ですか?

Amazon Aurora は、大規模なパフォーマンスと高可用性を提供する最新のリレーショナルデータベースサービスで、完全にオープンソースの MySQL と PostgreSQL 互換エディション、およびサーバーレスや機械学習 (ML) 駆動のアプリケーションを構築するためのさまざまなデベロッパーツールを提供します。

Aurora のストレージシステムは、分散型で耐障害性と自己修復機能を備えており、コンピューティングリソースから切り離され、データベースインスタンスごとに最大 128 TB まで自動的にスケールアップされます。Amazon Aurora は、最大 15 個の低レイテンシーリードレプリカ、ポイントインタイムリカバリ、Amazon Simple Storage Service (Amazon S3) への継続的なバックアップ、3 つのアベイラビリティーゾーン (AZ) 間でのレプリケーションにより、優れたパフォーマンスと可用性を発揮します。

Amazon Aurora は、ハードウェアプロビジョニング、データベース設定、パッチ適用、バックアップなど、時間のかかる管理タスクを自動化すると同時に、1/10 のコストで商用データベースのセキュリティ、可用性、信頼性を提供するフルマネージドサービスでもあります。

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

Amazon Aurora は、既存の MySQL オープンソースデータベースとドロップイン互換性があり、新しいリリースのサポートも定期的に追加されています。このため、標準的なインポート/エクスポートツールやスナップショットを使用して、MySQL データベースを簡単に Aurora との間で移行できます。また、現在お客様が MySQL データベースで使用しているコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Aurora と MySQL を比較する場合、Amazon Aurora データベースエンジンは InnoDB ストレージエンジンを使用することで MySQL 5.6 および 5.7 と強い互換性があります。これにより、2 つのエンジン間で簡単にアプリケーションを移動できます。MyISAM ストレージエンジンなど、特定の MySQL の特徴は Amazon Aurora で使用できません。

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

Amazon Aurora は、既存の PostgreSQL オープンソースデータベースとドロップイン互換性があり、新しいリリースのサポートも定期的に追加されています。このため、標準的なインポート/エクスポートツールやスナップショットを使用して、PostgreSQL データベースを簡単に Aurora との間で移行できます。また、現在お客様が PostgreSQL データベースで使用しているコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。 

Q: Amazon Aurora とAmazon Relational Database Service (Amazon RDS) については、どのように考えればよいですか?

A: Amazon RDS は、フルマネージドで可用性が高く、安全なデータベースサービスであり、PostgreSQL、MySQL、MariaDB、Oracle、SQL Server、Amazon Aurora MySQL 互換エディション、および Amazon Aurora PostgreSQL 互換エディションの 7 つのリレーショナルデータベースエンジンを簡単に設定、操作、実行できます。 

Amazon Aurora MySQL 互換エディションおよび Amazon Aurora PostgreSQL 互換エディションは、時間のかかるデータベース管理タスクを自動化するなど、Amazon RDS の利点を利用し、コミュニティのオープンソース MySQL および PostgreSQL と比較して、パフォーマンス、スケーラビリティ、および可用性を向上させます。

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

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

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

現在の料金情報については、Aurora 料金ページを参照してください。

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

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

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

リージョンと料金の最新情報については、Aurora 料金ページを参照してください。

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

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

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

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

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

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

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

I/O はソリッドステートドライブ (SSD) ベースの仮想ストレージレイヤーに対して Aurora データベースエンジンによって実行される入力/出力オペレーションです。各データベースページの読み取りオペレーションは 1 I/O とカウントされます。Aurora データベースエンジンは、キャッシュ内のメモリに存在しないデータベースページを取得するためにストレージレイヤーに対して読み取りを発行します。クエリトラフィックをメモリまたはキャッシュから完全に提供できる場合、メモリからデータページを取得するための料金は発生しません。クエリトラフィックをメモリから完全に提供できない場合は、ストレージから取得する必要のあるデータページについて課金されます。各データベースページについては、Aurora MySQL 互換エディションでは 16 KB、Aurora PostgreSQL 互換エディションでは 8 KB です。 

Aurora はコストを削減し、リソースが読み込み/書き込みトラフィックを提供するために利用可能になるように不要な I/O オペレーションを排除するよう設計されていました。書き込み I/O は、書き込みに耐久性を持たせる目的で、Aurora MySQL 互換エディションの redo ログレコードまたは Aurora PostgreSQL 互換エディションのログ先行書き込みレコードをストレージレイヤーに保持する場合にのみ消費されます。書き込み I/O は 4 KB 単位でカウントされます。例えば、ログレコードが 1,024 バイトの場合、1 書き込み I/O オペレーションとカウントされます。ただし、ログレコードが 4KB を超える場合は、ログレコードを保持するために複数の書き込み I/O オペレーションが必要になります。ログレコードが 4 KB 未満の同時書き込みオペレーションは、同じストレージ保護グループで保持されている場合、I/O 消費を最適化するために、Aurora データベースエンジンによってまとめてバッチ処理される場合があります。従来のデータベースエンジンとは異なり、Aurora はダーティデータページをストレージにフラッシュすることはありません。AWS マネジメントコンソールで Aurora インスタンスがどれほど I/O リクエストを消費しているか確認できます。AWS コンソールで Aurora インスタンスがどれほど I/O リクエストを消費しているか確認できます。I/O 消費を確認するには、Amazon 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 と互換性を持つように設計されているため、既存の MySQL アプリケーションおよびツールを修正することなく実行できます。一方で、Amazon Aurora が MySQL よりも優れている領域の 1 つが、ワークロードの同時実行数が非常に多い場合です。Amazon Aurora でワークロードのスループットを最大化するには、多数のクエリやトランザクションを同時実行するようにアプリケーションを作成することをお勧めします。

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

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

ハードウェアとスケーリング

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

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

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

Amazon Aurora のオンデマンドの自動スケーリング構成である Aurora Serverless を使用して、アプリケーションのニーズに基づいてデータベースコンピューティングリソースをスケーリングできます。データベース容量の管理を心配することなく、クラウド内でデータベースを実行できます。必要なデータベース容量の範囲を指定でき、データベースはアプリケーションのニーズに基づいてスケールされます。詳細については、Aurora Serverless ユーザーガイドをお読みください。

また、AWS マネジメントコンソールで目的の DB インスタンスタイプを選択することにより、データベースに関連付けられているコンピューティングリソースを手動でスケールすることもできます。要求された変更は、指定されたメンテナンスウィンドウ中に適用されます。あるいは、[すぐに適用] フラグを使用すると、DB インスタンスタイプをすぐに変更できます。これらのオプションはいずれも、スケーリング操作が実行されている数分間の可用性に影響を与えます。保留中の他のシステム変更も適用されることにご注意ください。

バックアップと復元

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

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

Q: DB スナップショットを取得し、そのスナップショットをいつまでも保持できますか?

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

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

Amazon Aurora では、3 つのアベイラビリティーゾーン (AZ) に 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 分前) から REDO ログをリプレイし、すべての変更が適用されたか確認する必要はありません。これにより、多くの場合データベースの再起動時間を 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
レプリケーションタイプ 非同期的 (ミリ秒単位) 非同期的 (秒単位)
プライマリへのパフォーマンスの影響
レプリカのロケーション リージョン内
クロスリージョン
フェイルオーバーターゲットとして機能 はい (データ損失なし) はい (数分間データ損失の可能性)
自動フェイルオーバー はい いいえ
ユーザー定義のレプリケーション遅延サポート いいえ はい
プライマリに対する異なるデータまたはスキーマのサポート いいえ はい

上記のものに加えて、さらに 2 つのレプリケーションオプションがあります。Amazon Aurora Global Database を使用すると、異なるリージョンの Aurora クラスター間での物理レプリケーションを大幅に高速化できます。さらに、Aurora と非 Aurora MySQL 互換エディションデータベース (AWS 外であっても) 間のレプリケーションでは、セルフマネージドの、独自の binlog レプリケーションを設定できます。

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

はい。物理または論理のいずれかのレプリケーションを使用して、クロスリージョンの Aurora レプリカを設定できます。物理レプリケーション (Amazon Aurora Global Database) は、アプリケーションにサービスを提供するためにお使いのデータベースを全面的に利用可能とする専用のインフラストラクチャであり、1 秒未満という一般的なレイテンシーを特徴とする最大 5 つのセカンダリリージョンにレプリケートできます。Aurora MySQL 互換エディションと Aurora PostgreSQL 互換エディションの両方で使用できます。低レイテンシーのグローバルな読み取りと災害復旧を実現するために、Amazon Aurora Global Database の使用をお勧めします。

Aurora は、各データベースエンジン (MySQL の場合はバイナリログ、PostgreSQL の場合は PostgreSQL レプリケーションスロット) でネイティブの論理レプリケーションをサポートしているため、リージョン間でも Aurora データベースと非 Aurora データベースにレプリケートできます。

Aurora MySQL 互換エディションは、最大 5 つのセカンダリ AWS リージョンをサポートする、使いやすい論理クロスリージョンリードレプリカ機能も提供しています。シングルスレッドの MySQL binlog レプリケーションに基づいています。レプリケーションラグは変更率または適用率、および選択された特定のリージョン間のネットワーク通信の遅延による影響を受けます。

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

はい。最大 15 個の Aurora レプリカを各クロスリージョンクラスターに追加できます。これにより、クラスター間で、クロスリージョンレプリカと同じ基盤となるストレージが共有されます。クロスリージョンレプリカはクラスターでプライマリとして機能し、クラスターの Aurora レプリカではプライマリよりも通常は数十ミリ秒の遅延が発生します。

Q: 自分のアプリケーションを現在のプライマリからクロスリージョンレプリカにフェイルオーバーできますか?

はい。Amazon RDS コンソールから、クロスリージョンレプリカを新しいプライマリに昇格させられます。論理 (binlog) レプリケーションの場合、ワークロードによって異なりますが、昇格プロセスには一般に数分かかります。昇格プロセスを開始すると、クロスリージョンレプリケーションは停止します。

Amazon Aurora Global Database を使用すれば、セカンダリリージョンを昇格させて 1 分以内にすべての読み取り/書き込みワークロードを取得できます。

Q: 特定のレプリカをフェイルオーバーターゲットとして、他のレプリカより優先させることができますか?

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

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

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

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

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

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

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

Amazon Aurora Global Database は、お使いのデータベースを複数の AWS リージョンで利用する場合に使用できます。これにより、データベースのパフォーマンスに影響を及ぼさずにデータがレプリケートされ、リージョン全体の停止からの災害復旧が可能になります。

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

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

  • Amazon Aurora レプリカを同一の、または異なるアベイラビリティーゾーンに作成しておくと、フェイルオーバーが発生した場合、Aurora は DB インスタンスの正規名レコード (CNAME) を切り替えて正常なレプリカを指定します。指定されたレプリカはこれにより新しいプライマリに昇格します。フェイルオーバーは開始から終了まで通常 30 秒以内に完了します。 
  • DB インスタンスか AZ が使用不能になった時でも、Aurora Serverless を使用していてれば、別の AZ 内に Aurora が DB インスタンスを自動的に再作成します。 
  • Amazon Aurora レプリカを作成しておらず(つまり、インスタンスは 1 つ) Aurora Serverless を使っていない場合、Aurora は元のインスタンスと同じアベイラビリティーゾーンに新しい DB インスタンスの作成を試みます。この時のオリジナルインスタンス置換処理はベストエフォートであり、アベイラビリティーゾーン内で広範囲に影響を及ぼす問題がある時などは失敗する可能性があります。

接続が切断された場合、アプリケーションではデータベースへの接続を再試行する必要があります。リージョンをまたがる災害復旧は手動プロセスであり、ここで、読み取り/書き込みワークロードを取得できるようにセカンダリリージョンを昇格させます。

Q: プライマリデータベースにおいて、Amazon Aurora レプリカからのアクティブな読み取りトラフィックが処理されているとき、フェイルオーバーが発生するとどうなりますか?

プライマリインスタンスでの問題は Amazon Aurora により自動検出され、フェイルオーバーがトリガーされます。クラスターエンドポイントを使っていれば、読み取りもしくは書き込みのための接続は Amazon Aurora レプリカに自動でリダイレクトされ、レプリカはプライマリに昇格します。さらに、Aurora レプリカが処理していた読み取りトラフィックは一時的に中断されます。クラスターリーダーエンドポイントを使って読み取りトラフィックを Aurora レプリカに送っている場合は、古いプライマリノードがレプリカとして復旧するまでの間、新たにプライマリに昇格した Aurora レプリカに対し読み取り専用接続が行われます。

Q: プライマリに対しレプリカにはどのくらいの遅延がありますか?

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

論理レプリケーションを使用するクロスリージョンレプリカは、変更率または適用率、および選択された特定のリージョン間のネットワーク通信の遅延による影響を受けます。Amazon Aurora Global Database を使用するクロスリージョンレプリカには、1 秒未満という標準的なラグが生じます。

Q: Aurora MySQL 互換エディションデータベースと外部の MySQL データベース間にレプリケーションは設定できますか?

はい。Aurora MySQL 互換エディションインスタンスと外部の MySQL データベースの間で binlog レプリケーションを設定できます。もう一方のデータベースは、Amazon RDS 上で、AWS 上でセルフマネージド型データベースとして、または完全に AWS の外部で実行できます。

Aurora MySQL 互換エディション 5.7 を実行している場合、GTID ベースの binlog レプリケーションをお勧めしています。これにより完全な一貫性が提供され、フェイルオーバーやダウンタイムの後でも、複製でトランザクションが失われたり、競合が発生することがありません。

Q: Amazon Aurora Global Database とは何ですか?

Amazon Aurora Global Database は、単一の Amazon Aurora データベースを複数の AWS リージョンにまたがって運用可能にする機能です。データベースのパフォーマンスに影響を与えずにデータをレプリケートし、1 秒未満という標準的なレイテンシーで各リージョンでのローカル読み取りを高速化し、リージョン規模の停止からの災害復旧を実現します。万一、リージョンの規模縮小や障害が発生した場合でも、セカンダリリージョンを、完全な読み取り/書き込み機能に 1 分以内で昇格させることができます。

この機能は、Aurora MySQL 互換エディションと Aurora PostgreSQL 互換エディションの両方で使用できます。

Q: Amazon Aurora Global Database はどうやって作成しますか?

Amazon RDS コンソールでのわずか数回のクリックにより、Aurora Global Database を作成できます。または、AWS ソフトウェア開発キット (SDK) または AWS Command-Line Interface (CLI) を使用することもできます。Amazon Aurora Global Database 内のリージョンにつき、少なくとも 1 つのインスタンスをプロビジョニングする必要があります。

Q: Amazon Aurora Global Database には何か所のセカンダリリージョンを設定できますか?

Amazon Aurora Global Database には、最大 5 つのセカンダリリージョンを作成できます。

Q: Amazon Aurora Global Database を使用する場合、プライマリデータベースで論理レプリケーション (binlog) も使用できますか?

はい。データベースのアクティビティを分析することが目的である場合は、データベースのパフォーマンスへの影響を避けるために、代わりに Aurora の高度な監査、全般ログ、スロークエリログの使用を検討してください。

Q: Aurora は、Amazon Aurora Global Database のセカンダリリージョンに自動的にフェイルオーバーしますか?

いいえ。プライマリリージョンが利用不可になる場合は、Amazon Aurora Global Database からセカンダリリージョンを手動で取り除き、完全な読み取り/書き込みを取得できるように昇格させることができます。新たに昇格させたリージョンへのアプリケーションの指定も必要になります。

Q: Amazon Aurora Multi-Master とは何ですか?

Aurora の MySQL 互換エディションの新機能である Amazon Aurora Multi-Master は、複数のアベイラビリティーゾーンにわたって書き込みパフォーマンスをスケールアウトする機能が追加され、アプリケーションは読み取り/書き込みワークロードをデータベースクラスター内の複数のインスタンスに送信して、操作の可用性を高めることができます。

Q: Amazon Aurora Multi-Master の使用を開始する方法を教えてください。

Amazon Aurora Multi-Master の一般公開を開始しました。詳細については 「Amazon Aurora のドキュメント」をご覧ください。Aurora Multi-Master クラスターの作成は、Amazon RDS コンソールから数回のクリックで完了しますが、最新の AWS SDK または CLI をダウンロードして行うこともできます。

セキュリティ

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

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

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

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

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

Q: Amazon Aurora は HIPAA コンプライアンス要件のあるアプリケーションで使用できますか?

はい。Aurora の MySQL 互換エディションと PostgreSQL 互換エディションは医療保険の相互運用性と説明責任に関する法令 (HIPAA) の要件を満たしているため、これらを使用して HIPAA 準拠のアプリケーションを作成し、AWS との事業提携契約 (BAA) に基づく保護医療情報 (PHI) などの医療関連情報を保存することができます。既に BAA を締結している場合は、BAA の適用を受けているアカウントでこのサービスの使用を開始するために何も行う必要はありません。AWS に準拠したアプリケーションの構築に関する詳細は、クラウドでの医療提供者と保険会社を参照してください。

Q: Amazon Aurora の各リリースについて公的に知られたサイバーセキュリティに関する脆弱性の「一般的な脆弱性と暴露 (CVE)」の項目をまとめた一覧はどこで見ることができますか?

CVE の一覧は現在、Amazon Aurora Security Updates でご覧いただけます。

サーバーレス

Q: Amazon Aurora Serverless とは何ですか?

Aurora Serverless は、Amazon Aurora のオンデマンドの Auto Scaling 設定です。データベース容量を管理せずにクラウド内でデータベースを実行できます。データベースの容量を手動で管理すると、貴重な時間が奪われ、データベースリソースの非効率的な使用につながるおそれがあります。Aurora Serverless では、データベースを作成し、必要に応じてデータベースの容量範囲を指定し、アプリケーションを接続するだけです。Aurora は、アプリケーションのニーズに基づいて、指定された範囲内で容量を自動的に調整します。データベースがアクティブなときに使用したデータベース容量に対して、秒単位でお支払いいただきます。Aurora Serverless の詳細を確認し、Amazon RDS マネジメントコンソールで数回クリックするだけで使い始めることができます。

Q: Aurora Serverless v2 と v1 の違いは何ですか?

Aurora Serverless v2 は、開発およびテスト環境、ウェブサイト、使用頻度が低い、断続的、または予測不能なワークロードを有するアプリケーションから、大規模で高可用性を必要とする最も要求の厳しいビジネスクリティカルなアプリケーションまで、あらゆる態様のデータベースワークロードをサポートします。データベースを大小のデータベースインスタンスにフェイルオーバーすることなく、CPU とメモリを追加することで適切にスケールインできます。その結果、長時間実行されるトランザクションやテーブルロックなどがある場合でもスケールできます。さらに、データベース容量を 0.5 Aurora Capacity Unit (ACU) の増分でスケールするため、データベース容量はアプリケーションのニーズに厳密に一致します。

Aurora Serverless v1 は、使用頻度が低い、断続的、または予測不能なワークロード向けのシンプルでコスト効率の良いオプションです。自動的に起動し、アプリケーションの使用状況に合わせてコンピューティング性能をスケールし、使用されていないときはシャットダウンします。詳細については、「Aurora ユーザーガイド」をご覧ください。

Q: Aurora Serverless v2 がサポートするすべての Aurora 機能は?

Aurora Serverless v2 は、リードレプリカマルチ AZ 構成グローバルデータベースRDS プロキシPerformance Insights など、プロビジョンされた Aurora のすべての機能をサポートします。

Q: 既存の Aurora DB クラスターで Aurora Serverless v2 の使用を開始できますか?

はい、Aurora Serverless v2 の使用を開始して、既存の Aurora DB クラスターのデータベースコンピューティング容量を管理できます。プロビジョンされたインスタンスと Aurora Serverless v2 の両方を含むクラスターは、混合構成クラスターと呼ばれます。クラスター内にプロビジョンされたインスタンスと Aurora Serverless v2 の任意の組み合わせを選択できます。Aurora Serverless v2 をテストするには、Aurora DB クラスターにリーダーを追加し、インスタンスタイプとして Serverless v2 を選択します。リーダーが作成されて使用可能になると、読み取り専用ワークロードでの使用を開始できます。リーダーが期待どおりに機能していることを確認したら、フェイルオーバーを開始して、読み取りと書き込みの両方で Aurora Serverless v2 の使用を開始できます。このオプションは、Aurora Serverless v2 の使用を開始するためのダウンタイムを最小限に留めます。

Q: Aurora Serverless v1 から Aurora Serverless v2 に移行できますか?

はい、Aurora Serverless v1 から Aurora Serverless v2 に移行することができます。詳細については、「Aurora ユーザーガイド」を参照してください。

Q: Aurora Serverless をサポートしているのは、Amazon Aurora のどのバージョンですか?

Aurora Serverless v2 は、バージョン 8.0 以降の MySQL 互換エディションの Amazon Aurora と、バージョン 13.5 以降の PostgreSQL 互換エディションで使用できます。Aurora Serverless v1 は、Aurora MySQL 5.6 および 5.7 と Aurora PostgreSQL10.14 で使用できます。

Q: 既存の Aurora DB クラスターを Aurora Serverless に移行できますか?

はい。クラスターがプロビジョンされている既存の Aurora のスナップショットを、Aurora Serverless DB クラスターに復元することができます (その逆も可能です)。

Q: Aurora Serverless DB クラスターに接続するにはどうしたらよいですか?

同一の VPC で実行しているクライアントアプリケーション内から Aurora Serverless DB クラスターにアクセスします。Aurora Serverless DB クラスターでパブリック IP アドレスを使用することはできません。

Q: Aurora Serverless クラスターのキャパシティーを明示的に設定することはできますか?

Aurora Serverless は、動作中のデータベースワークロードに応じて自動的にスケールしますが、大量の新しいトランザクションの発生といったワークロードの急激な変化に対して、キャパシティーを迅速にスケールして十分に対応することができない場合があります。このような場合、AWS マネジメントコンソール、AWS CLI、Amazon RDS API を使って、特定の値のキャパシティーを明示的に設定できます。

Q: Aurora Serverless DB クラスターが自動的にスケールしないのはなぜですか?

Aurora Serverless では、スケーリングオペレーションが開始されると、データベースのスケーリングを安全に行える時点となるスケーリングポイントを見つけようとします。Aurora Serverless では、進行中の長期のクエリやトランザクションがある場合や、一時的なテーブルやテーブルロックを使用している場合、スケーリングポイントを特定できないことがあります。

Q: Aurora Serverless の料金はどのように請求されますか?

Aurora Serverless では、データベース容量は Aurora Capacity Unit (ACU) で測定されます。ACU 使用量について 1 秒あたりの定額料金をお支払いいただきます。ストレージと I/O の料金は、プロビジョン構成もサーバーレス構成も同じです。料金と利用可能な AWS リージョンに関する最新情報については、Aurora の料金ページにアクセスしてください。

Parallel Query

Q: Amazon Aurora Parallel Query とは何ですか?

Amazon Aurora Parallel Query とは、ひとつのクエリを Aurora のストレージレイヤーにある数千規模の CPU にわたってプッシュダウンしてコンピューティングの負荷を分散できることを言います。Parallel Query なしでは、Amazon Aurora データベースに対して出されたクエリはデータベースクラスターのひとつのインスタンス中のみで実行されます。多くのデータベースはほぼこのように動作します。

Q: どのようなユースケースをターゲットにしていますか?

Parallel Query は大きな表でもフレッシュなデータと良好なクエリパフォーマンスを要する分析ワークロードに適しています。この種のワークロードの多くはオペレーションに関するものです。

Q: Parallel Query にはどのような利点がありますか?

Parallel Query を使用すると、パフォーマンスが向上し、分析クエリが最大 2 桁向上します。また、Aurora クラスター内の現在のトランザクションデータに対して直接クエリを発行できるため、シンプルなオペレーションとフレッシュなデータを得られます。また、Parallel Query では同じデータベースでトランザクションワークロードと分析ワークロードが可能であるため、Aurora が分析クエリと同時に高いトランザクションスループットを維持できます。

Q: Parallel Query で改善されるクエリには具体的にどのようなものがありますか?

バッファープールにまだない大型のデータセットへの多くのクエリに改善が見込めます。Parallel Query の最初のバージョンは 200 を越す SQL 関数、等価結合、プロジェクションの処理をプッシュダウンおよびスケーリングできます。

Q: どれほどのパフォーマンスの改善が見込めますか?

具体的なクエリのパフォーマンスへの改善は Aurora ストレージレイヤーにどれだけのクエリプランがプッシュダウンできるかによります。クエリレイテンシーに 1 桁以上の改善が見られたというお客様もおられます。

Q: パフォーマンスが遅くなることはありますか?

はい。しかしそのようなケースは希です。

Q: Parallel Query を活用するにはクエリにどのような変更を加える必要がありますか?

クエリシンタックスには変更を加える必要はありません。具体的なクエリに対してはクエリオプティマイザーが自動的に Parallel Query を使うべきかどうかを決定します。クエリが Parallel Query を使うかどうかを確認するには、EXPLAIN コマンドを用いてクエリ実行計画を見ることができます。ヒューリスティックスをバイパスして Parallel Query をテスト目的に強制的に使いたい場合、セッション変数に aurora_pq_force を使ってください。

Q: この機能はどのようにしてオン、オフできますか?

Parallel Query は aurora_pq パラメータを用いてグローバルでもセッションレベルでも動的に有効化、無効化可能です。

Q: Parallel Query に関連する追加料金はありますか?

いいえ。すでにインスタンス、I/O、ストレージに対してお支払いいただいている以上の料金はいただきません。

Q: Parallel Query は I/O を減らすので、これをオンにすると Aurora IO 料金は下がりますか?

いいえ、I/O ince Parallel Query はクエリの I/O コストを削減します。これはストレージレイヤーで計量されており、Parallel Query をオンにすると同じか、それ以上になります。改善されるのはクエリのパフォーマンスです。Parallel Query で I/O コストが上がるには 2 つの理由があり得ます。まず、表中のデータのうちいくつかがバッファープールにあっても、Parallel Query はすべてのデータのスキャンはストレージレイヤーでされなければならないので、I/O が発生します。また、バッファープールで競合を避けることには、Parallel Query クエリの実行がバッファープールをウォームアップしないという副作用があります。その結果、同じ Parallel Query クエリの連続した実行には I/O コストがフルにかかります。

Q: Amazon Aurora のどのバージョンが Parallel Query をサポートしていますか?

Parallel Query は MySQL 5.6 に対応した Amazon Aurora のバージョン v1.18.0 以降で使えます。Parallel Query は MySQL 5.7 に対応した Aurora、および Aurora PostgreSQL 互換エディションに対応した Aurora にも拡張する計画です。

Q: Parallel Query はすべてのインスタンスタイプに対して利用できますか?

いいえ。現時点では、Parallel Query は R* インスタンスファミリーのインスタンスで使用できます。

Q: Parallel Query はその他すべての Aurora の機能に対応していますか?

今は対応していません。現時点では、サーバーレスまたはバックトラック機能を実行していないデータベースクラスターにはオンにできます。さらに、MySQL 5.7 対応の Aurora 専用の機能はサポートしていません。

Q: Parallel Query がパフォーマンスの消失がたまに見られるクエリのみを高速化するならば、常にオンにしておくべきですか?

いいえ。Parallel Query は多くのケースでクエリレイテンシーの改善を見込んでいるものの、I/O コストは高くなります。ワークロードで機能をオン、オフにして徹底的にテストされることをお勧めします。Parallel Query が正しい選択肢であると確信されたら、クエリオプティマイザーを用いて Parallel Query を使用するクエリを自動的に決定できます。万一オプティマイザーが最適な決定をしてくれない場合は、設定をオーバーライドできます。

Q: Aurora Parallel Query は私のデータウェアハウスに代わるものですか?

Aurora Parallel Query はデータウェアハウスではなく、このような製品に通常備わった機能はありません。リレーショナルデータベースのクエリパフォーマンスを向上させるために作られており、データベース中の最新データに高速で分析クエリを行う必要のあるオペレーション分析などのユースケースに最適です。

Amazon DevOps Guru for RDS

Q: Amazon DevOps Guru for RDS とは?

Amazon DevOps Guru for RDS は、データベースのパフォーマンスと運用上の問題を自動的に検出および診断するように設計されています。Amazon RDS の新しい機械学習を利用した機能であり、数日もかかっていた問題を数分以内に解決できます。Amazon DevOps Guru for RDS は、Amazon DevOps Guru の機能であり、すべての Amazon RDS エンジンと他の数十のリソースタイプの運用およびパフォーマンスに関する問題を検出するように設計されています。DevOps Guru for RDS は、DevOps Guru の機能を拡張して、リソースの過剰使用や特定の SQL クエリの誤動作など、Amazon RDS のさまざまなデータベース関連の問題を検出、診断、および修正します。問題が発生すると、Amazon DevOps Guru for RDS はすぐにデベロッパーと DevOps エンジニアに通知するように設計されており、診断情報、問題の範囲の詳細、およびお客様がデータベースに関するパフォーマンスのボトルネックと運用上の問題を迅速に解決するのに役立つインテリジェントな修復についてレコメンデーションを提供します。

DevOps Guru for RDS を使用する利点は何ですか?

Amazon DevOps Guru for RDS は、手動作業を行わずに、時間 (数時間から数日かかっていたものを数分に) を短縮して、リレーショナルデータベースのワークロードで見つけにくいパフォーマンスのボトルネックを検出して解決するように設計されています。すべての Amazon Aurora データベースで DevOps Guru for RDS を有効にすると、ワークロードのパフォーマンス問題が自動的に検出されます。その後、各問題についてアラートが送信され、結果が説明され、問題を解決するための措置が推奨されます。DevOps Guru for RDS を使用すれば、専門家以外のユーザーがデータベースを管理しやすくなり、データベースの専門家がさらに多くのデータベースを管理できるように支援します。

Q: Amazon DevOps Guru for RDS はどのように機能しますか?

Amazon DevOps Guru for RDS は、機械学習を使用して、Amazon RDS Performance Insights (PI) によって収集されたテレメトリデータを分析します。DevOps Guru for RDS がデータベースに保存されているデータを分析に使用することはありません。PI は、データベースの負荷を測定します。これは、アプリケーションがデータベースでどのように時間を費やしているかを特徴付けるメトリクスであり、MySQL のサーバーステータス変数や PostgreSQL の pg_stat テーブルなど、データベースによって生成される厳選されたメトリクスです。

Q: Amazon DevOps Guru for RDS の使用を開始する方法を教えてください。

DevOps Guru for RDS の使用を開始するには、RDS コンソールで Performance Insights が有効になっていることを確認してから、Amazon Aurora データベースに対して DevOps Guru を有効にします。DevOps Guru を使用すれば、分析カバレッジの境界を AWS アカウント全体として選択することも、DevOps Guru に分析させる特定の AWS CloudFormation スタックを指定することも、AWS タグを使用して DevOps Guru に分析させるリソースグループを作成することもできます。

Q: Amazon DevOps Guru for RDS はどのような種類の問題を検出できますか?

Amazon DevOps Guru for RDS は、ロックパイルアップ、接続ストーム、SQL リグレッション、CPU と I/O の競合、メモリの問題など、アプリケーションサービスの品質に影響を与える可能性のあるさまざまなパフォーマンス問題を特定できます。

Q: DevOps Guru for RDS は、Amazon RDS Performance Insights とどのように異なりますか?

Amazon RDS Performance Insights は、Amazon RDS データベースパフォーマンスメトリクスを収集して視覚化するデータベースパフォーマンスのチューニングとモニタリングを行う機能で、データベースの負荷をすばやく評価し、いつどこに措置を講じたらよいかを判断するのに役立ちます。Amazon DevOps Guru for RDS は、これらのメトリクスをモニタリングし、データベースでパフォーマンスの問題が発生していることを検出します。さらに、メトリクスを分析して、何が問題で、何ができるかを通知するように設計されています。

Amazon Aurora 料金の詳細

料金ページを見る
構築を始めましょう。
Amazon Aurora の使用を開始する
ご不明な点がありますか?
お問い合わせ