全般

Amazon Aurora とは?

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

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

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

Amazon Aurora MySQL は互換性がありますか?

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

現在の Amazon Aurora MySQL のリリース互換性情報については、ドキュメントで確認することができます。

Amazon Aurora PostgreSQL は互換性がありますか?

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

現在の Amazon Aurora PostgreSQL のリリース互換性情報については、ドキュメントで確認することができます。

Amazon では Aurora PostgreSQL と Aurora で利用可能なすべての拡張機能を完全にサポートしています。Aurora PostgreSQL のサポートが必要な場合は、AWS サポートにご連絡ください。アクティブな AWS プレミアムサポートのアカウントをお持ちの場合、Aurora 固有の問題については、AWS プレミアムサポートにご連絡ください。

どのように Aurora を開始すればよいのですか?

Aurora を試用するには、AWS マネジメントコンソールにサインインし、[データベース] カテゴリの [RDS] を選択して、データベースエンジンとして Amazon Aurora を選択します。詳細なガイダンスとリソースについては、「Aurora の開始方法」のページをご覧ください。

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

Aurora が利用可能なリージョンについては、こちらを参照してください。

MySQL から Aurora に移行する方法、およびその逆の方法を教えてください。

MySQL から Aurora へ、あるいはその逆に移行したい場合、いくつかの選択肢があります。

  • 標準の mysqldump ユーティリティを使用して MySQL からデータをエクスポートし、mysqlimport ユーティリティを使用して Aurora にデータをインポートします。その逆の方法も可能です。
  • また、Amazon RDS の DB スナップショットの移行機能を利用して、AWS マネジメントコンソールで Amazon RDS for MySQL DB スナップショットを Aurora に移行します。

ほとんどの場合、Aurora への移行は 1 時間以内に完了しますが、データの形式およびデータセットのサイズによって時間が異なります。詳細については、MySQL データベースを Amazon Aurora に移行するためのベストプラクティスを参照してください。

PostgreSQL から Aurora に移行する方法や、その逆の方法を教えてください。

PostgreSQL から Aurora に移行したり、その逆を行いたい場合は、いくつかの選択肢があります。

  • 標準の pg_dump ユーティリティを使用して PostgreSQL からデータをエクスポートし、pg_restore ユーティリティを使用して Aurora にデータをインポートします。その逆の方法も可能です。
  • また、RDS の DB スナップショットの移行機能を利用して、AWS マネジメントコンソールで Amazon RDS for PostgreSQL DB スナップショットを Aurora に移行します。

ほとんどの場合、Aurora への移行は 1 時間以内に完了しますが、データの形式およびデータセットのサイズによって時間が異なります。

Babelfish for Aurora PostgreSQL を使用して、SQL Server データベースを Amazon Aurora PostgreSQL 互換エディションに移行できます。お客様のアプリケーションはそのままお使いいただけます。詳細については、こちらの Babelfish ドキュメントをご参照ください。

Amazon Aurora PostgreSQL 互換エディションを使用するためにクライアントドライバーの変更が必要ですか?

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

パフォーマンス

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

Amazon Aurora は、データベースワークロード用の SSD ベースの仮想化ストレージレイヤーとデータベースエンジンを緊密に統合し、ストレージシステムに対する書き込みを削減し、ロックの競合を最小化し、データベースのプロセススレッドによる遅延を排除することで、MySQL と比較して大幅に高いパフォーマンスを提供します。

SysBench による r3.8xlarge インスタンスのテストの結果、Amazon Aurora は 500,000 SELECT/秒および 100,000 UPDATE/秒のパフォーマンスを示しました。これは同じハードウェアで実行する MySQL の 5 倍のパフォーマンスです。このベンチマークとその再現方法の詳細な手順は、Amazon Aurora MySQL 互換エディションのパフォーマンスベンチマークに関するガイドに記載されています。

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

Amazon Aurora では、データベースワークロード用の SSD ベースの仮想化ストレージレイヤーとデータベースエンジンを緊密に統合し、ストレージシステムに対する書き込みを削減し、ロックの競合を最小化し、データベースのプロセススレッドによる遅延を排除することで、PostgreSQL と比較して大幅に高いパフォーマンスが実現されています。

SysBench による r4.16xlarge インスタンスのテストの結果、Amazon Aurora は SELECT/秒および UPDATE/秒で、同じハードウェアで実行する PostgreSQL の 3 倍のパフォーマンスを示しました。このベンチマークとその再現方法の詳細な手順は、Amazon Aurora PostgreSQL 互換エディションのパフォーマンスベンチマークに関するガイドに記載されています。

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

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

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

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

請求

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

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

Aurora は AWS 無料利用枠で利用できますか?

現時点では、Aurora 向けの AWS 無料利用枠はありません。ただし、Auroraはデータを1つのリージョンの3つのアベイラビリティーゾーンに永続的に保存し、1つのデータコピーに対してのみ料金を請求します。データベースクラスターのサイズの最大 100% のバックアップには料金はかかりません。また、データベースクラスターに設定したバックアップ保持期間中のスナップショットにも課金されません。

Aurora はデータを 3 つのアベイラビリティーゾーンにリプリケートします。実際のストレージ料金は、料金表ページに書かれている料金の 3 倍になるということですか?

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

Aurora の I/O オペレーションとは何ですか? どのように計算されるのですか?

I/O オペレーションは、Aurora データベースエンジンによって SSD ベースの仮想ストレージレイヤーに対して実行されます。各データベースページの読み取りオペレーションは 1 I/O とカウントされます。
Aurora データベースエンジンは、ストレージレイヤーに対して読み取りを発行し、キャッシュ内のメモリに存在しないデータベースページを取得します。

  • クエリトラフィックをメモリまたはキャッシュから完全に提供できる場合、メモリからデータページを取得するための料金は発生しません。
  • クエリトラフィックをメモリから完全に提供できない場合は、ストレージから取得する必要のあるデータページについて課金されます。
    各データベースページについては、Amazon 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 リクエストを消費しているか確認できます。I/O 消費を確認するには、Amazon RDS セクションのコンソールでインスタンスのリストから Aurora インスタンスを選び、モニタリングセクションの「VolumeReadIOPs」と「VolumeWriteIOPs」メトリクスを確認します。

I/O オペレーションの料金の詳細については、「Aurora の料金ページ」をご覧ください。データベースクラスターを Aurora Standard 設定にすると、読み取りと書き込み I/O オペレーションに対して課金されます。データベースクラスターを Amazon Aurora I/O 最適化に設定すると、読み取りと書き込み I/O オペレーションの料金は発生しません。

Aurora Standard と Aurora I/O 最適化とは何ですか?

Aurora では、料金パフォーマンスと料金予測可能性のニーズに基づいて 2 つの設定オプションから選択することで、データベース支出を柔軟に最適化できます。2 つの設定オプションには、Aurora Standard と Aurora I/O 最適化があります。どちらのオプションも、I/O やストレージのプロビジョニングを前もって行う必要はなく、I/O オペレーションをスケールして最も要求の厳しいアプリケーションをサポートすることが可能です。

Aurora Standard は、I/O 使用量が少ないか中程度のアプリケーションの大部分に対して費用対効果の高い料金設定を提供するデータベースクラスター設定です。Aurora Standard では、データベースインスタンス、ストレージ、リクエスト I/O ごとの料金を支払います。

Aurora I/O 最適化は、支払い処理システム、e コマースシステム、金融アプリケーションなどの I/O 集約型アプリケーションの料金パフォーマンスを向上させるデータベースクラスター設定です。I/O 支出が Aurora データベースの総支出の 25% を超える場合、Aurora I/O 最適化を使用すると、I/O 集約型のワークロードのコストを最大 40% 節約できます。Aurora I/O 最適化では、読み取りと書き込み I/O オペレーションに料金がかからないため、すべてのアプリケーションについて予測可能な料金設定ができ、I/O の変動制が大きいワークロードに最適です。

