AWS S3 ประมวลผลได้ 1 เพตะไบต์ต่อวินาทีบน HDD ที่ช้าได้อย่างไร

 (bigdata.2minutestreaming.com)
19 คะแนน โดย GN⁺ 2025-09-27 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • AWS S3 เป็นบริการ object storage แบบ multi-tenant ขนาดใหญ่ ที่มอบ ความพร้อมใช้งานสูง และ ความทนทานของข้อมูล ใน ต้นทุนต่ำ
  • แม้จะใช้ HDD แบบเก่าและช้า (≈120 IOPS) แต่ก็ใช้ประโยชน์จากความคุ้มค่าของสื่อจัดเก็บข้อมูลแบบ ราคาต่ำมาก·ความจุสูง ได้อย่างเต็มที่
  • S3 ออกแบบชั้นจัดเก็บข้อมูลภายใน (ShardStore) แบบ log-structured (LSM) เพื่อให้เส้นทางการเขียนเหมาะกับ sequential I/O ขณะที่เส้นทางการอ่านชดเชยปัญหาด้านประสิทธิภาพด้วย Erasure Coding (5-of-9) และ การทำงานแบบขนานในวงกว้าง
  • ตั้งแต่ฝั่งไคลเอนต์ ฟรอนต์เอนด์ ไปจนถึงสตอเรจ S3 ใช้ multipart upload, byte-range GET, connection pool, hedged requests เพื่อลด tail latency และ รวม throughput เข้าด้วยกัน
  • ด้วยการกระจายตำแหน่งข้อมูลแบบสุ่ม, Power of Two Random Choices, การรีบาลานซ์อย่างต่อเนื่อง และ decorrelation ที่ทำให้ภาระงานเรียบขึ้นเมื่อระบบใหญ่ขึ้น จึงหลีกเลี่ยง hotspot ได้ และทำให้ได้ throughput ระดับ >1 PB/s

สถาปัตยกรรมสตอเรจขนาดใหญ่ของ AWS S3

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

  • ขนาดของ S3

    • จัดเก็บออบเจ็กต์มากกว่า 400 ล้านล้านชิ้น
    • รองรับคำขอ 150 ล้านรายการต่อวินาที
    • รองรับทราฟฟิกมากกว่า 1 PB ต่อวินาทีในช่วงพีก
    • ใช้งานฮาร์ดดิสก์หลายสิบล้านลูก
  • S3 ตั้ง ความพร้อมใช้งาน และ ความทนทานของข้อมูล (“11 nines” ตามเป้าหมายการออกแบบ) พร้อมต้นทุนที่ค่อนข้างต่ำ เป็นเงื่อนไขพื้นฐานของประสบการณ์ผู้ใช้
    • และยังขยายบทบาทไปเป็น ชั้นจัดเก็บพื้นฐาน ของ data analytics และ machine learning data lake
  • เป้าหมายการออกแบบคือรองรับ รูปแบบการเข้าถึงแบบสุ่ม และ การทำงานพร้อมกันจำนวนมหาศาล โดยยังคงประสิทธิภาพด้านต้นทุน
    • S3 ตั้งอยู่บนสมมติฐานของ workload แบบ random access ที่แต่ละ tenant เข้าถึงข้อมูลด้วยขนาด/ออฟเซ็ตที่ไม่ตายตัว

