Xây dựng và vận hành một hệ thống lưu trữ khổng lồ mang tên S3

• Amazon S3 khởi đầu là một dịch vụ lưu trữ đối tượng dựa trên HTTP REST API ra mắt ngày 14 tháng 3 năm 2006, và đã phát triển thành một dịch vụ quy mô lớn được vận hành bởi hàng trăm microservice cùng nhiều đội ngũ chuyên trách
• Quy mô của S3 không thể được giải thích chỉ bằng mã nguồn; đó là một hệ thống mà ổ cứng, firmware, trung tâm dữ liệu, tổ chức vận hành và workload của khách hàng liên tục gắn kết và cùng thay đổi
• HDD đã cải thiện đáng kể về dung lượng và hiệu quả chi phí, nhưng hiệu năng truy cập ngẫu nhiên vẫn bị ràng buộc bởi giới hạn cơ học, nên S3 xem quản lý độ nóng I/O và phân bố dữ liệu trên hàng triệu ổ đĩa là vấn đề cốt lõi
• Cơ chế sao chép và erasure coding dựa trên Reed-Solomon không chỉ tăng độ bền dữ liệu mà còn giúp định tuyến vòng qua các ổ đĩa quá tải, từ đó hỗ trợ quản lý hiệu năng và tail latency
• Vận hành S3 được thiết kế để duy trì đồng thời tốc độ phát triển nhanh và tiêu chuẩn độ bền cao thông qua durability review, ShardStore dựa trên Rust, kiểm chứng hình thức hạng nhẹ và quyền sở hữu (ownership) theo từng nhóm

---

Nhìn S3 như một hệ thống dịch vụ khổng lồ

• S3 là một dịch vụ lưu trữ đối tượng, gồm HTTP REST API, frontend fleet, dịch vụ namespace, storage fleet dựa trên ổ cứng và background worker fleet
• Mỗi thành phần lớn đều có khu vực riêng trong tổ chức S3, người phụ trách, cùng nhiều nhóm; các thành phần sâu hơn bên trong cũng được vận hành theo mô hình có fleet và nhóm riêng
• Hiện nay S3 được cấu thành từ hàng trăm microservice, và tương tác giữa các nhóm gần giống các cam kết ở cấp API
• Nếu tính mô-đun được thiết kế sai, tương tác giữa các nhóm cũng có thể trở nên kém hiệu quả và gượng gạo; việc sửa điều đó cũng là một phần của quá trình đồng thiết kế phần mềm và đội ngũ

Không phải phần mềm, mà toàn bộ dịch vụ mới là hệ thống

• Khách hàng của S3 không mua phần mềm đóng gói mà mua trải nghiệm dịch vụ, và họ kỳ vọng chất lượng ổn định, có thể dự đoán được
• Ranh giới hệ thống của S3 không chỉ dừng ở mã nguồn
  • Mã chạy gần ổ đĩa
  • Kỹ thuật viên lắp thêm storage rack mới trong trung tâm dữ liệu
  • Ứng dụng khách hàng tinh chỉnh hiệu năng
  • Các tổ chức phần cứng, tài chính và kỹ thuật
• S3 gần với một hệ thống sống đang liên tục phát triển và thay đổi, nơi phần mềm, phần cứng và con người cùng vận hành
• Những sơ đồ kiến trúc vẽ trên bảng trắng một cách đơn giản thường che khuất quy mô và độ mở rộng của dịch vụ bên trong từng khối, khiến người ta đánh giá thấp hệ thống thực tế

Giới hạn vật lý của HDD ảnh hưởng thế nào đến thiết kế S3

• S3 là một hệ thống rất lớn sử dụng hàng triệu ổ cứng, và đặc tính của HDD là một trong những ràng buộc trung tâm của thiết kế
• Kể từ IBM 350 disk storage unit năm 1956, HDD đã tiến bộ rất nhiều
  • HDD lớn nhất được nhắc đến hiện nay là Western Digital Ultrastar DC HC670 26TB
  • Dung lượng đã cải thiện gấp 7,2 triệu lần kể từ RAMAC
  • Kích thước vật lý đã nhỏ hơn 5.000 lần
  • Chi phí trên mỗi byte sau điều chỉnh lạm phát đã rẻ hơn 6 tỷ lần
• Tuy nhiên, seek time chỉ cải thiện khoảng 150 lần, và hiệu năng đọc/ghi ngẫu nhiên vẫn dừng ở mức khoảng 120 thao tác mỗi giây
• Chỉ số hiệu năng này cũng gần như vậy vào thời điểm S3 ra mắt năm 2006, và không khác biệt nhiều so với 10 năm trước đó
• Vì HDD là thiết bị cơ khí, phải chờ cánh tay di chuyển và platter quay, nên hiệu năng truy cập ngẫu nhiên không thể cải thiện theo tốc độ tăng dung lượng
• Lộ trình của ngành chỉ ra con đường đến HDD 200TB trong vòng 10 năm tới; ở mức đó, nếu giả định truy cập ngẫu nhiên công bằng trên toàn bộ dữ liệu, mỗi 2TB dữ liệu trên đĩa chỉ cho phép 1 I/O mỗi giây
• Dù S3 hiện chưa dùng ổ 200TB, hệ thống được dự đoán sẽ dùng loại ổ đó và mọi mức dung lượng trung gian trước khi tới đó

