Slide 1
Slide 1 text
Aurora PostgreSQLをちょっとだけ
（AWS-HUB@名古屋⽀部【2018年12⽉12⽇】
忘年会スペシャル ＆ re:Invent振り返LT⼤会）
hmatsu47（松久 裕保）
Slide 2
Slide 2 text
re:Invent 2018 前
Aurora Serverless Database with the New Data API
https://aws.amazon.com/jp/about-aws/whats-
new/2018/11/aurora-serverless-data-api-beta/
Aurora PostgreSQL Serverless (Preview)
https://aws.amazon.com/jp/about-aws/whats-
new/2018/11/sign-up-for-the-preview-of-amazon-aurora-
postgresql-serverless/
今⽇はこれらのネタは関係ありません。
Slide 3
Slide 3 text
ちなみに
DMS Version 3.1.2 登場︕
https://aws.amazon.com/jp/blogs/news/introducing-aws-
dms-replication-engine-version-3-1-2/
やっと utf8mb4 がサポートされた（らしい）︕
今⽇はこの話でもないです。
Slide 4
Slide 4 text
とある事情で
PostgreSQL Advent Calendar 2018 になにか書くことに
犯⼈依頼⼈はこの⼈↓
右⼿に持ってるのはしゃもじです
Slide 5
Slide 5 text
原因はこれだった
Advent Calendar を書いてるどころではなかったらしい
Slide 6
Slide 6 text
仕⽅がないので書いた
https://qiita.com/hmatsu47/items/16b8d3e1eaff9e5a6247
https://qiita.com/hmatsu47/items/7adbe764696b85c637a2
Slide 7
Slide 7 text
内容
PostgreSQL では、共有バッファでデータのキャッシュとダー
ティーページの管理などを⾏う
MySQL ではバッファプール
MySQL のバッファプールとは違い、PostgreSQL の共有バッ
ファは⼤きくしすぎてはいけない（らしい）
全メモリ容量の 1/4 くらいまでにとどめておく
共有バッファから溢れた分について、OS のディスクキャ
ッシュでフォローしてもらう思想（らしい）
Aurora PostgreSQL 互換版では、フェイルオーバーしたときに
共有バッファと OS のディスクキャッシュは両⽅とも⽣きのこ
るの︖
実験︕
Slide 8
Slide 8 text
結果
共有バッファはフェイルオーバーしても⽣きのこる
そもそも OS のディスクキャッシュに相当する機構がない︖
共有バッファを溢れた分はキャッシュされないのでスト
レージノードへ取りに⾏く（ぽい）
Slide 9
Slide 9 text
ここで RDBMS の仕組みについて⼤雑把に補⾜
データの更新があった場合、
先⾏ログ（Write Ahead Log︓WAL）をシーケンシャル
Write でディスクに記録
データページそのものはメモリ上のバッファ／キャッシ
ュに記録するだけですぐにはディスクに書き出さない
（ランダム Write の抑制）
ある程度変更（ダーティーページ）が溜まったところで
まとめて書き出す（チェックポイント処理）
MySQL のバッファプールや PostgreSQL の共有バッファはこ
の⽤途にも使われている
Slide 10
Slide 10 text
ところで Aurora の仕組みは︖
データの更新があった場合、
WAL（Redo Log）をストレージノードとクラスタの
Reader（レプリカ）に送り出す
メモリ上のバッファ／キャッシュには記録するだけ
メモリ上のバッファ／キャッシュはただのキャッシュであっ
て、ダーティーページ管理には利⽤していない
追記型のストレージ（SQL ノードとは別ノードで処理）
キャッシュ外のデータはストレージノードへ取りに⾏く
SQL ノードローカルのディスクは経由しない（ので OS の
ディスクキャッシュが使われることはない）
PostgreSQL 互換版も同じ（ぽい）
Slide 11
Slide 11 text
もしかして
Aurora PostgreSQL 互換版は MySQL 互換版と⽐較して、本家
より遅くなるシーンが多い︖
Slide 12
Slide 12 text
と、ここで思い出した
パラメータグループの shared_buffers の初期値
RDS
{DBInstanceClassMemory/32768}
Aurora
{DBInstanceClassMemory/10922}
3 倍違った
Slide 13
Slide 13 text
資料を漁ってみた
あった
https://www.slideshare.net/AmazonWebServices/deep-
dive-on-the-amazon-aurora-postgresqlcompatible-
edition-dat402-reinvent-2017
P.29 〜 30 「No Double Buffering」
Aurora PostgreSQL 互換版では全メモリ容量の 3/4 を共有
バッファに取る仕様（⼆重のバッファリングはしない）
Slide 14
Slide 14 text
めでたしめでたし
まてよ︖
「PostgreSQL の共有バッファは⼤きくしすぎてはいけない」
んじゃなかったの︖
理由の 1 つはチェックポイント処理（ダーティーページ
書き出し︓Aurora では不要）の負荷だけど…
Slide 15
Slide 15 text
つづく
気が向いたら…
その前に、明⽇⼤阪の re:Invent 2018 ダイジェストに⾏けたら
聞いて来よう
午前中の検査でストップがかからないことを祈る
Slide 16
Slide 16 text
ありがとうございました