Trong phần 1, mình đã giải thích lý do tại sao EGANY chọn AWS làm Cloud Server, cũng như giới thiệu về các tài nguyên AWS mà team đang sử dụng.
Tuy nhiên, việc ứng dụng và triển khai một công nghệ mới thì chẳng có gì là suôn sẻ cả. Trong quá trình vận hành, team đã gặp phải một số vấn đề nhức nhối và gây tốn kém chi phí.
Chính vì thế, trong bài viết #2 này, mình sẽ chia sẻ về 3 Vấn Đề mà team đã gặp phải, cùng những hướng giải quyết. Từ đó, bạn có thể đỡ phải đi đường vòng hơn, giúp cho quá trình triển khai AWS trở nên dễ dàng và ít tốt kém hơn.
Khi bắt đầu một công nghệ mới, "không biết bắt đầu từ đâu" là điều mình nghĩ đa số mọi người sẽ gặp. Cũng như khi bạn là một front-end mới vào nghề, và phía designer đưa ra một bản thiết kế khủng. Khi đó, bạn sẽ phải khá đau đầu trong việc lựa chọn framework để thực hiện, lựa chọn thứ tự các component (thành phần) để code, và phải code đi code lại nhiều lần nếu bạn làm sai, để có thể đúng design.
AWS cũng vậy! Nếu bạn ví hệ thống của bạn quản lý là bản design, thì các service (dịch vụ) của AWS chính là các component để hoàn thành bản design đó!
Công việc của bạn sẽ là sử dụng các service của AWS để triển khai hệ thống, theo đúng công dụng của nó, và đúng theo một thứ tự. Nếu bạn triển khai sai một service nào đó, bạn sẽ cần phải triển khai lại service đó, hoặc thậm chí là các service liên quan sao cho đúng.
Để tìm ra một hướng đi đúng, team đã tiến hành thử sai cả tháng trời. Team đã phải nghiên cứu rất nhiều tài liệu, các best practice từ người đi trước, và thử sai. Bởi vì với mỗi case, hướng giải quyết sẽ khác nhau, mình không thể copy y nguyên cách làm của người khác được, mà mình cần phải mix từng chút một.
Có hai thứ mình nghĩ sẽ giúp ích được bạn trong giai đoạn bắt đầu mà mình muốn chia sẻ, đó là kinh nghiệm của bản thân mình, và nguồn tài liệu mà mình tìm đọc.
Playlist AWS trên Youtube
Là một admin của hệ thống, bạn không muốn hệ thống lăn đùng ra chết, hay database bị mất sạch dữ liệu vào một ngày "xấu trời" nọ vì lỗi của member phải không nào? Chính vì thế, phân quyền thành viên của AWS theo lĩnh vực, chức vụ luôn là điều cần được ưu tiên hàng đầu. Cho dù bạn nắm giữ tài khoản root, để login vào AWS thì bạn cũng cần tạo một tài khoản admin cho riêng mình để phòng tránh rủi ro tốt hơn.
Giao diện AWS IAM
Tuy nhiên, AWS lại có hàng trăm hàng ngàn IAM Policy với các chức năng khác nhau. Việc đọc hết các IAM là điều không khả thi, nên sẽ làm cho quá trình phân quyền diễn ra rất khó khăn.
Để giải quyết bài toán phân quyền này, không có cách nào khác là xem các kinh nghiệm từ người đi trước cả, gặp vấn đề gì, search vấn đề đó.
Tất nhiên là mình sẽ không "đem con bỏ chợ", nên mình sẽ chia sẻ với bạn cách mà mình phân quyền cho member trong team. Mình đã chia các thành viên trong team thành 4 nhóm người dùng chính:
AdministratorAccess. Họ sẽ là người nắm toàn quyền về hệ thống của công ty (trừ Billing). Bạn cần cực kì thận trọng khi add user vào group này.EC2, CloudWatch, S3. Họ sẽ là người phát triển, bảo trì, sửa lỗi ứng dụng mà họ code ra. Chính vì thế, họ cần phải có quyền truy cập xem logs, truy cập VPS và những thành phần liên quan, đảm bảo cho công việc của họ.Phân quyền cho Frontend
Khi sử dụng một nền tảng Cloud Server mới như AWS, cái team kì vọng chính là: "sự ổn định của hệ thống" và "chi phí hàng tháng".
Chính vì thế, sau một tháng triển khai các dịch vụ trên, team mình đã ngồi để đánh giá lại kết quả.
Mọi thứ diễn ra quá ổn, hệ thống không gặp tình trạng quá tải và lăn đùng ra chết, kết nối giữa các máy chủ rất ổn định. Chỉ có điều AWS đã charge 3000$/tháng cho hoá đơn của công ty. Số tiền này quá cao so với dự kiến ban đầu của team.
Có nhiều nguyên nhân xảy ra vấn đề trên. Tuy nhiên, mình xin chia sẽ với các bạn 2 nguyên nhân chính, đó là: "triển khai EC2 ở quốc gia có chi phí cao" và "sử dụng CloudWatch quá nhiều".
Thông thường, trong một hệ thống của công ty sẽ chia làm 3 môi trường: dev, staging và production. Trong đó, dev và staging dành cho nội bộ công ty, và production dành cho khách hàng.
Production là môi trường dành cho khách hàng. Chính vì thế, team cần dành những gì tốt nhất cho production, bao gồm số lượng máy chủ, tài nguyên phần cứng… và quốc gia của máy chủ (ảnh hưởng đến latency – độ trễ của hệ thống). Với lượng user của EGANY đến từ Việt Nam, team cần phải sử dụng một máy chủ gần Việt Nam để giảm latency, và team đã chọn Singapore.
Tuy nhiên, chi phí server tại Singapore lại cao hơn khoảng 1/4 lần so với server tại Hoa Kì. Ví dụ như 5 con server c5.large (cấu hình 2 CPU, 4GB RAM) tại Singapore sẽ có giá là 425.76$/tháng, trong khi ở Oregon (Hoa Kỳ) chỉ có giá là 374.8$/tháng thôi.
Bảng so sánh giá 5 con EC2 c5.large giữa các quốc gia
Nhưng, đối với môi trường dev và staging (dành cho nội bộ), việc cải thiện latency là không cần thiết lắm, mà nó chỉ gây lãng phí tài nguyên. Giá sử bạn có 100 con server c5.large dành cho nội bộ, mỗi con server của mỗi quốc gia Singapore và Oregon (Hoa Kỳ) chênh nhau 10$/tháng, thì chi phí sẽ độn lên 1000$/tháng nếu triển khai toàn bộ server ở Singapore.
Chính vì thế, tùy thuộc vào mục đích sử dụng, bạn hãy lựa chọn quốc gia đặt server cho phù hợp nhé!
CloudWatch là một dịch vụ monitoring toàn diện của AWS, từ các thông số cơ bản của server như RAM, CPU, Disk… đến các thông tin bên trong container như logs, CPU, Disk…
Ngoài ra, CloudWatch còn Monitoring các thông tin khác như S3, Fargate… nữa nhé
Chính vì thế, mình đã thử nghiệm triển khai nó rất nhiều để có thể monitoring được toàn diện nhất. Và đó là sai lầm của mình, khiến phía AWS đã charge gần 1500$/tháng cho phần này trong khi team chỉ sử dụng chưa tới 50 server.
AWS tính tiền CloudWatch dựa vào 2 thông số chính: số lượng chỉ mục và số lượng request hệ thống gửi lên Cloud Watch.
Chỉ mục ở đây bạn có thể hiểu: nó là loại tài nguyên của server/container cần monitoring. VD như RAM của mỗi server là 1 chỉ mục, CPU của mỗi server là 1 chỉ mục… RAM của mỗi container là 1 chỉ mục, CPU của mỗi container là 1 chỉ mục… Mỗi chỉ mục sẽ có giá là 0.3$, tuỳ vào số lượng server, container mà khi nhân lên sẽ ra số tiền khổng lồ.
Lưu ý: Nếu hệ thống bạn chạy dưới dạng docker container, thì mỗi lần container chết, và container mới được tạo ra thì AWS cũng sẽ charge thêm tiền với bấy nhiêu chỉ mục mới của container được sinh ra đó nhé!
Còn số lượng request hệ thống gửi lên CloudWatch: đơn giản là hệ thống sẽ gửi state (trạng thái) của các chỉ mục lên Cloud Watch, như gửi tham số về RAM của server thay đổi theo thời gian. Tuỳ thuộc vào thiết lập mà mỗi 30s, 60s… hệ thống sẽ gửi các state của chỉ mục lên AWS 1 lần.
Xem cách AWS tính tiền Cloud Watch tại đây
Hiện tại, team mình đã ngưng sử dụng Cloud Watch, và đang hướng tới phương pháp truyền thống, như sử dụng cụm ELK. Tuy nhiên, nếu bạn muốn sử dụng Cloud Watch, thì mình xin đưa ra một vài lời khuyên:
Vậy là đã xong AWS #2 – Vấn đề và giải pháp rồi nhỉ?
Trong bài viết này, mình đã giới thiệu với mọi người các bài toán mà team gặp phải, cũng như các hướng mà team giải quyết, kèm những gợi ý để bạn không phải thử sai như team mình.
Trong các bài viết tiếp theo, mình sẽ đi sâu hơn chút về các tài nguyên mà team đang sử dụng, cùng các best practice. Nào, hãy cùng chờ đón nhé!
Trong phần trước, mình đã chia sẻ với mọi người những khó khăn khi team…
Xin chào, tiếp tục loạt bài về trải nghiệm của mình trong việc xây dựng…
Cắm đầu cắm cổ dọn dẹp deadline và dọn nhà trước Tết nên ngâm bài…
Nếu bạn yêu thích phát triển sản phẩm với nhiều thử thách và cơ hội…
Trong giới công nghệ hiện nay, Amazon Web Service không còn là một cái gì…
Xin chào! Chúng ta lại quay trở lại với loạt bài về trải nghiệm của…