ปี 2023 เกียรติยศอยู่ห่างออกไปเพียง 11MB/วินาที

 (thmsmlr.com)
2 คะแนน โดย GN⁺ 2024-04-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ความจริงเกี่ยวกับต้นทุนคลาวด์

  • แม้จะมีความเชื่อว่าบริการคลาวด์มีราคาถูก แต่ในความเป็นจริงผู้ใช้อาจจ่ายแพงเกินความจำเป็น
  • AWS สร้างกำไรส่วนใหญ่ให้ Amazon แต่สิ่งนี้ก็อาจหมายความได้ว่าบริการคลาวด์นั้นมีราคาแพงจริง

การคำนวณจากหลักการพื้นฐาน

  • หากต้องการสร้างเว็บไซต์ให้ติดอันดับหนึ่งใน 1000 เว็บไซต์ชั้นนำ เช่น businessinsider.com ก็ต้องรองรับผู้เข้าชม 200M ครั้งต่อเดือนและ 400M page views
  • แค่เอกสาร HTML อย่างเดียวก็ต้องใช้แบนด์วิดท์ 30TB ต่อเดือน แต่คิดเป็นเพียง 11MB/วินาทีเท่านั้น ซึ่งถือเป็นเกณฑ์ที่ต่ำมากสำหรับฮาร์ดแวร์สมัยใหม่

ทำความเข้าใจเรื่อง latency

  • หากคิดตามความเร็วแสง การเดินทางไป-กลับถึงอีกฟากของโลกต้องใช้เวลาประมาณ 200ms แต่ในความเป็นจริงจะอยู่ที่ราว 300ms
  • หากใช้ CDN เพื่อส่ง JS, CSS และสื่อ ก็สามารถลดเวลาในการประมวลผลของเซิร์ฟเวอร์ลงได้ 300ms ซึ่งให้ผลใกล้เคียงกับการมีเซิร์ฟเวอร์อยู่ข้างผู้ใช้

ข้อจำกัดของเทคโนโลยี edge

  • เทคโนโลยี edge ยังแก้ปัญหาเรื่องฐานข้อมูลไม่ได้ แม้ serverless รุ่นที่สองจะพัฒนาขึ้นมากแล้วก็ตาม
  • หน้าส่วนใหญ่ที่มีความซับซ้อนต้องอาศัยการ query ฐานข้อมูล ซึ่งอาจเพิ่ม latency ได้

การพิจารณาเรื่องต้นทุน

  • Hetzner.com ให้ค่าใช้จ่ายด้านเซิร์ฟเวอร์และแบนด์วิดท์ที่ถูกกว่า AWS EC2 อย่างมาก
  • ผู้ให้บริการคลาวด์มักแจกของฟรีจำนวนมากในช่วงแรก แต่เมื่อขยายระบบ ค่าใช้จ่ายจะเพิ่มขึ้นอย่างมาก

สถานการณ์ที่สมจริง

  • หากไม่ใช่ use case เฉพาะทาง เว็บไซต์หรือ SaaS ส่วนใหญ่สามารถรันบนเซิร์ฟเวอร์เครื่องเดียวได้ ซึ่งทั้งถูกกว่าและดูแลง่ายกว่า
  • สามารถใช้ SQLite แบบ local, cache CSS, JS และรูปภาพผ่าน CDN และเพิ่มประสิทธิภาพด้วย server-side rendering ได้
  • แม้ไม่มี Docker หรือ virtualization ที่ซับซ้อน ก็ยังขยายระบบได้เพียงพอ พร้อมทั้งจัดการง่ายและประหยัดกว่า

