คู่มือ Scaling บน DigitalOcean 2026 — Vertical vs Horizontal

A practical guide to scaling on DigitalOcean, comparing vertical Droplet resizing with horizontal scaling using Load Balancers, snapshots, and a sample production architecture.

เมื่อเว็บไซต์หรือแอปพลิเคชันเริ่มมีผู้ใช้งานมากขึ้น การขยายระบบ (Scaling) บน DigitalOcean ทำได้สองแนวทางหลัก คือ Vertical Scaling ที่เพิ่มทรัพยากรให้ Droplet เดิม และ Horizontal Scaling ที่กระจายโหลดไปหลาย Droplet ผ่าน Load Balancer บทความนี้อธิบายวิธีเลือกแนวทางที่เหมาะสม พร้อมคำสั่งจริงและตัวอย่างสถาปัตยกรรมที่นำไปใช้งานได้ทันที ข้อมูลราคาและสเปกทั้งหมดอ้างอิงจาก digitalocean.com/pricing ณ กรกฎาคม 2026

Vertical Scaling: Resize Droplet เพิ่ม RAM/CPU

Vertical Scaling คือการเพิ่มทรัพยากรให้ Droplet ตัวเดิม โดยไม่เปลี่ยนสถาปัตยกรรมของระบบ เหมาะกับแอปพลิเคชันที่ยังรันบนเซิร์ฟเวอร์เดียวและยังไม่ต้องกระจายโหลด DigitalOcean เปิดให้ resize Droplet ได้ทั้งผ่านหน้า Control Panel และคำสั่ง doctl โดยเลือกได้ว่าจะเพิ่มเฉพาะ RAM/CPU หรือเพิ่ม disk ไปพร้อมกัน ข้อควรรู้คือการขยาย disk เป็นการกระทำที่ย้อนกลับไม่ได้ (ลด disk กลับคืนไม่ได้) ดังนั้นควรตัดสินใจให้รอบคอบก่อน resize แบบเพิ่ม disk ทุกครั้ง

ตัวอย่าง Basic Droplet ของ DigitalOcean ไล่ระดับจาก 512 MiB RAM / 1 vCPU / 10GB SSD / 500GiB transfer ที่ $4/เดือน ไปจนถึง 16 GiB RAM / 8 vCPU / 320GB SSD / 6,000GiB transfer ที่ $96/เดือน สำหรับงานที่ต้องการ CPU แบบ dedicated (ไม่แชร์กับ Droplet อื่น) มีตัวเลือก Droplets General Purpose เริ่มต้นที่ $63/เดือน (8GB RAM, 2 vCPU, 25GB SSD) ไปจนถึง $1,260/เดือนสำหรับงานหนักระดับ production ที่ต้องการความเสถียรของ CPU ห้ามสับสนกับราคา Basic Droplet เพราะเป็นคนละกลุ่มสินค้ากัน

ขั้นตอน resize ผ่าน doctl เริ่มจาก power off Droplet ก่อนเสมอ: doctl compute droplet-action power-off <droplet-id> จากนั้น resize: doctl compute droplet-action resize <droplet-id> --size s-4vcpu-8gb --resize-disk และเปิดเครื่องกลับมาทำงาน: doctl compute droplet-action power-on <droplet-id>

ถ้าต้องการเพิ่มแค่ RAM/CPU โดยไม่แตะ disk ให้ตัดพารามิเตอร์ --resize-disk ออก ระบบจะยังอนุญาตให้ downgrade ขนาดกลับได้ในอนาคตเพราะ disk ไม่ถูกขยาย ระหว่างขั้นตอน resize ทั้งหมด Droplet จะหยุดให้บริการชั่วคราว (ปกติไม่กี่นาที) จึงควรแจ้ง maintenance window ล่วงหน้าหากเป็นระบบ production และควรสร้าง Droplet Snapshot ก่อน resize ทุกครั้งเพื่อเป็นจุดย้อนกลับหากมีปัญหาเกิดขึ้นระหว่างขั้นตอนนี้

