บริการจัดเก็บข้อมูล S3 ของ Amazon บรรลุเป้าหมายที่น่าประทับใจด้วยการให้บริการ 1 เพตาไบต์ต่อวินาทีโดยใช้ฮาร์ดดิสก์ไดรฟ์แบบดั้งเดิม (HDDs) ซึ่งกระตุ้นให้เกิดการอภิปรายอย่างกว้างขวางเกี่ยวกับประสิทธิภาพนี้เปรียบเทียบกับทางเลือก open source และเทคโนโลยีใดที่ทำให้เป็นไปได้
ขนาดที่อยู่เบื้องหลังประสิทธิภาพของ S3
AWS S3 ทำงานในระดับที่ใหญ่มหาศาลอย่างแท้จริง จัดการคำขอมากกว่า 100 ล้านครั้งต่อวินาทีในช่วงเวลาที่มีการใช้งานสูงสุด ขณะเดียวกันก็เก็บข้อมูลมากกว่า 100 ล้านออบเจ็กต์ บริการนี้บรรลุความเร็วในการถ่ายโอนข้อมูลที่น่าทึ่ง 1.1 เพตาไบต์ต่อวินาทีแม้จะอาศัย HDD เป็นหลัก ซึ่งโดยทั่วไปถือว่าเป็นอุปกรณ์จัดเก็บข้อมูลที่ช้า ประสิทธิภาพนี้มาจากวิศวกรรมที่ชาญฉลาดซึ่งแก้ไขข้อจำกัดทางกายภาพของดิสก์หมุนผ่านการประมวลผลแบบขนานขนาดใหญ่และสถาปัตยกรรมแบบกระจาย
ข้อเข้าใจสำคัญคือแม้ว่า HDD แต่ละตัวจะช้าเนื่องจากข้อจำกัดทางกลไกเช่นเวลาในการค้นหาและความล่าช้าในการหมุน แต่การกระจายข้อมูลไปยังไดรฟ์หลายพันตัวช่วยให้ระบบสามารถให้บริการคำขอหลายรายการพร้อมกันได้ ไดรฟ์แต่ละตัวอาจจัดการเพียงส่วนเล็กๆ ของคำขอใดๆ แต่เมื่อรวมกันแล้วจะสร้างความเร็วในการถ่ายโอนข้อมูลรวมที่มหาศาล
เมตริกประสิทธิภาพของ AWS S3:
- อัตราการถ่ายโอนข้อมูล: 1.1 เพตาไบต์ต่อวินาที
- คำขอสูงสุด: 100 ล้านครั้งต่อวินาที
- จำนวนออบเจ็กต์ทั้งหมด: มีการจัดเก็บมากกว่า 100 ล้านออบเจ็กต์
- ความสามารถในการดำเนินงาน: 800,000 การดำเนินงานทั้งหมด
- ประสิทธิภาพต่อโหนด: หลายหมื่นธุรกรรมต่อวินาที
ชุมชนแสวงหาทางเลือก Open Source
การอภิปรายนี้กระตุ้นให้หลายคนในชุมชนเทคโนโลยีค้นหาโซลูชัน open source ที่สามารถบรรลุประสิทธิภาพที่คล้ายคลึงกันด้วยการจัดเก็บข้อมูลที่ใช้ HDD ทางเลือกหลายตัวได้เกิดขึ้นจากการอภิปรายของชุมชน แม้ว่าแต่ละตัวจะมาพร้อมกับข้อแลกเปลี่ยน Ceph พร้อม RadosGW ดูเหมือนจะเป็นหนึ่งในตัวเลือกที่เป็นผู้ใหญ่ที่สุด โดยผู้ใช้รายงานว่าสามารถมีประสิทธิภาพเหนือกว่า S3 สำหรับภาระงานบางอย่างที่เกี่ยวข้องกับการถ่ายโอนไฟล์ขนาดใหญ่
ตัวเลือกอื่นๆ ได้แก่ Gluster ซึ่งตลาดตัวเองว่าสามารถจัดการการจัดเก็บข้อมูลแบบกระจายขนาดใหญ่โดยใช้ฮาร์ดแวร์ทั่วไป และโปรเจ็กต์ใหม่ๆ เช่น Garage ที่ใช้วิธีการที่แตกต่างกันในการแก้ปัญหาเดียวกัน อย่างไรก็ตาม โซลูชันเหล่านี้ส่วนใหญ่ต้องการขนาดที่สำคัญในหลายเซิร์ฟเวอร์เพื่อให้บรรลุประสิทธิภาพที่ดีที่สุด ทำให้เหมาะสมน้อยกว่าสำหรับการปรับใช้ขนาดเล็ก
หมายเหตุ: RadosGW เป็นอินเทอร์เฟซเกตเวย์ที่เข้ากันได้กับ S3 ของ Ceph ที่ช่วยให้แอปพลิเคชันสามารถเข้าถึงการจัดเก็บข้อมูล Ceph โดยใช้การเรียก API มาตรฐาน S3
ทางเลือก S3 แบบ Open Source ที่กล่าวถึง:
- Ceph + RadosGW: เป็นตัวเลือกที่เป็นผู้ใหญ่ที่สุด สามารถทำงานได้เหนือกว่า S3 สำหรับไฟล์ขนาดใหญ่
- Gluster: มีการตลาดสำหรับฮาร์ดแวร์ทั่วไปที่หาซื้อได้ เหมาะสำหรับระบบไฟล์ที่ใช้ร่วมกัน
- Garage: โปรเจกต์ใหม่ที่มีแนวทางการออกแบบที่แตกต่าง (ไม่มี erasure coding)
- MinIO: ต้องการ flash storage เพื่อประสิทธิภาพที่เหมาะสม
- SeaweedFS: มีการพัฒนาด้วยการสนับสนุน RDMA และ erasure coding
ข้อมูลเชิงลึกเกี่ยวกับสถาปัตยกรรมทางเทคนิค
สมาชิกชุมชนที่มีความรู้ภายในได้เปิดเผยว่าสถาปัตยกรรมของ S3 ประกอบด้วยเว็บเซอร์วิสที่ใช้ Java หลายชั้น โดยการดำเนินการส่วนใหญ่จัดการแบบซิงโครนัสมากกว่าผ่านคิว ระบบใช้วิธีการตรงไปตรงมาที่คำขอจะไปที่เซิร์ฟเวอร์ส่วนหน้าก่อน จากนั้นสอบถามบริการจัดทำดัชนีเพื่อแมปชื่อออบเจ็กต์กับตำแหน่งการจัดเก็บ ก่อนที่จะดึงข้อมูลจริงจากโหนดจัดเก็บข้อมูล
มันเป็นตัวอย่างที่ดีที่สุดของจำนวนธุรกรรมต่อวินาทีที่สแต็กเว็บเซอร์วิส Java มาตรฐานสามารถจัดการได้ที่ฉันเคยเห็นในอาชีพของฉัน
สถาปัตยกรรมนี้สามารถจัดการธุรกรรมหลายหมื่นรายการต่อวินาทีต่อโหนด แสดงให้เห็นว่าระบบกระจายที่ออกแบบมาอย่างดีสามารถบรรลุประสิทธิภาพที่น่าทึ่งได้แม้จะใช้สแต็กเทคโนโลยีทั่วไป
สถาปัตยกรรมทางเทคนิคของ S3 :
- Stack หลัก: เว็บเซอร์วิสที่ใช้ Java
- การไหลของ Request: เซิร์ฟเวอร์ Front-end → บริการ Indexing → โหนด Storage
- การสื่อสาร: โปรโตคอล STUMPY แบบกำหนดเอง (อาจมีการย้ายไปใช้ HTTP)
- บริการ: ประมาณ 12 บริการหลัก (ข้อมูลในอดีต)
- ประเภทการดำเนินงาน: การตอบสนอง API แบบ synchronous เป็นหลัก มีการใช้ queuing น้อยที่สุด
ความเป็นจริงสำหรับการปรับใช้ขนาดเล็ก
แม้ว่าวิธีการของ S3 จะใช้ได้ผลในระดับขนาดใหญ่ การอภิปรายของชุมชนเผยให้เห็นความท้าทายสำหรับองค์กรขนาดเล็กที่พยายามจำลองประสิทธิภาพที่คล้ายคลึงกัน ระบบจัดเก็บข้อมูล open source หลายตัวได้รับการปรับให้เหมาะสมสำหรับการขยายแนวนอนในหลายเซิร์ฟเวอร์มากกว่าการเพิ่มประสิทธิภาพสูงสุดในโหนดเดียว สิ่งนี้สร้างช่องว่างสำหรับผู้ใช้ที่ต้องการประสิทธิภาพเหมือน S3 แต่ไม่มีโครงสร้างพื้นฐานระดับศูนย์ข้อมูล
สมาชิกชุมชนบางคนกำลังทดลองกับวิธีการแบบผสม รวม ZFS สำหรับการจัดการการจัดเก็บข้อมูลท้องถิ่นกับระบบเช่น Garage สำหรับความเข้ากันได้กับ S3 โซลูชันเหล่านี้มีเป้าหมายเพื่อใช้ประโยชน์จากจุดแข็งของเทคโนโลยีทั้งสองขณะทำงานภายในข้อจำกัดของการปรับใช้ฮาร์ดแวร์ขนาดเล็ก
การอภิปรายเน้นบทเรียนสำคัญ: แม้ว่าหลักการพื้นฐานของความสำเร็จของ S3 สามารถเข้าใจและจำลองได้ แต่การบรรลุผลลัพธ์ที่คล้ายคลึงกันต้องการขนาดที่ใหญ่มหาศาลหรือโซลูชันวิศวกรรมสร้างสรรค์ที่ปรับให้เหมาะสมกับกรณีการใช้งานเฉพาะ
อ้างอิง: How AWS S3 serves 1 petabyte per second on top of slow HDDs