Điện toán đám mây được giải thích: 11 khái niệm kiến trúc bạn phải biết (Lớp học chuyên sâu 4K).

Nội dung video này đề cập

• - Bức tường Kiến trúc & Bản thiết kế tổng thể
• - 01. Mở rộng quy mô theo chiều dọc so với chiều ngang
• - 02. Kiến trúc cân bằng tải (L4 so với L7 & Kiểm tra sức khỏe)
• - 03. Tự động điều chỉnh quy mô & Tính đàn hồi
• - 04. Không máy chủ (FaaS & Firecracker MicroVMs)

Bản ghi đã dịch

Được dịch từ lời tường thuật tiếng Anh gốc. Âm thanh và phụ đề có sẵn được điều khiển bởi YouTube.

- Bức tường Kiến trúc & Bản thiết kế tổng thể

0:00 Mọi kỹ sư phần mềm cuối cùng đều phải đối mặt với bức tường kiến trúc đám mây. Bạn xây dựng một ứng dụng trên máy tính xách tay của mình, đẩy nó vào sản xuất, và ngay khi người dùng thực sự đến, máy chủ bị treo, các kết nối cơ sở dữ liệu hết, và hóa đơn AWS của bạn trông giống như một số điện thoại. Hầu hết các nhà phát triển cố gắng giải quyết kỹ thuật đám mây bằng cách ghi nhớ ba trăm từ viết tắt sản phẩm AWS khác nhau. Nhưng điện toán đám mây thực sự không phải là ghi nhớ danh mục của nhà cung cấp: nó được xây dựng trên mười một nguyên tắc kiến trúc cơ bản.

0:34 Trong lớp học chuyên sâu này, chúng ta sẽ đi qua toàn bộ bản thiết kế doanh nghiệp: từ mở rộng quy mô và cân bằng tải đến không máy chủ, tách rời theo sự kiện, phân cấp lưu trữ và mạng đám mây. Nắm vững mười một khái niệm này, bạn có thể thiết kế bất kỳ phần phụ trợ nào trên AWS, GCP hoặc Azure. Đây là The Daily Diff, bên trong.

- 01. Mở rộng quy mô theo chiều dọc so với chiều ngang

0:57 Khái niệm số một: Mở rộng quy mô. Khi ứng dụng của bạn gặp phải sự gia tăng lưu lượng truy cập, bạn có hai cách cơ bản khác nhau để xử lý tải: mở rộng quy mô theo chiều dọc, hoặc mở rộng quy mô theo chiều ngang. Mở rộng quy mô theo chiều dọc, hay mở rộng tăng, có nghĩa là lấy máy hiện có của bạn và thêm nhiều tài nguyên hơn: nâng cấp từ bốn lõi CPU lên ba mươi hai, hoặc hoán đổi ba mươi hai gigabyte RAM lấy một trăm hai mươi tám. Mở rộng quy mô theo chiều dọc không yêu cầu thay đổi kiến trúc: mã của bạn

1:28 và cơ sở dữ liệu vẫn hoàn toàn giống nhau. Nhưng nó gặp phải một giới hạn phần cứng khắc nghiệt. Không có một máy duy nhất nào trên thế giới có mười nghìn lõi CPU, và các phiên bản hàng đầu có giá cao cấp theo cấp số nhân. Mở rộng quy mô theo chiều ngang, hay mở rộng ra, có nghĩa là giữ cho máy chủ của bạn nhỏ và có giá cả phải chăng, nhưng chạy nhiều phiên bản song song phía sau một bộ định tuyến. Nếu một phiên bản bị lỗi, các nút còn lại sẽ hấp thụ lưu lượng truy cập mà không có thời gian ngừng hoạt động. Quy tắc vàng của mở rộng quy mô theo chiều ngang là

2:01 tính không trạng thái: các máy chủ ứng dụng của bạn không thể lưu trữ các phiên người dùng, các tệp đã tải lên, hoặc trạng thái trên các đĩa cục bộ của chúng. Trạng thái phải nằm trong một cơ sở dữ liệu hoặc bộ đệm bên ngoài, cho phép bất kỳ nút nào xử lý bất kỳ yêu cầu người dùng nào.

- 02. Kiến trúc cân bằng tải (L4 so với L7 & Kiểm tra sức khỏe)