Quản lý độ nóng: phân bố dữ liệu và hiệu năng

• Trong S3, heat là số lượng yêu cầu đi vào một ổ đĩa tại một thời điểm nhất định
• Nếu quản lý độ nóng kém, yêu cầu có thể dồn vào một ổ cụ thể tạo thành hotspot, làm suy giảm hiệu năng tổng thể của các yêu cầu phụ thuộc vào ổ đó
• Hotspot thường không làm hệ thống dừng ngay lập tức mà tạo ra hàng đợi yêu cầu và làm xấu đi trải nghiệm khách hàng
  • Các yêu cầu phải chờ ổ đĩa bận sẽ bị trễ
  • Độ trễ được khuếch đại lên các lớp cao hơn của storage stack thông qua các I/O phụ thuộc như tra cứu metadata hay erasure coding
  • Xuất hiện độ trễ cao ở một số yêu cầu, tức straggler
  • Hotspot trên từng HDD dẫn tới tail latency và nếu để kéo dài sẽ ảnh hưởng đến cả độ trễ yêu cầu tổng thể
• Tại thời điểm dữ liệu được ghi, S3 không biết khi nào và theo cách nào dữ liệu đó sẽ được truy cập trong tương lai, nên việc quyết định phân bố dữ liệu lúc ghi là rất khó
• Ở quy mô nhỏ, việc dự đoán và quản lý I/O heat rất khó, nhưng ở quy mô và tính đa thuê của S3 thì các đặc tính khác xuất hiện
• Từng workload riêng lẻ thường rảnh phần lớn thời gian rồi đột ngột đạt đỉnh, nhưng khi cộng hàng triệu workload lại thì tổng nhu cầu trở nên phẳng hơn và dễ dự đoán hơn
• Khi vượt qua một quy mô nhất định, một workload đơn lẻ gần như khó hoặc không thể ảnh hưởng tới đỉnh tải tổng thể

Sao chép và erasure coding xử lý đồng thời độ bền và hiệu năng

• Cách thêm dư thừa trong hệ thống lưu trữ không chỉ bảo vệ dữ liệu khỏi lỗi phần cứng mà còn hỗ trợ phân tán độ nóng
• Sao chép tạo nhiều bản sao trên nhiều ổ đĩa để chịu được lỗi đĩa và cho phép yêu cầu đọc được phục vụ từ bất kỳ bản sao nào
• Sao chép tốn kém về dung lượng nhưng hiệu quả về mặt read I/O
• Để không phải trả overhead sao chép cho toàn bộ dữ liệu, S3 cũng dùng erasure coding
• Một ví dụ là dùng thuật toán như Reed-Solomon
  • Chia đối tượng thành k identity shard
  • Tạo thêm m parity shard
  • Chỉ cần k shard khả dụng trong tổng số k+m shard là có thể đọc được đối tượng
• Cách tiếp cận này giảm overhead dung lượng trong khi vẫn chịu được cùng số lượng lỗi

Chiến lược phân bố dữ liệu và cô lập workload của khách hàng

• Cơ chế dư thừa chia dữ liệu thành nhiều mảnh hơn số lần đọc thực sự cần thiết, nhờ đó có thể gửi yêu cầu theo hướng tránh các ổ đĩa bị quá tải
• S3 còn phân bố các đối tượng mới rộng khắp trên toàn bộ disk fleet để giảm độ nóng hơn nữa
• Một đối tượng riêng lẻ có thể được mã hóa trải trên hàng chục ổ đĩa, và các đối tượng khác nhau được đặt trên các tập ổ đĩa khác nhau
• Khi phân tán các đối tượng trong từng bucket ra nhiều ổ đĩa, có hai lợi ích
  • Tỷ lệ dữ liệu của khách hàng trên một ổ đơn lẻ trở nên rất nhỏ, khiến một workload riêng lẻ khó tạo hotspot trên một ổ cụ thể
  • Một workload riêng lẻ có thể burst lên đến quy mô ổ đĩa mà nếu tự xây như một hệ thống độc lập thì rất khó và rất tốn kém
• Một đợt burst khi khách hàng phân tích hệ gen chạy phân tích song song trên hàng nghìn hàm Lambda có thể được xử lý bởi hơn 1 triệu ổ đĩa riêng lẻ
• Hiện nay S3 có hàng chục nghìn khách hàng với bucket được phân tán trên hàng triệu ổ đĩa
• Điểm khác biệt của S3 không chỉ là quy mô của chính hệ thống lưu trữ, mà còn là việc quy mô tổng hợp của khách hàng và workload có thể thay đổi cả bản chất của hệ thống

Durability review và guardrail

• Amazon rất coi trọng việc giúp kỹ sư và các nhóm có thể thất bại nhanh nhưng an toàn
• Để vừa cung cấp lưu trữ có độ bền cao vừa di chuyển nhanh, S3 dùng quy trình durability review
• Durability review không phải là cơ chế nằm trong mô hình thống kê 11 số 9, nhưng vẫn được xem là rất quan trọng trong vận hành S3
• Nếu thay đổi của kỹ sư có thể ảnh hưởng đến trạng thái độ bền, durability review sẽ được thực hiện
• Quy trình này mượn ý tưởng threat model từ nghiên cứu bảo mật
  • Viết phần tóm tắt thay đổi
  • Lập danh sách toàn diện các mối đe dọa
  • Tổng hợp cách thay đổi đó chịu được các mối đe dọa tương ứng
• Durability review đóng hai vai trò
  • Buộc người viết và người review phải suy nghĩ phản biện về những rủi ro cần được bảo vệ
  • Tách riêng rủi ro và biện pháp ứng phó để có thể thảo luận từng phần độc lập
• Khi tìm biện pháp ứng phó, thay vì gắn một cách giảm thiểu riêng cho từng rủi ro chi tiết, S3 ưu tiên những guardrail đơn giản nhưng mạnh, có thể chặn cả một nhóm rủi ro rộng

ShardStore, Rust và kiểm chứng hình thức hạng nhẹ

• Vài năm trước, S3 bắt đầu một dự án viết lại từ đầu lớp thấp nhất của storage stack, tức phần quản lý dữ liệu trên từng ổ đĩa riêng lẻ
• Tên của lớp lưu trữ mới là ShardStore
• Một trong những guardrail được áp dụng khi xây lại ShardStore là kiểm chứng hình thức hạng nhẹ
• Nhóm đã chuyển ngôn ngữ triển khai sang Rust để phát hiện lỗi sớm hơn
  • Tận dụng tính an toàn kiểu dữ liệu
  • Tận dụng hỗ trợ ngôn ngữ có cấu trúc
  • Viết thư viện để mở rộng tính an toàn kiểu dữ liệu sang cả cấu trúc trên đĩa
• Về mặt kiểm chứng, họ viết một mô hình đơn giản hóa logic ShardStore bằng Rust và đặt nó trong cùng kho mã với triển khai ShardStore chạy production thực tế
• Mô hình này đóng vai trò là một đặc tả có thể thực thi, loại bỏ sự phức tạp của lớp lưu trữ trên đĩa thực tế và của HDD
• Kích thước mô hình chỉ khoảng 1% hệ thống thực tế, nhưng cho phép mức độ kiểm thử vốn phi thực tế nếu nhắm trực tiếp vào ổ cứng 120 IOPS
• Công trình này cũng đã được công bố qua bài báo SOSP Using lightweight formal methods to validate a key-value storage node in Amazon S3
• Sau đó, nhóm dùng các công cụ và kỹ thuật sẵn có như property-based testing để xác minh rằng hành vi của phần triển khai khớp với đặc tả
• Điểm cốt lõi là các kỹ thuật nghiên cứu kiểm chứng hình thức đã được công nghiệp hóa thành mã mà kỹ sư thông thường có thể duy trì và thành công cụ chạy trên mỗi commit
• Các guardrail kiểm chứng mang lại cho nhóm sự tự tin để phát triển nhanh hơn, và vẫn tiếp tục được duy trì kể cả sau khi có kỹ sư mới gia nhập

Giải quyết bài toán mở rộng của nhóm và cá nhân bằng ownership

• Ở Amazon, ownership là khái niệm chỉ rõ một cá nhân hoặc một nhóm duy nhất chịu trách nhiệm đến cùng để một công việc hay dịch vụ thành công
• Để vừa di chuyển nhanh vừa giữ tiêu chuẩn chất lượng cao trong S3, các nhóm phải là chủ sở hữu
  • Sở hữu các cam kết API với hệ thống khác
  • Chịu trách nhiệm về độ bền, hiệu năng và tính sẵn sàng
  • Nếu lỗi bất ngờ ảnh hưởng đến tính sẵn sàng, họ vẫn sửa lúc 3 giờ sáng
  • Sau khi sửa lỗi, họ cải thiện hệ thống để chuyện tương tự không lặp lại
• Ownership đi kèm trách nhiệm lớn và cũng đòi hỏi sự tin cậy
• Để một cá nhân hay nhóm thực sự sở hữu dịch vụ, họ cần có không gian để tự quyết định cách cung cấp nó
• Kinh nghiệm từ các dự án nghiên cứu cao học cũng cho thấy khi sinh viên cảm thấy đó là ý tưởng của mình và có thể tự phát triển nó, họ sẽ đầu tư sâu hơn
• Ở vai trò kỹ sư rất senior, thay vì trực tiếp đưa ra lời giải như thể đang triển khai luôn giải pháp, cách hiệu quả hơn là xác định bài toán thật rõ và giúp nhóm sở hữu lời giải
• Với những vấn đề có nhiều lời giải khả dĩ, việc khiến ai đó chọn ra lời giải phù hợp cũng là một cách trao cho họ quyền sở hữu giải pháp

Kết luận rút ra từ S3

• Quy mô kỹ thuật của S3 không chỉ đơn giản là lớn hơn các hệ thống nhỏ, mà workload, cấu trúc và cách vận hành của nó còn khác biệt về bản chất
• “Hệ thống” không chỉ bao gồm phần mềm mà còn cả vận hành dịch vụ, tổ chức vận hành và cả mã của khách hàng chạy cùng dịch vụ đó
• Tổ chức cũng là một phần của hệ thống, nên bản thân nó có các bài toán mở rộng và cơ hội đổi mới riêng
• Để thành công ở vai trò cá nhân, cần diễn đạt bài toán thật rõ hơn là áp sẵn lời giải, đồng thời hỗ trợ các nhóm kỹ thuật mạnh thực sự sở hữu và triển khai lời giải đó

