[AWS] Reliability Pillar – Trụ cột độ tin cậy

Xin chào các anh chị em. Nếu mọi người đã đọc những bài viết của mình về các nội dung có trong khóa học AWS rồi thì chắc là mọi người cũng biết, mình hay viết mấy bài về nghiên cứu hay các lý thuyết cơ bản hơn là các bài lab thực hành, do mình nghĩ các bài lab đó, các bạn gặp rất nhiều. Vậy thì hôm nay chúng ta sẽ nói đôi chút về Reliability Pillar, một trong 6 trụ cột (lục trụ) của AWS Well Architected.

Trước tiên, chúng ta hiểu reliability là gì? Reliability là mức độ tin cậy của một hệ thống. Khi hệ thống có những lỗi phát sinh thì có thể tự phục hồi về trạng thái bình thường hay không. Hệ thống có thực hiện đúng chức năng mà nó cần phải có hay không. Đây là những yêu cầu về Reliability. 

Khi thiết kế hệ thống đảm bảo reliability, chúng ta cần tuân theo 1 số nguyên lý:

• Tự động phục hồi khi có lỗi (Automatically recover from failure): Nguyên lý này nói rằng, để đảm bảo mục tiêu cho hệ thống của chúng ta (chẳng hạn với 1 lượng request nhất định), thì chúng ta cần theo dõi các chỉ số, chỉ báo để hệ thống tự động làm các công việc đằng sau. Ví dụ trường hợp có lỗi do leak memory mà chúng ta chưa thể sửa được ngay, thì ít nhất, chúng ta cũng có thể reset lại máy. Đây là cách mà thông thường chúng ta làm.
• Test tiến trình hồi phục (Test recovery procedures): Thông thường, ở các hệ thống on-premise, do việc tắt bật hay thay đổi các thành phần phần cứng bị hạn chế, nên người ta thường chỉ dùng để đo lượng workload có thể hoạt động được trên server. Tuy nhiên trên cloud, việc thực hiện 1 vài thao tác tự động để thay đổi tài nguyên là có thể thực hiện được. Do đó, trên cloud, chúng ta cần cân nhắc thêm việc này. Bên phía AWS cũng cung cấp các dịch vụ, công cụ để giả lập các trường hợp bị lỗi, thậm chí, có thể tái tạo lại các vấn đề phát sinh để tiến hành fix tiến trình hồi phục trước khi vấn đề xảy ra trong thực tế.
• Scale theo chiều ngang để tăng khối lượng công việc tổng hợp (Scale horizontally to increase aggregate workload availability): Single failure point là một vấn đề chúng ta cần phải lưu ý. Các hệ thống đang chạy cần đảm bảo, nếu có 1 vấn đề nào đó xảy ra ở bất kỳ vị trí nào cũng không được ảnh hưởng đến toàn bộ hệ thống. Chính vì thế, chúng ta nên chia một resource lớn ra làm nhiều resource nhỏ, hoạt động song song với nhau. Tất cả những vị trí này, cần đảm bảo không cùng sử dụng 1 thành phần nào đó chung, tránh single point failure. Ví dụ tránh sử dụng 1 EC2 làm Load Balancer mà nên sử dụng ELB (AWS ELB yêu cầu tối thiểu đặt trong 2 subnets do bản thân ELB có thể coi là 2 thành phần resource, có 2 IP, dùng chung 1 DNS name).
• Không cần dự đoán khả năng của hệ thống (Stop guessing capacity): Đối với hệ thống on-premise, chúng ta sẽ cần tính toán và xem xét khả năng tối đa của hệ thống. Đối với hệ thống cloud, việc scale từ các thông số hệ thống được thực hiện khá là dễ dàng, do vậy, các hệ thống xây dựng trên cloud cần xem xét và tính toán đến khả năng scale của hệ thống, và thiết lập những thông số này, chứ không nên xây dựng hệ thống có thể đạt được một ngưỡng nào đó. Việc đó có thể gây lãng phí chi phí không cần thiết, mà lại giới hạn khả năng của hệ thống.
• Tất cả những thay đổi trên hệ thống nên được tiến hành tự động. Chúng ta thường chỉ khởi tạo hệ thống lần đầu và giám sát việc chạy hệ thống. Nếu như hiện tại, hệ thống của chúng ta cần phải thực hiện thủ công bất kỳ một việc gì có tính lặp đi lặp lại thường xuyên như scale, thêm, bớt resource, có nghĩa là hệ thống của chúng ta chưa thực sự đảm bảo Reliability.

Availability và tính toán availability:

Độ khả dụng (Availability) là tỷ lệ một dịch vụ có thể sử dụng trên tổng thời gian sử dụng.

Avavilability = Available for Use Time / Total time

Ví dụ hệ thống của chúng ta mong muốn sử dụng 24/24. Tuy nhiên, mỗi ngày 1 lần, hệ thống của chúng ta cần chạy update trong vòng 2 phút, và hệ thống sẽ ở trạng thái unavailable trong 2 phút này. Vậy độ khả dụng của hệ thống sẽ là (( 24 * 60 ) – 2) / (24 * 60) = 99,8611 %

Như đã nói phía trên, thông thường người ta sẽ tránh việc để single point failure, do đó, người ta sử dụng multi resource có thể thiết lập song song như sau:

Ở đây, chúng ta thấy hệ thống sẽ trở nên Unavailable khi cả 2 thành phần đều ở trạng thái Unavailable. Chúng ta có thể tính bằng công thức sau:

Unavailability * Unavailability = Unavailability toàn phần

-> Availability toàn phần = 100% – (100% – Availability thành phần) * (100% – Availability thành phần)

(Hiện đang tính toán trong trường hợp lý tưởng là Available của các thành phần và cả hệ thống có thể đạt đến 100%)

• Khi thiết kế hệ thống, chắc chắn chúng ta sẽ gặp trường hợp các thành phần bị phụ thuộc vào nhau nối tiếp. Ví dụ Service A -> Service B -> Service C.

Khi đó, chúng ta có thể tính:

Availability toàn phần = Availability service A * Availability service B * Availability service C.

Từ đó, chúng ta có thể tính toán được độ khả dụng của tất cả các hệ thống (về lý thuyết là thế). Vậy thì các bạn có đang phân vân về việc học AWS khó hay dễ? Bạn muốn được vận dụng lí thuyết này vào công việc hàng ngày thì tham khảo khóa học AWS Practical tại CodeStar xem sao nhé: https://codestar.vn/product/aws-co-ban/