Amazon Aurora とそのイノベーションの詳細 (DAT441)

セッションノート

オーロラの概要

• Amazon Aurora はクラウドネイティブのリレーショナル データベースです
• ハイエンドの商用データベースの速度と可用性と、オープンソースのシンプルさと費用対効果を組み合わせます。
• フルマネージド、MySQL および PostgreSQL と互換性あり
• サーバーレスおよび機械学習アプリケーションと統合するためのツールが含まれています
• Aurora を使用するためにアプリケーションを変更する必要はありません
• PostgreSQLの拡張機能をサポート
• 最近の追加: Aurora DSQL (分散 SQL) Aurora
• アーキテクチャ:
• 3 アベイラビリティ ゾーンを利用
• すべての 3 可用性ゾーンにまたがる Aurora ストレージを備えています
• ストレージ ノードは、データベース ページに変換されるログ レコードを処理します。

Aurora ストレージの主な機能

• チェックポイント、全ページ書き込み、二重書き込みバッファ、ログのアーカイブなどの従来のデータベースの問題はありません
• データは、3 アベイラビリティ ゾーン内の 6 ストレージ ノード全体で 6 コピーを使用して冗長的に保存されます。
• 破損または紛失したログ レコード、または障害が発生したストレージ ノードの自動ピアツーピア修復
• レプリカ管理:
• 一貫性の遅れを生じることなく最大 15 読み取り専用レプリカを追加する機能
• ヘッド ノード間の非同期の無効化と更新
• レプリカはさまざまなサイズとインスタンス タイプにすることができます (例: Graviton、Intel)
• ストレージは自動的に最大 256 テラバイトまで拡張されます。
• 自動フェイルオーバー:
• 障害時のレプリカの読み取り/書き込みノードへの昇格
• アプリケーション再ルーティングのための DNS- ベースのエンドポイント変更
• より高速な (最大 66% より高速な) フェイルオーバーのために利用可能な高度な高速ドライバー
• マルチリージョン機能:
• リージョン間でのストレージの非同期レプリケーション (グローバル データベース)
• レプリケーションは Aurora によって処理され、アプリケーションの変更は不要です
• セカンダリ リージョンでアプリケーションを実行することにより、低遅延のリージョン ローカル読み取りが可能になります
• 最大 10 リージョンをグローバル データベースのセットアップに利用できます。 テクニカル
• ノート:
• ヘッド ノードはレプリケーション プロセスに関与しません。
• セカンダリ リージョンの読み取り専用レプリカは、通常 1 秒未満の RPO 遅延でほぼ瞬時のデータ可視性を維持します。

グローバルエンドポイントとフェイルオーバー

• グローバルエンドポイントは、現在のライター領域を指す DNS 名です。
• プライマリ リージョンに問題が発生した場合、フェイルオーバー操作が発行されます。
• フェイルオーバーにより、別のリージョンのレプリカがライター ノードに昇格されます。
• 非同期レプリケーションによりデータ損失が発生する可能性があります
• グローバル エンドポイントの AAAA 名は、ルート 53 データ プラン API グローバル データベース
• スイッチオーバーを介して更新されます。
• スイッチオーバーは、両方のリージョンが正常で、ライターが運用上の理由で移動された場合に発生します。
• 最近の改善により、スイッチオーバー時間が 5 分から 30 秒に短縮されました
• ログベースのアーキテクチャを利用して、ゼロのデータ損失 (RPO/0) と 30 秒の回復時間 (RTO/30 秒) を実現します。
• ローカル書き込み転送:
• セカンダリ アベイラビリティ ゾーンからの書き込みをライター ノードに転送できるようにします。
• システムをアクティブ/アクティブ構成に変換しません
• アベイラビリティーゾーン 2 からの書き込みはアベイラビリティーゾーン 1, のライターノードに転送され、実行され、結果が返されます。
• データの整合性やシステム設計を損なうことなく、運用の柔軟性を強化します。 Aurora
• の整合性モード:
• 3 つの異なる一貫性モード/可視性モードが利用可能
• デフォルトのモードはセッション可視性で、更新が確認されるのを待ってから読み取りを続行します。
• 最終整合性モードは更新を待機しないため、最新の書き込みが反映されない読み取りが発生する可能性があります。
• グローバル整合性モードは、クラスター全体のすべての更新を待ってから続行し、読み取りがすべての書き込みを確実に反映するようにします。
• ローカル書き込み転送:
• セカンダリ アベイラビリティ ゾーンからの書き込みをライター ノードに転送できるようにします。
• ローカル操作と同じ一貫性モードと考慮事項を維持します。
• リージョン間のレイテンシーの違いは、グローバル書き込み転送の Aurora ストレージ
• ノード操作の要因となります。
• 各ストレージ ノードは、エンジンとストレージ間の通信を容易にする「ストレージ デーモン」を実行します。
• ログ レコードは受信キューに書き込まれ、ディスク上のホット ログに排出されてから確認応答されます。
• 欠落したログレコード（転送遅延などによる）は、他のストレージノードからピアツーピアで取得できます。
• ログ レコードはデータベース ページに結合され、読み取りリクエストが遅延への影響を最小限に抑えて処理されるようにします。
• S3 への継続的なバックアップにより、過去 35 日以内のポイントインタイム復元が可能