[GN⁺]

Ý kiến trên Hacker News

• Một trong những cuộc trò chuyện tôi nhớ khi còn ở AWS là: ngay cả sự kiện xác suất một phần tỷ cũng xảy ra hằng ngày ở quy mô của S3
  Những việc bình thường quá hiếm đến mức không đáng lo cũng nhất định phải được cân nhắc và xử lý
  Thật vui khi thấy các cách tiếp cận như ShardStore, đặc biệt là kiểm chứng hình thức và kiểm thử dựa trên thuộc tính. Các dịch vụ thế hệ trước có rất nhiều lỗi, đủ để cho thấy rủi ro của tăng trưởng hữu cơ, nhưng ít nhất chúng được thiết kế để sự cố xảy ra một cách “an toàn”, ngăn mất dữ liệu, và các kỹ sư S3 đã ám ảnh với điểm đó

  • Đúng vậy. S3 xử lý trung bình hơn 100 triệu yêu cầu mỗi giây, nên một phần tỷ nghĩa là cứ 10 giây lại xảy ra một lần
    Không chỉ S3 mới vậy. Ví dụ, vào Prime Day 2022, DynamoDB chỉ với workload của Amazon đã lên tới hơn 105 triệu yêu cầu mỗi giây: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
    Trong bài, Andy cũng nói về các phương pháp hình thức nhẹ và việc đội ngũ áp dụng Rust; ở quy mô mà ngay cả các sự kiện xác suất cực thấp cũng trở nên phổ biến, cần đầu tư vào nhiều lớp công cụ và quy trình để đảm bảo tính đúng đắn
  • Kiến trúc sư trưởng của AWS James Hamilton đã viết về hiện tượng tương tự vào năm 2017. Khi quy mô đủ lớn, sự kiện hiếm không còn hiếm nữa: https://news.ycombinator.com/item?id=14038044
  • Tôi từng là SDM dựng một dịch vụ mới với một nhóm toàn SDE mới vào nghề; trong review code, khi tôi chỉ ra một vấn đề có thể gây Sev2, một SDE phản bác rằng “cao lắm cũng chỉ xác suất một phần triệu”
    Tôi giải thích rằng nếu tăng lên mục tiêu 500k TPS thì tức là 30 lần mỗi phút, rồi hỏi “cậu có muốn trực on-call tuần đó không?”. Trong stack đó, “insist on the highest standards” mang ý nghĩa hoàn toàn khác so với hầu hết tổ chức
  • Hằng ngày ư? Một component hỗ trợ S3 Index mà tôi từng làm việc có thể gặp vấn đề một phần tỷ vài lần mỗi phút
    May là thuật toán tốt, và phần cứng ngày nay cũng ổn định hơn rất nhiều
  • Cá nhân tôi rất muốn làm việc trong một môi trường như vậy. Cái lỗ hổng một phần tỷ đó vẫn khiến tôi bứt rứt
    Trong đầu tôi cũng có một giọng nói hơi lệch lạc, sẵn sàng cầm bắp rang ngồi xem nếu may mắn chứng kiến hậu quả khi vụ va chạm hash mật mã lớn đầu tiên nổ ra

• Tôi làm trong lĩnh vực genomics và đã xử lý nhiều kho dữ liệu cấp petabyte trong 10 năm qua
  Sau khi dùng AWS S3, GCP GCS và các hệ thống lưu trữ cho phần cứng colocated (Ceph, Gluster, một hệ thống HP mà tôi đã xóa khỏi trí nhớ), tôi rất tôn trọng công sức cần có để vận hành những hệ thống như vậy
  Cũng khó mà đánh giá thấp lợi ích của việc chia sẻ disk I/O với vô số khách hàng khác. Thuật ngữ “heat” trong bài là lần đầu tôi nghe, nhưng trong một hệ thống đơn lẻ thì việc giảm nhẹ nó thật sự rất khó. Trong cụm colocation của chúng tôi, để quản lý I/O đúng cách giữa các job lớn, chúng tôi đã phải sửa hệ thống batch để xem I/O là tài nguyên có thể phân bổ như RAM hay CPU. S3 và GCP rất đắt, nhưng có lúc hiệu năng xứng đáng với giá tiền
  Tôi nghĩ những bài như thế này chính là mặt hay nhất của HN

  • Mô hình chi phí của cloud storage cũng được giải thích ở một mức nào đó
    Nhìn từ góc độ cloud storage, khách hàng tốt nhất là người lưu trữ cực nhiều dữ liệu nhưng hầu như không đọc. Nó giống như thuê ổ cứng, nhưng nếu chỉ lấp đầy một phần mỗi ổ bằng dữ liệu “lạnh”, bạn vẫn có thể tiếp tục dùng toàn bộ năng lực I/O của cùng ổ đó để xử lý các workload nóng
    Nếu cân bằng rất cẩn thận dữ liệu nào đặt trên ổ nào, bạn có thể tiếp tục tận dụng tất cả các ổ dù phần lớn dữ liệu không được dùng đến. Vì vậy lưu trữ tương đối rẻ, còn đọc thì tương đối đắt
  • Đáng tiếc là nhiều công cụ trong genomics, rộng hơn là biotech, vẫn phụ thuộc vào hệ thống tệp cục bộ
    Ngay cả khi hỗ trợ S3, hiệu năng thường chậm hơn rất nhiều so với mức có thể đạt được
  • Là người trong lĩnh vực này, tôi muốn làm sao để dữ liệu EiB của người dùng có cảm giác như ở local
    Việc đó khó, và xin lỗi vì độ sẵn sàng đọc chỉ khoảng 99,95%
  • Đúng là mặt hay của HN. Nếu có link các bài HN tương tự mà bạn thấy hay, tôi muốn xem

