案件でふと気になった内容を、こちらでまとめます。

Kubernetes上にPostgreSQLをデプロイする際に悩みがちなのが、
resources.requests と limits の設定。

アプリと違って、DBは適当に設定すると OOM Kill → 即障害 になりやすいので、最低限の考え方をまとめます。

---

結論

まず実務的な結論。

• requests ≒ limits にするのが基本

• メモリは PostgreSQL設定から逆算

• CPUは後からチューニングでもOK

DBはGuaranteed QoSで動かすのが無難。

---

なぜDBは特別扱いなのか？

理由はシンプル。

• PostgreSQLはメモリ前提の設計

• メモリ不足 = 性能劣化じゃなくて死亡

• OOM KillでWAL破損リスクあり

つまり「足りないと死ぬ」。

---

メモリの見積もり方法（重要）

PostgreSQLのメモリは大きく3種類。

① 固定メモリ

• shared_buffers

• background workers

常に使用される領域。

---

② 接続ごとのメモリ

• work_mem

• maintenance_work_mem

ここが爆発ポイント。

max_connections に比例して増える。

---

③ その他

• autovacuum

• OS page cache

• WAL buffer

余裕分として見積もる。

---

実務テンプレ計算式

ざっくり見積もるならこれでOK。

---

計算例

設定例：

計算：

合計：

→ requests.memory = 12Gi

---

CPUの考え方

CPUはメモリほどシビアじゃない。

ざっくり目安：

迷ったら 2vCPUスタート でOK。

---

limitsはどうする？

基本は2択。

パターン① requests = limits（推奨）

メリット:

• OOM減る

• QoS Guaranteed

デメリット:

• ノード密度下がる

---

パターン② limitsなし

---

Kubernetes特有の注意点

OOM Killは想像以上に危険

PostgreSQLはOOMに弱い。

• WAL flush中に死亡

• crash recovery長時間

• PVC肥大化の原因にも

メモリlimitは慎重に。

---

swapは基本無い

Kubernetesはswap無効が多い。

つまり：

メモリ不足 = 即OOM

---

実務でよくやる決め方

理論より現場はこっち。

方法① 既存環境から逆算

• VM版PostgresのRSSを見る

• Prometheusのmemory usage確認

---

方法② 小さく始めて観測

• requests=4Giで開始

• Prometheusで観測

• 徐々に上げる

---

参考リンク

良記事まとめ。

• https://learnk8s.io/postgresql-ha

• https://cloudnative-pg.io/documentation/

• https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

• https://pgtune.leopard.in.ua/

CloudNativePGのドキュメントは特に実務向け。