+2
Mọi người cho em hỏi về vấn đề scale server với ứng dụng Laravel với ạ
Tự dưng ngồi nghĩ ra 1 vấn đề trong quá khứ, rất mong được sự giúp đỡ của mọi người ạ
Vấn đề:
Em deploy ứng dụng Laravel lên 1 máy chủ EC2(máy chủ chính)
Trên máy chủ đó em có chạy một số cronjob và Laravel queue dùng cho việc gửi mail và 1 số tác vụ khác.
Sau đó e cần scale thêm N máy chủ EC2 nữa để sử dụng Load Balancer
Nếu em tiến hành clone N máy chủ từ máy chủ chính, thì các crontab và queue đồng thời đc chạy trên nhiều server. Dẫn tới việc gửi mail, ... có thể diễn ra đồng thời ở N server kia.
Cách làm của em là: Tạo ra thêm 1 Image Ec2 mà ko có chạy các queue, cronjob kia để dùng trong auto scale. Nói cách khác là làm cách nào đó để chỉ có 1 máy có chứa các tác vụ crontab và queue.
Ắt hẳn sẽ có cách tốt hơn, mong mọi người chỉ giúp em ạ. Cảm ơn mọi người.
Thêm một bình luận
3 CÂU TRẢ LỜI
+2
Hướng bạn làm như vậy mình nghĩ là ổn đó. Bạn nên scale riêng từng loại:
- Web cần nhiều thì scale thêm nhiều process hoặc thêm server chạy web (fpm only, không queue, cron)
- Nếu chỉ chạy queue ở server ban đầu mà bạn thấy không đáp ứng được thì scale tiếp queue:
- Tăng process của worker lên
- Tăng số worker lên, chia nhỏ thành nhiều queue riêng biệt như queue cho mails, default... -> chia queue thì code cũng phải sửa để chỉ định dispatch job vào từng queue cụ thể.
Có thể là còn nhiều giải pháp nữa nhưng ở trên là những giải pháp đơn giản nhất để bạn scale Laravel mà mình vừa note ra. Bạn tham khảo nhé.
Thank Kim.
Mĩnh cái mình đã triển khai ở hệ thống cũ cũng gần giống 80% memo của bạn.
Chỉ là thấy vẫn phải phân tách ra 2 loại server là loại có chạy cron , queue và 1 loại không chạy.
Nên sợ có khả năng người maintain sau quên hay sao đó.
Nên đang tìm cách làm nó tốt lên thui 
@thanhnguyen Thường mình hay nhóm các service vào các lại cho đễ nhớ như: Server nào chạy database, cron, server nào làm storage. Tất cả các phần quản trị server thì luôn phải take note lại để transfer cho người mới thì lôi ra.
Còn vấn đề quên thì mình nghĩ là là do mindset và trách nhiệm của người quản trị, chứ solution có tốt bao nhiêu mà không take note lại thì vẫn vậy. Chưa kể càng scale thì độ phức tạp của infra structure càng cao hơn nữa.
Bên bạn làm theo hướng kia thì mình thấy khá ổn, ngoài ra việc chia thành từng queue riêng biệt cho một số chức năng thì bạn còn có thể dễ dàng chia tách queue sang nhiều server khác nhau chứ không phải chia queue xong rồi vẫn chỉ chạy trên 1 server 
Như vậy thì cũng ổn hơn.
Còn về cron, chạy trên một server mình nghĩ là không sao, vì khi chạy cron mình có thể bắn nó vào queue nữa Cron bạn cũng có thể tách nó ra thành nhiều cron chuyên biệt cho từng nhóm nhiệm vụ giống queue chẳng hạn nên với solution mình vẫn cảm thấy khá yên tâm.
+1
Có cách tốt hơn là dùng gộp nhiều máy chủ thành 1 cụm Nodes, phân phối tài nguyên đồng đều giữa các máy chủ đó. Bạn tham khảo thêm Kubernetes của Amazon đã cung cấp sẵn rồi đó Amazon Elastic Kubernetes Service (EKS). Nhanh gọn lẹ, mỗi tội hơi chát về giá. Cần có kiến thức devOps này khá chuyên sâu mới config được hệ thống bạn muốn.
Cảm ơn bạn.
Mình sẽ thử tìm hiểu xem, nhưng mình vẫn muốn tìm kiếm một giải pháp khác.
Ví dụ như thay Ec2 thày VPS.
Thì không biết sẽ xử lý thế nào
0
Đơn giản là đặt thêm config trong env là có chạy crawl ko. Code check config đó là ok. Khi triển khai node mới thì sẽ set config true/false là xong