• Nếu S3 từng định nghĩa một giao thức đơn giản dựa trên OAuth2 để ủy quyền truy cập đọc/ghi, hẳn đã có thể tạo ra rất nhiều thứ
  Thế giới cần một giao thức dựa trên HTTP cho phép ứng dụng truy cập dữ liệu thay cho người dùng. Google Drive là thứ gần nhất với điều này, nhưng chỉ có một nhà cung cấp và còn có các vấn đề khác[0]. Thật tiếc là remoteStorage đã không được chấp nhận rộng rãi. Tôi hy vọng Solid sẽ thành công, nhưng với tôi nó có vẻ quá phức tạp. Cách tiếp cận của tôi cho vấn đề này là https://gemdrive.io/, nhưng hiện gần như đang dừng lại vì tôi đang tập trung vào các phần khác của stack tự host
  [0]: https://gdrivemusic.com/help

  • Hoàn toàn đồng ý. Sẽ thật tuyệt nếu có thể tạo các ứng dụng lưu dữ liệu của mọi người vào bucket S3 của riêng họ, và chi phí cũng được tính vào tài khoản của từng người
    Hiện nay nếu muốn làm đúng thì cực kỳ khó. Tôi đã phải tạo hẳn một ứng dụng CLI để giải quyết bài toán “cấp thông tin xác thực AWS chỉ có quyền truy cập vào đúng bucket cụ thể này”, nhưng tôi không muốn hướng dẫn người dùng cài và chạy thứ như vậy: https://s3-credentials.readthedocs.io/en/stable/
  • Nhưng hầu hết ứng dụng đều giả định truy cập dữ liệu kiểu POSIX
    Thực tế, sẽ rất hay nếu có một thư viện với phụ thuộc phía client tối thiểu, mount một thư mục cục bộ vốn là bucket S3 của người dùng
  • Một hệ thống như vậy sẽ rất đáng gờm. Nó có thể buộc các công ty bán sản phẩm phủ UI lên S3 phải cạnh tranh cực kỳ khốc liệt
    Vì đối thủ cạnh tranh có thể nhảy vào bất cứ lúc nào bằng khả năng tương tác đối kháng
    Thật đáng tiếc là các dự án đã hoặc đang cố tạo chủ quyền dữ liệu cho người dùng đều trôi sang hướng tiền mã hóa kỳ quặc
  • Dùng Cognito Identity Pool có thể tiến khá gần. Cách làm là đổi khóa của người dùng lấy thông tin xác thực AWS gắn với một IAM role có quyền truy cập các tài nguyên cần đọc/ghi thay mặt họ, và đây là một mẫu khá tiêu chuẩn
    https://docs.aws.amazon.com/cognito/latest/developerguide/co...
    Sửa: Có vẻ tôi đã đọc nhầm bình luận. Tôi hiểu là ứng dụng muốn ủy quyền dữ liệu người dùng cho client, nhưng thực ra có vẻ là người dùng muốn ủy quyền dữ liệu của mình cho ứng dụng. Đây là hai use case khác nhau
  • Chúng tôi đang xây dựng thứ này tại https://puter.com

• Thông số của IBM RAMAC ghi dung lượng lưu trữ 3,75MB, khoảng 9.200 USD mỗi terabyte, nhưng điều đó không thể đúng
  Nếu nhân chi phí với dung lượng lưu trữ thì giá ổ đĩa chỉ là 3 xu
  Trang này[1] nói rằng nó “lưu trữ khoảng 2.000 bit trên mỗi inch vuông và giá mua vào khoảng 10.000 USD mỗi megabyte”
  Vì vậy có lẽ thông số phải là 9.200 USD mỗi megabyte. Khi đó giá ổ đĩa là 34.500 USD, nghe hợp lý hơn
  [1]: https://www.historyofinformation.com/detail.php?entryid=952

  • Có vẻ như đặt nhầm dấu thập phân hoặc kiểu vậy. Tôi cũng luôn mắc lỗi như thế. Lúc nào cũng sai những chi tiết nhỏ
  • Trên https://en.m.wikipedia.org/wiki/IBM_305_RAMAC có nội dung có thể là nguyên nhân của lỗi này
    Nó là 30 triệu bit, và con số đó chỉ tính 6 bit dữ liệu, trừ parity. Nhưng vì được thuê với giá 3.000 USD mỗi tháng nên không có chi phí cố định như mua đứt ổ đĩa vật lý. Theo nghĩa đó, nó cũng khá giống mô hình S3

