Regatta Storage (YC F24): เปลี่ยน S3 ให้เป็นระบบไฟล์คลาวด์แบบ POSIX ที่ให้ความรู้สึกเหมือนโลคัล

 (news.ycombinator.com)
5 คะแนน โดย GN⁺ 2024-11-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Regatta Storage เป็นบริการที่ทำให้ใช้สตอเรจที่เข้ากันได้กับ S3 ได้เหมือนระบบไฟล์คลาวด์ที่ซิงก์อัตโนมัติ เหมาะสำหรับจัดการข้อมูลขนาดใหญ่โดยไม่ต้องเพิ่มดิสก์โลคัล
  • มุ่งให้เข้าถึงชุดข้อมูลบน S3 ได้โดยตรงในงาน Spark, PyTorch และ pandas เพื่อลด เวลารอดาวน์โหลด และภาระในการเตรียมดิสก์โลคัลขนาดใหญ่
  • จุดเริ่มต้นมาจากประสบการณ์ด้านการดำเนินงานสตอเรจที่ Amazon EFS และ Netflix โดยแม้ EFS จะมีข้อดีด้านความเรียบง่ายและการขยายตัวได้ แต่เมื่อย้ายจากดิสก์โลคัลไปยัง NFS ก็ยังมี ปัญหาด้านประสิทธิภาพ เหลืออยู่
  • ลูกค้าจะเมานต์ระบบไฟล์ Regatta ผ่าน NFSv3 และอินสแตนซ์แคชของ Regatta จะเชื่อมต่อกับบัคเก็ต S3 ของลูกค้า เพื่อให้ประสิทธิภาพระดับต่ำกว่ามิลลิวินาทีสำหรับการอ่าน·เขียนที่ถูกแคชไว้
  • มีการใช้งานกับ Jupyter Notebook แบบ serverless, เลเยอร์แคชแบบกระจายบน S3 และใช้แทน thin-provisioned Ceph boot volume และในอนาคตกำลังพัฒนา โปรโตคอลไฟล์แบบกำหนดเอง อยู่

มอบประสบการณ์ระบบไฟล์บน S3 ที่ให้ความรู้สึกเหมือนโลคัล

  • Regatta Storage เป็นระบบไฟล์คลาวด์แบบคิดค่าบริการตามการใช้งาน และซิงก์อัตโนมัติกับ สตอเรจที่เข้ากันได้กับ S3
  • เป้าหมายคือเวิร์กโฟลว์ที่สามารถเข้าถึงชุดข้อมูลขนาดใหญ่จาก Spark, PyTorch และ pandas ได้โดยตรง โดยไม่ต้องดาวน์โหลดลงดิสก์โลคัล
  • ดูวิดีโอภาพรวมบริการได้ที่ YouTube และสามารถสมัครบัญชีเพื่อทดลองใช้ฟรีได้
  • เหตุผลที่ไม่ได้ให้ทดลองโดยไม่ต้องมีบัญชี คือมองว่าไม่เหมาะที่ผู้ใช้ Hacker News จะใช้ระบบไฟล์เดียวกันและบัคเก็ต S3 เดียวกันร่วมกัน

เบื้องหลังการออกแบบจากประสบการณ์กับ EFS

  • ผู้ก่อตั้งสร้าง Regatta จากประสบการณ์ 8 ปีที่ Amazon Elastic File System (EFS) และจากการสร้าง·ดำเนินงานสตอเรจคลาวด์ขนาดใหญ่ที่ Netflix และที่อื่น ๆ
  • EFS มีข้อดีด้านความเรียบง่ายและการขยายตัวได้ เพราะไม่ต้องประเมินความจุที่ต้องใช้ล่วงหน้าเหมือน S3 แต่ที่ Netflix กลับไม่ได้ถูกใช้งานมากเท่าที่คาด
    • แอปพลิเคชันจำนวนมากต้องการระบบไฟล์ POSIX และความต้องการสตอเรจอาจไม่ชัดเจนหรืออาจพุ่งสูงขึ้นอย่างรวดเร็ว
    • หลายกรณีต้องการสตอเรจที่คงอยู่ยาวนานกว่าอายุของอินสแตนซ์หรือคอนเทนเนอร์
    • ไดรฟ์โลคัลมักถูกโปรวิชันเกินความจำเป็นตามปริมาณการใช้งานที่อาจเกิดขึ้น ทำให้ต้องเสียค่าใช้จ่ายแม้กับ พื้นที่สตอเรจว่าง
  • EFS ไม่ได้เหมาะกับทุก workload
    • เมื่อย้ายจากดิสก์โลคัลไปยัง NFS บางกรณีเกิด ปัญหาด้านประสิทธิภาพ
    • แอปพลิเคชันที่เคยใช้ดิสก์โลคัลเหมือนพื้นที่เก็บข้อมูลชั่วคราว ต้องคอยล้างข้อมูลที่เหลืออยู่ในสตอเรจถาวรด้วยตนเอง

