AWS #3 – Kinh nghiệm triển khai EC2

9 mins read
AWS Kinh nghiệm triển khai EC2
AWS Kinh nghiệm triển khai EC2

Trong phần trước, mình đã chia sẻ với mọi người những khó khăn khi team triển khai AWS, cùng những giải pháp mà team đưa ra để giải quyết vấn đề.

Tuy nhiên, nó vẫn chỉ là món "khai vị" cho loạt bài viết về AWS của mình. Mục đích mình viết những bài đó là để giúp mọi người chuẩn bị hành trang cho các kiến thức chuyên sâu về AWS mà mình sẽ chia sẻ. Chính vì thế, những ai chưa xem #1 và #2 về AWS thì hãy quay lại những bài trước đó nhé! Còn bây giờ, chúng ta hãy tiếp tục hành trình với AWS nào!

Đoạn đường hôm nay của chúng ta sẽ là EC2. Mình sẽ không "cầm tay chỉ việc" các bước để deploy EC2, vì trên mạng đã có rất nhiều rồi. Thay vào đó, mình sẽ chia sẻ các best practice về EC2 mà hiện tại team đang áp dụng. Nó là kinh nghiệm của team sau những lần thử sai, gây lãng phí thời gian và công sức của team.

Nào, hãy cùng bắt đầu nhé!

Lưu ý: Nội dung mình chia sẽ là kinh nghiệm hiện tại của team khi triển khai EC2. Nếu có những trải nghiệm mới, mình sẽ update bài viết để chia sẻ thêm. Vì vậy, bạn đừng ngỡ ngàng khi hiện tại mình chia sẽ 5 kinh nghiệm về triển khai EC2, mà sau này bạn quay lại sẽ thành 10 nhé!

1. Hãy dùng HĐH Linux

Mình đã từng mentor cho vài bạn newbies, và thấy vẫn có bạn sử dụng Windows làm HĐH (Hệ điều hành) cho server. Đây là sự lãng phí tài nguyên (trừ trường hợp bất khả kháng). Thay vào đó, bạn hãy sử dụng HĐH Linux như Ubuntu, CentOS thuần không GUI (Graphical user interface – Giao diện đồ họa người dùng). Hệ thống của bạn sẽ chạy nhanh hơn rất nhiều.

Linux vs Windows

Có nhiều nguyên nhân dẫn đến Linux nhanh hơn rất nhiều so với Windows, bạn có thể xem tại đây. Trong đó, khác biệt lớn nhất ta có thể phát hiện ra được là GUI. Trong khi Windows có hệ thống GUI đồ sộ để phục vụ user thì Linux lại không có (trừ khi bạn cài thêm). User chỉ có thể tương tác với hệ thống sử dụng Linux thông qua Terminal (Cửa sổ dòng lệnh). Chính vì thế, bạn sẽ có nhiều RAM và CPU hơn để chạy ứng dụng của mình.

Ngoài ra, khi bạn sử dụng Windows, bạn cần phải trả thêm tiền License. Các phía quản lý Cloud Server rất gắt vụ này, họ sẽ sẵn sàng thu hồi VPS nếu biết bạn xài Windows bản "chùa". Trong khi Linux là open source nên nó không tốn kém chi phí.

Theo mình thì trường hợp bắt buộc phải xài Windows thì mới nên xài.

2. Dùng nhiều EC2 cấu hình thấp, thay vì 1 EC2 cấu hình cao

Bạn đừng lạ khi lúc mình gọi server là EC2, lúc thì gọi là VPS nhé! Vì trong series AWS của mình, nó là một thôi! Tuỳ theo ngữ cảnh mà mình sẽ có cách gọi khác nhau.

Khi bạn muốn scale ứng dụng theo chiều ngang tốt hơn, mình khuyên bạn nên lựa chọn nhiều EC2 cấu hình thấp hơn, so với lựa chọn một EC2 cấu hình cao hơn trong cùng mức giá. Tuỳ thuộc vào loại ứng dụng của bạn mà sẽ có mức yêu cầu cấu hình tối thiểu. Tuy nhiên, bạn hãy nên lựa chọn cấu hình tối thiểu của server là từ 2 CPU trở lên.

Nhiều EC2 nhỏ vs Một EC2 lớn

Ví dụ như hệ thống bạn cần một EC2 có RAM 4 GB để chạy ứng dụng. Bạn đang hướng tới 1 con EC2 t3.medium có 2 CPU, RAM 4GB, giá là 0,0416 USD/giờ. Ổn đó, nhưng mà sẽ tốt hơn nếu bạn lựa chọn 2 con EC2 t3.small có 2 CPU, RAM 2GB, giá mỗi con là 0,0208 USD/giờ.