• Điều mà phần lớn mọi người không nhận ra là phép màu không nằm ở việc xử lý chính hệ thống, mà ở việc làm cho ủy quyền trông như không tốn chi phí
  Trong hệ thống phân tán, ủy quyền cực kỳ khó. Ở quy mô AWS, thực tế gần như là phép màu. AWS có mô hình quyền phong phú, và các thay đổi quyền có lẽ lan truyền khắp toàn bộ hạ tầng ở tốc độ dưới mili giây, trong khi vẫn xử lý hàng nghìn tỷ yêu cầu
  Phần này cùng với logging/đối soát cho tính phí là hai yếu tố “ma thuật” ở AWS mà tôi muốn được đọc một bài viết về chúng
  S3 xử lý kiểm soát truy cập khác với các dịch vụ khác, trong đó quyền được gắn với tài nguyên. Tôi đoán là vì tốc độ

  • Cần nhớ rằng S3 ra đời trước IAM vài năm
    Một trong những lý do cách tiếp cận bucket/key đặc biệt là vì khi IAM xuất hiện, mô hình đó đã được thiết lập rồi
    Khả năng cao việc nó vẫn được duy trì về sau là vì loại bỏ mô hình cũ sẽ có thể phá vỡ nhiều cấu hình của khách hàng, nên đó là một việc khó

• “Ở công ty, với tư cách một kỹ sư thật sự senior, đương nhiên tôi có những quan điểm mạnh và cả agenda kỹ thuật. Nhưng khi tương tác với các kỹ sư, nếu chỉ cố chia sẻ ý tưởng của mình thì rất khó để mọi người cùng thành công. Sẽ khó dấn thân hơn nhiều vào một ý tưởng mà bản thân không sở hữu. Vì vậy, khi làm việc với đội ngũ, tôi đã chọn chiến lược để những ý tưởng hay nhất của mình trở thành ý tưởng do người khác đưa ra, chứ không phải của tôi. Tôi chủ động dành nhiều thời gian hơn rất nhiều cho việc phát triển vấn đề và diễn đạt nó thật tốt, thay vì bán một giải pháp. Thường có nhiều cách để giải một vấn đề, và việc chọn đúng cách chính là để ai đó sở hữu giải pháp đó.”
  “Tôi đã học được rằng để thật sự thành công trong vai trò của mình, tôi cần tập trung vào việc diễn đạt rõ vấn đề chứ không phải giải pháp, và tìm cách hỗ trợ một đội ngũ kỹ thuật mạnh thật sự sở hữu giải pháp đó.”
  Đoạn này thật sự rất hay. Ở mức nào đó nó gợi nhớ đến hiệu ứng Ikea. Nếu muốn ai đó nhiệt huyết với việc họ làm, cần khuyến khích cảm giác sở hữu, và một cách tốt là biến việc đó thành “ý tưởng của người đó”

  • Không có ý nói một cách hoài nghi, nhưng cần thừa nhận rằng bản thân việc mô tả vấn đề cũng là một công cụ để dẫn mọi người về phía giải pháp mà ta mong muốn
    Rốt cuộc, mọi người thường nhìn nhận khác nhau ngay từ việc “vấn đề” là gì
    May là không phải mọi vấn đề đều như vậy. Nhưng chẳng hạn nhìn vào các cuộc thảo luận về “vấn đề packaging” của Python, thực ra có khoảng 6 vấn đề khác nhau đang được mọi người mô tả theo những cách rất khác nhau, và hiện tượng này bộc lộ khá tệ
  • Đoạn đó cũng thật sự nổi bật với tôi
    Nếu Andy Warfield đang đọc, mà có lẽ là đang đọc, tôi có một câu hỏi. Khi phát triển vấn đề, việc phác thảo các giải pháp khả dĩ có giá trị đến mức nào? Nếu diễn đạt rõ vấn đề thì vài giải pháp khả dĩ sẽ tự nhiên nảy ra; có đáng chia sẻ chúng để khởi động suy nghĩ của những người có thể sẽ sở hữu không? Hay tốt hơn là chỉ tập trung vào vấn đề và để không gian giải pháp hoàn toàn mở?
    Thêm nữa, có tài liệu nào đáng đọc thêm về cách vận hành của kiểu individual contributor rất senior như thế này không?
  • Ta thường nghe câu “đừng chỉ mang vấn đề đến, hãy mang cả giải pháp”, và chắc ai cũng từng nghe một lần, nhưng đó thật sự là một câu rất tệ
    Với tôi, nó nghe như “Này dân đen! Ta không có thời gian quan tâm đến vấn đề của ngươi. Nếu ngươi chỉ mang vấn đề đến thì ta đâu thể dùng việc của ngươi để được thăng chức”
    Muốn giải được một vấn đề thì trước hết phải hiểu vấn đề đó và thừa nhận nó tồn tại
  • Tôi rất đồng ý với góc nhìn này, nhưng sẽ tốt nếu có thể khái quát nó thành một kỹ thuật cũng hoạt động trong đời sống hằng ngày, chứ không chỉ trong môi trường đã có sẵn trật tự chuyên môn, nơi người ta chú ý đến “đang nói gì” hơn là “có thẩm quyền để nói điều đó hay không”
    Trong những tình huống không có thẩm quyền hay chuyên môn được công nhận từ trước, tức bối cảnh mà phần lớn vấn đề thường nhật xuất hiện, nếu một mình chiếm kênh đối thoại hai chiều bằng một bản mô tả vấn đề dài, chi tiết và cẩn trọng, bạn dễ bị nhìn như người chỉ nói mà không làm, hoặc như người không muốn cùng người khác tìm giải pháp
  • Cách này chỉ hiệu quả khi đội ngũ gồm những người thông minh và có năng lực