Vertical Scaling means adding resources to a single Droplet without changing your system architecture—ideal for applications still running on a single server that don't yet need load distribution. DigitalOcean lets you resize Droplets both via the Control Panel and the doctl command, with the flexibility to increase only RAM/CPU or add disk space simultaneously. One important caveat: disk expansion is permanent. You cannot shrink disk afterward, so always decide carefully before resizing with disk expansion.

DigitalOcean's Basic Droplet lineup ranges from 512 MiB RAM / 1 vCPU / 10GB SSD / 500GiB transfer at $4/month up to 16 GiB RAM / 8 vCPU / 320GB SSD / 6,000GiB transfer at $96/month. For workloads requiring dedicated (non-shared) CPU, the Droplets General Purpose tier starts at $63/month (8GB RAM, 2 vCPU, 25GB SSD) and goes up to $1,260/month for heavy production loads needing CPU stability. Don't confuse these: they are separate product lines entirely.

The resize workflow via doctl starts by powering off the Droplet: doctl compute droplet-action power-off <droplet-id> Then resize: doctl compute droplet-action resize <droplet-id> --size s-4vcpu-8gb --resize-disk Finally, power it back on: doctl compute droplet-action power-on <droplet-id>

If you want to increase only RAM/CPU without touching disk, omit the --resize-disk flag. The system will still allow you to downsize later since the disk wasn't expanded. During the entire resize process, your Droplet stops serving traffic briefly (typically just a few minutes). Plan a maintenance window in advance for production systems, and always create a Droplet Snapshot before resizing as a rollback point in case anything goes wrong during the operation.

• Resize ผ่าน doctl หรือ Control Panel ได้ทั้งคู่ ผลลัพธ์เหมือนกัน
• เพิ่ม disk พร้อม resize เป็นการกระทำถาวร ย้อนกลับไม่ได้
• Basic Droplet ไล่ราคาตั้งแต่ $4/เดือน (512MiB) ถึง $96/เดือน (16GiB)
• งานที่ต้องการ CPU เสถียรใช้ Droplets General Purpose เริ่ม $63/เดือน

Horizontal Scaling: หลาย Droplet + Load Balancer

จุดที่ผู้ใช้มักถามมาคือ horizontal Scaling คือการเพิ่มจำนวน Droplet แทนการขยายเครื่องเดียว แล้วกระจาย traffic ผ่าน Load Balancer เหมาะกับระบบที่ต้องการความพร้อมใช้งานสูง (High Availability) และรองรับ traffic ที่ผันผวนได้ดีกว่า เพราะสามารถเพิ่มหรือลดจำนวน Droplet ตามโหลดจริงโดยไม่ต้องหยุดระบบทั้งหมด

DigitalOcean Load Balancer เริ่มต้นที่ $12/เดือน ทำงานร่วมกับ Droplet ผ่าน VPC เครือข่ายภายในที่ให้ใช้งานฟรีไม่จำกัดจำนวนต่อบัญชี วิธีที่แนะนำคือติด Tag ให้ Droplet ทุกตัวในกลุ่ม เช่น tag ชื่อ web-backend แล้วให้ Load Balancer forward traffic ไปยัง Droplet ที่มี tag นั้นโดยอัตโนมัติ เมื่อเพิ่ม Droplet ใหม่เข้ากลุ่มพร้อม tag เดียวกัน Load Balancer จะเริ่มส่ง traffic ให้ทันทีโดยไม่ต้องตั้งค่าใหม่ทีละตัว

ตัวอย่างสร้าง Load Balancer ด้วย doctl: doctl compute load-balancer create --name web-lb --region sgp1 --tag-name web-backend --forwarding-rules entry_protocol:https,entry_port:443,target_protocol:http,target_port:80

