S3 Files และภาพลักษณ์ที่เปลี่ยนไปของ S3

• เพื่อลดความไม่มีประสิทธิภาพของการย้ายข้อมูลขนาดใหญ่ จึงมีการเปิดตัว S3 Files ที่ทำให้สามารถ เข้าถึงข้อมูลใน S3 ได้โดยตรงเหมือนเป็นระบบไฟล์
• ฟีเจอร์นี้ ผสาน Amazon EFS กับ S3 ทำให้สามารถ เมานต์ S3 bucket เป็น NFS เพื่ออ่านและเขียนได้จาก EC2, คอนเทนเนอร์, Lambda เป็นต้น
• ภายในใช้โครงสร้าง stage และ commit เพื่อสะท้อนการเปลี่ยนแปลงไปยัง S3 เป็นระยะ และรองรับ การซิงก์สองทางระหว่างไฟล์กับอ็อบเจ็กต์
• S3 Files ทำหน้าที่เป็นองค์ประกอบหลักในการขยาย S3 ไปสู่ แพลตฟอร์มข้อมูลแบบรวมศูนย์ ร่วมกับ S3 Tables, S3 Vectors
• ตอนนี้ S3 กำลังก้าวข้ามจากการเป็นเพียงสตอเรจ ไปสู่ พื้นที่ทำงานแบบรวมศูนย์ที่ขับเคลื่อนด้วยข้อมูล ซึ่งเป็นรากฐานให้นักพัฒนานำข้อมูลไปใช้งานได้โดยตรง

---

การเปลี่ยนแปลงของ S3 และการออกแบบ S3 Files

• ความยากของการย้ายข้อมูลและจุดเริ่มต้นของ S3 Files

  • กระบวนการย้ายข้อมูลขนาดใหญ่เป็น สาเหตุของความไม่มีประสิทธิภาพอย่างต่อเนื่อง ในหลากหลายอุตสาหกรรม ตั้งแต่งานวิจัยทางวิทยาศาสตร์ไปจนถึงแมชชีนเลิร์นนิง
  • ในกรณีงานวิจัยจีโนมของ UBC นักวิจัยต้องใช้เวลาอย่างมากกับ การคัดลอกข้อมูลระหว่าง S3 กับระบบไฟล์ภายในเครื่อง
  • data friction ลักษณะนี้เกิดขึ้นเพราะเครื่องมือต่าง ๆ เข้าถึงข้อมูลกันคนละแบบ
  • S3 Files ถูกออกแบบมาเพื่อลดแรงเสียดทานนี้ โดยทำให้ เข้าถึงข้อมูลใน S3 ได้โดยตรงเหมือนเป็นระบบไฟล์

• การพัฒนาแบบเอเจนต์และความสำคัญของข้อมูล

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

primitive ข้อมูลแบบใหม่ของ S3

• S3 Tables

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

• S3 Vectors

  • การพัฒนาของ AI ทำให้ความต้องการ vector index เพิ่มขึ้น
  • เดิมทีฐานข้อมูลเวกเตอร์จะเก็บดัชนีไว้ในหน่วยความจำหรือ SSD แต่แนวทางนี้มี ข้อจำกัดด้านต้นทุนและการขยายระบบ
  • S3 Vectors มอบ vector index ที่ยืดหยุ่นเต็มรูปแบบ โดยมี โปรไฟล์ด้านต้นทุน ประสิทธิภาพ และความทนทาน คล้ายกับอ็อบเจ็กต์ของ S3
  • สามารถขยายได้ตั้งแต่หลักร้อยไปจนถึงหลายพันล้านเรคคอร์ด และมี API endpoint สำหรับ scalar similarity search

การมาถึงของ S3 Files

• ภาพรวม

  • S3 Files ผสาน Amazon EFS เข้ากับ S3 ทำให้ เข้าถึงข้อมูลใน S3 ได้โดยตรงเหมือนระบบไฟล์เครือข่าย (NFS)
  • สามารถ เมานต์ S3 bucket หรือ prefix จาก EC2, คอนเทนเนอร์, Lambda เป็นต้น แล้วอ่านเขียนได้เหมือนไฟล์
  • การเปลี่ยนแปลงจะถูกสะท้อนไปยัง S3 โดยอัตโนมัติ จึงรองรับ การซิงก์สองทางระหว่างไฟล์กับอ็อบเจ็กต์

