全般

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 および 5.7 と強い互換性があります。MyISAM ストレージエンジンなど、特定の MySQL の特徴は Amazon Aurora で使用できません。

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

これは、現在お客様が PostgreSQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Amazon Aurora データベースエンジンは、PostgreSQL 9.6 および 10 との強い互換性を持つよう設計され、RDS for PostgreSQL 9.6 および 10 でサポートされる 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 時間以内に完了しますが、データの形式およびデータセットのサイズにより時間が異なります。詳細については、MySQL データベースを Amazon Aurora に移行するためのベストプラクティスを参照してください。

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

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

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 オペレーションを排除するよう設計されていました。書き込み IO はストレージレイヤーが耐久性の高い書き込みを実現するためにトランザクションログレコードをプッシュする時にのみ消費します。書き込み IO は 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 と互換性を持つように設計されているため、既存の 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 単位で最大 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 分前) から 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
レプリケーションタイプ 非同期的 (ミリ秒単位) 非同期的 (秒単位)
プライマリへのパフォーマンスの影響
フェイルオーバーターゲットとして機能 はい (データ損失なし) はい (数分間データ損失の可能性)
自動フェイルオーバー はい いいえ
ユーザー定義のレプリケーション遅延サポート いいえ はい
プライマリに対する異なるデータまたはスキーマのサポート いいえ はい

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

はい。Aurora MySQL では、論理または物理のいずれかのレプリケーションを使用して、クロスリージョンの Aurora レプリカを設定できます。

論理レプリケーションは、最大 5 つのセカンダリ AWS リージョンにレプリケートでき、シングルスレッドの MySQL binlog レプリケーションをベースとして利用しています。そのため、レプリケーションラグが、変更率または適用率、および選択された特定のリージョン間のネットワーク通信の遅延による影響を受けます。物理レプリケーション (Aurora Global Database) は、お使いのデータベースをアプリケーションの提供に全面的に利用可能とする専用のインフラストラクチャであり、1 秒未満という一般的なレイテンシーを特徴とするセカンダリリージョンの 1 つにレプリケートできます。低レイテンシーのグローバルな読み取りと災害復旧を実現するために、Global Database の使用をお勧めします。

今のところ、Aurora PostgreSQL でクロスリージョンレプリカはサポートされていません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

リージョンをまたがる災害復旧は手動プロセスであり、ここで、読み取り/書き込みワークロードを取得できるようにセカンダリリージョンを昇格させます。

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

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

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

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

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

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

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

この機能は、Amazon Aurora MySQL で利用できます。

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

Amazon RDS マネジメントコンソールでのわずか数回のクリックにより、Aurora Global Database を作成できます。あるいは、SDK または CLI を使用することもできます。Aurora Global Database 内のリージョンにつき、少なくとも 1 つのインスタンスをプロビジョニングする必要があります。

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

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

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

いいえ。プライマリリージョンが利用不可になる場合は、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 の 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: Amazon Aurora は HIPAA コンプライアンス要件のあるアプリケーションで使用できますか?

はい。Aurora の MySQL 互換版と PostgreSQL 互換版は HIPAA の要件を満たしているため、これらを使用して HIPAA 準拠のアプリケーションを作成し、AWS との事業提携契約 (BAA) に基づく保護医療情報 (PHI) などの医療関連情報を保存することができます。既に BAA を締結している場合は、BAA の適用を受けているアカウントでこのサービスの使用を開始するために何も行う必要はありません。AWS との BAA を締結していない場合や、AWS の HIPAA 準拠のアプリケーションについてご不明な点がある場合は、お問い合わせください。

サーバーレス

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

Amazon Aurora Serverless は、Amazon Aurora の MySQL 互換版向けのオンデマンド自動スケーリング構成です。Aurora Serverless DB クラスターは、アプリケーションニーズに応じて、自動的に起動、シャットダウン、およびキャパシティーのスケールアップまたはスケールダウンを行います。Aurora Serverless では、不定期、断続的、または予測不能なワークロード向けに、比較的シンプルでコスト効率の良いオプションを提供しています。詳細については、Amazon Aurora ユーザーガイドを参照してください。

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

現在、Aurora Serverless は MySQL 5.6 互換の Aurora で利用できます。

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

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

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

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

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

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

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

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

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

Aurora Serverless では、データベース容量は Aurora Capacity Unit (ACU) で測定されます。ACU 使用量に応じた毎秒固定レートで、データベースがアクティブになるたびに最低 5 分間使用されます。 ストレージと I/O の料金は、プロビジョン構成もサーバーレス構成も同じです。Aurora Serverless の料金の例を確認してください。

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 を活用するにはクエリにどのような変更を加える必要がありますか?

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

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

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

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

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

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

いいえ。クエリに対する IO コストはストレージレイヤーで計量されており、Parallel Query をオンにすると同じか、それ以上になります。改善されるのはクエリのパフォーマンスです。

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

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

Parallel Query は MySQL 5.6 に対応した Amazon Aurora のバージョン v1.18.0 以降で使えます。Parallel Query は MySQL 5.7 に対応した Aurora と、PostgreSQL に対応した Aurora にも拡張する計画です。

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

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

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

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

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

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

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

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

Amazon Aurora 料金の詳細

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