Aurora の I/O 最適化はどのような場合に使用すべきですか?

Aurora I/O 最適化は、あらゆるアプリケーションで予測可能なコストが必要な場合に最適な選択肢です。書き込み高スループットを必要とする場合や、大量のデータを処理する分析クエリを実行する I/O 集約型のアプリケーションでは、料金パフォーマンスが向上します。I/O 支出が Aurora 請求額の 25% を超えるお客様の場合、Aurora I/O 最適化を使用すると、I/O 集約型のワークロードのコストを最大 40% 節約できます。

Aurora I/O 最適化を使用するために、既存のデータベースクラスターを移行するにはどうすればよいですか?

AWS マネジメントコンソールで利用できるワンクリックエクスペリエンスを使用して、既存のデータベースクラスターのストレージタイプを Aurora I/O 最適化に変更できます。AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を呼び出してこの変更を行うこともできます。

Aurora I/O 最適化と Aurora Standard 設定を切り替えることはできますか?

30 日に 1 回、既存のデータベースクラスターを Aurora I/O 最適化に切り替えることができます。いつでも Aurora Standard に戻すことができます。

Aurora I/O 最適化はリザーブドインスタンスでも機能しますか?

はい。Aurora I/O 最適化は既存の Aurora リザーブドインスタンスでも動作します。Aurora は Aurora Standard と Aurora I/O 最適化リザーブドインスタンスとの料金の差を自動的に計算します。Aurora I/O 最適化によるリザーブドインスタンスの割引を利用すると、I/O 支出をさらに節約できます。

Aurora I/O 最適化を使用すると、バックトラック、スナップショット、エクスポート、継続的バックアップの料金が変わることはありますか?

Aurora I/O Optimized によるバックトラック、スナップショット、エクスポート、継続的バックアップの料金に変更はありません。

Aurora の I/O 最適化機能を備えた Aurora Global Database を使用して、リージョン間でデータをリプリケーションするために必要な I/O オペレーションの料金を引き続き支払う必要がありますか?

はい。リージョン間でデータをリプリケーションするために必要な I/O オペレーションの料金は引き続き適用されます。Aurora I/O 最適化は、データリプリケーションとは異なり、読み取りと書き込み I/O オペレーションには課金しません。

Amazon Aurora Optimized Reads for Aurora PostgreSQL にはどの程度のコストがかかりますか?

Amazon Aurora Optimized Reads for Aurora PostgreSQL では、インテルベースの R6id および Graviton ベースの R6gd インスタンスの料金以外に追加料金は発生しません。詳細については、Aurora の料金ページにアクセスしてください。

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

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

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

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

Amazon Aurora DB インスタンスに関連するコンピューティングリソースをスケールするには、Aurora Serverless を使用する方法と手動調整の 2 つの方法があります。

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

また、AWS マネジメントコンソールで目的の DB インスタンスタイプを選択することにより、データベースに関連付けられているコンピューティングリソースを手動でスケールすることもできます。要求された変更は、指定されたメンテナンスウィンドウ中に適用されます。あるいは、[すぐに適用] フラグを使用すると、DB インスタンスタイプをすぐに変更できます。

これらのオプションはいずれも、スケーリング操作が実行されている数分間の可用性に影響を与えます。保留中の他のシステム変更も適用されることにご注意ください。

バックアップと復元

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

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

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

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

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

Amazon Auroraは、リージョンの3つのAvailability Zone (AZ) (アベイラビリティーゾーン (AZ))にわたってデータを自動的に永続化し、データが失われることのない正常なAZでデータベースの復元を自動的に試みます。Amazon Aurora ストレージでデータが利用不可になるという稀なケースでは、DB スナップショットから復元するか、新しいインスタンスに任意の時点を指定した復元を実行できます。ポイントインタイムの復元オペレーションを実行する場合、最新の復元可能時間は直近で 5 分前までです。

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

DB インスタンスを削除する際に、最後の DB スナップショットを作成することができます。DB スナップショットを作成した場合、後日そのスナップショットを使用して、削除した DB インスタンスを復元することができます。Amazon Aurora は、DB インスタンスが削除された後も、このユーザーが作成した最終的な DB スナップショットと手動で作成されたその他の DB スナップショットをすべて保持します。DB インスタンスが削除された後は DB スナップショットのみが保持されます (つまり、ポイントインタイムの復元のために作成された自動バックアップは保持されません)。

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

はい。Aurora では、データベースのスナップショットを作成できます。これを使用して、後でデータベースを復元できます。スナップショットは別の AWS アカウントと共有でき、受取人アカウントの所有者は、そのスナップショットを使用して、お客様のデータを含む DB を復元できます。スナップショットを公開して、誰でもお客様の公開データを含む DB を復元できるように選択することもできます。

この機能を使用して、異なる AWS アカウントを持つさまざまな環境 (本番、開発/テスト、ステージングなど) でデータを共有できます。また、メインの AWS アカウントが侵害された場合でも、すべてのデータのバックアップを別個のアカウントで安全に保持できます。

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

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

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

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

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

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

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

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

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

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

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

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

高可用性とレプリケーション

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

Amazon Aurora はデータベースボリュームを自動で 10 GB のセグメントに分割し、多数のディスクに分散します。10 GB 単位の各データベースボリュームが、3 つのアベイラビリティーゾーンにわたって 6 つの方法でレプリケートされます。Amazon Aurora は最大 2 つまでのデータのコピー損失をデータベースの書き込み能力に影響せずに透過的に処理し、最大 3 つまでのコピー損失を読み込み能力に影響せずに処理します。

また、Amazon Aurora ストレージは自己修復機能を備えています。データブロックおよびディスクはエラー検出のために継続的にスキャンされ、自動的に修復されます。

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

他のデータベースと違い、データベースクラッシュ後、Amazon Aurora はデータベースを利用できるようにする前に最後のデータベースチェックポイント (通常 5 分前) から REDO ログをリプレイし、すべての変更が適用されたか確認する必要はありません。これにより、多くの場合データベースの再起動時間を 60 秒以内に短縮します。

また Amazon Aurora はバッファキャッシュをデータベース処理から除外し、再起動時にすぐ利用できるようにします。そのため、ブラウンアウトを避けるためにキャッシュが再生成されるまでアクセスを調整する必要がなくなります。

Aurora ではどのようなレプリケーションがサポートされていますか?

Amazon Aurora MySQL 互換エディションと Amazon Aurora PostgreSQL 互換エディションは、同じAWS リージョン内のプライマリインスタンスと同じ基盤ボリュームを共有する Amazon Aurora レプリカをサポートしています。プライマリにより実行された更新は、すべての Amazon Aurora レプリカで確認できます。

Amazon Aurora MySQL 互換エディションを使用すると、MySQL の binlog ベースのレプリケーションエンジンに基づいてクロスリージョン MySQL リードレプリカを作成することもできます。MySQL リードレプリカでは、プライマリインスタンスのデータはトランザクションとしてレプリカでリプレイされます。読み込みのスケーリングおよび高可用性など、ほとんどの使用目的では Amazon Aurora レプリカを使用することをお勧めします。

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

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

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

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 レプリケーションに基づいています。レプリケーションラグは変更率または適用率、および選択された特定のリージョン間のネットワーク通信の遅延による影響を受けます。

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

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

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

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

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

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

はい。クラスターの各インスタンスに昇格優先階層を割り当てることができます。プライマリインスタンスが失敗した場合、Amazon RDS は最も高い優先度のレプリカをプライマリに昇格します。複数の Aurora レプリカで同じ優先度を共有する場合、Amazon RDS は最大サイズのレプリカを昇格します。複数の Aurora レプリカで同じ優先度とサイズを共有する場合、Amazon RDS は同じ昇格階層の任意のレプリカを昇格します。