วิธีทำงานของ Regatta และโมเดลแคช

  • Regatta ถูกออกแบบเป็นระบบไฟล์แบบ คิดค่าบริการตามการใช้งาน ที่ auto-scale ไปพร้อมกับแอปพลิเคชัน
    • ซิงก์อัตโนมัติกับ S3 ในรูปแบบไฟล์เนทีฟ จึงเชื่อมต่อกับชุดข้อมูลเดิมได้
    • ข้อมูลไฟล์ที่เพิ่งเขียนก็สามารถใช้งานได้โดยตรงจาก S3
    • ข้อมูลที่ไม่ได้ถูกใช้งานอย่างต่อเนื่องจะถูกนำออกจากแคชของ Regatta ทำให้เสียค่าใช้จ่ายเฉพาะสตอเรจ S3 ฝั่ง backend เท่านั้น
  • ปัจจุบันลูกค้าเมานต์ระบบไฟล์ Regatta โดยเชื่อมต่อผ่าน NFSv3 เข้ากับฟลีตอินสแตนซ์แคชของ Regatta
    • อินสแตนซ์ Regatta เชื่อมต่อกับบัคเก็ต S3 ของลูกค้าในฝั่ง backend
    • ให้ประสิทธิภาพระดับต่ำกว่ามิลลิวินาทีสำหรับการอ่านและเขียนที่ถูกแคชไว้
    • แคชที่มีความคงทนช่วยให้ไคลเอนต์ไฟล์ทั้งหมดที่เชื่อมต่ออยู่เห็นมุมมองระบบไฟล์ที่มีความสอดคล้องอย่างเข้มงวด
    • งานที่จัดการยากอย่างการเปลี่ยนชื่อไดเรกทอรี จะถูกประมวลผลอย่างรวดเร็วและทนทาน แล้วจึงเผยแพร่ไปยังบัคเก็ต S3 แบบอะซิงโครนัส

