- AWS S3 là dịch vụ lưu trữ đối tượng đa tenant quy mô lớn, cung cấp tính sẵn sàng cao và độ bền với chi phí thấp
- Dù sử dụng HDD cũ và chậm (≈120 IOPS), S3 vẫn tối đa hóa hiệu quả kinh tế của phương tiện lưu trữ siêu rẻ, dung lượng lớn
- S3 thiết kế tầng lưu trữ nội bộ (ShardStore) theo kiểu log-structured (LSM) để tối ưu đường ghi cho sequential I/O, còn đường đọc thì bù đắp vấn đề hiệu năng bằng Erasure Coding (5-of-9) và song song hóa quy mô lớn
- Trên toàn bộ đường đi từ client, frontend đến storage, S3 giảm tail latency và cộng gộp throughput bằng các kỹ thuật như multipart upload, byte-range GET, connection pool, hedge request
- Nhờ phân bố ngẫu nhiên, Power of Two Random Choices, rebalancing liên tục, và decorrelation khiến tải được làm phẳng khi quy mô tăng, S3 tránh được hotspot và cuối cùng đạt mức throughput >1 PB/s
Kiến trúc lưu trữ quy mô lớn của AWS S3
- Ai cũng biết AWS S3 là gì, nhưng ít người hiểu S3 vận hành ở quy mô khổng lồ như thế nào và những đổi mới nào đã giúp đạt được điều đó
- S3 là một dịch vụ lưu trữ đối tượng đa tenant có khả năng mở rộng, cho phép lưu và truy xuất đối tượng qua API, đồng thời cung cấp tính sẵn sàng rất cao và độ bền với chi phí tương đối thấp
-
Quy mô của S3
- Lưu trữ hơn 400 nghìn tỷ đối tượng
- Xử lý 150 triệu request mỗi giây
- Hỗ trợ hơn 1 PB traffic mỗi giây ở thời điểm đỉnh
- Vận hành hàng chục triệu ổ cứng
- S3 đặt tính sẵn sàng và độ bền cao (“11 nines” là mục tiêu thiết kế), cùng chi phí tương đối thấp, làm nền tảng cho trải nghiệm người dùng
- Thậm chí đã mở rộng thành lớp lưu trữ mặc định cho data analytics và machine learning data lake
- Mục tiêu thiết kế là duy trì hiệu quả chi phí trong khi vẫn chịu được mẫu truy cập ngẫu nhiên và mức đồng thời cực lớn
- S3 được xây dựng với giả định về workload random access tổng hợp, nơi mỗi tenant truy cập ở kích thước và offset tùy ý
Công nghệ nền tảng: ổ cứng HDD
- Khả năng mở rộng và hiệu năng đáng kinh ngạc của S3 lại được xây dựng trên phương tiện lưu trữ truyền thống là HDD
- HDD là công nghệ lâu đời, độ bền cao nhưng có chuyển động vật lý, nên bị giới hạn về IOPS và độ trễ
- Vì cần đến chuyển động cơ học như vòng quay (ví dụ: 7200 RPM) và actuator seeking, nên độ trễ về cấu trúc là lớn và khó tránh khỏi
- Seek nửa vòng trung bình ≈4 ms, nửa vòng quay trung bình ≈4 ms, truyền 0.5 MB ≈2.5 ms → đọc ngẫu nhiên 0.5 MB trung bình ≈11 ms, throughput random của một ổ đĩa ≈45 MB/s
- Không giống SSD, HDD vẫn giữ được tính kinh tế “siêu rẻ/dung lượng lớn” nhờ xu hướng dài hạn dung lượng tăng, giá giảm, nên tiếp tục được dùng cho lưu trữ quy mô lớn
- Giá: giảm 6 tỷ lần trên mỗi byte (đã điều chỉnh theo lạm phát)
- Dung lượng: tăng 7.2 triệu lần
- Kích thước: giảm 5 nghìn lần
- Trọng lượng: giảm 1.235 lần
- Tuy vậy, trong 30 năm qua IOPS gần như dậm chân ở mức khoảng 120, còn hiệu năng truy cập ngẫu nhiên và độ trễ không cải thiện nhiều
- SSD mạnh hơn về random I/O, nhưng ở quy mô lưu trữ peta/exa thì lại bất lợi về tổng chi phí sở hữu (TCO)
Đường ghi tối ưu cho sequential I/O
- HDD được tối ưu cho truy cập tuần tự; khi đọc và ghi các byte liên tiếp, platter có thể quay tự nhiên và xử lý dữ liệu nhanh hơn
- Cấu trúc dữ liệu dựa trên log (log-structured) tận dụng đặc tính tuần tự này
- ShardStore, tầng lưu trữ nội bộ của S3, áp dụng log-structured LSM để xử lý ghi bằng append tuần tự lên đĩa
- Tương tự, cũng có thể tối đa hóa throughput tuần tự của đĩa bằng xử lý theo lô
Song song hóa và Erasure Coding cho đường đọc ngẫu nhiên
- Việc đọc phải nhảy tới các vị trí ngẫu nhiên theo yêu cầu người dùng, nên trực tiếp gặp giới hạn vật lý này (độ trễ trung bình của random I/O khoảng 11 ms)
- Một HDD đơn lẻ chỉ xử lý tối đa khoảng 45 MB/s với random I/O
- Vì thế HDD rất kinh tế cho lưu trữ khối lượng lớn, nhưng hiệu năng truy cập ngẫu nhiên lại yếu
- Để vượt qua giới hạn vật lý này, S3 áp dụng song song hóa quy mô lớn bằng cách shard dữ liệu lên nhiều ổ đĩa và đọc đồng thời để cộng gộp throughput
- Dữ liệu được phân tán lên rất nhiều HDD, tận dụng I/O song song của từng ổ để tăng mạnh throughput tổng thể
- Ví dụ, nếu một file 1 TB được chia và lưu trên 20.000 HDD, có thể cộng gộp throughput của toàn bộ đĩa để đạt tốc độ đọc cấp TB/s
Mã sửa lỗi xóa (Erasure Coding)
- Trong hệ thống lưu trữ, việc đảm bảo tính dư thừa là bắt buộc
- S3 dùng Erasure Coding (EC) để chia dữ liệu thành K mảnh dữ liệu và M mảnh parity
- Chỉ cần bất kỳ K mảnh nào trong tổng số K+M là có thể khôi phục
- S3 dùng cấu trúc 9 mảnh (5 data shard, 4 parity shard), tức Erasure Coding (5-of-9), để đạt điểm cân bằng
- 5 mảnh dữ liệu + 4 mảnh parity = 9 mảnh
- Có thể khôi phục dù mất tối đa 4 shard, tức chỉ cần bất kỳ 5 mảnh nào để tái tạo dữ liệu gốc, cung cấp khả năng chịu lỗi
- Overhead lưu trữ là ≈1.8x, hiệu quả dung lượng hơn sao chép 3 bản (3x)
- Đồng thời có 5 đường đọc song song, thuận lợi cho song song hóa theo shard và tránh straggler
- Nhờ đó, S3 vượt qua giới hạn vật lý này và cung cấp truy cập ngẫu nhiên cho dữ liệu quy mô lớn
Cấu trúc xử lý song song
- S3 sử dụng 3 kiểu song song hóa chính
- 1. Người dùng chia dữ liệu thành nhiều chunk để upload và download
- 2. Client gửi request đồng thời tới nhiều frontend server
- 3. Server phân tán đối tượng lên nhiều storage server
-
1. Song song hóa ở cấp frontend server
- Tận dụng HTTP connection pool nội bộ để kết nối đồng thời tới nhiều endpoint phân tán
- Giúp tránh quá tải ở một node hạ tầng hoặc cache cụ thể
-
2. Song song hóa giữa các ổ cứng
- Dữ liệu được phân tán thành các shard nhỏ trên nhiều HDD dựa trên EC
-
3. Song song hóa request PUT/GET
- Client chia dữ liệu thành nhiều phần để upload song song
- PUT: tối đa hóa song song hóa với multipart upload
- GET: hỗ trợ byte-range GET (chỉ đọc một phần phạm vi trong object)
- Khi phân tán và xử lý song song, việc upload 1 GB mỗi giây cũng có thể đạt được dễ dàng
Tránh hotspot
- S3 vận hành song song trên hàng chục triệu ổ đĩa, hàng trăm triệu request mỗi giây, và hàng trăm triệu shard
- Nếu tải dồn vào một ổ đĩa hoặc node cụ thể, toàn bộ hệ thống có thể bị suy giảm hiệu năng
- Các chiến lược cốt lõi để ngăn điều đó:
- 1. Phân bố ngẫu nhiên vị trí lưu dữ liệu
- 2. Rebalancing liên tục
- 3. Mở rộng quy mô hệ thống
-
1. Shuffle sharding & Power of Two
- Vị trí lưu dữ liệu ban đầu được phân tán ngẫu nhiên
- Áp dụng thuật toán Power of Two Random Choices:
- Chọn node ít tải hơn giữa 2 node ngẫu nhiên sẽ tạo ra hiệu quả cân bằng tải rất tốt
-
2. Rebalancing
- Nhiệt độ dữ liệu: tận dụng đặc tính dữ liệu mới thì nóng hơn (được truy cập thường xuyên hơn) để rebalancing định kỳ nhằm phân phối lại không gian và I/O
- Dữ liệu càng cũ thì tần suất truy cập càng giảm, nên dư địa I/O của toàn bộ storage càng tăng
- S3 tái phân tán dữ liệu lạnh để tối đa hóa việc sử dụng không gian và tài nguyên
- Khi đưa rack mới vào (ví dụ: 20 PB/rack, 1000×20 TB), cần phân tán chủ động vào phần dung lượng trống
-
3. Chill@Scale
- Hiệu ứng quy mô: khi workload càng độc lập, đồng thời dạng burst càng giảm, tạo ra hiện tượng decorrelation làm phẳng tải tổng hợp
- Hệ thống càng lớn thì càng có lợi thế thu hẹp chênh lệch đỉnh/trung bình và cải thiện khả năng dự đoán
- Nói cách khác, dù mức sử dụng của từng bên có lặp lại kiểu tăng vọt-rảnh rỗi, ở quy mô lớn chúng sẽ bù trừ lẫn nhau để giữ tải ở mức có thể dự đoán
Văn hóa vận hành, độ tin cậy và các kỹ thuật khác
- Dùng DNS-level shuffle sharding để hướng tới việc cô lập tenant và phân phối đồng đều ngay ở tầng name resolver
- Phát hành phần mềm cũng được thực hiện dần dần, không gián đoạn như EC; quá trình chuyển sang ShardStore cũng diễn ra mà không ảnh hưởng đến dịch vụ
- Văn hóa độ bền: bảo đảm độ tin cậy dựa trên quy trình như phát hiện lỗi liên tục, chain of custody, mô hình hóa mối đe dọa độ bền, kiểm chứng hình thức
Vì sao điều này quan trọng: xu hướng hạ tầng dữ liệu dựa trên S3
- Cùng với sự phổ biến của kiến trúc stateless, ngày càng nhiều ứng dụng để node ứng dụng không giữ trạng thái và giao phó persistence, replication, load balancing cho S3
- Ví dụ: Kafka Diskless(KIP-1150), SlateDB, Turbopuffer, Lucene on S3, tích hợp object storage của ClickHouse/OpenSearch/Elastic
- Ưu điểm là co giãn linh hoạt, đơn giản hóa vận hành, tiết kiệm chi phí; nhược điểm là có thể tăng độ trễ, nên cần thiết kế trade-off giữa latency, chi phí, độ bền theo từng workload
Tóm tắt
- AWS S3 là dịch vụ lưu trữ đa tenant quy mô lớn, vượt qua giới hạn của phương tiện lưu trữ chậm bằng mức song song cực lớn, cân bằng tải, sharding dữ liệu
- S3 bảo đảm tính ổn định và hiệu năng bằng Erasure Coding, phân bố ngẫu nhiên, rebalancing liên tục, hedge request
- Ban đầu S3 chủ yếu phục vụ backup và media, nhưng nay đã phát triển thành storage chính cho hạ tầng dữ liệu lớn như phân tích dữ liệu và machine learning
- Kiến trúc dựa trên S3 mang lại khả năng mở rộng stateless, đồng thời có thể giao bài toán độ bền, replication và load balancing cho AWS một cách hiệu quả
- Điều này còn giúp giảm chi phí cloud và tăng hiệu quả quản trị
2 bình luận
Nếu công nghệ không tốt thì có lẽ sẽ không có lãi.
Ý kiến trên Hacker News
Có một vài sai sót về mặt dữ kiện, nhưng không ảnh hưởng lớn đến mạch bài. Ví dụ, bài viết nói S3 dùng sơ đồ sharding 5:9, nhưng thực tế S3 dùng nhiều sơ đồ sharding khác nhau, và theo hiểu biết của tôi thì 5:9 không phải một trong số đó. Tỷ lệ 1,8 byte vật lý cho mỗi 1 byte logic là con số thực sự rất tệ nếu nhìn từ góc độ chi phí HDD. Trên thực tế vẫn có cách hạ thấp tỷ lệ đó đồng thời mở rộng mức độ song song và cải thiện tính sẵn sàng. Ví dụ, cần nghĩ đến việc có thể mất bao nhiêu shard trước khi object trở thành không thể GET được khi cả một AZ bị sự cố
Tôi hiểu từ video này ở mốc 42:20 rằng S3 dùng sơ đồ sharding đó. Nếu bạn biết thêm thì tôi rất muốn nghe
Khó mà hình dung được chuyện vừa giảm tỷ lệ 1,8x vừa tăng tính sẵn sàng. Nếu số bản sao ít hơn thì chẳng phải rủi ro mất dữ liệu khi AZ gặp sự cố sẽ cao hơn sao? Tôi cứ nghĩ AWS cung cấp các bản sao hoàn toàn độc lập trên 3 AZ. Và lời giải thích rằng để đọc một chunk 16MB thì thực ra đọc 4MB từ 5 ổ đĩa cứng khác nhau lại nhanh hơn vẫn khiến tôi thấy khá kỳ diệu
VAST data dùng sơ đồ 146+4. (liên kết)
Tôi đọc bài này rất thích, nhưng đáp án cho câu hỏi ở tiêu đề thì quá rõ ràng: đó là tính song song
Bình thường tôi gần như không bao giờ nghĩ về tốc độ I/O lưu trữ ở quy mô lớn như vậy. Hồi xưa tôi từng dùng RAID0 để ghi nhanh hơn lên ổ cứng, nhưng đó là chuyện lâu rồi. Ban đầu tôi tưởng họ sẽ dùng những cách thú vị như caching hay phân tầng. Chỉ sau khi đọc xong tôi mới nhận ra song song hóa đúng là câu trả lời hiển nhiên, nhưng tôi đã không nghĩ tới các chi tiết triển khai của S3 hay cách nó sửa lỗi. Từ "song song" là điểm cốt lõi, nhưng phần chi tiết đem lại rất nhiều insight. Tôi đoán minio cũng có câu chuyện mở rộng tương tự: vẫn là song song hóa
Tôi thấy tiêu đề bài báo hơi gây nhầm vì chỉ tập trung vào peak throughput của toàn bộ S3. Câu hỏi thực sự thú vị theo tôi là: "Làm sao có thể đạt GET throughput vượt quá throughput tối đa của HDD?" Nếu chỉ sao chép đơn thuần thì có thể chỉ định nhiều HDD và chạy GET song song, nên xét trên toàn S3 thì throughput sẽ cao hơn, nhưng cuối cùng vẫn bị trói bởi throughput của từng HDD * số lượng yêu cầu GET. Điều bí mật và thú vị là S3 dường như không bị giới hạn đó
Ghép hàng triệu ổ cứng lại với nhau thì sẽ có băng thông IO khổng lồ
Nghe giống kiểu logic "Cách lên mặt trăng thì rõ rồi: đi du lịch"
Trên các ổ đĩa đời mới, full seek gần với 25ms hơn là 8ms. Nếu muốn tự kiểm tra, chỉ cần có ổ cứng và quyền root thì có thể dùng fio với tùy chọn --readonly và đọc xen kẽ hai đầu đĩa. Cũng có một bài báo rất hay giải thích vì sao con số 1/3 không chính xác với ổ đĩa hiện đại (ở đây). Nếu ai còn tò mò về cơ khí hay hiệu năng của ổ đĩa thì tôi có thể trả lời thêm
Khi đầu đọc di chuyển giữa các track sẽ có quá trình tăng tốc. Quãng đường càng ngắn thì tốc độ đỉnh càng thấp, lại còn có độ trễ cố định như thời gian ổn định đầu đọc, nên trên thực tế trung bình 4ms vẫn có thể đúng
Vì platter có dạng hình tròn nên không nên dùng phân bố đều trên [0, 1] mà phải dùng phân bố trên đường tròn đơn vị [0, 2pi], và vì platter chỉ quay theo một hướng nên khoảng cách luôn phải tính theo chiều kim đồng hồ.
Đơn giản hóa bài toán: nếu điểm bắt đầu là 0 độ còn điểm đích là một vị trí ngẫu nhiên, thì khoảng cách trung bình là bao nhiêu? Vì cung 0-180 độ và 180-360 độ có độ dài như nhau nên khoảng cách trung bình là 180 độ. Tức là half-platter seek chính xác bằng một nửa full-platter seek
Nếu muốn đoán xem S3 có còn dùng HDD cho dịch vụ mặc định hay không thì có thể nhìn vào giá rồi quy đổi theo IOPS. Đơn giá yêu cầu GET/PUT của S3 đủ cao để AWS có dư địa bỏ trống một phần dung lượng đĩa nhằm phục vụ các tenant cần hiệu năng cao. Nhưng cũng không cao hơn mức đó bao nhiêu
Tôi tự hỏi liệu một phần của S3 có chạy trên SSD hay không. Tôi từng nghĩ ngay cả S3 tiêu chuẩn cũng dựa trên SSD, còn chỉ các tier chậm mới dùng HDD hoặc hệ thống chậm hơn
KeyMap Index của S3 dùng SSD. Ở thời điểm hiện tại, tôi nghĩ SSD có lẽ cũng đã được dùng cho cache object nóng hoặc như một phần của các sản phẩm one zone mới
Dữ liệu lưu trữ thực tế nhiều khả năng chủ yếu vẫn nằm trên HDD. Nhưng metadata, index và các phần tương tự chắc sẽ dùng flash nhanh hơn nhiều. Các server MDS trong các cụm Ceph nhỏ cũng thường như vậy, còn S3 thì ở quy mô lớn hơn rất nhiều
Tôi đã nhắc ở trên rồi, nhưng với tier tiêu chuẩn thì đơn giá request đủ cao để kể cả có khách hàng với tỷ lệ IOPS/TB cao, việc để trống một phần dung lượng đĩa vẫn còn hiệu quả về chi phí. Nhưng cao hơn mức đó thì không còn đáng nữa. HDD hiện đại lưu được khoảng 30TB, và dù tôi không biết AWS thực sự mua với giá bao nhiêu, có thể ước chừng vào khoảng 300~500 USD. So với SSD 30TB thì rẻ hơn rất nhiều. Ngoài ra, các HDD này còn có thể được lắp vào những hệ thống mật độ cao, ví dụ 100 ổ trong khung 4U, mà tổng chi phí chỉ tăng thêm khoảng 25%. Ngược lại, phần cứng hỗ trợ SSD số lượng lớn có chi phí trên mỗi khe cắm cao hơn nhiều
Tôi đoán S3 Express One Zone là SSD-based. Tuy nhiên có vẻ Amazon chưa công khai nói điều đó
Metadata thì gần như chắc chắn sẽ nằm trên SSD. Các object nóng được đọc thường xuyên cũng có thể được cache trên SSD
Điều khiến tôi ngạc nhiên là dù giá HDD cứ tiếp tục giảm, giá S3 gần như không đổi trong ít nhất 8 năm. Có vẻ thiếu cạnh tranh về giảm giá nên họ vẫn giữ được mức phí cao. Có thể tưởng tượng điều này mang lại lợi nhuận lớn đến mức nào cho AWS
Chính sách giá của AWS gần như vậy ở mọi dịch vụ. Ví dụ instance EC2 m7a.medium có giá on-demand là 50 USD/tháng, còn reserved 1 năm là 35 USD. So với dịch vụ từ các công ty khác có cấu hình tương tự thì tính cạnh tranh không quá cao
Cũng phải tính đến lạm phát, nên ngay cả khi giá danh nghĩa giữ nguyên thì trên thực tế vẫn là giảm giá. Nhưng tôi đồng ý rằng lạm phát phản ánh chậm hơn rất nhiều so với tốc độ tiến bộ công nghệ
Tôi nghĩ mục tiêu của incentive không phải là giảm chi phí. Nếu nhìn vào các công ty như Splunk hay CrowdStrike lưu lượng dữ liệu khổng lồ trên AWS, sẽ thấy có rất nhiều dữ liệu lặp lại; họ cứ thế tính phí khách hàng và chỉ áp dụng chống trùng lặp dữ liệu ở mức rất đơn giản. Nếu giảm chi phí thì lại tạo ra incentive cho việc sử dụng lãng phí còn nhiều hơn nữa
Tôi cũng tò mò không biết giá HDD thực sự đã giảm mạnh đến mức nào. Trong vài năm gần đây, tốc độ giảm giá trên mỗi GB của ổ cứng đã chậm đi rất nhiều, nên có vẻ SSD rồi sẽ sớm bắt kịp
Tôi đề xuất một bài còn thú vị hơn về S3: "Building and operating a pretty big storage system called S3"
Tôi tò mò không biết hiệu năng thực tế của rustfs ra sao
Khi thấy nhắc đến hàng chục triệu HDD đang được sử dụng, có thể ước tính rằng nếu HDD doanh nghiệp có dung lượng cỡ 10~20TB thì tổng dung lượng của AWS S3 phải ở mức hàng trăm Exabyte. Nó rất có thể là hệ thống lưu trữ lớn nhất trên Trái Đất
Nếu phần cứng đã được nâng cấp kể từ năm 2013 thì một trung tâm dữ liệu cụ thể ở Utah có thể vượt qua dung lượng đó (bài liên quan)
HDD doanh nghiệp hiện tại đã là 30TB, và sắp tới thậm chí có thể lên 50TB
Tôi muốn biết có dịch vụ mã nguồn mở nào được tối ưu cho HDD mà vẫn đạt hiệu năng tương tự không. Các dự án lớn như MinIO, Swift, Ceph+RadosGW, SeaweedFS đều khuyến nghị triển khai all-flash. Gần đây tôi đang xem Garage, nhưng thiết kế của nó khá khác, chẳng hạn không dùng EC
Ceph+RadosGW cũng chạy rất ổn với HDD. Tuy nhiên index pool nên dùng SSD, và cần có kỳ vọng thực tế về số IOPS có thể đạt được từ HDD pool. Vì IOPS ở phía client trên thực tế sẽ bị nhân lên nhiều lần, nên S3 cũng giải quyết bài toán này bằng cách dùng số lượng HDD khổng lồ. Với lưu trữ dung lượng lớn kiểu streaming 4MB thì đây không phải vấn đề lớn, nhưng nếu đọc ghi ngẫu nhiên nhiều key nhỏ hoặc có nhiều truy cập phân tán vào cùng một key thì hiệu năng backend rất quan trọng
Lustre/ZFS cũng có thể đạt tốc độ tương tự. Nhưng nếu cần IOPS cao thì với Lustre sẽ cần flash cho MDS, còn ZFS sẽ cần SSD log chuyên dụng
Tất cả các dịch vụ này chỉ đạt hiệu năng tương đương nếu có rất nhiều ổ đĩa ở quy mô trung tâm dữ liệu lớn. Rất ít hệ thống triển khai có thể xử lý ở mức scale như vậy. Vì thế flash hiệu quả hơn nhiều cho truy cập nhanh xét theo không gian/chi phí
SeaweedFS đã tiến bộ rất nhiều trong vài năm gần đây, thêm hỗ trợ RDMA và cả EC
Ở chỗ làm cũ, tôi từng vận hành object storage dựa trên SwiftStack; metadata lưu trên SSD còn dữ liệu object lưu trên HDD thường. Nó hoạt động hoàn toàn ổn