フェイルオーバーロジックの詳細については、Amazon Aurora ユーザーガイドをお読みください。

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

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

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

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

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

Amazon Aurora レプリカを追加できます。同じ AWS リージョン内の Aurora レプリカ間で、プライマリインスタンスと同じ基盤となるストレージを共有します。任意の Aurora レプリカをデータを損失することなくプライマリに昇格できるため、プライマリ DB インスタンスに障害が発生した際の耐障害性を向上するために使用できます。

データベースの可用性を高めるためには、3 つのアベイラビリティーゾーンに任意に 1 から 15 個のレプリカを作成するだけで、Amazon RDS が自動でデータベースの機能停止時のフェイルオーバープライマリ対象としてそれらのレプリカを認識します。Amazon Aurora Global Database は、お使いのデータベースを複数の AWS リージョンで利用する場合に使用できます。これにより、データベースのパフォーマンスに影響を及ぼさずにデータがレプリケートされ、リージョン全体の停止からのディザスタリカバリが可能になります。

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

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

  • 同一、または異なるアベイラビリティーゾーンに Aurora レプリカを作成している場合、障害が発生すると、Aurora は DB インスタンスの Canonical Name Record (CNAME) を反転させ、正常なレプリカを指定します。指定されたレプリカは新しいプライマリに昇格します。フェイルオーバーは開始から終了まで通常 30 秒以内に完了します。回復性を高め、フェイルオーバーを高速化するには、アプリケーション接続を維持したままフェイルオーバー DB インスタンスに自動的に接続する Amazon RDS Proxy の使用を検討してください。プロキシはフェイルオーバーをアプリケーションに透過的に表示し、フェイルオーバー時間を最大 66% 短縮します。
  • DB インスタンスまたは AZ が使用不能になった時でも、Aurora Serverless v1 を実行していれば、別の AZ 内に Aurora が DB インスタンスを自動的に再作成します。Aurora Serverless v2 は、フェイルオーバーや他の高可用性機能のためにプロビジョニングされたように機能します。詳細については、「Aurora Serverless v2 と高可用性」を参照してください。 
  • Aurora レプリカを作成しておらず(つまり、インスタンスは 1 つ)、Aurora Serverless を使用していない場合、Aurora は元のインスタンスと同じアベイラビリティーゾーンに新しい DB インスタンスの作成を試みます。オリジナルのインスタンスの置換処理はベストエフォート型であり、アベイラビリティーゾーンで広範囲に影響を及ぼす問題がある時などは失敗する可能性があります。

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

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

プライマリインスタンスでの問題は Amazon Aurora により自動検出され、フェイルオーバーがトリガーされます。クラスターエンドポイントを使っていれば、読み取りもしくは書き込みのための接続は Amazon Aurora レプリカに自動でリダイレクトされ、レプリカはプライマリに昇格します。

さらに、Aurora レプリカが処理していた読み取りトラフィックは一時的に中断されます。クラスターリーダーエンドポイントを使って読み取りトラフィックを Aurora レプリカに送っている場合は、古いプライマリノードがレプリカとして復旧するまでの間、新たにプライマリに昇格した Aurora レプリカに対し読み取り専用接続が行われます。

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

Amazon Aurora レプリカは、同じ AWS リージョン内のプライマリインスタンスと同じデータボリュームを共有しているため、実質的にレプリケーションラグはありません。通常、ラグは数十ミリ秒です。

クロスリージョンレプリケーションの場合、binlog ベースの論理レプリケーションラグは変更率または適用率、およびネットワーク通信の遅延に応じて無制限に増大する可能性があります。ただし、通常の状況では 1 分未満のレプリケーションラグが一般的です。Amazon Aurora Global Database の物理レプリケーションを使用するクロスリージョンレプリカには、1 秒未満という標準的なラグが生じます。

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

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

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

Amazon Aurora Global Database とは何ですか?

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

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

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

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

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

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

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

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

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

セキュリティ

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

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

Amazon Aurora は転送中と保存中にデータを暗号化しますか?

はい。Amazon Aurora では、SSL (AES-256) を使用してデータベースインスタンスとアプリケーションの間の通信が保護されています。Amazon Aurora では、AWS Key Management Service (AWS KMS) で管理されるキーを使って、データベースを暗号化できます。

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

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

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

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

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

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

はい、Aurora の MySQL 互換エディションと PostgreSQL 互換エディションは、HIPAA に対応しています。それらを使用して HIPAA 準拠のアプリケーションを構築し、AWS との履行済み事業提携契約 (BAA) に基づく保護された医療情報 (PHI) を含む医療関連情報を保存できます。既に AWS で BAA を締結している場合、BAA の適用を受けているアカウントでこのサービスの使用を開始するためにこれ以上何も行う必要はありません。AWS を使用してコンプライアンスに準拠したアプリケーションを構築するための詳細については、「ヘルスケアプロバイダー」を参照してください。

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

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

Aurora データベースへのセキュリティ脅威を検出するにはどうすればよいですか?

Aurora は Amazon GuardDuty と統合されており、Aurora データベースに保存されているデータへの潜在的な脅威を特定するのに役立ちます。GuardDuty RDS Protection は、アカウント内の既存および新規のデータベースへのログインアクティビティをプロファイリングおよびモニタリングし、カスタマイズされた機械学習モデルを使用して Aurora データベースへの疑わしいログインを検出します。詳細については、「Monitoring threats with GuardDuty RDS Protection」(GuardDuty RDS Protection を使用した脅威のモニタリング) および「GuardDuty RDS Protection ユーザーガイド」を参照してください。

サーバーレス

Amazon Aurora Serverless とは何ですか?

Aurora Serverless は、Amazon Aurora のオンデマンドの Auto Scaling 設定です。 Aurora Serverless を使用すると、データベース容量を管理せずにデータベースをクラウドで実行できます。データベース容量を手動で管理すると時間がかかり、データベースリソースの非効率的な使用につながります。Aurora Serverless では、データベースを作成し、必要に応じてデータベースの容量範囲を指定し、アプリケーションを接続します。Aurora は、アプリケーションのニーズに基づいて、指定された範囲内で容量を自動的に調整します。

データベースがアクティブなときに使用したデータベース容量に対して、秒単位でお支払いいただきます。Aurora Serverless の詳細を確認し、Amazon RDS マネジメントコンソールでいくつかのステップだけで使い始めることができます。

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

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

さらに、データベース容量を 0.5 Aurora Capacity Unit (ACU) の増分でスケールするため、データベース容量はアプリケーションのニーズに厳密に一致します。

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

Aurora Serverless v2 がサポートするすべての Aurora 機能は何ですか?

Aurora Serverless v2 は、リードレプリカマルチ AZ 構成Aurora Global DatabaseRDS プロキシ、および Performance Insights など、プロビジョンされた Aurora のすべての機能をサポートします

既存の 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 の使用を開始するためのダウンタイムを最小限に留めます。

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

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

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

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

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

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

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

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

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

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

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

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

Aurora Serverless では、データベースの容量は ACU で測定されます。ACU 使用量について 1 秒あたりの定額料金をお支払いいただきます。Aurora Serverless でワークロードを実行するためのコンピューティングコストは、選択したデータベースクラスター設定、つまり Aurora Standard または Aurora I/O 最適化によって異なります。料金と利用可能なリージョンについてはAurora の料金ページをご覧ください。

Parallel Query

Amazon Aurora Parallel Query とは何ですか?

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

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

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

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

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

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

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

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

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

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

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

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

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

Parallel Query 機能をどのようにオンまたはオフに変えることができますか?

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

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

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

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

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

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

詳細については、ドキュメントの Parallel Query を参照してください。

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

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

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

Parallel Query は、MySQL 5.7 および MySQL 8.0 互換バージョンの Amazon Aurora で利用可能です。

Parallel Query は他のすべての Aurora の機能と互換性がありますか?

Parallel Query は Aurora Serverless v2 および Backtrack と互換性があります。

Parallel Query を使用することでクエリが高速化される一方で、パフォーマンスの低下がほとんど発生しない場合、常にオンにしておくべきですか?

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

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

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

エクサバイト規模のクラウドデータウェアハウスについては、Amazon Redshift をご検討ください。

Optimized Reads

Amazon Aurora Optimized Reads for Aurora PostgreSQL とは何ですか?

Aurora PostgreSQL で利用可能な Amazon Aurora Optimized Reads は、費用対効果の高い新しいオプションであり、これを備えていないインスタンスと比較して、クエリレイテンシーが最大 8 倍改善し、コストが最大 30% 削減されます。これは、データベースインスタンスのメモリ容量を超える大規模なデータセットを使用するアプリケーションに最適です。

Amazon Aurora Optimized Reads for Aurora PostgreSQL はクエリのパフォーマンスをどのように改善しますか?

Amazon Aurora Optimized Reads インスタンスは、NVMe ベースの SSD ブロックレベルのローカルストレージ (Graviton ベースの R6gd およびインテルベースの R6id インスタンスで利用可能) を使用して、データベースインスタンスのメモリ容量を超えるデータセットを使用するアプリケーションのクエリレイテンシーを改善します。Optimized Reads には、階層化されたキャッシュや一時オブジェクトなどのパフォーマンスの強化が含まれます。

階層化されたキャッシュにより、読み取りを多用し、I/O が大量に発生するアプリケーション (運用ダッシュボード、異常検出、ベクトルベースの類似検索など) では、クエリレイテンシーが最大 8 倍改善し、コストが最大 30% 削減されます。これらの利点は、インメモリデータベースのバッファキャッシュから削除されたデータをローカルストレージに自動的にキャッシュし、そのデータへの後続のアクセスを高速化することによって実現されます。階層化されたキャッシュは、Aurora I/O-Optimized 設定を備えた Amazon Aurora PostgreSQL エディションでのみ使用できます。

一時オブジェクトは、Aurora PostgreSQL によって生成された一時テーブルをローカルストレージに配置することでクエリ処理の高速化を実現し、ソート、ハッシュ集計、高負荷の結合、および他のデータを多用するオペレーションを伴うクエリのパフォーマンスを改善します。

Amazon Aurora Optimized Reads for Aurora PostgreSQL はどのような場合に使用すべきですか?

Amazon Aurora Optimized Reads for Aurora PostgreSQL は、レイテンシーの影響を受けやすいアプリケーションや大規模なワーキングセットを使用するお客様に、ビジネス SLA を満たし、インスタンスでさらに多くのことを実行するための、費用対効果が魅力的な代替手段を提供します。

Amazon Aurora Optimized Reads for Aurora PostgreSQL は、どのデータベースインスタンスタイプでサポートされていますか? どのリージョンで利用できますか?

Amazon Aurora Optimized Reads は、インテルベースの R6id および Graviton ベースの R6gd インスタンスでご利用いただけます。Aurora が利用可能なリージョンについては、こちらを参照してください。

Aurora Optimized Reads for Aurora PostgreSQL は、Amazon Aurora のどのエンジンバージョンをサポートしていますか?

Amazon Aurora Optimized Reads は、R6id および R6gd インスタンス上の Aurora の PostgreSQL 互換エディションでご利用いただけます。サポートされているエンジンバージョンは 15.4 以降、Aurora PostgreSQL では 14.9 以降です。

Aurora Serverless v2 で Amazon Aurora Optimized Reads for Aurora PostgreSQL を使用できますか?

Amazon Aurora Optimized Reads は、Aurora Serverless v2 (ASv2) ではご利用いただけません。

Aurora Standard および Aurora I/O-Optimized 設定で、Amazon Aurora Optimized Reads for Aurora PostgreSQL を利用できますか?

はい。Amazon Aurora Optimized Reads は両方の設定でご利用いただけます。どちらの設定でも、Optimized Reads 対応インスタンスは一時テーブルを NVMe ベースのローカルストレージに自動的にマッピングし、分析クエリとインデックスの再構築のパフォーマンスを改善します。

読み取りを多用し、大量の I/O が発生するワークロードについて、Aurora I/O-Optimized を使用するように設定された、Aurora PostgreSQL 上の Optimized Reads 対応インスタンスは、データベースインスタンスのメモリ容量を超える大規模なデータセットを使用するアプリケーションのために、NVMe ベースのローカルストレージ上のメモリから削除されるデータを自動的にキャッシュします。これにより、このインスタンスは、この構成を使用しないインスタンスと比較してクエリレイテンシーを最大 8 倍改善し、コストを 30% 削減します。

Amazon Aurora Optimized Reads for Aurora PostgreSQL の使用を開始するにはどうすればよいですか?

お客様は、AWS マネジメントコンソール、CLI、SDK を通じて Amazon Aurora Optimized Reads の使用を開始できます。Optimized Reads は、デフォルトですべての R6id および R6gd インスタンスでご利用いただけます。この機能を使用するために必要なのは、既存の Aurora データベースクラスターを変更して R6id および R6gd インスタンスを含めるか、またはこれらのインスタンスを使用して新しいデータベースクラスターを作成することだけです。使用を開始するには、Amazon Aurora Optimized Reads ドキュメントをご覧ください。

Amazon Aurora Optimized Reads for Aurora PostgreSQL にはどの程度のローカルストレージを使用できますか?

R6id および R6gd インスタンスで使用可能なローカルストレージの約 90% は Optimized Reads に使用でき、Aurora は SSD 書き込み増幅の影響を軽減するために NVMe ストレージの 10% が予約されます。使用可能なストレージの割り当ては、有効になっている Optimized Reads の機能によって異なります。

Optimized Reads で一時オブジェクトと階層化されたキャッシュの両方の機能を使用する場合、ローカルストレージ内の一時オブジェクトのために使用できる領域は、これらのデータベースインスタンスで使用できるメモリサイズの 2 倍に相当します。これは、Aurora PostgreSQL の一時オブジェクトストレージの現在のサイズと一致します。残りのローカルストレージのディスク領域は、データのキャッシュのために使用できます。

Optimized Reads で一時オブジェクト機能のみを使用する場合、使用可能なすべてのローカルストレージのディスク領域を一時オブジェクトのために使用できます。例えば、r6gd.8xlarge インスタンスで一時オブジェクトと階層化されたキャッシュの両方の機能を使用する場合、一時オブジェクトのために 534 GiB (メモリ容量の 2 倍) が予約され、階層化されたキャッシュのために 1,054 GiB が予約されます。

ローカルストレージに障害が発生した場合はどうなりますか?

ローカルストレージに障害が発生した場合、Aurora は自動的にホストの置き換えを実行します。マルチノードデータベースクラスターでは、これによりリージョン内のフェイルオーバーがトリガーされます。

Amazon Aurora Optimized Reads for Aurora PostgreSQL は、データベースのフェイルオーバー発生時のクエリレイテンシーにどのような影響を及ぼしますか?

データベースのフェイルオーバーが発生した場合、フェイルオーバー後にクエリレイテンシーが一時的に増大します。このレイテンシーの増大は時間の経過とともに小さくなり、最終的にはフェイルオーバー前のクエリレイテンシーに追いつきます。この追いつきに要する期間は、クラスターキャッシュ管理 (CCM) を有効にすることで短縮できます。CCM を使用すると、お客様は、特定の Aurora PostgreSQL データベースインスタンスをフェイルオーバーターゲットとして指定できます。

CCM が有効になっている場合、指定されたフェイルオーバーターゲットのローカルストレージキャッシュはプライマリインスタンスのローカルストレージキャッシュを厳密にミラーリングするため、フェイルオーバー後の追いつきに要する時間が短くなります。ただし、指定されたフェイルオーバーターゲットが、ライターインスタンスのワークロードとは別の読み取りワークロードを処理するためにも使用されている場合、CCM を有効にすると、ローカルストレージキャッシュの長期的な有効性に影響が生じる可能性があります。

