S3 Files và diện mạo đang thay đổi của S3

• Để giảm sự kém hiệu quả trong việc di chuyển dữ liệu quy mô lớn, S3 Files đã được giới thiệu, cho phép truy cập trực tiếp dữ liệu S3 như một hệ thống tệp
• Tính năng này tích hợp Amazon EFS với S3, cho phép mount bucket S3 dưới dạng NFS để đọc và ghi từ EC2, container, Lambda, v.v.
• Về mặt nội bộ, nó sử dụng cấu trúc stage và commit để phản ánh thay đổi lên S3 theo chu kỳ, đồng thời hỗ trợ đồng bộ hai chiều giữa tệp và đối tượng
• Cùng với S3 Tables, S3 Vectors, S3 Files hoạt động như một thành phần cốt lõi mở rộng S3 thành nền tảng dữ liệu hợp nhất
• Giờ đây, S3 không còn chỉ là một kho lưu trữ đơn thuần mà đang tiến hóa thành không gian làm việc hợp nhất lấy dữ liệu làm trung tâm, cung cấp nền tảng để nhà phát triển trực tiếp khai thác dữ liệu

---

Sự thay đổi của S3 và thiết kế của S3 Files

• Khó khăn của việc di chuyển dữ liệu và điểm khởi đầu của S3 Files

  • Quá trình di chuyển dữ liệu quy mô lớn là nguyên nhân gây ra sự kém hiệu quả kéo dài trong nhiều ngành, từ nghiên cứu khoa học đến machine learning
  • Trong trường hợp nghiên cứu hệ gen tại UBC, các nhà nghiên cứu đã phải dành rất nhiều thời gian cho việc sao chép giữa S3 và hệ thống tệp cục bộ
  • Ma sát dữ liệu (data friction) này phát sinh vì các công cụ truy cập dữ liệu theo những cách khác nhau
  • S3 Files được thiết kế để giảm ma sát đó bằng cách cho phép truy cập trực tiếp dữ liệu S3 như hệ thống tệp

• Phát triển dựa trên agent và tầm quan trọng của dữ liệu

  • Sự phát triển của agentic tooling đang làm tăng mạnh tốc độ và sự đa dạng trong phát triển ứng dụng
  • Khi rào cản viết mã giảm xuống, môi trường đang hình thành nơi các chuyên gia lĩnh vực có thể trực tiếp xây dựng ứng dụng
  • Vòng đời ứng dụng ngày càng ngắn hơn, còn dữ liệu nổi lên như tài sản cốt lõi tồn tại lâu dài
  • Lưu trữ không nên chỉ là nơi chứa dữ liệu, mà phải trở thành lớp trừu tượng giúp tách dữ liệu khỏi ứng dụng để có thể khai thác bền vững

Các data primitive mới của S3

• S3 Tables

  • Để xử lý dữ liệu có cấu trúc, S3 đã giới thiệu S3 Tables dựa trên Apache Iceberg
  • Trong khi vẫn giữ các tính năng của Iceberg, dịch vụ này cung cấp thêm bảo vệ tính toàn vẹn dữ liệu, tự động nén gộp (compaction), sao chép liên vùng v.v.
  • Hiện đã có hơn 2 triệu bảng được lưu trong S3 Tables, và nhiều ứng dụng khác nhau đang được xây dựng dựa trên đó

• S3 Vectors

  • Sự phát triển của AI làm gia tăng nhu cầu đối với vector index
  • Các cơ sở dữ liệu vector hiện tại lưu chỉ mục trong bộ nhớ hoặc SSD, nhưng điều này có giới hạn về chi phí và khả năng mở rộng
  • S3 Vectors cung cấp vector index co giãn hoàn toàn với hồ sơ chi phí, hiệu năng và độ bền tương tự đối tượng S3
  • Có thể mở rộng từ hàng trăm đến hàng tỷ bản ghi, đồng thời cung cấp endpoint API cho similarity search vô hướng (scalar similarity search)

Sự xuất hiện của S3 Files

• Tổng quan

  • S3 Files tích hợp Amazon EFS vào S3, cho phép truy cập trực tiếp dữ liệu S3 như hệ thống tệp mạng (NFS)
  • Có thể mount bucket hoặc prefix của S3 từ EC2, container, Lambda, v.v. để đọc và ghi như tệp
  • Các thay đổi sẽ tự động được phản ánh lên S3, hỗ trợ đồng bộ hai chiều giữa tệp và đối tượng