IO 最適化構成

• 構成オプションを調整して、IO- 集中型アプリケーションのスループットを向上させます。
• ストレージドライバーを変更して、より積極的なバッチ処理を実現し、IO-heavy アプリケーションに有益です。
• さらなる最適化のために最新のエンジン バージョンを利用します。
• 受信キューを耐久性のあるキューに変更して、遅延とジッターを削減し、パフォーマンスを向上させます。
• Aurora PostgreSQL の互換性と更新:
• Aurora PostgreSQL は PostgreSQL と完全な互換性があります。
• アップストリームからの PostgreSQL アップデートの定期的な統合。
• バージョン 17.6.
• までの PostgreSQL のサポート
• ローカルディスクを備えた RAG インスタンスタイプとの互換性。
• 相関サブクエリ キャッシュ、アダプティブ ジョインなど、アップストリームからの多数のパフォーマンスの向上。
• メモリ効率を高めるための共有プラン キャッシュの導入。
• 大規模なインスタンスとレプリカの読み取り可用性が強化されました。
• FIPS 140-3 セキュリティ暗号化の実装。
• さまざまな拡張機能、特に PG ベクターの更新。
• 最大 256 テラバイトのボリュームをサポート。
• Aurora PostgreSQL のパフォーマンス分析:
• さまざまなインスタンス世代にわたるスループットの評価。
• テスト例:
• R52.4Xlarge (古いインスタンス) と R7i.48Xlarge (新しい、より大きなインスタンス) による CPU-bound パフォーマンスは、2.1 倍のパフォーマンス向上を示しています。
• R8G (Graviton バージョン、次世代) の導入は、ベースラインよりも 2.7 倍の改善を示し、線形より優れたスケーリングを示しています。
• 線形よりも優れたスケーリングとは、リソース (データ サイズやノードなど) の増加に応じて、システムやプロセスのパフォーマンスや効率が不釣り合いに向上することを意味します。これは対数的成長や特殊なアーキテクチャでよく見られ、データ視覚化、データベース パフォーマンス、計算効率のアプリケーションでの線形成長 (入力が 2 倍になれば出力も 2 倍) やサブリニア スケーリング (収穫逓減、アムダールの法則の制限) とは対照的です。

Aurora PostgreSQL の動的データ マスキング

• Aurora の機密データを保護するための新機能。
• 機密データには、口座番号、口座名義人名、個人を特定できる情報 (PII) が含まれます。
• Aurora PostgreSQL の動的データ マスキング:
• データの丸められたバージョンまたはマスクされたバージョンを提供することにより、機密データを保護するように設計されています。
• Aurora の新しい PG 列マスク拡張機能を介して実装されます。
• 特定のテーブルおよび列に対するマスキング ポリシーの定義を許可します。
• 例：
• 顧客 ID を X としてマスクし、口座残高を四捨五入します。
• ポリシーは、競合解決のために定義された重みを使用して、指定された役割 (「アナリスト」など) に適用されます。
• インデックスに影響を与えずに効率的なパフォーマンスを実現するために、クエリ リライト レイヤーに実装されています。
• 動的データマスキングの実装の詳細:
• マスキング関数は、ポストフェッチではなく、クエリの書き換えフェーズ中に適用されます。
• 良好なパフォーマンスを確保し、インデックス機能を維持します。
• マスク関数がターゲット列に適用されているクエリ記述出力に表示されます。
• Aurora MySQL の更新:
• MySQL 8.0.43 との互換性を備えたバージョン 3.11 の最近のリリース。
• 機能が強化された 3.10.0 長期サポート バージョンの導入。
• 最大 40% のインメモリ リレー ログ キャッシュにより、ログ レプリケーションのスループットが向上しました。
• MySQL の高度な高速ドライバーでの ODBC のサポート。 ODBC (Open Database Connectivity) は、アプリケーションが標準言語 SQL を使用してさまざまなデータベース管理システムのデータにアクセスできるようにする API です。これはブリッジとして機能し、単一のアプリケーションが、それぞれに書き換えることなく、AAAE サーバー、MySQL、Oracle などの異なるデータベースに接続できるようにします。
• 最大 256 テラバイトまでのボリューム サポートが増加しました。
• グローバル データベースのセカンダリ リーダーにより、グローバルな問題が発生した際の読み取り可用性が向上します。

