ใช้เซิร์ฟเวอร์ขนาดใหญ่เพียงเครื่องเดียว (2022)

 (specbranch.com)
34 คะแนน โดย GN⁺ 2025-09-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แก่นของข้อถกเถียงไม่ใช่ monolithic vs microservices แต่คือการตัดสินว่า distributed system คุ้มค่ากับโอเวอร์เฮดด้านการพัฒนา/ปฏิบัติการหรือไม่
  • เซิร์ฟเวอร์เดี่ยวสมัยใหม่มี หลายสิบถึงหลายร้อยคอร์, หน่วยความจำระดับ TB, I/O ระดับหลายสิบถึงหลายร้อย Gbps ซึ่งมี เผื่อประสิทธิภาพเพียงพอ สำหรับรองรับบริการเว็บส่วนใหญ่
  • เบนช์มาร์กจริงแสดงให้เห็นว่าเซิร์ฟเวอร์เพียงเครื่องเดียวสามารถรองรับ Nginx 500,000 RPS, PostgreSQL 70,000 IOPS, NoSQL 1,000,000 IOPS, การเข้ารหัส 4K 75 FPS และงานประสิทธิภาพสูงอื่น ๆ ได้
  • การใช้คลาวด์ช่วยเพิ่ม ความสะดวกและความพร้อมใช้งาน แต่มีค่าใช้จ่ายพรีเมียมค่อนข้างสูง จึงต้องพิจารณาความคุ้มค่าของการลงทุน
  • เฉพาะกรณีที่รูปแบบการใช้งาน ผันผวนรุนแรงมาก เท่านั้นที่สถาปัตยกรรม cloud-native และ serverless จะได้เปรียบด้านต้นทุน
  • แต่ ค่าใช้จ่ายพรีเมียมของ serverless/ไมโคร VM นั้นสูง และหากเวิร์กโหลด ต่อเนื่อง/คาดการณ์ได้ การ ขยายแนวตั้ง จะคุ้มค่ากว่า
  • เรื่องความพร้อมใช้งานสามารถแก้ได้เป็นส่วนใหญ่ด้วย ระบบสำรองแบบหลัก/รอง (หรือ 2×2) และการผสมฮาร์ดแวร์ต่างชนิดกัน โดยใช้กลยุทธ์ กระจายเฉพาะ CDN และแบ็กอัป ถือว่าสมเหตุสมผล

ภาพรวม: คุณค่าของ “เซิร์ฟเวอร์ใหญ่หนึ่งเครื่อง” เมื่อเทียบกับ distributed system

  • แก่นของข้อถกเถียง “monolithic vs. microservices” คือการตัดสินว่าการนำ distributed system มาใช้นั้นคุ้มกับ เวลาและต้นทุนของนักพัฒนา ที่ต้องจ่ายจริงหรือไม่
  • ซอฟต์แวร์สมัยใหม่ทำงานอยู่บน virtualization ของเซิร์ฟเวอร์และเลเยอร์ abstraction หลายชั้น แม้แต่ “serverless” หรือ “bare metal” ก็ล้วนสร้างอยู่บนทรัพยากรของเซิร์ฟเวอร์จริง
  • เซิร์ฟเวอร์ในปัจจุบันมี ความคุ้มค่าด้านประสิทธิภาพต่อต้นทุน สูงกว่าที่เราคิด
    • เมื่อเทียบกับอดีต สเปกเซิร์ฟเวอร์พัฒนาแบบก้าวกระโดดทั้งในด้าน จำนวนคอร์·แบนด์วิดท์หน่วยความจำ·PCIe lane·NVMe storage และบริการจำนวนมากสามารถทำ QPS ตามเป้าหมายได้โดยไม่ต้องกระจายระบบ

ประสิทธิภาพอันทรงพลังของฮาร์ดแวร์เซิร์ฟเวอร์

  • เซิร์ฟเวอร์ตัวอย่างของ Microsoft Azure ใช้ AMD CPU สำหรับเซิร์ฟเวอร์รุ่นที่ 3 จำนวน 2 ตัว รวมเป็น 128 คอร์ 256 เธรด
  • เซิร์ฟเวอร์เดี่ยวสามารถให้สมรรถนะการประมวลผลระดับ 4 TFLOPs ซึ่งเหนือกว่าซูเปอร์คอมพิวเตอร์ในช่วงต้นทศวรรษ 2000
  • ด้วยการติดตั้ง RAM DDR4-3200 แบบ 16 สล็อตต่อซ็อกเก็ต จึงขยายหน่วยความจำได้สูงสุด 8TB และยังมีตัวเลือกซื้อใช้งานจริงที่รองรับ 1TB
  • มี PCIe Gen4 รวม 128 lane พร้อม SSD แบบ NVMe 30 ตัว และ การ์ดเครือข่าย 50~100Gbps สำหรับงานสตอเรจและเครือข่ายสมรรถนะสูง

สิ่งที่เซิร์ฟเวอร์เดี่ยวแบบนี้ทำได้ (อ้างอิงเบนช์มาร์ก)

  • สามารถทำได้ถึง การส่งวิดีโอ 400–800 Gbps, NoSQL 1,000,000 IOPS, PostgreSQL 70,000 IOPS, Nginx 500,000 RPS
  • ยังให้ throughput สูงในงานที่กิน CPU·หน่วยความจำ·I/O อย่าง คอมไพล์ Linux kernel 20 วินาที และ เข้ารหัส x264 4K ที่ 75FPS
