Chạy Magento trong môi trường AWS

Hosting Magento, như mọi người đều biết, không giống như lưu trữ các ứng dụng PHP khác. Làm thế nào khả thi để chạy Magento trong môi trường Dịch vụ web Amazon vào năm 2013?

Sự kết hợp kỳ diệu nào của các dịch vụ AWS có ý nghĩa khi sử dụng với Magento? Những mức nào là mặc định thông minh cho một cửa hàng "chạy của nhà máy"? (vâng, tôi biết, không có hoạt động của các cửa hàng nhà máy)

Những cái nào (EBS?) Nên tránh?

Bất kỳ mẹo, thủ thuật, chiến lược triển khai để tránh những tuần đau đớn khi thiết lập này?

Tôi đã lưu trữ Magento trên AWS vào năm 2011 cho đến năm 2013. Nhiều điều bạn có được từ việc sử dụng cơ sở hạ tầng đám mây thay vì lưu trữ dành riêng hoặc chia sẻ truyền thống được mô tả phù hợp hơn theo chủ đề DevOps, không dành riêng cho AWS nhưng dễ dàng được kích hoạt hơn thông qua công dụng của nó.

• Kiểm soát hoàn toàn và linh hoạt việc lập kế hoạch năng lực của bạn - mở rộng trước các sự kiện tiếp thị, cho phép cung cấp năng động thông qua Elastic Beanstalk, giảm quy mô trong thời gian khối lượng thấp, quay vòng một trang web trong vài tuần, xé nó và ném nó đi.
• Dễ dàng thiết lập môi trường dev / test / staging và sao chép các thay đổi giữa chúng.
• Lưu trữ các trang quản trị của bạn trên một máy chủ riêng biệt.
• Sử dụng DynamoDB để quản lý phiên và ElastiCache cho bộ đệm khi không phát sinh thêm các hoạt động bổ sung, hãy cẩn thận ElastiCache hiện không hoạt động trong VPC.
• sử dụng ELB để cân bằng tải, nhưng hãy cẩn thận nếu các yêu cầu mất hơn 60 giây, chúng sẽ bị chấm dứt một cách vô duyên
• Sử dụng AmazonSES để gửi email (giờ đây thậm chí còn dễ dàng hơn thông qua SMTP thông thường), mặc dù các lỗ hổng vẫn tồn tại trong công cụ để theo dõi bị trả lại / khiếu nại
• Sử dụng AmazonS3 để lưu trữ phương tiện truyền thông và Cloudfront cho CDN.
• Giảm chi phí hoạt động cho hoạt động cơ sở dữ liệu thông qua RDS, có tính năng khôi phục thời gian, chuyển đổi dự phòng tự động, sao lưu tự động và nâng cấp tự động.
• Quản lý DNS cực kỳ dễ dàng trong Route53, nhưng thường được khuyến nghị để dễ dàng ánh xạ các tên miền phụ để tải các bộ cân bằng.
• VPC để đặt tất cả các máy của bạn trên mạng riêng của chúng để có quyền kiểm soát chi tiết hơn và hiển thị quyền truy cập khi bạn thấy phù hợp thông qua các đường hầm VPN của riêng bạn.
• Dễ dàng đo lường hiệu suất và cảnh báo (ngoài việc sử dụng bộ nhớ và sử dụng đĩa) qua CloudWatch & SNS

Dấu chân tối thiểu sẽ là 1 ELB, 2 máy chủ web EC2 trong các AZ riêng biệt, 1 RDS đa az, vùng lưu trữ Route53 cho miền. Ban đầu, bạn có thể sử dụng các phiên dính trên ELB để đơn giản hóa việc quản lý phiên, nhưng khi lưu lượng truy cập của bạn tăng, bạn sẽ muốn chuyển phương tiện vào CDN (S3 & CloudFront) và tắt các máy riêng lẻ.

