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

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

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

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

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

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

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

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

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

ほとんどの場合、Aurora への移行は 1 時間以内に完了しますが、データの形式およびデータセットのサイズによって時間が異なります。詳細については、MySQL データベースを Amazon 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 ドキュメントをご参照ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

はい。最大 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 レプリカを追加できます。同じ 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 レプリカに自動でリダイレクトされ、レプリカはプライマリに昇格します。

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

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

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

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

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

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

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

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

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

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

はい。すべての Amazon Aurora DB インスタンスは VPC で作成します。Amazon VPC では、お客様のデータセンターで運用されている従来型のネットワークを正確に模倣して、仮想ネットワークのトポロジーを定義できます。これにより、どのユーザーが 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 インスタンスを作成し、データを移行してください。

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

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

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

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

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

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

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

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

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

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

はい、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 ユーザーガイド」を参照してください。

Aurora Serverless v1 の互換性については、こちらをご覧ください。Aurora Serverless v2 の互換性については、こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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 は自動的にホストの置き換えを実行します。マルチノードデータベースクラスターでは、これによりリージョン内のフェイルオーバーがトリガーされます。

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

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

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

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

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

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

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

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

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 互換エディションでご利用いただけます。

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

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

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

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

• 拡張バイナリログを有効にすることで追加の I/O とストレージが使用される
• Amazon Redshift データベースをシードするための初期データエクスポートのスナップショットエクスポートコスト
• レプリケートされたデータを保存するための追加の Amazon Redshift ストレージ
• ソースからターゲットへのデータ移動にかかる Cross-AZ データ転送コスト。

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

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 エンジニアに通知するように設計されており、診断情報、問題の範囲の詳細、およびお客様がデータベースに関するパフォーマンスのボトルネックと運用上の問題を迅速に解決するのに役立つインテリジェントな修復についてレコメンデーションを提供します。

Amazon DevOps Guru for RDS は、手動作業を行わずに、時間 (数時間から数日かかっていたものを数分に) を短縮して、リレーショナルデータベースのワークロードで見つけにくいパフォーマンスのボトルネックを検出して解決するように設計されています。

すべての Amazon Aurora データベースで DevOps Guru for RDS を有効にすると、ワークロードのパフォーマンス問題が自動的に検出されます。その後、各問題についてアラートが送信され、結果が説明され、問題を解決するための措置が推奨されます。
DevOps Guru for RDS を使用すれば、専門家以外のユーザーがデータベースを管理しやすくなり、データベースの専門家がさらに多くのデータベースを管理できるように支援します。

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

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

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

新しい最新のアプリケーション、特にリクエスト/レスポンスモデルで Aurora にアクセスする必要がある AWS Lambda で構築されたアプリケーションには、Data API を使用する必要があります。既存のアプリケーションがデータベースドライバーと高度に連動している場合、実行時間が長い場合、または開発者が一時テーブルなどのデータベース機能を利用したり、セッション変数を使用したりする場合は、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 は使いやすく安全な HTTP ベースの API で、データベースドライバーをデプロイしたり、クライアント側の接続プールを管理したり、アプリケーションとデータベース間の複雑な VPC ネットワークを設定したりする必要がありません。また、Data API は、データベース接続を自動的にプールして共有することでスケーラビリティを向上させ、接続を頻繁に開いたり閉じたりするアプリケーションによる計算オーバーヘッドを軽減します。 

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 グローバルデータベースライターインスタンスをサポートします。

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

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

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

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

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

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

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

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

グリーンインスタンスでワークロードを実行する場合、ブルーインスタンスと同じ料金が発生します。ブルーおよびグリーンインスタンスで実行するコストは、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 Aurora Global Database、Amazon RDS Proxy、またはクロスリージョンリードレプリカをサポートしません。

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

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

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

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

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

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

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

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

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

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

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

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