AWS S3 là một dịch vụ mà hầu như mọi kỹ sư trong ngành IT đều đã quen mặt.
Đây là dịch vụ đã giúp khái niệm "lưu trữ lạnh" (cold-storage) trở nên phổ biến rộng rãi trong thế giới điện toán đám mây. Về cơ bản, S3 là một dịch vụ lưu trữ đa-tenant (multi-tenant) có khả năng mở rộng (scalable), cung cấp các giao diện để lưu trữ và truy xuất đối tượng (object) với tính sẵn sàng (availability) và độ bền bỉ (durability) cực cao, mà chi phí lại vô cùng phải chăng. Điều đặc biệt là khách hàng sẽ chia sẻ toàn bộ phần cứng bên dưới.
S3 cũng là một trong những dịch vụ "hot" nhất, được yêu thích nhất của AWS.
Trải qua 18 năm kể từ khi ra mắt vào năm 2006, S3 đã phát triển thành một "gã khổng lồ" thực sự, trải dài 31 khu vực (regions) và 99 vùng sẵn sàng (availability zones). Những con số mà S3 tự hào sở hữu còn cho thấy quy mô ấn tượng, vượt xa mọi giới hạn:
- 100 triệu yêu cầu mỗi giây
- 400 Terabit mỗi giây
- 280 nghìn tỷ đối tượng được lưu trữ
Dưới đây là cột mốc đáng nhớ về các tính năng chính của S3 kể từ khi ra mắt:
- 2006: S3 chính thức ra mắt
- 2012: Giới thiệu Glacier – một dịch vụ chi phí thấp để lưu trữ và sao lưu dữ liệu dài hạn (thời gian truy xuất mất từ vài phút đến vài giờ)
- 2013: S3 Intelligent-Tiering – một tính năng tự động di chuyển dữ liệu của bạn đến tầng truy cập (access tier) hiệu quả chi phí nhất
- 2015: Standard-Infrequent Access – một tầng mới dành cho dữ liệu ít được truy cập hơn, nhưng vẫn cần truy cập nhanh chóng khi cần
- 2018: Glacier Deep Archive – phiên bản Glacier rẻ hơn với thời gian truy xuất chậm hơn nhiều (12 giờ)
- 2020: Giới thiệu strong read-after-write consistency (tính nhất quán đọc-sau-ghi mạnh mẽ)
- 2021: Object Lambda – cho phép khách hàng thêm code của riêng họ vào các yêu cầu S3 GET, chỉnh sửa dữ liệu khi nó được trả về ứng dụng
- 2023: S3 Express ra mắt, cung cấp độ trễ (latency) tốt hơn 10 lần (chỉ vài mili giây) và chi phí yêu cầu rẻ hơn 50%.
Ban đầu, S3 được tối ưu hóa cho việc sao lưu, lưu trữ video và hình ảnh cho các trang web thương mại điện tử. Nhưng theo thời gian, với quy mô và nhu cầu tăng trưởng "chóng mặt", nó đã trở thành hệ thống lưu trữ chính cho các tác vụ phân tích (analytics) và Machine Learning trên các kho dữ liệu khổng lồ (data lakes). Nhìn vào các xu hướng hiện tại, S3 dường như đang trở thành "xương sống" lưu trữ không thể thiếu cho bất kỳ hạ tầng dữ liệu cloud-native nào.
Kiến trúc
S3 được cho là được xây dựng từ hơn 300 microservices.
Nhưng điểm thú vị là S3 lại cố gắng tuân thủ một nguyên tắc thiết kế cốt lõi: sự đơn giản đến bất ngờ.
Bạn có thể phân biệt kiến trúc của nó qua bốn dịch vụ cấp cao:
- Một nhóm máy chủ front-end với REST API
- Một dịch vụ quản lý namespace
- Một nhóm máy chủ lưu trữ chứa đầy ổ cứng
- Một nhóm máy chủ quản lý lưu trữ, thực hiện các tác vụ nền như replication (nhân bản) và tiering (phân tầng).
Tóm lại, có thể hình dung S3 như một dịch vụ lưu trữ đối tượng (object storage) đa-tenant với HTTP REST API.
Người ta thường nói rằng AWS "triển khai" chính sơ đồ tổ chức của mình.
Điều này có nghĩa là kiến trúc của S3 thể hiện rõ rệt Quy luật Conway (Conway's Law): lý thuyết cho rằng các tổ chức sẽ thiết kế hệ thống phản ánh cấu trúc giao tiếp nội bộ của họ.
Mỗi trong bốn thành phần này đều là một phần của tổ chức S3, mỗi thành phần lại có những lãnh đạo và đội ngũ riêng biệt. Điều thú vị là cấu trúc này được cho là tiếp tục một cách đệ quy – các "ô" trên sơ đồ tổ chức lại chứa các thành phần con riêng lẻ, với đội ngũ và "fleet" của riêng họ. Có thể nói, chúng hoạt động không khác gì những "doanh nghiệp" độc lập.
Và cách các đội tương tác với nhau? Đó chính là thông qua các "hợp đồng" ở cấp độ API chuẩn chỉnh, mà các kỹ sư phải có trách nhiệm duy trì và đảm bảo.
Nhóm máy chủ lưu trữ (Storage Fleet)
S3 thực chất là một hệ thống siêu lớn được xây dựng từ HÀNG TRIỆU ổ cứng vật lý.
Cốt lõi của hệ thống này là các máy chủ node lưu trữ (storage node servers). Chúng là các kho dữ liệu key-value đơn giản, có nhiệm vụ lưu trữ dữ liệu đối tượng vào ổ cứng. Các máy chủ node chỉ chứa các phân đoạn (shards) của dữ liệu đối tượng tổng thể, trong khi control plane sẽ nhân bản (replicate) các shard này trên nhiều node khác nhau.
AWS đã dành nhiều tâm huyết chia sẻ về backend lưu trữ mới của họ – ShardStore. Thật bất ngờ, nó chỉ bắt đầu với 40.000 dòng code Rust!
Về cơ bản, nó là một log-structured merge tree (LSM Tree) đơn giản, với dữ liệu shard được lưu trữ bên ngoài cây để giảm write amplification.
ShardStore sử dụng giao thức nhất quán (consistency protocol) dựa trên soft-updates để chống lỗi khi crash và được thiết kế từ đầu để hỗ trợ concurrency (đồng thời) cực kỳ lớn. Nó tận dụng nhiều tối ưu hóa để sử dụng IO của HDD một cách hiệu quả, chẳng hạn như lập lịch các hoạt động (scheduling operations) và coalescing (gộp các thao tác).
Đây có lẽ là phần code quan trọng nhất trong S3, và do đó, quy trình phát triển của nó được đầu tư rất mạnh. AWS đã viết rất chi tiết về các phương pháp formal verification (kiểm chứng hình thức) "nhẹ nhàng" mà họ đã tích hợp vào quy trình làm việc của các kỹ sư.
Ổ cứng (Hard Drives)
Ổ cứng (Hard drives) là một công nghệ cũ, không phải lúc nào cũng lý tưởng cho mọi trường hợp sử dụng – chúng bị hạn chế về IOPS, có độ trễ tìm kiếm (seek latency) cao và dễ bị hỏng vật lý.
Đáng để nhìn lại và xem xét sự tiến hóa của chúng:
- 1956: ổ đĩa 3.75MB có giá 9.000 USD
- 2024: ổ đĩa 26TB đã xuất hiện, với 1TB chỉ có giá 15 USD
Trong suốt quá trình tồn tại, chúng đã chứng kiến sự cải thiện theo cấp số nhân:
- Giá: rẻ hơn 6 tỷ lần mỗi byte (tính theo USD đã điều chỉnh lạm phát)
- Dung lượng: tăng 7,2 triệu lần
- Kích thước: giảm 5.000 lần
- Trọng lượng: giảm 1.235 lần
Nhưng có một vấn đề vẫn tồn tại – chúng bị hạn chế về IOPS. Suốt một thời gian dài, IOPS của ổ cứng chỉ quanh quẩn ở mức 120. Tương tự, độ trễ (latency) cũng không theo kịp tốc độ phát triển của các yếu tố khác.
Điều này có nghĩa là, tính trên mỗi byte, HDD đang trở nên chậm hơn.
Trong một thế giới ngày càng nhạy cảm với độ trễ, thật khó để HDD bắt kịp các yêu cầu khắt khe của hệ thống hiện đại.
Tuy nhiên, S3 đã tìm ra một cách để vẫn đảm bảo độ trễ chấp nhận được trong khi khắc phục vấn đề này – đó là tận dụng mạnh mẽ Parallel IO (IO song song).
Nhân bản (Replication)
Trong các hệ thống lưu trữ, các phương án dự phòng (redundancy schemes) là một thực tiễn phổ biến.
Chúng thường gắn liền với độ bền bỉ (durability) bổ sung – giúp bảo vệ dữ liệu khỏi các lỗi phần cứng. Nếu một đĩa bị hỏng, một bản sao của dữ liệu vẫn còn trên đĩa khác, do đó dữ liệu không bị mất.
Một khía cạnh thường bị đánh giá thấp của các phương án dự phòng này là quản lý tải nhiệt (heat). Các phương án này giúp phân tán tải và mang lại cho hệ thống của bạn sự linh hoạt để điều hướng lưu lượng đọc một cách cân bằng.
S3 sử dụng Erasure Coding (EC). Đây là một phương pháp bảo vệ dữ liệu phức tạp, chia dữ liệu thành K shard (phân đoạn) và thêm M shard "parity" dự phòng. EC cho phép bạn khôi phục dữ liệu từ bất kỳ K shard nào trong tổng số K+M shard.
Ví dụ: chia dữ liệu thành 10 mảnh, thêm 6 shard parity. Bạn có thể mất tới 6 shard mà dữ liệu vẫn an toàn.
Replication (nhân bản dữ liệu) thì tốn kém về mặt độ bền bỉ (vì tốn rất nhiều dung lượng bổ sung), nhưng lại hiệu quả về mặt I/O. Erasure Coding giúp S3 tìm ra một sự cân bằng hợp lý: không tốn quá nhiều dung lượng bổ sung cho nhu cầu bền bỉ (họ không nhân bản dữ liệu gấp 3 lần) mà vẫn cung cấp cơ hội I/O linh hoạt và sống sót qua cùng số lượng lỗi đĩa.
Phân đoạn (Sharding)
S3 luôn nỗ lực phân tán các shard này rộng rãi hết mức có thể. Họ tiết lộ rằng có tới hàng chục ngàn khách hàng với dữ liệu được lưu trữ trên hơn một triệu ổ đĩa vật lý!
Việc phân tán dữ liệu mang lại cho họ những lợi ích sau:
1. Tránh điểm nóng (Hot Spot Aversion)
Khi dữ liệu được phân tán tốt, không khách hàng nào có thể gây ra hot spot (điểm nóng) ảnh hưởng đến toàn hệ thống. Hot spot đặc biệt rắc rối và cần tránh, vì chúng gây ra sự chậm trễ dây chuyền khắp hệ thống, và trong trường hợp xấu nhất, có thể dẫn đến hiệu ứng domino khó chịu.
2. Nhu cầu bùng nổ (Burst Demand)
Tương tự, tính song song (parallelism) bổ sung mà mỗi ổ đĩa chứa shard mang lại có thể cho phép IO bùng nổ (burst IO) lớn hơn nhiều so với một giải pháp đơn giản. (ví dụ: dữ liệu được nhân bản trên 3 ổ đĩa)
3. Độ bền bỉ cao hơn (Greater Durability)
Các shard càng được phân tán rộng, độ bền bỉ càng cao. Hệ thống có thể chịu đựng nhiều lỗi máy riêng lẻ hơn.
4. Không khuếch đại đọc (No Read Amplification)
Read amplification (khuếch đại đọc) chỉ số lượng lần tìm kiếm đĩa (disk seeks) mà một lần đọc gây ra. Giả sử phần cứng đồng nhất, một lần đọc duy nhất vẫn sẽ gây ra cùng một lượng tìm kiếm đĩa. Nhưng vì dữ liệu được phân tán, các lần tìm kiếm đó sẽ không diễn ra trên cùng một ổ đĩa.
Càng ít lần tìm kiếm đĩa mà một HDD cần thực hiện, thì càng tốt. Điều này giảm khả năng xảy ra độ trễ cao.
Quản lý tải nhiệt ở quy mô lớn (Heat Management at Scale)
Với quy mô "khổng lồ" hiện tại, một trong những thách thức kỹ thuật lớn nhất của S3 là làm sao quản lý và cân bằng nhu cầu I/O "dữ dội" này trên một "biển" ổ cứng.
Mục tiêu chung là giảm thiểu số lượng yêu cầu truy cập cùng một đĩa tại bất kỳ thời điểm nào. Nếu không, như đã đề cập – bạn sẽ gặp phải hot spot và tích tụ tail latency (độ trễ ở phần đuôi), cuối cùng ảnh hưởng đến tổng độ trễ yêu cầu.
Trong trường hợp xấu nhất, số lượng yêu cầu không cân xứng trên cùng một ổ đĩa có thể gây tắc nghẽn (stalling) khi giới hạn I/O mà đĩa cung cấp bị cạn kiệt. Điều này dẫn đến hiệu suất tổng thể kém cho các yêu cầu phụ thuộc vào (các) ổ đĩa đó. Khi các yêu cầu bị tắc nghẽn, độ trễ sẽ được khuếch đại lên các tầng của software stack – chẳng hạn như các yêu cầu ghi Erasure Coding cho dữ liệu mới hoặc tra cứu metadata.
Việc đặt dữ liệu ban đầu là rất quan trọng, nhưng cũng rất khó để thực hiện đúng vì S3 không biết khi nào hoặc dữ liệu sẽ được truy cập như thế nào tại thời điểm ghi.
Đội ngũ S3 tiết lộ rằng, chính vì quy mô "khủng khiếp" của hệ thống và đặc tính đa-tenant, một vấn đề vốn dĩ cực kỳ khó nhằn này lại trở nên dễ giải quyết hơn về mặt cơ bản.
S3 trải nghiệm một hiện tượng thú vị được gọi là workload decorrelation (giảm tương quan tải công việc). Đây là hiện tượng khi tải công việc được tổng hợp ở quy mô đủ lớn, nó sẽ trở nên "mượt mà" và ổn định hơn đáng kể.
Đội ngũ S3 chia sẻ rằng hầu hết các workload lưu trữ đều ở trạng thái "ngủ yên" phần lớn thời gian. Chúng chỉ trải qua một đỉnh tải đột ngột khi dữ liệu được truy cập, và nhu cầu ở đỉnh này cao hơn nhiều so với mức trung bình.
Nhưng khi hệ thống tổng hợp hàng triệu workload, lưu lượng truy cập cơ bản đến bộ nhớ trở nên "phẳng" một cách đáng kinh ngạc. Nhu cầu tổng hợp dẫn đến một throughput (thông lượng) mượt mà hơn, dễ dự đoán hơn.
Khi bạn tổng hợp ở quy mô đủ lớn, một workload riêng lẻ không thể ảnh hưởng đến đỉnh tổng hợp.
Vấn đề khi đó trở nên dễ giải quyết hơn nhiều – bạn chỉ cần cân bằng một tốc độ yêu cầu mượt mà trên nhiều đĩa.
Tính song song (Parallelism)
Parallelism (tính song song) mang lại lợi ích chung cho cả AWS và khách hàng – nó không chỉ mở khóa hiệu suất tốt hơn cho khách hàng mà còn cho phép S3 tối ưu hóa cho workload decorrelation.
Hãy cùng xem xét một vài ví dụ minh họa bằng con số:
Hai ví dụ đối lập
Hãy tưởng tượng một bucket S3 dung lượng 3.7 Petabyte. Giả sử nó nhận 2.3 triệu IO mỗi giây.
Với các ổ đĩa 26 TB, bạn chỉ cần 143 ổ đĩa để hỗ trợ dung lượng 3.7PB. Nhưng với 120 IOPS thấp trên mỗi đĩa, bạn sẽ cần tới 19.166 ổ đĩa cho nhu cầu 2.3 triệu IO! Con số này nhiều hơn tới 13.302% số lượng ổ đĩa cần thiết.
Bây giờ hãy tưởng tượng trường hợp ngược lại – một bucket S3 dung lượng 28 PB chỉ với 8.500 IO mỗi giây.
Với 120 IOPS mỗi đĩa, bạn sẽ cần 71 ổ đĩa cho các IO. Với ổ đĩa 26 TB, bạn sẽ cần 1076 ổ đĩa cho dung lượng. Tức là nhiều hơn 1.415% số lượng ổ đĩa.
Mức mất cân bằng 134 lần trong một trường hợp, 15 lần trong trường hợp khác.
S3 có thể có cả hai loại workload này, nhưng yêu cầu về số lượng ổ đĩa lớn chứng tỏ sự cần thiết của parallelism để đạt được thông lượng đọc (read throughput) cần thiết.
Tính song song trong thực tế
S3 tận dụng parallelism theo hai cách:
Giữa các máy chủ (Across Servers)
Parallelism bắt đầu ngay từ phía client!
Thay vì yêu cầu tất cả các tệp thông qua một client với một kết nối đến một S3 endpoint duy nhất, người dùng được khuyến khích tạo càng nhiều yêu cầu và kết nối song song càng tốt. Điều này tận dụng nhiều endpoint khác nhau của hệ thống phân tán, đảm bảo không có điểm nào trong hạ tầng trở nên quá nóng (ví dụ như các cache).
Trong một thao tác (Intra-Operation)
Trong một thao tác duy nhất bên trong một kết nối, S3 cũng tận dụng parallelism.
- Các yêu cầu PUT hỗ trợ multipart upload, mà AWS khuyến nghị để tối đa hóa throughput bằng cách tận dụng nhiều luồng (threads).
- Các yêu cầu GET tương tự hỗ trợ một HTTP header chỉ định bạn chỉ đọc một phạm vi cụ thể của đối tượng. AWS cũng khuyến nghị điều này để đạt được throughput tổng hợp cao hơn thay vì một yêu cầu đọc đối tượng duy nhất.
Metadata và xu hướng chuyển sang tính nhất quán mạnh mẽ (Strong Consistency)
Vào năm 2020, S3 đã giới thiệu tính nhất quán đọc-sau-ghi mạnh mẽ (strong read-after-write consistency). Điều này có nghĩa là, một khi bạn ghi một đối tượng mới hoặc ghi đè một đối tượng hiện có, mọi lần đọc tiếp theo sẽ nhận được phiên bản mới nhất của đối tượng đó.
Đây thực sự là một thay đổi "khủng" khi xét đến quy mô hoạt động của S3, đặc biệt là khi nó được triển khai mà không hề ảnh hưởng tới hiệu suất, tính sẵn sàng hay chi phí!
S3 có một hệ thống con riêng biệt để lưu trữ metadata từng đối tượng. Vì việc ghi/đọc metadata là một phần của đường dẫn dữ liệu quan trọng cho hầu hết các yêu cầu, tầng bền vững (persistence tier) của hệ thống được thiết kế để sử dụng công nghệ caching có khả năng phục hồi cao, đảm bảo rằng ngay cả khi nó bị lỗi, các yêu cầu S3 vẫn thành công.
Điều này có nghĩa là các thao tác ghi có thể đi qua một phần của hạ tầng cache, trong khi các thao tác đọc có thể truy vấn một phần khác, dẫn đến việc đọc dữ liệu cũ (stale read). Người ta nói rằng đây là nguyên nhân chính gây ra tính nhất quán cuối cùng (eventual consistency) của S3.
Là một phần của các tính năng khác, S3 đã giới thiệu logic nhân bản (replication logic) mới vào tầng bền vững của nó, cho phép họ suy luận về thứ tự các hoạt động từng đối tượng. Là một phần cốt lõi của giao thức nhất quán cache (cache coherency protocol) của họ, điều này cho phép họ hiểu liệu một chế độ xem đối tượng của cache có bị cũ hay không.
Một thành phần mới đã được giới thiệu để theo dõi điều này. Thành phần này hoạt động như một “nhân chứng” (witness) cho các thao tác ghi của S3 và một "rào cản" đọc (read barrier) trong quá trình đọc của S3. Khi thành phần này nhận ra rằng một giá trị có thể đã cũ, nó sẽ bị vô hiệu hóa khỏi cache và được đọc từ tầng bền vững (persistence layer).
Độ bền bỉ (Durability)
S3 tự hào "khoe" độ bền bỉ "khủng khiếp" với 11 số 9 – tức là 99.999999999%! Theo tính toán, tỷ lệ mất đối tượng trung bình hàng năm dự kiến chỉ vỏn vẹn 0.000000001%.
Nói một cách dễ hiểu, nếu bạn lưu trữ 10.000 đối tượng trên S3, bạn có thể "yên tâm" rằng chỉ khoảng 10 triệu năm nữa thì may ra mới mất một đối tượng duy nhất!
Lỗi phần cứng (Hardware Failure)
Đạt được độ bền bỉ "11 số 9" là một kỳ công khó khăn. Ổ cứng thường xuyên hỏng hóc, và ở quy mô của S3, điều này có thể xảy ra hàng giờ.
Về lý thuyết, độ bền bỉ rất đơn giản. Khi ổ cứng hỏng, bạn sửa chữa chúng. Miễn là tốc độ sửa chữa khớp với tốc độ hỏng hóc, dữ liệu của bạn sẽ an toàn.
Nhưng trên thực tế, để đảm bảo quy trình này đáng tin cậy khi đối mặt với các lỗi không thể đoán trước, bạn cần xây dựng một hệ thống hoàn chỉnh xung quanh nó.
AWS chia sẻ một ví dụ đơn giản trong thế giới thực về nơi các lỗi tích tụ – hãy tưởng tượng trung tâm dữ liệu nằm trong khí hậu nóng và xảy ra mất điện. Hệ thống làm mát của nó ngừng hoạt động. Các đĩa bắt đầu quá nhiệt và tỷ lệ hỏng hóc tăng lên đáng kể.
AWS đã xây dựng một hệ thống tự phục hồi liên tục (continuous self-healing system) với các bộ phát hiện theo dõi các lỗi và mở rộng đội sửa chữa của họ tương ứng.
Ở chế độ nền, một mô hình bền bỉ chạy phân tích để theo dõi xem độ bền bỉ mong muốn có thực sự được đáp ứng hay không.
Bài học ở đây là độ bền bỉ không thể là một "ảnh chụp nhanh" duy nhất của hệ thống – nó là một quá trình đánh giá liên tục.
Các loại lỗi khác
Độ bền bỉ là một khái niệm rất rộng. Phần cứng của bạn có thể hoạt động tốt nhưng dữ liệu vẫn có thể bị mất bằng các phương tiện khác, như triển khai một bug làm hỏng dữ liệu, lỗi của người vận hành vô tình xóa dữ liệu, các triển khai có vấn đề, hoặc mạng làm hỏng các bit được khách hàng tải lên trước khi nó đến trung tâm dữ liệu của bạn.
Chẳng hạn, S3 đã triển khai cái mà họ gọi là "chuỗi kiểm soát bền vững" (durable chain of custody). Để giải quyết trường hợp dữ liệu có thể bị hỏng trước khi đến S3, AWS đã triển khai một checksum trong SDK được thêm vào dưới dạng HTTP Trailer (tránh phải quét dữ liệu hai lần) vào yêu cầu.
Quy mô khổng lồ của S3 có nghĩa là bất kỳ lỗi lý thuyết nào có thể xảy ra thì có lẽ đã được chứng kiến, hoặc sẽ sớm xảy ra.
Văn hóa
Để đạt được một kỳ tích kỹ thuật như S3, đó không chỉ là về đổi mới công nghệ mà còn là về tổ chức xã hội.
Với các kỹ sư mới gia nhập và những người có kinh nghiệm rời đi, việc duy trì cùng một tốc độ phát triển ở quy mô và rủi ro ngày càng tăng có thể khó khăn.
AWS hướng tới tự động hóa càng nhiều càng tốt. Họ đã tích hợp các bài kiểm tra dựa trên thuộc tính (property-based tests) mở rộng, lặp lại qua các bộ mẫu yêu cầu lớn, cũng như formal verification (kiểm chứng hình thức) "nhẹ nhàng" vào pipeline CI/CD của họ. Cả hai tính năng này đều tự động hóa, mang lại sự tự tin cho các kỹ sư trong việc...
AWS đã chia sẻ rằng nội bộ họ tuân theo một phương pháp thiết kế "Mô hình Đe dọa Độ bền bỉ" (Durability Threat Model), mượn từ mô hình đe dọa bảo mật phổ biến. Khi thiết kế các tính năng, họ tính đến bất kỳ mối đe dọa tiềm tàng nào đối với độ bền bỉ và đảm bảo họ suy nghĩ một cách nghiêm túc về các biện pháp giảm thiểu cho tất cả chúng.
Họ nhấn mạnh sự cần thiết phải thấm nhuần độ bền bỉ vào văn hóa tổ chức và đảm bảo các quy trình liên tục duy trì nó.
Kết luận
S3 về cơ bản là một dịch vụ lưu trữ đa-tenant (multi-tenant) với quy mô khổng lồ. Nó là một hệ thống phân tán (distributed system) khổng lồ, bao gồm nhiều node riêng lẻ chậm chạp nhưng khi tổng hợp lại, cho phép bạn truy xuất lượng lớn dữ liệu một cách nhanh chóng.
Nhờ lợi thế về kinh tế theo quy mô (economies of scale), thiết kế của S3 đã biến những trường hợp sử dụng trước đây quá tốn kém trở nên phải chăng. Các workload "bùng nổ" (bursty workloads) lưu trữ lượng lớn dữ liệu, nằm im hàng tháng trời rồi đột ngột đọc tất cả trong một thời gian ngắn – ví dụ như trong genomics, machine learning và xe tự lái – đều có thể sử dụng S3 mà không cần phải trả toàn bộ chi phí cho tất cả các ổ đĩa mà họ sẽ cần nếu tự triển khai. Đây là một nghiên cứu điển hình thú vị về cách quy mô "mở khóa" hiệu quả chi phí và giúp việc quản lý trở nên dễ dàng hơn.
Tài liệu tham khảo
Bài viết này được tổng hợp từ nhiều nguồn tài liệu công khai mà AWS đã chia sẻ về S3. Dưới đây là danh sách ngắn gọn nếu bạn muốn tìm hiểu thêm: