Đổi mới liên tục: Lược sử ngắn về block storage của AWS

 (allthingsdistributed.com)
2 điểm bởi GN⁺ 2024-08-23 | 1 bình luận | Chia sẻ qua WhatsApp

Đổi mới liên tục: Lược sử ngắn về block storage của AWS

  • Giới thiệu

    • Marc Olson đã làm việc trong nhóm Elastic Block Store (EBS) hơn 10 năm.
    • EBS đã phát triển từ một dịch vụ block storage đơn giản thành một hệ thống lưu trữ mạng quy mô lớn xử lý hơn 140 nghìn tỷ thao tác mỗi ngày.
    • Bài viết này chia sẻ quá trình tiến hóa của EBS và những bài học quan trọng.

  • Lịch sử ban đầu của EBS

    • EBS được ra mắt vào ngày 20 tháng 8 năm 2008, bắt đầu từ một ý tưởng đơn giản là cung cấp block storage kết nối qua mạng cho các EC2 instance.
    • Ban đầu hệ thống sử dụng ổ đĩa cứng dùng chung (HDD), còn hiện nay có thể cung cấp hàng trăm nghìn IOPS cho một EC2 instance duy nhất.
    • Hiện tại, EBS xử lý hơn 140 nghìn tỷ thao tác mỗi ngày thông qua một fleet SSD phân tán.

  • Lý thuyết hàng đợi

    • Cách các hệ thống máy tính tương tác với lưu trữ về cơ bản không thay đổi.
    • CPU đưa yêu cầu vào hàng đợi, còn thiết bị lưu trữ lấy dữ liệu từ bộ nhớ CPU và ghi lên môi trường lưu trữ bền vững, hoặc làm ngược lại là truyền dữ liệu về bộ nhớ CPU.
    • Lý thuyết hàng đợi đóng vai trò quan trọng trong việc hiểu quy trình này.

  • Chuyển đổi từ HDD sang SSD

    • EBS ban đầu sử dụng HDD, nên hiệu năng bị giới hạn bởi các ràng buộc vật lý.
    • Khi SSD xuất hiện, ngay cả các yêu cầu ngẫu nhiên cũng có thể được xử lý gần như nhanh bằng các yêu cầu tuần tự.
    • Năm 2012, AWS đã ra mắt một loại storage server mới dùng SSD cùng với một loại volume EBS mới là Provisioned IOPS.

  • Đo lường và quản lý

    • Vào năm 2012, EBS chỉ có telemetry ở mức cơ bản.
    • Để cải thiện hiệu năng hệ thống, trước tiên cần xác định vấn đề nằm ở đâu rồi giải quyết chúng theo thứ tự ưu tiên.
    • Nhóm đã xây dựng cách đo IO trên nhiều hệ thống con và phát hiện thay đổi thông qua giám sát liên tục.

  • Chia nhỏ tổ chức để chinh phục vấn đề

    • Nhóm storage server của EBS được tái cấu trúc thành các nhóm nhỏ tập trung vào những lĩnh vực cụ thể như sao chép dữ liệu, độ bền dữ liệu, và snapshot hydration.
    • Mỗi nhóm có thể lặp lại thay đổi và commit một cách độc lập.

  • Thách thức các giả định

    • Nhóm phát hiện cấu hình mặc định của hypervisor Xen đang giới hạn hiệu năng.
    • Họ sử dụng thẻ offload Nitro để chuyển các tác vụ xử lý mạng và lưu trữ sang phần cứng.

  • Thử nghiệm tinh chỉnh mạng

    • Khi chuyển EBS sang Nitro, overhead của chính mạng lại tăng lên.
    • Để cải thiện hiệu năng mạng, AWS đã phát triển giao thức SRD (Scalable Relatable Diagram) thay cho TCP.

  • Ràng buộc thúc đẩy đổi mới

    • Để mang lợi ích của SSD đến cho mọi khách hàng, AWS đã bổ sung SSD mà không cần thay thế phần cứng hiện có.
    • SSD được gắn thủ công vào server, các lượt ghi mới sẽ được lưu trên SSD rồi sau đó được flush bất đồng bộ xuống HDD.

  • Nhìn lại quá trình mở rộng hiệu năng

    • Câu chuyện trưởng thành cá nhân: chuyển từ văn hóa công ty nhỏ sang một tổ chức quy mô lớn.
    • Thông qua các phiên debug cùng đồng nghiệp, họ giải quyết vấn đề và nâng cao hiệu quả của đội ngũ.

  • Kết luận

    • EBS đã phát triển không phải nhờ một thay đổi lớn duy nhất, mà thông qua một chuỗi cải tiến dần dần.
    • Nhu cầu của khách hàng sẽ tiếp tục tăng, và đó là động lực để tiếp tục đổi mới và lặp lại.