Aurora サーバーレス

• 合理化されたフリート管理に推奨されるインスタンス タイプ。
• ワークロードの需要に基づいて CPU とメモリを自動的に調整します。
• V1 のサポート終了に伴い、Aurora Serverless V2 から単に Aurora Serverless に名前が変更されました。
• 柔軟なリソース割り当てのための柔軟なインスタンス タイプを提供します。
• Aurora サーバーレスの機能と利点:
• エンジンを再起動せずに、メモリ、CPU、ネットワークを自動的にスケールします。
• スケーリングは 1 秒ごとに行われ、Aurora キャパシティ ユニット (ACU) で測定され、それぞれが RAM の 2 GB および関連リソースを表します。
• Lambda 関数または分析ジョブに応じてスケールし、需要に基づいて ACU を調整します。
• 1 秒ごとに料金が設定され、ユーザーは実際に使用したリソースの料金のみを支払います。
• Aurora Serverless のスケーリング メカニズム:
• 定期的にクレジットが満たされるスケーリング バケットを使用して動作し、設定された最大 ACU 制限までスケールアップできます。
• クレジットはスケーリングが必要なときに消費され、時間の経過とともにバケットが補充されます。
• 最近の機能強化には、より高速なトリガー応答 (1 秒未満)、より大きな初期バケット サイズ、およびより迅速な補充速度が含まれます。
• プラットフォーム バージョン 3 によるパフォーマンスの向上:
• 選択や追加の構成を必要とせずに、パフォーマンスが最大 30% 向上します。
• すべての新しいクラスターで利用可能で、バックアップからの復元、クローン作成、または新しいクラスターの作成によってアクセスできます。
• パフォーマンスの例:
• プラットフォーム バージョン 2 を高速スケーリングありとなしで比較したテストでは、高速スケーリングを使用した場合、ピーク パフォーマンスの期間が 3.6 倍長くなり、使用時間は 9% よりも少なくなりました。
• プラットフォーム バージョン 3 (高速スケーリングと組み合わせた) を使用したテストでは、プラットフォーム バージョン 2, と比較して実行時間と使用時間 ACU が 20% 削減され、請求額が 20% 低下することが実証されました。
• 高速スケーリングとプラットフォーム バージョン 3 の両方が新しいクラスターに自動的に適用され、ユーザーが余分な労力を費やすことなく、パフォーマンスとコスト効率が向上します。

高速構成で作成する

• データベースクラスターを数秒で迅速に作成します。
• CI/CD パイプラインやエージェント AI アプリケーションなど、クラスタを頻繁に作成するユーザーを対象としています。
• インタラクションごとに新しいデータベースを作成できるようになり、機敏性と速度が向上します。
• 高速構成を使用した作成の機能:
• 16 ACU (Aurora Capacity Unit) から始まる、柔軟で編集可能な構成を提供します。
• ACU やその他の構成を変更する機能を含め、作成後にほとんどの設定を変更できます。
• 暗号化と IAM (アイデンティティとアクセス管理) が有効になっているため、デフォルトで安全です。
• グローバルデータベースやゼロ ETL を含む、ほぼすべての Aurora 機能をサポートします。
• VPC 要件なし:
• Aurora Internet Access Gateway は、AAAA (Virtual Private Cloud) を必要とせずにデータベースクラスターへのアクセスを容易にする新しいコンポーネントです。
• インターネット アクセス ゲートウェイは、PostgreSQL ワイヤ プロトコルと互換性のある可用性の高いエンドポイントであり、遅延を最小限に抑えます。
• どこからでも DB クラスターにアクセスできるため、VPN の必要性が減り、開発者のプロセスが簡素化されます。
• Amazon IAM および AWS Shield と統合して、詐欺防止やデータ保護などのセキュリティ機能を強化します。
• AWS シールドは、アマゾン ウェブ サービス (AWS) 上で実行されているアプリケーションを分散型サービス拒否 (DDoS) 攻撃から保護するためのマネージド サービスです。一般的なネットワーク層攻撃を自動的に軽減する無料の AAAC Shield Standard と、より高度な攻撃に対する保護、高度な機能、専門家によるサポートを提供する有料の AAAD Shield Advanced の 2 層が提供されます。