• Bài toán khó trong thiết kế

  • Hệ thống tệp và object storage có mô hình dữ liệu khác nhau về bản chất
  • Ban đầu người ta định chỉ đơn giản kết hợp EFS và S3, nhưng cuối cùng chỉ còn lại “những thỏa hiệp khó chấp nhận (unpalatable compromises)”
  • Tệp hỗ trợ thay đổi chi tiết và truy cập đồng thời, trong khi đối tượng giả định tính bất biến và cập nhật theo đơn vị toàn phần
  • Hệ thống thông báo sự kiện của S3 xử lý hơn 300 tỷ thông báo mỗi ngày và hoạt động dựa trên thay đổi ở cấp đối tượng

Nguyên lý thiết kế Stage and Commit

• Biến ranh giới thành tính năng

  • Thay vì che giấu sự khác biệt giữa tệp và đối tượng, thiết kế đã biến chúng thành ranh giới tường minh
  • Thay đổi được stage (lưu tạm) trong EFS, rồi theo chu kỳ sẽ được commit để phản ánh lên S3
  • Cách tiếp cận này lấy cảm hứng từ khái niệm quản lý phiên bản của Git, cho phép kiểm soát truyền dữ liệu dựa trên thời gian và chính sách

• Tính nhất quán và tính nguyên tử

  • Hỗ trợ song song các thao tác nguyên tử của hệ thống tệp (rename, move) và cập nhật toàn bộ ở cấp đối tượng của S3
  • Bằng cách tách hai lớp, hệ thống vẫn giữ được mô hình nhất quán của từng bên trong khi cung cấp một góc nhìn dữ liệu thống nhất

• Quản lý quyền hạn

  • Chính sách IAM của S3 và quyền dựa trên inode của hệ thống tệp khác nhau về cấu trúc
  • S3 Files tách hai cơ chế này thông qua cấp quyền theo đơn vị mount
  • Chính sách IAM của S3 vẫn được giữ làm lớp backstop cuối cùng, cho phép kiểm soát truy cập khi ranh giới dữ liệu thay đổi

• Sự không khớp của namespace

  • S3 không có khái niệm thư mục, và dấu phân tách đường dẫn (delimiter) cũng có thể được chỉ định tùy ý
  • Để giải quyết sự không khớp với hệ thống tệp, thiết kế giữ nguyên quy tắc đặt tên của cả hai bên
  • Các đối tượng không tương thích sẽ không bị di chuyển mà được thiết kế để phát sinh sự kiện để nhà phát triển tự xử lý

• Hiệu năng và độ trễ (latency)

  • Hệ thống tệp được tối ưu cho truy cập xoay quanh metadata, còn S3 tối ưu cho truy cập song song quy mô lớn
  • Vì phần lớn workload không truy cập tệp và đối tượng cùng lúc, việc duy trì một lớp đồng bộ thực tế hơn là cố hợp nhất hai mô hình
  • Góc nhìn tệp giữ tính nhất quán NFS, góc nhìn đối tượng giữ tính nhất quán mạnh của S3, và lớp đồng bộ đóng vai trò kết nối

Cách S3 Files hoạt động

• Cấu trúc cơ bản

  • S3 Files sử dụng EFS làm backend để mang lại trải nghiệm hệ thống tệp
  • Khi truy cập thư mục, hệ thống lấy metadata của S3 để tạo góc nhìn đã đồng bộ, và với tệp dưới 128KB thì dữ liệu cũng được tải ngay
  • Với tệp lớn, dữ liệu được lấy khi cần bằng lazy hydration
  • Các thay đổi được commit lên S3 bằng một lệnh PUT duy nhất khoảng mỗi 60 giây, đồng thời thực hiện đồng bộ hai chiều

• Xung đột và quản lý

  • Khi cả hai phía cùng sửa đồng thời, S3 được xem là source of truth
  • Các tệp bị xung đột được chuyển vào thư mục lost+found và được ghi nhận bằng metric CloudWatch
  • Những tệp không được truy cập trong 30 ngày sẽ bị loại khỏi góc nhìn hệ thống tệp để tối ưu chi phí

• Tối ưu hiệu năng

  • Thông qua tính năng read bypass, khi đọc tuần tự các tệp lớn, hệ thống đọc trực tiếp từ S3 bằng các yêu cầu GET song song

    • Đạt thông lượng 3GB/s cho mỗi client, và với nhiều client có thể đạt khả năng mở rộng cấp terabit