เทคโนโลยีพื้นฐาน: ฮาร์ดไดรฟ์ (HDD)

  • ความสามารถในการขยายขนาด และ ประสิทธิภาพ อันน่าทึ่งของ S3 มีรากฐานมาจากสื่อจัดเก็บข้อมูลแบบดั้งเดิมอย่าง HDD
  • HDD เป็นเทคโนโลยีเก่าที่ ทนทานสูง แต่มีข้อจำกัดด้าน IOPS (อินพุต/เอาต์พุตต่อวินาที) และ latency เพราะต้องอาศัยการเคลื่อนที่ทางกายภาพ
    • เนื่องจากต้องมี การหมุนต่อวินาที (เช่น 7200 RPM) และ การ seek ของ actuator ซึ่งเป็น การเคลื่อนไหวเชิงกล จึงทำให้ latency สูงโดยโครงสร้างและหลีกเลี่ยงไม่ได้
    • ค่าเฉลี่ยของ half-platter seek ≈4 ms, ค่าเฉลี่ยของ half-rotation ≈4 ms, การส่งข้อมูล 0.5 MB ≈2.5 ms → การอ่าน 0.5 MB แบบสุ่มมีค่าเฉลี่ย ≈11 ms, throughput แบบสุ่มของดิสก์เดี่ยวอยู่ที่ประมาณ ≈45 MB/s
  • ต่างจาก SSD, HDD ยังคงถูกใช้ในสตอเรจขนาดใหญ่เพราะมีความคุ้มค่าแบบ “ราคาต่ำมาก/ความจุสูง” จากแนวโน้มระยะยาวของ ความจุ↑·ราคา↓
    • ราคา: ลดลง 6 พันล้านเท่าต่อไบต์ (เมื่อคิดตามมูลค่าเงินเฟ้อ)
    • ความจุ: เพิ่มขึ้น 7.2 ล้านเท่า
    • ขนาด: ลดลง 5,000 เท่า
    • น้ำหนัก: ลดลง 1,235 เท่า
  • อย่างไรก็ตาม ตลอด 30 ปีที่ผ่านมา IOPS แทบคงอยู่ที่ราว 120 และประสิทธิภาพกับ latency ของการเข้าถึงแบบสุ่มก็แทบไม่ดีขึ้นมากนัก
  • SSD ได้เปรียบด้าน random I/O แต่ในสเกลระดับ เพตะ/เอกซะ กลับเสียเปรียบในแง่ total cost of ownership (TCO)

เส้นทางการเขียนที่ปรับให้เหมาะกับ sequential I/O

  • HDD เหมาะกับ การเข้าถึงแบบลำดับ เพราะเมื่ออ่านหรือเขียนไบต์ที่ต่อเนื่องกัน จานดิสก์จะหมุนต่อเนื่องตามธรรมชาติ ทำให้ประมวลผลข้อมูลได้รวดเร็ว
  • โครงสร้างข้อมูลแบบ log-structured ใช้ประโยชน์จากลักษณะ sequential นี้
    • ShardStore ซึ่งเป็นชั้นจัดเก็บข้อมูลภายในของ S3 ใช้ LSM แบบ log-structured โดยเลือกให้ การเขียนเป็นการ append ลงดิสก์แบบ sequential
    • ในทำนองเดียวกัน ยังสามารถใช้ batch processing เพื่อดึง throughput แบบ sequential ของดิสก์ออกมาได้สูงสุด

การทำงานแบบขนานและ Erasure Coding สำหรับเส้นทางการอ่านแบบสุ่ม

  • การอ่านต้อง กระโดดไปยังตำแหน่งแบบสุ่ม ตามคำขอของผู้ใช้ จึงชนกับข้อจำกัดทางกายภาพโดยตรง (latency เฉลี่ยของ random I/O อยู่ที่ประมาณ 11ms)
    • HDD หนึ่งลูกให้ throughput แบบ random I/O ได้สูงสุดเพียง 45MB ต่อวินาที
    • ดังนั้น HDD จึงคุ้มค่ามากสำหรับการเก็บข้อมูลปริมาณมาก แต่ประสิทธิภาพด้าน random access ต่ำ
  • เพื่อก้าวข้าม ข้อจำกัดทางกายภาพ นี้ S3 จึงใช้ การ shard ข้อมูลลงบนดิสก์จำนวนมาก และ อ่านพร้อมกันเพื่อรวม throughput เข้าด้วยกัน ผ่าน การทำงานแบบขนานในวงกว้าง
    • ข้อมูลถูกกระจายเก็บไว้ใน HDD จำนวนมหาศาล และใช้ I/O ของแต่ละดิสก์แบบขนานเพื่อยกระดับ throughput โดยรวมอย่างมาก
    • ตัวอย่างเช่น หากแบ่งไฟล์ 1TB ไปเก็บบน HDD 20,000 ลูก ก็สามารถรวม throughput ของดิสก์ทั้งหมดจนอ่านได้ในระดับ TB/s

