Aurora PostgreSQLと通常のPostgreSQLのチューニング上の違い

Aurora PostgreSQLのチューニング情報をネットで探してみると、PostgreSQL自体の情報はたくさんあるのですが、それがAurora PostgreSQLにそのまま利用できるのか、効果的なのか、といったことについて書いている記事は見つけられませんでした。
そこで、実際にチューニング作業の中で体験的にわかった、感じたことを記載しておきます。

以下、本記事では区別しやすいように、「Aurora PostgreSQL」は「Aurora」または「Aurora PostgreSQL」、通常の「PostgreSQL」は「"PostgreSQL"」と表記します。

利用したAurora PosgreSQLは13.7です。

要約

• "PostgreSQL"のチューニング項目は、Auroraでは使えるものもあるが、使えないもの、使っても効果がないものもある。
  • SQL単体でのチューニングの考え方はそのまま適用できる
  • システムに関わるものは設定自体ができないものも多い
    • 設定はできても効果がない場合もある
    • 記事を鵜吞みにせず試してみる必要がある

"SQL"チューニング手法はほぼそのまま使える

Aurora PostgreSQLのベースはやはり"PostgreSQL"なので、アーキテクチャは基本同じです。
そのため、SQLとしてどういった書き方が効率的であるとか、パラレルクエリはいつ適用されるのか、といったことは"PostgreSQL"の説明がそのまま当てはまります。
たとえば、アーキテクチャ的に他のDBMSと比べてUPDATEが遅いのでUPDATEの同値更新は避ける、とか。
または、パラレルクエリはどういったときに適用されるのか、とか。
そうしたSQL単位でのチューニングの考え方は"PostgreSQL"と同じです。
なので、"PostgreSQL"の記事を参考にチューニングを行うことができます。

※　上記の例に挙げたチューニングに関わるこうした部分については私もいくつか書きましたので、参考にしていただければ。

PostgreSQLのUPDATEの特徴とfillfactorをわかりやすく説明してみました
Aurora PostgreSQLのチューニングポイント
パラレルクエリの有効利用の仕方

"システム"チューニング手法は使えないものや効果的ではないものがある

ここでいう「システムチューニング」とはアプリケーション外の要素に対するチューニング項目です。

Auroraはマネージドシステムといって、OSや物理ディスクやパックアップなどはAWSの管理下にあり、ブラックボックスになっています。
物理的なものも含めデータの安全性に関わる部分はAWS側で保証しますよ、という形です。

ありがたいことなのですが、逆に言えば、この「データ安全性」に関わる部分は外部からは触ることができないようになっています。

このため、OSパラメータやデータ保証に関わる部分については設定できないものがあります。

設定できないパラメータ例

"PostgreSQL"のチューニング項目としてWALやチェックポイントというものがよく挙げられます。
テーブルへの変更があった場合、毎回物理ディスクに書込を行うと時間がかかります。
そこで、テーブル変更の情報をいったんWALというメモリ上の保管場所に保存し、物理ディスクには「チェックポイント」のタイミングで書き出す、といった仕組みです。
この仕組みにより物理ディスク書込という時間のかかる処理の回数を減らしているわけです。
この「チェックポイント」のタイミングは"PostgreSQL"ではデフォルト10分です。
このチェックポイント期間を１時間などに設定することで物理ディスクへのアクセス量をさらに減らして性能を向上させるというのは"PostgreSQL"ではメジャーな手法のようです。

ですが、これはAurora PostgreSQLでは使えません。
Auroraではデータ保証を確実にするために"チェックポイント"の概念自体を持っておらず、WALの情報はすぐに物理ディスクに書き出しているとの記述がありました。
参考：https://enterprisezine.jp/article/detail/16194?p=2

"PostgreSQL"でのチェックポイントの設定は「checkpoint_timeout」「max_wal_size」といったパラメータで行うのですが、Aurora PostgreSQLではこれらのパラメータ自体が設定できないようになっています。
（後述しますが、パラメータ自体は存在するが設定不可となっているようです）