• Giới hạn và cải tiến dự kiến

  • Vì S3 không có thao tác rename native, việc đổi tên thư mục cần sao chép rồi xóa toàn bộ
  • Mount chứa hơn 50 triệu đối tượng sẽ hiển thị cảnh báo
  • Điều khiển commit tường minh chưa được đưa vào phiên bản đầu tiên
  • Một số object key không thể biểu diễn dưới dạng tên tệp POSIX, nên sẽ bị loại khỏi góc nhìn tệp

Tính đa dạng của dữ liệu và sự tiến hóa của S3

• Sự cùng tồn tại của các cách truy cập dữ liệu

  • Như trong trường hợp nghiên cứu tại UBC, các nhà phát triển phải dành nhiều thời gian cho di chuyển dữ liệu, caching và quản lý tên
  • Đội ngũ S3 đang hỗ trợ hợp nhất nhiều cách truy cập dữ liệu khác nhau thông qua Tables, Vectors và Files
  • Thay vì cố xóa nhòa khác biệt giữa tệp và đối tượng, họ thừa nhận đặc tính riêng của từng loại và biến ranh giới thành tính năng

• Vai trò mở rộng của S3

  • S3 đang tiến hóa từ một object storage đơn thuần thành nền tảng lưu trữ hợp nhất hỗ trợ nhiều dạng dữ liệu khác nhau
  • Thông qua Tables, Vectors và Files, dữ liệu có thể được khai thác trực tiếp theo cách làm việc phù hợp
  • Mục tiêu là biến storage thành hạ tầng nền trong suốt, không còn là vật cản của công việc
  • Trong tương lai, các tính năng như điều khiển stage/commit, tích hợp pipeline sẽ tiếp tục được mở rộng

• Kết luận

  • S3 Files kết hợp ưu điểm của cả hai bên trong khi vẫn giữ ranh giới tường minh giữa tệp và đối tượng
  • S3, khởi đầu là object storage cách đây 20 năm, nay đã phát triển thành không gian làm việc hợp nhất lấy dữ liệu làm trung tâm
  • Như thông điệp “Giờ hãy bắt tay xây dựng (Go build!)”, S3 đang trở thành nền tảng giúp nhà phát triển thử nghiệm và xây dựng với dữ liệu nhanh hơn

[xguru]

À, giờ có mục bài viết nên đọc cùng liên kết khá tốt với các bài chính thức liên quan nên tiện thật. Mình vẫn luôn băn khoăn không biết nên xử lý thế nào khi có bài giới thiệu và bài chính thức tách riêng như thế này, nhưng mục bài viết nên đọc cùng hoạt động rất ổn nên thấy vui ghê.. haha

Giờ thì S3 đang mở rộng thành một nền tảng dữ liệu bao gồm cả file, table và vector.

Có cảm giác như S3, vốn là điểm khởi đầu của hạ tầng đám mây hiện đại, đang được định nghĩa lại sau 20 năm.

[rtyu1120]

Dù cấu trúc tệp không được chia sẻ một cách minh bạch với S3, vẫn có mã nguồn mở tên là ZeroFS dùng S3 làm cơ sở dữ liệu để vận hành một hệ thống tệp tuân thủ POSIX. Nó từng khá nổi tiếng với bản demo chạy PostgreSQL trên S3.

https://www.zerofs.net/

[GN⁺]

Ý kiến trên Hacker News

• Về cơ bản đây là cấu trúc dùng S3FS, nhưng sử dụng EFS (dịch vụ NFS được AWS quản lý) làm lớp bộ nhớ đệm cho dữ liệu đang hoạt động và các truy cập ngẫu nhiên nhỏ
  Vấn đề là mô hình giá đắt đỏ của EFS cũng đi kèm nguyên vẹn
  — mọi thao tác ghi đều tốn $0.06/GB, có thể là điểm chí mạng với workload thiên về ghi
  — khi đọc từ cache sẽ bị tính $0.03/GB, còn các lượt đọc lớn trên 128KB sẽ được stream trực tiếp từ bucket S3 nên miễn phí
  — cache có giá $0.30/GB/tháng, nhưng có lẽ chi phí không quá lớn vì chủ yếu chỉ lưu bền vững các tệp nhỏ hơn 128KB

  • Tôi thắc mắc liệu có đúng là các lượt đọc tệp lớn (>128KB) luôn không đi qua cache hay không
    Tôi lo vì độ trễ (latency) của S3 khá tệ

• Câu “NFS provides the semantics your applications expect” là thứ buồn cười nhất tôi từng thấy

  • Ứng dụng đâu có mong đợi chỉ vì một lần mất kết nối mạng mà system call bị treo vô hạn, và filesystem rơi vào trạng thái không thể unmount

