View profile

#178 - Đo lường Site Reliability với SLI, SLO, và SLA

Grokking Vietnam
Grokking Vietnam
Những bài viết hay
Measuring Site Reliability with SLI, SLO, and SLA
Trọng tâm chính của Site reliability engineering (SRE) là xây dựng và chạy một ứng dụng đáng tin cậy mà không ảnh hưởng đến tốc độ delivery sản phẩm - hai điều hoàn toàn trái ngược nhau (tức là “Tạo ra phần mềm tốt hơn, nhanh hơn”).
Các kỹ sư SRE đo lường mọi thứ, đồng thời xác định và đồng thuận dựa trên các chỉ số có thể đo lường, để đảm bảo công việc hướng tới một mục tiêu có thể đo lường được. Ví dụ, nói rằng trang web đang chạy chậm là một tuyên bố mơ hồ vì nó không có ý nghĩa gì về mặt kỹ thuật. Nhưng nói rằng 95% lượng phản hồi có thời gian vượt quá SLO 10%, thì sẽ mang lại nhiều giá trị hơn. SRE cũng đo lường các công việc lặp đi lặp lại theo thời gian và tìm cách tự động hóa chúng. 
Có ba tham số độ tin cậy chính mà SRE xử lý: Definition of availability (SLO), Indicators of Availability (SLI), và Consequences of Unavailability (SLA)
Service Level Indicators (SLI) là các thước đo định lượng được xác định cẩn thận về một số khía cạnh của mức độ dịch vụ được cung cấp. Một số ví dụ phổ biến có thể là độ trễ yêu cầu, tỷ lệ lỗi, thông lượng dữ liệu, … SLI dành riêng cho user journeys và chúng khác nhau giữa các ứng dụng. User journey là một chuỗi các hoạt động được người dùng thực hiện để đạt được một mục đích cụ thể. Ví dụ: user journey để thực hiện chuyển khoản ngân hàng có thể là thêm người nhận thanh toán và thực hiện chuyển tiền.
Service Level Objectives (SLO) chỉ định mức mục tiêu cho độ tin cậy của dịch vụ của bạn. SRE team sẽ xác định phần trăm SLI bạn nên đáp ứng để coi trang web của bạn là đáng tin cậy. SLO được tạo bằng cách kết hợp một hoặc nhiều SLI. Ví dụ: nếu bạn có SLI yêu cầu độ trễ dưới 500 ms trong 15 phút qua với phân vị 95%, SLO sẽ cần SLI được đáp ứng 99% thời gian đối với SLO 99%.
Service Level Agreements (SLAs) là một hợp đồng rõ ràng hoặc được ngầm hiểu đối với người dùng dịch vụ bao gồm các hậu quả của việc đáp ứng (hoặc thiếu) SLO được nêu ra. SLA là một thỏa thuận mang tính chính thức với khách hàng nêu rõ điều gì sẽ xảy ra nếu tổ chức không đáp ứng SLA. Chúng có thể vừa rõ ràng (explicit), vừa ẩn ý (implicit). Explicit SLA là một SLA có hậu quả xác định (chủ yếu là về tín dụng dịch vụ) do không đáp ứng độ tin cậy đã đặt. Implicit SLA ngầm được đo lường về mức độ mất uy tín đối với doanh nghiệp và khách hàng.
betterprogramming.pub
How to troubleshoot memory problems in Python
Các vấn đề về bộ nhớ, như out-of-memory là một trong những vấn đề khó khăn thường gặp phải. Các vấn đề này thường rất khó chẩn đoán nguyên nhân và khắc phục. Trong Python, tính năng garbage collection cho phép dễ dàng sử dụng ngôn ngữ này, nhưng đôi khi nó sẽ không hoạt động như mong đợi, và có thể gặp khó khăn trong việc xác định và khắc phục sự cố.
Trong bài đăng trên blog này, tác giả sẽ chỉ ra cách chẩn đoán và khắc phục sự cố bộ nhớ trong EvalML, thư viện AutoML mã nguồn mở được phát triển bởi Alteryx Innovation Labs. Không có công thức kỳ diệu nào để giải quyết các vấn đề về bộ nhớ, nhưng thông qua bài viết này, bạn có thể tìm hiểu về các công cụ và phương pháp hay nhất có thể tận dụng khi gặp phải loại vấn đề này trong tương lai.
innovation.alteryx.com
How Netflix describes the play process
How Netflix describes the play process
Netflix: What Happens When You Press Play?
Khi nhắc đến một hệ thống stream video, chúng ta thường sẽ nghĩ đến việc lưu trữ video trên một kho storage nào đó, ví dụ như AWS S3, và khi bấm “Play” thì thông qua url, video sẽ truyền trực tiếp từ S3, qua internet, đến thẳng thiết bị của bạn. Cách làm này hoàn toàn hợp lí, cho một ứng dụng nhỏ. Tuy nhiên với một hệ thống toàn cầu có hơn 110 triệu subscribers, trên 200 nước, 1 tỉ giờ stream video mỗi tuần, chiếm 37% lưu lượng internet nước Mĩ (dựa trên dữ liệu 2017), cách hoạt động của Netflix phức tạp và thú vị hơn chúng ta tưởng nhiều.
Tuy bài viết được tác giả phân tích và giải thích rất chi tiết, chúng ta có thể tóm gọn lại như sau:
- Netflix có thể chia làm 3 phần: backend, client, và CDN ở giữa.
- Netflix chỉ hoạt động trên 2 cloud: AWS và Netflix Open Connect, một hệ thống CDN toàn cầu của riêng Netflix.
- Mọi thứ trước khi nhấn Play được xử lí trên AWS, bao gồm khâu chuẩn bị, xử lí data và nhận request từ clients.
- Mọi thứ sau khi nhấn Play được xử lí trên Open Connect.
- Tất cả video được stream từ một OCA ( Open Connect Appliance) đặt gần client từ Open Connect CDN.
- Netflix hoạt động trên 3 region AWS và có thể xử lí failure từ bất cứ region nào mà user không hề biết.
- Những video mới được biến đổi thành nhiều định dạng khác nhau. Netflix chọn ra định dạng thích hợp nhất cho client dựa trên loại thiết bị, chất lượng mạng, vị trí địa lí, và gói subscription.
- Hằng ngày, thông qua Open Connect, Netflix phân tán video khắp thế giới dựa trên dự đoán user trên mỗi vùng sẽ muốn xem video.
- Khi bạn nhấn Play, client gửi một play request lên Netflix Playback Apps chạy trên AWS.
- Netflix kiểm tra bản quyền và quyền truy cập của bạn.
- Playback Apps trả về list các URLs cho khoảng 10 OCA servers đc cho là tốt nhất và nhanh nhất cho client.
- Client chọn ra OCA nào để dùng, bằng cách liên tục test chất lượng kết nối tới mỗi OCAs, và chọn ra cái nhanh nhất và đáng tin cậy nhất. Quá trình test này diễn ra liên tục trong quá trình stream video.
- Client chọn ra cách tốt nhất để nhận video từ OCA được chọn.
- Client kết nối tới OCA và bắt đầu stream video.
- Client liên tục điều chỉnh chất lượng video để phù hợp với tốc độ đường truyền, và thậm chí đổi qua OCA khác nếu chất lượng giảm quá nhiều.
Bài viết được tác giả giải thích rất kĩ thích, phù hợp cho cả đối tượng newbie về xử lí điện toán đám mây, và được xuất thành Kindle ebook riêng có cùng tên. Mời bạn truy cập bài viết gốc để nắm thêm chi tiết nhé.
highscalability.com
Góc Distributed System
Một số ý tưởng trong thiết kế hệ thống Async của FacebookAsync là hệ thống trung tâm xử lý các job bất đồng bộ ở Facebook, bất kể job được submit từ service nào.
Nhiệm vụ chính của nó là nhận job từ các service, đưa vào hệ thống queue, sau đó phân bổ tới các máy worker để thực hiện. Tuy nhiên do đặc thù của Facebook là có lượng truy cập rất lớn, hệ thống Async này có một số điểm thiết kế đặc biệt để đáp ứng được.
Bài viết này tuy không đi sâu vào implementation, nhưng có liệt kê những điểm thiết kế đó như sau:
1. Đảo ngược mức độ ưu tiên.
Thay vì ưu tiên các job cần thực hiện sớm theo thiết kế thông thường, Async xác định deadline của job và ưu tiên chọn job gần sát với deadline nhất để xử lý. Việc này làm giảm gánh nặng đáng kể cho hệ thống lúc peak time.
2. Xây dựng hệ thống Async gồm rất nhiều queue.
Mỗi queue phục vụ cho 1 luồng use-case cụ thể và chỉ nhận job từ use-case đó. Queue ở đây là priority queue, sắp xếp job theo thứ tự deadline mô tả ở điểm #1. Ở đầu nhận, Dispatcher sẽ pickup job từ các queue, chọn lấy job có deadline sát nhất đẩy vào worker. Ở đầu gửi, các background threads sẽ đẩy thêm job từ client services vào các queue.
3. Time shifting.
Để tránh quá tải ở peak time, Async sẽ thực hiện một số pre-computation ở những thời điểm low traffic, hay còn gọi là off-peak. Hệ thống có module đi thu thập dữ liệu người dùng đã sử dụng hoặc tương tác trong ngày hôm qua, đưa ra dự đoán về các dữ liệu người dùng có thể cần tới trong ngày hôm nay để lưu vào cache, phục vụ cho thời điểm peak time. Một ví dụ khác là những dữ liệu đưa cho người dùng lúc họ online nhưng có thể tính offline ví dụ như “people you may know”
4. Batching.
Các job được gom lại để lưu vào 1 slot trong queue, tránh việc phân bổ job quá nhỏ. Đây là cách tiếp cận thông thường, và các hệ thống queue thường có hỗ trợ việc batching này.
5. Xây dựng policy về quota và rate limit.
Async có cơ chế track vấn đề sử dụng resource của từng luồng use-case để có điều chỉnh quota và rate limit cho phù hợp. Tuy nhiên các traffic mang tính đột biến có thể go over ngưỡng cho phép, do đó rate limiting của async vẫn có cơ chế buffer (overlimit) để đề phòng cho những trường hợp này.
Bài viết gốc: https://engineering.fb.com/2020/08/17/production-engineering/async/
Trong một bài viết khác, Facebook có mô tả về hệ thống priority queue của họ. Mời bạn xem ở đây: https://engineering.fb.com/2021/02/22/production-engineering/foqs-scaling-a-distributed-priority-queue/
Góc Lập Trình
Đề ra kỳ này
Tìm số đường đi trong ma trận.
Cho ma trận mxn, hãy tìm số đường đi có thể để đi từ điểm xuất phát (0, 0) tới đích (m-1, n-1). Lưu ý, ta chỉ có thể đi sang phải, hoặc đi xuống.Điều kiện: 1 <= m, n <= 100
Ví dụ 1:
Cho ma trận 3x2 (m=3, n=2) , ta sẽ có 3 đường đi như sau.
- Sang phải → Đi xuống → Đi xuống
- Đi xuống → Đi xuống → Sang phải
- Đi xuống → Sang phải → Đi xuống
Chương trình trả lại kết quả bằng 3.
Ví dụ 2:
m = 7, n = 3
output = 28
Ví dụ 3:
m = 3, n = 3
output = 6
Lời giải tuần trước:
Chúng ta có thể dùng giải pháp greedy để giải bài toán này như sau: Với mỗi số bắt đầu từ số thứ 2, chúng ta cần tìm số thao tác nhỏ nhất để biến đổi nó thành một số lớn hơn số trước đấy. Lưu ý là khi thêm các chữ số vào phía sau, ta sẽ muốn 1 số nhỏ nhất có thể, qua đó đảm bảo số thao tác là nhỏ nhất.
Giả sử xét 1 cặp Xi và Xi+1, tạm gọi là A và B. Chúng ta cần tìm một số B’ sao cho B’ > A và B là prefix của B’.
Gọi hàm len(Z) là hàm trả về số chữ số của một số nguyên Z.
Bước đầu tiên ta kiểm tra nếu A < B, vậy B’ = B, ta ko cần làm gì và chuyển qua xét cặp số tiếp theo Xi+1 và Xi+2.
Bước thứ 2, nếu A >= B và len(A) = len(B), ta chỉ cần thêm 1 số 0 vào phía sau B để được số B’.
Bước 3, nếu len(A) > len (B), gọi k = len(A) - len(B):
- Ta sẽ thử thêm k số 0 vào phía sau B để được một số B’ nhỏ nhất có thể lớn hơn A. So sánh B’ và A, nếu B’ > A đây là phương án tối ưu.
- Nếu B’ < A. Nếu ta thêm k số 9 vào phía sau B, và vẫn được một số nhỏ hơn A, vậy có nghĩa là B’ sẽ cần nhiều chữ số hơn A. Trong trường hợp này, ta cần thêm k+1 số 0 vào phía sau B để được B’ tối ưu nhất.
- Ngược lại, nếu thêm k số 9 vào phía sau B và ta được một số lớn hơn A, vậy có nghĩa là B’ sẽ có số chữ số = A. Trong trường hợp này, ta chỉ cần lấy B’ = A + 1 sẽ là phương án tối ưu.
Lời giải sau sử dụng python tương đối gọn gàng và cho kết quả chính xác.
Code & Tools
Tin tức khác
Việt Nam giành 4 huy chương Bạc Olympic Tin học quốc tế năm 2021
Việt Nam giành 4 huy chương Bạc Olympic Tin học quốc tế năm 2021
Vừa qua cả 4 học sinh của đội tuyển Việt Nam dự thi Olympic Tin học quốc tế đều đạt huy chương Bạc.
Các bạn đọc cũng có thể thử làm đề thi năm nay tại đây nhé.
vietnamnet.vn
This Week Sponsors
Discover your career at KMS with many available jobs, especially with a 1-month joining bonus: CLICK HERE.
More surprisingly, your next move could be even greater when referred by your buddies who are working at KMS:
  • One-month joining bonus
  • FULL 13th-month salary
  • Cut off HR screening and phone interview
  • Only 1 all-included interview
  • Employment results within 3 working days
We hope it impresses you in case you’re considering KMS Technology as your next career destination or you know someone who does.
Quotes
A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work.
John Gall, Systemantics (1975)
Did you enjoy this issue? Yes No
Grokking Vietnam
Grokking Vietnam

Cảm ơn bạn đã dành thời gian đọc newsletter kỳ này và chúng tôi hi vọng rằng bạn đã khám phá ra một số điều mới mẻ từ các bài viết trên. Các bạn có thể đọc lại các số cũ tại website newsletter.grokking.org

Ngoài ra các bạn có thể gửi feedback cho Grokking Newsletter team ở https://bit.ly/3k3Jdw5 hoặc đóng góp bài viết tại https://bit.ly/2XaBUtF

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.
Charmington La Pointe, 181 Cao Thang, Dist 10, Ho Chi Minh city, Viet Nam