2:17 Khái niệm số hai: Cân bằng tải. Mở rộng quy mô theo chiều ngang nghe có vẻ tuyệt vời trên lý thuyết, nhưng nó đưa ra một vấn đề ngay lập tức: khi mười nghìn người dùng truy cập tên miền của bạn, máy chủ cụ thể nào nhận được lưu lượng truy cập của họ? Bộ cân bằng tải hoạt động như một máy chủ proxy ngược nằm giữa internet công cộng và cụm phụ trợ riêng của bạn. Nó chấp nhận các kết nối TCP hoặc HTTP đến và phân phối các yêu cầu trên các phiên bản hoạt động của bạn.

2:47 Bộ cân bằng tải hoạt động ở hai lớp mạng chính. Bộ cân bằng tải mạng Lớp 4 hoạt động ở lớp vận chuyển, định tuyến các gói TCP và UDP thô dựa trên địa chỉ IP và cổng với độ trễ micro giây và hàng triệu yêu cầu mỗi giây. Bộ cân bằng tải ứng dụng Lớp 7 kiểm tra giao thức HTTP chính nó: đọc đường dẫn URL, tiêu đề yêu cầu, cookie và phương thức HTTP. Điều này cho phép định tuyến dựa trên đường dẫn: gửi yêu cầu slash-api đến cụm phụ trợ của bạn và yêu cầu slash-static đến một

3:25 kho lưu trữ đối tượng. Quan trọng là, bộ cân bằng tải thực hiện kiểm tra sức khỏe chủ động. Mỗi vài giây, bộ cân bằng ping một điểm cuối sức khỏe trên mỗi phiên bản. Nếu một phiên bản ném ba lỗi năm trăm liên tiếp hoặc không phản hồi, nó sẽ tự động bị loại khỏi nhóm mà không bỏ lỡ yêu cầu nào.

- 03. Tự động điều chỉnh quy mô & Tính đàn hồi

3:45 Khái niệm số ba: Tự động điều chỉnh quy mô. Nếu ứng dụng web của bạn cần hai máy chủ vào lúc ba giờ sáng, nhưng hai mươi máy chủ trong một đợt ra mắt giữa trưa, việc nhấp chuột thủ công các nút trong bảng điều khiển đám mây là một con đường chắc chắn dẫn đến thời gian ngừng hoạt động và phá sản. Tự động điều chỉnh quy mô mang lại tính đàn hồi động cho các nhóm máy chủ ngang. Một Nhóm Tự động Điều chỉnh quy mô giám sát các chỉ số hiệu suất như mức sử dụng CPU trung bình, I-O mạng hoặc độ sâu tồn đọng hàng đợi. Khi CPU trung bình vượt qua một ngưỡng xác định — ví dụ,

4:19 bảy mươi phần trăm trong ba phút liên tiếp — bộ tự động điều chỉnh quy mô tự động khởi chạy các máy ảo mới, đăng ký chúng với bộ cân bằng tải của bạn, và bắt đầu định tuyến lưu lượng truy cập. Quan trọng không kém là mở rộng thu nhỏ: khi sóng lưu lượng truy cập giảm, bộ tự động điều chỉnh quy mô sẽ chấm dứt các phiên bản dư thừa để bạn ngừng trả tiền cho tính toán nhàn rỗi. Để ngăn chặn sự dao động — nơi các máy chủ được tạo và phá hủy nhanh chóng trong một vòng lặp không ngừng — các kiến trúc sư đám mây cấu hình thời gian chờ. Khái niệm số bốn: Không máy chủ.

- 04. Không máy chủ (FaaS & Firecracker MicroVMs)

4:53 Trong nhiều năm, các nhóm tiếp thị đã quảng bá không máy chủ như một mã ma thuật chạy trên bầu trời. Trong thực tế, không máy chủ vẫn sử dụng máy chủ — nhưng bạn không sở hữu, vá lỗi, hoặc trả tiền cho chúng khi không có mã nào chạy. Với Chức năng dưới dạng Dịch vụ như AWS Lambda hoặc Google Cloud Functions, bạn viết một hàm xử lý độc lập. Khi một yêu cầu HTTP, tải lên tệp S3 hoặc thay đổi cơ sở dữ liệu xảy ra, thời gian chạy đám mây khởi động một

5:23 máy vi tính ảo tạm thời như Firecracker trong vòng chưa đầy năm mili giây. Mã của bạn thực thi, trả về một phản hồi và tắt. Nếu không ai truy cập trang web của bạn trong ba tháng, hóa đơn điện toán của bạn chính xác là không đô la và không xu. Nếu một triệu người dùng truy cập nó đồng thời, nhà cung cấp sẽ khởi động một triệu microVM đồng thời. Các đánh đổi kỹ thuật là có thật: độ trễ khởi động lạnh khi khởi động các thời gian chạy mới, giới hạn thực thi cứng mười lăm phút trên Lambda và tính không trạng thái nghiêm ngặt.