Các khu vực tôi chưa xem nhưng vẫn đầy hứa hẹn: Các kịch bản CloudFormation để triển khai dễ dàng hơn cho ngăn xếp Magento, giảm tải việc tạo đơn hàng qua DynamoDB và hàng đợi công nhân để có thông lượng thanh toán lớn hơn (ai đó đã bắt đầu một dự án để thực hiện điều này thông qua MongoDB tại một trong những hackathons gần đây) và thiết lập sự hiện diện đa vùng thông qua định tuyến dựa trên độ trễ với Route53.

Tôi đoán tôi là một nhà truyền giáo cho đám mây. Cụ thể với AWS, c3.lund là một kích thước cá thể phù hợp cho các máy chủ web sản xuất, nhưng tôi sẽ bắt đầu với từng loại nhỏ nhất của từng lớp cá thể và đo lường hiệu suất và tăng quy mô hoặc tối ưu hóa mã khi bạn thấy phù hợp, đó là lý do tôi giới thiệu mọi người xhgui liên tục.

Đây là cách chúng tôi làm điều đó cho webshop của Angrybirds:

Trình bày tiếng Anh tại Magento Imagine 2012.

Trình bày tiếng Đức tại Meet Magento # 6.12

"PHP Magazin" hiện tại của Đức cũng có một bài viết dài 6 trang (bằng tiếng Đức) với một số chi tiết