กรณีใช้งานช่วงแรกและขั้นตอนถัดไป

  • ผู้ใช้ช่วงแรกกำลังใช้ Regatta สำหรับเซิร์ฟเวอร์ Jupyter Notebook แบบ serverless สำหรับนักวิจัย AI, เลเยอร์แคชแบบกระจายความหน่วงต่ำบน S3 และใช้แทน thin-provisioned Ceph boot volume
  • โปรโตคอลไฟล์แบบกำหนดเอง ที่กำลังพัฒนา มีเป้าหมายให้ได้ประสิทธิภาพใกล้เคียงโลคัลสำหรับ workload ที่มีไฟล์ขนาดเล็ก และให้ประสิทธิภาพแบบ scale-out คล้าย Lustre สำหรับงานข้อมูลแบบกระจาย

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

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

 
GN⁺ 2024-11-19
ความคิดเห็นใน Hacker News

  • ความแตกต่างระหว่าง Rclone กับ Regatta Storage คือ Regatta ใช้เลเยอร์แคชความเร็วสูงระหว่างการแก้ไขเปลี่ยนแปลงไฟล์ระบบ เพื่อให้มีความสอดคล้องกันอย่างเข้มงวด ส่วน Rclone ไม่มีเลเยอร์ที่รับประกันความสอดคล้องระหว่างไคลเอนต์แบบขนาน

    • Regatta Storage ใช้เลเยอร์แคชความเร็วสูงระหว่างการแก้ไขเปลี่ยนแปลงไฟล์ระบบ เพื่อให้มีความสอดคล้องกันอย่างเข้มงวด
    • Rclone ไม่มีเลเยอร์ที่รับประกันความสอดคล้องระหว่างไคลเอนต์แบบขนาน

  • เป็นหนึ่งในผลิตภัณฑ์ที่เจ๋งที่สุดจาก YC และมีคำถามหลายข้อเกี่ยวกับวิธีการทำงาน

    • สงสัยว่าจะมีประสิทธิภาพลดลงหรือไม่เมื่อจัดการข้อมูลขนาดราว 50GB บนดิสก์ภายในเครื่องขนาด 10GB
    • สงสัยว่าสามารถได้ความเร็วสูงบนคลาวด์เจ้าอื่นนอกเหนือจาก AWS หรือไม่
    • มีข้อสงสัยเกี่ยวกับวิธีการใช้การเมานต์ FUSE และ NFS
    • สงสัยว่าสามารถรัน Clickhouse หรือ Postgres บน Regatta volume ได้หรือไม่
    • สงสัยว่าบริษัทมีแนวคิดอย่างไรเกี่ยวกับโอเพนซอร์ส
    • สงสัยว่าสามารถเมานต์บนหลายเซิร์ฟเวอร์ได้หรือไม่ และมีข้อจำกัดอะไรบ้าง

  • กำลังโฮสต์ DuckDB โดยใช้ GCP Filestore และขอข้อมูลเกี่ยวกับราคาและประสิทธิภาพของ Regatta

    • ขอข้อมูลราคาและประสิทธิภาพของอินสแตนซ์ขนาด 10 TiB

  • สนใจใช้เป็นดิสก์สำรองสำหรับ SQLite/DuckDB/parquet และต้องการการอ่านแบบแคชจากสตอเรจ NVMe ภายในเครื่องของอินสแตนซ์

    • ต้องการความสามารถด้านการล็อกและ shared memory ที่ NFS ให้ไม่ได้
    • สามารถทำเองได้โดยตรงใน user space แต่ถ้าจะทำแบบนั้นก็จะใช้ S3 ไปเลย

  • คิดว่าการใช้ NFS เป็นโปรโตคอลเป็นไอเดียที่ดี

    • เคยมีประสบการณ์เขียนระบบไฟล์แบบเข้ารหัสที่มีแนวคิดคล้ายกันที่ IBM
    • เวลาที่เมานต์ไฟล์ระบบแล้วข้อมูลทั้งหมด "อยู่ตรงนั้นเลย" ให้ความรู้สึกเหมือนเวทมนตร์

  • มีความกังวลว่า AWS อาจคัดลอกผลิตภัณฑ์นี้และขายในราคาที่ถูกกว่า

  • เคยมีประสบการณ์เดโมต่อหน้า CEO ของ Adobe ในปี 2008 โดยถ่ายรูปด้วย iPhone แล้วรูปนั้นปรากฏเป็นไฟล์บน Mac โดยอัตโนมัติได้สำเร็จ

    • ใช้ FUSE เพื่อทำ local FUSE ที่สื่อสารกับระบบ distributed object storage ของ Adobe
    • เริ่มทำวิจัยและพัฒนาระบบ distributed system พร้อมกับการเปิดตัวของ Dropbox

  • สงสัยว่าสามารถใช้ Lambda + SQLite + Regatta เพื่อสร้าง real-time ACID SQL storage ได้หรือไม่

  • ยังไม่ชัดเจนว่าจัดการกับการชนกันของการอัปเดตไฟล์อย่างไร

    • ตัวอย่างเช่น หากผู้ใช้สองคนอัปเดตไฟล์เดียวกันจากคนละเครื่อง ไฟล์สุดท้ายจะออกมาเป็นอย่างไร

  • มีทางเลือกที่น่าสนใจอื่น ๆ เช่น s3fs, rclone, goofys เป็นต้น