Amazon biến S3 thành hệ thống tệp thực thụ: Tôi đã thử "hỏng" nó và đây là kết quả

Tôi đã dành hơn một thập kỷ để nói với bất kỳ ai chịu nghe rằng S3 không phải là hệ thống tệp (filesystem), và nay nhìn lại, đó thực sự là một cách kỳ lạ để bắt đầu một cuộc trò chuyện. Vì vậy, khi AWS ra mắt S3 Files vào thứ Ba vừa qua — tính năng cho phép gắn một bucket S3 dưới dạng chia sẻ NFS — tôi đã làm điều mà bất kỳ người hợp lý nào cũng sẽ làm: tôi khởi tạo một EC2 instance và bắt đầu cố gắng "phá vỡ" nó.

Tôi có khoảng bốn giờ trước khi tham gia cuộc gọi với Andy Warfield, Phó Tổng thống/Kỹ sư xuất sắc/người kiên nhẫn phi thường người dẫn dắt kỹ thuật của S3 (dù ông có thừa nhận hay không), cùng một nhóm nhỏ từ đội ngũ S3. Tôi muốn đến đó với dữ liệu, không phải ý kiến. Ý kiến thì rẻ. Ý kiến về lưu trữ thì nguy hiểm. Và ý kiến của tôi về lưu trữ thì rất hài hước.

Tin tốt là: sản phẩm cốt lõi rất vững chắc. Tôi đã ném vào đó mười xung đột cố ý — ghi cùng một key từ mount NFS và API S3 đồng thời — và S3 đã thắng mọi lần, hội tụ trong vòng dưới hai giây với trạng thái "split-brain" bằng không. Đối với bất kỳ ai từng không may phải dựa vào các driver FUSE cộng đồng như s3fs-fuse hay goofys, nơi "giải quyết xung đột" trước đây thường có nghĩa là "lỗi dữ liệu hoặc một cái nhún vai", đây thực sự là một kỹ thuật đáng khen ngợi.

Mô hình giá và kiến trúc

S3 Files được xây dựng trên hạ tầng EFS, với mức phí giống hệt ($0,30/GB lưu trữ, $0,03/GB đọc, $0,06/GB ghi), và sự trùng khớp về giá cả là có chủ đích. "Việc có lợi ích kinh tế tốt hơn cái này so với cái kia là điều bất thường," nhóm kỹ thuật cho biết. Mẹo ở đây là bạn chỉ trả các mức giá đó cho phần nhỏ dữ liệu nóng thực sự nằm trên hệ thống tệp. Mọi thứ khác vẫn nằm trong S3 với giá $0,023/GB. Gắn kết một bucket petabyte, sử dụng tích cực một terabyte trong số đó, và trả tiền tương ứng.

Đội ngũ đã dành nhiều tháng để cố gắng làm cho ranh giới giữa tệp và đối tượng trở nên vô hình trước khi nhận ra chính ranh giới đó mới là thiết kế đúng đắn. "Chúng tôi đang xây dựng theo mẫu số chung thấp nhất của cả hai," một kỹ sư chia sẻ. Các client hệ thống tệp thay đổi đối tượng mỗi 10 mili-giây? Điều đó bình thường với NFS. Nhưng nó đáng sợ với một bucket S3. Vì vậy, họ giữ hai thế giới riêng biệt với đồng bộ hóa tự động giữa chúng. S3 vẫn là kho lưu trữ dữ liệu có thẩm quyền. Hệ thống tệp là một chế độ xem, không phải một bản sao.

Ba tốc độ, một sản phẩm

Tôi đã đo được ba tốc độ đồng bộ rất khác nhau, điều này cho bạn biết một chút về kiến trúc. Các thao tác ghi từ hệ thống tệp được tổng hợp trong một cửa sổ cố định 60 giây trước khi cam kết vào S3 dưới dạng các lệnh PUT đơn lẻ. Các tệp mới được tạo thông qua API S3 sẽ xuất hiện trên mount NFS trong khoảng 30 giây. Các bản cập nhật cho các tệp mà hệ thống tệp đã biết sẽ truyền đi trong 1,8 giây — nhanh gấp 15 lần so với việc tạo tệp mới.