5:55 Không máy chủ là không thể đánh bại cho các đường ống sự kiện và API rời rạc, nhưng kém hiệu quả cho WebSockets bền vững hoặc các phiên chạy huấn luyện kéo dài nhiều giờ.

- 05. Kiến trúc hướng sự kiện (EDA & Tách rời)

6:05 Khái niệm số năm: Kiến trúc hướng sự kiện, hay EDA. Trong các kiến trúc truyền thống, các dịch vụ giao tiếp đồng bộ. Dịch vụ thanh toán của bạn gọi thanh toán, thanh toán gọi hàng tồn kho, hàng tồn kho gọi gian lận, và gian lận gọi email. Điều này tạo ra sự sụp đổ đồng bộ. Nếu nhà cung cấp email bên thứ ba gặp sự cố mạng và mất mười giây để phản hồi, toàn bộ yêu cầu thanh toán của khách hàng sẽ hết thời gian chờ với một lỗi. Trong kiến trúc hướng sự kiện, các dịch vụ được tách rời hoàn toàn.

6:37 Khi khách hàng nhấp vào mua, dịch vụ thanh toán không gọi các dịch vụ hạ nguồn. Nó chỉ đơn giản là xuất bản một sự kiện gọi là Đơn hàng đã đặt tới một Bus sự kiện trung tâm như Amazon EventBridge hoặc một chủ đề SNS. Việc thanh toán hoàn tất trong năm mươi mili giây. Các tác nhân hạ nguồn để thanh toán, trừ hàng tồn kho và biên lai email kéo tin nhắn độc lập từ các hàng đợi SQS chuyên dụng của riêng họ. Nếu dịch vụ email ngừng hoạt động trong một giờ, tin nhắn sẽ đợi an toàn được đệm trong hàng đợi mà không bị bỏ lỡ một đơn hàng nào.

- 06. Điều phối Container (Docker & Kubernetes)

7:13 Khái niệm số sáu: Điều phối Container. Docker đã giải quyết vấn đề đóng gói: nó gói mã ứng dụng của bạn, các thư viện hệ thống, cấu hình và thời gian chạy thành một hình ảnh bất biến chạy giống hệt trên MacBook của bạn và trên đám mây. Nhưng đóng gói một container thì dễ. Chạy năm trăm container trên năm mươi máy ảo vật lý là nơi kỹ thuật bị hỏng. Đó là lý do tại sao các bộ điều phối container như Kubernetes và AWS ECS

7:41 tồn tại. Một bộ điều phối cung cấp một mặt phẳng điều khiển: một máy chủ API, một kho trạng thái etcd và một bộ lập lịch thông minh. Bạn khai báo trạng thái mong muốn của mình: Tôi muốn mười bản sao của dịch vụ xác thực của tôi với hai gigabyte RAM mỗi cái. Bộ lập lịch kiểm tra cụm, đặt các pod lên các nút có bộ nhớ trống, cấu hình mạng nội bộ và liên tục điều chỉnh thực tế. Nếu một nút gặp sự cố phần cứng, Kubernetes phát hiện sự mất mát và ngay lập tức lên lịch lại tất cả các pod bị dịch chuyển lên các

- 07. 4 trụ cột lưu trữ đám mây (S3, EBS, DBs & Redis)

8:16 nút khỏe mạnh. Khái niệm số bảy: Hệ thống phân cấp lưu trữ đám mây. Người mới bắt đầu thường coi lưu trữ đám mây là một thùng duy nhất nơi bạn đổ các tệp. Trong kiến trúc sản xuất, lưu trữ được chia thành bốn trụ cột riêng biệt dựa trên các mô hình truy cập và độ trễ. Đầu tiên là Lưu trữ đối tượng, như Amazon S3 hoặc Google Cloud Storage. Bạn truy cập các tệp qua API HTTP REST bằng cách sử dụng các cuộc gọi PUT và GET đơn giản. Nó cung cấp dung lượng ngang vô hạn với hai xu mỗi gigabyte mỗi tháng,

8:49 làm cho nó lý tưởng cho video, tải lên của người dùng, nhật ký và sao lưu. Thứ hai là Lưu trữ khối, như Amazon EBS. Đây là các ổ cứng ảo được gắn trực tiếp vào một máy ảo cụ thể qua các kết nối tốc độ cao. Chúng định dạng thành các hệ thống tệp tiêu chuẩn như ext4, hỗ trợ truy cập đọc và ghi ngẫu nhiên nhanh chóng được yêu cầu bởi các công cụ cơ sở dữ liệu. Thứ ba là Cơ sở dữ liệu được quản lý: các công cụ quan hệ như PostgreSQL trên RDS cung cấp các giao dịch ACID và các phép nối phức tạp,