Aurora と Agentic AI の統合

• Aurora は、エージェント AI システムのメモリとして機能し、エージェント AI ループの機能に不可欠です。
• 「Letter」フレームワークを使用した例: 高速構成で DB クラスターを作成し、ベクトル埋め込みに対して PG ベクトル拡張を有効にし、Letter フレームワークを PostgreSQL エンドポイントにポイントします。
• Aurora PostgreSQL は、LangChain などのさまざまなフレームワークにわたる遺伝的 AI メモリに使用できます。
• AWS によってオープンソース化された MCP (Model Context Protocol) サーバーでは、Aurora データベースのスキーマを理解し、それらを SQL クエリに変換する自然言語クエリが可能になります。これは、データベースを探索する新規ユーザーと効率を求めるパワー ユーザーの両方にとって有益です。
• Aurora でのパッチ適用とアップグレード:
• Aurora は、クラスターのパッチ適用とアップグレードのための管理されたエクスペリエンスを提供し、保留中のメンテナンスアクションがコンソールに表示されます。
• OS パッチは、クラスタ内の複数のノードにローリング方式で適用され、可用性が向上します。
• ユーザーは、更新のメンテナンスウィンドウを設定し、メンテナンスアクションに関する通知を受け取ることができます。
• メンテナンス アクションの自動化はオプションであり、ユーザーは Terraform などの独自のシステムを通じてアップグレードを制御できます。
• クラスターのフリートの場合、開発環境、AAAA、本番環境全体でアップグレードをシーケンスすることが重要です。
• Aurora クラスターの順次アップグレード:
• テストと反応時間を考慮して、異なる環境 (開発、AAAA、本番) 間でアップグレードを順序付けることが重要です。
• ランダムなメンテナンスアナウンスによる課題。望ましい順序に反して、開発前に QA 環境をアップグレードする可能性があります。

AWS 組織のアップグレード展開ポリシー

• シーケンスの問題に対処するために導入され、アップグレードをウェーブ (1 番目、2 番目、最後) に分割できるようになります。
• このプロセスには、ユーザーへの通知、最初のウェーブのメンテナンス期間の待機、それらのインスタンスのアップグレード、ベーキング (テスト期間)、および次のウェーブへの移行が含まれます。
• 問題が発生した場合にユーザーが対応するかオプトアウトするための十分な時間を提供します。
• アップグレードは、アップデートがリリースされる曜日に関係なく、順番に進行します。
• アップグレード ロールアウト ポリシーの実装:
• AWS 組織を有効にし、組織内にアカウントを配置する必要があります。
• 通常のセットアップには、自動マイナー バージョン アップグレードを有効にし、メンテナンス期間を設定することが含まれます。
• ポリシーは、タグをリソースに関連付けることによって設定されます。たとえば、最後のウェーブではリソースに「env=prod」でタグ付けします。
• 認識されたタグのないリソースは、デフォルトで指定されたウェーブ (例: 2 番目のウェーブ) になります。
• ユーザーは、タグを使用せず、すべてのリソースにわたる 1 回限りのアップグレードのデフォルトを受け入れることを選択できます。
• アップグレード ロールアウト ポリシーの適用:
• ポリシーを作成した後、組織全体 (ルート) または個別のアカウントに適用して選択的に適用できます。
• アップグレード中、ユーザーには保留中のメンテナンス アクションと AWS Health の通知が表示され、アップグレードが発生するウェーブが示されます。

メジャー バージョン アップグレードのための Blue-Green デプロイメント