Erasure Coding

  • ในระบบสตอเรจ การรับประกัน redundancy เป็นสิ่งจำเป็น
  • S3 ใช้ Erasure Coding (EC) โดยแบ่งข้อมูลเป็นชิ้นข้อมูล K ชิ้น และ parity M ชิ้น
    • จากทั้งหมด K+M ชิ้น ขอเพียงมี K ชิ้นใดก็สามารถกู้คืนได้
  • S3 ใช้โครงสร้าง Erasure Coding (5-of-9) ที่แบ่งเป็น 9 ส่วน (5 data shards, 4 parity shards) เพื่อหาจุดสมดุล
    • ข้อมูล 5 ชิ้น + parity 4 ชิ้น = 9 ชิ้น
    • ทนต่อการสูญหายของ shard ได้สูงสุด 4 ชิ้น และกู้คืนต้นฉบับได้จาก ชิ้นใดก็ได้ 5 ชิ้น จึงให้ fault tolerance
    • storage overhead อยู่ที่ ≈1.8 เท่า ซึ่งมีประสิทธิภาพด้านความจุดีกว่า การทำซ้ำ 3 ชุด (3x)
    • และยังทำให้มี เส้นทางการอ่านแบบขนาน 5 เส้นทาง เอื้อต่อ shard parallelization และ การหลีกเลี่ยง straggler
  • ด้วยวิธีนี้ S3 จึงเอาชนะ ข้อจำกัดทางกายภาพ และให้การเข้าถึงแบบสุ่มกับข้อมูลขนาดใหญ่ได้

โครงสร้างการประมวลผลแบบขนาน

  • S3 ใช้ การทำงานแบบขนานหลัก 3 รูปแบบ
    • 1. ผู้ใช้แบ่งข้อมูลออกเป็นหลายชังก์เพื่ออัปโหลดและดาวน์โหลด
    • 2. ไคลเอนต์ส่งคำขอพร้อมกันไปยังฟรอนต์เอนด์เซิร์ฟเวอร์หลายตัว
    • 3. เซิร์ฟเวอร์กระจายเก็บออบเจ็กต์ไปยังสตอเรจเซิร์ฟเวอร์หลายเครื่อง

  • 1. การประมวลผลแบบขนานระดับฟรอนต์เอนด์เซิร์ฟเวอร์

    • ใช้ internal HTTP connection pool เพื่อเชื่อมต่อพร้อมกันไปยังหลาย endpoint ที่กระจายกันอยู่
    • ป้องกันไม่ให้โหนดโครงสร้างพื้นฐานหรือแคชบางจุดรับภาระหนักเกินไป

  • 2. การประมวลผลแบบขนานระหว่างฮาร์ดไดรฟ์

    • อาศัย EC กระจายข้อมูลเป็น shard ขนาดเล็กลงบน HDD หลายลูก

  • 3. การประมวลผลแบบขนานของคำขอ PUT/GET

    • ไคลเอนต์แบ่งข้อมูลออกเป็นหลายส่วนเพื่ออัปโหลดแบบขนาน
    • PUT: เพิ่มการประมวลผลแบบขนานของข้อมูลใหม่ให้สูงสุดด้วย multipart upload
    • GET: รองรับ byte-range GET (อ่านเฉพาะบางช่วงภายในออบเจ็กต์ได้)
  • เมื่อกระจายประมวลผลแบบขนาน ก็สามารถทำอัปโหลดระดับ 1GB ต่อวินาทีได้โดยไม่ยาก