ตั้งค่า Health Check เพื่อให้ Load Balancer ตัด Droplet ที่ตอบสนองไม่ได้ออกจากวงจรอัตโนมัติ: doctl compute load-balancer update <lb-id> --health-check protocol:http,port:80,path:/healthz,check_interval_seconds:10,unhealthy_threshold:3

สำหรับผู้ใช้ในไทยควรเลือก region sgp1 (Singapore) เป็นหลักเพราะ latency ต่ำที่สุดจาก 15 datacenter ที่ DigitalOcean มีให้บริการ รองลงมาคือ blr1 (Bangalore) ระบบ Horizontal Scaling ยังช่วยลดความเสี่ยงจาก Droplet ตัวเดียวล่มแล้วทั้งระบบล่มตาม (single point of failure) ซึ่งเป็นข้อจำกัดสำคัญของ Vertical Scaling ที่ resize ได้แค่เครื่องเดียวเท่านั้น

• Load Balancer ของ DigitalOcean เริ่มต้น $12/เดือน ครบทั้ง 15 region
• ใช้ Tags ผูก Droplet เข้ากลุ่มแทนการเพิ่มทีละตัวใน config
• VPC เชื่อม Droplet กับ Load Balancer แบบ private network ฟรี
• Health Check ตัด Droplet ที่ตายออกจากวงจรอัตโนมัติ

เมื่อไหร่ควรใช้แบบไหน

การเลือกระหว่าง Vertical และ Horizontal Scaling ขึ้นอยู่กับลักษณะ traffic และงบประมาณ ไม่มีคำตอบตายตัวว่าแบบไหนดีกว่ากันเสมอไป แต่มีหลักคิดที่ใช้ได้จริงดังนี้

Vertical Scaling เหมาะกับระบบขนาดเล็กถึงกลางที่ยังรันบน Droplet เดียวได้สบาย เช่น เว็บไซต์บริษัท บล็อก หรือ API ที่ traffic ยังไม่สูงมาก ข้อดีคือทำง่าย ไม่ต้องแก้ code หรือสถาปัตยกรรม แค่ resize แล้วรอไม่กี่นาที ข้อเสียคือมีเพดานสูงสุดที่ $96/เดือนสำหรับ Basic Droplet หรือ $1,260/เดือนสำหรับ General Purpose และถ้า Droplet เดียวล่ม ทั้งระบบก็ล่มไปด้วย

Horizontal Scaling เหมาะกับระบบที่ต้องการ uptime สูง มี traffic ผันผวนตามช่วงเวลา เช่น flash sale หรือแคมเปญการตลาด หรือมีผู้ใช้งานจำนวนมากพร้อมกัน ข้อดีคือขยายได้แทบไม่จำกัดโดยเพิ่ม Droplet ทีละตัว และถ้า Droplet ตัวใดตัวหนึ่งล่ม ระบบยังทำงานต่อได้เพราะ Load Balancer จะส่ง traffic ไปยัง Droplet ที่เหลือ ข้อเสียคือค่าใช้จ่ายเริ่มต้นสูงกว่า ต้องมี Load Balancer $12/เดือน บวก Droplet อย่างน้อย 2 ตัว และระบบต้องออกแบบให้ stateless หรือแยก session/ไฟล์ออกจาก Droplet แต่ละตัว

แนวทางที่ทีมพัฒนาส่วนใหญ่ใช้จริงคือเริ่มจาก Vertical Scaling ก่อนในช่วงเริ่มต้นโปรเจกต์ เพราะง่ายและถูกกว่า แล้วค่อยย้ายไป Horizontal Scaling เมื่อ traffic เริ่มแตะเพดานของ Droplet ตัวเดียว หรือเมื่อธุรกิจเริ่มต้องการ uptime ระดับที่ทน downtime ไม่ได้อีกต่อไป

1. Vertical: ง่าย เร็ว เหมาะเว็บ/API ขนาดเล็ก-กลาง
2. Horizontal: ทน downtime ได้ดีกว่า เหมาะ traffic ผันผวน
3. Vertical มีเพดานสูงสุด $96/เดือน (Basic) หรือ $1,260/เดือน (General Purpose)

