Cấu hình Amazon Cloud cho ứng dụng web Java EE với MySQL

Question

Trong công việc của tôi, tôi cần di chuyển một số ứng dụng Java Enterprise Enterprise hiện có sang AWS. Tôi đã trải qua nhiều trang trên aws.amazon.com và cũng đủ googled. Ngoài ra, tôi đã cố gắng đi qua tất cả các câu hỏi liên quan tại stackoverflow. Tất cả những điều này làm cho nhiều điều rõ ràng, tuy nhiên, tôi vẫn còn có một số nhầm lẫn. Đây là cấu trúc ứng dụng của chúng tôi:

1. Ứng dụng dựa trên Spring sử dụng Spring MVC làm lớp trình bày và Giao diện Java đơn giản và Lớp học để xử lý doanh nghiệp và logic dữ liệu.
2. MySQL được sử dụng để kiên trì.

Vì vậy, kiến ​​trúc ứng dụng đủ đơn giản. Tuy nhiên, bắt là chúng ta cần triển khai nhiều phiên bản của ứng dụng này. Số lượng này hiện là 15 và có thể vượt quá 30. Một điểm nữa là tất cả các trường hợp này đều dùng chung một cơ sở dữ liệu chung.

Bây giờ đây là những gì chúng ta cần phải đạt được bằng cách di chuyển đến AWS:

fault tolerance

1. cao hơn cho ứng dụng. Gần đây chúng tôi phải đối mặt với một máy chủ/mất điện trong lưu trữ dành riêng gây ra một số giờ xuống thời gian.
2. Hiệu suất cao hơn cho tất cả phiên bản ứng dụng về thời gian phản hồi và thông lượng.
3. Dung sai lỗi cao hơn đối với MySQL. Trường hợp ứng dụng đã đi xuống trên một trong các máy chủ của chúng tôi gần đây do một số phần cứng (Hard Drive) mà về cơ bản đã khiến MySQL dừng đột ngột. Toàn bộ hệ thống tệp trên ổ cứng chỉ đọc mà gây ra sự cố cho các cá thể ứng dụng được lưu trữ trên máy chủ đó.
4. Rõ ràng là giảm tổng chi phí và chi phí quản lý cơ sở hạ tầng.

Theo như tôi có thể hiểu được cơ sở hạ tầng AWS cho đến bây giờ, đây là những gì chúng ta cần trong AWS cho các thiết lập của chúng tôi:

1. 4 trường hợp, mỗi lưu trữ khoảng 10 trường hợp ứng dụng, một số EBS dựa trên LINUX AMI với Tomcat và MySQL được cài đặt trên đó.
2. Tôi đoán rằng chúng tôi cũng sẽ cần 1 trường hợp cho khả năng chịu lỗi cho mỗi trong số 4 trường hợp đó tổng cộng 8 trường hợp trong tất cả.
3. Tất cả các phiên bản máy chủ sẽ có khoảng 160GB EBS.
4. 4 Elastic IP
5. 4 tải cân bằng đàn hồi
6. thứ khác như ảnh chụp vv

Bây giờ đây là những câu hỏi của tôi:

1. Tôi có thực sự cần phải có mà thêm ví dụ máy chủ (đối với dung sai lỗi) cho mỗi trường hợp máy chủ chính, xem xét khuôn mặt mà EBS được tự động sao lưu bởi AWS và họ sẽ cung cấp EBS mới với cùng một dữ liệu trong trường hợp lỗi phần cứng?

2. Làm cách nào để chia sẻ cơ sở dữ liệu giữa tất cả các phiên bản máy chủ (4x2) trong trường hợp trên? Một tùy chọn mà tôi thấy là triển khai thực hiện phân cụm MySQL giữa các cá thể máy chủ đó. Cho phép nói, cụm MySQL sẽ chứa 1 nút quản lý, 3 nút SQL và 4 nút dữ liệu.Tuy nhiên, trong trường hợp này, việc duy trì cụm sẽ là chi phí bổ sung cho chúng tôi và điều này có thể không được chấp nhận vì chúng tôi muốn loại bỏ quản lý cơ sở hạ tầng.

