นวัตกรรมอย่างต่อเนื่อง: ประวัติย่อของบล็อกสตอเรจบน AWS

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

นวัตกรรมอย่างต่อเนื่อง: ประวัติย่อของบล็อกสตอเรจบน AWS

  • บทนำ

    • Marc Olson ทำงานอยู่ในทีม Elastic Block Store (EBS) มานานกว่า 10 ปี
    • EBS ได้พัฒนาจากบริการบล็อกสตอเรจที่เรียบง่าย ไปสู่ระบบเน็ตเวิร์กสตอเรจขนาดใหญ่ที่ประมวลผลงานมากกว่า 140 ล้านล้านรายการต่อวัน
    • บทความนี้แบ่งปันเส้นทางวิวัฒนาการของ EBS และบทเรียนสำคัญที่ได้รับ

  • ประวัติช่วงแรกของ EBS

    • EBS เปิดตัวเมื่อวันที่ 20 สิงหาคม 2008 โดยเริ่มต้นจากแนวคิดง่าย ๆ ในการให้บริการบล็อกสตอเรจที่เชื่อมต่อผ่านเครือข่ายสำหรับ EC2 instance
    • ในช่วงแรกใช้ฮาร์ดดิสก์ไดรฟ์แบบแชร์ (HDD) และปัจจุบันสามารถให้ประสิทธิภาพระดับหลายแสน IOPS แก่ EC2 instance เดียวได้
    • ปัจจุบัน EBS ประมวลผลงานมากกว่า 140 ล้านล้านรายการต่อวันผ่าน distributed SSD fleet

  • ทฤษฎีคิว

    • วิธีที่ระบบคอมพิวเตอร์โต้ตอบกับสตอเรจนั้นโดยพื้นฐานแล้วยังไม่ได้เปลี่ยนแปลง
    • CPU จะนำคำขอเข้าไปใส่ในคิว ส่วนอุปกรณ์สตอเรจจะดึงข้อมูลจากหน่วยความจำของ CPU ไปเก็บลงบนสื่อที่คงทน หรือส่งข้อมูลกลับไปยังหน่วยความจำของ CPU
    • ทฤษฎีคิวมีบทบาทสำคัญในการทำความเข้าใจกระบวนการเหล่านี้

  • การเปลี่ยนผ่านจาก HDD ไปสู่ SSD

    • EBS ในยุคแรกใช้ HDD ซึ่งมีข้อจำกัดด้านประสิทธิภาพจากขีดจำกัดทางกายภาพ
    • เมื่อ SSD ปรากฏขึ้น คำขอแบบสุ่มก็สามารถประมวลผลได้เร็วเกือบเท่าคำขอแบบลำดับ
    • ในปี 2012 มีการเปิดตัว storage server type ใหม่ที่ใช้ SSD และ EBS volume type ใหม่ชื่อ Provisioned IOPS

  • การวัดและการจัดการ

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

  • การแบ่งองค์กรแล้วพิชิตปัญหา

    • มีการปรับโครงสร้างทีม storage server ของ EBS ให้เป็นทีมขนาดเล็กที่โฟกัสเฉพาะด้าน เช่น data replication, durability และ snapshot hydration
    • แต่ละทีมสามารถทำซ้ำและ commit การเปลี่ยนแปลงได้อย่างอิสระ

  • ท้าทายสมมติฐานเดิม

    • ทีมค้นพบว่าการตั้งค่าพื้นฐานของ Xen hypervisor เป็นตัวจำกัดประสิทธิภาพ
    • จึงใช้ Nitro offload card เพื่อ offload งานประมวลผลด้านเครือข่ายและสตอเรจไปยังฮาร์ดแวร์

  • การทดลองปรับแต่งเครือข่าย

    • เมื่อย้าย EBS ไปยัง Nitro ค่า overhead ของเครือข่ายเองกลับเพิ่มขึ้น
    • ทีมจึงพัฒนาโปรโตคอล SRD (Scalable Relatable Diagram) ขึ้นแทน TCP เพื่อปรับปรุงประสิทธิภาพเครือข่าย

  • ข้อจำกัดผลักดันนวัตกรรม

    • เพื่อมอบข้อดีของ SSD ให้ลูกค้าทุกคน ทีมได้เพิ่ม SSD เข้าไปโดยไม่ต้องเปลี่ยนฮาร์ดแวร์เดิมทั้งหมด
    • มีการเพิ่ม SSD เข้าไปในเซิร์ฟเวอร์ด้วยมือ บันทึกการเขียนใหม่ลง SSD ก่อน แล้วค่อย flush แบบ asynchronous ไปยัง HDD

  • การทบทวนเรื่องการขยายประสิทธิภาพ

    • มีเรื่องราวการเติบโตส่วนบุคคล: การเปลี่ยนผ่านจากวัฒนธรรมบริษัทขนาดเล็กไปสู่องค์กรขนาดใหญ่
    • การทำ debugging session ร่วมกับเพื่อนร่วมงานช่วยแก้ปัญหาและเพิ่มประสิทธิภาพของทีม

  • บทสรุป

    • EBS พัฒนามาได้ไม่ใช่จากการเปลี่ยนแปลงครั้งใหญ่เพียงครั้งเดียว แต่จากการปรับปรุงแบบค่อยเป็นค่อยไปอย่างต่อเนื่อง
    • ความต้องการของลูกค้าจะยังเพิ่มขึ้นต่อไป และสิ่งนี้เป็นแรงผลักดันให้เกิดนวัตกรรมและการทำซ้ำอย่างต่อเนื่อง

