#208 - Các nguyên tắc và mẫu thiết kế cho hệ thống quy mô lớn
Thân chào quý bạn đọc,
Trong các khảo sát trước đây, một số bạn đọc phản ánh về việc khó tìm lại nội dung của các số Newsletter cũ. Nhằm giải quyết vấn đề này, team Grokking đang xây dựng một trang chỉ mục online dành cho các bài viết liên quan đến chủ đề Software Engineering nói chung, đặc biệt là các bài viết đã được đăng trên các số newsletter cũ.
Sắp tới, team product cần phỏng vấn một số bạn đọc thường xuyên của Newsletter để có thêm ý tưởng giúp hoàn thiện trang chỉ mục này. Nếu có thể tham gia, thân mời bạn đăng ký tại đây.
Buổi phỏng vấn sẽ diễn ra online trong khoảng 1-2 tiếng.
Lịch phỏng vấn sẽ được sắp xếp theo thời gian phù hợp với từng bạn.
Để thay lời cảm ơn, Grokking sẽ gửi tặng bạn một quyển Dijkstra tập 2 vừa xuất bản.
Sự tham gia của các bạn sẽ giúp chúng tôi làm ra một sản phẩm đáp ứng được nhu cầu của các bạn đọc Newsletter. Chúng tôi rất mong sẽ nhận được nhiều sự ủng hộ và ý kiến đóng góp trong tương lai.
================================================
Trong số này, chúng ta tìm hiểu về:
Một số nguyên tắc và mẫu thiết kế cho phép các hệ thống mở rộng lên quy mô lớn;
Ba loại định dạng file dữ liệu phổ biến tại Góc Database;
Lời giải đề bài Binary Tree Camera tại Góc Lập trình;
Cách Netflix giải quyết vấn đề authorization trên trên các môi trường cloud native tại mục Tech Talk.
Những bài viết hay
Design Patterns and Principles That Support Large Scale Systems
Ngày nay, ngay cả những công ty khởi nghiệp nhỏ cũng có thể phải làm việc với hàng chục terabyte dữ liệu hoặc xây dựng các dịch vụ hỗ trợ hàng trăm nghìn event mỗi phút (hoặc thậm chí một giây!). Khi nhắc tới khái niệm "scale", chúng ta thường đề cập đến một lượng lớn các request/data/event mà hệ thống phải xử lý trong một khoảng thời gian ngắn. Nếu cố gắng triển khai các dịch vụ trên quy mô lớn một cách đơn giản sẽ dễ thất bại, hoặc gây tốn kém về mặt chi phí.
Trong bài viết này, tác giả mô tả một số nguyên tắc và mẫu thiết kế cho phép hệ thống scale lên quy mô lớn. Khi nói về các hệ thống này (hầu hết là hệ thống phân tán), chúng ta thường dùng ba thuộc tính để đánh giá một hệ thống ổn định hoặc tốt đến đâu:
Availability (Tính khả dụng): Một hệ thống nên có khả năng "available" càng nhiều càng tốt. Tỉ lệ thời gian hoạt động là quan trọng nhất đối với trải nghiệm của khách hàng, và dĩ nhiên một ứng dụng sẽ không hữu ích nếu không ai có thể sử dụng nó. Tính khả dụng được đo bằng “nines”.
Performance (Hiệu suất): Một hệ thống sẽ tiếp tục hoạt động và thực hiện các nhiệm vụ của nó ngay cả khi chịu tải nặng (heavy load). Hơn nữa, tốc độ là một yếu tố rất quan trọng đối với trải nghiệm của khách hàng.
Reliability (Độ tin cậy): Một hệ thống phải xử lý dữ liệu một cách chính xác, và trả về một kết quả chính xác. Một hệ thống được cho là đáng tin cậy khi nó không bị lỗi một cách âm thầm, hoặc trả về kết quả không chính xác, hoặc tạo ra dữ liệu lỗi. Hệ thống đáng tin cậy sẽ được cấu trúc để tránh lỗi nhiều nhất có thể, và trong trường hợp bất khả kháng thì nó sẽ phát hiện, báo cáo và thậm chí cố gắng tự động sửa chữa lỗi.
Chúng ta có thể mở rộng quy mô hệ thống theo hai cách:
Mở rộng theo chiều dọc (scale-up): triển khai hệ thống trên một máy chủ với phần cứng mạnh hơn, CPU mạnh hơn, nhiều RAM hơn.
Mở rộng theo chiều ngang (scale-out): triển khai hệ thống trên nhiều máy chủ, có nghĩa là tạo ra nhiều phiên bản hơn, cho phép phục vụ lưu lượng truy cập cao hơn hoặc xử lý nhiều data/event hơn.
Trong hai phương án trên, mở rộng theo chiều dọc thường ít được ưa chuộng vì hai lý do:
Thường cần một khoảng downtime.
Có những giới hạn nhất định (chúng ta không thể cứ tăng phần cứng, CPU, RAM... mãi mãi).
Mời bạn tham khảo một số nguyên tắc và mẫu thiết kế khác nhau cho phép các hệ thống mở rộng quy mô trong khi vẫn duy trì độ tin cậy và khả năng phục hồi cao.
(by lpv)
Góc Database
Khi thiết kế các DBMS truyền thống, file storage là một trong các bài toán quan trọng có thể ảnh hưởng đến đặc tính của database. Các bạn có thể tìm đọc lại về B-tree và LSM tại Góc Database ở các kỳ trước để hiểu thêm về vai trò của file storage.
Đối với kiến trúc Data lake hiện đại, việc lựa chọn định dạng của các file dữ liệu (table format) cũng là một bài toán quan trọng không kém. Lựa chọn một định dạng phù hợp sẽ giúp cho hiệu suất query và xử lý tăng gấp nhiều lần, kèm theo đó là một số bài toán có thể được giải quyết dễ dàng hơn như atomic transactions, hoặc consistent updates.
Trong Góc Database kỳ này, mời các bạn cùng tham khảo sự khác nhau của ba loại định dạng phổ biến gần đây: Apache Hudi, Apache Iceberg và Delta lake. Chúng tôi giới thiệu hai bài viết về các nội dung sau:
(by n^4)
Góc Lập Trình
Đề tuần này: Find K-th Smallest Pair Distance
Lời giải đề bài tuần trước:
Đề bài: Binary Tree Cameras
Lời giải:
Đề bài yêu cầu tìm số camera ít nhất nhưng vẫn đảm bảo tất cả các nút được quan sát.
Trước tiên ta có thể nhận thấy rằng, nếu ta đặt camera tại nút lá của cây, ta sẽ không có được kết quả tối ưu so với việc đặt camera tại nút cha. Hình sau minh hoạ nhận xét trên:
Các nút màu xanh là các nút đang được quan sát.
Với cách đặt camera như hình bên phải, ta chỉ cần 1 camera. Với cách đặt như hình bên trái, ta cần 2 camera. Từ đó, ta thấy nên giải bài toán này với post-order traversal.
Để biết nút có đang được quan sát hay không, ta có thể dùng HashSet, mỗi lần ta đặt camera tại 1 nút ta thêm các nút đang được quan sát vào HashSet. Xem thêm về giải thuật này tại đây.
Giải thuật có độ phức tạp:
Time Complexity: là O(n),
Space Complexity: là O(n) cho
Set<TreeNode> covered.
Ta có thể tối ưu Space Complexity của giải thuật trên bằng cách định nghĩa một số trạng thái của nút như sau:
CoverWithCamera: nút đang được quan sát và có camera.
CoverNoCamera: nút đang được quan sát và không có camera. Hay nút đang được quan sát bởi camera đặt tại nút con.
NotCover: nút đang không được quan sát.
Như vậy, nếu nút là null, nút sẽ có trạng thái CoverNoCamera.
Ta thực hiện post-order travel như giải thuật trên, và kiểm tra trạng thái của các nút con:
Nếu 1 trong 2 nút con được quan sát, ta cần đặt camera tại nút hiện tại.
Nếu 2 nút con đều ở trạng thái
CoverNoCamera, nút hiện tại đang không được quan sát, trạng tháiNotCover.Trong những trường hợp còn lại, 1 trong 2 nút con có camera, nút hiện tại ở trạng thái
CoverNoCamera.
Mời các bạn đọc kỹ hơn về giải thuật này tại link bên dưới.
(by phucnh)
Tech Talks
How Netflix Is Solving Authorization Across Their Cloud — www.youtube.com
Từ 2008, Netflix đã đi đầu trong việc triển khai các micro services trên nền điện toán đám mây. Năm 2017, Netflix được công nhận là một trong những công ty hàng đầu trong việc xây dựng và vận hành các hệ thống cloud native trên quy mô lớn. Giống như nhiều công ty và tổ chức khác, Netflix có các yêu cầu bảo mật riêng cho workload. Điều này đòi hỏi một cách tiếp cận toàn diện về vấn đề ủy quyền (authorization), trả lời cho câu hỏi "Ai được làm gì" trên những resource, điểm thực thi khác nhau ở các môi trường khác nhau.
Trong buổi nói chuyện này, hai kỹ sư của Netflix là Manish Mehta (Senior Security Software Engineer) và Torin Sandall (Technical Lead, Open Policy Agent project) trình bày cách Netflix giải quyết vấn đề authorization trên trên các môi trường cloud native. Qua những gì họ chia sẻ, chúng ta có thể thấy:
Cách Netflix thực thi các quyết định authorization trên quy mô lớn với nhiều loại tài nguyên (như API HTTP, gRPC, SSH), nhiều điểm thực thi (như microservices, proxy, host-level daemons) và nhiều môi trường thực thi (như VM, vùng chứa) với một độ trễ hợp lý.
Các diễn giả cũng đi sâu vào kiến trúc của hệ thống authorization trên cloud tại Netflix, cũng như cách giảm tải (offload) các quyết định authorization sang một open source hoặc open policy agent có chung mục đích.
Mời các bạn cùng xem toàn bộ nội dung Tech Talk này tại link bên dưới.
(by MS)
Code & Tools
Great Expectation là một mã nguồn mở và là bộ tiêu chuẩn để đánh giá chất lượng dữ liệu, giúp Data Team loại bỏ các pipeline chất lượng thấp thông qua data testing, documentation, và profiling.
Góc Sponsors
Fossil Việt Nam, tiền thân là Misfit, giữ vị thế là Trung tâm Nghiên cứu và Phát triển Công nghệ Thiết bị đeo thông minh trực thuộc Fossil Group. Từ những ngày đầu thành lập, đội ngũ kỹ sư Việt đã thiết kế và xây dựng hệ sinh thái thiết bị đeo thông minh phục vụ cuộc sống của hàng triệu người toàn cầu. Chúng tôi tự hào là những nhà đổi mới luôn bứt phá giới hạn của công nghệ và thời trang, tập trung phát triển 3 nhóm sản phẩm chủ lực: thiết bị, ứng dụng, và dữ liệu trên đám mây.
ĐIỀU FOSSIL TỰ TIN MANG ĐẾN CHO BẠN?
Tham gia nghiên cứu và phát triển Thiết bị đeo thông minh hàng triệu người dùng trên toàn thế giới. Với Fossil, mỗi việc bạn làm đều có thể mang lại thay đổi cho cuộc sống của rất nhiều người.
Lộ trình nghề nghiệp đa dạng, bất kể bạn muốn quản lý đội ngũ hay tập trung phát triển chuyên môn kỹ thuật.
Cơ hội làm việc và học hỏi từ các kỹ sư Google, Qualcomm, Citizen, v.v.
Bảo hiểm sức khỏe cao cấp, thu nhập và phúc lợi cạnh tranh mang đến trải nghiệm làm việc toàn diện nhất.
Môi trường làm việc linh hoạt để bạn thỏa sức học hỏi, phát triển và tạo ra tác động tích cực!
Fossil Việt Nam đang mở ra cơ hội với hàng loạt vị trí hấp dẫn (Cloud Engineer, Android Engineer, Software Architect), mời bạn tham khảo chi tiết công việc tại ĐÂY.
Kết nối với Fossil Việt Nam
Email tuyển dụng: people@fossil.com
Linkedin: https://www.linkedin.com/company/fossilvietnamcareers
Quotes
“Walking on water and developing software from a specification are easy if both are frozen.”
― Edward V. Berard
Bạn đánh giá nội dung số newsletter này thế nào?
(1 = Rất tệ / 5 = Rất tốt)
👎 1 -------2 ------ 3 ------ 4 ------ 5 👍
(Việc đánh giá của các bạn sẽ giúp chúng tôi cải thiện nội dung newsletter tốt hơn)