Amazon Optimized Reads による Aurora PostgreSQL のクエリパフォーマンスの向上 - Amazon Aurora
PostgreSQL の Aurora Optimized Reads の概要使用ユースケースモニタリングベストプラクティス

Amazon Optimized Reads による Aurora PostgreSQL のクエリパフォーマンスの向上

Aurora Optimized Reads で Aurora PostgreSQL のクエリ処理を高速化できます。Aurora Optimized Reads を使用する Aurora PostgreSQL DB インスタンスは、DB インスタンスのメモリ容量を超える大規模なデータセットを持つアプリケーションのクエリレイテンシーを最大 8 倍改善し、コストを最大 30% 削減します。

PostgreSQL の Aurora Optimized Reads の概要

Aurora Optimized Reads は、Graviton ベースの R6gd インスタンスと不揮発性メモリエクスプレス (NVMe) ストレージを備えた Intel ベースの R6id インスタンスを使用する DB クラスターを作成するときに、デフォルトで使用できます。以下の PostgreSQL バージョンから入手できます。

  • 16.1 以降のすべてのバージョン

  • 15.4 以降のバージョン

  • 14.9 以降のバージョン

Aurora Optimized Reads は、階層型キャッシュと一時オブジェクトの 2 つの機能をサポートしています。

Optimized Reads 対応階層型キャッシュ - 階層型キャッシュを使用すると、DB インスタンスのキャッシュ容量をインスタンスメモリの 5 倍まで拡張できます。これにより、トランザクションが一貫した最新のデータがキャッシュに自動的に保持され、外部の結果セットベースのキャッシュソリューションによるデータ流通管理のオーバーヘッドからアプリケーションが解放されます。これまで Aurora ストレージからデータを取得していたクエリのレイテンシーが最大 8 倍向上します。

Aurora では、デフォルトパラメータグループでの shared_buffers の値は、通常、使用可能なメモリの約 75% に設定されます。ただし、r6gd および r6id インスタンスタイプの場合、Aurora は Optimized Reads キャッシュのメタデータをホストするため、shared_buffers スペースを 4.5% 削減します。

Optimized Reads 対応一時オブジェクト - 一時オブジェクトを使用すると、PostgreSQL によって生成された一時ファイルをローカルの NVMe ストレージに配置することで、クエリ処理を高速化できます。これにより、ネットワーク経由の Elastic Block Storage (EBS) へのトラフィックが減少します。DB インスタンスで使用可能なメモリ容量に収まらない大量のデータをソート、結合、またはマージする高度なクエリでは、レイテンシーとスループットが最大 2 倍向上します。

Aurora I/O 最適化クラスターでは、Optimized Reads は NVMe ストレージ上の階層型キャッシュと一時オブジェクトの両方を利用します。Optimized Reads 対応階層型キャッシュ機能により、Aurora はインスタンスメモリの 2 倍を一時オブジェクトに、ストレージの約 10% を内部オペレーションに、残りのストレージを階層型キャッシュとして割り当てます。Aurora スタンダードクラスターでは、Optimized Reads は一時オブジェクトのみを使用します。

エンジン クラスターのストレージ設定 Optimized Reads 対応一時オブジェクト Optimized Reads 対応階層型キャッシュ サポートされるバージョン
Aurora PostgreSQL 互換エディション 標準 はい 不可 Aurora PostgreSQL バージョン 16.1 およびそれ以降のすべてのバージョン、15.4 以降、バージョン 14.9 以降
I/O 最適化 はい はい
注記

NVMe ベースの DB インスタンスクラスで IO 最適化クラスターとスタンダードクラスターを切り替えると、データベースエンジンがすぐに再起動します。

Aurora PostgreSQL では、一時オブジェクトが格納されるテーブルスペースを設定するのに temp_tablespaces パラメータを使用します。

一時オブジェクトが設定されているかどうかを確認するには、次のコマンドを使用します。

postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
aurora_temp_tablespace
(1 row)

aurora_temp_tablespace は、NVMe ローカルストレージを指す Aurora によって設定された表領域です。このパラメータは変更できません。また、Amazon EBS ストレージに切り替えることはできません。

Optimized Reads キャッシュがオンになっているかどうかを確認するには、次のコマンドを使用します。

postgres=> show shared_preload_libraries;
                 shared_preload_libraries
--------------------------------------------------------
rdsutils,pg_stat_statements,aurora_optimized_reads_cache

Aurora Optimized Reads の使用

NVMe ベースの DB インスタンスを使用して Aurora PostgreSQL DB インスタンスをプロビジョニングすると、DB インスタンスは自動的に Aurora Optimized Reads を使用します。

RDS Optimized Reads をオンにするには、次のいずれかの操作を行います。

  • NVMe ベースの DB インスタンスクラスの 1 つを使用して、Aurora PostgreSQL DB クラスターを作成します。詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。

  • NVMe ベースの DB インスタンスクラスの 1 つを使用して、既存の Aurora PostgreSQL DB クラスターを変更します。詳細については、「Amazon Aurora DB クラスターの変更」を参照してください。

Aurora Optimized Reads は、ローカル NVMe SSD ストレージのある DB インスタンスクラスの 1 つ以上がサポートされているすべての AWS リージョン で使用できます。詳細については、「Amazon Aurora DB インスタンスクラス」を参照してください。

最適化されていない読み取り Aurora インスタンスに戻すには、Aurora インスタンスの DB インスタンスクラスを、データベースワークロードの NVMe エフェメラルストレージがない同様のインスタンスクラスに変更します。例えば、現在の DB インスタンスクラスが db.r6gd.4xlarge の場合、db.r6g.4xlarge を選択して元に戻します。詳細については、「Aurora DB インスタンスを変更する」を参照してください。