โฆษณา

เปรียบเทียบค่าเช่าและค่าซื้อเซิร์ฟเวอร์

  • OVHCloud: เซิร์ฟเวอร์ 128 คอร์/512GB RAM เช่าได้ราว $1,318 ต่อเดือน
  • Hetzner: ให้บริการเซิร์ฟเวอร์ 32 คอร์/128GB RAM ที่ €140 ต่อเดือน และราคาจะต่างกันตามขนาด
  • AWS m6a.metal: เซิร์ฟเวอร์ 96 physical cores/768GB RAM ราคา $8.29 ต่อชั่วโมง หรือประมาณ $6,055 ต่อเดือน ซึ่งมี cloud premium สูง
  • หากซื้อเซิร์ฟเวอร์สเปกใกล้เคียงกันจาก Dell โดยตรงจะอยู่ที่ประมาณ $40,000 และอาจคืนทุนเมื่อเทียบกับคลาวด์ได้ภายในราว 8 เดือน
  • หากสมมติ throughput เท่ากัน การใช้ serverless จะมีต้นทุนพรีเมียมประมาณ 5.5 เท่าเมื่อเทียบกับ instance และ 25 เท่าเมื่อเทียบกับโฮสติ้งราคาประหยัด

ทำไม distributed system จึงเคยได้รับความนิยม

  • ในอดีต (ราวปี 2010) ข้อจำกัดด้านประสิทธิภาพของ CPU·หน่วยความจำ·อุปกรณ์จัดเก็บข้อมูล ทำให้บริการขนาดใหญ่ต้องอาศัย การรวมหลายเซิร์ฟเวอร์เข้าด้วยกัน
  • แต่ปัจจุบัน เซิร์ฟเวอร์เดี่ยวขนาดใหญ่·NVMe SSD·แบนด์วิดท์หน่วยความจำสูง ทำให้ ขีดจำกัดของการประมวลผลแบบ single node ดีขึ้นอย่างมาก ขณะที่หน่วย VM และคอนเทนเนอร์ยังคงถูกออกแบบโดยอิงทรัพยากรเซิร์ฟเวอร์ขนาดเล็ก

กรณีที่เซิร์ฟเวอร์ใหญ่เพียงเครื่องเดียวก็เพียงพอ

  • บริการเว็บส่วนใหญ่ที่ต่ำกว่า 10k QPS ใช้เครื่องเดียวก็เพียงพอ และบริการที่เรียบง่ายอาจไปได้ถึงระดับ ล้าน QPS
  • แม้แต่การสตรีมวิดีโอ control plane ก็ยังใช้เซิร์ฟเวอร์เดี่ยวได้จริง และยังสามารถคำนวณขนาดเซิร์ฟเวอร์ที่เหมาะสมได้จากตารางประสิทธิภาพมาตรฐานและเบนช์มาร์ก
  • นอกเหนือจากสถานการณ์พิเศษ การมีเพียงเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์สำรองก็เพียงพอสำหรับรับประกัน ความพร้อมใช้งาน

“สูงขึ้น” แทนที่จะ “กว้างออก”: เลือกเซิร์ฟเวอร์ใหญ่ไม่กี่เครื่องแทนกลุ่มเซิร์ฟเวอร์จำนวนมาก

  • แม้จำเป็นต้องมีคลัสเตอร์ การใช้ เซิร์ฟเวอร์ใหญ่ไม่กี่เครื่อง ก็มี โอเวอร์เฮดในการประสานงาน (O(n)) ต่ำกว่า เซิร์ฟเวอร์เล็กจำนวนมาก
    • กล่าวคือ ในระยะยาว การลดจำนวนเซิร์ฟเวอร์และเพิ่มสเปกมักมีประสิทธิภาพกว่า
  • ในรูปแบบ serverless หรือระบบที่อิงคอนเทนเนอร์อายุสั้น สัดส่วนโอเวอร์เฮดจะยิ่งสูงเป็นพิเศษ
  • ข้อเสียคือมี single point of failure แต่สามารถบรรเทาได้มากด้วย ระบบหลัก/รอง (คนละ DC)
  • หากต้องการให้แข็งแกร่งขึ้นอีก สามารถใช้ โครงแบบ 2×2 (DC หลัก 2 เครื่อง + DC สำรอง 2 เครื่อง) และ ฮาร์ดแวร์/ผู้ผลิตต่างกัน เพื่อหลีกเลี่ยง ความเสียหายที่เกิดร่วมกัน
  • ในกรณีเช่าเซิร์ฟเวอร์ การ กระจายรุ่นของเซิร์ฟเวอร์ ยังช่วยลดความเสี่ยงของ ความล้มเหลวต่อเนื่อง จากดิสก์หรือ SSD ล็อตเดียวกันได้
โฆษณา