การป้องกัน Hot Spot

  • S3 ทำงานในสภาพแวดล้อมที่มีไดรฟ์หลายสิบล้านลูก คำขอหลายร้อยล้านรายการต่อวินาที และ shard หลายร้อยล้านชิ้นที่ทำงานคู่ขนานกัน
  • หากภาระงานไปรวมที่ดิสก์หรือโหนดบางตัว ก็เสี่ยงให้ประสิทธิภาพของทั้งระบบลดลง
  • กลยุทธ์หลักเพื่อป้องกันสิ่งนี้คือ:
    • 1. การกระจายตำแหน่งข้อมูลแบบสุ่ม
    • 2. การรีบาลานซ์ อย่างต่อเนื่อง
    • 3. การขยายสเกลของระบบ

  • 1. Shuffle sharding & Power of Two

    • กระจายตำแหน่งจัดเก็บข้อมูลตั้งแต่แรกแบบสุ่ม
    • ใช้อัลกอริทึม ‘Power of Two Random Choices’:
      • สุ่ม 2 โหนดแล้วเลือกฝั่งที่มีภาระน้อยกว่า จะช่วยทำ load balancing ได้อย่างมีประสิทธิภาพ

  • 2. การรีบาลานซ์

    • อุณหภูมิของข้อมูล: ใช้คุณลักษณะที่ว่า ข้อมูลใหม่จะร้อนกว่า (ถูกเข้าถึงบ่อยกว่า) ในการ รีบาลานซ์เป็นระยะ เพื่อกระจายพื้นที่และ I/O ใหม่
      • ยิ่งข้อมูลเก่า ความถี่ในการเข้าถึงก็ยิ่งลดลง ทำให้มี I/O เหลือมากขึ้นทั่วทั้งระบบสตอเรจ
    • S3 กระจาย cold data ใหม่เพื่อใช้พื้นที่และทรัพยากรให้เกิดประโยชน์สูงสุด
    • เมื่อเพิ่ม rack ใหม่ (เช่น 20 PB/rack, 1000×20 TB) จำเป็นต้องมี การกระจายเชิงรุก ไปยังความจุที่ว่าง

  • 3. Chill@Scale

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

วัฒนธรรมด้านการปฏิบัติการ·ความน่าเชื่อถือ และเทคนิคอื่น ๆ

  • ใช้ DNS-level shuffle sharding เพื่อมุ่งให้เกิดการแยกระหว่าง tenant และการกระจายอย่างสม่ำเสมอในระดับ name resolver
  • แม้แต่ software rollout ก็ทำแบบค่อยเป็นค่อยไปและไม่หยุดชะงักเหมือน EC โดยการเปลี่ยนผ่าน ShardStore ก็เกิดขึ้นได้โดยไม่กระทบต่อบริการ
  • วัฒนธรรมด้าน durability: รับประกันความน่าเชื่อถือด้วยกระบวนการ เช่น การตรวจจับความผิดปกติอย่างต่อเนื่อง, chain of custody, durability threat modeling, และ formal verification

ทำไมจึงสำคัญ: เทรนด์โครงสร้างพื้นฐานข้อมูลที่สร้างบน S3

  • จากการขยายตัวของ สถาปัตยกรรมแบบ Stateless ทำให้เกิดรูปแบบที่โหนดแอปพลิเคชันไม่มีสถานะ และ มอบ persistence, replication, load balancing ให้ S3 ดูแล มากขึ้น
    • ตัวอย่าง: Kafka Diskless(KIP-1150), SlateDB, Turbopuffer, Lucene on S3, การรวม object storage ของ ClickHouse/OpenSearch/Elastic เป็นต้น
  • ข้อดีคือ การขยายสเกลอย่างยืดหยุ่น·การปฏิบัติการที่ง่ายขึ้น·การลดต้นทุน ส่วนข้อเสียคือมีโอกาส latency เพิ่มขึ้น จึงต้องออกแบบ trade-off ระหว่าง latency·ต้นทุน·durability ให้เหมาะกับแต่ละ workload

สรุป

  • AWS S3 เป็นบริการสตอเรจแบบ multi-tenant ขนาดใหญ่ ที่ก้าวข้ามข้อจำกัดของสื่อจัดเก็บข้อมูลที่ช้าด้วย การทำงานแบบขนานขนาดใหญ่, load balancing, data sharding
  • ใช้ Erasure Coding, การกระจายแบบสุ่ม, การรีบาลานซ์อย่างต่อเนื่อง, hedged requests เพื่อให้ได้ทั้งเสถียรภาพและประสิทธิภาพ
  • จากเดิมที่เน้นงานสำรองข้อมูลและสื่อ ปัจจุบันได้พัฒนาไปเป็นสตอเรจหลักของโครงสร้างพื้นฐานบิ๊กดาต้า เช่น data analytics และ machine learning
  • สถาปัตยกรรมที่อิง S3 ช่วยให้ได้ ความสามารถในการขยายแบบ stateless และสามารถมอบปัญหาเรื่อง durability, replication และ load balancing ให้ AWS จัดการได้อย่างมีประสิทธิภาพ
  • สิ่งนี้ยังช่วย ลดต้นทุนคลาวด์และเพิ่มประสิทธิภาพในการบริหารจัดการ

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

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

 
shakespeares 2025-10-05

