Bài viết thuộc series: Xây dựng hạ tầng phục vụ hàng triệu người dùng trên AWS
Giới thiệu
Ở bài trước chúng ta đã xây dựng một hạ tầng đơn giản để phục vụ hàm trăm người dùng. Ở bài này chúng ta tìm hiểu cách mở rộng hạ tầng đơn giản đó ra để có thể phục vụ được hàng ngàn tời hàng chục ngàn người dùng.
Hướng dẫn tạo lại hạ tầng ở bài trước
Hạ tầng ta đã tạo ở bài trước.
Các bạn có thể xem lại bài 0 để tạo lại hạ tầng trước đó, hoặc theo hướng dẫn của mình ở bài này là dùng Terraform, sử dụng Terraform sẽ nhanh hơn nhiều. Các bạn tìm hiểu Terraform ở bài này: Bài 0 - Infrastructure as Code và Terraform.
Các bạn tải code ở đây Million Users. Di chuyển tới thư mục 01 và chạy câu lệnh terraform.
terraform init && terraform applyTerraform sẽ bắt bạn nhập vào hai giá trị là S3 Bucket và AWS Key Pair (tên của key pair các bạn tạo ở bài trước), các bạn nhập vào giá trị Key Pair cho đúng, còn S3 Bucket các bạn nhập gì cũng được.
var.ec2_keypair
Enter a value: devopsvn
var.s3_bucket_name
Enter a value: devopsvnSau khi chạy xong bạn sẽ thấy kết quả sau được in ra Terminal.
database = {
"endpoint" = "mysql-cluster.cluster-cz2tvtl6lcep.ap-southeast-1.rds.amazonaws.com"
"name" = "devopsvn"
"password" = "devopsvn"
"username" = "devopsvn"
}
wordpress = {
"wordpress" = "13.250.18.77"
}Truy cập địa chỉ 13.250.18.77 ở trên trình duyệt và làm theo hướng dẫn để cấu hình cho WordPress. Cuối cùng làm theo hướng dẫn Kết nối WordPress với S3 bucket như ta đã làm ở bài trước. Vậy là ta đã xây dựng xong hạ tầng ở bài trước.
Tiếp theo ta sẽ mở rộng hạ tầng ở trên để nó có thể phục vụ hàng ngàn người dùng, hình minh họa.
Hạ tầng bao gồm:
- AWS Application Load Balancer
- Auto-Scaling Group
- AWS RDS
- AWS S3
Mở rộng hạ tầng
Trong vấn đề mở rộng thì ta có hai phương pháp là Vertical Scaling và Horizontal Scaling. Ta sẽ không đi sâu về lý thuyết, định nghĩa Vertical Scaling và Horizontal Scaling như sau:
- Vertical Scaling: mở rộng bằng cách thêm sức mạnh cho một Workload (máy chủ hoặc database) trong hệ thống, ví dụ như CPU hoặc Memory
- Horizontal Scaling: mở rộng bằng cách thêm số lượng Workload trong hệ thống, ví dụ tăng gấp đôi số lượng máy chủ
Vertical Scaling phù hợp cho các ứng dụng có lưu trữ dữ liệu (stateful), Horizontal Scaling phù hợp cho các ứng dụng không có dữ liệu riêng (stateless). WordPress của ta là ứng dụng stateless vì nó không có lưu dữ liệu riêng, mà WordPress của ta dùng RDS để lưu trữ dữ liệu và S3 Bucket để lưu hình ảnh. Nên ta sẽ dùng phương pháp Horizontal Scaling để mở rộng EC2 WordPress phục vụ được cho hàng ngàn người dùng, quá trình như sau.
Ban đầu ta chỉ có một con EC2 WordPress, mọi thứ đều ổn nếu người dùng của ta tầm hàng trăm.
Nhưng khi số lượng người dùng của ta tăng lên hàng ngàn thì chỉ một con EC2 sẽ không thể xử lý nổi, nên ta cần mở rộng bằng cách thêm số lượng EC2.
Đây là cách ta thực hiện phương pháp Horizontal Scaling. Nếu ở dưới hệ thống on-premise việc này sẽ hơi khó làm một xíu, còn ở trên AWS thì việc này rất đơn giản với Autoscaling Group.
Để tạo được Autoscaling Group ta sẽ cần các thứ sau:
- Amazon Machine Images (AMI)
- AWS Launch Template
- Autoscaling Group
Amazon Machine Images
AMI sẽ giúp ta đóng gói EC2 thành một Image (tương tự như ta đóng gói ứng dụng thành Container Image), trong AMI sẽ chứa mọi thứ từ EC2 ta đã đóng gói và ta chỉ cần tạo EC2 mới từ AMI đó.
Ví dụ ở bài này ta sẽ đóng gói EC2 WordPress của ta thành AMI, sau đó ta chỉ cần tạo con EC2 mới từ AMI đó thì nó sẽ có mọi thứ ta cần, đây là một resource giúp ta dễ dàng hơn trong việc mở rộng hệ thống. Truy cập AWS EC2 Console ta sẽ thấy có một con EC2, ta sẽ tiến hành đóng gói nó thành AMI.
- Chọn EC2 WordPress
- Chọn Menu Action
- Chọn Image and templates -> Create image
- Mục Image name nhập vào WordPress
- Bấm Create image
Quay lại AWS EC2 Console, ở Menu bấm vào mục Images -> AMIs ta sẽ thấy AMI ta vừa tạo.
EC2 Launch Templates
Bước tiếp theo ta tạo Launch Templates để làm Templates cho Autoscaling Group.
- Truy cập AWS EC2 Console
- Chọn Instances -> Launch Templates
- Bấm Create launch template
- Mục Launch template name nhập vào WordPress
- Mục Launch template contents -> Application and OS Images (Amazon Machine Image) chọn My AMIs -> Owned by me, kiếm AMI tên là WordPress ta vừa tạo khi nãy
- Mục Instance type chọn
t3.small - Mục Key pair (login) chọn Key bạn đã tạo
- Mục Security Groups nếu bạn dùng Terraform thì chọn Select existing security group ->
access-ec2, còn không thì bạn bấm Create security group - Bấm Create
EC2 Auto Scaling Group
Cuối cùng ta tạo ASG từ Launch Templates ở trên. Toàn bộ EC2 được tạo từ ASG này đều giống với EC2 WordPress ban đầu của ta, có sẵn hết mọi thứ từ cấu hình WordPress, cấu hình kết nối tới Database và cấu hình kết nối tới S3.
Ta làm theo các bước sau:
- Truy cập AWS EC2 Console
- Chọn Auto Scaling -> Auto Scaling Groups
- Bấm Create Auto Scaling group
- Mục Auto Scaling group name nhập vào WordPress
- Mục Launch template chọn Launch Template ta vừa tạo là WordPress. Bấm Next
- Mục VPC chọn Default, mục Availability Zones and subnets chọn toàn bộ. Bấm Next
- Mục Load balancing chọn No load balancer. Bấm Next
- Mục Group size nhập vào
Desired capacity = 1, Minimum capacity = 1, Maximum capacity = 4, mục Scaling policies chọn Target tracking scaling policy nhập vào như hình bên dưới
Ở đây ta đang cấu hình là khi số lượng EC2 hiện tại chạy hơn 50% CPU thì ASG sẽ tự động tạo thêm EC2 mới.
- Bấm Skip to review, bấm Create Auto Scaling group
Bấm qua AWS EC2 Console ta sẽ thấy bây giờ có 2 con EC2, bấm vào con mới và lấy địa chỉ của nó dán lên trình duyệt.
Ta sẽ thấy nó hiển thị WordPress như con cũ, ta đã thành công. Các bạn nên thêm con cũ vào ASG luôn để ASG quản lý, bấm như hình bên dưới.
Chọn ASG là WordPress.
Bấm Attach. Bây giờ thì ta có nhiều con EC2 WordPress và mỗi con đều có IP khác nhau. Đây là lúc vấn đề xảy ra, vì người dùng của ta làm sao biết được họ cần truy cập vào con nào?
Ta giải quyết vấn đề này bằng cách sử dụng AWS Application Load Balancer.
AWS Application Load Balancer
AWS Application Load Balancer sẽ đóng vai trò như một Proxy để hứng request từ người dùng và chuyển nó tới từng con EC2 WordPress.
Đây là kiến trúc rất phổ biến trong thiết kế hệ thống. Ta làm theo các bước sau để tạo AWS ALB:
- Truy cập AWS EC2 Console
- Chọn Auto Scaling -> Auto Scaling Groups ta sẽ thấy ASG ta vừa tạo, bấm vào nó
- Kéo xuống mục Load balancing, bấm vào nút Edit
- Bấm Add a new load balancer
- Mục Load balancer type chọn Application Load Balancer
- Mục Load balancer scheme chọn Internet-facing
- Mục Listeners and routing -> Default routing (forward to) bấm Create a target group
- Bấm Update
Vậy là ta đã tạo xong AWS ALB, để xem URL của AWS ALB ta quay lại AWS EC2 Console, chọn Load Balancing -> Load Balancers ta sẽ thấy ALB ta vừa tạo.
Mục DNS name là URL của ALB, thay vì truy cập IP của EC2 thì ta sẽ truy cập URL của ALB. Dán địa chỉ của ALB lên trên trình duyệt ta sẽ thấy được trang WordPress, của mình là http://wordpress-1-835238640.ap-southeast-1.elb.amazonaws.com/.
Tuy nhiên ta sẽ không thể truy cập được trang admin, vì cấu hình Root URL của WordPress trong Database hiện tại đang là IP của con EC2 cũ, các bạn truy cập vào Database và sửa lại, ví dụ mình dùng Navicat, truy cập Table wp_options và sửa lại hai Rows siteurl và home.
Giờ thì ta đã truy cập được trang admin.
Kết luận
Vậy là ta đã tìm hiểu xong cách mở rộng kiến trúc hạ tầng để phục vụ cho hàng ngàn người dùng, kiến trúc bao gồm Load Balancer + Autoscaling Group + Database, đây là kiến trúc rất phổ biến trong thiết kế hệ thống. Và ta sẽ từ kiến trúc hạ tầng cơ bản này để mở rộng ra thành hạ tầng có thể phục vụ hàng chục ngàn người dùng ở bài tiếp theo.
Lưu ý: nhớ xóa resource bằng câu lệnh terraform destroy -auto-approve và ASG bằng tay, nếu không bạn sẽ mất tiền làm lab.
Tác giả @Quân Huỳnh
Nếu bài viết có gì sai hoặc cần cập nhật thì liên hệ Admin.
Tham gia nhóm chat của DevOps VN tại Telegram.
Kém tiếng Anh và cần nâng cao trình độ giao tiếp: Tại sao bạn học không hiệu quả?
Bài viết liên quan