9:21 và các công cụ NoSQL như DynamoDB cung cấp độ trễ một chữ số mili giây ở quy mô lớn. Và thứ tư là Bộ đệm trong bộ nhớ như Redis. Đọc dữ liệu từ RAM mất micro giây thay vì mili giây. Bộ đệm nằm trước cơ sở dữ liệu của bạn, che chắn nó khỏi lưu lượng đọc lặp lại và quản lý các mã thông báo phiên người dùng biến động.

- 08. Tính sẵn sàng cao & Các số 9 (Chuyển đổi dự phòng đa AZ)

9:44 Khái niệm số tám: Tính sẵn sàng cao, hay HA. Tính sẵn sàng trả lời một câu hỏi: ứng dụng của bạn hoạt động và có thể truy cập được bởi người dùng trong bao nhiêu phần trăm thời gian? ứng dụng của bạn hoạt động và có thể truy cập được bởi người dùng? Trong các hợp đồng doanh nghiệp, tính sẵn sàng được đo bằng số chín. Hai số chín, hay chín mươi chín phần trăm tính sẵn sàng, cho phép hơn ba ngày rưỡi thời gian ngừng hoạt động mỗi năm. Bốn số chín giảm thời gian ngừng hoạt động được phép xuống còn năm mươi hai phút, và năm số chín chỉ cho phép năm phút tổng thời gian ngừng hoạt động mỗi

10:15 năm. Để đạt được tính sẵn sàng cao, bạn phải loại bỏ các điểm lỗi đơn lẻ trên các miền lỗi. Trong đám mây, điều đó có nghĩa là triển khai trên nhiều Vùng sẵn sàng. Một Vùng sẵn sàng không phải là một giá đỡ duy nhất: nó là một hoặc nhiều trung tâm dữ liệu vật lý riêng biệt cách xa hàng dặm với nguồn điện và hệ thống làm mát độc lập. Bằng cách chạy các phiên bản hoạt động trong Vùng A và Vùng B với đồng bộ hóa cơ sở dữ liệu, một tia sét hoặc đường cáp quang bị đứt làm sập toàn bộ cơ sở vật lý sẽ dẫn đến một chuyển đổi dự phòng tự động.

10:50 trong ba mươi giây mà không cần sự can thiệp của con người.

- 09. Độ bền so với tính sẵn sàng (Tại sao 11 số 9 không phải là thời gian hoạt động)

10:53 Khái niệm số chín: Độ bền (Durability) so với Tính sẵn sàng (Availability). Đây là cạm bẫy khái niệm phổ biến nhất trong kiến trúc đám mây trong các buổi phỏng vấn. Các kỹ sư thường sử dụng các từ này thay thế cho nhau, nhưng chúng đo lường các thuộc tính hoàn toàn khác nhau. Tính sẵn sàng đo thời gian hoạt động: tôi có thể thực hiện một lệnh gọi API để đọc hoặc ghi dữ liệu của mình ngay lúc này không? Độ bền đo sự bảo toàn: dữ liệu của tôi sẽ tồn tại mà không bị hỏng vĩnh viễn, hư hại hoặc phá hủy trong mười năm không?

11:24 Hãy xem Amazon S3 Standard. Thỏa thuận cấp độ dịch vụ của nó cung cấp chín mươi chín phẩy chín phần trăm tính sẵn sàng, cho phép khoảng bốn mươi ba phút ngừng hoạt động mỗi tháng khi yêu cầu API có thể trả về lỗi năm trăm. Nhưng S3 hứa hẹn mười một số chín của độ bền: chín mươi chín phẩy chín chín chín chín chín chín chín chín chín phần trăm. Nếu bạn lưu trữ mười triệu tệp trong S3, bạn có thể thống kê rằng sẽ mất trung bình một

11:56 tệp cứ mỗi mười nghìn năm. S3 đạt được điều này bằng cách mã hóa xóa các đối tượng và sao chép các khối trên ít nhất ba cơ sở dữ liệu được tách biệt về mặt địa lý. Trong thời gian mất mạng khu vực lớn, S3 có thể tạm thời không khả dụng, nhưng dữ liệu của bạn không bao giờ bị phá hủy.

- 10. Cơ sở hạ tầng dưới dạng mã (Terraform so với Console Drift)

