Tweet
Kiến trúc giải pháp aws
🌟 KIẾN TRÚC GIẢI PHÁP AWS
🚀 TƯ DUY QUAN TRỌNG NHẤT KHI HỌC AWS
Học AWS không phải chỉ nhớ từng dịch vụ, mà là biết cách ghép chúng thành một hệ thống hoàn chỉnh, giống như khi bạn xây một ngôi nhà:
Solution Architect trên AWS chính là người làm việc đó.
📌 Chính vì vậy, phần kiến trúc trong file này cực kỳ quan trọng, vì nó cho bạn thấy cách AWS “suy nghĩ” khi xây hệ thống.
🟢 KIẾN TRÚC 1: ỨNG DỤNG ĐƠN GIẢN – “WhatIsTheTime.com”
👉 Ứng dụng này chỉ trả lời câu hỏi “Bây giờ là mấy giờ?”
❌ Không có database
❌ Không cần lưu thông tin người dùng
➡ Nghĩa là stateless (không phụ thuộc dữ liệu lưu lại trên server)
🧩 Giai đoạn 1 – Cách đơn giản nhất
Bạn chỉ cần:
➡ 1 máy chủ EC2 chạy web
➡ Gán Elastic IP để người dùng truy cập được
=> Khởi chạy được ngay.
Nhược điểm:
⚠ Nếu cần nâng cấp server → phải tắt ứng dụng → người dùng mất truy cập
➡ Có downtime
🧩 Giai đoạn 2 – Scale theo chiều dọc (Vertical Scaling)
Bạn thay máy nhỏ → máy lớn hơn
Ví dụ: từ t2.micro → m5.large
Giống như đổi xe máy sang ô tô vậy.
⚠ Vẫn phải dừng dịch vụ khi nâng cấp
➡ Người dùng không truy cập được trong lúc chuyển đổi
🧩 Giai đoạn 3 – Scale theo chiều ngang (Horizontal Scaling)
👉 Bạn không nâng cấp server nữa, mà chạy nhiều server cùng lúc
→ 2 máy trả lời nhanh hơn 1 máy
→ 10 máy chịu tải tốt hơn 2 máy
⚠ Nhưng sẽ phát sinh vấn đề:
Giống như lễ tân đứng trước tòa nhà, ai đi vào thì lễ tân đưa đến văn phòng còn trống.
➡ Load Balancer tự kiểm tra server nào khỏe, server nào chết
➡ DNS chỉ trỏ về Load Balancer (vì vậy không sợ server “biến mất”)
🧩 Giai đoạn 5 – Auto Scaling Group
🔥 Đây là mảnh ghép giúp ứng dụng “TỰ LỚN LÊN KHI CÓ NGƯỜI XEM”
→ Khi traffic tăng, Auto Scaling tự chạy thêm EC2
→ Khi traffic ít, tự thu nhỏ, giảm tiền
➡ Load Balancer + Auto Scaling = hệ thống không bao giờ “quá tải”
🧩 Giai đoạn 6 – Multi-AZ (Chống sập hệ thống)
Bạn chạy server ở nhiều khu vực (AZ) khác nhau.
👉 Nếu 1 trung tâm dữ liệu bị cháy, bị lỗi điện, bị đứt cáp → DỊCH VỤ VẪN CHẠY
➡ Vì AZ khác vẫn còn sống
Đây là sự khác biệt giữa ứng dụng “chạy chơi” và ứng dụng “kiếm tiền”.
🟠 KIẾN TRÚC 2: ỨNG DỤNG CÓ TRẠNG THÁI – “MyClothes.com”
👉 Đây là website bán hàng thật sự
❗ Người dùng có giỏ hàng → không được mất
❗ Người dùng đăng nhập → phải giữ session
❗ Phải có Database lưu thông tin khách hàng
📌 Đây là kiến trúc mọi thương mại điện tử đều gặp phải
🎯 Bài toán khó: Session lưu ở đâu?
❌ Lưu session trong EC2
→ Khi server bị xóa, session mất ❌ Lưu session trong cookie
→ Dễ bị sửa, giới hạn 4KB
→ Không an toàn nếu không mã hóa ✅ Giải pháp chuẩn AWS: Redis / ElastiCache
🔥 => Web trở thành stateless, nhưng vẫn giữ trải nghiệm người dùng
🏦 Database – phải có RDS
Dữ liệu user, đơn hàng → lưu trong Amazon RDS
➡ Multi-AZ để phòng sự cố
➡ Read Replica để tăng tốc truy vấn đọc
➡ Caching bằng Redis để giảm tải Database
🔐 Bảo mật – Security Group
🔵 KIẾN TRÚC 3: WEBSITE WORDPRESS – “MyWordPress.com”
📌 Vấn đề lớn nhất: Lưu ảnh upload
❌ Nếu bạn dùng EBS → nó chỉ gắn được vào 1 máy
➡ Scale ra 2 máy = HỎNG
✔ AWS sử dụng EFS → ổ đĩa dùng chung nhiều máy cùng lúc
➡ Upload ảnh ở máy A → máy B nhìn thấy ngay
🔥 KHỞI TẠO ỨNG DỤNG NHANH (RẤT QUAN TRỌNG)
👉 AWS dạy bạn cách làm devops đúng chuẩn, không tự cài tất cả mọi thứ bằng tay 3 cách nhanh:
1️⃣ Golden AMI – tạo bản EC2 đã cài sẵn ứng dụng → launch là chạy
2️⃣ User Data – script tự cài khi boot
3️⃣ Snapshot Restore – tạo DB / EBS sẵn dữ liệu ngay lập tức
🟣 ELASTIC BEANSTALK – CODE LÀ CHẠY
➡ Dành cho DEV không muốn quản EC2, LB, Auto Scaling
Bạn chỉ:
✔ Upload code
✔ Chọn môi trường
➡ AWS tự dựng full stack (EC2, ALB, ASG…)
💡 Nhưng bạn vẫn chỉnh sửa cấu hình nếu cần
💡 BẠN RÚT RA ĐƯỢC GÌ?
AWS không chỉ là “học từng service”
💥 Mà là học cách TRỞ THÀNH KIẾN TRÚC SƯ ĐÁM MÂY:
🚀 TƯ DUY QUAN TRỌNG NHẤT KHI HỌC AWS
Học AWS không phải chỉ nhớ từng dịch vụ, mà là biết cách ghép chúng thành một hệ thống hoàn chỉnh, giống như khi bạn xây một ngôi nhà:
- Bạn phải biết cái gì cần xây trước,
- Chọn vật liệu nào phù hợp,
- Chuẩn bị phòng khi mưa gió hoặc hỏng hóc,
- Và biết cách mở rộng khi có nhiều người đến ở hơn.
Solution Architect trên AWS chính là người làm việc đó.
📌 Chính vì vậy, phần kiến trúc trong file này cực kỳ quan trọng, vì nó cho bạn thấy cách AWS “suy nghĩ” khi xây hệ thống.
🟢 KIẾN TRÚC 1: ỨNG DỤNG ĐƠN GIẢN – “WhatIsTheTime.com”
👉 Ứng dụng này chỉ trả lời câu hỏi “Bây giờ là mấy giờ?”
❌ Không có database
❌ Không cần lưu thông tin người dùng
➡ Nghĩa là stateless (không phụ thuộc dữ liệu lưu lại trên server)
🧩 Giai đoạn 1 – Cách đơn giản nhất
Bạn chỉ cần:
➡ 1 máy chủ EC2 chạy web
➡ Gán Elastic IP để người dùng truy cập được
=> Khởi chạy được ngay.
Nhược điểm:
⚠ Nếu cần nâng cấp server → phải tắt ứng dụng → người dùng mất truy cập
➡ Có downtime
🧩 Giai đoạn 2 – Scale theo chiều dọc (Vertical Scaling)
Bạn thay máy nhỏ → máy lớn hơn
Ví dụ: từ t2.micro → m5.large
Giống như đổi xe máy sang ô tô vậy.
⚠ Vẫn phải dừng dịch vụ khi nâng cấp
➡ Người dùng không truy cập được trong lúc chuyển đổi
🧩 Giai đoạn 3 – Scale theo chiều ngang (Horizontal Scaling)
👉 Bạn không nâng cấp server nữa, mà chạy nhiều server cùng lúc
→ 2 máy trả lời nhanh hơn 1 máy
→ 10 máy chịu tải tốt hơn 2 máy
⚠ Nhưng sẽ phát sinh vấn đề:
- Máy nào trả lời user?
- Máy vừa bị xóa, nhưng DNS vẫn trỏ vào nó?
=> User gặp lỗi “server không tồn tại” (vì DNS TTL chưa cập nhật)
Giống như lễ tân đứng trước tòa nhà, ai đi vào thì lễ tân đưa đến văn phòng còn trống.
➡ Load Balancer tự kiểm tra server nào khỏe, server nào chết
➡ DNS chỉ trỏ về Load Balancer (vì vậy không sợ server “biến mất”)
🧩 Giai đoạn 5 – Auto Scaling Group
🔥 Đây là mảnh ghép giúp ứng dụng “TỰ LỚN LÊN KHI CÓ NGƯỜI XEM”
→ Khi traffic tăng, Auto Scaling tự chạy thêm EC2
→ Khi traffic ít, tự thu nhỏ, giảm tiền
➡ Load Balancer + Auto Scaling = hệ thống không bao giờ “quá tải”
🧩 Giai đoạn 6 – Multi-AZ (Chống sập hệ thống)
Bạn chạy server ở nhiều khu vực (AZ) khác nhau.
👉 Nếu 1 trung tâm dữ liệu bị cháy, bị lỗi điện, bị đứt cáp → DỊCH VỤ VẪN CHẠY
➡ Vì AZ khác vẫn còn sống
Đây là sự khác biệt giữa ứng dụng “chạy chơi” và ứng dụng “kiếm tiền”.
🟠 KIẾN TRÚC 2: ỨNG DỤNG CÓ TRẠNG THÁI – “MyClothes.com”
👉 Đây là website bán hàng thật sự
❗ Người dùng có giỏ hàng → không được mất
❗ Người dùng đăng nhập → phải giữ session
❗ Phải có Database lưu thông tin khách hàng
📌 Đây là kiến trúc mọi thương mại điện tử đều gặp phải
🎯 Bài toán khó: Session lưu ở đâu?
❌ Lưu session trong EC2
→ Khi server bị xóa, session mất ❌ Lưu session trong cookie
→ Dễ bị sửa, giới hạn 4KB
→ Không an toàn nếu không mã hóa ✅ Giải pháp chuẩn AWS: Redis / ElastiCache
- Web chỉ lưu “session_id”
- Dữ liệu thật lưu trong Redis
- Bất kỳ EC2 nào cũng truy cập được session
🔥 => Web trở thành stateless, nhưng vẫn giữ trải nghiệm người dùng
🏦 Database – phải có RDS
Dữ liệu user, đơn hàng → lưu trong Amazon RDS
➡ Multi-AZ để phòng sự cố
➡ Read Replica để tăng tốc truy vấn đọc
➡ Caching bằng Redis để giảm tải Database
🔐 Bảo mật – Security Group
- Chỉ EC2 được phép nói chuyện với RDS & Redis
- Internet chỉ truy cập Load Balancer
➡ Một lớp bảo vệ VÔ CÙNG QUAN TRỌNG mà nhiều bạn mới bỏ qua
🔵 KIẾN TRÚC 3: WEBSITE WORDPRESS – “MyWordPress.com”
📌 Vấn đề lớn nhất: Lưu ảnh upload
❌ Nếu bạn dùng EBS → nó chỉ gắn được vào 1 máy
➡ Scale ra 2 máy = HỎNG
✔ AWS sử dụng EFS → ổ đĩa dùng chung nhiều máy cùng lúc
➡ Upload ảnh ở máy A → máy B nhìn thấy ngay
🔥 KHỞI TẠO ỨNG DỤNG NHANH (RẤT QUAN TRỌNG)
👉 AWS dạy bạn cách làm devops đúng chuẩn, không tự cài tất cả mọi thứ bằng tay 3 cách nhanh:
1️⃣ Golden AMI – tạo bản EC2 đã cài sẵn ứng dụng → launch là chạy
2️⃣ User Data – script tự cài khi boot
3️⃣ Snapshot Restore – tạo DB / EBS sẵn dữ liệu ngay lập tức
🟣 ELASTIC BEANSTALK – CODE LÀ CHẠY
➡ Dành cho DEV không muốn quản EC2, LB, Auto Scaling
Bạn chỉ:
✔ Upload code
✔ Chọn môi trường
➡ AWS tự dựng full stack (EC2, ALB, ASG…)
💡 Nhưng bạn vẫn chỉnh sửa cấu hình nếu cần
💡 BẠN RÚT RA ĐƯỢC GÌ?
AWS không chỉ là “học từng service”
💥 Mà là học cách TRỞ THÀNH KIẾN TRÚC SƯ ĐÁM MÂY:
- App có trạng thái hay không?
- Scale ngang hay dọc?
- Đặt session ở đâu?
- DB chống lỗi thế nào?
- Tối ưu chi phí ra sao?