Khi tôi đi qua nhóm với các con số này, họ xác nhận cửa sổ 60 giây hiện tại là cố định, nhưng để ngỏ khả năng điều này trở nên thích ứng (nếu điều đó quan trọng với bạn, hãy gây áp lực lên đội ngũ tài khoản AWS của bạn). Con số 30 giây chỉ là độ trễ lan truyền sự kiện S3. Tốc độ cập nhật 1,8 giây là hệ thống tệp vô hiệu hóa một inode mà nó đã lưu trong bộ nhớ đệm, đây là một đường dẫn nhanh hơn nhiều.

Các thao tác đọc trên 128 KB (mặc định; bạn có thể cấu hình mức này thấp xuống 0. Không phải bạn nên làm thế. Nhưng bạn chắc chắn có thể...) sẽ bỏ qua hệ thống tệp hoàn toàn và truyền trực tiếp từ S3 miễn phí — không có phí S3 Files nào cả, trong một động thái đáng ngờ gợi nhớ đến thời hoàng kim của Amazon khi luôn ám ảnh khách hàng. Việc bỏ qua này thực hiện các lệnh GET song song với tốc độ khoảng 3 GB/s cho mỗi client hiện nay.

Những trường hợp đặc biệt và rủi ro tiềm ẩn

Sau đó, tôi bắt đầu trở nên "sáng tạo". Tôi đã tạo mười đối tượng S3 với các tên key lạ. Dấu gạch chéo ở cuối. Dấu gạch chéo kép. Mô hình đường dẫn. Các thành phần đường dẫn 256 ký tự. Các key chỉ được đặt tên là "." và "..". Emoji. Chuỗi EICAR, vì tại sao không chứ. Sau đó tôi gắn kết bucket và chạy lệnh ls.

Sáu trong số đó đã biến mất. Không có lỗi trên client, không có mục nhật ký. Chúng vẫn ở trong S3 — bạn chỉ không thể thấy chúng từ hệ thống tệp.

Ban đầu tôi đã nhầm lẫn về điều này, nhưng hóa ra là một chỉ số CloudWatch thực sự tồn tại cho việc này: ImportFailures trong không gian tên AWS/S3/Files, được kích thước theo FileSystemId. Nó kích hoạt chính xác cho tất cả các key không tương thích của tôi. Nhưng không có bất kỳ chỉ báo nào ở phía client — không có lỗi từ ls, không có nhật ký trên instance, không có gì trong phản hồi NFS. Bạn phải biết rằng mình cần đi tìm một chỉ số CloudWatch cụ thể trong một không gian tên mà bạn chưa từng nghe nói đến, đối với một dịch vụ vừa mới ra mắt. Việc đo lường tốt hơn đang trong lộ trình, bao gồm cả nhật ký CloudWatch chỉ ra chính xác các đối tượng chưa được nhập. Hiện tại, nếu bạn gắn kết một bucket đã tích lũy các tên key "sáng tạo" trong nhiều năm, một số đối tượng của bạn sẽ vô hình và tín hiệu duy nhất của bạn là một bộ đếm trong CloudWatch mà chẳng ai nghĩ đến việc kiểm tra.

Quá trình truyền xóa tạo ra một kết quả thực sự kỳ lạ: các tệp bị xóa qua S3 vẫn có thể đọc được trên mount NFS trong 6 giây hoặc 18 giây, không có gì ở giữa; một phân phối song cực hoàn hảo. "Điều đó thực sự thú vị và tôi đã không mong đợi điều đó," Warfield nói. Đội ngũ nghi ngờ đó là một tạo tác của thông báo xóa nội bộ S3. Về mặt thực tế, điều này có nghĩa là bạn có thể đọc nội dung hợp lệ, hoàn chỉnh từ một tệp đã bị xóa trong tối đa 18 giây. Không quá tệ, không phải thảm họa, nhưng chắc chắn đáng để biết.

