Đổi mới liên tục: Lược sử ngắn gọn về block storage của AWS
(allthingsdistributed.com)- AWS EBS khởi đầu là block storage gắn qua mạng cho EC2, rồi phát triển từ một dịch vụ dùng chung HDD thành một fleet SSD phân tán xử lý hơn 140 nghìn tỷ thao tác mỗi ngày
- Các giới hạn hiệu năng ban đầu không chỉ đến từ mức 120~150 IOPS và độ trễ trung bình 6~8ms của HDD, mà còn từ vấn đề noisy neighbor phát sinh khi nhiều workload của khách hàng cùng chia sẻ một đĩa
- Sau khi áp dụng SSD, volume Provisioned IOPS vào năm 2012 cung cấp tối đa 1.000 IOPS và độ trễ trung bình khoảng 2~3ms, nhưng các nút thắt chuyển sang mạng, hypervisor và hàng đợi phần mềm
- Nhóm EBS đã đo đạc toàn bộ đường đi của IO và cải tiến theo từng lớp, từ queue của Xen, offload Nitro, xử lý mã hóa bằng phần cứng, tinh chỉnh TCP cho đến giao thức truyền tải SRD
- Việc tăng hiệu năng được thực hiện không phải bằng các đợt viết lại quy mô lớn mà bằng cải tiến từng bước có thể rollback, migration không gián đoạn, thay đổi độc lập từ các nhóm nhỏ và đo lường liên tục
Từ block storage cho EC2 đến một fleet SSD quy mô lớn
- EBS ra mắt ngày 20/8/2008, khoảng 2 năm sau khi EC2 beta ra mắt, từ ý tưởng cung cấp block storage gắn qua mạng cho các instance EC2
- Khi đó, đội ngũ chỉ có một hai chuyên gia storage cùng vài kỹ sư hệ thống phân tán, và bắt đầu xây dựng dịch vụ dựa trên hiểu biết về hệ thống máy tính và mạng
- Sau đó EBS chuyển từ một sản phẩm HDD dùng chung thành dịch vụ có thể cung cấp hàng trăm nghìn IOPS cho một instance EC2 duy nhất
- Hiện nay số IOPS có thể cung cấp cho một instance còn lớn hơn mức mà cả một Availability Zone nhận được trong thời HDD ban đầu
- Toàn bộ EBS xử lý hơn 140 nghìn tỷ thao tác mỗi ngày trên một fleet SSD phân tán
- Workload chính là đĩa hệ thống của các instance EC2, gần giống như cung cấp vai trò của ổ cứng trong máy chủ vật lý dưới dạng network storage
- Khách hàng coi trọng độ bền dữ liệu, nhưng hiệu năng và tính sẵn sàng gắn trực tiếp với trải nghiệm EC2 cũng quan trọng ở mức tương đương
- volume io2 Block Express và snapshot volume là những thành phần nền tảng để đạt độ bền cao
- Hiệu năng và tính sẵn sàng của volume EBS gần như chuyển nguyên vẹn thành trải nghiệm của ứng dụng chạy trên EC2
Những giới hạn ban đầu do queue và HDD tạo ra
- Trong hệ thống máy tính, các yêu cầu storage được xử lý qua nhiều queue giữa CPU, bus và thiết bị
- Với network storage, nhiều queue xuất hiện giữa kernel hệ điều hành, adapter storage, storage fabric, adapter storage đích và môi trường lưu trữ
- Khi EBS mới được tạo ra năm 2008, thị trường storage chủ yếu vẫn là HDD, và độ trễ bị chi phối chủ yếu bởi chính môi trường lưu trữ
- Ổ cứng là thiết bị cơ khí nên có giới hạn vật lý
- Trong nhiều thập kỷ, hiệu năng HDD gần như dừng ở khoảng 120~150 thao tác mỗi giây, với độ trễ IO trung bình 6~8ms
- Do queue và việc sắp xếp lại lệnh bên trong ổ đĩa, tail latency có thể tăng lên tới hàng trăm ms
- Khi đó độ trễ end-to-end của EBS ở mức hàng chục ms, nên vài chục micro giây thêm từ mạng chỉ chiếm tỷ trọng nhỏ trong tổng độ trễ
- Hiệu năng HDD bị ảnh hưởng mạnh bởi các thao tác khác đang nằm trong queue
- Các request random nhỏ nằm rải rác trên môi trường lưu trữ mất nhiều thời gian tìm kiếm và truy cập hơn vài request lớn ở gần nhau
- Phân tán khách hàng qua nhiều đĩa giúp giảm độ trễ đỉnh của workload nóng nhất, nhưng lại làm hành vi thất thường lan sang nhiều khách hàng hơn
- Noisy neighbor trở thành một vấn đề kinh doanh quan trọng khi một workload ảnh hưởng tới workload khác
- AWS cho rằng cần có cơ chế cô lập hiệu năng mạnh để nâng cao chất lượng trải nghiệm khách hàng
- Việc thay đổi thuật toán scheduling đĩa và phân tán workload ra nhiều spindle hơn chỉ mang lại cải tiến nhỏ từng bước
Tầm quan trọng của đo đạc hiện ra sau khi đưa SSD vào
- Khoảng năm 2011, SSD trở nên phổ biến hơn và bắt đầu có mức dung lượng đủ để AWS cân nhắc
- SSD không cần chuyển động cơ học để tìm dữ liệu, xử lý request random gần nhanh như request tuần tự, và có nhiều kênh giữa controller và chip NAND
- EBS trước tiên tạo ra loại storage server mới dựa trên SSD cùng một loại volume mới là Provisioned IOPS
- Việc ra mắt loại volume mới không phải là công việc nhỏ, và số workload có thể tận dụng nó cũng còn hạn chế
- Trái với kỳ vọng rằng chỉ cần thay HDD bằng SSD thì gần như mọi vấn đề sẽ biến mất, vấn đề noisy neighbor không tự động được giải quyết
- Provisioned IOPS ra mắt tháng 8/2012 cung cấp tối đa 1.000 IOPS
- Cao gấp 10 lần so với volume EBS standard trước đó
- Độ trễ trung bình khoảng 2~3ms, cải thiện 5~10 lần
- Khả năng kiểm soát outlier cũng tốt hơn rõ rệt
- Ở thời điểm này EBS mới chỉ có telemetry cơ bản, và cần đo đạc dày hơn để quyết định phải sửa gì
- Nhóm đã xây dựng cách theo dõi mọi IO tại nhiều điểm khác nhau
- initiator của client EBS
- network stack
- durability engine của storage
- hệ điều hành
- Ngoài việc theo dõi workload của khách hàng, họ còn tạo canary test để liên tục kiểm tra tác động tích cực và tiêu cực của các thay đổi trên những workload đã biết rõ
Các cải tiến được chia nhỏ đồng thời ở cả phần cứng và phần mềm
- Telemetry mới cho thấy rõ các khu vực cần đầu tư trước
- Cần giảm số lượng queue trong toàn hệ thống
- Có dư địa để giảm độ phức tạp đường đi IO của Xen hypervisor đang dùng trong EC2
- Cần tối ưu phần mềm mạng
- Durability engine cốt lõi cần bố trí dữ liệu on-disk hiệu quả hơn, tối ưu cache line và chấp nhận mô hình lập trình bất đồng bộ
- Các vấn đề hiệu năng hệ thống ở AWS thường cắt ngang nhiều lớp của cả stack phần cứng lẫn phần mềm cùng lúc
- EBS vận hành song song đội storage server và đội client, đồng thời có sự tham gia của các kỹ sư hypervisor EC2 và nhóm hiệu năng mạng nội bộ AWS
- Tổ chức phát triển cũng được chia theo cách divide and conquer giống như một hệ thống phần mềm
- Đội phát triển storage server nguyên khối được tái tổ chức thành các nhóm nhỏ theo từng lĩnh vực như sao chép dữ liệu, độ bền dữ liệu, hydration snapshot
- Mỗi nhóm có thể lặp lại phát triển và đưa thay đổi vào một cách độc lập dựa trên kiểm thử nghiêm ngặt
- Bản thiết kế được tạo ra năm 2013 không giống hoàn toàn EBS ngày nay, nhưng đã định ra hướng đi
- Khi đó chưa ai dự đoán rằng một ngày nào đó Amazon sẽ tự làm SSD riêng và sở hữu stack công nghệ phù hợp với nhu cầu của EBS
Loại bỏ nút thắt từ Xen sang Nitro và SRD
- Cho đến cuối năm 2017, mọi instance EC2 vẫn chạy trên Xen hypervisor
- Trong đường đi thiết bị của Xen có ring queue để guest domain và privileged driver domain là dom0 chia sẻ thông tin, còn EBS client chạy như một kernel block device trong dom0
- Trước khi rời instance để đi ra host EC2, một request IO đi qua nhiều queue
- queue block device của instance
- Xen ring
- queue kernel block device của dom0
- queue mạng của EBS client
- Nhóm EBS đã viết nhiều loopback device để tách riêng ảnh hưởng của từng queue
- Dù độ trễ của driver thiết bị trong dom0 gần như không đáng kể, họ vẫn xác nhận được hiện tượng throughput hiệu dụng của toàn hệ thống giảm đi khi nhiều instance cùng phát sinh IO
- EC2 được phát hành với số queue block device mặc định và số entry mỗi queue theo mặc định của Xen
- Các giá trị mặc định này được đặt dựa trên phần cứng storage hạn chế trong môi trường phát triển Xen trước đây
- Số request IO outstanding bị giới hạn ở 64 cho toàn host, không phải theo từng thiết bị
- Năm 2013, AWS đang phát triển Nitro offload card đầu tiên dành riêng cho networking
- Xử lý mạng software-defined của VPC được chuyển từ kernel Xen dom0 sang một pipeline phần cứng chuyên dụng
- Data plane xử lý packet được tách khỏi hypervisor, nên không còn phải dùng chu kỳ CPU của instance khách hàng để xử lý lưu lượng mạng
- Cách tiếp cận tương tự cũng được áp dụng cho EBS storage
- Nhiều xử lý hơn được chuyển sang phần cứng để giảm các queue hệ điều hành trong hypervisor
- Các công việc dựa trên interrupt được offload, giảm thời gian hypervisor phải dùng để xử lý request
- Nitro card thứ hai còn có khả năng phần cứng để xử lý volume EBS mã hóa mà không ảnh hưởng hiệu năng
- Vật liệu khóa mã hóa cũng được tách khỏi hypervisor để bảo vệ dữ liệu khách hàng tốt hơn
- Sau khi chuyển EBS sang Nitro, nút thắt lại chuyển sang chính mạng
- AWS xem xét các tham số tinh chỉnh TCP hiện đại trong datacenter và các thuật toán kiểm soát nghẽn
- Có trường hợp chỉ cần thêm một độ trễ random nhỏ vào request của storage server là hiệu ứng smoothing của mạng giúp giảm cả độ trễ trung bình lẫn outlier
- Những tinh chỉnh này không duy trì lâu khi hiệu năng và quy mô hệ thống tiếp tục tăng, nên vẫn cần đo lường và giám sát liên tục để ngăn hồi quy
- Năm 2014, công việc dựa trên Scalable Reliable Datagram (SRD) bắt đầu với mục tiêu tìm cách tốt hơn TCP
- Bài báo liên quan là A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
- Các yêu cầu gồm cải thiện khả năng phục hồi khi lỗi, khả năng đi đường vòng và sự thuận tiện cho offload phần cứng
- Trong thiết kế SRD, hai quan sát là quan trọng nhất
- Có thể tập trung vào thiết kế mạng datacenter của AWS thay vì Internet nói chung
- Trong storage, có thể sắp xếp lại thứ tự thực thi của các request IO đang ở trên đường truyền
- Nhờ đó có thể tránh chi phí của cơ chế in-order delivery nghiêm ngặt của TCP, đồng thời gửi các request khác nhau qua nhiều đường mạng để thực thi khi tới nơi
- SRD không chỉ dùng cho storage mà còn cho networking
- Trong Elastic Network Adapter(ENA) Express, SRD cải thiện hiệu năng của TCP stack trong guest
- Nó tận dụng nhiều đường mạng và giảm overflow cũng như queue ở các thiết bị mạng trung gian để đạt mức sử dụng mạng cao hơn
SSD cache và migration không gián đoạn
- EBS không hài lòng với việc chỉ một phần volume và khách hàng nhận được hiệu năng tốt hơn, mà muốn mở rộng lợi ích của SSD rộng hơn
- Khi đó, hàng triệu volume khách hàng non-provisioned IOPS đang chạy trên hàng nghìn storage server
- Một số volume trong đó vẫn còn tồn tại đến nay
- Cách làm bỏ toàn bộ phần cứng cũ rồi thay mới hoàn toàn có chi phí rất lớn
- Trong chassis máy chủ vẫn còn khoảng trống, nhưng vị trí không cản luồng không khí làm mát chỉ nằm giữa mainboard và quạt
- SSD nhỏ và nhẹ, nhưng không thể để rung lắc trong chassis, và sau khi nhờ đến các nhà khoa học vật liệu cùng nhiều lần thử sai, nhóm đã tìm ra loại băng dán hook-and-loop công nghiệp chịu nhiệt
- Trong vài tháng của năm 2013, EBS đã lắp thủ công 1 SSD vào từng máy trong số hàng nghìn server
- Trong phần mềm, họ thêm một thay đổi nhỏ: stage các ghi mới vào SSD rồi trả về hoàn tất cho ứng dụng, sau đó flush bất đồng bộ xuống HDD chậm hơn
- Công việc này được thực hiện mà không làm gián đoạn khách hàng
- EBS ngay từ đầu đã được thiết kế để tính đến các sự kiện bảo trì không gián đoạn
- EBS có thể retarget volume sang storage server mới, rồi cập nhật hoặc dựng lại server trống
- Khả năng chuyển volume khách hàng sang storage server mới tiếp tục tỏ ra hữu ích nhiều lần về sau
- Nó được dùng khi giới thiệu các cấu trúc dữ liệu hiệu quả hơn cho định dạng on-disk
- Nó cũng được dùng khi thay phần cứng cũ bằng phần cứng mới
- Một số volume được tạo trong những tháng đầu EBS ra mắt năm 2008 vẫn còn hoạt động
- Các volume đó có thể đã đi qua hàng trăm server khác nhau và nhiều thế hệ phần cứng
- Việc cập nhật và tái dựng fleet được thực hiện mà không ảnh hưởng tới workload đó
Cách lãnh đạo phù hợp với việc mở rộng hiệu năng
- Quy mô của EBS khác với môi trường công ty nhỏ hay startup trước đây không chỉ ở công nghệ mà còn ở khía cạnh tổ chức
- Nếu một chuyên gia hệ thống phải tham gia mọi escalation, mọi lần review commit và mọi thay đổi thiết kế, người đó có thể trở thành nút thắt hiệu năng của tổ chức
- Để giải quyết điều này, AWS thử nghiệm không chỉ trong code mà cả trong cách cộng tác
- Một công cụ tiêu biểu là peer debugging
- Nhiều kỹ sư cùng nhìn vào code và terminal để lần theo vấn đề
- Họ tìm ra một trường hợp mà vị trí và cách đặt locking cho việc cập nhật critical data structure là nguyên nhân
- Thông thường vấn đề không lộ ra, nhưng thỉnh thoảng làm phản hồi request chậm đi, và việc sửa nó đã loại bỏ một nguyên nhân gây jitter
- Khi kỹ sư được trao quyền để thử nghiệm an toàn, đồng thời giảm bớt rào cản nhưng vẫn giữ guardrail, kết quả có thể tốt hơn
Cải tiến liên tục thay vì những lần viết lại lớn
- Việc cải tiến EBS không diễn ra bằng một thay đổi khổng lồ duy nhất, mà là chuỗi cải tiến từng bước kéo dài theo thời gian
- Cách làm này giúp chuyển giá trị đến khách hàng nhanh hơn, đồng thời cho phép điều chỉnh hướng đi theo những gì học được khi workload khách hàng thay đổi
- Trải nghiệm độ trễ của EBS đã cải thiện từ mức trung bình hơn 10ms cho mỗi IO xuống mức sub-millisecond IO ổn định của volume io2 Block Express hiệu năng cao nhất
- AWS đạt được thay đổi này mà không phải đưa dịch vụ offline để triển khai kiến trúc mới
- Khách hàng vẫn tiếp tục muốn hiệu năng cao hơn nữa, và chính nhu cầu đó là động lực thúc đẩy đổi mới và lặp lại liên tục của EBS
1 bình luận
Ý kiến trên Hacker News
Thật vui khi thấy bài viết này ở đây. Nếu bạn có chút quan tâm nào đến hệ thống quy mô lớn, đây là bài rất đáng đọc
Với các workload tuần tự, ổ đĩa từ hiện đại có thể đạt tốc độ đọc/ghi trên 100MB/s, nhưng với workload 4kB hoàn toàn ngẫu nhiên, tốc độ có thể rơi xuống còn 400kB/s. Dù hàng đợi và lập lịch giúp tránh tình huống tệ nhất, hiệu năng thực tế vẫn có thể chênh nhau hơn 100 lần tùy workload, khiến hệ thống multi-tenant rất khó xử lý. Đặc biệt với thao tác đọc thì không có cách né kiểu “cứ ghi sang chỗ khác”
Điều lớn nhất tôi học được từ Marc là: muốn biết cái gì đang hỏng, trước hết phải nhìn cho đúng. Ông tạo ra các trực quan hóa độ trễ, chẳng hạn như chuỗi thời gian histogram trong bài, rồi dùng các trực quan hóa đó để kể câu chuyện, khiến đội nhìn nhận việc cần làm theo cách hoàn toàn khác. Mỗi đỉnh trong histogram đều có nguyên nhân và công việc tối ưu hóa riêng; việc đầu tư nhìn sâu vào dữ liệu hiệu năng theo nhiều cách sẽ mở ra những hiệu quả và cơ hội vốn không thể thấy được
Dự án retrofit năm 2013, trong đó gắn một SSD vào từng máy trong hàng nghìn máy chủ, là một trong những câu chuyện AWS tôi thích nhất. Điều này khả thi vì ngay từ đầu họ đã thiết kế để có thể chuyển hướng EBS volume sang storage server mới và cập nhật hoặc dựng lại máy chủ trống, với các sự kiện bảo trì không gián đoạn trong đầu. Đây là ví dụ hay cho thấy hệ thống phân tán không chỉ để mở rộng quy mô, mà còn giúp chịu lỗi máy chủ một cách tự nhiên và di chuyển dữ liệu mà không mất mát, từ đó vận hành được ở quy mô lớn
Dick Lyon của Google cũng dùng cách tiếp cận tương tự với các storage server của Google, và từ slide 62 của https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.... đã xác định nhiều hàng đợi và tranh chấp tài nguyên là các nút thắt chính của block storage
Gợi lại ký ức cũ. Reddit là một trong những người dùng EBS thời kỳ đầu vào năm 2008, và chúng tôi từng tự cho là mình thông minh khi phát hiện rằng tạo software RAID từ 5 EBS volume sẽ tăng IOPS
Khi đó hiệu năng của từng volume rất thất thường, nên chúng tôi khởi tạo 7–8 volume, chạy tải đọc/ghi, rồi chọn 5 volume có hiệu năng tốt nhất để ghép bằng Linux software RAID. Khi thuận lợi thì đúng là đạt hiệu quả mong muốn, đôi khi IOPS còn cao hơn 5 lần một node đơn; nhưng khi không ổn thì thật sự kinh khủng
Chúng tôi không biết rằng trong software RAID, nếu một node chậm thì toàn bộ RAID sẽ chạy theo tốc độ của volume chậm nhất, và kết quả là trông như cơ sở dữ liệu bị hỏng. Mất một thời gian mới xác định được nguyên nhân là RAID, và việc loại node xấu ra cũng khó. Vì software RAID không chịu thả volume chậm đó cho đến khi ghi xong vào nó
Chúng tôi phải thêm EBS volume mới và dựng lại array, nhưng việc này cũng tệ vì bị giới hạn bởi IOPS của volume mới. Sau đó chúng tôi ngừng dùng software RAID đó, và ở Netflix thì gần như không dùng EBS. Tôi kể với mọi người nghe về sai lầm đã mắc ở Reddit, còn Netflix thì trước khi tôi gia nhập đã chuẩn hóa theo hướng chỉ dùng ổ đĩa cục bộ
Một chuyện bên lề thú vị là khi sự cố EBS quy mô lớn của AWS xảy ra, tôi đang làm ở Reddit; trong lúc chờ EBS quay lại để sửa cơ sở dữ liệu, tôi xem Netflix. Khi phỏng vấn ở Netflix, tôi hỏi “Làm sao các anh vẫn sống sót trong sự cố EBS?”, họ trả lời “À, bọn tôi đơn giản là không dùng EBS”
Tôi thích đọc bài này
Điểm thú vị là trong giai đoạn được bài viết đề cập, tôi nhớ AWS đã gặp một sự cố kéo dài khoảng 4 ngày vì EBS, ảnh hưởng đến EC2, EBS và RDS. Sự cố này đã làm lung lay đáng kể niềm tin vào AWS
Kết quả là có tái cơ cấu tổ chức, và họ đầu tư sâu hơn nhiều vào EBS như một dịch vụ độc lập. Giai đoạn này cũng trùng với lúc Apple trở thành khách hàng, và cũng là thời điểm toàn bộ AWS tăng trưởng bùng nổ nhờ các startup như Netflix, Zynga, Dropbox bắt đầu sử dụng
Những câu chuyện kỹ thuật và vận hành như thế này rất thú vị, nhưng đổi mới công nghệ trong production thường lộn xộn và diễn ra trên nền các nhu cầu kinh doanh ngoài đời thực. Tôi mong được nghe thêm nhiều câu chuyện như vậy
Nhưng bánh xe lại quay và mọi thứ trở về phát triển tính năng. Tôi luôn nhớ năm đó là năm có ít escalation nhất trong thời gian tôi ở đó
Tôi tò mò về đoạn “thêm một lượng nhỏ độ trễ ngẫu nhiên vào các yêu cầu tới storage server lại làm giảm độ trễ trung bình và các ngoại lệ nhờ hiệu ứng làm phẳng mạng”. Ai có thể giải thích vì sao không?
Nếu quan tâm, có một bài nói chuyện [0] từ năm 2009 về cấu trúc nội bộ của Amazon S3. Bài này dựa trên tài liệu nội bộ của đội S3, và nhiều nội dung trong đó cũng ảnh hưởng đến cách phát triển EBS
[0]: https://vimeo.com/7330740
Tôi thích đoạn nói rằng vào năm 2013 họ đã thêm SSD thủ công vào tất cả thiết bị EBS. Nhìn ảnh thì trông khá giống Samsung SATA SSD
https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
Có thể trí nhớ của tôi sai, nhưng tôi nhớ việc lắp SSD vào các blade Dell để dùng đã có từ trước đó khá lâu. Khoảng 2010–2012, hiệu năng I/O thực sự là vấn đề rất lớn, và đó là giai đoạn chuyển từ ổ cứng đĩa quay sang bộ nhớ flash
Tôi vẫn nhớ những lần thử nghiệm với các thiết bị dựa trên flash thô, hoàn toàn không có xử lý lỗi hay wear leveling. Đúng là điên rồ, nhưng ai cũng rất cần mức tăng hiệu năng I/O khổng lồ khi chuyển từ đĩa quay sang silicon
Tốc độ của ổ đĩa tăng quá nhanh đến mức SKU đầu tiên đã lỗi thời chỉ sau 6 tháng. Tôi mừng là không phải trực tiếp giải thích với đội tài sản khi loại bỏ các rack đó sớm hơn kế hoạch vài năm. Đưa vào các mẫu mới hơn, dày đặc hơn và nhanh hơn khiến giá trị của vị trí rack cao hơn rất nhiều
Tôi nhớ lại thời trước khi có mã nguồn mở đủ dùng, khi chúng tôi xây dựng hạ tầng lưu trữ dạng dịch vụ. Từ Sun SAN, Fibre Channel và Solaris, chúng tôi chuyển sang GlusterFS chạy trên các máy chủ lưu trữ Supermicro dùng Linux và NFS, và trước khi tôi rời đi vào năm 2007 thì đã lên tới gần 2PB
Tôi cũng nhớ một thời mà việc lén phá rồi tạo lại mdraid bằng cách thay ổ đĩa quay bằng SSD khi máy chủ vẫn đang chạy đơn giản là hợp lý. Lý do là SATA có hỗ trợ hot-swap ổ đĩa ở một mức độ nào đó. Việc đổi từ ổ đĩa quay sang SSD đã làm IOPS của hệ thống quan trọng nhất trên nền tảng tăng 14 lần
Thời đầu sự nghiệp, tôi làm công việc bao quát toàn bộ hệ thống tại một công ty Internet có quy mô lớn về mặt kỹ thuật và vận hành, chứ không phải về số lượng nhân sự. Số bài học học được trong thời gian ngắn nhiều đến mức khó tin. Sau khi rời công ty đó, tôi nhận ra rằng hầu hết mọi người gần như không gặp những vấn đề như vậy trong suốt sự nghiệp, nên cũng không học được các bài học đó
Vì vậy tôi nghĩ nên có một chế độ chứng nhận chuyên môn. Nếu yêu cầu học việc dưới một kỹ sư giàu kinh nghiệm, người ta có thể tiếp thu trong thời gian ngắn những kiến thức và kỹ năng rất giá trị chỉ có thể học qua trải nghiệm, rồi sau đó làm việc hiệu quả hơn nhiều. Với người phỏng vấn ứng viên, bằng chứng về kinh nghiệm và lời giới thiệu từ mentor cũng sẽ rất có giá trị
Tôi thích câu này
“Lý tưởng về kỹ sư full-stack được ca ngợi rộng rãi cũng có giá trị, nhưng trong các hệ thống sâu và phức tạp, nhiều khi việc xây dựng một nhóm chuyên gia có thể cộng tác và làm việc sáng tạo xuyên suốt toàn bộ stack cũng như các lĩnh vực chuyên môn sâu của từng người còn có giá trị hơn”
Sơ đồ đầu tiên trong bài viết không chính xác hoặc đã khá cũ. Trên máy tính hiện đại, phần lớn PCIe lane được kết nối trực tiếp tới I/O hub hoặc vùng Uncore của CPU, thay vì đi qua PCH riêng như trước đây
Đây là một bước tiến quan trọng cả về thông lượng I/O lẫn độ trễ. Ngoài điểm đó ra thì đây là một bài viết rất hay, và cho thấy rõ rằng rốt cuộc ở đâu cũng là hàng đợi
Tôi sẽ làm rõ trong chú thích ảnh rằng đó là cấu trúc của thời kỳ đó