Nhìn chung thì giá của cả 2 lựa chọn đều giống nhau phải không nào? Nhưng cái khác biệt ở phương án 2 chính là hệ thống của bạn sẽ có tận 4 CPU để xử lý dữ liệu, thay vì chỉ 2 CPU như phương án 1. Mà càng nhiều CPU thì xử lý đa luồng càng tốt, nên hệ thống trong phương án 2 sẽ nhanh hơn rất nhiều so với phương án 1. Ngoài ra, với phương án 2, khi một server lăn đùng ra chết vì quá tải, thì bạn vẫn còn một server khác tiếp tục chạy và "chờ đợi" server còn lại "hồi sinh", chứ không phải là "ngủm sạch" như phương án 1.

3. Lựa chọn quốc gia theo môi trường hệ thống

Bảng giá EC2 theo quốc gia c5.large

Nếu bạn đã đọc qua AWS #2 – Khó khăn và giải pháp thì bạn sẽ hiểu tại sao mình lại khuyên như vậy. Trong bài viết trên, mình đã phân tích mức giá chênh lệch của EC2 giữa các quốc gia, đồng thời đưa ra một vài lời khuyên theo kinh nghiệm bản thân. Nhờ đó, bạn sẽ tiết kiệm được một khoản chi phí khổng lồ hàng tháng cho công ty!

4. Sử dụng EC2 Launch Template để tạo EC2

Có 2 cách để bạn tạo trực tiếp phiên bản EC2 (nghĩa là không thông qua quá trình auto scaling), đó là Launch Instances và Launch Templates.

Launch Instances có nghĩa là bạn sẽ triển khai EC2 theo từng bước, step by step như: Từ Lựa chọn cấu hình EC2, lựa chọn VPC dùng cho EC2, thiết lập tags… đến SSH vào EC2, cài đặt các môi trường cần thiết như docker, .NET, connect cluster…

EC2 Launch Template

Còn đối với Launch Template, bạn chỉ cần tạo sẵn một template, và bạn chỉ cần khởi chạy template là đủ. AWS sẽ giúp tự động hoá các quy trình phía trên cho bạn.

Tips: Khi khởi tạo một Instance EC2, bạn hãy điền các lệnh bash dùng khởi tạo môi trường vào phần thiết lập User Data (Có trong Launch Instance lẫn Launch Template). User Data nó giống như một file thực thi .sh vậy, nó sẽ được khởi chạy khi EC2 khởi động lần đầu tiên.

Nhờ đó, bạn sẽ tiết kiệm thời gian rất nhiều khi muốn triển khai một EC2 mới. Đồng thời, nó giúp bạn hạn chế những sai sót khi bạn triển khai bằng tay.

5. Thiết lập Elastic IP cho EC2

Khi bạn cho phép EC2 giao tiếp với mạng internet, thì EC2 đó sẽ được gán một IP, gọi là Public IP. Bạn có thể truy cập hoặc SSH vào EC2 đó thông qua IP này. Tuy nhiên, Public IP sẽ được thay đổi nếu như bạn reboot lại EC2.

Elastic IP

Ôi không, thật tệ hại nếu bạn trỏ các DNS vào Public IP này nhỉ? Lúc đó, client truy cập vào DNS sẽ nhận được lỗi 404. Bạn sẽ cần trỏ lại DNS đến IP mới để giải quyết sự cố.

Để giải quyết vấn đề trên, Elastic IP đã ra đời. Elastic IP chính là một public IP thứ 2 được gán vào EC2, nhưng nó là một IP tĩnh, không bị thay đổi mỗi khi EC2 bị reboot. Nhờ đó, bạn sẽ không còn lo lắng vấn đề public IP bị thay đổi mỗi lần reboot lại EC2 nữa!

Lưu ý: AWS có giới hạn 5 Elastic IP/account (có thể gia hạn thêm), và sẽ tính phí đối với các Elastic IP không sử dụng nhé.

Tổng kết

Trong bài viết này, mình đã chia sẻ với mọi người những kinh nghiệm khi triển khai EC2 của mình và của team. Mình hi vọng với những kiến thức này, bạn sẽ đỡ phải mất thời gian thử sai, gây lãng phí thời gian.

Ngoài ra, vì là kinh nghiệm bản thân nên sẽ có những yếu tố mang tính chủ quan trong đó, cũng như còn thiếu sót. Vì thế, mình rất vui khi nhận được sự đóng góp của các bạn, để cộng đồng người Việt sử dụng AWS phát triển hơn!