ถ้าเทคโนโลยีไม่ดี ก็ดูเหมือนว่าจะไม่มีกำไรนะครับ
 
GN⁺ 2025-09-27
ความเห็นบน Hacker News

  • มีข้อผิดพลาดเชิงข้อเท็จจริงอยู่บ้าง แต่ไม่ได้กระทบกับภาพรวมของบทความมากนัก ตัวอย่างเช่นที่อ้างว่า S3 ใช้การทำ sharding แบบ 5:9 ทั้งที่จริงแล้ว S3 ใช้ sharding หลายแบบ และเท่าที่ฉันทราบ 5:9 ไม่ใช่หนึ่งในนั้น อัตราส่วน 1.8 physical byte ต่อ 1 logical byte นั้นถือว่าแย่มากในมุมต้นทุน HDD จริง ๆ แล้วมีวิธีลดอัตราส่วนนี้ให้ต่ำลงได้ พร้อมกับเพิ่มระดับความขนานและทำให้ความพร้อมใช้งานดีขึ้นด้วย เช่น เวลาที่ทั้ง AZ ล่ม เราควรคิดด้วยว่าสามารถเสีย shard ไปได้กี่ชิ้นก่อนที่ object จะกลายเป็น GET ไม่ได้

    • ฉันเข้าใจจากวิดีโอ YouTube นี้ตรงช่วง 42:20 ว่า S3 ใช้ sharding scheme แบบนั้น ถ้าคุณรู้อะไรมากกว่านี้ก็อยากทราบเหมือนกัน

    • การลดอัตราส่วน 1.8x ลงพร้อมกับเพิ่มความพร้อมใช้งานไปด้วย ฟังดูขัดกับสัญชาตญาณพอสมควร ถ้ามี replica น้อยลง ความเสี่ยงข้อมูลหายเวลา AZ มีปัญหาจะไม่สูงขึ้นหรือ? ฉันเข้าใจมาตลอดว่า AWS ให้ replica ที่แยกจากกันอย่างสมบูรณ์ใน 3 AZ และคำอธิบายที่ว่าการอ่าน chunk ขนาด 16MB จะเร็วกว่าเมื่อไปอ่าน 4MB จากฮาร์ดไดรฟ์ 5 ลูกที่ต่างกัน ก็ยังทำให้ฉันทึ่งอยู่

    • VAST data ใช้ scheme แบบ 146+4 (ลิงก์)

  • ฉันอ่านบทความนี้อย่างเพลิดเพลิน แต่คำตอบของคำถามในชื่อเรื่องมันชัดเจนเกินไป: ความขนาน

    • ปกติฉันแทบไม่เคยคิดเรื่องความเร็ว storage I/O ในสเกลขนาดนั้นมาก่อน สมัยก่อนเคยใช้ RAID0 เพื่อให้ฮาร์ดดิสก์เขียนได้เร็วขึ้น แต่นั่นก็นานมากแล้ว ตอนแรกนึกว่าพวกเขาจะใช้วิธีน่าสนใจอย่าง caching หรือ tiering พออ่านจบถึงได้รู้ว่าคำตอบที่ชัดเจนก็คือความขนานนั่นเอง แต่ก่อนหน้านี้ฉันไม่ได้นึกถึงรายละเอียดระดับ implementation ของ S3 หรือวิธีแก้ไขข้อผิดพลาดของมันเลย คำว่า parallelism คือหัวใจ แต่รายละเอียดก็ให้ insight เยอะมาก ฉันคิดว่า minio ก็น่าจะมีเรื่องเล่าด้าน scalability คล้ายกัน: สรุปก็คือ parallelism เหมือนกัน

    • ฉันคิดว่าชื่อบทความค่อนข้างทำให้สับสนเล็กน้อย เพราะไปโฟกัสที่ peak throughput ของ S3 ทั้งระบบ คำถามที่น่าสนใจจริง ๆ คือ "ทำอย่างไรจึงมี GET throughput ที่สูงกว่า throughput สูงสุดของ HDD ได้" ถ้าเป็นการทำ replication แบบตรงไปตรงมา คุณก็อาจระบุ HDD หลายลูกแล้วทำ GET แบบขนานได้ ทำให้มองจากภาพรวมของ S3 ทั้งระบบ throughput สูงขึ้น แต่สุดท้ายก็ยังติดเพดานที่ throughput ของ HDD รายลูก * จำนวนคำขอ GET อยู่ดี แต่ S3 ไม่มีข้อจำกัดแบบนี้ นี่แหละคือความลับและจุดที่น่าสนใจ

    • เอาฮาร์ดดิสก์มารวมกันหลายล้านลูกก็ได้แบนด์วิดท์ I/O มหาศาล

    • ฟังดูเหมือนตรรกะประมาณว่า "วิธีไปดวงจันทร์นั้นชัดเจน: ก็เดินทางไปสิ"

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    โดยเฉลี่ยแล้ว ถ้าสุ่มสองจุดแบบ uniform บนช่วง [0,1] ค่าคาดหมายของระยะห่างจะไม่ใช่ 0.5 แต่เป็น 1/3 ถ้า full platter seek time คือ 8ms ค่า seek time เฉลี่ยก็ควรเป็น 2.666ms

    • สำหรับไดรฟ์รุ่นใหม่ full seek จะใกล้ 25ms มากกว่า 8ms ถ้าอยากทดสอบเองและมีฮาร์ดดิสก์กับสิทธิ root ก็ใช้ fio พร้อมออปชัน --readonly แล้วสั่งให้อ่านสลับกันที่ต้นและท้ายดิสก์ได้เลย ยังมีงานวิจัยที่อธิบายได้ดีด้วยว่าเหตุใดตัวเลข 1/3 จึงไม่แม่นสำหรับไดรฟ์รุ่นใหม่ (ที่นี่) ถ้ามีคำถามเพิ่มเติมเกี่ยวกับกลไกหรือประสิทธิภาพของ disk drive ฉันก็ตอบได้

    • เวลาเคลื่อนที่ข้ามแทร็กจะมีการเร่งความเร็วของหัวอ่านด้วย ระยะยิ่งสั้น ความเร็วสูงสุดก็ยิ่งต่ำ และยังมี latency คงที่บางส่วนอยู่ด้วย (เช่น settling time) ดังนั้นค่าเฉลี่ยจริงอาจเป็น 4ms ได้

    • เนื่องจาก platter เป็นวงกลม เราจึงไม่ควรใช้การกระจายแบบ uniform บน [0, 1] แต่ควรใช้การกระจายบนวงกลมหนึ่งหน่วย [0, 2π] และเพราะ platter หมุนได้ทิศเดียว ระยะทางจึงควรคำนวณตามเข็มนาฬิกาเท่านั้น
      ถ้าทำปัญหาให้ง่ายลงโดยให้จุดเริ่มต้นเป็น 0 องศา และจุดหมายเป็นตำแหน่งสุ่ม ค่าเฉลี่ยของระยะทางคือเท่าไร? เนื่องจากความยาว arc ของ 0-180 องศา และ 180-360 องศา เท่ากัน ค่าเฉลี่ยของระยะทางจึงเป็น 180 องศา กล่าวคือ half-platter seek คือครึ่งหนึ่งของ full-platter seek แบบพอดี

  • ถ้าอยากเดาว่า S3 ยังใช้ HDD เป็นบริการหลักอยู่ไหม ก็พอจะคำนวณคร่าว ๆ จากราคาแล้วแปลงเป็น IOPS ได้ ราคาคำขอ GET/PUT ของ S3 สูงพอที่ AWS จะยังมีช่องให้ปล่อยพื้นที่ดิสก์ว่างทิ้งไว้เพื่อรองรับ tenant ที่ต้องการประสิทธิภาพสูงได้ แต่ก็ไม่ได้แพงไปมากกว่านั้นนัก

  • ฉันสงสัยว่า S3 บางส่วนรันบน SSD หรือไม่ เดิมทีฉันคิดว่าแม้แต่ S3 มาตรฐานก็น่าจะเป็น SSD และมีแค่ tier ที่ช้ากว่าเท่านั้นที่ใช้ HDD หรือระบบที่ช้ากว่า

    • KeyMap Index ของ S3 ใช้ SSD ณ ตอนนี้ฉันเดาว่า SSD น่าจะถูกใช้กับ hot object cache หรือเป็นส่วนหนึ่งของผลิตภัณฑ์ one zone แบบใหม่อยู่แล้ว

    • ข้อมูลที่เก็บจริง ๆ มีโอกาสสูงมากว่าจะอยู่บน HDD แต่ metadata, index และสิ่งคล้ายกันน่าจะอยู่บน flash storage ที่เร็วกว่าเยอะ แม้แต่ MDS server ของ Ceph cluster ขนาดเล็กก็มักทำแบบนั้นอยู่แล้ว และ S3 มีขนาดใหญ่กว่ามาก

    • มีการพูดถึงไปครั้งหนึ่งแล้วด้านบน แต่สำหรับ standard tier นั้นราคาต่อ request สูงพอที่ถึงจะมีลูกค้าที่มีอัตรา IOPS/TB สูง ก็ยังคุ้มที่จะปล่อยความจุดิสก์บางส่วนว่างไว้ แต่ถ้าสูงกว่านั้นก็ไม่คุ้มแล้ว HDD รุ่นใหม่เก็บได้ราว 30TB และแม้จะไม่รู้ว่า AWS ซื้อจริงที่ราคาเท่าไร แต่ก็น่าจะประมาณ 300-500 ดอลลาร์ ซึ่งถูกกว่า SSD ขนาด 30TB มาก นอกจากนี้ยังสามารถใส่ HDD เหล่านี้ในระบบความหนาแน่นสูงได้ด้วย (เช่น 100 ไดรฟ์ใน 4U) โดยต้นทุนรวมเพิ่มขึ้นแค่ราว 25% ในทางกลับกัน กล่องฮาร์ดแวร์ที่รองรับ SSD จำนวนมากจะมีต้นทุนต่อสล็อตสูงกว่ามาก

    • ฉันเดาว่า S3 Express One Zone น่าจะใช้ SSD เป็นฐาน แม้ดูเหมือนว่า Amazon จะไม่ได้ประกาศเรื่องนี้อย่างเปิดเผย

    • ฉันคาดว่า metadata ต้องเก็บบน SSD แน่นอน และ object ที่ถูกอ่านบ่อย ๆ ก็น่าจะถูก cache บน SSD ได้เช่นกัน

  • น่าทึ่งที่แม้ราคา HDD จะลดลงเรื่อย ๆ แต่ค่าบริการ S3 แทบไม่เปลี่ยนเลยอย่างน้อย 8 ปีที่ผ่านมา การแข่งขันด้านการลดราคามีน้อยเกินไป จึงยังรักษาโครงสร้างราคาสูงแบบนี้ไว้ได้ น่าลองจินตนาการว่าเรื่องนี้สร้างกำไรให้ AWS มากแค่ไหน

    • นโยบายราคาของ AWS ก็คล้ายกันในทุกบริการ เช่น EC2 instance แบบ m7a.medium ราคา on-demand อยู่ที่ 50 ดอลลาร์ต่อเดือน และถ้าจองล่วงหน้า 1 ปีจะอยู่ที่ 35 ดอลลาร์ เทียบกับบริการของเจ้าอื่นที่สเปกใกล้กันแล้ว ความสามารถในการแข่งขันไม่ได้ดีนัก

    • ต้องคำนึงถึงผลของเงินเฟ้อด้วย ดังนั้นแม้ราคาตามตัวเลขจะเท่าเดิม แต่ในเชิงจริงก็ถือว่าราคาลดลง อย่างไรก็ดี ฉันเห็นด้วยว่าเงินเฟ้อสะท้อนช้ากว่าความก้าวหน้าทางเทคโนโลยีมาก

    • ฉันคิดว่าเป้าหมายของแรงจูงใจไม่ใช่การลดต้นทุน ดูจากบริษัทอย่าง Splunk หรือ CrowdStrike ที่เก็บข้อมูลมหาศาลไว้บน AWS จะเห็นว่ามีข้อมูลซ้ำจำนวนมาก พวกเขาเพียงคิดเงินลูกค้าตามนั้น และทำ deduplication แบบง่าย ๆ ถ้าลดต้นทุนลง ก็อาจยิ่งสร้างแรงจูงใจให้เกิดการใช้งานสิ้นเปลืองโดยไม่จำเป็นมากขึ้น

    • ฉันสงสัยว่าราคา HDD ลดลงมากจริงหรือไม่ ในช่วงไม่กี่ปีที่ผ่านมาอัตราการลดลงของราคาต่อ GB ของฮาร์ดดิสก์ชะลอลงมาก จนดูเหมือนว่า SSD อาจตามทันได้ในไม่ช้า

  • ขอยกบทความที่น่าสนใจเกี่ยวกับ S3 อีกชิ้นคือ "Building and operating a pretty big storage system called S3"

  • ฉันสงสัยว่า rustfs ให้ประสิทธิภาพจริงเป็นอย่างไร

  • พอเห็นคำพูดที่ว่ามีการใช้ HDD หลายสิบล้านลูก ก็พอประเมินได้ว่าถ้า enterprise HDD มีความจุระดับ 10-20TB ความจุรวมของ AWS S3 ก็น่าจะอยู่ในระดับหลายร้อย Exabyte อาจเป็นระบบจัดเก็บข้อมูลที่ใหญ่ที่สุดบนโลกก็ได้

    • ถ้าฮาร์ดแวร์ได้รับการอัปเกรดมาตั้งแต่ปี 2013 ศูนย์ข้อมูลบางแห่งในยูทาห์อาจมีความจุเกินกว่านั้นได้ (บทความที่เกี่ยวข้อง)

    • ตอนนี้ enterprise HDD อยู่ที่ 30TB แล้ว และในไม่ช้าก็น่าจะไปถึง 50TB ได้ด้วย

  • อยากรู้ว่ามีบริการโอเพนซอร์สไหนบ้างที่ออกแบบมาสำหรับ HDD โดยเฉพาะและให้ประสิทธิภาพใกล้เคียงกัน โปรเจกต์หลัก ๆ (MinIO, Swift, Ceph+RadosGW, SeaweedFS) ล้วนแนะนำ deployment แบบ all-flash ทั้งนั้น ช่วงนี้ฉันกำลังดูโปรเจกต์ชื่อ Garage อยู่ ซึ่งการออกแบบก็ต่างออกไปพอสมควร เช่น ไม่ใช้ EC

    • Ceph+RadosGW ก็ทำงานกับ HDD ได้ดีพอสมควร เพียงแต่ index pool ควรใช้ SSD และต้องประเมินอย่างเป็นจริงว่า pool HDD จะให้ IOPS ได้เท่าไร เพราะ IOPS ฝั่ง client จริง ๆ แล้วมักถูกคูณขึ้นหลายเท่า ซึ่ง S3 ก็แก้ปัญหานี้ด้วยการใช้ HDD จำนวนมหาศาล สำหรับ large storage แบบสตรีมมิง 4MB นั้นไม่ใช่ปัญหาใหญ่ แต่ถ้ามีการอ่านเขียน random ของ key ขนาดเล็กจำนวนมาก หรือมีการเข้าถึงแบบกระจายเข้าหา key เดียวมาก ๆ ประสิทธิภาพของ backend จะสำคัญมาก

    • Lustre/ZFS ก็ทำความเร็วลักษณะเดียวกันได้ แต่ถ้าต้องการ IOPS สูง ในกรณีของ Lustre จะต้องใช้ flash สำหรับ MDS ส่วน ZFS ต้องมี log SSD โดยเฉพาะ

    • บริการเหล่านี้ทั้งหมดต้องมีไดรฟ์ระดับ data center จำนวนมากพอจึงจะได้ประสิทธิภาพเท่ากัน มี deployment จำนวนน้อยมากที่รองรับสเกลแบบนี้ได้ นี่จึงเป็นเหตุผลว่าทำไม flash จึงมีประสิทธิภาพกว่ามากสำหรับการเข้าถึงแบบรวดเร็วเมื่อเทียบในมิติของพื้นที่และต้นทุน

    • SeaweedFS พัฒนาไปมากในช่วงไม่กี่ปีที่ผ่านมา และเพิ่มการรองรับ RDMA กับ EC แล้ว

    • ที่ทำงานเก่าของฉันเคยรัน object storage บน SwiftStack โดยเก็บ metadata ไว้บน SSD และเก็บข้อมูล object ไว้บน HDD ทั่วไป มันทำงานได้ดีพอสมควร