• Hugging Face Buckets gần đây cũng đã thêm tính năng mount bucket như một filesystem
  changelog của hf-mount

• Tôi tò mò về phần đồng bộ hóa
  Theo tài liệu AWS,
  nếu sau khi sửa /mnt/s3files/report.csv mà một phiên bản khác được upload lên bucket S3, thì khi xảy ra xung đột, phiên bản của tôi sẽ bị chuyển vào thư mục .s3files-lost+found-file-system-id và được thay bằng phiên bản trong bucket
  Tức là có một thư mục khôi phục tự động khi xung đột

• FiberFS gần như đã ở giai đoạn phát hành chính thức đầu tiên
  Nó có cache tích hợp, tương thích CDN, metadata JSON, an toàn đồng thời và nhắm tới mọi loại storage tương thích S3

  • Tôi muốn biết nó so với triển khai FUSE riêng của Amazon thế nào. Giờ đã ra tới phiên bản thứ ba rồi

• Tôi ước AWS cung cấp cầu nối được quản lý với storage NVMe cục bộ
  NVMe nhanh hơn EBS rất nhiều, và EBS lại nhanh hơn EFS
  Nếu đặt một lớp cache trên NVMe thì có vẻ tốc độ sẽ khá ổn, nhưng một lựa chọn tích hợp hoàn toàn còn lý tưởng hơn

  • Nếu EFS chỉ đơn thuần là một NFS mount, thì có lẽ cũng có thể tự làm bằng cách gắn volume NVMe và cấu hình cachefilesd
    Ví dụ

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

    Làm như vậy có khi chạy ngay được
    Thực chất chỉ là lệnh ba dòng, nhưng việc tung nó ra như một dịch vụ được quản lý đúng là phong cách của AWS

• Tôi nhớ là trước đây AWS từng nói không nên dùng S3 như một filesystem, nên tôi thắc mắc vì sao giờ lại đổi ý

  • Lần này có vẻ là cấu trúc đặt một filesystem thật (EFS) ở phía trước S3 và thực hiện đồng bộ hóa minh bạch
    Ngay trong blog họ cũng nhắc tới các lưu ý như vấn đề nhất quán hay xử lý tên object
    Với tư cách là một fan của S3, tôi thấy đây là một phương án dung hòa khá ổn
  • Các kiến trúc sư ở khách hàng lớn từ lâu đã dùng S3 như filesystem rồi
    Áp lực ticket hỗ trợ mà AWS nhận được cùng các yêu cầu kiểu “tại sao không làm được” có lẽ đã tích tụ và cuối cùng đẩy họ theo hướng này
    Cá nhân tôi không thích kiểu “về bản chất vẫn là thứ khác, chỉ thay lớp vỏ” này, nhưng có vẻ đây là một trường hợp chịu tác động từ áp lực xã hội của $$$
  • Có vẻ đây là chiến lược để kéo thêm cả nhóm người dùng ít kỹ thuật hơn
    Vì như vậy họ cũng có thể biến những người dùng công cụ kiểu “S3asYourFS.exe” thành khách hàng AWS
    Dù vậy, xét tới năng lực hỗ trợ khách hàng của AWS thì tôi không chắc đây có phải quyết định khôn ngoan hay không
    Nhưng sức hấp dẫn của việc có thêm người dùng trả tiền hàng tháng hẳn là rất lớn
  • Dù sao thì mọi người vẫn sẽ dùng S3 như filesystem, nên tôi nghĩ hỗ trợ chính thức còn tốt hơn
  • Cuối cùng AWS đã đặt cache ở phía trước và tạo ra một mô hình doanh thu
    Từ góc nhìn người dùng thì hiệu năng tốt hơn, còn AWS thì giảm tải
    Có thể tiết kiệm tiền, cũng có thể không

• Tôi tò mò nếu dùng cái này để lưu cơ sở dữ liệu SQLite thì sẽ ra sao
  Có lẽ chỉ phù hợp cho bản sao chỉ đọc, và chắc không thể backup như Litestream

  • Cơ chế khóa (lock) của SQLite không an toàn trên NFS nên sẽ không hoạt động

• Hành vi locking của NFS vốn đã phức tạp rồi, nếu còn trộn thêm backend S3 từ xa vào thì có lẽ càng rối hơn

• Werner Vogels đúng là một con người đáng nể
  Trước đây khi học về DynamoDB tôi đã lần đầu đọc bài viết của ông ấy, và từ đó trở thành fan