Lời khuyên cho người mới bắt đầu với hệ thống phân tán
(somethingsimilar.com)- Khó khăn cốt lõi của hệ thống phân tán không phải là độ trễ mà là lỗi cục bộ; ngay cả xử lý ngoại lệ đơn giản trên một máy cũng trở thành một phần của thiết kế giao thức khi có nhiều máy
- Hệ thống phân tán vững chắc có những lỗi chỉ lộ ra trên nhiều máy thật, trong điều kiện mạng trung tâm dữ liệu và với tập dữ liệu lớn, nên tốn kém hơn hệ thống một máy
- Để xây dựng hệ thống có thể vận hành, cần giảm phối hợp và tăng tính độc lập, đồng thời coi backpressure, tính sẵn sàng cục bộ, metric và chỉ số percentile là công cụ cơ bản
- Feature flag, thiết kế không gian ID, tính cục bộ của dữ liệu và tách dịch vụ là các kỹ thuật thực tiễn giúp giảm phạm vi lỗi và chi phí phối hợp trong quá trình migration và mở rộng
- Định lý CAP gần với một công cụ phê bình thiết kế hơn là điểm khởi đầu để xây dựng hệ thống; trong hệ thống phân tán, phối hợp xã hội giữa các nhóm và tổ chức cũng khó không kém các vấn đề kỹ thuật
Những điều dễ bỏ sót khi lần đầu học hệ thống phân tán
- Nhiều bài học của kỹ sư hệ thống phân tán đến từ những sai lầm gặp phải dưới traffic production và vết sẹo vận hành, nhưng kỹ sư mới vào nghề cần bối cảnh trực tiếp và khả thi hơn
- Fallacies of Distributed Computing và CAP theorem hữu ích cho việc tự học, nhưng vẫn khá trừu tượng để một kỹ sư ít kinh nghiệm có thể bắt tay ngay vào làm
- Hệ thống phân tán cần nhiều máy móc và vốn hơn, nên dễ kéo theo nhiều đội hơn và các tổ chức lớn hơn
- Vấn đề xã hội nói chung là phần khó nhất trong công việc của nhà phát triển phần mềm, và có thể đặc biệt nổi bật trong phát triển hệ thống phân tán
- Đôi khi giải pháp xã hội hiệu quả và thỏa mãn hơn giải pháp kỹ thuật, nhưng nền tảng, giáo dục và kinh nghiệm thường khiến kỹ sư nghiêng về giải pháp kỹ thuật
Thiết kế với giả định có lỗi và chi phí
- Hệ thống phân tán thường xuyên lỗi, và tệ hơn là lỗi cục bộ
- Một lỗi unlock mutex trong một tiến trình đơn có thể được xử lý bằng cách cho tiến trình crash, nhưng lỗi unlock của mutex phân tán phải được đưa vào trong chính giao thức lock
- Cách tiếp cận như “chỉ cần gửi write tới cả hai máy” hoặc “cứ retry cho đến khi thành công” không xử lý đầy đủ tình huống chỉ một bên write thành công còn bên kia thất bại
- Có thể xảy ra lỗi switch, leader biến mất do GC pause, socket write trông như thành công nhưng phía remote lại thất bại, hoặc một đĩa chậm làm chậm toàn bộ giao thức giao tiếp của cluster
- Một giải pháp phân tán vững chắc tốn nhiều chi phí hơn giải pháp một máy
- Có những lỗi chỉ xảy ra trên nhiều máy; VM và cloud làm giảm chi phí, nhưng vẫn không rẻ bằng việc thiết kế, triển khai và kiểm thử trên một máy tính sẵn có
- Những lỗi chỉ lộ ra với kích thước dataset khó đặt trên một máy dùng chung, hoặc trong điều kiện mạng trung tâm dữ liệu, cần môi trường phân tán thật
- Simulation hữu ích, nhưng không thể thay thế toàn bộ lỗi của hệ thống phân tán
- Hệ thống phân tán mã nguồn mở vững chắc hiếm hơn rất nhiều so với hệ thống một máy vững chắc
- Chi phí chạy nhiều máy trong thời gian dài là gánh nặng cho cộng đồng mã nguồn mở
- Developer làm vì sở thích và dilettante thường tạo mã nguồn mở bằng máy sẵn có và thời gian rảnh, nên rất khó tìm được developer sẵn sàng khởi chạy, duy trì nhiều máy và trả chi phí cho chúng
- Kỹ sư trong doanh nghiệp có thể lấp một phần khoảng trống, nhưng ưu tiên của tổ chức đó có thể không khớp với ưu tiên của tổ chức người dùng
Giảm phối hợp và hấp thụ sự cố
- Nên tránh phối hợp giữa các máy nhiều nhất có thể
- Trọng tâm của khả năng mở rộng ngang là bố trí dữ liệu đủ độc lập để các máy có thể giảm thiểu việc giao tiếp và đạt đồng thuận với nhau
- Mỗi khi hai máy phải đồng ý về một điều gì đó, việc triển khai service lại khó hơn
- Tốc độ truyền thông tin có giới hạn trên, truyền thông mạng kém ổn định hơn ta nghĩ, và trực giác về đồng thuận có thể sai
- Việc hiểu Two Generals, Byzantine Generals và độ khó khi triển khai Paxos sẽ hữu ích
- Nếu vấn đề nằm gọn trong bộ nhớ, với kỹ sư hệ thống phân tán thì nhìn chung nó gần như là vấn đề nhỏ
- Khi dữ liệu nằm bên kia vài switch thay vì chỉ qua vài con trỏ, xử lý nhanh trở nên khó hơn
- Thuật toán và triển khai cho một máy rất phong phú, nhưng tài liệu và triển khai dành cho hệ thống phân tán ít hơn nhiều
- “Chậm” là vấn đề khó debug nhất
- Một hoặc nhiều hệ thống tham gia vào request của người dùng có thể chậm, hoặc một phần của pipeline biến đổi đi qua nhiều máy có thể chậm
- Bản thân mô tả vấn đề gần như không đưa ra manh mối về vị trí lỗi, và có thể có lỗi cục bộ ẩn ở phần không hiện trên các biểu đồ thường xem
- Trước khi suy giảm hiệu năng trở nên rất rõ ràng, thường khó được cấp đủ tài nguyên như thời gian, tiền bạc và công cụ
- Dapper và Zipkin được tạo ra vì lý do này
- Cần triển khai backpressure trên toàn hệ thống
- Backpressure là cách hệ thống phục vụ báo hiệu lỗi cho hệ thống gửi request, và hệ thống gửi request xử lý lỗi đó để ngăn quá tải cho chính nó và hệ thống bên kia
- Giới hạn việc sử dụng tài nguyên trong lúc quá tải hoặc lỗi hệ thống là một thành phần cơ bản của hệ thống phân tán vững chắc
- Cách triển khai thường là bỏ message mới khi tài nguyên bị giới hạn hoặc có lỗi, hoặc trả lỗi cho người dùng; trong cả hai trường hợp đều cần tăng metric
- Timeout và exponential backoff là bắt buộc cho các kết nối và request tới hệ thống khác
- Nếu không có backpressure, rất dễ xảy ra lỗi dây chuyền hoặc mất message ngoài ý muốn
- Cần tìm cách cung cấp tính sẵn sàng cục bộ
- Tính sẵn sàng cục bộ là khả năng trả về một phần kết quả ngay cả khi một phần hệ thống thất bại
- Hệ thống tìm kiếm đánh đổi giữa chất lượng kết quả và thời gian bắt người dùng chờ; khi quá thời hạn, có thể chỉ trả về những kết quả đã thu thập được
- Trong private messaging, việc chỉ một số người dùng gặp sự cố có thể tốt hơn việc một số message biến mất với mọi người dùng
- Cần quyết định tách failure domain đến mức nào để sự cố private messaging không ảnh hưởng tới các chức năng không liên quan như upload ảnh công khai
Biến quan sát, dung lượng và triển khai thành công cụ vận hành
- Metric là phương tiện thiết yếu để biết hệ thống thực sự làm gì trong production
- Các metric như percentile độ trễ, bộ đếm tăng cho một hành vi cụ thể và tốc độ thay đổi giúp thu hẹp khoảng cách giữa hành vi hệ thống mà ta tin là có và hành vi thực tế
- Biết hành vi hệ thống ở ngày thứ 20 khác ngày thứ 15 như thế nào là điều phân biệt engineering thành công với tà thuật thất bại
- Metric cần thiết để hiểu vấn đề và hành vi, nhưng không đủ để cho biết tiếp theo nên làm gì
- Log file hữu ích nhưng dễ nói dối
- Một vài lớp lỗi có thể chiếm phần lớn dung lượng file log, nhưng tỷ lệ request thực tế lại thấp
- Log thành công phần lớn là trùng lặp và có thể làm đầy đĩa; kỹ sư thường đoán sai log lỗi nào là hữu ích
- Nên ghi log với giả định người đọc chưa từng xem code
- Nếu đánh giá quá cao một điểm bất thường thấy trong log mà không xác nhận bằng metric, sự cố có thể kéo dài hơn
- Nên dùng percentile thay vì trung bình
- Percentile 50th, 99th, 99.9th, 99.99th chính xác và hữu ích hơn trung bình trong hầu hết hệ thống phân tán
- Trung bình giả định rằng chỉ số đánh giá tuân theo phân bố hình chuông, nhưng rất ít chỉ số mà kỹ sư quan tâm rơi vào trường hợp đó
- Nếu độ trễ hệ thống phân tán không tuân theo phân bố hình chuông, độ trễ trung bình sẽ dẫn đến quyết định và hiểu biết sai
- Cần học khả năng ước lượng dung lượng
- Biết cần bao nhiêu máy cho một công việc là điều phân biệt hệ thống bền lâu với hệ thống phải thay thế sau 3 tháng
- Cần các phép tính xấp xỉ kiểu: tính đến cuối năm 2012, một máy thông thường có 24GB bộ nhớ, OS cần 4–5GB, xử lý request cần tối thiểu vài GB, tweet id là 8 byte
- Numbers Everyone Should Know của Jeff Dean hữu ích để đặt kỳ vọng
- Feature flag là cách rollout hạ tầng
- Feature flag không chỉ dùng mạnh cho A/B test frontend, mà còn cho việc thay thế hạ tầng
- Cách “big cutover” đã khiến nhiều dự án thất bại vì bị buộc rollback do bug phát hiện muộn
- Khi chuyển từ một database đơn sang một service che giấu storage mới, có thể tăng từ từ việc gửi write song song tới service mới, sau khi backfill xong thì thử read mà chưa dùng cho phản hồi người dùng, so sánh read giữa hệ thống cũ và mới, rồi tăng dần read thật
- Nếu có vấn đề, có thể lập tức hạ giá trị flag hoặc đưa về 0, đồng thời điều chỉnh lượng traffic để debug và thử nghiệm
- Feature flag là sự đánh đổi, đổi độ phức tạp cục bộ trong code lấy sự đơn giản và khả năng phục hồi toàn cục
- Cần chấp nhận thực tế rằng nhiều phiên bản hạ tầng và dữ liệu là điều bình thường chứ không phải ngoại lệ
Thiết kế mô hình dữ liệu và ranh giới
- Không gian ID quyết định hình dạng của hệ thống
- Càng cần nhiều ID để truy cập một dữ liệu, càng có nhiều lựa chọn để partition dữ liệu đó
- Càng cần ít ID cho một dữ liệu, output của hệ thống càng dễ được tiêu thụ
- Twitter API v1 tra cứu, tạo và xóa tweet bằng một ID số 64-bit duy nhất, và ID này không gắn với dữ liệu khác
- Khi số lượng tweet tăng, có thể lưu tweet của cùng một người dùng trên cùng một máy để xây dựng user tweet timeline và subscription timeline hiệu quả, nhưng vì public API cho phép định địa chỉ mọi tweet chỉ bằng tweet id, nên cần một service tra cứu để biết user nào sở hữu tweet id nào
- Một phương án khác là yêu cầu user id khi tra cứu tweet, hoặc đưa user id vào chính tweet id, nhưng phương án sau có chi phí là tweet id không còn là numeric k-sortable nữa
- Cấu trúc ID có thể ảnh hưởng đến việc khử ẩn danh dữ liệu riêng tư, crawling ngoài dự kiến, vấn đề ID tự tăng và các kiểu tấn công như Insecure Direct Object References
- Cần tận dụng tính cục bộ của dữ liệu
- Đặt xử lý dữ liệu và caching càng gần persistent storage thì hiệu quả xử lý càng cao và càng dễ duy trì tính nhất quán cũng như tốc độ của cache
- Mạng có nhiều lỗi và độ trễ hơn dereference con trỏ hay
fread(3) - Tính cục bộ áp dụng không chỉ cho không gian mà cả thời gian
- Nếu nhiều người dùng gần như đồng thời thực hiện cùng một request đắt đỏ, có thể gộp chúng thành một; nếu các request cho cùng loại dữ liệu xảy ra gần nhau về thời gian, có thể gom thành một request lớn hơn
- Cách này giảm overhead giao tiếp và giúp quản lý lỗi dễ hơn
- Ghi lại dữ liệu đã cache vào persistent storage là điều không tốt
- Lỗi này có thể xuất hiện đặc biệt trong những hệ thống do người ít kinh nghiệm về hệ thống phân tán thiết kế lần đầu
- Trong các triển khai nói về “Russian-doll caching”, khả năng gặp bug dễ thấy là rất cao
- Triệu chứng phổ biến là thông tin người dùng, ví dụ screenname, email, hashed password, bị quay về giá trị cũ
- Máy tính có thể làm nhiều việc hơn bạn nghĩ
- Ngay cả một web server nhẹ vào cuối năm 2012 cũng có hơn 6 processor, 24GB bộ nhớ và dung lượng đĩa rất lớn
- Ngay cả ứng dụng CRUD tương đối phức tạp trên runtime ngôn ngữ hiện đại cũng có thể xử lý hàng nghìn requests per second trên một máy trong vài trăm millisecond
- Trong phần lớn trường hợp, vài trăm requests per second trên mỗi máy không phải là con số đáng tự hào xét từ góc độ năng lực vận hành
- Nếu profile ứng dụng và tối ưu dựa trên đo lường, đạt hiệu năng cao hơn không phải là việc quá khó
- Nên dùng định lý CAP như công cụ phê bình thiết kế, không phải cách xây dựng hệ thống
- Định lý CAP quá tổng quát và không gian giải pháp khả dĩ quá rộng, nên không phù hợp để lấy làm nguyên lý đầu tiên nhằm suy ra một hệ thống hoạt động được
- Nếu liên tục xem xét các ràng buộc mà CAP áp lên các subsystem trong thiết kế hệ thống, ta có thể đạt được thiết kế tốt hơn
- Trong C, A, P, không thể chọn CA
- Tách dịch vụ đem lại lợi ích về đóng gói và triển khai
- Ở đây, service chỉ một hệ thống phân tán chứa logic ở mức cao hơn storage system và thường có API kiểu request-response
- Cần liên tục xem xét liệu một đoạn code cụ thể có dễ thay đổi hơn khi nằm trong một service riêng thay vì bên trong hệ thống hay không
- Service được tách ra cung cấp khả năng đóng gói như library, đồng thời có thể làm cho việc triển khai thay đổi nhanh và dễ hơn so với nâng cấp library trong hệ thống client
- Service nhỏ có ít phụ thuộc về code và vận hành hơn, còn ranh giới nghiêm ngặt làm giảm các lối tắt vốn được chấp nhận trong library
- Khi có nhiều hệ thống client, shared library đòi hỏi phối hợp triển khai từng client, và sẽ khó hơn nữa nếu hỏng dữ liệu có thể phát sinh tùy theo thứ tự triển khai
- Nếu người duy trì các hệ thống client khác nhau, chi phí phối hợp xã hội để đạt đồng thuận nâng cấp cũng tăng lên do ưu tiên không khớp
- Use case tiêu biểu là che giấu một storage layer đang thay đổi phía sau một service có API tiện hơn và bề mặt nhỏ hơn
1 bình luận
Các ý kiến trên Hacker News
Bài viết lẽ ra nhất định phải đề cập đến CALM (Consistency as Logical Monotonicity — tính nhất quán như tính đơn điệu logic). Nó dễ hiểu hơn CAP rất nhiều, là một kết quả nền tảng hơn, và giúp cả những người ít kinh nghiệm cũng có thể xây dựng các hệ thống phân tán rất vững chắc.
Tính lũy đẳng, CRDT, WAL, Raft đều là các trường hợp đặc biệt của nguyên lý CALM.
https://arxiv.org/pdf/1901.01930
Có một nguyên tắc chung tôi thích nhưng bị bỏ sót ở đây: truyền đúng một lần là bất khả thi.
Có thể truyền tối đa một lần hoặc tối thiểu một lần, nhưng bạn phải chọn kiểu lỗi nào mình chấp nhận và thiết kế theo đó.
Việc chuyển dữ liệu của một hàng sang hàng khác trong cơ sở dữ liệu cụm là có thể, và cũng có thể diễn giải đó là một thông điệp đã được truyền.
Nếu toàn bộ hệ thống có tính lũy đẳng, hoặc nếu có thể xem toàn bộ hệ thống phân tán là một đơn vị duy nhất có thể rollback cùng nhau, thì bạn có thể đạt được truyền đúng một lần. Tức là không được có tác dụng phụ lên các hệ thống khác ngoài miền đó.
Cả hai đều là một dạng tính đơn điệu logic. Tính lũy đẳng thì dễ nhận ra, còn tính giao dịch cũng dựa trên tính đơn điệu thông qua các thuật toán như WAL và Raft.
Bài viết lẽ ra nên đề cập đến CALM (Consistency as Logical Monotonicity — tính nhất quán như tính đơn điệu logic). Nó dễ hiểu hơn CAP rất nhiều và là một kết quả nền tảng hơn.
https://arxiv.org/pdf/1901.01930
An Overview of End-to-End Exactly-Once Processing in Apache Flink (with Apache Kafka, too!) — https://flink.apache.org/2018/02/28/an-overview-of-end-to-en...
Flink's Fault Tolerance Guarantees — https://nightlies.apache.org/flink/flink-docs-release-1.20/d...
Như một hệ quả của câu “nếu bạn có thể đưa bài toán vào bộ nhớ thì có lẽ đó là bài toán tầm thường”, phạm vi có thể đưa vào bộ nhớ lớn hơn nhiều so với bạn nghĩ.
Tôi từng nghĩ mình biết RAM lớn là gì, nhưng đã đổi ý khi các cloud lớn bắt đầu cung cấp VM 12TB cho SAP HANA.
Bài viết cũng có nhắc rất ngắn gọn rằng “máy tính có thể làm được nhiều hơn bạn nghĩ”, nhưng ở đó chỉ nói về máy 24GB. Dù tính đến bối cảnh năm 2012, khi ấy chắc cũng đã có khá nhiều máy có RAM gấp 10 lần như vậy.
Tôi chia sẻ tài liệu này cho những người triển vọng nhất trong số những người tôi làm việc cùng.
Khi tôi làm ở Lookout, Jeff Hodges đã chia sẻ bài tiểu luận này dưới dạng một bài thuyết trình, và ở cuối có thêm hệ quả “đừng giả vờ rằng kỹ thuật không mang tính chính trị”.
Những người nghĩ rằng code tự nó lên tiếng đang bỏ lỡ một khía cạnh quan trọng trong việc ảnh hưởng đến cách thứ gì đó sẽ được xây dựng và đạt được kết quả thực tế.
10 năm sau, vẫn không có nhiều người hiểu ngắn gọn được giao điểm giữa lãnh đạo kỹ thuật và những năng lực nền tảng thường được xem là của SRE/DevOps như thế này.
Đây là các thảo luận trước đây.
https://news.ycombinator.com/item?id=5055371
346 points|jcdavis|12 years ago|42 comments
https://news.ycombinator.com/item?id=12245909
386 points|kiyanwang|8 years ago|133 comments
Danh sách rất hay, và tôi thích phần giải thích thực dụng, sát thực tế. Không có buzzword, cũng không có “microservices”.
Tôi cho rằng phần lớn lời khuyên này cũng áp dụng cho hệ thống một máy. Có thể có nhiều thành phần con ở mức độ nào đó là phân tán, như IPC giữa các chương trình hoặc việc phối hợp các luồng trong một tiến trình.
Khái niệm bộ nhớ hợp nhất trên một máy đơn ở một mức nào đó cũng là giả, dù phần cứng vẫn có thể cung cấp bảo đảm tốt hơn môi trường phân tán “thật”.
Nhiều lời khuyên trong bài khi so sánh “phân tán” với “một máy” cũng khá khớp với so sánh giữa đa luồng và đơn luồng.
Ở một trục khác, nếu bạn tạo chương trình rồi phân phối để nhiều người chạy, đó cũng trở thành một dạng tình huống “phân tán”. Vì ngoài thực tế sẽ có nhiều phiên bản khác nhau, và bạn phải quan tâm đến tương thích cũng như nâng cấp, nên các feature flag được nhắc trong bài cũng liên quan.
Tính phân tán giống một phổ hơn, kéo dài từ một CPU, nhiều CPU, nhiều máy tính kết nối chặt chẽ, cho đến nhiều máy tính phân tán toàn cầu; ở giữa còn có nhiều điểm và nhiều chiều khác nhau.
Nhiều tiến trình trên cùng một máy giao tiếp qua localhost cũng là một ví dụ rất nổi tiếng về hệ thống phân tán, và thực tế nhiều người lần đầu học về hệ thống phân tán từ đó.
Nếu vậy, tất cả chúng ta hẳn đã viết mọi code dưới dạng các chương trình MPI bộ nhớ phân tán đẹp đẽ. False sharing cũng biến mất, và chúng ta sẽ phải suy nghĩ rõ ràng, sâu sắc về các mẫu giao tiếp.
Vài năm gần đây tôi có cơ hội làm việc ngắn với tác giả bài viết này. Jeff là một trong những người sâu sắc và tích cực nhất mà tôi từng học hỏi.
Anh ấy thẳng thắn một cách đáng kinh ngạc về những khó khăn mình trải qua, đồng thời rất dễ tiếp cận một cách dễ chịu trong mentoring và tư vấn.
Trong câu “hệ thống phân tán khác biệt vì chúng thường xuyên thất bại”, điểm mấu chốt không chỉ là tỷ lệ lỗi đơn thuần, mà là tỷ lệ lỗi trong hệ thống nhiều node.
Và “vấn đề hệ thống phân tán” không chỉ xuất hiện trên nhiều server nối mạng. Nếu là một tập hợp các node có quan hệ với nhau, thì các file trên những ổ đĩa được liên kết logic hoặc buffer của các thiết bị I/O khác nhau cũng gặp các vấn đề tương tự.
Một số lão làng chế giễu sự phức tạp quá mức phát sinh khi giảm nhẹ các vấn đề này, và phàn nàn rằng chỉ cần chạy phần mềm trên một server đơn thì sẽ đơn giản hơn nhiều.
Trên thực tế, ngay cả thời AS/400 hay VAXft thì điều đó cũng hầu như không đúng, và càng không áp dụng được cho thế giới Unix đa người dùng, đa tiến trình hỗn loạn hơn.
“Nếu bạn có thể đưa bài toán vào bộ nhớ thì có lẽ đó là bài toán tầm thường” là một sai lầm phổ biến trong một số kỹ sư hệ thống phân tán.
Nó hoàn toàn không tầm thường; chỉ là các vấn đề cần xử lý chuyển sang một miền bổ sung khác.
Sai lầm này dễ dẫn đến tình huống dùng cụm 100 máy để xử lý việc mà nếu tối ưu đúng cách thì một máy đơn cũng làm được.