Mục tiêu bài học
Ghép compute, storage, database và networking vào một kiến trúc nhỏ có thể giải thích được.
Bài giảng chi tiết
Bài toán thực tế
Một web app 3-tier cần nhận traffic, chạy app qua nhiều AZ, lưu object và dùng database. Người học phải ghép đúng service theo flow và bảo vệ boundary, không chọn service chỉ vì quen tên.
Đừng học nội dung này như một danh sách tên dịch vụ. Hãy đi theo chuỗi: requirement → khái niệm → quyết định → bằng chứng. Một câu trả lời tốt phải nói được vì sao lựa chọn phù hợp, phương án gần nhất bị loại ở đâu, và kiểm tra nào chứng minh lựa chọn đó hoạt động.
Khái niệm được giải thích theo scenario
- ALB/Route 53/CloudFront xử lý entry và delivery; app tier nên nằm sau boundary phù hợp.
- ASG/EC2 xử lý compute; RDS/DynamoDB xử lý data theo access pattern; S3 xử lý object.
- Multi-AZ tăng availability nhưng không thay backup/DR; private không có nghĩa tự động secure.
- Mọi lựa chọn phải trả lời requirement, failure mode, security và cost.
Ví dụ khi gặp một scenario mới, hãy thay các từ khóa trong đề bằng một hệ thống cụ thể: ai là người dùng, dữ liệu đi qua đâu, thành phần nào có thể lỗi, quyền nào cần có và điều gì phải được quan sát. Cách làm này giúp phân biệt các đáp án gần đúng thay vì chọn theo trí nhớ tên service.
flowchart LR
A[Scenario / requirement] --> B[Concept and boundary]
B --> C[Service or control choice]
C --> D[Evidence and trade-off]
D --> E[Failure variant]
Khái niệm cốt lõi
Một flow tham chiếu: Route 53 → CloudFront/ALB → app tier ở nhiều AZ → RDS/DynamoDB → S3 cho object. Public edge chỉ chứa thành phần cần nhận traffic; database và app không cần public IP nếu route đúng. Mỗi dịch vụ phải có lý do, không dùng vì tên quen thuộc.
Ví dụ giảng viên: phân loại một quyết định cloud
Đi theo request path của ticketing app: user → DNS/CDN/ALB → app → database/object. Sau đó đi theo failure path: target unhealthy, AZ mất, database failover, object bị xóa và credential bị lộ. Mỗi hộp trên sơ đồ phải có requirement và evidence; nếu hộp chỉ xuất hiện vì “kiến trúc mẫu” thì loại ra hoặc ghi assumption.
Đổi một constraint mỗi lượt: read-heavy thành transactional, một AZ thành hai AZ, static public thành object private qua CDN. Người học đạt khi cập nhật được design và giải thích thành phần nào thay đổi, không học thuộc sơ đồ cố định.
Thực hành có kiểm soát
Vẽ kiến trúc, đánh dấu AZ, route, trust boundary và dữ liệu. Với mỗi service, viết một câu “vì sao không dùng lựa chọn gần nhất”. Đây là cách kiểm tra hiểu biết tốt hơn việc học danh sách.
Expected state và recovery
Trước khi thực hành, ghi rõ target/account/region, trạng thái hiện tại và output mong đợi. Sau thao tác, kiểm chứng bằng trạng thái thực tế hoặc command phù hợp; nếu kết quả sai, giữ lại evidence, quay về thay đổi nhỏ nhất và cleanup đúng owner. Không coi exit code 0 hoặc thông báo “success” là bằng chứng duy nhất.
- Sơ đồ có ít nhất hai AZ và không đặt database public.
- Giải thích được ALB, ASG, RDS/DynamoDB và S3 theo data/request flow.
- Phân biệt HA, backup và read scaling trong thiết kế.
- Nêu được ít nhất ba trade-off và service gần đúng bị loại vì lý do cụ thể.
Bẫy đề thi và cách tự kiểm tra
Không đặt database public chỉ để ứng dụng kết nối dễ hơn. Không dùng S3 thay EBS cho boot disk. Không xem “managed” là không cần monitoring, backup hoặc access control.