3. Tôi có cần phải có RDS để thay thế cho cơ sở dữ liệu và xóa các phiên bản MySQL khỏi tất cả các trường hợp máy chủ (4x2) không? Nếu có, tôi có cần phải mua các trường hợp RDS ngoài các trường hợp EC2 (tôi nghĩ, nếu tôi cần mua các trường hợp riêng biệt cho RDS thì chi phí của tổng số cơ sở hạ tầng sẽ tăng ít nhất 75%.) Hoặc các trường hợp RDS cũng cung cấp cho các đơn vị tính toán để phát triển ứng dụng, do đó làm giảm tổng số trường hợp triển khai ứng dụng?

4. Trong trường hợp triển khai RDS, có thực sự cần các phiên bản EC2 dựa trên EBS không? Nếu chúng ta có thể loại bỏ yêu cầu EBS từ các cá thể EC2 với các cá thể RDS tại chỗ, chúng ta có thể giảm tổng chi phí.

Bất kỳ trợ giúp nào sẽ được đánh giá cao và vui lòng cho tôi biết nếu tôi không rõ ràng để xác định sự cố của mình và cần làm rõ thêm bất kỳ điểm nào.

Answer 1

Tôi không phải là chuyên gia về cơ sở hạ tầng, nhưng tôi có một số kinh nghiệm về AWS và tôi hy vọng tôi có thể giúp ít nhất một số câu hỏi của bạn. Nền của tôi không cho phép tôi cung cấp cho bạn lời khuyên nào về việc định kích thước cơ sở hạ tầng của bạn, nhưng tôi có thể giúp tư vấn về loại thông tin.
Trước hết, tôi chắc chắn sẽ đi với EBS. Ngoài việc tách biệt về mặt vật lý với máy chủ ứng dụng của bạn, nó cũng có độ tin cậy cao và tính sẵn sàng cao. Tôi có thể nói với bạn rằng nó đã cứu tôi một vài lần. Mặc dù tôi đã nói rằng tôi sẽ không nói với bạn bất cứ điều gì về kích thước, tôi không nghĩ rằng bạn sẽ cần thêm 4 "lỗi khoan dung" trường hợp, nhưng có lẽ bạn có thể giữ một số 2 trường hợp đã sẵn sàng để cất cánh giao thông, chỉ trong trường hợp.

Về DB của bạn, bạn chắc chắn nên tiếp tục và sử dụng RDS cho MySQL (http://aws.amazon.com/rds/mysql/). Chúng cung cấp cho bạn các nút được cấu hình sẵn, tự động vá, tự động sao lưu, sao chép tự động và chia tỷ lệ một lần, với mức giá nhỏ (IMHO). Tất cả các tính năng này đã sẵn sàng, out-of-the-box, cho MySQL. Bạn cũng có thể sử dụng chỉ số và theo dõi, tất cả đều được bao gồm. RDS không cung cấp cho bạn các đơn vị tính toán, nhưng nó là một thực hành tốt để giữ chúng riêng biệt trong AWS. Bạn cũng có thể thiết lập với 4 nút Tomcat EC2 + 2 nút RDS. Nó chỉ là vấn đề kích thước :)

Nếu bạn đã đọc về Cân bằng tải đàn hồi của Amazon, nó trông hoàn hảo cho giải pháp của bạn. Bạn có thể gắn một số nút EC2 vào mỗi nút ELB của bạn và quên mất cân bằng tải. Nó chỉ hoạt động và bạn cũng có thể định cấu hình các phiên dính nếu muốn. Tuy nhiên, tôi không biết, bạn nên chọn bao nhiêu nút ELB, nhưng hãy lưu ý một vấn đề: bạn chỉ có thể thêm các nút EC2 từ cùng một vùng địa lý (ví dụ: Bờ Đông Hoa Kỳ) vào cùng một ELB. Không thể cân bằng lưu lượng giữa, ví dụ như Tomcat ở Bờ Tây và một tàu khác ở Bờ Đông. Nếu bạn chọn phân phối các nút của mình trên nhiều vùng, bạn sẽ cần phải đi kèm với một giải pháp LB khác bên ngoài Amazon.

Lời khuyên cuối cùng của tôi: tiếp tục với ELB + EBS dựa trên EC2 + RDS. Nó sẽ đơn giản hóa rất nhiều việc theo dõi, triển khai và bảo trì của bạn, và chi phí có xu hướng thấp hơn nhiều. Bạn có thể biết nhiều hơn về số lượng của mỗi loại nút mà bạn sẽ cần, nhưng đừng ngại bỏ lỡ, bởi vì nó rất dễ dàng để nâng cao hoặc hạ thấp tầm ảnh hưởng của bạn trên AWS.