ข้อดีและข้อจำกัดของการใช้คลาวด์

  • คลาวด์มีจุดแข็งด้าน ความพร้อมใช้งาน·ความเร็วในการกู้คืน·ความสะดวกในการปฏิบัติการ ซึ่งก็มีคุณค่าพอที่จะจ่าย ต้นทุนพรีเมียม
    • สามารถสตาร์ตกลับขึ้นมาใหม่ได้อย่างรวดเร็วภายใต้งบประมาณโดยไม่ต้องล่มยาว และใช้ประโยชน์จากพูลทรัพยากรขนาดใหญ่ที่บริหารแบบกริดได้
    • ผู้ให้บริการเซิร์ฟเวอร์เช่าอาจมีราคาถูกกว่า แต่ก็มีข้อจำกัดในด้านคุณภาพ·เครือข่าย·การสนับสนุนระดับพรีเมียม
  • อย่างไรก็ตาม การขายคลาวด์มักผลักดัน สถาปัตยกรรมที่ผูกกับผู้ขาย เช่น VM auto-scale, serverless, managed HA DB จึงควรระวังทั้ง ต้นทุนและความซับซ้อน
  • การรองรับทราฟฟิกขนาดใหญ่โดยตัวมันเอง ไม่ใช่เหตุผลหลักของ cloud-native และมีกรณีจำนวนมากที่ เซิร์ฟเวอร์เดี่ยวขนาดใหญ่ ก็รองรับ ผู้ใช้พร้อมกันระดับหลายล้าน ได้

ต้นทุนช่วงพีกและเกณฑ์ของเวิร์กโหลดแบบ bursty

  • ต้องมีใครสักคนเตรียม capacity ให้พร้อมรับช่วงพีก ดังนั้น ต้นทุนของพีก จะถูกคิดที่ใดที่หนึ่งในห่วงโซ่อุปทานอยู่ดี
  • งานแบบ bursty หรือชั่วคราว (เช่น การจำลองขนาดใหญ่แบบครั้งเดียว) เหมาะกับ serverless/auto-scale ในเชิงเศรษฐศาสตร์ แต่ โหลดที่ต่อเนื่องและคาดการณ์ได้ จะคุ้มค่ากว่าหาก รันบนเซิร์ฟเวอร์ใหญ่แบบคงที่
  • หากใช้ สัญญา 1 ปี / spot / การเจรจากับฝ่ายขาย ต้นทุนของ instance จะยิ่งลดลง และ พรีเมียมเมื่อเทียบกับ serverless จะยิ่งสูงขึ้น

การประเมิน “cloud premium” ในเชิงปริมาณ

  • serverless computing อย่าง AWS Lambda อาจมีต้นทุนพรีเมียม 5~30 เท่า เมื่อเทียบกับเซิร์ฟเวอร์ที่ให้สมรรถนะเท่ากัน
  • สมมติว่าเซิร์ฟเวอร์ราคา $8.2944/ชั่วโมง ให้ 1k QPS, 768GB RAM หากแทน throughput เดียวกันด้วย Lambda จะมีค่าใช้จ่ายประมาณ $46/ชั่วโมง หรือเป็น พรีเมียม 5.5 เท่า
  • ประเมินว่ามี พรีเมียม 25 เท่าเมื่อเทียบกับการเช่า OVH และเพียงมี อัตราการใช้งาน 5% ก็ทำให้ โฮสติ้งราคาประหยัดคุ้มกว่า serverless แล้ว
    • หากใช้สัญญาระยะยาวหรือ spot instance ช่องว่างของพรีเมียมอาจยิ่งกว้างขึ้นอีก
    โฆษณา
  • แม้ QPS จะต่างกัน แต่หากคำนวณในรูป memory-time แล้ว ตัวคูณของพรีเมียมจะใกล้เคียงกัน และหัวใจสำคัญคือ การปรับขนาดเซิร์ฟเวอร์ให้เหมาะกับขนาดของเวิร์กโหลด

ข้อโต้แย้งและความเข้าใจผิดที่พบบ่อย

  • “ถ้าอยู่บนคลาวด์ก็ไม่ต้องมีทีมดูแลระบบ”: แค่เปลี่ยนชื่อตำแหน่งเป็น Cloud Ops เท่านั้น และยังต้องมีความสามารถด้าน เอกสาร·การติดตามการเปลี่ยนแปลง·การรับมือกับ deprecation ซึ่งทำให้ ต้นทุนบุคลากรสูงขึ้น
  • “คลาวด์ทำให้ไม่ต้องอัปเดตด้านความปลอดภัย”: บางส่วนได้รับการยกเว้นจริง แต่จำกัดอยู่ใน ส่วนที่ทำอัตโนมัติได้ง่าย ขณะที่ การตรวจสอบไลบรารีและการตรวจสอบคอนฟิก ยังจำเป็นอยู่
  • “คลาวด์อุ่นใจได้เพราะออกแบบมาให้มี high availability”: ความซับซ้อนที่เพิ่มขึ้นสร้างจุดอ่อนใหม่ และแม้จะทำ สำรองข้าม region หรือข้าม provider ก็ยังไม่สามารถกำจัด ความล้มเหลวที่มีสาเหตุร่วมกัน ได้ทั้งหมด
  • “คลาวด์ทำให้พัฒนาได้เร็วกว่า”: ความคล่องตัวช่วงเริ่มต้นเป็นข้อดีจริง จึงควรใช้ประโยชน์จากมัน แต่ต้องติดตาม จุดเปลี่ยนด้านต้นทุน และ ย้ายในเวลาที่เหมาะสม
  • “ทราฟฟิกของเรามีความ bursty มาก”: ในกรณีนี้ serverless·auto-scale เหมาะสม
  • “แล้ว CDN ล่ะ?”: การลด latency และประหยัดแบนด์วิดท์ คือสิ่งที่ ควรซื้อแบบกระจายเป็นพื้นฐาน และ แบ็กอัป ก็เช่นกัน เป็นส่วนที่ ควรซื้อใช้

