การโฮสต์ Database หลายอินสแตนซ์บนเซิร์ฟเวอร์เครื่องเดียว

คำสัญญาของการโฮสต์ database ด้วยตนเอง

Database ที่จัดการบน Cloud นั้นสะดวก — จนกว่าใบแจ้งหนี้จะมาถึง สำหรับทีมที่รันโปรเจคหลายโปรเจค แต่ละโปรเจคต้องการอินสแตนซ์ Postgres ของตัวเอง การคำนวณต้นทุนจะเปลี่ยนไปอย่างมากเมื่อผ่านสามหรือสี่ database

แต่ในความเป็นจริง การยัด database อินสแตนซ์หลายตัวลงในเครื่องเดียวไม่ใช่แค่การรัน container เพิ่มขึ้นเท่านั้น การแย่งหน่วยความจำ ความขัดแย้งของ disk I/O และการจัดการ backup ทั้งหมดกลายเป็นปัญหาสำคัญที่บริการแบบ managed จัดการให้คุณอย่างเงียบ ๆ

การตั้งค่าของเรา: หลาย Supabase stack บนเซิร์ฟเวอร์เครื่องเดียว

เรารัน Supabase stack หลายตัว — แต่ละตัวประกอบด้วย Postgres, GoTrue, PostgREST, Realtime และ Storage — บนเซิร์ฟเวอร์ dedicated เครื่องเดียว เซิร์ฟเวอร์เป็นเครื่อง 16 vCPU, 32 GB ในดาต้าเซ็นเตอร์ยุโรป ซึ่งจัดการทั้งหมดผ่าน Docker Compose

แต่ละ stack มี compose file ของตัวเอง, network namespace ของตัวเอง และ data volume ของตัวเอง การตัดสินใจทางสถาปัตยกรรมหลัก: ไม่มี Postgres cluster ที่ใช้ร่วมกัน แต่ละโปรเจคได้รับอินสแตนซ์ database ที่แยกจากกันอย่างสมบูรณ์ ค่าใช้จ่ายในการรัน Postgres process หลายตัวนั้นมีจริง — ประมาณ 200-400 MB ต่ออินสแตนซ์ที่ไม่ได้ใช้งาน — แต่ความเรียบง่ายในการปฏิบัติงานของการแยกแบบสมบูรณ์นั้นคุ้มค่ากว่าต้นทุนทรัพยากร

ข้อจำกัดทรัพยากรที่สำคัญจริง ๆ

services:
  db:
    image: supabase/postgres:15.6
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '2.0'
        reservations:
          memory: 512M
          cpus: '0.5'

ข้อจำกัดทรัพยากรของ Docker คือแนวป้องกันแรก หากไม่มีสิ่งเหล่านี้ query ที่หนักเกินไปเพียงตัวเดียวสามารถทำให้ database อื่น ๆ ทุกตัวบนเครื่องขาดแคลนทรัพยากรได้ การ reservation ช่วยให้มั่นใจว่าแต่ละอินสแตนซ์มี allocation ขั้นต่ำเสมอ แม้ในช่วงที่มีการแย่งชิงทรัพยากร

การจัดการ backup ข้ามอินสแตนซ์

ปัญหาของ database หลายตัวไม่ใช่การ backup — pg_dump จัดการได้อย่างน่าเชื่อถือ ปัญหาคือการจัดการ backup เพื่อไม่ให้รันพร้อมกันทั้งหมดและทำให้ disk I/O อิ่มตัว

เราจัดตาราง backup โดยใช้ตาราง cron ที่เรียบง่ายพร้อม offset อินสแตนซ์ A backup เวลา 02:00, อินสแตนซ์ B เวลา 02:15, อินสแตนซ์ C เวลา 02:30 การ backup แต่ละตัวผ่าน gzip และอัปโหลดไปยัง object storage หน้าต่างการ backup ทั้งหมดสำหรับทุกอินสแตนซ์: ไม่เกิน 45 นาที

การตรวจสอบโดยไม่มี monitoring stack

กับดักทั่วไป: การ deploy Prometheus, Grafana และ AlertManager เพื่อตรวจสอบเซิร์ฟเวอร์ — ซึ่งทำให้ใช้ทรัพยากรที่คุณพยายามจะปกป้อง สำหรับขนาดของเรา วิธีการที่เบากว่าทำงานได้ดีกว่า

shell script รันทุกห้านาทีผ่าน cron, ตรวจสอบแต่ละอินสแตนซ์ Postgres ด้วย pg_isready, วัดการใช้ disk ต่อ volume และส่งสรุปไปยัง notification endpoint หากมีการละเมิด threshold ใด ๆ ต้นทุนทรัพยากรทั้งหมด: ไม่มีนัยสำคัญ

เมื่อใดควรหยุดโฮสต์เอง

การโฮสต์ database หลายตัวด้วยตนเองเหมาะสมเมื่อทีมเข้าใจการปฏิบัติงาน Postgres, workload คาดเดาได้ และการประหยัดต้นทุนคุ้มค่ากับค่าใช้จ่ายในการปฏิบัติงาน ทันทีที่เงื่อนไขใด ๆ เปลี่ยนไป — ความต้องการ scaling ที่รวดเร็ว, ข้อบังคับการปฏิบัติตามกฎระเบียบสำหรับบริการแบบ managed, หรือการเปลี่ยนแปลงทีม — การคำนวณจะเปลี่ยนกลับไปสู่บริการแบบ managed

การตัดสินใจด้านโครงสร้างพื้นฐานที่ดีที่สุดสามารถย้อนกลับได้ Docker volume สามารถส่งออกได้, ไฟล์ pg_dump สามารถ restore ได้ทุกที่ และ application layer ไม่ควรสนใจว่า database ของมันอยู่ที่ไหน ความพกพาสะดวกนั้นคือคุณค่าที่แท้จริงของวิธีการ containerized — ไม่ใช่การประหยัดต้นทุน