• Thật vui khi thấy nhân viên Amazon đã có thể nói công khai về cách S3 hoạt động bên trong
  Tôi cũng muốn nghe thêm về cách Glacier hoạt động. Theo tôi biết, họ chưa từng công khai nền tảng lưu trữ cơ bản là gì, nên đã có đủ kiểu suy đoán: băng từ, HDD offline, HDD tùy biến...

  • Có giả thuyết cho rằng cốt lõi là đĩa Blu-ray: https://storagemojo.com/2014/04/25/amazons-glacier-secret-bd...
    Nhưng cũng có người không đồng ý. Vẫn là một ẩn số
  • Glacier thật sự là một mảng rất “kín như bưng”
    Ước gì AWS kể cho chúng ta mọi thứ về nó và toàn bộ hành trình của nó. Đó thật sự là một chủ đề rất thú vị
  • Thành thật mà nói, việc đến giờ vẫn chưa bị rò rỉ là cực kỳ ấn tượng
    Chỉ cần một kỹ sư say rượu lỡ miệng là đủ. Trong những lĩnh vực nghiêm trọng hơn nhiều, một quân nhân ở Massachusetts đã rò rỉ thông tin an ninh quốc gia lên Discord để trông ngầu trước bạn bè game thủ và đang đối mặt với án tù dài. Tôi đã nghĩ chi tiết về Glacier hẳn phải lộ ra từ lâu rồi

• “Hãy tưởng tượng đầu đọc/ghi ổ cứng như một chiếc 747 bay trên bãi cỏ với tốc độ 75 dặm/giờ. Khoảng hở không khí giữa đáy máy bay và ngọn cỏ dày bằng hai tờ giấy. Nếu đo các bit trên đĩa bằng lá cỏ, bề rộng track là 4,6 lá cỏ và chiều dài bit là một lá cỏ. Khi chiếc máy bay bay trên bãi cỏ và đếm các lá cỏ, cứ bay 25.000 vòng quanh Trái Đất mới bỏ sót một lá cỏ.”

  • Có câu đùa rằng người Mỹ thích các đơn vị đo lường kỳ lạ, nhưng ví dụ này là một phép so sánh quái dị đến mức đáng được trao giải

• Phần cân bằng tải làm tôi nhớ lại thời S3 KeyMap và lúc cố migrate từ triển khai ban đầu sang nó
  Bài học rút ra là ngay cả sau khi xác định được object/partition/bucket nóng nhất, cũng không thể đơn giản chuyển nó đi rồi xong. Phải sắp xếp mọi thứ theo thứ tự. Giải pháp thực tế là sắp xếp, rồi chia tải partition của các host thành các tứ phân vị, và chuyển partition ở tứ phân vị thứ hai sang host có tải thấp nhất
  Nếu cố chuyển bucket nóng nhất, tức tứ phân vị đầu tiên, tải sẽ dồn thêm lên các thành viên còn lại và cứ tiếp tục thất bại
  Một tác dụng phụ khác là tỷ lệ lỗi từ mức ổn định khoảng 1% chuyển thành nhiều ngày không có lỗi, và kết quả là chúng tôi cập nhật ngưỡng cảnh báo nghiêm ngặt hơn nhiều. Chuyện này khoảng năm 2009
  Tôi cũng có nền tảng học thuật ở UM, nhưng thay vì làm tiến sĩ thì tôi gia nhập S3. Nghe cũng có vần

• S3 không chỉ là lưu trữ, mà còn là chuẩn
  Tôi thích việc ở một số nơi có thể dùng lưu trữ tương thích S3, thường kèm vài lưu ý. Tôi không biết chuẩn này mở đến mức nào, hay muốn nói “S3 compatible” thì có phải trả tiền cho Amazon không, nhưng khá hay
  Ví dụ có iDrive E2, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage, Backblaze B2

  • Còn có Google GCS, và tôi chưa dùng Microsoft, nhưng sẽ khá lạ nếu họ không có tùy chọn “tương thích S3”
    Sửa: tìm thử thì có vẻ Azure thật sự không có :-/

[GN⁺]

Ý kiến Hacker News

