Classic Solutions Architecture
Ba câu chuyện, mỗi câu bắt đầu từ một máy chủ đơn giản rồi lớn dần cho tới khi thành kiến trúc thật. Đây chính là cách đề thi mô tả tình huống — nên chương này dạy bạn lối tư duy nhiều hơn là kiến thức mới.
Cách đọc chương này
Chương này gần như không giới thiệu dịch vụ mới — ngoài Elastic Beanstalk. Giá trị của nó nằm ở chỗ khác: cho bạn thấy vì sao mỗi thành phần được thêm vào kiến trúc, chứ không phải chỉ biết nó tồn tại.
Mỗi câu chuyện đi theo cùng một nhịp: bắt đầu đơn giản → gặp vấn đề cụ thể → thêm đúng một thứ để giải quyết → gặp vấn đề mới. Đề thi SAA mô tả tình huống theo đúng kiểu này, nên nắm được mạch tiến hóa là nắm được cách chọn đáp án.
1. Ứng dụng có state không (session, file, dữ liệu cục bộ)?
2. Cần sẵn sàng cao tới mức nào (một AZ, nhiều AZ, nhiều region)?
3. Đâu là ràng buộc ưu tiên số một — chi phí, hiệu năng, hay tính sẵn sàng?
WhatsTheTime.com — ứng dụng stateless
Ứng dụng chỉ trả về giờ hiện tại. Không cần database, không lưu gì cả — đây là ví dụ stateless thuần túy.
Bước 1 — Một EC2 instance
Một t2.micro gắn Elastic IP. Chạy được, nhưng người dùng tăng thì nghẽn.
Bước 2 — Scale dọc
Nâng lên t2.large, rồi m5.large. Vấn đề: mỗi lần đổi kích cỡ phải stop instance → có downtime, và sớm muộn cũng chạm trần phần cứng.
Bước 3 — Scale ngang, mỗi máy một Elastic IP
Vấn đề: mỗi tài khoản mặc định chỉ có 5 Elastic IP, và người dùng phải tự biết gọi vào IP nào.
Bước 4 — Thêm Route 53
Dùng A record trỏ tới các instance. Vấn đề: khi một instance bị xóa, người dùng vẫn giữ IP cũ trong bộ nhớ đệm cho tới khi hết TTL — nghĩa là lỗi kéo dài hàng giờ.
Bước 5 — Thêm Load Balancer
ELB có health check nên tự loại máy chết. Route 53 dùng Alias record trỏ vào ELB. Instance chuyển sang private, chỉ ELB gọi vào được nhờ Security Group tham chiếu nhau. Vì ứng dụng stateless nên không cần sticky session.
Bước 6 — Thêm Auto Scaling Group, trải nhiều AZ
ASG tự thêm bớt máy theo tải, và trải qua ít nhất 2 AZ để chịu được sự cố một AZ.
ASG có minimum capacity = 2 để luôn sẵn sàng cao. Nghĩa là hai máy đó chạy suốt năm không bao giờ tắt → mua Reserved Instances cho đúng hai máy này, phần scale thêm ở giờ cao điểm để On-Demand. Đây chính là câu hỏi đầu tiên trong quiz gốc.
Hạ min capacity xuống 1 → mất tính sẵn sàng cao.
Hạ xuống 0 → website có lúc không còn máy nào, downtime.
Bỏ ELB dùng Elastic IP → mất luôn khả năng scale và health check.
MyClothes.com — ứng dụng có state
Website mua sắm. Khác biệt so với câu chuyện trước: giỏ hàng phải được nhớ qua nhiều request, và dữ liệu người dùng phải lưu lâu dài.
Vấn đề 1 — Mất giỏ hàng
Người dùng thêm hàng vào giỏ, request tiếp theo rơi sang instance khác, giỏ hàng trống trơn. Có ba cách giải, và đề thi hỏi cả ba:
| Cách | Cơ chế | Đánh đổi |
|---|---|---|
| ELB Sticky Sessions | Ép người dùng luôn về đúng một instance | Dễ nhất, nhưng gây mất cân bằng tải và mất session khi instance chết |
| Lưu session trong cookie của client | Trình duyệt gửi kèm toàn bộ dữ liệu session mỗi request → server hoàn toàn stateless | Cookie giới hạn dưới 4 KB; client sửa được nên phải kiểm tra dữ liệu; mỗi request nặng thêm |
| Session trong ElastiCache | Cookie chỉ chứa session_id, dữ liệu thật nằm trong Redis | An toàn và nhanh nhất; DynamoDB cũng dùng được |
"Cách nào KHÔNG giúp thiết kế tầng ứng dụng stateless?" → Lưu session trên EBS volume. Lý do: EBS gắn với một AZ và mỗi lúc chỉ gắn được một instance, nên các máy khác không đọc được. Ba phương án còn lại (RDS, ElastiCache, cookie) đều chia sẻ được.
Vấn đề 2 — Lưu dữ liệu người dùng lâu dài
Hồ sơ, địa chỉ, lịch sử đơn hàng → RDS. Đây là dữ liệu quan hệ, cần bền vững, khác hẳn session vốn tạm thời.
Vấn đề 3 — Quá nhiều lượt đọc
Hai công cụ đã học ở Section 9, dùng kết hợp:
- RDS Read Replicas — tách tải đọc sang bản sao
- ElastiCache theo mẫu Lazy Loading — cache kết quả truy vấn, chỉ hỏi database khi cache miss
Vấn đề 4 — Sẵn sàng cao ở mọi tầng
Multi-AZ cho toàn bộ: ELB, ASG, RDS Multi-AZ, ElastiCache Multi-AZ. Một tầng còn nằm trong một AZ là cả hệ thống vẫn có điểm chết duy nhất.
Bảo mật bằng Security Group tham chiếu nhau
Internet → SG-ALB (mở 443 cho 0.0.0.0/0)
→ SG-EC2 (mở 80 chỉ từ SG-ALB)
→ SG-RDS (mở 3306 chỉ từ SG-EC2)
→ SG-CACHE (mở 6379 chỉ từ SG-EC2)Chuỗi này là mô hình chuẩn: không tầng nào mở thẳng ra Internet trừ load balancer, và thêm máy mới không phải sửa rule nào.
Một sàn thương mại điện tử Việt Nam từng gặp đúng chuỗi này khi lên 10 máy: đầu tiên bật sticky session cho nhanh, nhưng dịp sale thì vài máy quá tải trong khi máy khác rảnh — vì khách mua nhiều bị "dính" vào cùng một máy. Chuyển session sang ElastiCache Redis là hết: tải chia đều, và khi ASG tắt bớt máy lúc đêm cũng không ai bị đăng xuất.
MyWordPress.com — file dùng chung
Website WordPress mở rộng toàn cầu. Hai nhu cầu: database MySQL và lưu ảnh người dùng upload.
Tầng database
- Bắt đầu: RDS MySQL Multi-AZ
- Lớn hơn: chuyển sang Aurora MySQL Multi-AZ để có hiệu năng và read replica tốt hơn
- Toàn cầu: thêm Aurora Global Database để giảm độ trễ ở các châu lục khác
Tầng lưu ảnh — vấn đề cốt lõi của câu chuyện này
| EBS | EFS | |
|---|---|---|
| Số instance truy cập | Một (trừ Multi-Attach io1/io2, cùng AZ) | Hàng trăm, nhiều AZ |
| Kết quả với WordPress | Khách upload ảnh vào máy 1, request sau vào máy 2 → ảnh 404 | Mọi máy thấy cùng một thư mục → hoạt động đúng |
Cách triển khai: mỗi EC2 instance mount EFS qua ENI của nó, trỏ thư mục /wp-content/uploads vào EFS.
"Cần cài bản cập nhật phần mềm lên hàng trăm EC2 Linux, lưu trên bộ nhớ dùng chung, nạp động, không muốn thao tác nặng nề" → EFS, mount như một ổ mạng lúc khởi động. EBS phải nhân bản thủ công từng AZ; snapshot thì phải tạo volume mới cho mỗi bản cập nhật; RDS thì dành cho dữ liệu quan hệ chứ không phải file nhị phân lớn.
Khởi tạo ứng dụng thật nhanh
Khi Auto Scaling sinh máy mới lúc traffic tăng vọt, tốc độ sẵn sàng của instance là vấn đề sống còn. Có ba cách, và đề thi phân biệt rất rõ.
| Cách | Làm gì | Hợp khi |
|---|---|---|
| Golden AMI | Cài sẵn ứng dụng, thư viện, cấu hình, công cụ → chụp thành AMI | Cài đặt lâu (nhiều phút tới hàng giờ) |
| Bootstrap bằng User Data | Script chạy lúc boot đầu tiên để cài và cấu hình | Cấu hình động, thay đổi thường xuyên, nhẹ |
| Kết hợp cả hai (hybrid) | AMI chứa phần nặng, User Data lo phần riêng của từng môi trường | Cách Elastic Beanstalk đang dùng |
Phần mềm mất hơn một tiếng để cài. Nếu dùng User Data, mỗi máy mới vẫn phải chờ đủ một tiếng — không giải quyết được gì. Chỉ Golden AMI mới rút thời gian xuống còn vài chục giây. Đây là hai câu riêng biệt trong quiz gốc.
Áp dụng cho các dịch vụ khác
| Dịch vụ | Cách khởi tạo nhanh |
|---|---|
| RDS | Khôi phục từ snapshot — schema và dữ liệu đã sẵn |
| EBS | Khôi phục từ snapshot — đĩa đã format và có dữ liệu |
Một hệ thống ERP mất 70 phút để cài trên Linux. Đội vận hành ban đầu để toàn bộ trong User Data, kết quả là mỗi lần ASG scale out lúc cao điểm thì máy mới chỉ kịp phục vụ sau khi đợt tải đã đi qua. Chuyển sang dựng Golden AMI hàng tháng: instance mới sẵn sàng sau khoảng 90 giây, và cooldown của ASG cũng hạ được theo. Phần cấu hình riêng theo môi trường (chuỗi kết nối, biến môi trường) vẫn để trong User Data — đúng mô hình hybrid.
Elastic Beanstalk
Sau ba câu chuyện trên, bạn thấy các kiến trúc lặp đi lặp lại: ALB + ASG + EC2 + RDS. Beanstalk đóng gói toàn bộ mô hình đó thành một dịch vụ.
Định nghĩa: góc nhìn dành cho lập trình viên về việc triển khai ứng dụng lên AWS. Bên dưới nó vẫn dùng đúng những dịch vụ bạn đã học, nhưng AWS lo hết phần vận hành.
| Beanstalk lo | Bạn lo |
|---|---|
| Cấp phát công suất, load balancing, auto scaling | Chỉ mã nguồn ứng dụng |
| Cấu hình instance và hệ điều hành | |
| Giám sát sức khỏe ứng dụng, chiến lược deploy |
Beanstalk là dịch vụ miễn phí — bạn chỉ trả tiền cho tài nguyên bên dưới (EC2, ELB, RDS…). Giống ASG.
Ba thành phần
- Application — dự án tổng thể
- Application Version — mỗi lần deploy tạo một phiên bản, và rollback về phiên bản cũ được
- Environment — dev, test, prod… tự do đặt tên; đẩy một version từ môi trường này sang môi trường kế tiếp
Hai kiểu môi trường
| Web Server Tier | Worker Tier | |
|---|---|---|
| Thành phần | ALB + ASG chạy EC2 | SQS queue + EC2 xử lý message |
| Phục vụ | Request HTTP từ người dùng | Tác vụ nền chạy lâu |
| Scale theo | Traffic | Số message trong queue |
Mô hình phổ biến: web tier nhận yêu cầu rồi đẩy message sang worker tier để xử lý những việc nặng như encode video hay xuất báo cáo.
Hai deployment mode — điểm ra thi
| Single Instance | High Availability with Load Balancer | |
|---|---|---|
| Thành phần | 1 EC2 + 1 Elastic IP, ASG min=max=desired=1, một AZ | ALB + ASG trải nhiều AZ, RDS Multi-AZ |
| Dùng cho | Môi trường phát triển — rẻ nhất | Production |
"Đang phát triển ứng dụng, muốn deploy lên Beanstalk với chi phí tối thiểu" → Single Instance Mode, vì nó chỉ tạo một EC2 và một Elastic IP. High Availability Mode tạo thêm load balancer nên đắt hơn.
Nền tảng được hỗ trợ
Go, Java SE, Java với Tomcat, .NET (Linux và Windows Server), Node.js, PHP, Python, Ruby, Docker (single container, multi-container, preconfigured), Packer Builder.
Deploy lên Beanstalk chậm bất thường, xem log thấy các thư viện phụ thuộc được tải và cài lại trên từng instance mỗi lần deploy. Cách chữa gọn nhất: dựng Golden AMI đã chứa sẵn dependencies rồi cho Beanstalk launch instance từ image đó — thời gian deploy giảm mạnh mà không phải động vào code. Đưa dependencies lên EFS cũng "chạy được" nhưng thêm độ trễ mạng và một điểm phụ thuộc mới.
Map từ khóa & cheat sheet
| Đề nhắc đến… | Nghĩ ngay tới |
|---|---|
| "phần mềm mất hàng giờ để cài, scale-out chậm" | Golden AMI |
| "deploy chậm vì dependencies cài lại mỗi lần" | Golden AMI chứa sẵn dependencies |
| "file dùng chung cho hàng trăm EC2 Linux" | EFS |
| "session data, muốn stateless" | ElastiCache · DynamoDB · cookie — không phải EBS |
| "ASG min capacity chạy suốt, giảm chi phí" | Reserved Instances cho đúng số máy nền |
| "môi trường dev trên Beanstalk, rẻ nhất" | Single Instance Mode |
| "xử lý tác vụ nền theo hàng đợi trên Beanstalk" | Worker Environment (SQS) |
| "người dùng mất giỏ hàng khi chuyển trang" | Sticky session (nhanh) hoặc ElastiCache (đúng) |
| "cookie lưu session" | Nhớ giới hạn dưới 4 KB và phải kiểm tra dữ liệu |
| "instance mới cần cấu hình động theo môi trường" | EC2 User Data |
| "khởi tạo nhanh RDS hoặc EBS" | Khôi phục từ snapshot |
Cheat sheet 60 giây
- Mạch tiến hóa: 1 EC2 → scale dọc → scale ngang → Route 53 → ELB → ASG → Multi-AZ → Reserved cho phần nền.
- Stateless dễ scale nhất. Có state thì đưa state ra ngoài: ElastiCache, DynamoDB, RDS, hoặc cookie.
- EBS không dùng để chia sẻ session — một AZ, một instance.
- Nhiều máy cần chung file → EFS. Một máy → EBS.
- Cài lâu → Golden AMI. Cấu hình động → User Data. Thực tế → kết hợp cả hai.
- Security Group tham chiếu nhau: ALB → EC2 → RDS/Cache, không tầng nào mở ra Internet.
- Beanstalk: miễn phí, ba thành phần Application / Version / Environment, có rollback.
- Beanstalk mode: Single Instance (dev, rẻ) vs HA with Load Balancer (prod).
- Beanstalk tier: Web Server (ALB + ASG) vs Worker (SQS, scale theo số message).
Năm câu tự kiểm tra trước khi qua file quiz
1. ASG có min capacity = 2 chạy quanh năm. Cách giảm chi phí mà vẫn giữ HA?
2. Cách nào KHÔNG giúp làm tầng ứng dụng stateless?
3. Phần mềm cài mất 1 tiếng, scale-out quá chậm. Làm sao?
4. 200 EC2 Linux cần đọc chung một kho bản cập nhật. Dùng gì?
5. Deploy Beanstalk cho môi trường dev, ưu tiên chi phí. Chọn mode nào?
Đáp án: (1) Mua Reserved Instances cho đúng 2 máy nền — hạ min capacity xuống 1 hay 0 đều phá vỡ yêu cầu HA. (2) Lưu session trên EBS volume — EBS khóa theo AZ và chỉ gắn một instance. (3) Golden AMI; User Data không giúp vì vẫn phải chờ đủ một tiếng. (4) EFS — mount như ổ mạng lúc khởi động. (5) Single Instance Mode — chỉ một EC2 và một Elastic IP, không tốn tiền load balancer.