# สรุปโดย GN⁺

  • บทความนี้นำเสนอมุมมองจากคนวงในเกี่ยวกับการที่ EBS ของ AWS พัฒนามาได้อย่างไร
  • ครอบคลุมทั้งความท้าทายทางเทคนิคและวิธีแก้ไข เช่น ทฤษฎีคิว การนำ SSD มาใช้ และการปรับแต่งเครือข่าย
  • เน้นย้ำความสำคัญของการวัดผลและการจัดการอย่างต่อเนื่องเพื่อปรับปรุงประสิทธิภาพ
  • ผลิตภัณฑ์ที่มีความสามารถใกล้เคียงกัน ได้แก่ Google Cloud Persistent Disk และ Microsoft Azure Disk Storage

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

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

 
GN⁺ 2024-08-23
ความคิดเห็นบน Hacker News

  • ถ้าคุณสนใจระบบขนาดใหญ่ ก็ควรอ่านบทความนี้

    • ประสิทธิภาพของฮาร์ดไดรฟ์ขึ้นอยู่กับทรานแซกชันอื่น ๆ ที่อยู่ในคิว
    • สำหรับงานแบบสุ่มขนาด 4kB ประสิทธิภาพอาจลดลงอย่างมาก
    • การจัดคิวและการจัดตารางช่วยได้ แต่ประสิทธิภาพจริงอาจแตกต่างกันมากกว่า 100 เท่าตามลักษณะเวิร์กโหลด
    • ในระบบหลายผู้เช่า มีความท้าทายเป็นพิเศษ โดยเฉพาะงานอ่าน

  • หากต้องการแก้ปัญหา ต้องรู้ก่อนว่าอะไรผิดพลาด

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

  • โปรเจ็กต์ติดตั้ง SSD ในเซิร์ฟเวอร์ EBS เมื่อปี 2013 เป็นหนึ่งในเรื่องราวที่น่าสนใจของ AWS

    • ระบบถูกออกแบบตั้งแต่ต้นโดยคำนึงถึงเหตุการณ์บำรุงรักษาแบบไม่ทำลายระบบ
    • เมื่อสร้างระบบกระจาย ก็สามารถปฏิบัติการในระดับขนาดใหญ่ได้

  • เหตุขัดข้องของ AWS ที่ยาวราว 4 วันเกิดจาก EBS และทำให้ความเชื่อมั่นต่อ AWS สั่นคลอน

    • ส่งผลให้มีการลงทุนใน EBS เพิ่มขึ้น
    • ช่วงเวลาดังกล่าวยังตรงกับตอนที่ Apple กำลังจะมาเป็นลูกค้า

  • Reddit เป็นหนึ่งในผู้ใช้ EBS ระยะแรกในปี 2008

    • พยายามเพิ่ม IOPS ด้วยการใช้ software RAID แต่ประสิทธิภาพไม่สม่ำเสมอ
    • ใช้เวลาพอสมควรในการแก้ปัญหาของ RAID
    • Netflix ไม่ได้ใช้ EBS

  • การเพิ่ม latency แบบสุ่มให้ผลช่วยลดทั้ง latency เฉลี่ยและค่าผิดปกติ

  • การทำงานในบริษัทอินเทอร์เน็ตขนาดใหญ่ให้บทเรียนมากมาย

    • กระบวนการฝึกงานแบบช่างฝึกหัดช่วยให้เรียนรู้ความรู้และทักษะสำคัญได้อย่างรวดเร็ว
    • ตอนสัมภาษณ์งาน ประสบการณ์และคำแนะนำจากเมนเทอร์มีประโยชน์มาก

  • ส่วนที่บอกว่ามีการติดตั้ง SSD ด้วยมือให้กับทุกยูนิต EBS ในปี 2013 น่าสนใจมาก

    • ระหว่างปี 2010-2012 ประสิทธิภาพ I/O เป็นประเด็นสำคัญมาก

  • มีการบรรยายเกี่ยวกับภายในของ Amazon S3 ในปี 2009

    • การบรรยายนี้มีอิทธิพลต่อการพัฒนา EBS

  • ในยุคแรกของคลาวด์ มีการใช้ฮาร์ดแวร์อเนกประสงค์ แต่ตอนนี้ใช้ฮาร์ดแวร์ที่ออกแบบเฉพาะสำหรับแต่ละบริการ

    • AWS ใช้ชิป Graviton, Inferentia, Tranium
    • Google ใช้ TPU และการ์ดความปลอดภัย Titan
    • Azure ใช้ FPGA และ Sphere

  • ไดอะแกรมแรกไม่ถูกต้องหรือล้าสมัย

    • คอมพิวเตอร์สมัยใหม่ส่วนใหญ่เชื่อมต่อ PCIe lane ส่วนใหญ่เข้ากับ CPU โดยตรง
    • นี่เป็นพัฒนาการสำคัญต่อ throughput และ latency ของ I/O

  • กำลังมองหาวิธีที่ดีที่สุดในการจัดเตรียมไดเรกทอรีชุดข้อมูลขนาด 256GB ที่รวดเร็วให้กับ EC2 instance ใหม่

    • ใช้ EBS volume อยู่ แต่การอัปเดตยุ่งยาก
    • EFS ช้าเกินไป
    • SSD แบบ instance storage เป็นแบบชั่วคราว
    • ยังไม่ได้ลอง FSx Lustre