したがって、リーダーをスタンバイフェイルオーバーとして指定する必要があるワークロードを実行しているお客様は、フェイルオーバー後にクエリレイテンシーが迅速に元に戻る可能性を高めるために、CCM を有効にする必要があります。指定したフェイルオーバーターゲットで別個のワークロードを実行しているお客様には、CCM を有効にする前に、フェイルオーバー後のレイテンシーの即時回復のニーズと、キャッシュパフォーマンスの長期的な有効性のバランスを取ることをお勧めします。

生成系 AI

pgvector とは何ですか?

pgvector は、Amazon Aurora PostgreSQL 互換エディションでサポートされている PostgreSQL のオープンソース拡張機能です。

pgvector は Aurora PostgreSQL でどのような機能を有効化しますか?

pgvector を使用すると、 Amazon BedrockAmazon SageMaker からの埋め込みなど、データベース内の機械学習 (ML) モデルや人工知能 (AI) モデルから生成された何十億もの埋め込みを保存、検索、インデックス付け、クエリできます。ベクター埋め込みとは、テキスト、画像、動画などのコンテンツのセマンティックな意味を表す数値表現です。
 
pgvector を使用すると、Aurora PostgreSQL データベース内の埋め込みにクエリを実行して、ベクトルとして表されるこれらのデータ型を Aurora の他の表形式データと組み合わせて、効率的なセマンティック類似性検索を実行できます。これにより、類似するテキストや画像に基づくパーソナライズされた推奨事項、面接のメモに基づいた候補者のマッチング、チャットボット、成功した議事録やチャット記録の対話に基づくカスタマーサービスの次善アクションの推奨事項など、生成 AI やその他の AI/ML システムを新しいタイプのアプリケーションに使用できるようになります。 
 
ベクトルデータベースの機能に関するブログを読み、pgvector エクステンションを使用して Aurora PostgreSQL データベースに埋め込みを保存する方法、インタラクティブな質問応答チャットボットを作成する方法、pgvector と Aurora 機械学習のネイティブ統合を使用して感情分析を行う方法を学びましょう。

pgvector はオーロラの機械学習と併用できますか?

はい。Aurora 機械学習 (ML) は ML モデルを SQL 関数として公開するため、標準 SQL を使用して ML モデルを呼び出し、データを渡し、予測をクエリ結果として返すことができます。pgvector では、データベースにベクター埋め込みを保存する必要があります。そのため、ソーステキストまたは画像データで ML モデルを実行して埋め込みを生成し、埋め込みをバッチで Aurora PostgreSQL に移動する必要があります。

Aurora ML は、これをリアルタイム処理にして、モデルから最新の埋め込みを返す Amazon BedrockAmazon SageMaker を定期的に呼び出すことで、Aurora PostgreSQL への埋め込みを最新の状態に保つことができます。

Aurora Optimized Reads for Aurora PostgreSQL は pgvector のパフォーマンスにどのように役立ちますか?

pgvector を使用した Amazon Aurora PostgreSQL Optimized Reads では、使用可能なインスタンスメモリを超えるワークロードにおいて、ベクトル検索の 1 秒あたりのクエリ数が最大 9 倍に増加します。これは、Optimized Reads で使用可能な、階層化されたキャッシュ機能によって可能になります。この機能は、インメモリデータベースのバッファキャッシュから削除されたデータをローカルストレージに自動的にキャッシュして、そのデータに対する以降のアクセスを高速化します。

ゼロ ETL 統合

Amazon Redshift との Aurora ゼロ ETL 統合はいつ使用すべきですか?

トランザクションデータにほぼリアルタイムでアクセスする必要がある場合は、Amazon Redshift との Amazon Aurora ゼロ ETL 統合を使用してください。この統合により、簡単な SQL コマンドで Amazon Redshift ML を活用できるようになります。

Amazon Aurora のどのエンジンとバージョンがゼロ ETL 統合をサポートしていますか?

Amazon Redshift との Amazon Aurora ゼロ ETL 統合は、Aurora MySQL 3.05 バージョン (MySQL 8.0.32 互換) 以降の Aurora MySQL 互換エディションで利用できます。利用できるリージョンは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、欧州 (アイルランド)、欧州 (フランクフルト)、欧州 (ストックホルム) です。Aurora ゼロ ETL 統合と Amazon Redshift の統合は、米国東部 (オハイオ) リージョンの Aurora PostgreSQL 15.4 用の Aurora PostgreSQL 互換エディションでご利用いただけます。

ゼロ ETL 統合にはどのようなメリットがありますか?

Aurora ゼロ ETL 統合と Amazon Redshift の統合により、複雑なデータパイプラインを構築して維持する必要がなくなります。1 つまたは複数の Aurora データベースクラスターからのデータを 1 つの Amazon Redshift データベースクラスターに統合し、Amazon Aurora からのペタバイト単位のトランザクションデータに対して、Amazon Redshift を使用してほぼリアルタイムの分析と ML を実行できます。 

ゼロ ETL 統合は Amazon Aurora Serverless v2 と互換性がありますか?

Amazon Redshift との Amazon ゼロ ETL 統合は、Amazon Aurora Serverless v2 と互換性があります。Aurora Serverless v2Amazon Redshift Serverless の両方を使用すると、データパイプラインのインフラストラクチャを管理することなく、トランザクションデータの分析をほぼリアルタイムで生成できます。

ゼロ ETL 統合を開始するにはどうすればいいですか?

まず、Amazon RDS コンソールを使用してゼロ ETL 統合を作成します。これには、Aurora ソースと Amazon Redshift デスティネーションを指定します。統合が作成されると、Aurora データベースが Amazon Redshift にレプリケートされ、最初のシードが完了したらデータのクエリを開始できます。詳細については、Amazon Redshift との Amazon Aurora ゼロ ETL 統合に関するスタートガイドをお読みください。

ゼロ ETL 統合にはどれくらいの費用がかかりますか?

ゼロ ETL とデータ変更の継続的な処理に追加料金はかかりません。ゼロ ETL 統合の一環として作成された変更データの作成と処理に使用された既存の Amazon RDS および Amazon Redshift リソースには課金されます。これらのリソースには次のものが含まれます。

詳細については、Aurora の料金ページにアクセスしてください。

Amazon DevOps Guru for RDS

Amazon DevOps Guru for RDS とは?

Amazon DevOps Guru for RDS は、データベースのパフォーマンスと運用上の問題を自動的に検出および診断するように設計されています。Amazon RDS (Amazon Aurora を含む) の新しい機械学習を利用した機能であり、数日もかかっていた問題を数分以内に解決できます。

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 を使用すれば、専門家以外のユーザーがデータベースを管理しやすくなり、データベースの専門家がさらに多くのデータベースを管理できるように支援します。

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

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

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 に分析させるリソースグループを作成することもできます

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

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

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

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

Data API

データベースドライバーの代わりに Aurora で Data API を使用すべきなのはどのような場合ですか?

新しい最新のアプリケーション、特にリクエスト/レスポンスモデルで Aurora にアクセスする必要がある AWS Lambda で構築されたアプリケーションには、Data API を使用する必要があります。既存のアプリケーションがデータベースドライバーと高度に連動している場合、実行時間が長い場合、または開発者が一時テーブルなどのデータベース機能を利用したり、セッション変数を使用したりする場合は、Data API の代わりにデータベースドライバーを使用して永続的なデータベース接続を管理する必要があります。

どの Aurora エンジンとバージョンが Data API をサポートしていますか?

Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API AWS リージョンとデータベースバージョンの可用性は、当社のドキュメントに記載されています。現在 Aurora Serverless v1 用の Data API を使用しているお客様は、Aurora Serverless v2 に移行して、再設計された Data API と Aurora Serverless v2 のよりきめ細かなスケーリングを活用することをお勧めします。