ใช้ Snapshot/Image ช่วย Scale เร็วขึ้น

เมื่อต้อง Scale แบบ Horizontal การสร้าง Droplet ใหม่ให้มีสภาพแวดล้อมเหมือนตัวเดิมทุกประการ (OS, package, config เดียวกัน) เป็นเรื่องที่ต้องทำซ้ำบ่อย วิธีที่เร็วและปลอดภัยที่สุดคือใช้ Droplet Snapshot เป็น golden image แทนการติดตั้งซ้ำทุกครั้งด้วยมือหรือสคริปต์ยาวๆ

ราคา snapshot ของ DigitalOcean อยู่ที่ $0.06/GiB ต่อเดือน คิดตามพื้นที่ที่ snapshot ใช้จริง เช่น snapshot จาก Droplet ที่มี disk ใช้งานจริง 20GiB จะเสียค่าใช้จ่ายประมาณ $1.20/เดือน snapshot ที่สร้างไว้สามารถนำไปสร้าง Droplet ใหม่ได้ทุก region โดยไม่มีค่าใช้จ่ายเพิ่มสำหรับการใช้งานข้าม region

ขั้นตอนที่แนะนำคือตั้งค่า Droplet ต้นแบบให้สมบูรณ์ก่อน (ติดตั้ง web server, dependencies, deploy code เวอร์ชันล่าสุด) แล้วสร้าง snapshot: doctl compute droplet-action snapshot <droplet-id> --snapshot-name web-golden-2026-07

จากนั้นเมื่อต้องการเพิ่ม Droplet ใหม่เข้ากลุ่ม Horizontal Scaling ให้สร้างจาก snapshot นั้นโดยตรงพร้อมติด tag ให้ตรงกับที่ Load Balancer ใช้: doctl compute droplet create web-03 --image <snapshot-id> --size s-2vcpu-4gb --region sgp1 --tag-names web-backend --ssh-keys <key-fingerprint>

วิธีนี้ลดเวลา provisioning จากหลักสิบนาที (ติดตั้งใหม่ทั้งหมด) เหลือแค่ไม่กี่นาที (boot จาก image ที่พร้อมใช้แล้ว) ทีมที่ scale บ่อยควรอัปเดต golden image เป็นระยะทุกครั้งที่มีการ deploy เวอร์ชันใหม่ที่เสถียร เพื่อให้ Droplet ใหม่ที่สร้างขึ้นมาเสมอมีโค้ดล่าสุดโดยไม่ต้อง deploy ซ้ำหลัง provisioning อีกครั้ง

• Snapshot ราคา $0.06/GiB/เดือน คิดตามพื้นที่ใช้จริง
• สร้าง Droplet ใหม่จาก snapshot ได้ทุก region ไม่มีค่าใช้จ่ายเพิ่ม
• golden image ลดเวลา provisioning จากสิบนาทีเหลือไม่กี่นาที
• ควรอัปเดต snapshot ทุกครั้งที่ deploy โค้ดเวอร์ชันเสถียรใหม่
• ติด tag ให้ Droplet ใหม่ตรงกับ Load Balancer เสมอ

ตัวอย่างสถาปัตยกรรมรองรับ Traffic เพิ่ม

ตัวอย่างสถาปัตยกรรมที่ใช้งานจริงสำหรับเว็บแอปพลิเคชันที่ต้องรองรับ traffic เพิ่มขึ้นเรื่อยๆ ประกอบด้วยส่วนหลัก 4 ส่วน คือ Load Balancer ด้านหน้า กลุ่ม Droplet สำหรับ application server Managed Database แยกออกจาก Droplet และ VPC เป็นเครือข่ายภายในเชื่อมทุกส่วนเข้าด้วยกัน

