10 คะแนน โดย GN⁺ 2025-04-12 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

> "โปรโตคอลแบบมีสถานะของ Colossus" คือส่วนผสมลับที่ทำให้ Rapid Storage มีประสิทธิภาพสูง

  • Google Cloud Storage ถูกใช้อย่างแพร่หลายเพราะความเรียบง่ายและการขยายขนาด
  • โปรโตคอลแบบไร้สถานะที่อิง REST แบบเดิมใช้งานง่าย แต่มีปัญหาเรื่องเวลาแฝงและขาดความสามารถแบบเน้นไฟล์สำหรับเวิร์กโหลด AI และงานที่ใช้ข้อมูลเข้มข้น
  • Rapid Storage แก้ปัญหานี้ด้วยการนำโปรโตคอลสตรีมมิง gRPC แบบมีสถานะมาใช้ โดยยังคงความสามารถในการขยายขนาดและทรูพุตของอ็อบเจ็กต์สตอเรจไว้

จุดแข็งของสถาปัตยกรรมที่ขับเคลื่อนด้วย Colossus

  • Colossus เป็นระบบไฟล์ระดับคลัสเตอร์ภายในของ Google และเป็นเทคโนโลยีพื้นฐานสำหรับผลิตภัณฑ์ประสิทธิภาพสูง
  • รองรับการอ่าน/เขียนข้อมูลแบบเวลาแฝงต่ำมากด้วยโปรโตคอลแบบมีสถานะ
  • ไคลเอนต์สามารถเปิดไฟล์เพื่อรับ แฮนเดิล (handle) และใช้แฮนเดิลนั้นสื่อสารกับดิสก์ได้โดยตรง
  • ใช้โปรโตคอลลักษณะคล้าย RDMA เพื่อให้เข้าถึงได้รวดเร็ว พร้อมการปรับให้เหมาะกับ SSD และเทคนิคการเขียนแบบขนาน
  • เหมาะกับเวิร์กโหลดการเขียนล็อกและการวิเคราะห์แบบสตรีมมิงที่ต้องการความทนทานของข้อมูล

วิธีการทำงานของโปรโตคอลแบบมีสถานะของ Colossus

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

ประสิทธิภาพและตัวอย่างการใช้งานของ Rapid Storage

  • ไคลเอนต์ Cloud Storage จะเตรียมการยืนยันตัวตนและการเข้าถึงเมตะดาต้าล่วงหน้าเมื่อสร้าง gRPC stream
  • หลังจากนั้นการอ่าน/เขียนจะเชื่อมต่อกับ Colossus โดยตรง จึงคงเวลาแฝงที่ต่ำมากไว้ได้
  • รองรับได้ถึง 20 ล้านคำขอต่อวินาทีต่อหนึ่งบักเก็ต — เหมาะกับเวิร์กโหลด AI/ML ขนาดใหญ่
  • การออกแบบที่เหมาะกับการฝึก AI/ML โดยเฉพาะ

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

    • สามารถ append ไปยังอ็อบเจ็กต์เดียวได้ไม่จำกัด (ภายในข้อจำกัดขนาดอ็อบเจ็กต์)
    • ด้วยแฮนเดิล แม้สตรีมจะถูกตัดก็สามารถเชื่อมต่อใหม่แล้วอ่าน/เขียนต่อได้
    • มีเพียงหนึ่งสตรีมต่อครั้งเท่านั้นที่สามารถเขียนลงอ็อบเจ็กต์ได้ — สตรีมใหม่จะล็อกสตรีมก่อนหน้าในลักษณะธุรกรรม
    • แต่ละ append จะระบุออฟเซ็ตที่เขียนเพื่อรับประกันความสอดคล้องของข้อมูล

การผสานรวมและ API ของ Rapid Storage

  • กำลังอัปเดต SDK เพื่อรองรับความสามารถ append บน gRPC
  • ผสานรวมเข้ากับ Cloud Storage FUSE ทำให้เข้าถึงบักเก็ต Cloud Storage ได้เหมือนเป็นระบบไฟล์
  • ทำงานร่วมกับ Hierarchical Namespace เพื่อเสริมทั้งประสิทธิภาพและความสอดคล้อง พร้อมรองรับ API แบบโฟลเดอร์

จุดเด่นแบบผสมผสานของ Rapid Storage

  • เวลาแฝงต่ำมากในระดับบล็อกสตอเรจ
  • ทรูพุตสูงในระดับระบบไฟล์แบบขนาน
  • พร้อมมอบทั้งการขยายขนาดและความเรียบง่ายของอ็อบเจ็กต์สตอเรจ

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

 
ethanhur 2025-04-14

เห็นว่า Colossus ดีมาก เลยอยากรู้ว่าคนที่ได้ใช้งานจริงภายในคิดว่ายังไงบ้างครับ

 
GN⁺ 2025-04-12
ความคิดเห็นบน Hacker News
  • Google เป็นผู้ให้บริการคลาวด์รายใหญ่เพียงรายเดียวที่มีทั้ง object storage แบบ single-zone หน่วงต่ำ, object storage แบบ regional มาตรฐาน และ object storage แบบ dual-region ที่ทำสำเนาแบบโปร่งใส ผ่าน API เดียวกัน
    • ในระบบโครงสร้างพื้นฐาน สามารถเขียนโค้ดด้วย GCS API แล้วให้ผู้ใช้เลือกจุดสมดุลระหว่างต้นทุน, ความหน่วง และความทนทานได้
  • มีการประกาศในงานประชุม Google Next 2025 และเปิดตัว gRPC client สำหรับ Rapid Storage
    • ดูเหมือนว่านี่จะเป็น thin wrapper ของ Colossus เอง และเป็น single-zone storage
  • ดูเหมือนว่าน่าจะช่วยเพิ่มความเร็วให้ scientific computing ได้จริง
    • การทำข้อมูลให้เป็น local/non-local เป็นส่วนสำคัญของเวลารันอินสแตนซ์ทั้งหมด
  • ต้องกลับไปดูวิดีโอ microservices คลาสสิกอีกครั้ง
    • เคยนึกว่าใช้ Colossus แต่จริง ๆ แล้วเป็น Galactus & Omega Star
  • ลิงก์นี้เข้าใจง่ายกว่าลิงก์ก่อนหน้ามาก
  • ความเร็ว random I/O สูงของ SSD น่าจะมีส่วนสำคัญต่อข้อดีนี้อย่างมาก
    • ความเร็วเขียน 20m ต่อวินาทีดูเหมือนจะเป็นไปได้จากการกระจายไปยังเครือข่ายของไดรฟ์
  • ดีใจที่เห็น object storage แบบ single-zone ตั้งหลักได้สำเร็จ
    • ความเร็วแบนด์วิดท์มหาศาลจะนิยามงานวิเคราะห์ข้อมูลใหม่
    • 99% ของทุก query น่าจะรันบนโหนดเดียวได้เร็วกว่าการประมวลผลแบบกระจาย
  • อยากได้ Chubby แบบ as a service
    • จะได้เลิกใช้ etcd กับ zookeeper
  • คล้ายกับ S3 express one zone
  • สงสัยว่านี่เกี่ยวข้องกับ anywhere caches แบบเชิญเฉพาะบุคคลหรือไม่
    • หรือไม่ตอนนี้อาจเป็น GA แล้วก็ได้