• Blue-Green デプロイメントは、現在のバージョンと互換性がなく、インプレースで実行するとダウンタイムが必要なメジャー バージョン アップグレードに不可欠です。
• このプロセスには、運用環境 (「グリーン」環境) の完全なコピーの作成、論理レプリケーションを使用したデータの同期、Blue-Green デプロイメントが実行されている限り同期を維持することが含まれます。
• 切り替える前に、アップグレードされた環境を徹底的にテストできます。
• CLI またはコンソールを通じて容易に実行されるスイッチオーバーは、AWS リソースの名前を変更し、エンドポイントをグリーン環境に切り替え、データ損失がなく、ダウンタイムが最小限 (通常は 1 分未満) であることを保証します。
• スイッチオーバーがタイムアウトになった場合に、自動的に元の (青色) 環境に戻るフォールバック オプションを提供します。
• バージョンのアップグレードだけでなく、スキーマの変更、静的パラメータの変更、およびインプレース変更にはリスクが高すぎると考えられるメンテナンス更新にも役立ちます。
• グローバル データベースの Blue-Green デプロイメント:
• 最近のグローバル データベースのサポートにより、Blue-Green デプロイメントを使用してリージョン全体でメジャー バージョンのアップグレードが可能になります。
• このプロセスは単一リージョン展開のプロセスを反映しており、論理レプリケーションによりデータの同期と最小限のダウンタイム (スイッチオーバーに約 1 分) が保証されます。
• データ損失ゼロ (RPO または 0) および約 1 分の目標復旧時間 (RTO) で、グローバル クラスタ全体のメジャー バージョン アップグレードを可能にします。

Aurora のゼロ ETL 機能

• ETL パイプラインを管理せずに、Aurora PostgreSQL から Redshift への低レイテンシーのデータ転送を促進します。
• Aurora クラスターと Redshift クラスター間のパイプラインを作成する CLI コマンドによって実現されます。
• 5 ～ 12 秒のレプリケーション ラグを提供し、Redshift での迅速なデータの可用性を保証します。
• データのシーディング、メンテナンス、および変更データ キャプチャ (CDC) ストリーミングを管理し、ユーザーをこれらの複雑さから解放します。
• 複数の Aurora クラスター (MySQL と PostgreSQL の両方) の単一の Redshift クラスターまたはデータレイクへの統合をサポートします。
• また、同じテクノロジーを使用して、Aurora MySQL から SageMaker へのデータ フローも有効にします。
• ゼロ ETL の基盤技術:
• ストレージ層での並列直接エクスポートを利用して、パフォーマンスに影響を与えることなく、データを Redshift に迅速にシードします。
• 拡張ビン ログ (MySQL の場合) またはストレージに埋め込まれた PostgreSQL の同等のログを使用して、論理レプリケーション ログをキャプチャします。
• CDC ストリーミング サーバーは、ストレージからログを直接読み取り、データを Redshift にプッシュする前にフィルターと変更を適用して、ヘッド ノードのパフォーマンスに影響を与えないようにします。
• Aurora ストレージの種類:
• Aurora Standard: 基本的なパフォーマンスとコスト特性を提供するデフォルトのストレージ タイプ。

Aurora ストレージのコストとパフォーマンスの詳細な説明

• 読み取り操作: データがキャッシュされている場合、コストは最小限です (インスタンスの実行時間は数ミリ秒)。キャッシュが失われた場合、データはストレージから読み取られ、データベース エンジンに応じて 8K または 16K データベース ページあたり数セントのコストがかかります。
• 書き込み操作: 最大 4 キロバイトのコストは 1 セントにも満たないほどです。より大規模な書き込みは最大 4 I/O にバッチ処理され、各バッチのコストはサイズに応じて 1 セントの何分の 1 になります。
• Aurora I/O 最適化ストレージ:
• より予測可能な価格設定と潜在的に優れたパフォーマンスを提供します。
• クラスターの作成時に選択するか、オンラインに切り替えることができるクラスター レベルの構成。
• ストレージ側の変更を含め、システムのパフォーマンスとアーキテクチャの両方が変更されます。
• Aurora の請求額の I/O 比率が 25% を超えるユーザーには、コスト削減とパフォーマンスの向上が期待できるため推奨されます。
• 過去 18 か月以降のすべての最新エンジン バージョンで利用可能で、データベース節約プランと互換性があります。
• I/O 最適化ストレージのコスト モデル:
• ユーザーはコンピューティングとストレージに対して若干の割増料金を支払いますが、AAAAO に対しては費用がかからないため、請求がよりシンプルかつ予測可能になります。
• コンピューティングとストレージのプレミアム コストが I/O コストの排除によって相殺されるため、重要な I/O 操作を伴うワークロードに最適です。
• I/O 最適化によるパフォーマンスの向上:
• 16X ラージ インスタンスでのテストを通じて実証され、バージョン 14. を実行する R6I 16X ラージ インスタンスで I/O 最適化を有効にすると、スループットが 1.9x 向上することがわかります。
• バージョン 16 PostgreSQL の R7I インスタンスにアップグレードすると、さらなる改善 (追加の 10%) が見られます。