โครงสร้างเริ่มต้นที่แนะนำคือ Load Balancer ($12/เดือน) รับ traffic จากอินเทอร์เน็ตแล้วกระจายไปยัง Droplet อย่างน้อย 2 ตัว เช่นขนาด 4GiB/2vCPU ตัวละ $24/เดือน ที่อยู่ใน VPC เดียวกัน (ฟรี) เพื่อความปลอดภัยควรแยก Managed Database ออกมาต่างหาก เช่น PostgreSQL Basic tier ที่ $15.15/เดือน แทนการติดตั้ง database บน Droplet เดียวกับ application เพราะทำให้ scale application server ได้อิสระโดยไม่กระทบข้อมูล และ Managed Database มี backup อัตโนมัติในตัวอยู่แล้ว

สำหรับไฟล์ที่ต้องใช้ร่วมกันระหว่าง Droplet หลายตัว เช่นไฟล์รูปที่ผู้ใช้อัปโหลด ไม่ควรเก็บบน disk ของ Droplet ใดตัวหนึ่งเพราะ Droplet อื่นจะมองไม่เห็น ทางเลือกคือใช้ DigitalOcean Spaces (Object Storage เริ่ม $5/เดือน มี CDN ในตัว) เก็บไฟล์กลาง แทนการพึ่ง local disk ของแต่ละ Droplet

ตัวอย่าง Cloud Firewall (ฟรี) ที่ควรตั้งสำหรับสถาปัตยกรรมนี้คือเปิดเฉพาะ port 80/443 รับจาก Load Balancer เปิด port database เฉพาะจาก VPC internal IP range ของ Droplet กลุ่มเดียวกัน และปิด SSH ไม่ให้เปิดสู่อินเทอร์เน็ตทั่วไป จำกัดเฉพาะ IP ของทีมพัฒนาเท่านั้น ด้วยโครงสร้างนี้เมื่อ traffic เพิ่มขึ้นสามารถเพิ่ม Droplet ใหม่จาก golden image เข้ากลุ่มได้ทันทีโดยไม่กระทบส่วน database หรือ storage เลย

• Load Balancer + Droplet หลายตัว + Managed Database แยกกันคนละส่วน
• แยก Database ออกจาก Droplet application เพื่อ scale อิสระ
• ไฟล์ที่ใช้ร่วมกันเก็บใน Spaces แทน local disk ของ Droplet

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

ในทางปฏิบัติทีมพัฒนาส่วนใหญ่ไม่ได้เลือกใช้ Vertical หรือ Horizontal Scaling อย่างใดอย่างหนึ่งตลอดไป แต่ใช้ผสมกันตามช่วงเวลาของธุรกิจ ตัวอย่าง use case ที่พบบ่อยมีดังนี้

เว็บอีคอมเมิร์ซที่มีแคมเปญลดราคาตามฤดูกาล เช่น 11.11 หรือ 12.12 มักเลือก Horizontal Scaling ล่วงหน้าก่อนแคมเปญ 1-2 สัปดาห์ โดยเพิ่มจำนวน Droplet จาก golden image เข้ากลุ่ม Load Balancer แล้วลดจำนวนกลับหลังแคมเปญจบ วิธีนี้ควบคุมค่าใช้จ่ายได้ดีกว่าการคง Droplet จำนวนมากไว้ตลอดทั้งปีโดยไม่จำเป็น

สตาร์ทอัพหรือ SaaS ที่เพิ่ง launch มักเริ่มจาก Vertical Scaling บน Droplet เดียว เช่น เริ่มที่ 2GiB/1vCPU ($12/เดือน) แล้ว resize ขึ้นเป็น 4GiB/2vCPU ($24/เดือน) เมื่อผู้ใช้เพิ่มขึ้น จนกว่าจะถึงจุดที่ traffic เริ่มไม่แน่นอนหรือธุรกิจต้องการ SLA ที่รับ downtime ไม่ได้ จึงค่อยย้ายไปสถาปัตยกรรม Horizontal เต็มรูปแบบ