• โจทย์ยากด้านการออกแบบ

  • ระบบไฟล์กับ object storage มี โมเดลข้อมูลที่แตกต่างกันโดยพื้นฐาน
  • ในช่วงแรกพยายามจะรวม EFS กับ S3 แบบตรง ๆ แต่สุดท้ายเหลือเพียง “การประนีประนอมที่ยอมรับได้ยาก (unpalatable compromises)”
  • ไฟล์รองรับ การเปลี่ยนแปลงแบบละเอียดและการเข้าถึงพร้อมกัน ขณะที่อ็อบเจ็กต์ตั้งอยู่บนสมมติฐานของ ความไม่เปลี่ยนรูปและการอัปเดตทั้งก้อน
  • ระบบแจ้งเตือนเหตุการณ์ ของ S3 รองรับการแจ้งเตือนมากกว่า 3 แสนล้านครั้งต่อวัน และทำงานบนพื้นฐานของการเปลี่ยนแปลงระดับอ็อบเจ็กต์

หลักการออกแบบ Stage and Commit

• เปลี่ยนเส้นแบ่งให้เป็นฟีเจอร์

  • แทนที่จะซ่อนความต่างระหว่างไฟล์กับอ็อบเจ็กต์ ระบบกลับ ออกแบบให้เป็นเส้นแบ่งที่ชัดเจน
  • การเปลี่ยนแปลงจะถูก stage (เก็บชั่วคราว) ไว้ใน EFS และจะถูก commit ไปยัง S3 เป็นระยะ
  • แนวทางนี้ได้แรงบันดาลใจจากแนวคิดการจัดการเวอร์ชันของ Git ทำให้สามารถ ควบคุมการส่งข้อมูลตามเวลาและนโยบาย ได้

• ความสอดคล้องและ atomicity

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

• การจัดการสิทธิ์

  • นโยบาย IAM ของ S3 และ สิทธิ์แบบ inode-based ของระบบไฟล์มีโครงสร้างต่างกัน
  • S3 Files แยกสองระบบนี้ออกจากกันผ่าน การกำหนดสิทธิ์ระดับการเมานต์
  • นโยบาย IAM ของ S3 ยังคงทำหน้าที่เป็น backstop ขั้นสุดท้าย เพื่อควบคุมการเข้าถึงเมื่อเส้นแบ่งของข้อมูลเปลี่ยนไป

• ความไม่สอดคล้องกันของ namespace

  • S3 ไม่มีแนวคิดเรื่องไดเรกทอรี และยังสามารถกำหนด ตัวคั่นพาธ (delimiter) ได้อย่างอิสระ
  • เพื่อแก้ความไม่สอดคล้องกับระบบไฟล์ ระบบจึง คงกฎการตั้งชื่อของทั้งสองฝั่งไว้ตามเดิม
  • สำหรับอ็อบเจ็กต์ที่ไม่เข้ากัน จะไม่ถูกย้าย แต่จะ สร้างอีเวนต์ให้นักพัฒนาจัดการเอง

• ประสิทธิภาพและ latency

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

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

• โครงสร้างพื้นฐาน

  • S3 Files ใช้ EFS เป็นแบ็กเอนด์ เพื่อมอบประสบการณ์แบบระบบไฟล์
  • เมื่อเข้าถึงไดเรกทอรี ระบบจะดึง metadata จาก S3 มาสร้าง มุมมองที่ซิงก์แล้ว และสำหรับไฟล์ขนาดไม่เกิน 128KB ก็จะโหลดข้อมูลทันที
  • ไฟล์ขนาดใหญ่จะใช้ lazy hydration เพื่อดึงข้อมูลเมื่อจำเป็น
  • การเปลี่ยนแปลงจะถูก commit ไปยัง S3 ด้วย PUT เดียวประมาณทุก 60 วินาที พร้อมทำการซิงก์สองทาง

• ความขัดแย้งและการจัดการ

  • หากมีการแก้ไขพร้อมกันทั้งสองฝั่ง จะถือว่า S3 คือ source of truth
  • ไฟล์ที่เกิดความขัดแย้งจะถูกย้ายไปยัง ไดเรกทอรี lost+found และถูกบันทึกผ่าน CloudWatch metrics
  • ไฟล์ที่ไม่มีการเข้าถึงเป็นเวลา 30 วันจะถูก ลบออกจากมุมมองระบบไฟล์ เพื่อเพิ่มประสิทธิภาพด้านต้นทุน