Đã đọc tất cả các bài thuyết trình của Fabrizio được liên kết ở trên nhiều lần, tôi nghĩ rằng câu trả lời này thực sự là câu trả lời hay nhất, mặc dù tôi đồng ý rằng nó có thể sử dụng nhiều lời giải thích và trích xuất các ý tưởng chính từ các bài thuyết trình (đặc biệt là vì liên kết đầu tiên ban đầu đã có được 404'd khi tôi đăng bản cập nhật này).

Điều duy nhất tôi muốn thêm vào các khái niệm chính trong các bài thuyết trình là những tiến bộ hiện đại trong công nghệ của AWS / đối thủ sẽ gợi ý một số điều chỉnh ... giống như thực tế là Cloudfront hiện hỗ trợ gzip để cải thiện hiệu suất CDN, mặc dù nó không nhanh như vậy nó có cung cấp cho bạn chấm dứt SSL miễn phí như ưu đãi của CloudFlare không . DNS Tuyến 53 của họ cũng không nhanh hoặc giàu tính năng như CloudFlares, AWS cũng không có tính năng bảo vệ Tường lửa hoặc DDOS ứng dụng web tương đương, tất cả đều được bao gồm trong các dịch vụ của CloudFlare ...

Có một vài cách khác có thể để cải thiện bài thuyết trình ban đầu của Fabrizio nhưng tôi sẽ không trở thành một nhà tư vấn giỏi nếu tôi từ bỏ MỌI THỨ tôi biết trên mỗi bài đăng trên StackExchange mà tôi đã trả lời, bây giờ tôi sẽ làm gì? Ngoài ra, một số dịch vụ mới nhất sẽ thay đổi đáng kể các đề xuất trong bản trình bày ban đầu, tất cả đều VẪN cung cấp hiệu suất tuyệt vời, ngay cả khi nhiều hơn có thể được loại bỏ khỏi AWS với các tùy chọn khác nhau được sử dụng.

Tóm tắt các khái niệm chính :

1. Hiểu rõ sự tắc nghẽn của bạn : và tối ưu hóa một cách thích hợp. Mỗi tầng của ngăn xếp có các tắc nghẽn cụ thể (băng thông, cpu, cơ sở dữ liệu) và giải quyết các tắc nghẽn ở mỗi tầng yêu cầu một giải pháp khác nhau được tối ưu hóa cho từng thách thức cụ thể, mặc dù thực sự bộ nhớ đệm là yếu tố phổ biến ở mọi cấp độ, dẫn đến ...

2. Bộ nhớ cache Tất cả mọi thứ : Tận dụng các hệ thống AWS nếu có thể (Bộ đệm dữ liệu cho bộ đệm dữ liệu loại Redis / Memcache, Cloudfront cho bộ nhớ đệm, js và tài sản css gần nhất với người dùng cuối thông qua CDN) và Varnish để tăng tốc độ phản hồi của máy chủ lên mức tài sản ban đầu yêu cầu lưu trữ từ CDN. Ngoài ra, hãy chắc chắn nén & thu nhỏ trong các hệ thống triển khai của bạn TRƯỚC KHI triển khai lên CDN

3. Tự động hóa là điều cần thiết : Nhu cầu thay đổi thường xuyên và nhanh hơn bạn có thể theo dõi và phản ứng bằng tay. Thích ứng với những thay đổi này trong thời gian thực đòi hỏi phải sử dụng các công cụ tự động hóa có sẵn trong AWS như Auto-Scaleing Groups để tạo ra các phần của hệ thống phù hợp nhất với nhiệm vụ này. AWS xử lý việc này một cách minh bạch cho CloudFront CDN, Tuyến đường 53, Bộ cân bằng tải đàn hồi và Xô S3, bạn phải xử lý nó bằng cách định cỡ và tự động điều chỉnh cho Trường hợp EC2, và chỉ định cỡ / điều chỉnh cho các lớp RDS & Elasticache

4. Tự động hóa là cách duy nhất để kết nối tất cả những thứ này lại với nhau một cách hiệu quả : với rất nhiều thành phần có liên quan với nhau, một số thành phần phải được khởi tạo khi triển khai, một số ngay sau khi triển khai, quản lý một hệ thống được điều chỉnh để có hiệu suất tối ưu đòi hỏi phải tự động hóa. Tận dụng triển khai và tự động hóa hệ thống để xóa bộ nhớ cache, làm nóng bộ đệm, xử lý hình ảnh, ... là cách hợp lý duy nhất để quản lý nhiều hệ thống con khác nhau này và giữ cho chúng không bị ảnh hưởng và không có vấn đề.

5. Nhưng thực sự ngay cả điều đó là không thể nếu không có tự động hóa thử nghiệm : Với nhiều bộ phận chuyển động này, một cái gì đó sẽ phá vỡ với hầu hết mọi thay đổi. Và bạn sẽ cần thay đổi để theo kịp sự phát triển trong Magento và AWS. Và những điều đó sẽ xảy ra OFTEN . Vì vậy, để giảm thiểu chi phí thay đổi, tất cả các hình thức thử nghiệm cần phải được thực hiện và tự động hóa hoàn toàn - từ thử nghiệm đơn vị đến thử nghiệm tích hợp đến thử nghiệm chức năng dựa trên Selenium của trang web thực tế được đưa ra trong cấu hình thử nghiệm thực tế bắt chước môi trường sản xuất. Bây giờ bạn thật sự rất vui vì bạn đã tự động hóa tất cả các quy trình triển khai của mình, phải không?

Một giải pháp đơn giản hơn (!) Chỉ là cài đặt như bạn làm trên bất kỳ VPS nào khác. Tôi đã cung cấp một hình ảnh miễn phí trong vài năm nay ... gần đây tôi đã tập trung vào Sydney DC mới do nó là địa phương - chi tiết hơn tại http://www.greengecko.co.nz/magento_on_amazon_ec2 nếu bạn Tôi quan tâm đến điều đó. Thực tế không đau bắt đầu - một cú nhấp chuột và bạn đang ở đó. Trỏ trình duyệt của bạn vào ví dụ để biết thêm chi tiết. Điều này sẽ tạo ra một điểm khởi đầu tốt - nhưng hãy xem và sửa đổi /etc/rc.local nếu bạn sẽ xây dựng dựa trên nó.

Những điều quan trọng để nhận ra là các trường hợp được cung cấp năng lượng khá thấp. Rõ ràng việc ném rất nhiều tiền vào ứng dụng sẽ cải thiện điều này, nhưng đối với một webshop nhỏ vừa phải, một ví dụ trung bình là tối thiểu tuyệt đối, chỉ để có được nhiều lõi và thực sự lớn là nhỏ nhất cần thiết.

Ngoài ra, lưu trữ Amazon là chậm. Do đó, điều quan trọng hơn bình thường là cung cấp mọi thứ bạn có thể có từ bộ nhớ: điều chỉnh cơ sở dữ liệu, bộ nhớ được hỗ trợ bộ nhớ, v.v.

Một khi bạn đã sắp xếp nó, nó hoạt động tốt. yêu cầu chạy trong VPC nếu bạn muốn> 1 địa chỉ IP thực sự gây phiền nhiễu (đặc biệt là nếu bạn không nhận ra điều này khi bạn bắt đầu!), và thực sự là điều bí mật duy nhất bạn sẽ gặp.

Thật đơn giản để mở rộng nền tảng 'một cách nhanh chóng' - cuối cùng, nút cổ chai duy nhất trở thành lượng năng lực xử lý có sẵn cho PHP (mã không hiệu quả sang một bên!) Và chạy song song nhiều 'công cụ' có thể là tùy chọn đơn giản nhất - mang thêm tính năng trực tuyến khi cần thiết.

Thưởng thức!

Steve

Chúng tôi đang chạy RDS Multi AZ, Hai máy chủ được tối ưu hóa NGINX, 2 Máy chủ Varnish + ELB và trên cùng một Máy chủ Varnish (cổng khác với Varnish) SSL Nginx. Chúng tôi sử dụng Elasticache và sớm tích hợp DynamoDB để quản lý phiên của Magento. Chúng tôi cũng sử dụng S3 và Cloudfront.

Tôi đã có một cuộc trò chuyện thú vị với một công ty lưu trữ có trụ sở tại Vương quốc Anh, chúng tôi có một máy chủ 700 bảng mỗi tháng. Tất cả những gì họ làm là đá phiến Amazon AWS. Với việc thiết lập và tối ưu hóa chính xác trong tất cả các lĩnh vực bao gồm tước bỏ Magento, vô hiệu hóa các mô-đun, chức năng đếm danh mục, v.v. (chúng tôi đã tinh chỉnh NGINX và Máy chủ Varnish để ngồi trước máy chủ Cơ sở dữ liệu tải cân bằng).

Hiện tại chúng tôi có thể nhận được 2400 - 3000 lượt truy cập mỗi giây trên các trang chủ, danh mục, sản phẩm và CMS (trang véc ni). Không trang vecni, chúng tôi có thể xử lý 400 - 500 yêu cầu mỗi giây tùy thuộc vào cửa hàng. Chúng tôi hiện đang sử dụng RDS Multi with Reads.

Chúng tôi cũng đặt Magento Admin trên Node riêng để chạy crons và lưu lượng quản trị. http://ad quảnaton.mymagestore.com/admin

Chúng tôi chưa bao giờ nhìn lại. Chúng tôi đã sử dụng một trong những sản phẩm tốt nhất của Vương quốc Anh, tất cả đều là những máy chủ đắt tiền.

Bạn có thể sử dụng hầu hết tất cả các Dịch vụ AWS cơ bản để magento của bạn hoạt động. Phối cảnh đơn giản nhất sẽ là sử dụng EC2 với Elastic IP và AWS VPC cho cấu hình bảo mật.

Cách thông minh là có 2 máy chủ triển khai: Máy chủ Web + Cơ sở dữ liệu. Máy chủ web bao gồm Magento + Nginx + PHP + bộ đệm phụ trợ (Redis hoặc APC là một tùy chọn tốt) và một máy chủ MySQL riêng trong cùng một mạng con. Các máy chủ này có thể hiển thị với nhau thông qua IP riêng trong mạng riêng (được định cấu hình qua VPC). Nginx là máy chủ web được lựa chọn ngay khi có thể phân phối các tệp tĩnh cực nhanh.

Máy chủ cơ sở dữ liệu sẽ bị ẩn khỏi mọi truy cập. Máy chủ web sẽ hiển thị trên các cổng 80 và 443. Có thể phân bổ IP đàn hồi cho máy chủ web. Sau đó, sẽ rất hữu ích khi định cấu hình DNS (ví dụ thông qua AWS Route 53) hoặc cân bằng tải AWS.

Như bạn đã đề cập, nó có thể là một nỗi đau để làm cho cấu hình như vậy. Vì vậy, bạn có thể tăng tốc độ thiết lập thông qua Deploy4Me. Nó sẽ cấu hình tất cả các bảo mật, VM và mạng được đề cập trong vài phút.