ปี 2023 ความรุ่งโรจน์อยู่ห่างออกไปแค่ 11MB/วินาที
(thmsmlr.com)- แม้แต่เว็บไซต์ระดับท็อป 1,000 ที่มีผู้เข้าชมราว 200 ล้านครั้งต่อเดือน หากดูเฉพาะ HTML ก็มีปริมาณส่งข้อมูลเพียงประมาณ 30TB/เดือน หรือเฉลี่ย 11MB/วินาที ซึ่งเป็นขนาดที่เซิร์ฟเวอร์เครื่องเดียวรับมือได้
- การคำนวณตั้งต้นจาก Business Insider โดยสมมติว่าผู้เข้าชม 1 คนดู 2 หน้า จึงเป็น เอกสาร HTML 400 ล้านฉบับ/เดือน และ HTML แบบบีบอัดมีขนาดราว 75KB โดยให้ JS, CSS และรูปภาพไปอยู่บน CDN
- การรันที่ edge มีข้อดีคือใช้เซิร์ฟเวอร์ใกล้ผู้ใช้ แต่ถ้าระหว่างเรนเดอร์มีการ ไป-กลับฐานข้อมูล ความหน่วงก็จะถูกดึงกลับไปยังตำแหน่งของ DB ต้นทางอีกครั้ง
- ต้นทุนก็ต่างกันมาก: Hetzner ให้เซิร์ฟเวอร์ 16 คอร์, RAM 64GB และ NVMe ที่ $0.34/ชั่วโมง พร้อมทราฟฟิกฟรี 20TB แล้วคิด $1.5/TB ขณะที่ AWS และ Vercel มีค่าบริการแบนด์วิดท์ต่อหน่วยสูงกว่ามาก
- หากไม่ใช่งานที่จำเป็นต้องใช้คลาวด์เป็นพิเศษ สถาปัตยกรรมแบบ เซิร์ฟเวอร์เดี่ยว + SQLite + Litestream + CDN จะเรียบง่ายและถูกกว่า และช่วยเลี่ยงการสเกลแนวนอนโดยไม่จำเป็น
ขนาดจริงของเว็บไซต์ระดับท็อปเมื่อมองผ่าน 11MB/วินาที
- ใช้ Business Insider เป็นตัวอย่างของเว็บไซต์ในกลุ่มท็อป 1,000
- ตาม SimilarWeb อยู่อันดับ 587 ของโลก และมีผู้เข้าชมราว 200 ล้านคนต่อเดือน
- หากเฉลี่ย 2 หน้าต่อผู้เข้าชม 1 คน จะต้องให้บริการ เอกสาร HTML 400 ล้านชิ้นต่อเดือน
- จากบทความตัวอย่าง เอกสาร HTML มาตรฐานเมื่อบีบอัดแล้วมีขนาดประมาณ 75KB
- เมื่อนำมาคูณกัน จะต้องใช้แบนด์วิดท์สำหรับ HTML ราว 30TB/เดือน
- 30TB/เดือน เมื่อนำมาเฉลี่ยจะอยู่ที่ประมาณ 11MB/วินาที
- ในกรณีของ Business Insider จะอยู่ราว 150 requests/sec
- สมมติว่าไม่ได้ใช้ CDN สำหรับ HTML ส่วน JS, CSS และรูปภาพสามารถให้บริการผ่าน CDN ได้
- HTML แบบบีบอัด 75KB ถือว่าค่อนข้างใหญ่ ดังนั้นขึ้นอยู่กับการออกแบบว่าจะลดขนาด HTML หรือต้องเพิ่มจำนวนคำขอแทน
- บนฮาร์ดแวร์สมัยใหม่ การให้แอปพลิเคชันสร้าง HTML ที่ 11MB/วินาทีถือเป็นเกณฑ์ที่ต่ำ
- ซีพียูเซิร์ฟเวอร์ AMD รุ่นใหม่ให้ได้ถึง 64 คอร์ 128 เธรด
- มีข่าวลือว่า Zen 5 Turin สำหรับเซิร์ฟเวอร์จะมี 192 คอร์ และในเซิร์ฟเวอร์แบบ dual socket ก็มีการพูดถึงระดับเกือบ 400 คอร์และสูงสุด 768 เธรด
- ในมุมนี้ Docker, serverless และการสเกลแนวนอนไม่ได้เป็นตัวเลือกที่จำเป็นเสมอไป
การรันที่ edge ไม่ได้ลดความหน่วงเสมอไป
- ขีดจำกัดทางกายภาพของเวลาไป-กลับจากอีกฟากโลกหนึ่งถึงอีกฟากโลกหนึ่งตามความเร็วแสงอยู่ที่ราว 200ms
- ในโลกจริง การไปยังดาต้าเซ็นเตอร์ที่ดีอีกฟากโลกมักใช้เวลาประมาณ 300ms
- หากให้บริการ JS, CSS และสื่อผ่าน CDN การลดเวลาในการประมวลผลฝั่งเซิร์ฟเวอร์ลง 300ms ในการเรนเดอร์ครั้งแรก ก็แทบให้ผลใกล้เคียงกับการย้ายเซิร์ฟเวอร์ไปไว้ใกล้ผู้ใช้
- เทคโนโลยี serverless ยุคที่ 2 ลดปัญหาเดิมที่ cold boot เคยกินงบความหน่วง 300ms ไปได้มาก แต่การไป-กลับฐานข้อมูลยังคงอยู่
- หากการเรนเดอร์หน้าเว็บต้องใช้การ query ฐานข้อมูลแม้เพียงครั้งเดียว edge server ก็ยังต้องไป-กลับยังตำแหน่งที่ฐานข้อมูลต้นทางอยู่ เช่น us-east-1
- ความหน่วงจึงไม่ได้หายไป แต่ย้ายจากระหว่างผู้ใช้-เซิร์ฟเวอร์ต้นทาง ไปเป็นระหว่าง edge server-เซิร์ฟเวอร์ต้นทางแทน
- หน้าเว็บที่ซับซ้อนมักต้องใช้ การ query ฐานข้อมูล 5 ครั้งขึ้นไป เพื่อเรนเดอร์
- เว็บเฟรมเวิร์กจำนวนมากทำงานแบบ single-thread และรัน query ตามลำดับ ดังนั้นหากต้องไป-กลับข้ามดาต้าเซ็นเตอร์หลายรอบ อาจช้ากว่าการไปยังต้นทางครั้งเดียวด้วยซ้ำ
- มีหลักโดยคร่าวว่าการสื่อสารระหว่างดาต้าเซ็นเตอร์ช้ากว่าภายในดาต้าเซ็นเตอร์ 10 เท่า และภายในดาต้าเซ็นเตอร์ก็ช้ากว่าภายในอุปกรณ์เดียวกัน 10 เท่า
- ในบริบทนี้ SQLite แบบโลคัลจึงกลายเป็นตัวเลือกที่ได้เปรียบด้านความหน่วง
ความต่างด้านต้นทุนของ Hetzner, AWS และ Vercel
- เซิร์ฟเวอร์ 16 คอร์ของ Hetzner พร้อม RAM 64GB และไดรฟ์ NVMe มีราคา $0.34/ชั่วโมง
- เมื่อเทียบกับเซิร์ฟเวอร์ x86 ใกล้เคียงกัน AWS EC2 m5a.4xlarge อยู่ที่ $0.68/ชั่วโมง
- ความต่างของราคาแบนด์วิดท์ยิ่งชัดเจนกว่า
- Hetzner ให้ทราฟฟิกฟรี 20TB และหลังจากนั้นคิด $1.5/TB
- AWS ให้ฟรี 100GB และหลังจากนั้นคิด $90/TB
- Vercel ถูกยกเป็นตัวอย่างว่าให้ฟรี 1TB แรก แล้วคิด $200/TB
- ปริมาณใช้งานฟรีจากผู้ให้บริการคลาวด์ช่วยให้เริ่มต้นได้ง่าย แต่เมื่อขยายขนาดแล้วอาจย้อนกลับมาเป็นต้นทุนสูง
เดินระบบให้เรียบง่ายด้วยสถาปัตยกรรมเซิร์ฟเวอร์เดี่ยว
- หากไม่ใช่กรณีใช้งานคลาวด์เฉพาะทาง เช่น การแปลงรหัสวิดีโอ การรันโมเดล AI ของตนเอง หรือภาระงานที่สร้างโหลดหนักให้ระบบจริง ๆ เว็บไซต์หรือ SaaS ก็สามารถรันบน เซิร์ฟเวอร์เดี่ยว ได้
- หากวางเซิร์ฟเวอร์ไว้ที่เวอร์จิเนีย ก็สามารถให้ผู้ใช้ภาษาอังกฤษใช้งานด้วยความหน่วง ต่ำกว่า 100ms ได้
- โครงสร้างที่แนะนำคือให้เรียบง่ายโดยยึดเซิร์ฟเวอร์เครื่องเดียวเป็นศูนย์กลาง
- ใช้ SQLite เป็นฐานข้อมูลบนเครื่องเดียวกัน
- ใช้ Litestream เพื่อสำรองข้อมูล SQLite อย่างต่อเนื่อง
- แคช CSS, JS และรูปภาพผ่าน CDN
- เรนเดอร์ฝั่งเซิร์ฟเวอร์ใกล้กับ SQLite เพื่อลดการไป-กลับและเพิ่มประสิทธิภาพ
- การ deploy ก็ไม่จำเป็นต้องทำให้ซับซ้อน
- ให้ CI ส่งโค้ดขึ้นเซิร์ฟเวอร์ด้วย SCP ก็พอ
- NGINX รองรับการ deploy แบบไร้ downtime
- Docker และ virtualization ถูกมองว่าเป็นปัจจัยที่ทำให้การรันโค้ดและ CI/CD ช้าลง
กรณีที่ต้องสเกลแนวนอน และกรณีที่ไม่ต้อง
- แนวคิดที่ว่าจำเป็นต้องสเกลแนวนอนนั้น ส่วนใหญ่เป็นการพูดเกินจริง
- มีสมมติฐานรองรับว่า ประสิทธิภาพของเซิร์ฟเวอร์พัฒนาเร็วกว่าอัตราการเติบโตของอินเทอร์เน็ต
- หากความหน่วงมีความสำคัญมากจริง ๆ ก็สามารถเพิ่มเซิร์ฟเวอร์ในเยอรมนีและแคลิฟอร์เนียได้
- งานเขียนให้ route ไปยัง primary
- งานอ่านใช้ local read replica
- โครงสร้างเช่นนี้สเกลได้ดีพอ มีความซับซ้อนในการดูแลต่ำ และมีต้นทุนค่อนข้างถูก
- การให้บริการ HTML ระดับ 11MB/วินาที ไม่จำเป็นต้องทำให้ยากเกินความจำเป็น
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ธุรกิจ โฮสติ้ง เล็ก ๆ ในอดีตของฉันรุ่งและร่วงตรงจุดนี้พอดี ตอนนั้นเราไม่รู้เลยว่ากำลังเกิดอะไรขึ้น
ตอนที่ธุรกิจเติบโตในช่วงต้นยุค 2000 รายได้ก้อนใหญ่มักมาจากสแตกที่ซับซ้อน และมีการจัดวางแบบเกินความจำเป็นจริงของลูกค้า เช่น load balancer กับ firewall แบบทำซ้ำซ้อน แต่ลูกค้าต้องการแบบนั้น
การรับมือเหตุขัดข้องหลายครั้งมีต้นทุนด้านความซับซ้อนในการปฏิบัติการสูงกว่าประโยชน์ที่ได้เวลาที่เซิร์ฟเวอร์ล่มไปตามที่ออกแบบไว้ และเรายังสร้างแพลตฟอร์มคลาวด์โฮสติ้งแบบใช้ API เพื่อต่อกรกับ AWS ด้วย แต่รายได้ไปพีคในปี 2012
ลูกค้าต้องการโซลูชันที่ซับซ้อนกว่าซึ่งใช้ AWS บางส่วนหรือทั้งหมด แต่เราคิดว่าฮาร์ดแวร์แข็งแรงขึ้นมากเมื่อเทียบกับ 10 ปีก่อน ดังนั้นแม้แต่ลูกค้ารายใหญ่ก็น่าจะต้องการเซิร์ฟเวอร์ที่น้อยลงและเรียบง่ายขึ้น
แต่สิ่งนั้นไม่ใช่การขายความฉลาด แต่เป็นการขายราคา และเราไม่เข้าใจความทะเยอทะยานทางการเงินที่จำเป็นต่อการเปลี่ยนผ่านแบบนั้น เซิร์ฟเวอร์เดี่ยวราคาถูกไม่มีใครเชื่อถือ และถึงจะซื้อสองเครื่องก็ยังตอบเรื่องการสเกลไม่ได้
สุดท้ายรายได้ก็ยังพอประคองได้ แต่เราไม่สามารถสร้างสแตกบริการแบบจัดการให้พร้อมกับ ecosystem ซอฟต์แวร์ได้เร็วกว่า Amazon และหลังจากความท้าทายทางเทคนิคใหม่ ๆ เหือดหายไป ก็ขายบริษัทในปี 2018
เราเติบโตมาแบบบูตสแตรป จนบิลโฮสติ้งที่ไม่มีเพดานดูเหมือนความเสี่ยงบ้าคลั่ง ดังนั้นการออกแบบผลิตภัณฑ์ก็ออกมาจากวิธีคิดแบบนั้น แต่กว่าจะรู้ตัวก็สายไปว่าใคร ๆ ก็ยอมรับความเสี่ยงนั้นกันหมด
เหตุผลที่ AWS ฝังรากได้ไม่ใช่แค่เพราะ VC ทำให้ผลิตภัณฑ์ราคาแพงเป็นไปได้ แต่เพราะ ความฉลาด แบบเฉพาะตัวของมันถูกปลูกฝังเข้าไปในนักพัฒนาซอฟต์แวร์ทั้งรุ่นแล้ว เพียงแต่ความรู้ว่าควรไม่ใช้คลาวด์เมื่อไร และทางเลือกคืออะไร ตอนนี้ดูเหมือนกลายเป็นความรู้เฉพาะกลุ่มไปมากแล้ว
มีปัญหาอยู่หลายอย่างในตัวเลขเหล่านี้
อย่างแรก ทราฟฟิกไม่ได้กระจายอย่างสม่ำเสมอ ตัวเลข 400 ล้าน page load ต่อเดือนในบทความนี้อาจอยู่ภายใต้กฎ 80/20 แบบซ้อนกัน และถ้าคิดแบบนั้น จะมีคำขอราว 205 ล้านครั้งถาโถมเข้ามาในเวลา 5.8 ชั่วโมง หรือประมาณ 9.7 พันคำขอต่อวินาที
ระบบเดี่ยวก็อาจทำได้ แต่ไม่ใช่เรื่องเล็กน้อยอีกต่อไป โดยเฉพาะถ้าต้องการฐานข้อมูลเดี่ยวโดยไม่มี read replica แม้ทราฟฟิกรวมจะเท่ากัน แต่ข้อจำกัดแบนด์วิดท์ที่ต้องใช้รองรับโหลดพีกย่อมสูงกว่าค่าเฉลี่ย 11MB/s ที่มองโลกในแง่ดีมาก
อย่างที่สอง ค่า latency ปลายทางถึงปลายทางแบบทางเดียวใช้ได้กับข้อมูลสตรีมมิงเท่านั้น ในการ cold start ของโลกจริง ถ้าไม่มี HTTP/3 จะต้องมีการไปกลับ 3 ครั้งเพื่อสร้าง TCP connection และอย่างน้อย 2 ครั้งสำหรับ TLS ก่อนจะถึงขั้นส่ง HTTP request และ response
ถ้าจะให้บริการกับคนจริง ๆ ทุกอย่างที่ผู้ใช้สังเกตได้ต้องเกิดขึ้นภายใน ต่ำกว่า 1 วินาที และหลังจากนั้นอัตราที่ผู้ใช้คิดว่าระบบพังแล้วปิดแท็บจะพุ่งสูงขึ้นอย่างมาก
ฉันเคยช่วยดูแลเว็บเทรดเดิมพันแห่งหนึ่ง ทราฟฟิกพุ่งแบบสุดขั้ว ข้อกำหนดเรื่อง latency ก็เข้มมาก และปริมาณธุรกรรมก็กระจุกอยู่ในช่วงสั้นมากของหน้าต่างเหตุการณ์ทั้งหมด การเทรดแบบเรียลไทม์ต้องให้ผลลัพธ์ขึ้นหน้าจอภายใน 100ms นับจากที่ผู้ใช้เริ่มลงมือ และค่า network round-trip ก็กินงบเวลาประมวลผลของเหตุการณ์ไปไม่น้อย
อ้างอิง: https://www.nngroup.com/articles/response-times-3-important-...
โหลดแบบนั้นก็ยังรับมือได้ด้วยเซิร์ฟเวอร์เดี่ยวตัวใหญ่ แต่ตอนนี้มันไม่ใช่แค่เว็บเซิร์ฟเวอร์ธรรมดาแล้ว กลายเป็นการทำ ฟรอนต์เอนด์โหลดบาลานเซอร์ ที่ค่อนข้างทรงพลังและมีเว็บเซิร์ฟเวอร์ติดมาด้วย
AWS อาจคิดแพง แต่ load balancer กับโครงสร้างพื้นฐานเครือข่ายของมันมีงานวิศวกรรมมหาศาลอยู่เบื้องหลัง และทำให้คนอื่นไม่จำเป็นต้องกลายเป็นผู้เชี่ยวชาญทั้งกองนี้ทั้งหมด
จริง ๆ แล้วมีบริการกี่ตัวกันที่ต้องการการเข้าถึงระดับทั่วโลก? แล้วทำรองรับหลายภาษาไปพร้อมกันด้วยหรือเปล่า?
ถ้าให้บริการในสหรัฐหรือใน EU เซิร์ฟเวอร์ศูนย์กลางดี ๆ เพียงตัวเดียวก็ให้ latency ต่ำกว่า 30ms ได้ทั่วทั้งภูมิภาคนั้น
เว้นแต่จะมีความต้องการระดับโลกจริง ๆ และต้องดูแลฐานข้อมูลแบบ global ด้วย ไม่อย่างนั้น edge ก็ถูกให้ค่ามากเกินจริงอยู่พอสมควร
เห็น
500 Internal Server Errorโผล่ขึ้นมาแล้วเดาว่าผู้เขียนน่าจะได้รับทราฟฟิกมากกว่า 11MB/s เสียอีก มีสำเนาเก็บไว้ที่นี่: https://archive.is/UVpg0PR_END_OF_FILE_ERRORเป็นครั้งแรก หลายเว็บบอกว่าเกิดจาก proxy, VPN, DNS-over-HTTPS แต่ในกรณีของฉันไม่ใช่แบบนั้นฉันคิดว่าบทความนี้มองผิดมุม
วิธีที่ดีกว่าคือ อย่าสเกลเร็วเกินไป
สร้างเท่าที่จำเป็นก็พอ และในกรณีส่วนใหญ่ แม้แต่ CDN ก็เป็นค่าใช้จ่ายที่ไม่จำเป็นด้วยซ้ำ แน่นอนว่าต้องอยู่บนสมมติฐานว่าไม่ได้โดนผู้ให้บริการคลาวด์คิดภาษีแบนด์วิดท์แบบโหดเกินไป
ถ้าเริ่มเห็นปัญหาด้านประสิทธิภาพค่อยจัดการตอนนั้นก็ได้ และถ้าม้าทำงานธรรมดาตัวหนึ่งกลายเป็นยูนิคอร์นที่ทุกคนต้องการขึ้นมาจริง ๆ นั่นก็เป็นปัญหาที่น่าอยากมี
ถ้าผลิตภัณฑ์ดี ผู้ใช้ก็จะกลับมาลองใหม่ในอีกชั่วโมง ไม่ได้ย้ายไปหาคู่แข่งทันที ถ้าเริ่มมีปัญหาเรื่องการสเกล ก็ค่อยขยับไปใช้ โมเดลไฮบริด ที่สเกลเฉพาะส่วนที่กินทรัพยากรสูง
แต่ถ้าอยากทำเว็บสเกลตั้งแต่วันแรก มีไมโครเซอร์วิสเป็นสิบ ๆ ตัว มีสถานะความล้มเหลวที่ระเบิดอยู่ตรงกลาง และเผาเงิน VC ไปกับบิล AWS ก่อนลูกค้าคนแรกก็เชิญตามสบาย
การดูแลเซิร์ฟเวอร์จริงด้วยตัวเองเป็นปัญหาของวันหลัง ไม่ใช่ปัญหาตอนนี้ ถึงวันที่ต้องเลือกระหว่างบิล AWS หนึ่งล้านดอลลาร์กับเซิร์ฟเวอร์เดี่ยวตัวใหญ่ คุณก็คงไม่ได้ตัดสินใจจากการอ่านบล็อกโพสต์ แต่กำลังรันทดสอบเองอยู่แล้ว
การใช้ AWS ก็เหมือนซื้อ แพะรับบาป มาด้วย เวลาเกิดเหตุขัดข้องใหญ่ของบริการคลาวด์รายใหญ่ มันอธิบายกับหัวหน้าหรือนักลงทุนได้ง่ายกว่าเยอะ แต่ถ้าบอกว่า downtime สะสมเท่ากันเกิดจากความผิดพลาดของคนในทีม มันอธิบายยากกว่ามาก
ถ้าอย่างนั้นก็สงสัยว่ามันสอดคล้องกับการตีความว่าคลาวด์เป็นแพะรับบาปอย่างไร
ถ้าจะเน้นการขยายแนวตั้ง ทำไมต้องเป็น SQLite? ก็ไม่มีอะไรห้ามไม่ให้รัน Postgres หรือ Supabase แบบ self-host ร่วมกับแอปบนเซิร์ฟเวอร์เดียวกัน และนอกจากต้องลงแรงตั้งค่ามากขึ้น ก็แทบไม่ค่อยนึกข้อเสียอื่นออก
ถ้าไม่ใช้ DB เลย แล้วเก็บ state ส่วนกลางทั้งหมดไว้ในหน่วยความจำจริงของเซิร์ฟเวอร์ใหญ่เพียงเครื่องเดียว รักษาไว้เป็นอ็อบเจ็กต์ภายในโปรเซสโดยไม่ต้องวิ่งไปกลับกับ Redis ทำ snapshot หน่วยความจำลงดิสก์เป็นครั้งคราว และใช้ภาษาคอมไพล์แบบมัลติเธรด ก็อาจให้บริการคนทั้งโลกจากเครื่องเดียวได้พร้อมใช้ NIC เกิน 1Gbit จนเต็ม
ก็แอบคิดเหมือนกันว่าอยากเห็นกรณีใช้งานจริงที่ใช้สถาปัตยกรรมแบบนั้น
นอกเหนือจากแพตเทิร์น persistence เชิงสัมพันธ์แบบมาตรฐาน ความต่างด้านความสามารถอาจมากจน Postgres เหมาะกว่า แต่ในบางแพตเทิร์นสถาปัตยกรรม SQLite ก็อาจเหนือกว่าได้
สำหรับแอปที่เน้นคอนเทนต์อย่าง BusinessInsider แพตเทิร์น Baked Data ที่อิง SQLite อาจดีกว่าในแง่ต้นทุนและ latency
simonw (datasette) ได้ทำทั้งเครื่องมือและบทความจำนวนมากเกี่ยวกับการใช้ SQLite ใน production สำหรับเว็บไซต์ที่เน้นคอนเทนต์หรือมีข้อมูลหนาแน่น: https://simonwillison.net/2021/Jul/28/baked-data/
ก็สมเหตุสมผล เพราะ SQLite รันอยู่ในโปรเซสและไม่ต้องมีการ serialize อีกทั้งยังมีข้อดีเพิ่มคือทำงานแบบ serial ได้ ทำให้การทดสอบ การให้เหตุผล และการสร้างชั้น cache ง่ายขึ้นมาก
ถ้าไม่ใช้ Unix socket ก็ยังมี network overhead อยู่ แต่ในเมื่อพูดถึงเซิร์ฟเวอร์เดียวกัน ก็ปล่อยให้เป็นประเด็นรองไปก่อน ในโลกจริงก็พบบ่อยมากที่วาง Postgres ไว้อีกเครื่องเพื่อการแยกส่วน และนั่นก็เป็นหนึ่งในข้อดีหลักของฐานข้อมูลผ่านเครือข่ายด้วย
ฟีเจอร์ที่ต้องใช้ก็มีครบ แถมเรียบง่ายและเร็วกว่า SQLite จัดการข้อมูลระดับเทราไบต์ การอ่านหลายทาง และ real-time streaming backup ได้ และโดยรวมก็เป็น implementation ของ SQL ที่สมดุลมากพอสมควร
คงจะพิจารณา Postgres/MySQL ก็ต่อเมื่อต้องก้าวข้ามการขยายแนวตั้งบนเครื่องเดียวเท่านั้น
https://blog.cloudflare.com/introducing-d1
ดูเหมือนหลายคนจะรู้สึกว่าพอผู้เขียนโฟกัสที่ latency, bandwidth และต้นทุน ก็ต้องออกมาปกป้องสถานะปัจจุบันด้วยเหตุผลเรื่อง availability และ reliability
ข้อสรุปของผมไม่ใช่ว่าจะปฏิเสธข้อดีของคลาวด์เมื่อเจอกับ trade-off แต่คืออยากตั้งคำถามว่าทุกวันนี้ แพตเทิร์นสถาปัตยกรรมคลาวด์ ที่มีอยู่ทั่วไปพร้อมข้อผูกมัดที่ตามมานั้นจำเป็นจริงหรือไม่
การเปรียบเทียบสิ่งนี้กับสิ่งนั้นเป็นเพียงกลวิธีเชิงวาทศิลป์เพื่อแนะนำทางเลือก และโซลูชันไหนเหมาะก็ขึ้นอยู่กับปัจจัยมากมายตามลักษณะงาน ซึ่งก็เป็นเหตุผลนั่นเองที่วิศวกรยังมีงานทำ
แต่ถึงอย่างนั้น แม้อยู่ในแพตเทิร์นที่ผู้เขียนเสนอ ก็ยังจัดการข้อกังวลของฝั่ง SRE ได้ “ถ้าเซิร์ฟเวอร์เครื่องเดียวตายแล้ว availability จะทำยังไง?” ค่อนข้างเป็นการโจมตีหุ่นฟาง เพราะ availability สามารถแก้ได้ด้วยวิธีที่ต่างจากระบบที่เราคุ้นเคย และทางแก้ก็ควรสอดคล้องกับสิ่งที่สำคัญจริงๆ
มีวิธีที่เพิ่มขึ้นมาอีกขั้นเดียวแต่ได้อะไรอีกมากภายใต้งบแบบประหยัด นั่นคือวาง API กับฐานข้อมูล SQLite ไว้ด้วยกัน
ในอุดมคติ API ควรใช้ฟอร์แมต serialization แบบไบนารีที่มี overhead ต่ำและใช้การเชื่อมต่อแบบ persistent ส่วนการเสิร์ฟเว็บก็ใช้ประโยชน์จาก free tier ของบริการ edge ที่ได้รับทุน VC แล้วเผาเงินเล่น ตอนนี้ Cloudflare Workers ค่อนข้างใจกว้างและทราฟฟิกขาออกก็ฟรี
ประเด็นสำคัญคือ SQLite สามารถรองรับจำนวน query ต่อวินาทีมหาศาลได้แม้จะเป็น single-thread ก็ตาม คุณสามารถอัดงานจำนวนมากให้ประมวลผลแบบ serial ได้ จึงให้เหตุผลง่าย และทำให้ memory caching กับ invalidation ฝั่ง API ง่ายตามไปด้วย
ถ้าแยก web serving ออกมา ก็จะได้ประโยชน์จากประสิทธิภาพฝั่ง edge สำหรับ handshake และในหน้าสแตติกก็ข้าม DB ไปได้เลย บทความนี้ประเมินปัญหา round-trip time ต่ำเกินไป แต่แอปจริงมักต้องการ round trip มากกว่าที่คิด ปัญหานี้จึงค่อนข้างเกิดขึ้นจริง
การใช้ CPU ส่วนใหญ่นอก DB มาจาก parsing, deserialization, การคัดลอกข้อมูล และ TLS ดังนั้นถ้าตัดก้อนใหญ่พวกนี้ออกได้ ก็อาจได้การเขียนระดับหลายหมื่นครั้งต่อวินาทีบนเครื่องสเปกบ้านๆ แบบสบายๆ และการอ่านก็จะเร็วกว่าอีก
ถึงอย่างนั้น bottleneck แบบคลาสสิก โดยเฉพาะ I/O ก็ยังควร benchmark เสมอ ผู้ให้บริการมักพูดเกินจริงหรือชวนให้เข้าใจผิด จึงควรลองรันเองบน free tier และก็ควรเตรียม integration test กับ benchmark ไว้ด้วยเผื่อต้องย้ายในภายหลัง
ถ้าผลลัพธ์มีขนาดใหญ่ก็ค่อนข้างดี แต่ก็หวังว่า PostgreSQL เองจะไม่ไปติดคอขวดตอนสร้าง JSON จาก dataset ขนาดใหญ่
ผู้คนบอกว่าต้องอยู่ที่ edge ต้องอยู่ใกล้ผู้ใช้ และต้องลด latency
ในความเป็นจริง latency เป็นปัญหาใหญ่แค่ไหนกัน?
โปรเจกต์แนะนำหนังสือ Gnooks ที่รันบนเซิร์ฟเวอร์ในเยอรมนีเป็นตัวอย่าง: https://www.gnooks.com
เลยสงสัยว่ามันช้าจนมีใครรู้สึกว่าช้าเกินไปไหม
ตลอดหลายปีที่ผ่านมา โปรเจกต์นี้ได้รับข้อเสนอแนะจากผู้ใช้นับพันครั้ง แต่เท่าที่จำได้ ไม่เคยมีใครหยิบเรื่อง latency ขึ้นมาพูดเลย ทั้งที่กลุ่มผู้ใช้ใหญ่ที่สุดอยู่ในสหรัฐฯ
เพราะอย่างนั้นจึงเจอปัญหา latency น้อยกว่า PWA แบบสมัยนี้มาก ที่เอา logic ส่วนใหญ่ไปไว้ที่ frontend แล้วส่ง query หลายครั้งไปที่ backend เพื่อดึงข้อมูลที่ต้องใช้
ถึงอย่างนั้นตัวเว็บเองก็ยังโอเค ปัญหาจะเกิดก็ต่อเมื่อเว็บนั้นช้าอยู่แล้ว
ถ้าทำแบบนั้นจากยุโรป จะได้ latency ประมาณ 2 เท่าของที่ผู้ใช้ออสเตรเลียเห็น ซึ่งช่วยให้ประเมินประสบการณ์ที่แย่ที่สุดได้
ข้อดีคือสามารถทดสอบเรื่องนี้อย่างน่าเชื่อถือ เพื่อดูว่ามันสำคัญจริงไหม แล้วก็จะได้คำตอบที่เฉพาะเจาะจง
บทความไม่ได้พูดถึงเรื่อง availability เลยแม้แต่น้อย บริการที่รันบนกล่องเดียวมีได้ทั้ง downtime ที่วางแผนไว้และ downtime ที่ไม่คาดคิด
ต้องคิดถึง RPO/RTO ด้วย ตอนที่กล่องพัง หรือจริง ๆ คือถ้ามันพัง จะใช้เวลาฟื้นฟูนานแค่ไหนและจะเสียข้อมูลไปเท่าไร
สำหรับประโยคที่ว่าถ้ามี database query แม้แต่ครั้งเดียวในการ render หน้า ก็ต้องกลับไปหา DB ใน us-east-1 นั้น ยังมีตัวเลือกแบบนี้อยู่:
https://aws.amazon.com/rds/aurora/global-database/
https://aws.amazon.com/dynamodb/global-tables/
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce...
https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
ยังมีอย่างอื่นคล้ายกันอีกมาก และถ้าจะประกอบอะไรทำนองนี้ขึ้นมาเองแบบปะติดปะต่อก็คงเหนื่อยไม่น้อย
ถ้าเป็นเมื่อ 10~20 ปีก่อนก็คงเห็นด้วย อินเทอร์เน็ตยังใหม่อยู่ ถ้าเว็บไซต์ล่มคนก็จะโทษเว็บนั้น และสถานการณ์มักจะบานปลายอย่างรวดเร็ว แต่ตอนนี้คนมักจะโทษผู้ให้บริการอินเทอร์เน็ตก่อน หรือไม่ก็กลับมาลองใหม่ทีหลังมากกว่า
ไม่ใช่ทุกคนจะเป็น Google และระบบที่เรียบง่ายกว่าก็มีโอกาสล้มน้อยกว่าตั้งแต่แรกด้วย แค่ดูแล backup ไว้ และถ้ากังวลจริง ๆ ก็ replicate DB ไปยัง cold disaster recovery site ก็พอแล้ว สำหรับบริษัทและสถานการณ์ส่วนใหญ่ที่ไม่ใช่ FAANG นี่ถือว่าเพียงพอ
ตราบใดที่ไม่สูญเสียข้อมูล สำหรับหลายบริษัทมันก็เป็นแค่การสะดุดสั้น ๆ ถ้าการประชาสัมพันธ์ดีและเป็นเหตุการณ์ที่เกิดขึ้นน้อยมาก ต่อให้ล่มเป็นวัน ๆ ก็ยังรับมือได้ และในบางกรณีก็อาจรับการสูญเสียข้อมูลได้ด้วย
เคยมีคำพูดว่าทุกครั้งที่เพิ่มเลข 9 ให้ reliability อีกหนึ่งตัว ต้นทุนจะเพิ่มเป็นสองเท่า ซึ่งต้องเอาไปคิดใน ROI ด้วยเสมอ ความน่าเชื่อถือที่ธุรกิจต้องการจริง ๆ ขึ้นอยู่กับตลาดเป้าหมาย และผมคิดว่าคำตอบแบบพื้นฐานของสาย IT ที่ชอบตั้งเป็น 100% อัตโนมัตินั้นไม่ถูกต้อง
โมเดลเซิร์ฟเวอร์เดี่ยวหรือเซิร์ฟเวอร์คู่ก็มีความซับซ้อนต่ำกว่ามาก และเพราะอย่างนั้นแม้แต่ทีมปฏิบัติการอย่าง LetsEncrypt ก็เลือกใช้ สถาปัตยกรรมเซิร์ฟเวอร์จริงแบบคู่ นี้เพื่อให้บริการระดับโลกที่เว็บสเกลได้: https://letsencrypt.org/2021/01/21/next-gen-database-servers...
ด้วย internal latency ที่ต่ำมากของ DB ที่อยู่ในเครื่องเดียวกันหรืออยู่ติดกัน ซอฟต์แวร์จึงรัน database query ได้เร็วกว่าเป็นหลักหลายเท่า ใช้ทรัพยากรต่อผู้ใช้น้อยกว่า และมอบประสบการณ์ผู้ใช้ที่ลื่นไหลกว่าบริการ managed DB จริง ๆ ได้
ความซับซ้อนสร้างกับดักของมันเอง และผมคิดว่าไม่มีเว็บเซอร์วิสไหนที่ไม่เคยทำพลาดเรื่องนี้เลย แม้แต่ AWS เองก็ยังมี incident
จึงบอกไม่ได้ว่า VPS จะแย่กว่าในเรื่องนี้