Data API にはどのようなメリットがありますか?

Data APIを使用すると、モダンアプリケーション開発を簡素化および加速できます。Data API は使いやすく安全な HTTP ベースの API で、データベースドライバーをデプロイしたり、クライアント側の接続プールを管理したり、アプリケーションとデータベース間の複雑な VPC ネットワークを設定したりする必要がありません。また、Data API は、データベース接続を自動的にプールして共有することでスケーラビリティを向上させ、接続を頻繁に開いたり閉じたりするアプリケーションによる計算オーバーヘッドを軽減します。 

Data API は Aurora グローバルデータベースまたは Aurora Serverless v1 をサポートしていますか?

Aurora Serverless v1 の既存の Data API は、Aurora の PostgreSQL 互換エディションと MySQL 互換エディションの両方で Aurora Serverless v1 の機能として残ります。Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API は Aurora Serverless v1 をサポートしていません。Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API は、Aurora グローバルデータベースライターインスタンスをサポートします。

Data API を使用してデータベースで認証するにはどうすればよいですか?

ユーザーは、権限がある場合にのみで API オペレーションを呼び出すことができます。管理者は、権限を定義する AWS ID およびアクセス管理 (IAM) ポリシーをアタッチすることで、Data API を使用する権限をユーザーに付与できます。IAM ロールを使用している場合は、ポリシーをロールにアタッチすることもできます。Data API を呼び出すと、AWS Secrets Manager のシークレットを使用して Aurora DB クラスターの認証情報を渡すことができます。 

Data API の料金はいくらですか?

Aurora Serverless v1 での Data API の使用は、追加料金なしで引き続き利用できます。Aurora Serverless v2 および Aurora プロビジョニングインスタンスの Data API は、Aurora 料金ページに記載されている API リクエスト量に基づいて価格設定されます。Aurora Servless v2 および Aurora プロビジョニングインスタンスの Data API は、Aurora Serverless v1 の Data API の場合と同様に、管理イベントの代わりに AWS CloudTrail データプレーンイベントを使用してアクティビティをログに記録します。

このアクティビティを追跡したい場合は、CloudTrail コンソール、CLI、または SDK を使用してデータイベントのロギングを有効にできます。これには、CloudTrail の料金ページに記載されている料金が発生します。さらに、AWS Secrets Manager の使用には、AWS Secrets Manager 料金ページに記載されている料金が発生します。 

AWS が CloudTrail 管理イベントではなくData API にデータプレーンイベントを使用し始めたのはなぜですか?

AWS CloudTrail は AWS API アクティビティを管理イベントまたはデータイベントとしてキャプチャします。CloudTrail 管理イベント (「コントロールプレーンオペレーション」とも呼ばれる) は、リソースの作成、更新、削除など AWS アカウント内のリソースに対して実行される管理オペレーションを表示します。CloudTrail データイベント (「データプレーンオペレーション」とも呼ばれる) は、AWS アカウントのリソースで、またはリソース内で実行されたリソースオペレーションを示します。

Data API は Aurora データベース内のデータに対してクエリを実行するため、データプレーンの操作を実行します。したがって、Data API アクティビティはイベントの正しい分類であるため、データイベントとしてログに記録します。データイベントのログを有効にした場合、CloudTrail データイベントに対してのみ料金が発生します。

Data API には無料利用枠がありますか?

はい。Data API の無料利用枠には、1 か月あたり 100 万件のリクエスト(すべての AWS リージョンの合計)、初年度の使用分が含まれます。 1 年後、お客様は Aurora 料金ページに記載されているように Data API の支払いを開始します。

Amazon RDS ブルー/グリーンデプロイ

Amazon RDS ブルー/グリーンデプロイでは、どのバージョンがサポートされていますか?

Amazon RDS ブルー/グリーンデプロイは、Amazon Aurora MySQL 互換エディションバージョン 5.6 以降と Amazon Aurora PostgreSQL 互換エディションバージョン 11.21 以上、12.16 以上、13.12 以上、14.9 以上、15.4 以上でご利用いただけます。利用可能なバージョンの詳細については、Aurora のドキュメントを参照してください。

Amazon RDS ブルー/グリーンデプロイは、どのリージョンをサポートしていますか?

Amazon RDS ブルー/グリーンデプロイは、すべての AWS リージョンおよび AWS GovCloud リージョンで利用可能です。

Amazon RDS ブルー/グリーンデプロイはいつ使用すべきですか?

Amazon RDS ブルー/グリーンデプロイを使用すると、より安全、簡単、高速にデータベースの更新ができます。ブルー/グリーンデプロイは、メジャーバージョンまたはマイナーバージョンのデータベースエンジンのアップグレード、オペレーティングシステムの更新、論理レプリケーションを中断しないグリーン環境でのスキーマの変更 (テーブルの最後に新しい列を追加するなど)、またはデータベースパラメーター設定の変更などのユースケースに最適です。

ブルー/グリーンデプロイを使用すると、1 回のスイッチオーバーで複数のデータベースを同時に更新できます。これにより、セキュリティパッチを最新の状態に保ち、データベースのパフォーマンスを向上させ、短期間で予測可能なダウンタイムで新しいデータベース機能にアクセスできます。Aurora のマイナーバージョンアップグレードのみを行う場合は、 Aurora ゼロダウンタイムパッチ (ZDP) の使用をお勧めします。

Amazon RDS ブルー/グリーンデプロイを利用する際のコストは?

グリーンインスタンスでワークロードを実行する場合、ブルーインスタンスと同じ料金が発生します。ブルーおよびグリーンインスタンスで実行するコストは、db.instance の現在の標準料金、ストレージのコスト、読み取り/書き込み I/O のコスト、およびバックアップや Amazon RDS Performance Insights のコストなど、有効な機能を含みます。 事実上、ブルーグリーンデプロイの有効期間中は、db.instance でワークロードを実行するコストの約 2 倍を支払うことになります。

例: Aurora MySQL 互換エディション 5.7 クラスターが、us-east-1 AWS リージョンにおいて 2 つの r5.2xlarge db.instance、プライマリライターインスタンスとリーダーインスタンスで稼働しているとします。それぞれの r5.2xlarge db.instance は、40 GiB ストレージで構成され、月間 2,500 万 I/O があります。Amazon RDS ブルー/グリーンデプロイを使って ブルーインスタンスのトポロジーのクローンを作成し、15 日間 (360 時間) それを実行すると、その間に各グリーンインスタンスは 300 万 I/O 読み取りを行います。そして、スイッチオーバーが成功した後、ブルーインスタンスを削除します。ブルーインスタンス (ライターとリーダー) のコストは、15 日間で 849.2 USD、オンデマンド料金は 1.179 USD/時間 (インスタンス + ストレージ + I/O) です。グリーンインスタンス (ライターとリーダー) のコストは、15 日間で 840.40 USD、オンデマンド料金は 1.167 USD/時間 (インスタンス + ストレージ + I/O) です。この 15 日間、ブルー/グリーンデプロイを使用した場合の合計コストは 1689.60 USD で、これはその期間にブルーインスタンスを実行した場合のコストのおよそ 2 倍です。

Amazon RDS ブルー/グリーンデプロイでは、どのような変更を行うことができますか?

Amazon RDS ブルー/グリーンデプロイは、メジャー/マイナーバージョンアップグレード、スキーマの変更、インスタンスのスケーリング、エンジンパラメータの変更、メンテナンスアップデートなど、より安全でシンプル、かつ迅速なデータベース変更を行うのに役立ちます。

Amazon RDS ブルー/グリーンデプロイの「ブルー環境」とは何ですか? 「グリーン環境」とは何ですか?

Amazon RDS ブルー/グリーンデプロイでは、ブルー環境は現在の本番環境です。グリーン環境は、スイッチオーバー後に新しい本番環境となるステージング環境です。

