# Amazon Optimized Reads による Aurora PostgreSQL のクエリパフォーマンスの向上
Aurora Optimized Reads で Aurora PostgreSQL のクエリ処理を高速化できます。Aurora Optimized Reads を使用する Aurora PostgreSQL DB インスタンスは、DB インスタンスのメモリ容量を超える大規模なデータセットを持つアプリケーションのクエリレイテンシーを最大 8 倍改善し、コストを最大 30% 削減します。
**Topics**
+ [PostgreSQL の Aurora Optimized Reads の概要](#AuroraPostgreSQL.optimized.reads.overview)
+ [Aurora Optimized Reads の使用](#AuroraPostgreSQL.optimized.reads.using)
+ [Aurora Optimized Reads のユースケース](#AuroraPostgreSQL.optimized.reads.usecases)
+ [Aurora Optimized Reads を使用する DB インスタンスのモニタリング](#AuroraPostgreSQL.optimized.reads.monitoring)
+ [Aurora Optimized Reads のベストプラクティス](#AuroraPostgreSQL.optimized.reads.bestpractices)
## PostgreSQL の Aurora Optimized Reads の概要
Aurora Optimized Reads は、Graviton ベースの R6gd、R8gd、および Intel ベースの R6id インスタンスと不揮発性メモリエクスプレス (NVMe) ストレージを備えた DB クラスターを作成するときに、デフォルトで使用できます。以下の PostgreSQL バージョンから入手できます。
+ R8gd インスタンスの 14.12 以降のバージョン、15.7 以降のバージョン、16.3 以降のバージョン、17.4 以降のバージョン
+ R6gd および R6id インスタンスの 14.9 以降のバージョン、15.4 以降のバージョン、16.1 以降のすべてのバージョン
Aurora Optimized Reads は、階層型キャッシュと一時オブジェクトの 2 つの機能をサポートしています。
**Optimized Reads 対応階層型キャッシュ** - 階層型キャッシュを使用すると、DB インスタンスのキャッシュ容量をインスタンスメモリの 5 倍まで拡張できます。これにより、トランザクションが一貫した最新のデータがキャッシュに自動的に保持され、外部の結果セットベースのキャッシュソリューションによるデータ流通管理のオーバーヘッドからアプリケーションが解放されます。これまで Aurora ストレージからデータを取得していたクエリのレイテンシーが最大 8 倍向上します。
Aurora では、デフォルトパラメータグループでの `shared_buffers` の値は、通常、使用可能なメモリの約 75% に設定されます。ただし、r8gd、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 は一時オブジェクトのみを使用します。
Aurora I/O 最適化クラスターでは、インスタンスレベルで動的パラメータ `aurora_temp_space_size` を使用して、Optimized Reads が有効な一時オブジェクトに割り当てられたスペースのサイズを変更できます。この変更機能は、以下の PostgreSQL バージョンから入手できます。
+ 16.8 以降のすべてのバージョン
+ 15.12 以降の 15 バージョン
+ 14.17 以降の 14 バージョン
このパラメータを使用すると、データベースエンジンの再起動を必要とせずに、インスタンスメモリの容量を 2 倍から 6 倍まで変更できます。一時オブジェクトスペースを拡張すると、同時実行ワークロードに関係なく、変更はすぐに有効になります。ただし、スペースを減らすと、新しいサイズリクエストに対応するために、一時オブジェクトに十分な未使用のスペースがある場合にのみ調整が完了します。Optimized Reads 対応一時オブジェクトのサイズを変更すると、階層型キャッシュは使用可能なスペースを使用するように自動的に調整されます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html)
**注記**
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 クラスターの作成](Aurora.CreateInstance.md)」を参照してください。
+ NVMe ベースの DB インスタンスクラスの 1 つを使用して、既存の Aurora PostgreSQL DB クラスターを変更します。詳細については、「[Amazon Aurora DB クラスターの変更](Aurora.Modifying.md)」を参照してください。
Aurora Optimized Reads は、ローカル NVMe SSD ストレージのある DB インスタンスクラスの 1 つ以上がサポートされているすべての AWS リージョン で使用できます。詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
最適化されていない読み取り Aurora インスタンスに戻すには、Aurora インスタンスの DB インスタンスクラスを、データベースワークロードの NVMe エフェメラルストレージがない同様のインスタンスクラスに変更します。例えば、現在の DB インスタンスクラスが db.r6gd.4xlarge の場合、db.r6g.4xlarge を選択して元に戻します。詳細については、「[Aurora DB インスタンスを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)」を参照してください。
## 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 のインスタンスレベルのメトリクス](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)
`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 のクラスターキャッシュ管理によるフェイルオーバー後の高速リカバリ](AuroraPostgreSQL.cluster-cache-mgmt.md)」を参照してください。