# Tóm tắt của GN⁺

  • Bài viết mang đến góc nhìn từ người trong cuộc về cách EBS của AWS đã tiến hóa.
  • Bài viết đề cập đến nhiều thách thức kỹ thuật và cách giải quyết như lý thuyết hàng đợi, áp dụng SSD và tinh chỉnh mạng.
  • Bài viết nhấn mạnh tầm quan trọng của việc đo lường và quản lý liên tục để cải thiện hiệu năng.
  • Những sản phẩm có chức năng tương tự gồm có Google Cloud Persistent Disk và Microsoft Azure Disk Storage.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-08-23
Ý kiến trên Hacker News

  • Nếu quan tâm đến các hệ thống lớn thì nên đọc bài này

    • Hiệu năng ổ cứng phụ thuộc vào các giao dịch khác đang ở trong hàng đợi
    • Với các tác vụ 4kB ngẫu nhiên, hiệu năng có thể giảm mạnh
    • Hàng đợi và lập lịch có ích, nhưng hiệu năng thực tế có thể chênh lệch hơn 100 lần tùy theo khối lượng công việc
    • Trong hệ thống đa tenant, đặc biệt là với tác vụ đọc, có nhiều khó khăn

  • Để giải quyết vấn đề thì phải biết điều gì đang sai

    • Bài học lớn nhất học được từ Marc là thay đổi góc nhìn của cả nhóm thông qua trực quan hóa
    • Phân tích dữ liệu hiệu năng theo nhiều cách có thể phát hiện ra những hiệu quả và cơ hội vốn không nhìn thấy được

  • Dự án lắp SSD vào máy chủ EBS năm 2013 là một trong những câu chuyện thú vị của AWS

    • Hệ thống được thiết kế ngay từ đầu với các sự kiện bảo trì không phá hủy trong đầu
    • Khi xây dựng hệ thống phân tán, có thể vận hành ở quy mô lớn

  • Sự cố kéo dài khoảng 4 ngày của AWS là do EBS gây ra, và điều này đã làm lung lay niềm tin vào AWS

    • Vì vậy, đầu tư vào EBS đã tăng lên
    • Thời điểm đó cũng trùng với lúc Apple trở thành khách hàng

  • Reddit là một trong những người dùng EBS đầu tiên vào năm 2008

    • Họ cố tăng IOPS bằng cách dùng software RAID, nhưng hiệu năng không ổn định
    • Mất khá nhiều thời gian để giải quyết các vấn đề của RAID
    • Netflix không dùng EBS

  • Việc thêm độ trễ ngẫu nhiên có tác dụng làm giảm độ trễ trung bình và cả các giá trị ngoại lệ

  • Làm việc tại các công ty Internet quy mô lớn mang lại nhiều bài học

    • Thông qua quá trình học việc, có thể nhanh chóng tiếp thu kiến thức và kỹ năng quan trọng
    • Khi phỏng vấn, kinh nghiệm và sự giới thiệu từ mentor rất hữu ích

  • Phần nói về việc tự tay lắp SSD vào mọi thiết bị EBS năm 2013 rất thú vị

    • Trong giai đoạn 2010-2012, hiệu năng I/O là một vấn đề rất quan trọng

  • Năm 2009, đã có một bài thuyết trình về nội bộ của Amazon S3

    • Bài thuyết trình này đã ảnh hưởng đến quá trình phát triển EBS

  • Ở giai đoạn đầu của cloud, người ta dùng phần cứng đa dụng, nhưng giờ đây dùng phần cứng chuyên biệt cho từng dịch vụ

    • AWS dùng các chip Graviton, Inferentia, Tranium
    • Google dùng TPU và thẻ bảo mật Titan
    • Azure dùng FPGA và Sphere

  • Sơ đồ đầu tiên bị sai hoặc đã lỗi thời

    • Máy tính hiện đại hiện nay phần lớn có các lane PCIe nối trực tiếp vào CPU
    • Đây là một bước tiến quan trọng đối với thông lượng I/O và độ trễ

  • Đang tìm cách tốt nhất để cung cấp một thư mục dataset 256GB nhanh cho các EC2 instance mới

    • Đang dùng EBS volume nhưng việc cập nhật khá phiền phức
    • EFS quá chậm
    • SSD instance storage chỉ mang tính tạm thời
    • Vẫn chưa thử FSx Lustre