12:14 Khái niệm số mười: Hạ tầng dưới dạng Mã, hay IaC. Trong những ngày đầu của điện toán đám mây, các kỹ sư đăng nhập vào bảng điều khiển quản lý web của AWS và nhấp chuột thủ công để tạo các máy ảo, cấu hình các mạng con và gắn các nhóm bảo mật. Ngành gọi đây là ClickOps, và trong môi trường sản xuất, nó là một thảm họa tuyệt đối. Các thay đổi thủ công trên bảng điều khiển không có nhật ký kiểm toán, không có cơ chế quay lại và chắc chắn gây ra sự trôi lệch cấu hình giữa môi trường thử nghiệm và môi trường sản xuất. Với các công cụ Hạ tầng dưới dạng Mã

12:48 như Terraform, OpenTofu, Pulumi hoặc AWS CDK, bạn định nghĩa toàn bộ kiến trúc đám mây của mình trong các tệp cấu hình khai báo được lưu trữ trong Git. Mọi thay đổi đối với một cổng mở hoặc bản sao cơ sở dữ liệu đều thông qua một yêu cầu kéo (pull request) và đánh giá ngang hàng. Chạy terraform plan xem trước sự khác biệt API chính xác trước khi bất cứ điều gì được chạm vào, và khởi tạo một bản sao giống hệt của ngăn xếp sản xuất của bạn mất bốn phút thay vì bốn tuần.

- 11. Mạng đám mây (VPC, Subnet, NAT & Nhóm bảo mật)

13:20 Khái niệm số mười một: Mạng đám mây và Đám mây riêng ảo. Khi bạn triển khai máy chủ lên đám mây, chúng không nằm phơi bày trên internet công cộng thô. Chúng sống bên trong một ranh giới cô lập được xác định bằng phần mềm gọi là VPC. Bên trong VPC của bạn, bạn phân bổ một không gian địa chỉ IP riêng tư như mười chấm không chấm không chấm không gạch chéo mười sáu, và chia nó thành các mạng con công cộng và riêng tư. Một mạng con công cộng có tuyến đường trực tiếp đến một Cổng Internet.

13:51 Nó chứa các tài sản hướng ra công chúng như Bộ cân bằng tải ứng dụng và Cổng NAT của bạn. Đây là phần duy nhất của mạng của bạn sở hữu các địa chỉ IP công cộng. Máy chủ ứng dụng và cơ sở dữ liệu sản xuất của bạn chỉ nằm trong các mạng con riêng tư mà không có IP công cộng và không có tuyến đường đến từ internet. Khi các máy chủ phụ trợ của bạn cần tải xuống các bản cập nhật bảo mật, lưu lượng truy cập đi của chúng được định tuyến qua Cổng NAT trong mạng con công cộng. Bao quanh mọi phiên bản là Nhóm bảo mật: các tường lửa ảo có trạng thái thực thi nguyên tắc ít đặc quyền nhất.

- 12. Bản thiết kế doanh nghiệp hoàn chỉnh & Đánh giá

14:28 Nhóm bảo mật cơ sở dữ liệu của bạn chỉ chấp nhận kết nối trên cổng 5432 nghiêm ngặt từ nhóm bảo mật của các máy chủ ứng dụng của bạn, khiến việc xâm nhập từ bên ngoài là không thể về mặt toán học. Khi bạn nhìn tổng thể, mười một yếu tố cơ bản này kết nối thành một hệ thống gắn kết. DNS của bạn định tuyến đến một Bộ cân bằng tải trong một mạng con công cộng, các nhóm tự động mở rộng quy mô xử lý các đợt lưu lượng truy cập trên nhiều Vùng sẵn sàng, các bus sự kiện tách rời các worker phụ trợ, và toàn bộ ngăn xếp của bạn được triển khai từ Git bằng cách sử dụng Hạ tầng dưới dạng Mã.

15:02 Phán quyết của buổi học chuyên sâu hôm nay: SHIP IT. Ngừng ghi nhớ hàng trăm từ viết tắt tiếp thị đám mây. Nắm vững mười một mẫu kiến trúc này, tách rời trạng thái của bạn, và xây dựng các hệ thống không thể thất bại. Hãy cho tôi biết khái niệm đám mây nào đã khiến bạn đau đầu nhất khi bạn mới bắt đầu xây dựng trong phần bình luận. Và để lấy bảng gian lận kiến trúc đầy đủ, hãy đăng ký nhận bản tin tại the daily diff dot dev,

15:28 liên kết bên dưới. Và đó là sự khác biệt cho ngày hôm nay. Tôi là Niko từ Axrisi. Hợp nhất có trách nhiệm.

Nguồn

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io