นวัตกรรมอย่างต่อเนื่อง: ประวัติย่อของบล็อกสตอเรจของ AWS
(allthingsdistributed.com)- AWS EBS เริ่มต้นจาก บล็อกสตอเรจแบบเชื่อมต่อผ่านเครือข่าย สำหรับ EC2 และเติบโตจากบริการบน HDD แบบใช้ร่วมกันมาเป็น ฟลีต SSD แบบกระจายศูนย์ ที่ประมวลผลงานมากกว่า 140 ล้านล้านครั้งต่อวัน
- ข้อจำกัดด้านประสิทธิภาพในช่วงแรกไม่ได้มาจากเพียง 120~150 IOPS และค่าหน่วงเฉลี่ย 6~8ms ของ HDD เท่านั้น แต่ยังมาจากปัญหา noisy neighbor ที่เกิดจากเวิร์กโหลดของลูกค้าหลายรายใช้ดิสก์เดียวกันร่วมกัน
- หลังนำ SSD มาใช้ วอลุ่ม Provisioned IOPS ในปี 2012 ให้ได้สูงสุด 1,000 IOPS และค่าหน่วงเฉลี่ยราว 2~3ms แต่คอขวดก็ย้ายไปอยู่ที่เครือข่าย ไฮเปอร์ไวเซอร์ และคิวซอฟต์แวร์
- ทีม EBS วัดและติดตามเส้นทาง IO ทั้งหมด และปรับปรุงทีละเลเยอร์ ตั้งแต่คิวของ Xen, การ offload ด้วย Nitro, การประมวลผลการเข้ารหัสด้วยฮาร์ดแวร์, การปรับแต่ง TCP ไปจนถึง โปรโตคอลขนส่ง SRD
- การยกระดับประสิทธิภาพดำเนินไปด้วยการไมเกรตแบบไม่หยุดบริการ การเปลี่ยนแปลงอิสระโดยทีมขนาดเล็ก การวัดผลอย่างต่อเนื่อง และ การปรับปรุงแบบค่อยเป็นค่อยไป ที่สามารถ rollback ได้ มากกว่าการเขียนระบบใหม่ขนาดใหญ่
จากบล็อกสตอเรจสำหรับ EC2 สู่ฟลีต SSD ขนาดใหญ่
- EBS เปิดตัวเมื่อวันที่ 20 สิงหาคม 2008 ประมาณ 2 ปีหลังการเปิดตัว EC2 beta โดยเริ่มจากแนวคิดที่จะให้บริการ บล็อกสตอเรจแบบเชื่อมต่อผ่านเครือข่าย สำหรับอินสแตนซ์ EC2
- ในตอนนั้นทีมมีผู้เชี่ยวชาญด้านสตอเรจหนึ่งหรือสองคน และวิศวกรระบบกระจายศูนย์อีกไม่กี่คน เริ่มสร้างบริการจากความรู้ด้านระบบคอมพิวเตอร์และเครือข่าย
- ต่อมา EBS เปลี่ยนจากผลิตภัณฑ์ HDD แบบใช้ร่วมกัน มาเป็นบริการที่สามารถให้ IOPS หลายแสนครั้ง แก่อินสแตนซ์ EC2 เดี่ยวได้
- ปัจจุบัน IOPS ที่ให้ได้กับอินสแตนซ์เดี่ยวสูงกว่าระดับที่เคยให้ได้กับ Availability Zone ทั้งหมดในยุคเริ่มต้นที่ใช้ HDD
- EBS ทั้งระบบประมวลผลงานมากกว่า 140 ล้านล้านครั้งต่อวัน บนฟลีต SSD แบบกระจายศูนย์
- เวิร์กโหลดหลักคือดิสก์ระบบของอินสแตนซ์ EC2 ซึ่งมีลักษณะใกล้เคียงกับการให้สตอเรจผ่านเครือข่ายเพื่อทำหน้าที่แทนฮาร์ดดิสก์ในเซิร์ฟเวอร์จริง
- ลูกค้าให้ความสำคัญกับความทนทานของข้อมูล แต่ ประสิทธิภาพและความพร้อมใช้งาน ที่เชื่อมโยงโดยตรงกับประสบการณ์ใช้งาน EC2 ก็สำคัญในระดับเดียวกัน
- วอลุ่ม io2 Block Express และ volume snapshot ถูกให้เป็นองค์ประกอบพื้นฐานเพื่อให้ได้ความทนทานสูง
- ประสิทธิภาพและความพร้อมใช้งานของวอลุ่ม EBS ส่งต่อไปยังประสบการณ์ของแอปพลิเคชันบน EC2 แทบโดยตรง
ข้อจำกัดช่วงแรกจากคิวและ HDD
- ในระบบคอมพิวเตอร์ คำขอสตอเรจถูกประมวลผลผ่าน คิว หลายจุดระหว่าง CPU, bus และอุปกรณ์
- ในสตอเรจผ่านเครือข่าย จะมีคิวหลายชุดระหว่างเคอร์เนลของระบบปฏิบัติการ, storage adapter, storage fabric, storage adapter ฝั่งปลายทาง และสื่อบันทึกข้อมูล
- เมื่อ EBS ถูกสร้างขึ้นครั้งแรกในปี 2008 ตลาดสตอเรจยังเป็น HDD เป็นหลัก และค่าหน่วงถูกกำหนดโดยตัวสื่อบันทึกข้อมูลเอง
- ฮาร์ดดิสก์เป็นอุปกรณ์เชิงกล จึงมีข้อจำกัดทางกายภาพ
- ตลอดหลายทศวรรษ ประสิทธิภาพของ HDD อยู่ราว 120~150 งานต่อวินาที และค่าหน่วง IO เฉลี่ยประมาณ 6~8ms
- เพราะการเข้าคิวและการจัดลำดับคำสั่งใหม่ภายในไดรฟ์ tail latency อาจยืดไปถึงหลายร้อย ms
- ตอนนั้นค่าหน่วงแบบ end-to-end ของ EBS อยู่ในระดับหลายสิบ ms ดังนั้นระดับหลายสิบไมโครวินาทีที่เพิ่มจากเครือข่ายจึงเป็นสัดส่วนเล็กน้อยของค่าหน่วงทั้งหมด
- ประสิทธิภาพของ HDD ได้รับผลกระทบอย่างมากจากงานอื่นที่สะสมอยู่ในคิว
- คำขอแบบสุ่มขนาดเล็กที่กระจายอยู่บนสื่อบันทึกข้อมูล ใช้เวลาค้นหาและเข้าถึงนานกว่าคำขอขนาดใหญ่หลายรายการที่อยู่ใกล้กัน
- การกระจายลูกค้าไปยังดิสก์หลายลูกช่วยลดค่าหน่วงที่สูงกว่า peak ของเวิร์กโหลดที่ร้อนที่สุด แต่ทำให้พฤติกรรมที่ไม่สม่ำเสมอแพร่ไปยังลูกค้ามากขึ้น
- noisy neighbor ซึ่งเวิร์กโหลดหนึ่งส่งผลกระทบต่ออีกเวิร์กโหลด กลายเป็นปัญหาทางธุรกิจที่สำคัญ
- AWS เห็นว่าจำเป็นต้องมีการแยกประสิทธิภาพอย่างเข้มแข็งเพื่อยกระดับคุณภาพประสบการณ์ของลูกค้า
- การเปลี่ยนอัลกอริทึมจัดตารางของดิสก์และการกระจายเวิร์กโหลดไปยัง spindle จำนวนมากขึ้น เป็นเพียงการปรับปรุงเล็กน้อยแบบค่อยเป็นค่อยไป
ความสำคัญของการวัดและติดตามที่ชัดขึ้นหลังนำ SSD มาใช้
- ราวปี 2011 SSD เริ่มแพร่หลายมากขึ้น และเริ่มมีความจุในระดับที่ AWS พิจารณาใช้งานได้
- SSD ไม่มีการเคลื่อนที่ของแขนกลเพื่อค้นหาข้อมูล คำขอแบบสุ่มทำงานได้เร็วเกือบเท่าคำขอตามลำดับ และมีหลายช่องทางระหว่างคอนโทรลเลอร์กับชิป NAND
- EBS เริ่มด้วยการสร้างสตอเรจเซิร์ฟเวอร์ชนิดใหม่ที่ใช้ SSD และวอลุ่มชนิดใหม่ชื่อ Provisioned IOPS
- การเปิดตัววอลุ่มชนิดใหม่นี้ไม่ใช่งานเล็ก และเวิร์กโหลดที่ใช้ประโยชน์ได้ก็ยังจำกัด
- ตรงข้ามกับความคาดหวังว่าการเปลี่ยน HDD เป็น SSD จะช่วยแก้ปัญหาเกือบทั้งหมด ปัญหา noisy neighbor ไม่ได้หายไปเองโดยอัตโนมัติ
- Provisioned IOPS ที่เปิดตัวในเดือนสิงหาคม 2012 ให้ได้สูงสุด 1,000 IOPS
- สูงกว่าวอลุ่ม EBS standard เดิม 10 เท่า
- ค่าหน่วงเฉลี่ยอยู่ที่ประมาณ 2~3ms ดีขึ้น 5~10 เท่า
- การควบคุม outlier ก็ดีขึ้นมาก
- ณ จุดนี้ EBS มีเพียง telemetry ขั้นพื้นฐาน และต้องการ instrumentation ที่ละเอียดขึ้นเพื่อ判断ว่าควรแก้ส่วนใด
- ทีมสร้างวิธีติดตามทุก IO ในหลายจุด
- EBS client initiator
- network stack
- storage durability engine
- ระบบปฏิบัติการ
- นอกจากการมอนิเตอร์เวิร์กโหลดของลูกค้าแล้ว ยังสร้าง canary test เพื่อตรวจสอบผลกระทบทั้งเชิงบวกและเชิงลบของการเปลี่ยนแปลงกับเวิร์กโหลดที่รู้จักดีอย่างต่อเนื่อง
งานปรับปรุงที่แบ่งระหว่างฮาร์ดแวร์และซอฟต์แวร์
- telemetry ใหม่แสดงให้เห็นพื้นที่ลงทุนในช่วงแรกอย่างชัดเจน
- ต้องลดจำนวนคิวในระบบทั้งหมด
- ยังมีโอกาสลดความซับซ้อนของเส้นทาง IO ของ Xen hypervisor ที่ใช้ใน EC2
- ต้องปรับแต่งซอฟต์แวร์เครือข่าย
- durability engine หลักต้องการการจัดวางข้อมูลบนดิสก์, การปรับให้เหมาะกับ cache line และการรองรับโมเดลโปรแกรมมิงแบบ asynchronous
- ปัญหาประสิทธิภาพของระบบ AWS มักข้ามหลายชั้นของสแต็กฮาร์ดแวร์และซอฟต์แวร์พร้อมกัน
- EBS ให้ทีมสตอเรจเซิร์ฟเวอร์และทีมไคลเอนต์ทำงานคู่ขนานกัน และมีวิศวกร EC2 hypervisor กับกลุ่มประสิทธิภาพเครือข่ายภายใน AWS เข้าร่วมด้วย
- องค์กรพัฒนาถูกแบ่งแบบ divide and conquer เช่นเดียวกับระบบซอฟต์แวร์
- ปรับทีมพัฒนาสตอเรจเซิร์ฟเวอร์แบบโมโนลิธิกให้เป็นทีมขนาดเล็กตามด้านต่างๆ เช่น data replication, durability และ snapshot hydration
- แต่ละทีมสามารถพัฒนาแบบวนซ้ำและนำการเปลี่ยนแปลงเข้าใช้อย่างอิสระ บนฐานของการทดสอบที่เข้มงวด
- พิมพ์เขียวที่สร้างในปี 2013 ไม่ได้เหมือน EBS ในวันนี้ แต่ให้ทิศทางการเดินหน้า
- ตอนนั้นยังไม่ได้คาดว่า Amazon จะสร้าง SSD ของตนเอง ในสักวัน และมีเทคโนโลยีสแต็กที่ปรับให้เข้ากับความต้องการของ EBS
การขจัดคอขวดจาก Xen ไปสู่ Nitro และ SRD
- จนถึงปลายปี 2017 อินสแตนซ์ EC2 ทั้งหมดทำงานบน Xen hypervisor
- เส้นทางอุปกรณ์ของ Xen มี ring queue ที่ guest domain และ dom0 ซึ่งเป็น privileged driver domain ใช้แชร์ข้อมูลกัน และ EBS client ทำงานเป็นอุปกรณ์บล็อกในเคอร์เนลของ dom0
- ก่อนที่คำขอ IO จากอินสแตนซ์จะออกจากโฮสต์ EC2 จะผ่านคิวหลายชุด
- คิวอุปกรณ์บล็อกของอินสแตนซ์
- Xen ring
- คิวอุปกรณ์บล็อกในเคอร์เนลของ dom0
- คิวเครือข่ายของ EBS client
- ทีม EBS เขียน loopback device หลายตัวเพื่อแยกวิเคราะห์ผลกระทบของแต่ละคิว
- แม้ค่าหน่วงของไดรเวอร์อุปกรณ์ใน dom0 จะต่ำมาก แต่ก็พบว่าเมื่อหลายอินสแตนซ์สร้าง IO พร้อมกัน throughput ที่มีผลจริงของทั้งระบบจะช้าลง
- EC2 เปิดตัวด้วยจำนวนคิวอุปกรณ์บล็อกและจำนวน entry ในคิวตามค่าเริ่มต้นของ Xen
- ค่าเริ่มต้นนี้ตั้งตามฮาร์ดแวร์สตอเรจที่จำกัดในสภาพแวดล้อมพัฒนา Xen ในอดีต
- คำขอ IO แบบ outstanding ถูกจำกัดไว้ที่ 64 รายการ ต่อทั้งโฮสต์ ไม่ใช่ต่ออุปกรณ์
- ในปี 2013 มีการพัฒนา Nitro offload card ตัวแรกสำหรับเครือข่ายโดยเฉพาะ
- ย้ายการประมวลผลเครือข่ายแบบ software-defined ของ VPC จากเคอร์เนล Xen dom0 ไปยัง pipeline ฮาร์ดแวร์เฉพาะ
- แยก data plane สำหรับประมวลผลแพ็กเก็ตออกจาก hypervisor ทำให้ไม่ต้องใช้รอบ CPU ของอินสแตนซ์ลูกค้าเพื่อประมวลผลทราฟฟิกเครือข่าย
- แนวทางเดียวกันถูกนำมาใช้กับสตอเรจ EBS
- ย้ายการประมวลผลไปยังฮาร์ดแวร์มากขึ้น เพื่อลดคิวของระบบปฏิบัติการใน hypervisor
- offload งานที่อิง interrupt ทำให้เวลาที่ hypervisor ใช้ประมวลผลคำขอลดลง
- Nitro card ตัวที่สองยังมีความสามารถด้านฮาร์ดแวร์สำหรับจัดการวอลุ่ม EBS แบบเข้ารหัสโดยไม่กระทบประสิทธิภาพ
- แยก key material สำหรับการเข้ารหัสออกจาก hypervisor เพื่อปกป้องข้อมูลลูกค้าเพิ่มเติม
- หลังย้าย EBS ไปยัง Nitro คอขวดย้ายไปอยู่ที่เครือข่ายเอง
- ตรวจสอบพารามิเตอร์ tuning ของ TCP และอัลกอริทึม congestion control สำหรับดาต้าเซ็นเตอร์สมัยใหม่
- เคยมีกรณีที่การเพิ่มค่าหน่วงแบบสุ่มเล็กน้อยให้คำขอของสตอเรจเซิร์ฟเวอร์ทำให้เกิด network smoothing และลดทั้งค่าหน่วงเฉลี่ยกับ outlier
- การ tuning เหล่านี้ไม่ได้ยืนยาวนักเมื่อประสิทธิภาพและขนาดของระบบเพิ่มขึ้นต่อเนื่อง จึงต้องมีการวัดผลและมอนิเตอร์อย่างต่อเนื่องเพื่อป้องกัน regression
- ในปี 2014 งานที่ใช้ Scalable Reliable Datagram(SRD) เริ่มขึ้น โดยมีเป้าหมายให้ดีกว่า TCP
- บทความวิชาการที่เกี่ยวข้องคือ A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
- ข้อกำหนดรวมถึงการปรับปรุงความสามารถในการกู้คืนจากความล้มเหลวและการอ้อมเส้นทาง รวมถึงความง่ายในการ offload ด้วยฮาร์ดแวร์
- ในการออกแบบ SRD มีข้อสังเกตสำคัญสองข้อ
- สามารถโฟกัสที่การออกแบบเครือข่ายดาต้าเซ็นเตอร์ของ AWS ไม่ใช่อินเทอร์เน็ตทั่วไป
- ในสตอเรจ สามารถจัดลำดับการทำงานของคำขอ IO ที่กำลังอยู่ระหว่างส่งใหม่ได้
- จึงหลีกเลี่ยงต้นทุนของ in-order delivery แบบเข้มงวดของ TCP และส่งคำขอต่างๆ ไปหลายเส้นทางเครือข่ายเพื่อให้ทำงานได้เมื่อมาถึง
- SRD ถูกใช้ทั้งกับสตอเรจและเครือข่าย
- ใน Elastic Network Adapter(ENA) Express SRD ช่วยปรับปรุงประสิทธิภาพ TCP stack ของ guest
- สามารถใช้ประโยชน์จากหลายเส้นทางเครือข่าย และลด overflow กับคิวของอุปกรณ์เครือข่ายชั้นกลาง เพื่อให้ใช้งานเครือข่ายได้สูงขึ้น
SSD cache และการไมเกรตแบบไม่หยุดบริการ
- EBS ไม่พอใจกับสภาพที่มีเพียงบางวอลุ่มและลูกค้าบางรายได้ประสิทธิภาพที่ดีกว่า จึงพยายามขยายประโยชน์ของ SSD ให้กว้างขึ้น
- ตอนนั้นมีวอลุ่มลูกค้าแบบ non-provisioned IOPS หลายล้านวอลุ่มทำงานอยู่บนสตอเรจเซิร์ฟเวอร์หลายพันเครื่อง
- บางวอลุ่มในนั้นยังคงมีอยู่จนถึงปัจจุบัน
- วิธีทิ้งและเปลี่ยนฮาร์ดแวร์ทั้งหมดมีต้นทุนสูง
- ใน chassis ของเซิร์ฟเวอร์มีพื้นที่ว่าง แต่ตำแหน่งที่ไม่ขวางการไหลของอากาศระบายความร้อนมีเพียงระหว่าง motherboard กับพัดลม
- SSD มีขนาดเล็กและเบา แต่ต้องไม่สั่นคลอนภายใน chassis และหลังจากได้รับความช่วยเหลือจากนักวัสดุศาสตร์กับการลองผิดลองถูก ก็พบเทป hook and loop fastening สำหรับอุตสาหกรรมที่ทนความร้อน
- ในช่วงหลายเดือนของปี 2013 EBS ใส่ SSD 1 ตัว เข้าไปในเซิร์ฟเวอร์แต่ละเครื่องจากหลายพันเครื่องด้วยมือ
- ฝั่งซอฟต์แวร์มีการเพิ่มการเปลี่ยนแปลงเล็กๆ ให้ staging การเขียนใหม่ลง SSD และส่งผลสำเร็จกลับไปยังแอปพลิเคชัน จากนั้นจึง flush ไปยัง HDD ที่ช้ากว่าแบบ asynchronous
- งานนี้ทำโดยไม่หยุดบริการลูกค้า
- EBS ถูกออกแบบตั้งแต่แรกโดยคำนึงถึง maintenance event แบบไม่หยุดบริการ
- สามารถ retarget วอลุ่ม EBS ไปยังสตอเรจเซิร์ฟเวอร์ใหม่ แล้วอัปเดตหรือสร้างเซิร์ฟเวอร์ว่างใหม่ได้
- ความสามารถในการย้ายวอลุ่มลูกค้าไปยังสตอเรจเซิร์ฟเวอร์ใหม่มีประโยชน์อีกหลายครั้งในภายหลัง
- ใช้เมื่อนำโครงสร้างข้อมูลที่มีประสิทธิภาพมากขึ้นสำหรับรูปแบบบนดิสก์มาใช้
- ใช้เมื่อต้องเปลี่ยนฮาร์ดแวร์เก่าเป็นฮาร์ดแวร์ใหม่ด้วย
- วอลุ่มบางรายการที่สร้างขึ้นในช่วงไม่กี่เดือนแรกหลัง EBS เปิดตัวในปี 2008 ยัง active อยู่
- วอลุ่มเหล่านี้อาจผ่านเซิร์ฟเวอร์ที่แตกต่างกันหลายร้อยเครื่องและฮาร์ดแวร์หลายเจเนอเรชันมาแล้ว
- การอัปเดตและสร้างฟลีตใหม่เกิดขึ้นโดยไม่กระทบเวิร์กโหลดเหล่านั้น
แนวทางผู้นำที่สอดรับกับการขยายประสิทธิภาพ
- ขนาดของ EBS แตกต่างจากสภาพแวดล้อมของบริษัทขนาดเล็กหรือสตาร์ทอัพเดิมๆ ไม่ใช่แค่ด้านเทคนิค แต่รวมถึงด้านองค์กรด้วย
- หากผู้เชี่ยวชาญระบบต้องเข้าไปเกี่ยวข้องกับทุก escalation, commit review และการตรวจทานการเปลี่ยนแปลงด้านออกแบบ ก็อาจกลายเป็น คอขวดด้านประสิทธิภาพ ขององค์กร
- เพื่อแก้ปัญหานี้ จึงมีการทดลองไม่ใช่แค่ในโค้ด แต่รวมถึงวิธีทำงานร่วมกันด้วย
- เครื่องมือสำคัญอย่างหนึ่งคือ peer debugging
- วิศวกรหลายคนดูโค้ดและเทอร์มินัลร่วมกันเพื่อตามรอยปัญหา
- พบกรณีที่ตำแหน่งและวิธีการ locking สำหรับการอัปเดต critical data structure เป็นปัญหา
- โดยทั่วไปปัญหานี้ไม่ปรากฏให้เห็น แต่บางครั้งการตอบสนองของคำขอจะช้าลง และการแก้ไขช่วยขจัดสาเหตุหนึ่งของ jitter ได้
- การให้อำนาจวิศวกรทดลองได้อย่างปลอดภัย ลดอุปสรรค แต่ยังคง guardrail ไว้ เป็นแนวทางที่นำไปสู่ผลลัพธ์ที่ดีกว่าได้
การปรับปรุงต่อเนื่องมากกว่าการเขียนใหม่ครั้งใหญ่
- การปรับปรุง EBS ไม่ได้เป็นการเปลี่ยนแปลงยักษ์ครั้งเดียว แต่เป็นชุดของ การปรับปรุงแบบค่อยเป็นค่อยไป ต่อเนื่องตามเวลา
- วิธีนี้ช่วยส่งมอบคุณค่าให้ลูกค้าได้เร็วขึ้น และปรับทิศทางตามสิ่งที่เรียนรู้เมื่อเวิร์กโหลดของลูกค้าเปลี่ยนไป
- ประสบการณ์ค่าหน่วงของ EBS ดีขึ้นจากระดับเฉลี่ย มากกว่า 10ms ต่อ IO operation ไปเป็น IO ระดับต่ำกว่ามิลลิวินาที อย่างสม่ำเสมอบนวอลุ่ม io2 Block Express ที่มีประสิทธิภาพสูงสุด
- การเปลี่ยนแปลงนี้ทำได้โดยไม่ต้องนำบริการ offline เพื่อส่งมอบสถาปัตยกรรมใหม่
- ลูกค้ายังคงต้องการประสิทธิภาพมากขึ้นเรื่อยๆ และความต้องการนั้นคือแรงขับเคลื่อนที่ทำให้ EBS เดินหน้านวัตกรรมและการทำซ้ำอย่างต่อเนื่อง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ดีใจมากที่ได้เห็นบทความนี้ที่นี่ ถ้าสนใจ ระบบขนาดใหญ่ แม้แต่นิดเดียว ก็ควรอ่านอย่างยิ่ง
สำหรับ workload แบบลำดับ ดิสก์แม่เหล็กสมัยใหม่สามารถอ่าน/เขียนได้ มากกว่า 100MB/s แต่สำหรับ workload 4kB แบบสุ่มทั้งหมด อาจตกลงไปเหลือ 400kB/s ได้ แม้การจัดคิวและการจัดตารางจะช่วยเลี่ยงกรณีเลวร้ายที่สุด แต่ประสิทธิภาพจริงก็ยังต่างกันได้มากกว่า 100 เท่าตาม workload ทำให้ระบบแบบ multi-tenant รับมือได้ยากมาก โดยเฉพาะการอ่านนั้นไม่มีทางเลี่ยงแบบ “ก็แค่ไปเขียนที่อื่น”
สิ่งที่ผมได้เรียนรู้มากที่สุดจาก Marc คือ ถ้าอยากรู้ว่าอะไรพัง ก่อนอื่นต้องมองให้เห็นอย่างถูกต้องเสียก่อน เขาสร้างการแสดงผล latency เช่น time series ของ histogram แบบในบทความ แล้วใช้ภาพเหล่านั้นเล่าเรื่อง ทำให้ทีมมองสิ่งที่ต้องทำต่างไปอย่างสิ้นเชิง แต่ละ peak ใน histogram มีสาเหตุและงาน optimization ของมันเอง และการลงทุนมองข้อมูล performance อย่างลึกซึ้งในหลาย ๆ แบบจะเปิดให้เห็นประสิทธิภาพและโอกาสที่มองไม่เห็นหากไม่ทำเช่นนั้น
โปรเจกต์ retrofit ในปี 2013 ที่ใส่ SSD หนึ่งลูกลงในเซิร์ฟเวอร์หลายพันเครื่องเป็นหนึ่งในเรื่องของ AWS ที่ผมชอบที่สุด สิ่งนี้เป็นไปได้เพราะตั้งแต่แรกมีการออกแบบให้คำนึงถึง maintenance event แบบไม่หยุดระบบ สามารถ remap EBS volume ไปยัง storage server ใหม่ แล้วอัปเดตหรือสร้างเซิร์ฟเวอร์ว่างขึ้นมาใหม่ได้ เป็นตัวอย่างที่ดีว่า distributed system ไม่ได้มีไว้แค่เพื่อ scale เท่านั้น แต่ยังช่วยให้ทนต่อความเสียหายของเซิร์ฟเวอร์ได้อย่างเป็นธรรมชาติ และย้ายข้อมูลได้โดยไม่สูญหาย จนทำให้การปฏิบัติการในระดับใหญ่เป็นไปได้
Dick Lyon ของ Google ก็ใช้แนวทางเดียวกันกับ storage server ของ Google และตั้งแต่สไลด์ที่ 62 ของ https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.... เขาระบุคิวหลายชั้นและ การแย่งชิงทรัพยากร ว่าเป็นคอขวดหลักของ block storage
ทำให้นึกถึงความหลัง Reddit เป็นหนึ่งใน ผู้ใช้ EBS รุ่นแรก ๆ ในปี 2008 และเราคิดว่าตัวเองฉลาดที่พบว่าการทำ software RAID ด้วย EBS volume 5 ลูกช่วยเพิ่ม IOPS ได้
ตอนนั้น performance ของแต่ละ volume แกว่งมาก เราจึงเปิดขึ้นมา 7–8 ลูก รันโหลดอ่าน/เขียน แล้วเลือก 5 ลูกที่ performance ดีที่สุดมารวมเป็น Linux software RAID เวลามันเวิร์กก็ได้ผลตามที่ต้องการ บางครั้งได้ IOPS มากกว่า 5 เท่าของโหนดเดียวด้วยซ้ำ แต่เวลามันไม่เวิร์กก็น่ากลัวมาก
เราไม่รู้ว่าใน software RAID ถ้า node หนึ่งช้า RAID ทั้งชุดจะเดินด้วยความเร็วของ volume ที่ช้าที่สุด ผลลัพธ์คือดูเหมือนฐานข้อมูลเสีย ต้องใช้เวลาพอสมควรกว่าจะพบว่าสาเหตุคือ RAID และการเอา node แย่ ๆ ออกก็ยากด้วย เพราะ software RAID ไม่ยอมปล่อยจนกว่าจะเขียนลง volume ช้านั้นเสร็จ
เราต้องใส่ EBS volume ใหม่แล้วสร้าง array ใหม่ ซึ่งก็ไม่ดีอีกเพราะติด IOPS ของ volume ใหม่ หลังจากนั้นก็เลิกใช้ software RAID แบบนั้น และที่ Netflix ก็แทบไม่ได้ใช้ EBS เลย ผมเล่าเรื่องความผิดพลาดที่ทำที่ Reddit ให้ทุกคนที่ยอมฟัง และ Netflix ก็ standardize ไปทาง ใช้เฉพาะ local disk อยู่แล้วตั้งแต่ก่อนผมเข้าร่วม
เกร็ดขำ ๆ คือ ตอนเกิด EBS outage ครั้งใหญ่ของ AWS ผมยังทำงานที่ Reddit และกำลังดู Netflix ระหว่างรอให้ EBS กลับมาเพื่อซ่อมฐานข้อมูล ตอนสัมภาษณ์งานที่ Netflix ผมถามว่า “พวกคุณรอดมาได้ยังไงตอน EBS outage?” เขาตอบว่า “อ๋อ เราแค่ไม่ใช้ EBS น่ะ”
อ่านบทความนี้แล้วดีมาก
จุดที่น่าสนใจคือ ในช่วงเวลาที่บทความกล่าวถึง ผมจำได้ว่า AWS เคยเจอ outage ราว 4 วัน เพราะ EBS และ EC2, EBS, RDS ได้รับผลกระทบ เหตุการณ์นั้นสั่นคลอนความเชื่อมั่นต่อ AWS อย่างมาก
ผลคือมีการปรับโครงสร้างองค์กร และเริ่มลงทุนกับ EBS ในฐานะบริการอิสระอย่างลึกซึ้งกว่ามาก ช่วงเวลานี้ยังทับซ้อนกับตอนที่ Apple กลายเป็นลูกค้า และยังเป็นช่วงที่ AWS ทั้งหมดเติบโตอย่างรวดเร็วจากการนำไปใช้ของสตาร์ทอัพอย่าง Netflix, Zynga, Dropbox
เรื่องราวทางเทคนิคและปฏิบัติการแบบนี้ก็สนุก แต่ innovation ทางเทคโนโลยีใน production นั้นยุ่งเหยิง และเกิดขึ้นบนฉากหลังของ ความต้องการทางธุรกิจในโลกจริง อยากได้ยินเรื่องแบบนั้นมากกว่านี้ด้วย
แต่สุดท้ายวงล้อก็หมุนกลับไปสู่การพัฒนาฟีเจอร์ ผมจะจดจำปีนั้นเสมอว่าเป็นปีที่มี escalation น้อยที่สุดตลอดช่วงที่อยู่ที่นั่น
ผมสงสัยตรงส่วนที่ว่า “การเพิ่ม random delay เล็กน้อยให้กับ request ไปยัง storage server ทำให้ latency เฉลี่ยและ outlier ลดลงแทน เพราะมีผลช่วยทำให้เครือข่ายราบเรียบขึ้น” อธิบายได้ไหมว่าทำไมถึงเป็นเช่นนั้น?
ถ้าสนใจ มีทอล์ก [0] เมื่อปี 2009 เกี่ยวกับโครงสร้างภายในของ Amazon S3 ทำขึ้นจากเอกสารภายในของทีม S3 และหลายอย่างในนั้นก็มีอิทธิพลต่อวิธีพัฒนา EBS ด้วย
[0]: https://vimeo.com/7330740
ชอบส่วนที่บอกว่าในปี 2013 มีการเพิ่ม SSD ให้กับอุปกรณ์ EBS ทั้งหมดด้วยมือ ดูจากรูปแล้วหน้าตาค่อนข้างคล้าย Samsung SATA SSD
https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
ความจำผมอาจผิดก็ได้ แต่เหมือนว่าการติดตั้ง SSD ใน Dell blade เพื่อใช้งานนั้นเกิดขึ้นก่อนหน้านั้นมาก ประมาณปี 2010–2012 ประสิทธิภาพ I/O เป็นประเด็นใหญ่มากจริง ๆ และเป็นช่วงที่กำลังเปลี่ยนจากฮาร์ดดิสก์แบบจานหมุนไปสู่หน่วยความจำแฟลช
ยังจำได้ว่าเคยทดลองกับอุปกรณ์ที่ใช้แฟลชดิบ ๆ ซึ่งไม่มีทั้งการจัดการข้อผิดพลาดหรือ wear leveling เลย เป็นเรื่องบ้าบอมาก แต่ทุกคนต่างก็ต้องการประสิทธิภาพ I/O ที่เพิ่มขึ้นอย่างมหาศาลจากการย้ายจากดิสก์จานหมุนไปเป็นซิลิคอนอย่างยิ่ง
ความเร็วของดิสก์เพิ่มขึ้นเร็วมากจน SKU แรกตกรุ่นภายใน 6 เดือน โชคดีที่ตอนปลดระวางแร็กเหล่านั้นเร็วกว่าที่วางแผนไว้หลายปี ผมไม่ต้องไปอธิบายกับทีมสินทรัพย์ด้วยตัวเอง การใส่รุ่นใหม่ที่หนาแน่นกว่าและเร็วกว่าเข้าไปทำให้มูลค่าของตำแหน่งแร็กสูงกว่ามาก
นึกถึงสมัยที่สร้าง โครงสร้างพื้นฐานสตอเรจแบบบริการ ก่อนจะมีโอเพนซอร์สที่ใช้งานได้จริง เราออกจาก Sun SAN, Fibre Channel และ Solaris ไปใช้ GlusterFS บนเซิร์ฟเวอร์สตอเรจ Supermicro ที่รัน Linux กับ NFS และก่อนผมออกในปี 2007 ก็ขยายไปเกือบ 2PB แล้ว
ยังนึกถึงยุคที่การแอบทำให้ mdraid พังแล้วสร้างใหม่ด้วยการใส่ SSD แทนดิสก์จานหมุนในขณะที่เซิร์ฟเวอร์ยังทำงานอยู่ถือเป็นเรื่องสมเหตุสมผล เพราะ SATA รองรับ hot-swap ไดรฟ์ได้ในระดับหนึ่ง พอเปลี่ยนจากดิสก์จานหมุนเป็น SSD ค่า IOPS ของระบบที่สำคัญที่สุดบนแพลตฟอร์มเพิ่มขึ้น 14 เท่า
ช่วงต้นอาชีพ ผมทำงานดูแลระบบโดยรวมในบริษัทอินเทอร์เน็ตที่ไม่ได้ใหญ่ในแง่จำนวนคน แต่มีขนาดใหญ่ในเชิงเทคโนโลยีและการดำเนินงาน จำนวนบทเรียนที่ได้เรียนรู้ในช่วงเวลาสั้น ๆ นั้นมากจนน่าเหลือเชื่อ หลังจากออกจากบริษัทนั้น จึงได้รู้ว่าคนส่วนใหญ่แทบไม่เคยเจอปัญหาแบบนั้นตลอดอาชีพ จึงไม่มีโอกาสได้เรียนรู้บทเรียนเหล่านั้นด้วย
เพราะอย่างนั้นผมจึงคิดว่าควรมี ระบบคุณวุฒิวิชาชีพ หากกำหนดให้ต้องฝึกงานภายใต้วิศวกรที่ชำนาญ ก็จะช่วยให้เรียนรู้ความรู้และทักษะที่มีค่ามาก ซึ่งเรียนได้จากประสบการณ์เท่านั้น ภายในเวลาอันสั้น และหลังจากนั้นก็จะทำงานได้มีประสิทธิภาพยิ่งขึ้นมาก สำหรับคนที่สัมภาษณ์ผู้สมัคร หลักฐานด้านประสบการณ์และคำแนะนำจากเมนเทอร์ก็น่าจะมีค่ามากเช่นกัน
ชอบประโยคนี้
“อุดมคติของ วิศวกรฟูลสแต็ก ที่ได้รับการยกย่องอย่างกว้างขวางนั้นก็มีคุณค่า แต่ในระบบที่ลึกและซับซ้อน บ่อยครั้งการสร้างกลุ่มผู้เชี่ยวชาญที่สามารถร่วมมือและทำงานอย่างสร้างสรรค์ข้ามทั้งสแต็กทั้งหมดและขอบเขตความเชี่ยวชาญเชิงลึกของแต่ละคน มีคุณค่ามากกว่า”
ไดอะแกรมแรกของบทความไม่ถูกต้องหรือค่อนข้างล้าสมัย ในคอมพิวเตอร์สมัยใหม่ PCIe lane ส่วนใหญ่เชื่อมต่อโดยตรงกับ I/O hub ของ CPU หรือบริเวณ Uncore ไม่ได้ผ่าน PCH แยกเหมือนสมัยก่อน
นี่เป็นความก้าวหน้าที่สำคัญทั้งต่อ throughput และ latency ของ I/O นอกเหนือจากนั้นเป็นบทความที่ยอดเยี่ยม และแสดงให้เห็นได้ดีว่าท้ายที่สุดแล้วทุกที่ล้วนเป็นคิว
จะระบุในคำบรรยายภาพให้ชัดเจนว่าเป็นโครงสร้างของยุคนั้น