S3 là công nghệ lưu trữ tệp, không phải hệ thống tệp

• Amazon S3 là một công nghệ đám mây đời đầu ra mắt năm 2006, rất mạnh cho việc lưu trữ tệp, nhưng không phải là hệ thống tệp thay thế nguyên vẹn API tệp Unix
• API tệp Unix gần với một mô-đun sâu che giấu việc đệm, page cache, phân quyền và lập lịch IO phía sau một giao diện hẹp như open, read, write, seek, close
• S3 có vẻ đơn giản với trọng tâm là GetObject và PutObject, nhưng chỉ hỗ trợ đọc từng phần qua Range và không hỗ trợ ghi đè từng phần
• Các cơ sở dữ liệu như Postgres, SQLite, MySQL, MongoDB, Elasticsearch phụ thuộc vào ghi đè theo đơn vị trang, nên cách đưa nguyên file SQLite hay DuckDB lên S3 thường chỉ phù hợp với bộ dữ liệu nhỏ
• Băng thông đọc/ghi cao và gánh nặng vận hành thấp là điểm mạnh của S3, nhưng cũng cần tính đến các hạn chế như không có rename/move, liệt kê chậm, API chỉ dùng XML và không có môi trường kiểm thử cục bộ

---

S3 lưu trữ tệp, nhưng không phải hệ thống tệp

• S3 là một công nghệ đám mây đời đầu xuất hiện năm 2006 và theo cách gọi thịnh hành lúc đó, nó được gọi là “object store”
• Trên thực tế, nó được dùng rộng rãi như một kho lưu trữ tệp, nhưng nếu hiểu nó như “Amazon Cloud Filesystem” thì chỉ đúng một phần
• Nó lưu trữ tệp rất tốt, nhưng không thể thay thế nguyên vẹn cách hoạt động và kỳ vọng của các hệ thống tệp truyền thống

API tệp Unix và mô-đun sâu

• Phần cốt lõi của API tệp Unix có thể tóm gọn trong năm lời gọi sau
  • open(filepath): mở tệp
  • file.read(size=100): đọc từ vị trí hiện tại và dịch vị trí về phía trước
  • file.write("hello, world"): ghi tại vị trí hiện tại và dịch vị trí về phía trước
  • file.seek(94): di chuyển vị trí đến một byte cụ thể
  • file.close(): đóng tệp
• Những lời gọi này là phần cốt lõi trong toàn bộ các system call thực tế, và gần như là tập chức năng tối thiểu cần thiết để đọc và ghi tệp
• Vì có rất nhiều xử lý diễn ra phía sau giao diện hẹp này, API tệp Unix có thể được xem là một mô-đun sâu (deep module)
  • đệm và page cache
  • xử lý phân mảnh
  • quản lý quyền truy cập
  • lập lịch IO
  • cả các tính năng như wear-levelling trên thẻ SD cũng mang lại lợi ích mà người dùng không cần tự quan tâm trực tiếp

Mô-đun nông, YAML và ORM

• Mô-đun nông có bề mặt API tương đối lớn so với lượng công việc mà nó thực sự xử lý
• Ngày nay, một dấu hiệu để nhận ra mô-đun nông là giao diện của nó là YAML
  • YAML trông giống một ngôn ngữ markup, nhưng trên thực tế lại thường được dùng như một cú pháp tái sử dụng có thể gắn gần như bất kỳ ngữ nghĩa nào lên trên
  • Trong mảng DevOps, YAML thường hoạt động như một “ngôn ngữ lập trình”
  • Nếu một ngôn ngữ con viết bằng YAML cung cấp cấu trúc lặp, nó có thể đạt tính Turing-complete
• Mô-đun nông không phải lúc nào cũng xấu
  • SQL ORM về bản chất là một abstraction bị rò rỉ và khó dùng tốt nếu không hiểu SQL
  • Trong một số trường hợp, mô-đun nông có thể là hình thức tốt nhất có thể có
• Với cùng điều kiện, mô-đun sâu vẫn tốt hơn

API S3 đơn giản nhưng khác API tệp

