- การ โฮสต์ Postgres ด้วยตัวเอง ไม่ได้ซับซ้อนหรือเสี่ยงอย่างที่คิด และ มีต้นทุนต่ำกว่าบริการแบบ managed พร้อมปรับแต่งประสิทธิภาพได้อิสระกว่า
- บริการ ฐานข้อมูลบนคลาวด์ส่วนใหญ่ทำงานบน Postgres โอเพนซอร์สที่ถูกปรับแต่งเพียงเล็กน้อย โดยความต่างที่แท้จริงอยู่ที่ระดับของระบบอัตโนมัติด้านการปฏิบัติการ
- จากกรณีใช้งานจริง Postgres ที่โฮสต์เองสามารถรองรับผู้ใช้หลายพันคนและคิวรีหลายสิบล้านรายการได้อย่างเสถียร พร้อมใช้เวลาบำรุงรักษาน้อยมาก
- เนื่องจาก ราคาของบริการแบบ managed อย่าง AWS RDS สูงขึ้น ตอนนี้จึงสามารถนำงบประมาณเท่าเดิมไปดูแลเซิร์ฟเวอร์สเปกสูงกว่ามากได้ด้วยตัวเอง
- สำหรับทีมขนาดกลางที่การจัดการอินฟราสตรักเจอร์ไม่ได้ซับซ้อนมาก การโฮสต์เองกลายเป็นทางเลือกที่ใช้งานได้จริงทั้งในด้านความคุ้มค่าและประสิทธิภาพ
การเปลี่ยนแปลงของเรื่องเล่าที่มีคลาวด์เป็นศูนย์กลาง
- ในอดีต บริษัทส่วนใหญ่ ดูแลฐานข้อมูลบนเซิร์ฟเวอร์ของตัวเองโดยตรง ซึ่งมีข้อดีคือ latency เครือข่ายต่ำและทำงานได้รวดเร็ว
- ช่วงทศวรรษ 1980~2000 มักมีกรณีที่แอปพลิเคชันเซิร์ฟเวอร์และฐานข้อมูลเซิร์ฟเวอร์อยู่บนเครื่องจริงชุดเดียวกัน
- การเปิดตัว Amazon RDS(2009) ถูกมองว่าเป็นข้อเสนอที่น่าสนใจ เพราะช่วยทำงานอย่างการสำรองข้อมูล แพตช์ และมอนิเตอร์ให้เป็นอัตโนมัติ
- ในช่วงแรก ค่าใช้จ่ายใกล้เคียงกับเซิร์ฟเวอร์เฉพาะทาง แต่ลดภาระการดูแลระบบได้
- หลังปี 2015 เมื่อการใช้คลาวด์เร่งตัวขึ้น ก็เกิดการรับรู้แพร่หลายว่า การจัดการอินฟราสตรักเจอร์ด้วยตัวเองเป็นเรื่องไม่มีประสิทธิภาพ
- โมเดลที่ AWS ดูแลอินฟราสตรักเจอร์แทน และนักพัฒนามุ่งกับตรรกะของแอปพลิเคชัน กลายเป็นมาตรฐาน
- แต่ในปี 2025 ราคา RDS สูงขึ้นอย่างมาก จนกลายเป็นสถานการณ์ที่สามารถเช่าเซิร์ฟเวอร์เฉพาะทางสเปกสูงกว่ามากได้ในงบเท่ากัน
- ตัวอย่าง: อินสแตนซ์
db.r6g.xlarge (4 vCPU, 32GB RAM) ราคา $328 ต่อเดือน ขณะที่งบเท่านี้สามารถเช่าเซิร์ฟเวอร์ 32 คอร์ · 256GB RAM ได้
องค์ประกอบจริงของบริการแบบ managed
- AWS RDS โดยพื้นฐานคือ Postgres มาตรฐานที่เพิ่มระบบมอนิเตอร์และระบบสำรองข้อมูลเฉพาะของ AWS เข้าไป
- มีทั้งการสำรองข้อมูลด้วย EBS snapshot, การจัดการคอนฟิกผ่าน Chef/Puppet/Ansible, connection pooling ด้วย PgBouncer, การมอนิเตอร์ด้วย CloudWatch และสคริปต์ failover อัตโนมัติ
- องค์ประกอบเหล่านี้ไม่ได้ซับซ้อนทางเทคนิคมากนัก โดยคุณค่าหลักอยู่ที่ ระบบอัตโนมัติด้านการปฏิบัติการและความสะดวกในการ deploy ตั้งแต่แรก
- เมื่อย้ายจาก RDS มาสู่การโฮสต์เองบนเซิร์ฟเวอร์สเปกเดียวกัน พบว่า ประสิทธิภาพเท่าเดิมหรือดีขึ้นด้วยซ้ำ
- สามารถปรับพารามิเตอร์ที่ RDS จำกัดไว้ได้เอง จึงทำ optimization ด้านประสิทธิภาพได้
ความซับซ้อนในการปฏิบัติการของการโฮสต์เอง
- การย้ายไปยัง เซิร์ฟเวอร์ DigitalOcean สเปก 16 vCPU / 32GB RAM / ดิสก์ 400GB ใช้เวลาประมาณ 4 ชั่วโมง และหลังจากนั้นก็ยืนยันได้ว่าทำงานเสถียร
- กลุ่มผลิตภัณฑ์ที่ต้องการ high availability จะต้องใช้เวลาดูแลประมาณเดือนละ 30 นาที ส่วนบริการที่ทราฟฟิกน้อยสามารถทำให้เป็นอัตโนมัติได้ทั้งหมด
- รอบการดูแลตามปกติ
- รายสัปดาห์ (10 นาที) : ตรวจสอบการสำรองข้อมูล ทบทวน slow query log และเช็กพื้นที่ดิสก์
- รายเดือน (30 นาที) : อัปเดตด้านความปลอดภัย ตรวจนโยบายการเก็บสำรองข้อมูล และวางแผนความจุ
- รายไตรมาส (2 ชั่วโมง) : ปรับปรุงแดชบอร์ดมอนิเตอร์ ปรับแต่งคอนฟิก และทดสอบการกู้คืน
- แม้ การรับมือเหตุขัดข้องจะเป็นความรับผิดชอบโดยตรง แต่ RDS เองก็เกิดปัญหาได้ และสุดท้ายก็ยังต้องให้นักพัฒนารับมืออยู่ดี
- เมื่อดูแลเองจะ กำหนดจังหวะการอัปเดตและช่วงความเสี่ยงได้ด้วยตนเอง ทำให้ควบคุมเสถียรภาพได้ง่าย
กรณีที่ไม่เหมาะกับการโฮสต์เอง
- เมื่อ นักพัฒนาระยะเริ่มต้น ต้องการสร้างต้นแบบอย่างรวดเร็ว บริการแบบ managed จะสะดวกกว่า
- องค์กรขนาดใหญ่ อาจคุ้มกว่าหากมีวิศวกรฐานข้อมูลเฉพาะทาง หรือมอบหมายให้คลาวด์ดูแลเพื่อลดต้นทุนบุคลากร
- อุตสาหกรรมที่มีข้อกำกับดูแล (PCI-DSS, HIPAA เป็นต้น) อาจจำเป็นต้องใช้แพลตฟอร์มแบบ managed ที่ได้รับการรับรอง
จุดสำคัญของการตั้งค่า
- การตั้งค่าหน่วยความจำ: ต้องปรับ
shared_buffers, effective_cache_size, work_mem, maintenance_work_mem ฯลฯ ให้เหมาะกับฮาร์ดแวร์
- ตัวอย่าง: ตั้ง
shared_buffers เป็น 25% ของ RAM และ effective_cache_size เป็น 75%
- การจัดการการเชื่อมต่อ: ใช้
pgbouncer สำหรับทำ connection pooling และทำงานได้อย่างมีประสิทธิภาพในสภาพแวดล้อม Python asyncio
- มีตัวอย่างค่าพื้นฐาน เช่น
max_connections = 200, log_connections = on
- การจูนสตอเรจ: ในสภาพแวดล้อม NVMe SSD ให้ปรับเป็น
random_page_cost = 1.1, effective_io_concurrency = 200 เป็นต้น
- ช่วยเพิ่มความเร็วในการอ่านแบบสุ่มและทำให้ตัววางแผนคิวรีทำงานได้เหมาะสมขึ้น
- การตั้งค่า WAL: ปรับค่าอย่าง
wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9 เพื่อสมดุลด้านความทนทานและประสิทธิภาพ
บทสรุป
- ไม่จำเป็นต้องดูแลทุกอย่างในอินฟราสตรักเจอร์ด้วยตัวเอง แต่ Postgres เป็นหนึ่งในพื้นที่ที่การโฮสต์เองสมเหตุสมผล
- หากกำลังจ่ายให้ RDS มากกว่า $200 ต่อเดือน ก็ คุ้มค่าที่จะลองย้ายฐานข้อมูลที่ไม่ใช่แกนหลักไปยังเซิร์ฟเวอร์ทดสอบ
- ในอนาคต อินฟราสตรักเจอร์อาจพัฒนาไปสู่ รูปแบบไฮบริดที่ผสมทั้งบริการแบบ managed และการโฮสต์เอง
- Postgres ถูกประเมินว่าเป็น ตัวเลือกการโฮสต์เองที่คุ้มค่ามากเมื่อเทียบกับต้นทุน
4 ความคิดเห็น
เพราะเขารับประกันสตอเรจระดับ 11 nines อยู่แล้ว การดูแลระบบเองมันยากเหมือนตอนใช้คลาวด์นี่แหละ ก็เลยต้องใช้คลาวด์ไง 555
ในความเป็นจริง การดูแลคลัสเตอร์แบบ 3 โหนดคงไม่ได้ง่ายขนาดนั้นหรอกครับ
ความคิดเห็นบน Hacker News
ฉันมองว่า self-hosting เป็นเรื่องของความรับผิดชอบ
ตอนนี้ฉันโฮสต์ผลิตภัณฑ์ SaaS บางตัวเอง ซึ่งถูกกว่า AWS มากและประสิทธิภาพก็ดีกว่ามาก
แต่สำหรับโปรเจ็กต์ของลูกค้า ฉันจะโน้มน้าวให้ยอมจ่ายค่า AWS เพราะสามารถโยนความรับผิดชอบเรื่องความพร้อมใช้งานของฮาร์ดแวร์ไปให้อีกฝ่ายได้
ถ้างบจำกัด ค่า RDS ถือว่าแพงมาก การรัน Galera cluster 3 โหนดบน Hetzner ด้วยเงินไม่กี่ดอลลาร์คุ้มกว่ามาก
แต่ บริการแบบ managed อย่าง Cloudflare หรือ SQS ก็ยังล่มได้เป็นครั้งคราว สุดท้ายแล้วไม่มีที่ไหนเสถียรสมบูรณ์แบบ
AWS Aurora Serverless
ฝั่ง Cloud SQL กลับมี โครงสร้างค่าใช้จ่ายที่ซับซ้อน กว่า และถ้าตั้งค่าการสำรองข้อมูลไว้ครั้งเดียวก็จบ
ฉันไม่เห็นด้วยกับความคิดที่ว่า self-hosting เป็นทางเลือกที่เหมาะกับคนส่วนใหญ่
ฉันกลับมองว่าการโฮสต์เองสมเหตุสมผลเฉพาะกรณีที่ งบตึงมาก หรือ องค์กรใหญ่พอจะมีวิศวกรเฉพาะทาง เท่านั้น
สำหรับธุรกิจขนาดเล็ก การฝากไว้กับคลาวด์เป็นทางเลือกที่ใช้งานได้จริงกว่า หลังเซ็ตอัปแล้วใช้เวลาดูแลเดือนละ 30~120 นาทีก็พอ
PaaS อย่าง Heroku หรือ Render ให้นักพัฒนาทั่วไปจัดการได้ แต่แพงกว่ามาก
สุดท้ายถ้ายังไม่มีระบบกู้คืนแอปอัตโนมัติ คุณก็ยังโดนปลุกตอนตี 3 เหมือนเดิม
ถ้าเป็นเครื่องมือภายใน แค่เพิ่ม Postgres เข้าไปใน Docker ก็ใช้เวลา 5 นาทีพอ
คำนิยามของ ‘managed database’ มันชวนสับสน
สำหรับฉัน ข้อกำหนดพื้นฐานคือ การสำรองข้อมูลอัตโนมัติ, การปรับดัชนีให้เหมาะสม, การ failover ข้ามหลายดาต้าเซ็นเตอร์, point-in-time recovery, การวิเคราะห์ slow query, การคาดการณ์สตอเรจ
ถ้ามีทั้งหมดนี้รวมอยู่ในค่าบริการรายเดือน การถกเถียงเรื่อง self-hosting ก็แทบไม่มีความหมาย
สุดท้ายต้องมีสองคน แล้วเพราะงานไม่ยุ่งก็อาจเริ่มทำการปรับปรุงที่ไม่จำเป็นจนเสียเวลาไป 6 เดือน
DB แบบ managed แพงเกินไปเมื่อเทียบกับ VPS
ฉันคาดว่าจะจ่ายเพิ่มเพื่อความสะดวกบ้าง แต่ของจริงกลับแพงกว่าหลายเท่า เลยไม่ใช้ยกเว้นโปรเจ็กต์ใหญ่
ส่วนที่พูดถึง high availability (HA) ในบทความยังไม่พอ แค่อธิบายการตั้งค่า WAL อย่างเดียวไม่พอ เพราะการทำ replication มีต้นทุนสูงมาก
ฉันไม่เข้าใจว่าทำไม Postgres ถึงถูกอวยเกินจริงบน HN
มันไม่มีวิธีง่าย ๆ ในการตั้ง HA cluster ที่ failover อัตโนมัติ แบบ MongoDB เลย เลยอยากรู้ว่าในระบบจริงเขาแก้กันอย่างไร
การอภิปรายที่เกี่ยวข้อง: PostgreSQL mailing list
ในความเป็นจริงการเชื่อมต่อทั้งหมดจะหลุด แคชจะถูกล้าง และตอนอัปเกรดก็ต้องยอมให้บริการหยุดเสมอ
มีแค่ Oracle RAC ที่เป็นข้อยกเว้น และ PostgreSQL ไม่ได้ถูกออกแบบมาแบบนั้น ส่วน YugabyteDB ก็พอเป็นทางเลือกได้
แอปส่วนใหญ่ยอมรับ downtime ระดับไม่กี่ชั่วโมงได้ มีแค่บริษัทใหญ่เท่านั้นที่รับภาระระบบอัตโนมัติซับซ้อนได้
ถ้าอยู่บน Kubernetes, CloudNativePG ก็เป็นตัวเลือกที่ดี
pg_auto_failover เรียบง่ายแต่ก็มีข้อจำกัด
ถ้าดู Autobase มันช่วยทำงานที่จำเป็นสำหรับ self-hosting ให้เป็นอัตโนมัติ
ตลอด 15 ปีที่ผ่านมา ฉันใช้ Postgres แบบ self-hosted มาตลอด และแทบไม่เคยเจอปัญหาเลย
เรื่องเดียวที่กังวลคือตอนต้องทำ การย้ายเวอร์ชัน PG ให้สอดคล้องกับการอัปเกรด ORM ซึ่งก็จัดการได้ด้วย การดูแลระบบอย่างรอบคอบ
ฉันเคยรัน Postgres แบบไม่ managed เองบน Fly.io แล้วทรมานมาก
โหนดตายบ่อยจนต้องกู้คืนด้วย repmgr แบบแมนนวล และสุดท้ายก็ต้องเขียนขั้นตอนไว้ในวิกิภายใน
จุดประสงค์ของคลัสเตอร์คือ high availability แต่ฉันไม่เข้าใจว่าทำไมมันถึงไม่จัดการ zombie primary ให้อัตโนมัติ
สุดท้ายฉันย้ายไปใช้ managed Postgres และการที่มีคนอื่นจัดการให้เวลาเกิดปัญหานั้นสบายมาก
ความเห็นจำนวนมากในเธรดนี้มองข้ามปัจจัยในโลกจริงอย่าง ขนาด, เวิร์กโหลด, บุคลากร, เวลา, ระยะของธุรกิจ, ความต้องการด้านการขยายตัว
self-hosting อาจเหมาะหรือไม่เหมาะก็ได้ แต่การถกเถียงมันถูกทำให้ง่ายเกินไป
สำหรับนักพัฒนา เรื่องที่น่าคิดคงเป็นเวลาต้องทำ self-hosting ของแบบนั้นแล้ว องค์ประกอบพวกนั้นจะถูกยอมรับหรือไม่ก็น่าจะสำคัญเหมือนกัน ต่อให้ค่าใช้จ่ายบนคลาวด์สูงกว่า แต่ถ้าการประหยัดต้นทุนด้วยการ self-hosting ไม่ได้รับการยอมรับ สุดท้ายก็ต้องใช้บริการคลาวด์แล้วไปชดเชยเอา และลดขอบเขตที่ต้องรับผิดชอบน่าจะสบายใจกว่า