monolithic vs. microservices กับโครงสร้างเซิร์ฟเวอร์

  • “เซิร์ฟเวอร์ใหญ่” มักเชื่อมโยงกับ สถาปัตยกรรม monolithic แต่ก็สามารถจัด microservices หลายตัวในรูปคอนเทนเนอร์บนเซิร์ฟเวอร์เครื่องเดียวได้เช่นกัน
    • อย่างไรก็ตาม โอเวอร์เฮดของการสื่อสารระหว่างโปรเซส·การดีพลอย·การสังเกตการณ์ระบบ ยังคงเป็นภาระได้แม้อยู่บน โฮสต์เดียวกัน ทำให้ประโยชน์ด้านประสิทธิภาพที่ได้จริงเมื่อเทียบกับความซับซ้อนลดลงมาก
  • สำหรับระบบช่วงเริ่มต้นหรือขนาดเล็กถึงกลาง monolithic หรือบริการเพียงไม่กี่ตัว มักได้เปรียบกว่าในแง่ ความเรียบง่ายในการปฏิบัติการ

บทสรุป

  • ในกรณีส่วนใหญ่ การเลือก ขยายแนวตั้ง (เซิร์ฟเวอร์ใหญ่หนึ่งเครื่อง) จะเรียบง่ายและคุ้มค่ากว่า การขยายแนวนอน หรือสถาปัตยกรรมที่เน้นคลาวด์
  • หากผสาน ระบบสำรองหลัก/รอง·ฮาร์ดแวร์ต่างชนิด·การแยก CDN/แบ็กอัปไปภายนอก เข้าด้วยกัน ก็สามารถสร้าง ความเชื่อถือได้ในทางปฏิบัติ และมีความได้เปรียบด้าน TCO สูงในสภาพแวดล้อมที่มี โหลดต่อเนื่อง
  • หากมีกลยุทธ์ ทำซ้ำฮาร์ดแวร์อย่างแข็งแกร่ง รองรับ วิธีแบบ “เซิร์ฟเวอร์ใหญ่หนึ่งเครื่อง” ก็เป็นตัวเลือกที่เหมาะอย่างยิ่งสำหรับบริการจริง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-09-02