• API tệp Unix đã định hình từ đầu những năm 1970, và để giữ tương thích, giao diện được giữ nguyên trong khi phần triển khai bên trong đã thay đổi nhiều lần
• Amazon S3 không tái triển khai API hệ thống tệp Unix
• Các thao tác cơ bản của S3 chỉ tương ứng một phần với API tệp Unix
  • GetObject(Bucket, Key, Range=None): đọc toàn bộ hoặc một phần object
  • PutObject(Bucket, Key): ghi toàn bộ object
• Dù có thêm khái niệm bucket, nếu nhìn theo tỷ lệ giữa giao diện và chức năng thì S3 còn có thể được xem là đơn giản hơn API tệp Unix
• Khác biệt mang tính quyết định là việc thiếu ghi đè từng phần
  • Có thể đọc một phần object bằng tham số Range của GetObject
  • Không thể chỉ ghi đè một phần object
  • Việc ghi đè phải thực hiện trên toàn bộ tệp
• Vì khác biệt này, S3 chỉ thực sự phù hợp với một phần các trường hợp sử dụng tệp truyền thống

Cơ sở dữ liệu khó được chuyển nguyên trạng sang S3

• Nhiều cơ sở dữ liệu lưu dữ liệu vào các tệp nằm trên hệ thống tệp
  • Postgres duy trì 2–3 tệp cho mỗi bảng cùng nhiều tệp quản trị khác
  • SQLite nổi tiếng với việc lưu toàn bộ dữ liệu trong một tệp duy nhất
  • MySQL, MongoDB, Elasticsearch cũng lưu dữ liệu vào tệp
• Vấn đề là cơ sở dữ liệu nói chung phụ thuộc vào ghi đè từng phần theo đơn vị trang
  • Dữ liệu thường được lưu theo các trang như 4KB hoặc 8KB
  • Một heap file có thể chứa hàng nghìn trang
  • Các trang sẽ được ghi đè từng phần để lưu dữ liệu cần thiết
• Nếu đặt cơ sở dữ liệu SQLite trên S3, mỗi lần ghi sẽ phải ghi lại toàn bộ file cơ sở dữ liệu
• S3 có thể xử lý các lần ghi lớn rất nhanh, nhưng trừ những bộ dữ liệu nhỏ nhất, chiến lược ghi đè toàn bộ tệp mỗi lần thường không thể chịu nổi
• Việc ghi lại toàn bộ file cơ sở dữ liệu mỗi lần cũng khiến khó tận dụng tính toàn vẹn giao dịch mà người triển khai cơ sở dữ liệu đã xây dựng
• Trên S3, lần ghi cuối cùng sẽ thắng

Điều S3 làm tốt và chưa tốt

• Điểm mạnh của S3 là băng thông đọc và ghi rất cao
  • Không khó để tìm các trường hợp trên Internet ghi hoặc đọc hơn 10GB mỗi giây từ S3
  • Cũng từng có trải nghiệm các thao tác ghi lên S3 làm bão hòa mạng văn phòng của một khách hàng trong lĩnh vực tài chính
• Ngoài việc thiếu ghi đè từng phần, còn có các ràng buộc khác khiến nó khác với hệ thống tệp
• S3 không có thao tác rename hoặc move
  • Đổi tên được xử lý bằng CopyObject rồi DeleteObject
  • CopyObject mất thời gian tuyến tính theo kích thước tệp
  • Nếu đã ghi nhiều tệp vào sai vị trí rồi muốn hoàn tác, quá trình này sẽ rất chậm
• Việc liệt kê danh sách tệp thì chậm
  • Dù băng thông đọc/ghi rất cao, thao tác liệt kê các mục đã lưu lại chậm hơn nhiều
  • Thậm chí có thể chậm hơn cả một hệ thống tệp cục bộ vốn đã chậm
• Đổi lại, gánh nặng vận hành thấp hơn hệ thống tệp
  • Chỉ cần chỉ định bucket và key name, phần còn lại do đám mây xử lý
  • Giảm gánh nặng cho các tác vụ lặp lại như backup, sao chép offsite và provisioning
  • Provisioning ở đây không chỉ là dung lượng mà còn cả các thao tác IO