I/O 最適化によるレイテンシーとスループットの改善

• レイテンシ テスト: バージョン 17 PostgreSQL を実行する R8G 48X ラージ インスタンス上で最適化された I/O を使用した場合、ローエンドで 3 倍、ハイエンドで 6.4 倍のレイテンシの大幅な改善を示します。
• スループット テスト: 同じ条件でスループットが 5 倍向上していることを示し、レイテンシとスループットの両方について最適化された I/O の 2 つの利点を強調しています。
• 一時オブジェクトとローカル NVMe ストレージ:
• ローカル NVMe ストレージとは、サーバーまたはクラウド インスタンス内の超高速で物理的に接続されたソリッド ステート ドライブ (SSD) を指し、非常に低いレイテンシーと高スループットを提供し、一時的で高性能なスクラッチ スペースを必要とする要求の厳しいアプリ (AI/ML、データベース) に最適です。
• 速度: PCIe バスを使用し、ネットワーク/コントローラーのボトルネックをバイパスして、ミリ秒未満の遅延と大規模な IOPS を実現します。
• 直接接続: 物理的にサーバー/インスタンス シャーシ内 (AWS EC2 または Azure VM など)。
• エフェメラル: データは一時的なものです。インスタンスの終了、障害、場合によっては再起動やメンテナンスが発生しても存続しません。
• インデックスの再構築や大規模なソートなどの操作に PostgreSQL で一時オブジェクトを使用します。これらの操作はメモリを超え、ディスク ストレージを必要とする可能性があります。
• 通常のシステムでは、このディスクは EBS ディスクであり、パフォーマンスを考慮する必要があります。
• RAGD などの D インスタンスでは、代わりにローカル NVMe インスタンス ストレージが使用され、最大 6 倍のメモリ サイズをスピルに割り当てることができ、レイテンシが大幅に短縮され、これらの一時オブジェクトを使用するワークロードのパフォーマンスが向上します。
• 一時オブジェクトストレージに対する I/O 最適化の影響:
• I/O 最適化により、一時オブジェクトの割り当てがメモリの 6 倍からメモリの 2 倍に削減され、パフォーマンスは向上しますが、使用するストレージ領域は減少します。
• ストレージ領域の節約は、階層型キャッシュと呼ばれる機能に利用されます。この機能は、追加のキャッシュ層を提供することでパフォーマンスをさらに向上させるように設計されています。

階層型キャッシュ

• I/O 最適化の下で一時オブジェクト ストレージ割り当てを削減することで節約されたスペースを利用します。
• 追加のキャッシュ層を追加することでパフォーマンスを向上させることを目的としていますが、階層化キャッシュの動作方法に関する具体的な詳細は抜粋では提供されていません。
• 通常の読み取りプロセス:
• 共有バッファーでの初期チェック。データが見つかった場合は、それ以上のアクションを必要とせずに読み戻されます。
• データが共有バッファーにない場合、データはストレージから共有バッファーに読み取られて、エンジンに提供されます。
• D インスタンスによる最適化された読み取り:
• 共有バッファと同様に使用される、階層化キャッシュ用のディスク上のメモリの 4 倍を割り当てます。
• メタデータは、要求されたデータがディスク キャッシュ内にあるかどうかを判断するために使用されます。
• ストレージから読み取られたデータは共有バッファに配置されます。バッファがいっぱいになると、データはメタデータ追跡を使用して階層型キャッシュに追い出されます。
• 階層型キャッシュによる更新の処理:
• 更新では、メタデータ ビットを反転することで階層型キャッシュ内のデータを無効にし、階層型キャッシュへの頻繁な書き込みを回避します。
• 弾力性のある動的階層型キャッシュ:
• ワークロードのニーズに基づいて、階層化キャッシュと一時オブジェクトのサイズを調整する機能。
• ディスク流出の多いワークロードの場合は一時スペースを増やし、ワークロード後の大規模な階層型キャッシュの場合は一時スペースを減らします。