ความเห็นจาก Hacker News
  • หนึ่งในปัญหาใหญ่ที่สุดของค่าใช้จ่ายคลาวด์ (Cloud Tax) คือมันจำกัดขอบเขตของโซลูชันที่วิศวกรจะพิจารณาได้อย่างไม่เป็นธรรมชาติ ตัวอย่างเช่น ถ้าจ่าย AWS ประมาณ $200/เดือน จะได้เซิร์ฟเวอร์ 4 vCPU กับ RAM 16GB ซึ่งสเปกระดับนี้ก็พอๆ กับโน้ตบุ๊กสำหรับพัฒนาเมื่อ 5 ปีก่อน ในขณะที่บน Hetzner คุณสามารถเช่าเซิร์ฟเวอร์ 48 คอร์ RAM 128GB ได้ด้วยเงินเท่ากัน ช่องว่างด้านพลังประมวลผลมหาศาลมาก วิธีการที่ใช้ได้ผลดีเมื่อมีทรัพยากรมากขึ้น 10 เท่า กลับอาจไม่มีความหมายเลยบนโหนดขนาดเล็ก เงื่อนไขแบบนี้บางครั้งก็ช่วยประหยัดเวลางานวิศวกรรมที่ต้องใช้ไปกับการสร้างระบบที่ซับซ้อนกว่าได้ด้วย แน่นอนว่ายังต้องคำนึงถึงเรื่องอย่างความทนทาน แต่ในอีกด้านหนึ่ง เซิร์ฟเวอร์เฉพาะก็รับประกันประสิทธิภาพที่สม่ำเสมอได้โดยไม่ต้องกังวลเรื่อง noisy neighbor
    • ในปี 2025 คุณสามารถใช้บริการอย่าง fly.io สำหรับงานทั่วไปได้แบบสะดวกและไม่ต้องผ่านขั้นตอนซับซ้อน และสำหรับบางเฟรมเวิร์กก็มีตัวเลือกอย่าง Vercel ด้วย (เป็นตัวเลือกที่ดีมากสำหรับบางสแตกโดยเฉพาะ) ถ้าต้องการมากกว่านั้น ก็สามารถเช่าเครื่องระดับสัตว์ประหลาดจริงๆ ได้ในราคาถูกจาก OVH/Hetzner/Latitude ถ้าแค่รันบล็อกก็ยังมี VPS ให้เลือกเยอะมาก คลาวด์แบบดั้งเดิมตอนนี้แทบเหลือไว้ใช้แค่กับเรื่องกฎระเบียบ กระบวนการภายในองค์กร หรือความไร้ประสิทธิภาพเท่านั้น ทั้งในแง่ productivity ของการพัฒนาและต้นทุนเครื่อง ผมมองว่ามันแทบเป็นศูนย์ ถ้าไม่ใช่ทีมที่ไม่มีข้อจำกัดใดๆ และดันชอบระบบอนุมัติสไตล์ DMV, โหนด Intel เสียงดัง, margin แพงๆ และซัพพอร์ตห่วยๆ ก็แทบไม่มีเหตุผลสำหรับคนส่วนใหญ่
    • มันไปไกลกว่านั้นอีก—ถ้าใช้เซิร์ฟเวอร์ bare metal ก็ไม่ต้องเจอ network latency, ความหน่วง/การแย่งกันใช้ memory bandwidth ของ VM, หรือโครงสร้าง caching แยกต่างหาก ตัวอย่างเช่น แค่ให้ RAM กับ Postgres แบบจัดเต็มแล้วใช้ Linux disk caching อย่างเดียวก็พอ เร็วกว่าและเรียบง่ายกว่ามาก
    • ผมไม่เข้าใจว่าทำไมบริการเล็กๆ ถึงต้องกระโดดไปใช้ AWS ทันที ผมไม่ได้ทำอะไรซับซ้อนระดับคุณ แต่มีลูกค้ารายหนึ่งใช้สแต็ก PHP เว็บแอปขนาดเล็ก + AWS server/SQS/S3 อยู่ที่ $100/เดือน ผมย้ายมันไปเป็น Python/Django/PostgreSQL (ตอนแรกใช้ SQLite) บน VPS ราคา $25/เดือน งานอย่าง PDF OCR, อัปเดตราคา, หาสินค้าที่หายไป, และให้บริการเว็บไซต์ ทุกอย่างรันได้ดีบน 4 คอร์ RAM 6GB มันเป็นแอปภายในที่ไม่มีทางมีผู้ใช้เกิน 100 คนมากนัก ต่อให้โตขึ้นในอนาคตก็ย้ายระบบได้ง่ายมาก ตอนนี้ไม่มีเหตุผลจะใช้เซิร์ฟเวอร์ AWS $100 เลย จนกว่าจะต้องสเกลใหญ่จริงๆ
    • เห็นด้วยสุดๆ ใช้ฐานข้อมูลแบบฝังตัวอย่าง sqlite และปรับแต่งการเขียนแบบ batch ให้ดี คุณไปได้ไกลมากบน Hetzner ข้ออ้างว่า "ต้องเผื่อทรัพยากรเยอะจนสิ้นเปลือง" นั้นออกจาก AWS เมื่อไรแทบไม่มีความหมายเลย (ความคุ้มค่าต่างกันคนละชั้น) จริงๆ แล้วหลายครั้งยิ่งระบบซับซ้อน ก็ยิ่งมีความน่าเชื่อถือและความทนทานน้อยกว่าระบบโหนดเดียวด้วยซ้ำ แทบไม่มีอะไรเสียแบบถูกแยกโดดๆ เพียงจุดเดียวแล้วทั้งระบบพัง
    • ผมกลับคิดตรงข้ามนะ สำหรับเว็บไซต์เล็กๆ ผมก็ชอบ Hetzner มาก แต่สำหรับโปรเจกต์ใหญ่ คลาวด์ให้ความรู้สึกว่าแทบไม่มีข้อจำกัด ถ้าเป็นโปรเจกต์ที่เวลาของผมมีมูลค่าพอ ค่าโฮสต์ $200 หรือ $2000 ก็แทบไม่มีความหมาย ผมก็ไม่รู้สึกว่าระยะเวลาพัฒนาระหว่าง AWS CDK/Terraform+GitHub Actions กับ Docker/K8s/Ansible+CI pipeline ต่างกันชัดเจนแค่ไหน และก็ไม่รู้สึกว่าวิธี bare metal จะช่วยประหยัดเวลางานวิศวกรรมได้มากกว่าชัดเจน IaC แบบ Fargate+RDS ก็สะดวกดี ถ้าคุณต้องแยก file storage, ต้องการการสเกล, ต้องการ durability หรือจำเป็นต้องรวมบริการเฉพาะทางหลายตัวในชั้น infrastructure เช่น การสร้าง subdomain แบบ dynamic ภาระในการเรียนรู้และเชื่อมต่อบริการใหม่ๆ กลับจะหนักกว่าอีก จริงๆ ผมทำงานแบบนี้มาตั้งแต่ก่อนยุคคลาวด์ และถ้าเป็นโปรเจกต์ทำเงิน ผมมองว่าค่าใช้จ่ายคลาวด์คุ้มกับการลงทุน ถ้าโปรเจกต์ไหนค่าใช้จ่ายระดับนั้นยังหนักเกินไป มันก็คงใกล้เคียงงานอดิเรกมากกว่าธุรกิจ ผมไม่อยากจัดการ RAID หรือคลัสเตอร์ไฟล์ซิสเต็มหลายชุดด้วยทรัพยากรของสตาร์ตอัป/บริษัททั่วไปหรือด้วยเวลาของตัวเอง มันให้ความรู้สึกเหมือนรสนิยมแบบชอบปรับแต่ง Arch+Emacs เทียบกับคนที่พอใจกับ MacBook ถ้าอยากเปลี่ยน kernel scheduler ก็ใช้ Arch ไป แต่ถ้าไม่ใช่ผมแนะนำ MacBook อย่างไรก็ดี ถ้างบไม่มีจริงๆ และ raw throughput สำคัญมาก ผมก็เคยเจอว่าดีดิเคตเซิร์ฟเวอร์เหมาะมากจริงๆ (ประหยัดได้หลายพันดอลลาร์) ถ้ามันสำเร็จขึ้นมา หลังจากนั้นก็คงค่อย vertical scale ซึ่งกรณีแบบนี้ค่อนข้างหายาก
  • HN (Hacker News) ใช้งานอยู่ 2 เครื่อง คือเซิร์ฟเวอร์สำหรับโปรดักชันจริงกับเซิร์ฟเวอร์สำรอง เป็นรูปแบบที่มีประโยชน์มาก เพราะถ้ามีปัญหาฮาร์ดแวร์หรือต้องอัปเกรดก็ failover ได้ทันที แต่อย่างไรก็ตาม ถ้าเซิร์ฟเวอร์ทั้งสองเป็นโคลนที่เหมือนกันทุกอย่าง ก็ต้องระวังเพราะอาจพังพร้อมกันได้ทั้งคู่
    • แม้จะไม่ร้ายแรงเท่า SSD แต่ AMD CPU ก็เคยมีบั๊กน่าสนใจอยู่เหมือนกัน หลัง uptime ราว 1044 วัน คอร์บางคอร์จะหยุดทำงานไปเลย กรณี AMD EPYC Rome CPU Hang
    • สงสัยว่ามีสถิติเรื่อง downtime ของ HN (Hacker News) ไหม ในช่วง 10 ปีที่ผ่านมา ผมจำได้ว่าแทบจะล่มแค่ครั้งหรือสองครั้ง ความรู้สึกคือ uptime น่าจะเกิน 99.99%
  • ผมใช้ hybrid colo + public cloud มานานเกิน 10 ปีแล้ว และพอตั้งแต่ถึงขนาดหนึ่ง มันก็เป็นตัวเลือกที่ดีที่สุดด้านการ optimize ต้นทุนเสมอ ประสิทธิภาพฮาร์ดแวร์ก็ดีขึ้นเรื่อยๆ แน่นอนว่าต้องมีคนดูแล network/infrastructure แต่จริงๆ ทุกวันนี้การจัดการง่ายมาก และในทางกลับกันคุณก็มักต้องมีผู้ดูแล "คลาวด์" อยู่ดี ดังนั้นผลประหยัดค่าแรงแทบไม่มี ตัวเลือก colocation ก็มีหลากหลาย และผู้ให้บริการก็มักขาย bandwidth แบบรวมแพ็กเกจ ครั้งหนึ่งผมเคยรันคลัสเตอร์ dell vrtx 8 ชุด, SAN และ VM มากกว่า 500 ตัว (ตั้งแต่ msSQL ขนาดใหญ่ไปจนถึง kube) ถ้าอยู่บน public cloud ต่อให้ได้ส่วนลดแบบ reserved ก็ยังน่าจะโดนบิลทะลุเลข 6 หลัก แต่ค่า colo ตอนนั้นอยู่ที่ $2,400/เดือน (คิดจากค่าไฟเป็นหลัก) และความช้าของโหนดบน public cloud ที่เห็นได้ชัดก็ทำให้ผมแปลกใจเสมอ (แม้จะเป็น CPU/VCPU รุ่นเดียวกันก็ตาม) ต้องทำการบ้านเรื่องดีลซื้ออุปกรณ์, การอัปเดต, ไลเซนส์, สัญญาซัพพอร์ตให้ดี แต่ในโลกความจริงมันจัดการได้แน่นอน และตอนนี้การเชื่อมต่อคลาวด์กับเครือข่ายก็ทำได้ง่ายแล้ว รับ fiber drop แล้วต่อเข้ากับ VPC ได้เลย
    • ผมเข้าใจว่า colocation คือเราซื้อฮาร์ดแวร์เอง แล้วเช่าจากดาต้าเซ็นเตอร์เฉพาะไฟฟ้า แร็ก และวงจรเครือข่าย อยากรู้ว่าจริงๆ แล้วใช่แบบนั้นไหม และมันดีกว่าการเช่า bare metal server ทั่วไปอย่างไร
  • ผมคุยประเด็นนี้กับเพื่อนๆ มาหลายปีแล้ว ข้อเสียใหญ่ที่สุดของอินฟราภายในคือคุณต้องมีคนที่มีความเชี่ยวชาญมาดูแลมันให้ดี บทความนี้โฟกัสกับสเกลด้านบน แต่ตลาดด้านล่างนั้น ถ้ามีอุปกรณ์อยู่พอสมควรอยู่แล้ว แค่แร็กเล็กๆ หรือระบบเครือข่ายก็คืนทุนได้ภายในปีเดียว เมื่อคิดรวม cloud premium ในทุกวันนี้แล้ว ดูเหมือนว่าต่อให้จ้างแอดมินเพิ่มหนึ่งคน อินฟราภายในก็ยังคุ้มกว่า
  • บริษัทหนึ่งที่ผมเคยร่วมก่อตั้งทำระบบ enterprise automation engine และในทีมอยาก deploy โซลูชันเป็น SaaS เพื่อ maximize รายได้ ทั้งที่จริงๆ multi-tenant DB schema + VPS ก็เพียงพอแล้ว แต่ทีมกลับหมกมุ่นกับการเรียน kubernetes และ cloud-native stack ใช้เวลา 1 ปีเต็มไปกับสภาพแวดล้อมพัฒนาและระบบอัตโนมัติฝั่งปฏิบัติการ สุดท้ายบริษัทก็อยู่ได้ไม่นานและปิดตัวไป
    • แต่พวกวิศวกรก็ได้ประสบการณ์ k8s ไว้ในเรซูเม่ เลยหางานใหม่กันต่อได้
    • ผมก็มีประสบการณ์คล้ายกัน—เสียเวลาไปมากกับการแก้ปัญหาที่อาจจะต้องเจออีกทีในอีก 5 ปีข้างหน้า สำหรับโปรเจกต์ส่วนใหญ่และสตาร์ตอัประยะแรก แค่ PaaS หรือ nginx+docker containers ก็พอแล้ว พอถึงวันที่มี pain point จริงค่อยกลับมาคิดก็ได้
    • เพราะงั้นสำหรับผม ตราบใดที่ "บิลยังไม่เจ็บจริง" ก็ยังชอบใช้ PaaS อยู่ จ่ายค่า heroku/render/fly ไปแล้วเอาเวลาไปโฟกัสกับ PMF (Product-Market Fit) ไม่อย่างนั้นก็มีอีกเส้นทางคือใช้เงิน VC ไปสนุกกับ K8s แล้ววนย้ายงานไปที่ต่อไปเรื่อยๆ
  • หลายธุรกิจไม่ได้สำคัญขนาดนั้น คนจำนวนมากเครียดกับการที่ระบบหยุดทำงาน แต่จริงๆ บริการที่พวกเขาดูแลก็ไม่ได้สำคัญถึงขั้นนั้น ถ้าระบบโปรดักชันพังไปตอนกลางวัน โลกก็ไม่ได้แตก แค่น่ารำคาญหน่อย บริษัทแบบนี้เคยอยู่ได้สบายๆ กับเซิร์ฟเวอร์ออฟฟิศธรรมดาสำหรับผู้ใช้ 250 คน แต่พอย้ายขึ้นคลาวด์งบก็พุ่งกระฉูด คลาวด์ยอดเยี่ยมสำหรับงานบางประเภท แต่สำหรับที่เหลืออีกมาก มันใกล้เคียงกับการตลาดที่พูดเกินจริง ทั้งนี้วิศวกรจำนวนมากก็มักหมกมุ่นกับ "ความสามารถในการสเกลที่สมบูรณ์แบบ" จนมองหาแต่สถาปัตยกรรมในอุดมคติ แทนที่จะเลือกโซลูชันที่ดีพอ
    • มีเพื่อนร่วมทีมคนหนึ่งที่ผมเคยทำงานด้วยชอบพูดไว้เสมอว่า "อย่างน้อยถ้าเราพลาดก็ไม่มีใครตาย เพราะงั้นไม่ต้องกังวลเกินไป" เขาเคยทำงานที่มีความรับผิดชอบสูงกว่านี้มาก ดังนั้นแนวคิดนี้ช่วยได้มากเวลาเจอสถานการณ์ยากๆ
  • ถ้าสร้างโครงสร้างซับซ้อนเพื่อไล่ตามเป้าหมาย uptime 100% สุดท้ายกลับทำพลาดบ่อยจนความน่าเชื่อถือลดลง ธุรกิจส่วนใหญ่จริงๆ แล้วรับได้กับการล่มเป็นครั้งคราว 1–2 ชั่วโมง หรือแม้แต่ข้อมูลสูญหายบ้าง ถ้าสื่อสารความคาดหวังพวกนี้ให้ชัดก่อน คุณก็จะทำวิศวกรรมด้วยโครงสร้างที่เรียบง่ายกว่าและเชื่อถือได้มากกว่า
    • ต้นทุนก็ถูกกว่ามากด้วย แต่ความคาดหวังแบบนี้หลายครั้งผู้บริหารที่ไม่ใช่สายเทคนิคกลับยอมรับไม่ได้ (โดยเฉพาะเรื่องข้อมูลสูญหายที่แทบไม่ยอมกันเลย) วิศวกรมักบอกว่าแค่ดูแลสภาพแวดล้อม แต่ในโลกจริงมันไม่ได้ง่ายขนาดนั้น และถ้าพลาดขึ้นมาก็อาจดูเหมือนไม่มีความสามารถ
  • เป็นบทความที่ดีมาก ตอนสเกลด้วยแนวทางนี้ (ไม่ใช้คลาวด์) การเพิ่ม CDN ก็น่าคิด เพราะ CDN ให้ทั้ง WAF และ DNS failover ได้ด้วย แต่ถ้าไม่ใช้คลาวด์ก็มีจุดที่น่าเสียดายนิดหน่อยคือคุณต้องดูแล DB เอง ดังนั้นอาจพิจารณาผู้ให้บริการที่มี cloud DB เป็นตัวเลือก หรือถ้าใช้สถาปัตยกรรม active/passive ก็อาจรันโหนด passive บน cloud VM + autoscale เพื่อให้ถูกลงก็ได้ ทุกวันนี้ราคาเช่าเซิร์ฟเวอร์ถูกมากจริงๆ VPS 4GB ราว $6 และ bare metal แบบ 32GB quad-core ก็ประมาณ $90 ใช้เว็บเปรียบเทียบราคาอย่าง serversearcher.com ก็มีประโยชน์
    • ผมเคยรัน Postgres ใน docker container และแค่ทำ backup ตามรอบสม่ำเสมอก็ไม่มีปัญหาอะไร การดูแลก็ง่าย ไม่ได้มีอะไรน่าหนักใจ
    • บนเครื่องเดี่ยว sqlite ให้ประสิทธิภาพสูงกว่าและดูแลง่ายกว่า Postgres/MySQL มาก
  • ผมเองก็รันบริการบน VPS เหมือนกัน ทิ้งคลาวด์ไปนานแล้ว ถ้าวันหนึ่งโปรเจกต์ของผมเริ่มทำเงิน ผมก็ตั้งใจจะซื้อเครื่องแล้วเอาไป colo คลาวด์สำหรับผมเหมือนการเดต ตอนนี้ความสนุกหมดแล้ว และอยากทำอะไรที่จริงจังและมีผลผลิตมากกว่า
    • ตัว colo เองก็เต็มไปด้วยปัญหาเหมือนกัน ฮาร์ดแวร์เสียจากไฟดับในดาต้าเซ็นเตอร์นี่เกิดบ่อยอย่างน่าตกใจ แบบย้อนแย้งเลยคือไฟที่บ้านผมกลับเสถียรกว่า ถ้าไม่ใช่ธุรกิจที่รายได้หลายล้านจะกระทบจาก downtime แค่ไม่กี่นาที สำหรับคนส่วนใหญ่รันเซิร์ฟเวอร์ไว้ในชั้นใต้ดินก็ไม่ได้มีปัญหาอะไร หลายคนประเมินความจำเป็นของ uptime 99.999% หรือ bandwidth สูงๆ เกินจริงมาก และ colo ก็ไม่ได้ถูกอย่างที่คิดเสมอไป ค่าไฟในดาต้าเซ็นเตอร์หลายแห่งแพงกว่าค่าไฟทั่วไป/ธุรกิจ หรือแม้แต่ที่อยู่อาศัยเสียอีก ของที่ถูกจริงๆ คืออินเทอร์เน็ต/ไฟเบอร์ และทุกวันนี้หลายประเทศมีอินเทอร์เน็ตธุรกิจ 5–10Gbit ได้ในราคา 100 ยูโรแล้ว (เมื่อก่อนแค่ 1Gbit ก็ยังโดนเรียกเกิน 2,000 ยูโร)
  • ต่อให้ไม่มองเรื่องต้นทุนหรือการวิเคราะห์ความจุ การฝืนสวนทางเทรนด์ของอุตสาหกรรมก็ไม่ใช่เรื่องง่าย ข้อดีแบบ "ไม่ต้องสนใจฮาร์ดแวร์เลย" นั้นมีอยู่จริง นอกจากนี้ยังมีแนวคิดเข้มข้นว่าควรหลีกเลี่ยง capex (ค่าใช้จ่ายลงทุน) ให้ได้ทุกกรณี เพราะฮาร์ดแวร์เซิร์ฟเวอร์ต้องจ่ายล่วงหน้าก้อนใหญ่ และยังมีกลไกทางความรู้สึกที่ว่า ถ้า AWS region ล่ม มันไม่ค่อยเหมือนเป็น "ความผิดของเรา" แต่ถ้าเซิร์ฟเวอร์ในบริษัทล่ม มันดูเป็น "ความผิดของเรา" มากกว่า
    • การกลัว capex (ค่าใช้จ่ายลงทุน) แบบสุดโต่งนี่แทบเป็นผลจากโครงสร้างการลงทุนแบบ VC โดยตรง—ถ้านักลงทุนต้องการการเติบโตเร็วอย่างเดียว การลงทุนล่วงหน้า (ซื้อเซิร์ฟเวอร์) ก็แทบไม่มีทางถูกมองว่ามีเหตุผล ในทางกลับกัน ธุรกิจที่มั่นคงสามารถรับ capex ขนาดเล็กในแต่ละปีได้สบายๆ
    • ไม่จำเป็นต้องซื้อฮาร์ดแวร์เซิร์ฟเวอร์เองเสมอไป—เช่าจากที่อย่าง Hetzner ก็เพียงพอแล้ว ผมอยากฟังเพิ่มเติมว่าข้อดีของการ "ไม่ต้องกังวลเรื่องฮาร์ดแวร์" นี่หมายถึงอะไรอย่างเป็นรูปธรรม
    • แนวคิดอยากเลี่ยง capex มีอยู่จริง แค่ใช้เครื่องคิดเลขเป็นก็รู้แล้วว่าทุกวันนี้ราคาเซิร์ฟเวอร์แทบไม่มีนัยสำคัญต่อภาพรวมธุรกิจ สิ่งที่แพงจริงคือ "พื้นที่" รอบเซิร์ฟเวอร์ ดังนั้นส่วนใหญ่คนจึงไม่ได้เช่าเซิร์ฟเวอร์ แต่เช่าพื้นที่ (แร็ก/ไฟฟ้า)
    • สิ่งที่องค์กรจ่ายเงินจริงๆ โดยสรุปก็คือ "การทำให้ความรับผิดชอบเป็นนามธรรม (abstraction of responsibility)" ผู้บริหารระดับสูงในองค์กรใหญ่จะสบายใจเมื่อเลือกโซลูชันจากบริษัทใหญ่อย่าง MS หรือ AWS
    • ถ้าเช่า bare metal server ก็ไม่ต้องกังวลเรื่อง capex หรือการบำรุงรักษา