เว็บไซต์ข่าวหรือสื่อที่มีความเสี่ยงเนื้อหาไวรัล traffic พุ่งกะทันหันเมื่อบทความถูกแชร์ต่อ เหมาะกับ Horizontal Scaling ตั้งแต่ต้น เพราะคาดเดา traffic ล่วงหน้าไม่ได้ และการ resize Droplet เดียวแบบ Vertical ต้องใช้เวลาไม่กี่นาทีซึ่งอาจช้าเกินไปสำหรับ traffic ที่พุ่งขึ้นภายในไม่กี่นาทีเช่นกัน ในกรณีนี้ควรตั้ง Droplet สำรองไว้ล่วงหน้าและใช้ Monitoring Alert (ฟรี) แจ้งเตือนเมื่อ CPU/RAM ใกล้เต็ม เพื่อเพิ่ม Droplet ทันเวลาก่อนเว็บล่ม

• แคมเปญลดราคาตามฤดูกาล: เพิ่ม Droplet ก่อนงาน ลดหลังงานจบ
• สตาร์ทอัพเริ่มจาก Vertical แล้วย้าย Horizontal เมื่อโตขึ้น
• เว็บข่าว/สื่อที่ traffic พุ่งกะทันหันควรใช้ Horizontal ตั้งแต่ต้น
• ใช้ Monitoring Alert ฟรีแจ้งเตือนก่อน CPU/RAM เต็ม

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

จุดที่ผู้ใช้มักถามมาคือ ข้อผิดพลาดที่พบบ่อยที่สุดในการทำ Vertical Scaling คือ resize แบบเพิ่ม disk โดยไม่สร้าง Snapshot สำรองก่อน เพราะการขยาย disk เป็นการกระทำที่ย้อนกลับไม่ได้ หากมีปัญหาระหว่าง resize เช่น boot ไม่ขึ้นหลัง resize จะไม่มีจุดย้อนกลับให้ใช้ ควรสร้าง snapshot ก่อน resize ทุกครั้งแม้จะมั่นใจว่าไม่มีปัญหาก็ตาม

ข้อผิดพลาดอีกอย่างคือการ resize ในช่วงเวลาที่มี traffic สูง เพราะ Droplet ต้อง power off ระหว่างขั้นตอน resize ทำให้เว็บไซต์ล่มชั่วคราว ควรเลือก maintenance window ที่ traffic ต่ำที่สุดและแจ้งผู้ใช้งานล่วงหน้าถ้าเป็นระบบ production

สำหรับ Horizontal Scaling ข้อผิดพลาดที่พบบ่อยคือลืมตั้งค่า Health Check บน Load Balancer หรือตั้ง path ที่ไม่ตรงกับ endpoint จริงของแอป ทำให้ Load Balancer มองว่า Droplet ทุกตัว unhealthy และหยุดส่ง traffic ไปทั้งหมดทั้งที่ Droplet ทำงานปกติ ควรทดสอบ health check path ด้วย curl จากเครื่อง local ก่อนผูกเข้ากับ Load Balancer จริงเสมอ

อีกข้อผิดพลาดที่พบบ่อยคือเก็บ session หรือไฟล์ upload ไว้บน local disk ของ Droplet แต่ละตัวโดยไม่รู้ตัว เมื่อผู้ใช้ login ที่ Droplet ตัวหนึ่งแล้ว Load Balancer ส่ง request ถัดไปไปยัง Droplet อีกตัว จะพบว่า session หายหรือหาไฟล์ไม่เจอ วิธีแก้คือย้าย session ไปเก็บที่ Managed Database หรือ Valkey (ชื่อใหม่ของ Managed Redis) และย้ายไฟล์ upload ไปเก็บที่ Spaces แทน local disk ทั้งหมด