Amazon RDS ブルー/グリーンデプロイでのスイッチオーバーはどのように行われますか?

Amazon RDS ブルー/グリーンデプロイがスイッチオーバーを開始すると、スイッチオーバーが完了するまで、ブルーとグリーンの両方の環境への書き込みがブロックされます。  スイッチオーバーの間、ステージング環境 (グリーン環境) は本番システムに追いつき、ステージング環境と本番環境の間でデータの一貫性を確保します。本番環境とステージング環境が完全に同期されると、ブルー/グリーンデプロイは、新しく昇格させられる本番環境にトラフィックをリダイレクトすることで、ステージング環境を新しい本番環境として昇格させます。

Amazon RDS ブルー/グリーンデプロイは、スイッチオーバー完了後にグリーン環境への書き込みを可能にするよう設計されており、スイッチオーバープロセス中のデータ損失はゼロになります。

Amazon RDS ブルー/グリーンデプロイがスイッチオーバーした後、古い本番環境はどうなりますか?

Amazon RDS ブルー/グリーンデプロイでは、古い本番環境は削除されません。必要に応じて、追加の検証やパフォーマンス/リグレッションのテストのためにアクセスすることができます。古い本番環境が不要になった場合は、削除することができます。古い本番インスタンスについては、削除するまでは標準的な課金料金が適用されます。

Amazon RDS ブルー/グリーンデプロイのスイッチオーバーガードレールは何をチェックしますか?

Amazon RDS ブルー/グリーンデプロイのスイッチオーバーガードレールは、スイッチオーバー前にグリーン環境が追いつくまで、ブルー環境とグリーン環境での書き込みをブロックします。ブルー/グリーンデプロイは、ブルーとグリーンの環境におけるプライマリとレプリカのヘルスチェックも行います。レプリケーションのヘルスチェックも行います。例えば、レプリケーションが停止していないか、エラーが発生していないか、などを確認します。ブルー環境とグリーン環境の間で長時間実行されているトランザクションを検出します。最大許容ダウンタイムを最短で 30 秒から指定でき、進行中のトランザクションがこれを超えると、スイッチオーバーがタイムアウトします。

セルフマネージド論理レプリカのサブスクライバー/パブリッシャーとしてブルーデータベースを使用している場合、ブルー/グリーンデプロイを使用できますか?

ブルー環境がセルフマネージド論理レプリカまたはサブスクライバーの場合、スイッチオーバーはブロックされます。最初にブルー環境へのレプリケーションを停止し、スイッチオーバーを続行してからレプリケーションを再開することをお勧めします。対照的に、ブルー環境がセルフマネージド論理レプリカまたはパブリッシャーのソースである場合は、スイッチオーバーを続けることができます。ただし、スイッチオーバー後にグリーン環境からレプリケートするには、セルフマネージドレプリカを更新する必要があります。

Amazon RDS ブルー/グリーンデプロイは、Amazon Aurora Global Databases、Amazon RDS Proxy、またはクロスリージョンリードレプリカをサポートしていますか?

いいえ。Amazon RDS ブルー/グリーンデプロイは、Amazon Aurora Global Database、Amazon RDS Proxy、またはクロスリージョンリードレプリカをサポートしません。

Amazon RDS ブルー/グリーンデプロイを使用して、変更をロールバックすることはできますか?

いいえ。現時点では、Amazon RDS ブルー/グリーンデプロイを使用して変更をロールバックすることはできません。

Trusted Language Extensions for PostgreSQL

Trusted Language Extensions for PostgreSQL を使用すべきなのはなぜですか?

Trusted Language Extensions (TLE) for PostgreSQL により、デベロッパーは高パフォーマンスの PostgreSQL 拡張機能を構築して、Amazon Aurora で安全に実行できます。これにより、TLE は市場投入までの時間を短縮し、データベース管理者が本番データベースワークロードで使用するためのカスタムコードやサードパーティーコードを認証する負担を軽減します。拡張機能がニーズに合うと判断し次第、すぐに進めることができます。TLE を使用することで、独立系ソフトウェアベンダー (ISV) は、Aurora で実行しているお客様に新しい PostgreSQL 拡張機能を提供できます。

PostgreSQL で拡張機能を実行する際の従来のリスクにはどのようなものがありますか? また、TLE for PostgreSQL はそのリスクをどのように軽減していますか?

PostgreSQL の拡張機能では、同じプロセス空間で実行されるため、高いパフォーマンスを発揮します。しかし、拡張機能には、データベースをクラッシュさせるようなソフトウェアの欠陥があるかもしれません。
 
TLE for PostgreSQL は、このリスクを軽減するために複数のレイヤーを提供します。TLE は、システムリソースへのアクセスを制限するように設計されています。 rds_superuser ロールは、特定の拡張機能のインストールを許可するユーザーを決定することができます。ただし、これらの変更は、TLE API を通じてのみ可能です。TLE は、拡張機能の欠陥の影響を単一のデータベース接続に限定するように設計されています。これらの安全対策に加えて、TLE は、 rds_superuser ロールを持つ DBA が、拡張機能をインストールできるユーザーをきめ細かくオンラインで制御できるように設計されており、拡張機能を実行するための権限モデルを作成することが可能です。十分な権限を持つユーザーのみが、TLE 拡張機能の「CREATE EXTENSION」コマンドを使用して実行および作成することができるようになります。DBA は、データベースの内部動作を変更し、通常、昇格した特権を必要とする、より高度な拡張機能に必要な「PostgreSQL フック」を許可リスト化することもできます。

TLE for PostgreSQL は、他の AWS サービスとどのように関連/連携していますか?

TLE for PostgreSQL は、バージョン 14.5 以降の Amazon Aurora PostgreSQL 互換エディションでご利用いただけます。TLE は PostgreSQL 拡張機能自体として実装されており、Aurora でサポートされている他の拡張機能と同様に、rds_superuser ロールからアクティブ化できます。

TLE for PostgreSQL は、PostgreSQL のどのバージョンで動作させることができますか?

TLE for PostgreSQL は、Amazon Aurora の PostgreSQL 14.5 以降で実行できます。

Trusted Language Extensions for PostgreSQL はどのリージョンで利用できますか?

TLE for PostgreSQL は現在、すべての AWS リージョン (AWS 中国リージョンを除く) および AWS GovCloud リージョンでご利用いただけます。

TLE を実行するために、どの程度のコストがかかりますか?

Aurora をご利用のお客様は、TLE for PostgreSQL を追加料金なしで利用できます。

TLE for PostgreSQL は、Amazon Aurora および Amazon RDS で現在利用できる拡張機能とどのように異なりますか?

AuroraAmazon RDS は、85 以上の PostgreSQL 拡張機能のキュレートされたセットをサポートしています。AWS は、AWS 責任共有モデルに基づいて、これらの拡張機能それぞれのセキュリティリスクを管理しています。TLE for PostgreSQL を実装する拡張機能は、このセットに含まれています。お客様が書いた、またはサードパーティーのソースから入手して TLE にインストールした拡張機能は、お客様のアプリケーションコードの一部とみなされます。TLE 拡張機能を使用するアプリケーションのセキュリティは、お客様の責任で行ってください。

TLE for PostgreSQL で実行できる拡張機能の例には、どのようなものがありますか?

ビットマップ圧縮や差分プライバシーなど (個人のプライバシーを保護する、一般にアクセス可能な統計クエリなど) のデベロッパー機能を構築することができます。

TLE for PostgreSQL の開発には、どのようなプログラミング言語が使えますか?

TLE for PostgreSQL は現在、JavaScript、PL/pgSQL、Perl、および SQL をサポートしています。

TLE for PostgreSQL 拡張機能をデプロイするにはどうすればよいですか?