R8GD インスタンスのパフォーマンス

• R6GD と同じ価格で、165% のパフォーマンス向上を実現する新しいインスタンス タイプ。
• 階層型キャッシュのユーザーおよびその使用を検討しているユーザーに推奨されます。
• 階層型キャッシュによるパフォーマンスの向上:
• 特にメモリ容量を超えるデータの場合、読み取り操作の待ち時間が短縮されます。
• 340 GB テストの場合、階層化キャッシュではメモリと比較してレイテンシが 1.5% 増加し、階層化キャッシュがない場合は 8 倍の増加に対して 3 倍の不足が示されます。
• パレートランダム分布テストではさらに優れたパフォーマンスが示され、大規模なテストでは 1.4 倍のレイテンシー削減のみが実現されます。
• 実際の使用例:
• PG ベクトル ベンチマークは、最適化された読み取りにより 1 秒あたりのクエリ数が 3.5 倍以上向上していることを示しています (R7GD 対 R8G)。
• R6GD と 8GD (どちらも同じ価格) を比較すると、ベクトルのパフォーマンスが 1.6x 向上します。
• R: メモリ最適化インスタンス ファミリーを示します。
• 7：現世代（第7世代）を表します。
• g: インスタンスが AWS Graviton プロセッサ (Arm アーキテクチャ) を使用していることを示します。
• d: ローカルの NVMe ベースの SSD ストレージが含まれていることを示します。
• AWS Graviton 4 プロセッサを搭載した Amazon EC2 R8g インスタンスは、大規模なデータベースやリアルタイム分析などの要求の厳しいインメモリ ワークロード向けの AWS の最新世代のメモリ最適化インスタンスを表します。
• Aurora PostgreSQL と Aurora MySQL の概要:
• Aurora PostgreSQL: PostgreSQL と完全に互換性があり、同時書き込みに対して暗黙的または明示的なロックを備えた単一ライター アーキテクチャを使用します。
• Aurora MySQL: 複数の書き込みにアクティブ/アクティブ クエリ プロセッサを利用し、オプティミスティック同時実行制御を採用して競合を管理します。
• Aurora PostgreSQL でのスケールアウトには、非同期レプリケーションを使用したレプリカの追加、一貫性の問題の発生、パフォーマンスのためのキャッシュの活用が含まれます。
• 主な違い:
• 同時実行処理: PostgreSQL はロックを使用します。 MySQL はオプティミスティック同時実行制御を使用します。
• 書き込みアーキテクチャ: PostgreSQL には単一のライターがあります。 MySQL は複数のアクティブなライターをサポートします。
• スケーリングメカニズム: PostgreSQL はレプリカを介してスケーリングします。 MySQL は、追加のクエリ プロセッサを通じて拡張します。

Aurora PostgreSQL と Aurora MySQL の詳細な比較

• Aurora PostgreSQL: 単一ライターと同時実行のための明示的なロックを備えたアクティブ/パッシブ アーキテクチャを使用します。レプリカの追加によるスケーリングをサポートし、非同期レプリケーションを使用します。
• Aurora MySQL (DSQL): オプティミスティック同時実行制御を使用して、書き込み用に複数のクエリプロセッサを備えたアクティブ/アクティブ アーキテクチャを採用します。分散ブロック ストアによる読み取りに対して独立してスケーリングします。
• Aurora の読み取りおよび書き込みプロセス:
• 読み取り: データは、選択されたクエリ プロセッサによってアベイラビリティ ゾーン (AZ) 全体のストレージ サーバーからフェッチされます。
• 書き込み: クエリ プロセッサは、トランザクションがコミットされるまで書き込み操作をスプールアップします。コミット時に、書き込みは (競合解決のため) 裁定者に送信され、次にジャーナル (AZ にわたるログ ストレージのため) に送信され、影響を受けるストレージ シャードが更新されます。
• マルチリージョン操作:
• Aurora PostgreSQL: リージョン間のデータに非同期レプリケーションを使用するため、リージョン内コミットのレイテンシーが発生します。
• Aurora MySQL: コミットはリージョン間で同期的にレプリケートされるため、根本的な違いとしてリージョン間のコミット レイテンシーが発生します。