• การปรับแต่งประสิทธิภาพ

  • ฟีเจอร์ read bypass ช่วยให้เมื่ออ่านข้อมูลลำดับต่อเนื่องขนาดใหญ่ ระบบจะอ่านจาก S3 โดยตรงด้วยคำขอ GET แบบขนาน

    • ทำ throughput ได้ 3GB/s ต่อไคลเอนต์ และเมื่อมีหลายไคลเอนต์ก็ ขยายได้ถึงระดับเทราบิต

• ข้อจำกัดและสิ่งที่จะปรับปรุง

  • เนื่องจาก S3 ไม่มีโอเปอเรชัน rename แบบ native การเปลี่ยนชื่อไดเรกทอรีจึงต้องคัดลอกและลบทั้งหมด
  • การเมานต์ที่มีอ็อบเจ็กต์มากกว่า 50 ล้านรายการจะมีการแสดงคำเตือน
  • การควบคุม commit แบบ explicit ยังไม่รวมอยู่ในเวอร์ชันแรก
  • คีย์อ็อบเจ็กต์บางส่วน ไม่สามารถแสดงเป็นชื่อไฟล์แบบ POSIX ได้ จึงถูกตัดออกจากมุมมองแบบไฟล์

ความหลากหลายของข้อมูลและวิวัฒนาการของ S3

• การอยู่ร่วมกันของวิธีเข้าถึงข้อมูล

  • เช่นเดียวกับกรณีงานวิจัยของ UBC นักพัฒนายังต้องใช้เวลามากกับ การย้ายข้อมูล การแคช และการจัดการชื่อ
  • ทีม S3 ใช้ Tables, Vectors, Files เพื่อ รองรับและรวมวิธีเข้าถึงข้อมูลที่หลากหลาย
  • แทนที่จะพยายามลบความแตกต่างระหว่างไฟล์กับอ็อบเจ็กต์ ระบบเลือก ยอมรับคุณลักษณะของแต่ละแบบและทำให้เส้นแบ่งกลายเป็นฟีเจอร์

• บทบาทที่ขยายออกของ S3

  • S3 กำลังพัฒนาจาก object storage ทั่วไปไปเป็น แพลตฟอร์มสตอเรจแบบรวมศูนย์ที่รองรับข้อมูลหลายรูปแบบ
  • ผ่าน Tables, Vectors, Files ทำให้สามารถ นำข้อมูลไปใช้ได้โดยตรงตามลักษณะการทำงาน
  • เป้าหมายคือทำให้สตอเรจ ไม่ใช่อุปสรรคของงาน แต่เป็นโครงสร้างพื้นฐานที่โปร่งใสอยู่เบื้องหลัง
  • ในอนาคตยังมีแผนขยายฟีเจอร์ต่อ เช่น การควบคุม stage/commit, การผสานกับ pipeline

• บทสรุป

  • S3 Files ผสานข้อดีของทั้งสองฝั่งไว้ โดยยังคง เส้นแบ่งที่ชัดเจนระหว่างไฟล์กับอ็อบเจ็กต์
  • S3 ที่เริ่มต้นจาก object storage เมื่อ 20 ปีก่อน ตอนนี้กำลังพัฒนาเป็น พื้นที่ทำงานแบบรวมศูนย์ที่มีข้อมูลเป็นศูนย์กลาง
  • เช่นเดียวกับข้อความ “Go build!” ตอนนี้ S3 ได้กลายเป็นรากฐานที่ช่วยให้นักพัฒนาทดลองและสร้างสิ่งต่าง ๆ ด้วยข้อมูลได้เร็วขึ้น

[xguru]

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

ตอนนี้ S3 กำลังขยายตัวไปเป็นแพลตฟอร์มข้อมูลที่ครอบคลุมทั้งไฟล์ ตาราง และเวกเตอร์

ให้ความรู้สึกเหมือน S3 ที่เคยเป็นจุดเริ่มต้นของโครงสร้างพื้นฐานคลาวด์สมัยใหม่ กำลังถูกนิยามขึ้นใหม่อีกครั้งหลังผ่านไป 20 ปี

[rtyu1120]