สุดท้ายคือการลืมตั้ง Cloud Firewall ให้เปิด port เฉพาะจาก VPC internal range เมื่อเพิ่ม Droplet ใหม่เข้ากลุ่ม ทำให้ Droplet ใหม่เชื่อมต่อ database หรือ Droplet ตัวอื่นในกลุ่มไม่ได้ ควรตรวจสอบว่า Droplet ใหม่ทุกตัวอยู่ใน VPC และ Firewall rule เดียวกันกับ Droplet เดิมก่อนปล่อยให้รับ traffic จริง

• resize แบบเพิ่ม disk โดยไม่ backup ก่อน = ย้อนกลับไม่ได้ถ้าพัง
• resize ช่วง traffic สูง = เว็บล่มชั่วคราวโดยไม่จำเป็น
• Health Check path ผิด = Load Balancer ตัด Droplet ทุกตัวออกหมด
• เก็บ session/ไฟล์บน local disk = ข้อมูลหายเมื่อสลับ Droplet

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

สรุปแนวทางปฏิบัติที่ควรทำเมื่อวางแผน Scaling บน DigitalOcean ทั้งแบบ Vertical และ Horizontal

เริ่มจากเปิด Monitoring (ฟรี) และตั้ง Alert Policy ก่อนที่จะ scale จริง เพื่อให้เห็นข้อมูล CPU/RAM/Disk/Bandwidth ย้อนหลังประกอบการตัดสินใจว่าควร resize เท่าไหร่หรือเมื่อไหร่ควรเริ่มเพิ่ม Droplet แทนการเดาสุ่ม การเลือกขนาด Droplet ให้พอดีกับโหลดจริง (right-sizing) ช่วยประหยัดค่าใช้จ่ายได้มากกว่าการจ่ายเผื่อไว้ล่วงหน้าเกินความจำเป็น

ก่อน resize แบบ Vertical ทุกครั้งให้สร้าง Snapshot สำรอง และเลือกช่วงเวลาที่ traffic ต่ำที่สุด สำหรับระบบที่วางแผนจะ Scale แบบ Horizontal ในอนาคต ควรออกแบบแอปพลิเคชันให้ stateless ตั้งแต่ต้น คือแยก session และไฟล์ออกจาก local disk แม้ตอนนี้จะยังรันบน Droplet เดียวก็ตาม เพื่อให้ย้ายไปสถาปัตยกรรมหลาย Droplet ได้ในอนาคตโดยไม่ต้อง refactor ทั้งระบบใหม่ทั้งหมด

ใช้ Managed Database แทนการติดตั้งเองบน Droplet ทันทีที่งบประมาณอนุญาต เริ่มต้นที่ $15.15/เดือนสำหรับ PostgreSQL หรือ MySQL เพราะแยกการ scale database ออกจาก application server ได้อิสระ และมี backup อัตโนมัติในตัว ลดความเสี่ยงจากการลืม backup เอง

สำหรับทีมที่ scale บ่อย ควรเก็บขั้นตอนสร้าง Droplet เป็นสคริปต์หรือ Terraform config แทนการคลิกทำมือทุกครั้งผ่าน Control Panel เพื่อให้ Droplet ใหม่ทุกตัวมีการตั้งค่า Firewall, VPC, Tag ตรงกันเสมอ ลดความผิดพลาดจากมนุษย์เมื่อต้อง scale เร่งด่วนช่วงที่ traffic พุ่งจริง และควรทดสอบ failover จริงโดยปิด Droplet ตัวหนึ่งดูว่า Load Balancer ส่ง traffic ไปตัวที่เหลือได้จริงหรือไม่ อย่างน้อยไตรมาสละครั้งก่อนเกิดปัญหาจริง

• เปิด Monitoring + Alert ก่อน scale เพื่อตัดสินใจจากข้อมูลจริง
• Snapshot ก่อน resize ทุกครั้ง เลือกช่วง traffic ต่ำ
• ออกแบบแอปให้ stateless ตั้งแต่ต้นแม้ยังรัน Droplet เดียว
• ใช้ Managed Database แยกจาก application server

รับ $200 Free Credit →