Managed PostgreSQL หรือการเช่า PostgreSQL แบบมีผู้ดูแล คือการให้ผู้ให้บริการรันฐานข้อมูลแทนเรา ทั้งแบ็กอัป การกู้คืนย้อนเวลา (PITR) การสลับเครื่องเมื่อเครื่องหลักล่ม การอัปเดตแพตช์ และการมอนิเตอร์ ทีมของเรามีหน้าที่แค่เชื่อมต่อและพัฒนาระบบ ส่วนการติดตั้งดูแลเองให้อิสระเต็มที่และค่าเซิร์ฟเวอร์อาจดูถูกกว่า แต่จะคุ้มก็ต่อเมื่อมีคนในทีมที่มีทั้งเวลาและความรู้พอจะทำงานดูแลเหล่านี้อย่างสม่ำเสมอ สำหรับ SME และทีมพัฒนาที่ไม่มี DBA โดยเฉพาะ managed database มักเป็นตัวเลือกที่เสี่ยงน้อยกว่า
"Managed" ดูแลอะไรให้บ้าง
Managed ไม่ได้แปลว่าเราไม่ต้องทำอะไรเลย แต่เป็นการแบ่งความรับผิดชอบกัน ควรรู้ให้ชัดว่าใครดูแลส่วนไหน
| งาน | ดูแลเอง | Managed |
|---|---|---|
| เตรียมเซิร์ฟเวอร์และแพตช์ OS | เรา | ผู้ให้บริการ |
| อัปเดต PostgreSQL เวอร์ชันย่อย | เรา | ผู้ให้บริการ (มักทำในช่วง maintenance) |
| แบ็กอัปและระยะเวลาเก็บ | เรา | ผู้ให้บริการ |
| กู้คืนย้อนเวลา (PITR) | เราต้องสร้างและทดสอบเอง | ผู้ให้บริการ |
| Replication และ failover อัตโนมัติ | เรา | ผู้ให้บริการ |
| มอนิเตอร์และแจ้งเตือน | เรา | ผู้ให้บริการ พร้อมแดชบอร์ดให้ดู |
| การเข้าถึงเครือข่ายและ TLS | เรา | ร่วมกัน |
| ออกแบบ schema, index, query ที่ช้า | เรา | ยังเป็นเรา |
| สิทธิ์ของแต่ละแอปพลิเคชัน | เรา | ยังเป็นเรา |
สองแถวสุดท้ายสำคัญมาก managed service ช่วยให้ฐานข้อมูลที่ออกแบบ index ไม่ดีออนไลน์ได้ตลอด แต่ไม่ได้ทำให้มันเร็วขึ้น
แบ็กอัปและการกู้คืนย้อนเวลา (PITR)
การรัน pg_dump ทุกคืนเป็นจุดเริ่มต้นที่ดี แต่ได้แค่ภาพฐานข้อมูล ณ เวลาเดียว และกู้คืนช้าเมื่อฐานข้อมูลใหญ่ขึ้น ระบบที่จริงจังจะใช้ base backup ระดับไฟล์ร่วมกับการเก็บ WAL (write-ahead log) อย่างต่อเนื่อง ทำให้กู้คืนย้อนไปเวลาใดก็ได้ เช่น 14:32 น. ก่อนที่ใครสักคนจะเผลอรัน DELETE โดยไม่มี WHERE
ถ้าดูแลเอง เครื่องมืออย่าง pgBackRest, WAL-G หรือ Barman ทำเรื่องนี้ได้ดี แต่ยังต้อง
- เก็บสำเนาแยกจากเครื่องฐานข้อมูล ควรอยู่คนละที่ และเข้ารหัสไว้
- กำหนดระยะเวลาเก็บย้อนหลังว่าต้องย้อนได้กี่วัน
- ซ้อมกู้คืนตามรอบ เพราะแบ็กอัปที่ไม่เคยลองกู้คืนก็เป็นแค่ความหวัง
- ตกลง RPO (ยอมเสียข้อมูลได้มากสุดเท่าไร) และ RTO (ยอมให้ระบบล่มได้นานแค่ไหน)
High Availability และการ Failover
HA โดยทั่วไปคือเครื่องหลัก (primary) ส่งการเปลี่ยนแปลงไปยังเครื่องสำรอง (standby) อย่างต่อเนื่อง แต่ replication อย่างเดียวยังไม่พอ ต้องมีตัวตรวจจับว่าเครื่องหลักล่ม เลื่อนเครื่องสำรองขึ้นมาแทน และพาแอปพลิเคชันไปต่อที่เครื่องใหม่ ทีมที่ดูแลเองมักใช้ Patroni ร่วมกับ etcd หรือใช้ Kubernetes operator อย่าง CloudNativePG พร้อมชั้นจัดการการเชื่อมต่อ เช่น HAProxy, PgBouncer หรือ DNS ถ้าตั้งค่าผิดอาจเกิด "split brain" คือมีสองเครื่องรับการเขียนพร้อมกัน ซึ่งเป็นปัญหาที่ตามแก้ยากที่สุดปัญหาหนึ่ง
สำหรับ managed service การ failover เป็นส่วนหนึ่งของบริการ แต่ควรอ่าน SLA ให้ละเอียดว่ารับประกัน uptime เท่าไร นิยามการล่มอย่างไร และเครื่องสำรองอยู่คนละโซนหรือคนละภูมิภาคหรือไม่
การอัปเกรดเวอร์ชัน
โปรเจกต์ PostgreSQL ออกเวอร์ชันย่อยเป็นประจำ (อย่างน้อยทุกไตรมาส) เพื่อแก้ช่องโหว่และบั๊ก และแต่ละเวอร์ชันหลักได้รับการซัพพอร์ตประมาณห้าปี การอัปเดตเวอร์ชันย่อยความเสี่ยงต่ำแต่ต้องรีสตาร์ต ส่วนการอัปเกรดเวอร์ชันหลักต้องใช้ pg_upgrade หรือ logical replication ตรวจความเข้ากันได้ของ extension และทดสอบแอปพลิเคชัน ทีมที่ดูแลเองจึงมักเลื่อนออกไปเรื่อยๆ จนสุดท้ายค้างอยู่บนเวอร์ชันที่หมดการซัพพอร์ตแล้ว
การมอนิเตอร์
ใครก็ตามที่ดูแลฐานข้อมูลต้องเฝ้าดูและตั้งแจ้งเตือนเรื่องเหล่านี้
- พื้นที่ดิสก์และขนาด WAL ที่โตขึ้น (ดิสก์เต็มเมื่อไร ฐานข้อมูลหยุดทันที)
- จำนวน connection และ connection pool ที่ใกล้เต็ม
- ความหน่วงของ replication
- transaction ที่ค้างนานและการล็อก
- การทำงานของ autovacuum และตารางที่บวม (bloat)
- query ที่ช้า ผ่าน extension
pg_stat_statements
ทีมที่ดูแลเองนิยมใช้ Prometheus คู่กับ postgres_exporter และแดชบอร์ด Grafana ตัวเครื่องมือฟรี แต่เวลาที่ใช้ปรับการแจ้งเตือนและตื่นมาแก้ปัญหาตอนตีสองไม่ฟรี
ความปลอดภัย
ไม่ว่าจะเลือกทางไหน ควรทำเหมือนกัน คือไม่เปิดฐานข้อมูลออกอินเทอร์เน็ตสาธารณะ (ใช้เครือข่ายส่วนตัว VPN หรือจำกัด IP อย่างเข้มงวด) บังคับใช้ TLS ใช้การยืนยันตัวตนแบบ SCRAM-SHA-256 แยก role ให้แต่ละแอปพลิเคชันโดยให้สิทธิ์เท่าที่จำเป็น เข้ารหัสแบ็กอัป และลงแพตช์ให้ทันเวลา ถ้าฐานข้อมูลมีข้อมูลลูกค้า PDPA กำหนดให้เราต้องดูแลและอธิบายได้ว่าดูแลอย่างไร
ต้นทุนรวม (Total Cost of Ownership)
ความผิดพลาดที่พบบ่อยที่สุดคือเทียบกันแค่ค่าเซิร์ฟเวอร์ การเปรียบเทียบที่ยุติธรรมในรอบหนึ่งปีควรมองแบบนี้
| รายการต้นทุน | ดูแลเอง | Managed |
|---|---|---|
| ค่าประมวลผลและพื้นที่เก็บข้อมูล | เซิร์ฟเวอร์หลัก | รวมอยู่ในค่าบริการ |
| เครื่องสำรองสำหรับ failover | ค่าเครื่องเพิ่มขึ้นราวเท่าตัว | รวมอยู่แล้ว ขึ้นกับแพ็กเกจ |
| พื้นที่เก็บแบ็กอัปนอกเครื่อง | จ่ายเพิ่ม | มักรวมอยู่แล้ว |
| ระบบมอนิเตอร์ | ติดตั้งและดูแลเอง | มักรวมอยู่แล้ว |
| เวลาวิศวกร: ติดตั้ง อัปเกรด ซ้อมกู้คืน | มากและต่อเนื่อง | น้อยมาก |
| เวรเฝ้าระบบนอกเวลา | จำเป็นถ้าต้องการ HA จริง | ผู้ให้บริการรับผิดชอบ |
| ความเสียหายเมื่อเกิดเหตุ | เรารับเต็มๆ | ลดลง ตามเงื่อนไข SLA |
สำหรับทีมเล็ก เวลาของวิศวกรและความเสี่ยงเมื่อเกิดเหตุมักมีมูลค่ามากกว่าส่วนต่างค่าเซิร์ฟเวอร์
เมื่อไรที่ดูแลเองแล้วคุ้ม
การติดตั้งดูแลเองเป็นทางเลือกที่สมเหตุสมผล เมื่อ
- มี DBA หรือ SRE ที่มีประสบการณ์และมีเวรเฝ้าระบบอยู่แล้ว
- งานใหญ่และสม่ำเสมอมากพอที่ส่วนต่างค่าฮาร์ดแวร์จะคุ้มจริง
- มีข้อกำหนดเรื่องที่ตั้งข้อมูลหรือระบบปิด (air-gapped) ที่ผู้ให้บริการรายใดก็ตอบไม่ได้
- ต้องใช้ extension หรือการตั้งค่าที่ managed service ไม่อนุญาต
- เป็นระบบ dev ระบบทดสอบ หรือใช้ฝึกเรียนรู้ ที่ล่มได้โดยไม่กระทบธุรกิจ
แล้ว Redis ล่ะ?
Redis มักใช้เป็นแคช ที่เก็บ session ตัวจำกัดอัตราการเรียก (rate limiter) หรือคิวขนาดเล็ก ถ้าใช้เป็นแคชอย่างเดียวจะให้อภัยได้มาก เพราะสร้างข้อมูลใหม่ได้ แต่เมื่อเริ่มเก็บ session หรือ job ก็ต้องดูแลจริงจังไม่ต่างจากฐานข้อมูล ทั้งการเก็บข้อมูลลงดิสก์ (RDB และ/หรือ AOF) การทำ replication กับ Sentinel หรือ Redis Cluster เพื่อ failover การตั้ง maxmemory และนโยบายการลบข้อมูลที่เหมาะสม และห้ามเปิดออกอินเทอร์เน็ตเด็ดขาด เพราะ Redis ที่เปิดทิ้งไว้โดนโจมตีเป็นประจำ นอกจากนี้ Redis เปลี่ยนสัญญาอนุญาตในปี 2024 และเพิ่มตัวเลือก AGPLv3 ใน Redis 8 เมื่อปี 2025 ขณะที่ Valkey เกิดขึ้นเป็น fork แบบโอเพนซอร์ส การใช้ managed service ช่วยให้ไม่ต้องปวดหัวกับเรื่องเหล่านี้มากนัก
บริการ Managed Infrastructure ของ Vectorkub
บริการ managed infrastructure ของ Vectorkub ให้เช่า PostgreSQL, Redis, RabbitMQ, MongoDB, Elasticsearch และ MinIO แบบจ่ายตามการใช้งานจริง (pay-as-you-go) พร้อม SLA uptime 99.9% แบ็กอัปและมอนิเตอร์อัตโนมัติ failover ข้ามภูมิภาค และปรับขนาดขึ้นลงได้ทุกเมื่อ เป็นชุดเทคโนโลยีเดียวกับที่เราใช้กับระบบของเราเอง รวมถึงระบบแบบที่เล่าไว้ในคู่มือเชื่อมต่อ payment gateway
คำถามที่พบบ่อย (FAQ)
Managed PostgreSQL ช้ากว่าติดตั้งเองไหม?
ไม่จำเป็น ประสิทธิภาพขึ้นกับ CPU หน่วยความจำ ดิสก์ การตั้งค่า และระยะทางเครือข่ายระหว่างแอปกับฐานข้อมูล ควรวางทั้งสองไว้ในภูมิภาคหรือเครือข่ายเดียวกัน
ถ้าตอนนี้ดูแลเองอยู่ ย้ายไป managed ทีหลังได้ไหม?
ได้ ฐานข้อมูลขนาดเล็กย้ายด้วยการ dump แล้ว restore ในช่วง maintenance ได้เลย ส่วนฐานข้อมูลใหญ่ใช้ logical replication เพื่อให้ระบบหยุดเพียงไม่กี่นาที
ใช้ managed database แล้วยังต้องมี DBA ไหม?
ยังต้องมีคนรับผิดชอบการออกแบบ schema, index และประสิทธิภาพของ query แต่ไม่ต้องมีคนคอยดูแลแบ็กอัป แพตช์ และ failover อีกต่อไป
ธุรกิจขนาดเล็กควรตั้ง RPO และ RTO เท่าไร?
เป็นการตัดสินใจทางธุรกิจมากกว่าทางเทคนิค ให้ถามว่ายอมเสียข้อมูลและยอมให้ระบบหยุดได้นานแค่ไหนก่อนจะกระทบลูกค้าหรือรายได้ แล้วเลือกระบบที่ตอบโจทย์นั้น และทดสอบให้เห็นจริง
ก้าวต่อไป
ถ้าทีมของคุณเสียเวลาเฝ้าฐานข้อมูลมากกว่าพัฒนาฟีเจอร์ อาจถึงเวลาส่งต่องานนี้ให้คนที่ทำทุกวัน ติดต่อเรา เพื่อคุยเรื่องปริมาณงานของคุณ แล้วเราจะเสนอแผนและแนวทางย้ายระบบที่เหมาะสม