rds_superuser ロールが TLE for PostgreSQL をアクティブ化すると、psql などの任意の PostgreSQL クライアントから SQL CREATE EXTENSION コマンドを使用して TLE 拡張機能をデプロイできます。これは、PL/pgSQL や PL/Perl などの手続き言語で記述されたユーザー定義関数を作成する方法と似ています。TLE 拡張機能をデプロイする権限と特定の拡張機能を使用する権限を持つユーザーを制御できます。

TLE for PostgreSQL 拡張機能は、PostgreSQL データベースとどのように通信しますか?

TLE for PostgreSQL は、TLE API を介してのみ PostgreSQL データベースにアクセスします。TLE がサポートする信頼できる言語には、PostgreSQL サーバープログラミングインターフェイス (SPI) の全機能と、チェックパスワードフックを含む PostgreSQL フックのサポートが含まれます。

TLE for PostgreSQL オープンソースプロジェクトの詳細はどこで知ることができますか?

TLE for PostgreSQL プロジェクトの詳細については、公式の TLE GitHub ページで確認できます。

Amazon RDS 延長サポート

RDS 延長サポートはどのマイナーバージョンでも利用できますか?

いいえ、Amazon RDS 延長サポートは特定のマイナーバージョンでのみご利用いただけます。詳細については、「Aurora ユーザーガイド」をご覧ください。 

RDS 延長サポートの料金を見積もるにはどうすればよいですか?

Amazon RDS 延長サポートの料金は、以下の 3 つの要因によって異なります。1. インスタンスで実行されている vCPU または ACU の数、2.AWS リージョン、3. 標準サポート終了からの経過年数。

料金を見積もるには、インスタンスの vCPU の数と、エンジンバージョンに適した暦年の価格を決定します。ご利用のバージョンが 1~2 年目の料金の範囲内でプロビジョニングインスタンスを使用している場合、選択したリージョンの使用時間ごとに CPU の数 x 1 年目と 2 年目の料金が請求されます。ご利用のバージョンが 3 年目の料金で、プロビジョニングインスタンスを使用している場合、選択したリージョンの使用時間ごとに vCPU の数 x 3 年目の料金が請求されます。

例えば、RDS 延長サポートの初年度である 2024 年 12 月 30 日にバージニア北部で Aurora MySQL 互換の 2 db.r5.large インスタンスを実行している場合、1 時間あたり 0.200 USD、つまり 2 vCPU x vCPU あたり 0.100 USD の料金が発生します。

Amazon Aurora の RDS 延長サポートの料金が発生するのはいつからですか?

Amazon RDS 延長サポートの料金は、Aurora MySQL 互換エディションのメジャーバージョンが標準サポートを終了した翌日から発生します。これは、インスタンスの存在期間中に発生するインスタンス、ストレージ、バックアップ、および/またはデータ転送の料金に追加されます。

たとえば、Aurora MySQL 互換 2 の標準サポートは 2024 年 11 月 30 日に終了します。2024 年 11 月 30 日以降に Aurora MySQL 互換 2 のインスタンスを実行すると、そのインスタンスの RDS 延長サポートの料金が発生します。

DB スナップショットの RDS 延長サポートに料金は発生しますか?

いいえ、Amazon RDS 延長サポートの料金は DB スナップショットには適用されません。ただし、RDS 延長サポートのバージョンを使用する新しい DB インスタンスにスナップショットを復元する場合、標準サポートバージョンにアップグレードするか、インスタンスを削除するまで、インスタンスには RDS 延長サポートの料金が発生します。

RDS 延長サポートの料金はいつ発生しなくなりますか?

インスタンスを標準サポートで利用できる新しいエンジンバージョンにアップグレードすると、インスタンスへの RDS 延長サポート料金の発生を防ぐことができます。標準サポート終了日を過ぎてメジャーエンジンバージョンを実行しているインスタンスを停止または削除すると、RDS 延長サポートの料金は自動的に停止します。

エンジンバージョンごとに 2つの異なる料金が表示されています。どちらの料金で請求されているか、どうすればわかりますか?

請求される RDS 延長サポート料金は、エンジンバージョン、AWS リージョン、およびそのバージョンの標準サポートの有効期限が切れてからの暦年数によって異なります。標準サポート終了後の最初の 2 年間は、vCPU 時間ごとに、選択したリージョンの 1 年目と 2 年目の料金が請求されます。RDS 延長サポートの提供が 3 年目の場合、3 年目の初日から、vCPU 時間ごとに、選択したリージョンの 3 年目の料金が請求されます。

たとえば、Aurora PostgreSQL 互換 11 の標準サポートは 2024 年 2 月 29 日に終了します。米国東部 (オハイオ) にデプロイしている場合、2024 年 4 月 1 日から 2026 年 3 月 31 日までの間、vCPU 時間あたり 0.100 USD の料金が発生します。2026 年 4 月 1 日以降は、vCPU 時間あたり 0.200 USD の料金が発生します。

RDS 延長サポートの料金が発生しないようにするにはどうすればよいですか?

できるだけ早く、標準サポート期間内にインスタンスをメジャーエンジンバージョンにアップグレードすることをお勧めします。これにより、RDS 延長サポートの料金が発生するのを防ぐことができます。

Amazon RDS ブルー/グリーンデプロイを使用して RDS 延長サポートバージョンから標準サポートバージョンに移行できますか?

ブルー/グリーンデプロイがインスタンスのエンジン、リージョン、メジャーバージョンタイプをサポートしている場合に限り、Amazon RDS ブルー/グリーンデプロイで RDS 延長サポートを使用してインスタンスを移行できます。ブルー/グリーンデプロイは Aurora MySQL 互換エディションでご利用いただけます。使用可能なバージョンについては、「ブルー/グリーンデプロイのドキュメント」をご覧ください。

リザーブドインスタンス割引は RDS 延長サポートに適用されますか?

いいえ。RDS 延長サポートの料金は、インスタンスの料金とは関係ありません。したがって、リザーブドインスタンスの割引は RDS 延長サポートの料金には適用されません。

RDS for MySQL 5.7 から Aurora MySQL 2 (MySQL 5.7 ベース) に移行した場合でも、RDS 延長サポートの料金は発生しますか?

2024 年 2 月 29 日以前に RDS for MySQL 5.7 から Aurora MySQL 2 に移行した場合、RDS 延長サポートの料金は発生しません。2024 年 2 月 29 日から 2024 年 11 月 30 日の間に移行した場合、Amazon RDS で MySQL 5.7 を実行していた時間数に対して RDS 延長サポートの料金が発生します。

2024 年 11 月 30 日以降に移行もしくは Aurora MySQL 互換 2 を使用する場合、Aurora データベースの RDS 延長サポート料金も発生します。詳細については、「Amazon Aurora のドキュメント」と「Amazon RDS のドキュメント」を参照してください。

標準サポートが終了したバージョンで作成した DB スナップショットはどうなりますか? その場合、RDS 延長サポート料金を支払う必要がありますか?

いいえ、DB スナップショットには RDS 延長サポート料金は発生しません。ただし、標準サポートの終了後に DB スナップショットを新しい DB インスタンスに復元すると、そのインスタンスの RDS 延長サポート料金が発生します。

たとえば、2024 年 11 月 30 日以降に Aurora MySQL 互換 2 上の新しい DB インスタンスに DB スナップショットを復元した場合、Aurora MySQL 互換バージョン 3 以降にアップグレードするか、インスタンスを削除するまで、インスタンスには Aurora MySQL 互換 2 RDS 延長サポート料金が発生します。

標準サポートが終了した後にメジャーバージョンエンジンで新しいインスタンスを作成した場合、RDS 延長サポートの料金は発生しますか?

はい。インスタンスを作成するか、標準サポートの終了日に達したバージョンで実行されているインスタンスに DB スナップショットを復元すると、インスタンス、ストレージ、バックアップ、データ転送の料金に加えて RDS 延長サポート料金が発生します。

Amazon Aurora 料金表についてはこちらをご覧ください

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