Với giao diện giữa các tổ chức, mô-đun sâu còn quan trọng hơn

• Việc S3 là API đám mây phổ biến đầu tiên có liên hệ với lợi thế của API sâu
• API sâu hữu ích để che giấu độ phức tạp giữa các mô-đun trong một hệ thống đơn lẻ, và còn quan trọng hơn trong các mối quan hệ có chi phí cao như tương tác giữa hai doanh nghiệp
• Việc kết nối các hệ thống máy tính giữa doanh nghiệp với nhau từ lâu vẫn được gọi là integration, và thường bị xem gần như đồng nghĩa với đau khổ
• Phần mềm doanh nghiệp cỡ lớn như SAP không phải là mô-đun sâu
  • Gần như cả tổ chức phải hiểu SAP
  • Liên tục phải điều chỉnh theo cách làm việc hiện có
  • Các dự án tích hợp SAP đắt đỏ, khổng lồ và lặp đi lặp lại các ca thất bại
• Độ phức tạp nội tại của S3 không hề ít hơn một bản cài đặt SAP
  • Amazon gọi S3 là “Simple Storage Service”, nhưng trên thực tế độ phức tạp của S3 là rất lớn
  • Nó bao gồm lý thuyết hàng đợi, tranh chấp IO, sharding và nhiều vấn đề mà hệ thống tệp phải xử lý
• Chữ “simple” của S3 gần với ý nghĩa giao diện sâu hơn là sự đơn giản thật sự

Những ngoại lệ phù hợp với S3 và các hạn chế còn lại

• Điều này không có nghĩa là bỏ qua vấn đề S3 có thể đắt so với trường hợp sử dụng
• Khái niệm mô-đun sâu và mô-đun nông đến từ A Philosophy of Software Design của John Ousterhout
• Cũng có những cơ sở dữ liệu được thiết kế ngay từ đầu để dùng API S3 làm tầng lưu trữ
  • Snowflake là một ví dụ như vậy
  • Tuy nhiên đây không phải là khả năng chuyển đổi trong suốt, mà đòi hỏi quyết định thiết kế từ đầu
  • Snowflake là một trường hợp đã đưa ra quyết định này từ rất sớm, ít nhất là tới năm 2016
• Không chỉ cơ sở dữ liệu mới gặp khó trên S3
  • Nhiều định dạng tệp giả định rằng seek là rẻ
  • Tệp Zip là ví dụ điển hình cho trường hợp chạy tốt hơn trên đĩa so với trên S3

Những điểm còn đáng tiếc ở S3

• API S3 chỉ dùng XML
  • JSON đã tồn tại từ năm 2006, nhưng vào thời điểm đó XML vẫn chiếm ưu thế
  • Việc Amazon không phát hành phiên bản JSON khi chuyển từ SOAP sang REST là điều đáng tiếc
• Amazon cũng đã ngừng duy trì XSD schema
  • Schema là một trong những lợi thế cốt lõi của API XML, nhưng hiện nay tài liệu chuẩn lại là website
• Amazon không cung cấp môi trường kiểm thử cục bộ
  • Trong Python, để kiểm thử nghiêm túc người ta thường dùng thư viện moto
  • Dù là công cụ kiểm thử cho một dịch vụ thương mại, moto lại được duy trì bởi các tình nguyện viên
• Amazon S3 hỗ trợ checksum nhưng không bật theo mặc định
  • Amazon đưa ra nhiều tuyên bố về độ bền dữ liệu
  • Dù chưa nghe nói có sự cố thực tế, cũng chưa từng thấy các tuyên bố đó được kiểm chứng rõ ràng
• Trước đây S3 từng có cái bẫy eventual consistency
  • Có thể đọc tệp, ghi đè nó rồi đọc lại mà vẫn thấy nội dung cũ chưa đổi
  • Điều này đôi khi xảy ra trong thời gian ngắn và gây bối rối
  • Các triển khai S3 khác không sao chép đặc tính này, và vài năm trước Amazon cũng đã sửa bằng strong read-after-write consistency