Aurora Optimized Reads のユースケース

Optimized Reads 対応階層型キャッシュ

以下に、階層型キャッシュで Optimized Reads を使用することでメリットが得られるユースケースをいくつか紹介します。

  • 支払い処理、請求、E コマースなど、厳格なパフォーマンス SLA を備えたインターネットスケールアプリケーション。

  • メトリクスやデータ収集のために何百ものポイントクエリを実行するリアルタイムレポートダッシュボード。

  • pgvector 拡張機能を備えた生成 AI アプリケーションにより、何百万ものベクター埋め込みから正確な近傍または最近傍を検索できます。

Optimized Reads 対応一時オブジェクト

以下に、一時オブジェクトで Optimized Reads を使用することでメリットが得られるユースケースをいくつか紹介します。

  • テーブル共通式 (CTE)、派生テーブル、グループ化オペレーションを含む分析クエリ。

  • アプリケーションの最適化されていないクエリを処理するリードレプリカ。

  • GROUP BY や ORDER BY などの複雑な操作を伴うオンデマンドまたは動的なレポートクエリで、常に適切なインデックスを使用できるとは限らないもの。

  • ソート用の CREATE INDEX または REINDEX 操作。

  • 内部の一時テーブルを使用するその他のワークロード。

Aurora Optimized Reads を使用する DB インスタンスのモニタリング

Aurora Optimized Reads 対応階層型キャッシュを使用するクエリは、次の例のように EXPLAIN コマンドでモニタリングできます。

Postgres=> EXPLAIN (ANALYZE, BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000                   

QUERY PLAN
--------------------------------------------------------------------------------------
 Index Scan using sbtest15_pkey on sbtest15  (cost=0.57..8.59 rows=1 width=121) (actual time=0.287..0.288 rows=1 loops=1)
   Index Cond: (id = 100000000)
   Buffers: shared hit=3 read=2 aurora_orcache_hit=2
   I/O Timings: shared/local read=0.264
 Planning:
   Buffers: shared hit=33 read=6 aurora_orcache_hit=6
   I/O Timings: shared/local read=0.607
 Planning Time: 0.929 ms
 Execution Time: 0.303 ms
(9 rows)
Time: 2.028 ms
注記

説明プランの Buffers セクションにある aurora_orcache_hit およびaurora_storage_read フィールドは、Optimized Reads が有効で、値が 0 より大きい場合にのみ表示されます。読み取りフィールドは、aurora_orcache_hit と aurora_storage_read フィールドの合計です。

Aurora Optimized Reads を使用する DB インスタンスは、次の CloudWatch メトリクスでモニタリングできます。

  • AuroraOptimizedReadsCacheHitRatio

  • FreeEphemeralStorage

  • ReadIOPSEphemeralStorage

  • ReadLatencyEphemeralStorage

  • ReadThroughputEphemeralStorage

  • WriteIOPSEphemeralStorage

  • WriteLatencyEphemeralStorage

  • WriteThroughputEphemeralStorage

これらのメトリクスでは、利用可能なインスタンスストアストレージ、IOPS、スループットに関するデータを提供します。これらのメトリクスの詳細については、「Amazon Aurora のインスタンスレベルのメトリクス」を参照してください。

pg_proctab 拡張機能を使用して NVMe ストレージをモニタリングすることもできます。

postgres=>select * from pg_diskusage();

major | minor |       devname       | reads_completed | reads_merged | sectors_read | readtime | writes_completed | writes_merged | sectors_written | writetime | current_io | iotime  | totaliotime
------+-------+---------------------+-----------------+--------------+--------------+----------+------------------+---------------+-----------------+-----------+------------+---------+-------------
      |       | rdstemp             |           23264 |            0 |       191450 |    11670 |          1750892 |             0 |        24540576 |    819350 |          0 | 3847580 |      831020
      |       | rdsephemeralstorage |           23271 |            0 |       193098 |     2620 |           114961 |             0 |        13845120 |    130770 |          0 |  215010 |      133410
(2 rows)

Aurora Optimized Reads のベストプラクティス

Aurora Optimized Reads を使用するベストプラクティスは次のとおりです。

  • CloudWatch メトリクスの FreeEphemeralStorage を使用して、インスタンスストアで使用可能なストレージ容量をモニタリングします。DB インスタンスのワークロードが原因でインスタンスストアが上限に達している場合は、同時実行数と一時オブジェクトを頻繁に使用するクエリを調整するか、より大きな DB インスタンスクラスを使用するように変更します。

  • CloudWatch メトリクスをモニタリングして、Optimized Reads キャッシュヒットレートを確認します。VACUUM のようなオペレーションでは、多数のブロックを非常に素早く変更します。これにより、ヒットレートが一時的に低下する可能性があります。pg_prewarm 拡張機能を使用すると、データをバッファキャッシュにロードできます。これにより、Aurora はそれらのブロックの一部を Optimized Reads キャッシュに事前に書き込むことができます。

  • クラスターキャッシュ管理 (CCM) を有効にすると、フェイルオーバーターゲットとして使用される Tier-0 リーダーのバッファキャッシュと階層型キャッシュをウォームアップできます。CCM を有効にすると、バッファキャッシュが定期的にスキャンされ、エビクションの対象となるページが階層型キャッシュに書き込まれます。CCM の詳細については、「Aurora PostgreSQL のクラスターキャッシュ管理によるフェイルオーバー後の高速リカバリ」を参照してください。