Có một cạnh sắc khi S3 thắng trong một xung đột trên tệp bạn đang truy cập thông qua một điểm truy cập (Access Point). Vì tôi là tôi, tôi đã lao vào việc này với tốc độ cao. Các đối tượng S3 được tạo qua API không mang theo metadata quyền sở hữu POSIX, vì vậy tệp được nhập sẽ mặc định là root:root với chế độ 0644. Nếu điểm truy cập của bạn thực thi một UID khác, bạn có thể đọc tệp nhưng không thể ghi vào nó nữa — quyền hạn không khớp. "Đó thực sự không phải là hành vi tôi mong đợi," một kỹ sư nói. Cả hai hệ thống đều không sai về mặt riêng lẻ; chính sự kết hợp mới gây rắc rối. Đội ngũ đang xem xét vấn đề này.

Ngoài ra, tài liệu nói rằng các phiên bản hệ thống tệp xung đột sẽ đi vào một thư mục lost+found. Chúng thực sự có — nó được gọi là .s3files-lost+found- và nằm tại gốc hệ thống tệp thực. Nếu bạn gắn kết thông qua một điểm truy cập bị giới hạn trong một thư mục con, bạn không thể thấy nó. Đó là cách hoạt động của điểm truy cập: chúng hạn chế chế độ xem của bạn, nhưng điều đó có nghĩa là các tạo vật xung đột của bạn vô hình ngay từ mount đã tạo ra chúng. Đội ngũ đồng ý rằng tài liệu cần làm rõ điều này, và có thể sẽ được thực hiện vào thời điểm bạn đọc bài viết này.

So sánh với Mountpoint và Tương lai

Mountpoint cho S3 — driver FUSE mã nguồn mở của AWS — không chết; nó được định vị là một công cụ khác, cho đối tượng khác. Mountpoint dành cho khối lượng công việc thông lượng tệp lớn nơi các thao tác không được hỗ trợ thất bại nhanh theo thiết kế. S3 Files dành cho mọi thứ muốn một API NFS thực thụ. Công nghệ đọc bypass thực sự đến từ các bài học khi xây dựng Mountpoint, một di sản kỹ thuật khá hay.

Ed Naim, Tổng giám đốc Dịch vụ Lưu trữ Tệp và Đối tượng của AWS, đã phác thảo một tầm nhìn thú vị hơn cả buổi ra mắt. Ông nhìn thấy S3 Files phát triển thành các chế độ xem hệ thống tệp tạm thời cho các đường ống dữ liệu — tạo ra chế độ xem tệp của dữ liệu S3 trong thời gian thực hiện một nhiệm vụ, thực hiện công việc, đồng bộ hóa các thay đổi cụ thể lại, và sau đó tháo dỡ nó. Kiểm soát đồng bộ hóa theo API thay vì đẩy tự động 60 giây hiện tại đang trong lộ trình. Đó là một sản phẩm khác biệt có ý nghĩa so với "gắn kết bucket của bạn như một NAS", và với tư cách là một sysadmin cũ, tôi vô lý tức giận về những gì tôi coi là trường hợp sử dụng mới và đáng sợ này.

S3 hiện nay xử lý đối tượng, tệp, bảng, vectơ và điện toán hiệu suất cao. Tôi đã hỏi điều gì sẽ đến tiếp theo. Tôi đã phớt lờ mọi thứ họ nói trong câu trả lời, và chỉ viết xuống "Cơ sở dữ liệu" (Database) trong ghi chú của mình, được bao quanh bởi những trái tim vẽ nguệch ngoạc. Mọi thứ đều là cơ sở dữ liệu nếu bạn cầm nó sai cách.

Tôi đã hỏi liệu tôi có cần ngừng nói rằng S3 không phải là hệ thống tệp không. "Không," ông nói. "S3 không phải là hệ thống tệp. Nhưng S3 Files cung cấp cho bạn một giao diện tệp ở trên nó."

Tôi đã nói "S3 không phải là hệ thống tệp" trong hơn một thập kỷ. Hóa ra tôi đã đúng cả thời gian qua. AWS chỉ quyết định ngừng chống lại nó và đặt một hệ thống tệp thực sự lên phía trước.