ความเห็นของ GN⁺

  • บทความนี้ท้าทายความเชื่อทั่วไปเรื่องความคุ้มค่าของบริการคลาวด์ และชี้ว่าผู้ใช้อาจกำลังจ่ายเงินมากกว่าที่จำเป็นจริง
  • เมื่อเทียบกับโครงสร้างต้นทุนของบริการคลาวด์ ก็แสดงให้เห็นว่าการโฮสต์แบบเซิร์ฟเวอร์เดี่ยวดั้งเดิมยังอาจเป็นทางเลือกที่ใช้ได้จริง
  • บทความนี้เน้นว่าเทคโนโลยีอย่าง serverless, Docker และ horizontal scalability ไม่ได้จำเป็นกับทุกสถานการณ์ และบางครั้งแนวทางที่เรียบง่ายกว่ากลับให้ทั้งประสิทธิภาพและการประหยัดต้นทุนที่ดีกว่า
  • บทความนี้เน้นความสำคัญของการปรับแต่งฐานข้อมูลและการวางระบบตามภูมิภาค ซึ่งบ่งชี้ว่าสามารถบรรลุประสิทธิภาพที่เทียบเท่าหรือดีกว่าคลาวด์ได้
  • ปัจจัยที่ควรพิจารณาในการเลือกเทคโนโลยีคือการประเมินทราฟฟิกจริงและความต้องการด้านประสิทธิภาพ รวมถึงพิจารณาความคุ้มค่าต่อต้นทุน เพื่อชั่งน้ำหนักการใช้เซิร์ฟเวอร์โฮสต์แบบดั้งเดิมแทนคลาวด์

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

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

 
GN⁺ 2024-04-08
ความเห็นจาก Hacker News

  • ประสบการณ์ในธุรกิจโฮสติ้ง

    • ในอดีต ธุรกิจโฮสติ้งได้ให้ระบบที่ซับซ้อนตามความต้องการของลูกค้า
    • ได้พัฒนาแพลตฟอร์มคลาวด์โฮสติ้งแบบ API เพื่อตอบโต้ AWS แต่รายได้แตะจุดสูงสุดในปี 2012
    • ลูกค้าต้องการโซลูชันที่ซับซ้อนกว่าซึ่งสร้างบน AWS และไม่ไว้วางใจเซิร์ฟเวอร์แบบเรียบง่าย
    • บริษัทดำเนินงานแบบ bootstrap และไม่เข้าใจความจำเป็นของการยอมรับความเสี่ยงด้านต้นทุนของ AWS
    • AWS เป็นที่นิยมเพราะรากฐานของความ "ฉลาดแพรวพราว" ที่ฝังลึกอยู่ในหมู่นักพัฒนาซอฟต์แวร์รุ่นหนึ่ง

  • ข้อผิดพลาดในการวิเคราะห์ทราฟฟิก

    • ทราฟฟิกไม่ได้กระจายอย่างสม่ำเสมอ และความต้องการแบนด์วิดท์ในช่วงพีคสูงกว่าค่าเฉลี่ยมาก
    • ในบริการจริง การตั้งค่าการเชื่อมต่อ TCP และ TLS ต้องใช้การรับส่งหลายรอบ และเวลาในการตอบสนองมีความสำคัญต่อประสบการณ์ผู้ใช้

  • ข้อผิดพลาดของเซิร์ฟเวอร์และทราฟฟิก

    • 500 Internal Server Error บ่งชี้ว่าเซิร์ฟเวอร์กำลังรับทราฟฟิกมากกว่าที่คาดไว้

  • แนวทางต่อการขยายบริการ

    • ควรหลีกเลี่ยงการขยายระบบที่ไม่จำเป็น และสร้างเมื่อจำเป็นจริงเท่านั้น
    • เมื่อเกิดปัญหาด้านประสิทธิภาพค่อยรับมือในตอนนั้นจะดีกว่า

  • ข้อดีของ AWS

    • การใช้ AWS เปิดช่องให้มีข้ออ้างได้เมื่อบริการล่ม

  • การถกเถียงเกี่ยวกับสถาปัตยกรรมคลาวด์

    • นี่ไม่ใช่การโต้เถียงเรื่องความจำเป็นของสถาปัตยกรรมคลาวด์ แต่เป็นวิธีในการนำเสนอทางเลือก
    • ปัญหาความพร้อมใช้งานเมื่อเซิร์ฟเวอร์ล่มสามารถแก้ไขได้ด้วยวิธีอื่น

  • SQLite และการสเกลแนวตั้ง

    • แทนที่จะใช้ SQLite สามารถใช้ Postgres ที่โฮสต์เองได้ แต่จะต้องใช้ความพยายามในการตั้งค่ามากกว่า
    • สถาปัตยกรรมที่เก็บสถานะส่วนกลางทั้งหมดไว้ในหน่วยความจำและบันทึก snapshot ลงดิสก์ก็เป็นไปได้

  • การผสาน API กับฐานข้อมูล SQLite

    • SQLite สามารถจัดการคิวรีจำนวนมากได้ในเธรดเดียว
    • ฝั่ง API สามารถใช้ memory caching และข้ามฐานข้อมูลสำหรับหน้าสแตติกเพื่อเพิ่มประสิทธิภาพได้

  • ปัญหาความพร้อมใช้งานของเซิร์ฟเวอร์เดี่ยว

    • หากรันบริการบนเซิร์ฟเวอร์เพียงเครื่องเดียว อาจเกิด downtime ที่ไม่ได้วางแผนไว้
    • ต้องคำนึงถึงเวลาในการกู้คืนข้อมูลและปริมาณข้อมูลที่สูญหาย

  • การย้ายไปคลาวด์และความพร้อมใช้งาน

    • การย้ายไปคลาวด์มักให้ความรู้สึกเหมือนแรงกดดันจากคนรอบข้าง
    • ในมุมของความพร้อมใช้งาน เซิร์ฟเวอร์เดี่ยวอาจมีความเสี่ยง และควรผสมการใช้ CDN กับคลาวด์อย่างชาญฉลาด