การสร้างและการดำเนินงานระบบจัดเก็บข้อมูลขนาดค่อนข้างใหญ่ที่เรียกว่า S3

 (allthingsdistributed.com)
4 คะแนน โดย GN⁺ 2023-07-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การสร้างและการดำเนินงานของ S3

  • S3 ย่อมาจาก Amazon Simple Storage Service และหมายถึงระบบสตอเรจขนาดใหญ่
  • Andy Warfield ทำงานอยู่ที่ S3 และได้มีความเข้าใจระบบอย่างกว้างขวาง
  • S3 เป็นบริการที่ครอบคลุมหลายด้าน ตั้งแต่ประสบการณ์ด้านประสิทธิภาพของลูกค้าไปจนถึงกลไกของฮาร์ดดิสก์

เมื่อ 17 ปีก่อน ในแคมปัสมหาวิทยาลัยอันแสนห่างไกล...

  • S3 เปิดตัวเมื่อวันที่ 14 มีนาคม 2006 และปีนี้ครบรอบ 17 ปี
  • Warfield สำเร็จปริญญาเอกจากมหาวิทยาลัยเคมบริดจ์ เข้าร่วมโครงการ Xen และต่อมาได้ร่วมก่อตั้งสตาร์ตอัปชื่อ XenSource
  • XenSource เติบโตขึ้นและถูก Citrix เข้าซื้อกิจการ โดย Warfield ได้เรียนรู้มากมายเกี่ยวกับการขยายธุรกิจและการบริหารทีม

วิธีการทำงานของ S3

  • หลังจากเข้าร่วม Amazon แล้ว Warfield ได้เรียนรู้หลักการทำงานของ S3 จาก Seth Markle หนึ่งในวิศวกรยุคแรกของ S3
  • S3 เป็นบริการ object storage ที่มี HTTP REST API โดยประกอบด้วยฟรอนต์เอนด์ บริการเนมสเปซ storage fleet ที่มีฮาร์ดดิสก์ และ fleet ที่ทำงานเบื้องหลัง
  • S3 ประกอบด้วยไมโครเซอร์วิสหลายร้อยตัว และการทำงานร่วมกันระหว่างแต่ละทีมเกิดขึ้นผ่านข้อตกลงในระดับ API

ข้อสังเกตในช่วงแรก

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

ขนาดทางเทคนิค: ฟิสิกส์ของสตอเรจ

  • S3 เป็นระบบขนาดใหญ่มากที่ใช้ฮาร์ดดิสก์หลายล้านลูก
  • ฮาร์ดไดรฟ์สะท้อนทั้งความน่าทึ่งของเทคโนโลยีและนวัตกรรม พร้อมทั้งมีความคุ้มค่าด้านต้นทุนสูง

การจัดการความร้อน: การจัดวางข้อมูลและประสิทธิภาพ

  • ใน S3 มีการทำ optimization เพื่อแก้ปัญหาที่เรียกว่า 'การจัดการความร้อน' โดยกระจายคำขอ I/O อย่างสม่ำเสมอไปยังฮาร์ดไดรฟ์จำนวนมาก

การทำซ้ำข้อมูล: การจัดวางข้อมูลและความทนทาน

  • S3 ใช้สคีมาความซ้ำซ้อน เช่น replication และ erasure coding เพื่อรับประกันความทนทานของข้อมูลและจัดการความร้อน

ผลกระทบของขนาด: กลยุทธ์การจัดวางข้อมูล

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

ปัจจัยด้านมนุษย์

  • ความซับซ้อนของ S3 ไม่ได้มาจากปัจจัยทางเทคนิคเท่านั้น แต่ยังมาจากปัจจัยด้านมนุษย์ด้วย
  • Amazon สนับสนุนให้วิศวกรและทีมสามารถล้มเหลวได้อย่างรวดเร็วและปลอดภัย และมุ่งเน้นไปที่การให้บริการสตอเรจที่มีความทนทานสูง