แม้ว่า S3 จะไม่ได้แชร์โครงสร้างไฟล์กันแบบโปร่งใส แต่ก็มีโอเพนซอร์สชื่อ ZeroFS ที่ใช้ S3 เป็นฐานข้อมูลเพื่อรันไฟล์ซิสเต็มที่รองรับ POSIX อยู่ด้วยครับ มีชื่อเสียงพอสมควรจากเดโมที่รัน PostgreSQL บน S3

https://www.zerofs.net/

[rtyu1120]

มีบทความจาก Archil ซึ่งก่อตั้งโดยอดีตวิศวกร S3 ที่นำมาเปรียบเทียบกับผลิตภัณฑ์ของบริษัทด้วย เลยอ่านควบคู่กันแล้วสนุกดีครับ ฮ่าๆ

https://x.com/jhleath/status/2042613823522377933

[GN⁺]

ความเห็นจาก Hacker News

• นี่คือโครงสร้างที่ใช้ S3FS เป็นหลัก แต่ใช้ EFS (บริการ NFS แบบจัดการของ AWS) เป็นชั้นแคชสำหรับข้อมูลที่ใช้งานอยู่และการเข้าถึงแบบสุ่มขนาดเล็ก
  ปัญหาคือมันพ่วงเอา โครงสร้างค่าบริการที่แพงของ EFS มาด้วย
  — งานเขียนทั้งหมดคิดที่ $0.06 ต่อ GB ซึ่งอาจร้ายแรงมากสำหรับเวิร์กโหลดที่เน้นการเขียน
  — การอ่านจากแคชคิดที่ $0.03 ต่อ GB และการอ่านขนาดใหญ่เกิน 128KB จะสตรีมตรงจากบัคเก็ต S3 โดยไม่เสียค่าใช้จ่าย
  — แคชมีค่าใช้จ่าย $0.30 ต่อ GB ต่อเดือน แต่ดูเหมือนว่าจะเก็บถาวรเป็นหลักแค่ไฟล์เล็กกว่า 128KB ดังนั้นต้นทุนน่าจะไม่สูงมาก

  • สงสัยว่าจริงไหมที่การอ่านไฟล์ใหญ่ (>128KB) จะไม่ผ่านแคชเสมอ
    เพราะ latency ของ S3 ค่อนข้างแย่จนน่ากังวล

• ประโยคที่ว่า “NFS provides the semantics your applications expect” เป็นอะไรที่ตลกที่สุดเท่าที่เคยเห็นมา

  • แอปพลิเคชันไม่ได้คาดหวังว่าพอเครือข่ายหลุดครั้งเดียวแล้ว system call จะค้างรอแบบไม่สิ้นสุด และไฟล์ซิสเต็มจะอยู่ในสภาพ unmount ไม่ได้

• Hugging Face Buckets ก็เพิ่งเพิ่มความสามารถในการเมานต์บัคเก็ตให้เหมือนไฟล์ซิสเต็มได้เช่นกัน
  บันทึกการเปลี่ยนแปลง hf-mount

• ผมสงสัยเรื่องการซิงก์อยู่เหมือนกัน
  ตาม เอกสารของ AWS ระบุว่า
  ถ้าแก้ไข /mnt/s3files/report.csv แล้วมีการอัปโหลดเวอร์ชันอื่นขึ้นไปยังบัคเก็ต S3 เวอร์ชันของผมเมื่อเกิดคอนฟลิกต์จะถูกย้ายไปที่ไดเรกทอรี .s3files-lost+found-file-system-id และถูกแทนที่ด้วยเวอร์ชันจากบัคเก็ต
  กล่าวคือมี ไดเรกทอรีกู้คืนอัตโนมัติเมื่อเกิดคอนฟลิกต์ อยู่

• FiberFS ก็กำลังอยู่ในช่วงใกล้ออกรีลีสทางการครั้งแรก
  มี แคชในตัว, รองรับ CDN, เมตาดาตาแบบ JSON, และความปลอดภัยด้านการทำงานพร้อมกัน โดยรองรับสตอเรจที่เข้ากันได้กับ S3 ทั้งหมด

  • อยากรู้ว่าเมื่อเทียบกับ FUSE implementation ของ Amazon เองแล้วเป็นอย่างไร ตอนนี้ออกมาถึงเวอร์ชันที่สามแล้ว