PostgreSQLにあるがAuroraでは設定できないパラメータ

前項で例にあげた「チェックポイント」のように、"PostgreSQL"にはあるがAuroraにはない項目は他になにがあるでしょうか。
ここでは"PostgreSQL"では設定可能だがAuroraでは設定できない項目をリスト化して比較してみました。
やり方としては、以下２つの比較です。

• ①pgadminから実パラメータ一覧を取得
• ②AWSのRDS「パラメータグループ」で指定可能な設定項目一覧を取得

①については以下のコマンドで取得しました。

SHOW all

②についてはAWSのマネージドコンソール画面で以下の画面から取得しました。
RDS > パラメータグループ > (現在適用中のパラメータグループを選択) > 「パラメータ」

私の担当システムでは数字的には以下の状況でした。
パラメータの数が多いので、大まかに分類した内容で記載します。

• パラメータ数

  • ①391
  • ②359

• 設定不可だが実設定としては存在するもの（①にあって②にないもの）：142

  • ざっとした内訳
    • バッファ・キャッシュ関連
    • バックグラウンドでの動作関連
    • チェックポイント関連
    • 処理待ち時間や最大値設定
    • ロケール・文字コード関連
    • ログ関連
    • バックアップ・リストア関連
    • 通信関連（ssl）
    • rds固有

こうして見てみると見事に裏側の仕組みとAWSが担う部分が設定不可になっていますね。

これらに関わるものは"PosgreSQL"でチューニング項目として挙げられていてもAurora PostgreSQLでは利用できないということになります。

設定不可な項目で性能劣化になっていないか？

設定できないのはしょうがないのですが、その中には"PostgreSQL"ではチューニング項目として挙げられるものもあります。
チェックポイント関連はその一例です。
これらは、性能に関わる部分なので、Auroraで設定できないことが性能劣化につながっていないかが気になります。

これは私がチューニングしているときの感想になりますが、性能劣化にならないように工夫されているように思いました。

work_memの事例

"PostgreSQL"のチューニング項目としてよく挙げられるものに「work_mem」があります。
work_memのサイズを大きくすることで、メモリ上で保存しておける容量が増え、結果として物理ディスクに書き出すデータ量や回数を減らすことにつながるパラメータです。
チェックポイントのチューニングと考え方は同じですね。

このwork_memはAurora PostgreSQLでも設定可能なので、チューニングとしてサイズ変更を色々試しました。
ですが、サイズを大きくしても、性能はほとんど変わらず、逆にかえって遅くなるくらいでした。

このことから、Aurora PostgreSQLでは物理ディスクへの書込・読込はほぼメモリと変わらない性能が出ていると思います。
このため、チェックポイントなどの設定がいじれなくても問題ないように工夫されているように感じました。
(2023/10/02追記ここから）
ここについて、物理ディスクアクセスとメモリアクセスが同等の性能というのはさすがに考えられないとコメントいただきました。もっともなご指摘です。
思い返してみると、ボトルネックがディスクアクセスではない状況でwork_memを変更したために性能変化がなかった可能性があります。
なので「物理ディスクへの書込・読込はほぼメモリと変わらない性能」というのは憶測でしかなく言い過ぎですので取り消しさせてください。
ただ、ここに記載していない他の検証などで「"PostgreSQL"で言われるほどAurora PostgreSQLでは効果が出ない」というのは実際にそうでしたので、「Auroraでは"PostgreSQL"での効果を鵜吞みにせずきちんと実検証しましょう」という点が大事な点は変わりません。
(2023/10/02追記ここまで）

また、このwork_memの事例から、"PostgreSQL"で効果があるとされるチューニング項目がAurora PostgreSQLでは効果が薄かったりなかったりすることもあります。

これらを踏まえ、"PostgreSQL"で挙げられるシステムチューニング項目は、Aurora PostgreSQLでは設定可否や効果の有無を実際に確認するのが大事だと思います。