การขยายขอบเขตของตัวฉันเอง: การแก้ปัญหาที่ยากซึ่งเริ่มต้นและจบลงที่ 'ความเป็นเจ้าของ'

  • Warfield ได้สัมผัสกับการขยายขนาดในระดับส่วนตัวที่ Amazon และได้เรียนรู้เกี่ยวกับขนาดของซอฟต์แวร์ ผู้คน และธุรกิจ
  • ที่ Amazon มีการให้ความสำคัญกับ 'ความเป็นเจ้าของ' ซึ่งช่วยให้เข้าใจทั้งโครงสร้างองค์กรและแนวทางด้านวิศวกรรมได้ดีขึ้น

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

  • S3 ไม่ได้เป็นเพียงบริการสตอเรจธรรมดา แต่เป็นระบบนิเวศที่ซับซ้อนซึ่งผสานฮาร์ดแวร์ ซอฟต์แวร์ และปัจจัยด้านมนุษย์เข้าด้วยกัน
  • บทความนี้มอบมุมมองเชิงลึกให้กับวิศวกรซอฟต์แวร์ระดับเริ่มต้นที่ต้องการเข้าใจขนาดและความซับซ้อนของ S3
  • วัฒนธรรม 'ความเป็นเจ้าของ' ของ Amazon เป็นองค์ประกอบสำคัญที่ช่วยกระตุ้นให้ทั้งทีมและบุคคลแสวงหานวัตกรรมด้วยความรับผิดชอบที่มากขึ้น

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

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

 
GN⁺ 2023-07-28
ความคิดเห็นใน Hacker News

  • อัตราความผิดพลาดอยู่ที่ 1 ต่อ 10^15 คำขอ ซึ่งในโลกความเป็นจริงเกิดขึ้นบ่อยและเป็นสิ่งที่ต้องคำนึงถึงใน S3

    • ตอนที่ทำงานที่ AWS จำได้ว่าที่สเกลของ S3 เหตุการณ์แบบหนึ่งในพันล้านจะเกิดขึ้นทุกวัน และแม้แต่เหตุการณ์ที่มีโอกาสต่ำมากจนปกติไม่ต้องกังวล ก็ยังต้องนำมาพิจารณาและรับมือ
    • ดีใจที่ได้อ่านเกี่ยวกับ ShardStore โดยเฉพาะเรื่องการพิสูจน์ความถูกต้องเชิงรูปแบบและการทดสอบแบบอิงคุณสมบัติที่น่าประทับใจ บริการในยุคก่อนหน้านี้ขึ้นชื่อว่ามีบั๊กเยอะ แต่ก็ถูกออกแบบมาอย่างดีอย่างน้อยก็ให้ล้มเหลวอย่างปลอดภัย เพื่อป้องกันข้อมูลสูญหาย ต้องยกความดีความชอบให้วิศวกร S3 ที่หมกมุ่นกับเรื่องนี้

  • ทำงานในสายจีโนมิกส์และตลอด 10 ปีที่ผ่านมาได้จัดการระบบจัดเก็บข้อมูลระดับเพตะไบต์จำนวนมาก

    • จากประสบการณ์ที่เคยใช้ระบบจัดเก็บข้อมูลหลากหลายทั้ง AWS S3, GCP GCS, Ceph, Gluster, ระบบของ HP และอื่น ๆ ทำให้ชื่นชมอย่างมากกับความพยายามที่ต้องใช้ในการดูแลระบบเหล่านี้
    • ข้อดีของการแชร์ disk IOPS กับลูกค้าจำนวนมากนั้นมหาศาล และการบรรเทาปัญหานี้ในระบบเดี่ยวทำได้ยากมาก
    • สำหรับคลัสเตอร์ฮาร์ดแวร์แบบ co-location เราต้องปรับแต่งระบบแบตช์เพื่อจัดการ IO ให้เป็นทรัพยากรที่จัดสรรได้เหมือน RAM หรือ CPU สำหรับงานขนาดใหญ่
    • S3 และ GCP มีราคาแพง แต่ประสิทธิภาพก็คุ้มค่า

  • ถ้า S3 ใช้โปรโตคอลที่อิง OAuth2 เพื่อมอบหมายสิทธิ์การเข้าถึงแบบอ่าน/เขียนได้ สิ่งที่เราจะสร้างได้คงมีอีกมาก

    • เราต้องการโปรโตคอลแบบ HTTP ที่ให้แอปเข้าถึงข้อมูลแทนผู้ใช้ได้
    • Google Drive ใกล้เคียงที่สุดในเรื่องนี้ แต่มีปัญหาเรื่องผู้ให้บริการรายเดียว และก็น่าเสียดายที่ remoteStorage ไม่ได้รับความนิยม
    • หวังว่า Solid จะประสบความสำเร็จ แต่รู้สึกว่ามันซับซ้อน
    • วิธีแก้ปัญหาในแบบของตัวเองคือ gemdrive.io แต่ตอนนี้กำลังโฟกัสกับส่วนอื่นของสแตกที่โฮสต์เองอยู่

  • คำอธิบายเกี่ยวกับสเปกของฮาร์ดไดรฟ์ IBM RAMAC ปี 1956

    • สเปกที่ระบุว่าความจุ 3.75 MB และต้นทุนประมาณ $9,200 ต่อเทราไบต์ อาจไม่ถูกต้อง
    • เว็บไซต์อื่นเสนอว่าราคาซื้ออยู่ที่ประมาณ $10,000 ต่อเมกะไบต์ ดังนั้นสเปกควรเป็น $9,200 ต่อเมกะไบต์มากกว่า

  • การจัดการการยืนยันตัวตนในระบบกระจายนั้นยากมาก

    • ที่สเกลของ AWS การยืนยันตัวตนแทบเหมือนเวทมนตร์ และ AWS ก็มีโมเดลสิทธิ์ที่ละเอียดมาก ทำให้การเปลี่ยนแปลงสิทธิ์แพร่กระจายผ่านโครงสร้างพื้นฐานได้ในระดับต่ำกว่ามิลลิวินาที
    • S3 แตกต่างจากบริการอื่นตรงที่สิทธิ์อยู่ที่ตัวทรัพยากร ซึ่งอาจเป็นไปเพื่อความเร็ว

  • ในฐานะวิศวกรที่มีประสบการณ์สูงมากและมีวาระเชิงเทคนิค ฉันใช้เวลาพัฒนาปัญหาและอธิบายมันให้ชัดเจนมากกว่าการเสนอไอเดีย

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

  • เป็นเรื่องดีที่ได้เห็นพนักงาน Amazon พูดคุยอย่างเปิดเผยเกี่ยวกับการทำงานภายในของ S3

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

  • ส่วนที่อธิบายโดยเปรียบเทียบหัวอ่านฮาร์ดไดรฟ์กับเครื่องบิน 747

    • มันเป็นงานที่ต้องการความแม่นยำระดับที่เหมือนกับเครื่องบินบินรอบโลก 25,000 ครั้ง แล้วพลาดใบหญ้าไปเพียงครั้งเดียว

  • ย้อนกลับไปสมัย S3 KeyMap ได้เรียนรู้ว่าแม้จะระบุ object/partition/bucket ที่ร้อนที่สุดได้แล้ว ก็ไม่ได้แปลว่าจะย้ายมันแล้วแก้ปัญหาได้ง่าย ๆ

    • วิธีแก้จริงคือแบ่งโหลดของพาร์ทิชันบนโฮสต์ออกเป็นควอไทล์ แล้วค่อยย้ายพาร์ทิชันในควอไทล์ที่สองไปยังโฮสต์ที่มีโหลดต่ำที่สุด
    • ผลคืออัตราความผิดพลาดจากเดิมที่คงที่ราว 1% กลายเป็นวันที่ไม่มีข้อผิดพลาดเลย ทำให้ต้องปรับการแจ้งเตือนให้เข้มงวดขึ้นมาก

  • S3 ไม่ใช่แค่ที่เก็บข้อมูลธรรมดา แต่เป็นมาตรฐาน

    • มีหลายแห่งที่ให้บริการที่เก็บข้อมูลแบบเข้ากันได้กับ S3 แม้จะไม่แน่ใจว่ามาตรฐานนี้เปิดกว้างแค่ไหน หรือว่าต้องจ่ายเงินให้ Amazon เพื่อจะพูดว่า "รองรับ S3" หรือไม่ แต่ก็เป็นเรื่องที่เจ๋งมาก