• อยากให้ AWS มีบริการเชื่อมแบบจัดการกับ สตอเรจ NVMe บนเครื่องโลคัล
  NVMe เร็วกว่า EBS มาก และ EBS ก็เร็วกว่า EFS
  ถ้ามีชั้นแคชบน NVMe ก็น่าจะได้ความเร็วดีพอสมควร แต่ตัวเลือกแบบรวมทุกอย่างให้เลยน่าจะดีกว่า

  • ถ้า EFS เป็นแค่ NFS mount ธรรมดา ก็น่าจะต่อโวลุ่ม NVMe แล้วตั้งค่า cachefilesd เพื่อทำเองได้
    ตัวอย่างเช่น

    mkfs.ext4 /dev/nvme0n1 && \
    mount /dev/nvme0n1 /var/cache/fscache && \
    mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files
    

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

• จำได้ว่าเมื่อก่อน AWS บอกว่าอย่าใช้ S3 เป็นไฟล์ซิสเต็ม เลยสงสัยว่าทำไมตอนนี้ถึงเปลี่ยนท่าที

  • คราวนี้ดูเหมือนเป็นโครงสร้างที่วางไฟล์ซิสเต็มจริง (EFS) ไว้ด้านหน้า S3 แล้วทำ การซิงก์แบบโปร่งใส
    ในบล็อกก็พูดถึงข้อควรระวังอย่าง ปัญหาความสอดคล้องกัน หรือ การจัดการชื่ออ็อบเจ็กต์ ด้วย
    ในฐานะคนที่ชอบ S3 ผมคิดว่านี่เป็นทางประนีประนอมที่ค่อนข้างดี
  • สถาปนิกของลูกค้ารายใหญ่ใช้ S3 เหมือนไฟล์ซิสเต็มกันมานานแล้ว
    แรงกดดันจาก support ticket ที่ AWS ได้รับ และคำถามแนว “ทำไมถึงทำไม่ได้” คงสะสมมาจนสุดท้ายออกมาเป็นทิศทางนี้
    ส่วนตัวผมไม่ค่อยชอบนัก เพราะมันเป็นแนวทางแบบ “เอาของที่ต่างกันโดยพื้นฐานมาห่อใหม่” แต่ก็ดูเป็นอีกกรณีของแรงกดดันทางสังคมจาก $$$
  • นี่ดูเหมือนเป็นกลยุทธ์เพื่อดึงผู้ใช้ที่มีทักษะทางเทคนิคน้อยลงเข้ามา
    เพราะแม้แต่คนที่ใช้เครื่องมืออย่าง “S3asYourFS.exe” ก็อาจกลายเป็นลูกค้า AWS ได้
    แต่พอนึกถึง ความสามารถด้านซัพพอร์ตลูกค้า ของ AWS แล้ว ก็ยังไม่แน่ใจว่านี่เป็นการตัดสินใจที่ฉลาดหรือไม่
    ถึงอย่างนั้นแรงจูงใจจากการมีผู้ใช้จ่ายเงินรายเดือนเพิ่มขึ้นก็คงสูงมาก
  • ถ้ายังไงผู้คนก็จะใช้ S3 เป็นไฟล์ซิสเต็มอยู่แล้ว การ รองรับอย่างเป็นทางการ ก็น่าจะดีกว่า
  • ท้ายที่สุด AWS ก็แค่เอาแคชมาไว้ข้างหน้าแล้วสร้าง โมเดลหารายได้ ขึ้นมา
    สำหรับผู้ใช้ ประสิทธิภาพดีขึ้น และฝั่ง AWS ก็ลดภาระลง
    จะประหยัดเงินหรือไม่ก็อาจแล้วแต่กรณี

• สงสัยว่าถ้าเอาไว้เก็บ ฐานข้อมูล SQLite จะเป็นอย่างไร
  น่าจะใช้ได้แค่กับรีพลิกาแบบอ่านอย่างเดียว และคงใช้ทำแบ็กอัปแบบ Litestream ไม่ได้

  • กลไกล็อกของ SQLite ไม่ปลอดภัยบน NFS เลยใช้งานไม่ได้

• พฤติกรรมการ ล็อกของ NFS เดิมทีก็ซับซ้อนอยู่แล้ว พอเอาแบ็กเอนด์ S3 ระยะไกลมาผสมเข้าไปก็น่าจะยิ่งชวนสับสน

• Werner Vogels เป็นคนที่น่าทึ่งจริง ๆ
  ผมเจองานเขียนของเขาครั้งแรกตอนกำลังศึกษา DynamoDB แล้วก็ติดตามมาตั้งแต่นั้น