• Tỷ lệ lỗi là 1 trên 10^15 yêu cầu là chuyện xảy ra khá thường xuyên trong thế giới thực và là điều cần phải tính đến với S3.

  • Khi còn làm ở AWS, tôi nhớ rằng ở quy mô của S3, những sự kiện có xác suất 1 trên 1 tỷ vẫn xảy ra hằng ngày, và cả những sự kiện có xác suất thấp đến mức bình thường không cần lo cũng phải được cân nhắc và xử lý.
  • Tôi rất vui khi được đọc về ShardStore, đặc biệt ấn tượng với kiểm chứng hình thức, kiểm thử dựa trên thuộc tính, v.v. Thế hệ dịch vụ trước đây nổi tiếng là nhiều lỗi, nhưng ít nhất chúng được thiết kế tốt nhờ các kỹ sư S3 luôn ám ảnh với việc thất bại một cách an toàn để ngăn mất dữ liệu.

• Làm việc trong lĩnh vực hệ gen học, tôi đã xử lý nhiều kho dữ liệu cỡ petabyte trong suốt 10 năm qua.

  • Với kinh nghiệm sử dụng nhiều hệ thống lưu trữ khác nhau như AWS S3, GCP GCS, Ceph, Gluster, các hệ thống của HP, tôi đánh giá rất cao công sức cần bỏ ra để vận hành những hệ thống này.
  • Lợi ích của việc chia sẻ disk IOPS với vô số khách hàng khác là rất lớn, và việc giảm nhẹ vấn đề này trên một hệ thống đơn lẻ là cực kỳ khó.
  • Với các cụm phần cứng colocated, chúng tôi đã phải tùy biến hệ thống batch để xử lý IO như một loại tài nguyên có thể phân bổ giống như RAM hay CPU cho các tác vụ quy mô lớn.
  • S3 và GCP đắt, nhưng hiệu năng của chúng xứng đáng với chi phí đó.

• Nếu S3 có thể dùng giao thức dựa trên OAuth2 để ủy quyền quyền truy cập đọc/ghi, thì sẽ có rất nhiều thứ chúng ta có thể xây dựng.

  • Cần có một giao thức dựa trên HTTP để ứng dụng có thể truy cập dữ liệu thay mặt người dùng.
  • Google Drive là thứ gần nhất với điều đó, nhưng lại có vấn đề nhà cung cấp đơn lẻ, và thật tiếc khi remoteStorage không trở nên phổ biến.
  • Tôi hy vọng Solid sẽ thành công, nhưng nó có vẻ phức tạp.
  • Giải pháp riêng của tôi cho vấn đề này là gemdrive.io, nhưng hiện tại tôi đang tập trung vào những phần khác của stack tự host.

• Phần mô tả thông số năm 1956 của ổ cứng IBM RAMAC.

  • Dung lượng lưu trữ: 3.75 MB, chi phí: khoảng $9,200 mỗi terabyte — thông số này có thể không chính xác.
  • Các trang khác gợi ý giá mua khoảng $10,000 mỗi megabyte, nên thông số đúng có lẽ phải là $9,200 mỗi megabyte.

• Xử lý xác thực trong hệ thống phân tán là việc cực kỳ khó.

  • Ở quy mô AWS, xác thực gần như là phép thuật, và AWS có mô hình phân quyền rất phong phú nên các thay đổi về quyền được lan truyền qua hạ tầng với tốc độ dưới mili giây.
  • Không giống các dịch vụ khác, S3 có thể đặt quyền ở ngay trên tài nguyên để tối ưu tốc độ.

• Là một kỹ sư rất giàu kinh nghiệm với định hướng kỹ thuật rõ ràng, tôi dành nhiều thời gian hơn cho việc phát triển và diễn đạt rõ vấn đề thay vì đưa ra ý tưởng.

  • Để làm tốt vai trò này, cần tập trung vào việc làm rõ vấn đề và ủng hộ hướng giải quyết, đồng thời tìm cách hỗ trợ để một đội ngũ kỹ thuật mạnh có thể thực sự sở hữu giải pháp đó.

• Thật vui khi thấy nhân viên Amazon công khai nói về cách S3 vận hành bên trong.

  • Tôi muốn nghe thêm về cách Glacier hoạt động; vẫn còn nhiều suy đoán vì loại phương tiện lưu trữ được dùng đến nay vẫn chưa được công khai.

• Phần giải thích đầu đọc ổ cứng bằng cách so sánh với máy bay 747.

  • Đó là công việc chính xác đến mức giống như một chiếc máy bay chỉ mắc một sai lầm duy nhất là bỏ lỡ một ngọn cỏ sau khi bay quanh Trái Đất 25,000 lần.

• Quay lại thời KeyMap của S3, người ta học được rằng ngay cả khi xác định được object/partition/bucket nóng nhất, cũng không thể đơn giản di chuyển nó đi là xong.

  • Giải pháp thực tế là chia tải partition của host theo các phân vị bốn phần, rồi chuyển partition ở phân vị thứ hai sang host có tải thấp nhất.
  • Nhờ đó, tỷ lệ lỗi chuyển từ mức ổn định khoảng 1% sang những ngày không còn lỗi, và cảnh báo cũng được cập nhật nghiêm ngặt hơn nhiều.

• S3 không chỉ là một kho lưu trữ, mà còn là một tiêu chuẩn.

  • Một số nơi cung cấp lưu trữ tương thích S3; tôi không chắc tiêu chuẩn này mở đến mức nào hay có phải trả tiền cho Amazon để được nói là "tương thích S3" hay không, nhưng đó là điều rất tuyệt.