- แก่นของข้อถกเถียงไม่ใช่ 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 สูงในสภาพแวดล้อมที่มี โหลดต่อเนื่อง
- หากมีกลยุทธ์ ทำซ้ำฮาร์ดแวร์อย่างแข็งแกร่ง รองรับ วิธีแบบ “เซิร์ฟเวอร์ใหญ่หนึ่งเครื่อง” ก็เป็นตัวเลือกที่เหมาะอย่างยิ่งสำหรับบริการจริง
ยังไม่มีความคิดเห็น