Запуск Magento в среде AWS

Хостинг Magento, как все знают, не похож на хостинг других приложений PHP. Насколько реально запустить Magento в среде Amazon Web Services в 2013 году?

Какое волшебное сочетание сервисов AWS имеет смысл использовать с Magento? Какие уровни являются умными значениями по умолчанию для магазина "Run of the Mill"? (да, я знаю, нет мельничных магазинов)

Какие из них (EBS?) Следует избегать?

Какие-нибудь советы, хитрости, стратегии развертывания, чтобы избежать неделей боли при получении этой настройки?

Я проводил Magento на AWS в 2011 году до 2013 года. Многие вещи, которые вы получаете от использования облачной инфраструктуры, а не от традиционного выделенного или общего хостинга, более подробно описаны в разделе DevOps, которые не являются эксклюзивными для AWS, но их легче включить с помощью его использование.

• Полное и гибкое управление вашим планированием мощностей - увеличивайте масштаб перед маркетинговыми событиями, включайте динамическое выделение ресурсов с помощью Elastic Beanstalk, уменьшайте масштаб в периоды малого объема, раскручивайте сайт за пару недель, разрывайте его и выбрасывайте.
• Простая настройка сред разработки / тестирования / организации и повторение изменений между ними.
• Разместите страницы администратора на отдельном хосте.
• Используйте DynamoDB для управления сеансами и ElastiCache для кэширования без дополнительных накладных операций, однако остерегайтесь, ElastiCache в настоящее время не работает в VPC.
• используйте ELB для балансировки нагрузки, но будьте осторожны, если запросы занимают более 60 секунд, они будут прекращены без изящества
• Используйте AmazonSES для отправки электронных писем (теперь еще проще через обычный SMTP), хотя в инструментах для отслеживания отказов / жалоб все еще существуют пробелы
• Используйте AmazonS3 для размещения мультимедиа и Cloudfront для CDN.
• Снижение операционных затрат на работу с базой данных через RDS, которая обеспечивает восстановление на определенный момент времени, автоматическое восстановление после отказа, автоматическое резервное копирование и автоматическое обновление.
• Управление DNS очень простое в Route53, но обычно рекомендуется для упрощения сопоставления поддоменов с балансировщиками нагрузки.
• VPC позволяет размещать все ваши машины в собственной частной сети, чтобы иметь более детальный контроль и предоставлять доступ по своему усмотрению через собственные VPN-туннели.
• Простые показатели производительности и оповещения (кроме использования памяти и дискового пространства) через CloudWatch & SNS

Минимальная занимаемая площадь будет составлять 1 ELB, 2 веб-сервера EC2 в отдельных AZ, 1 многоадресная RDS, размещенная зона Route53 для домена. Первоначально вы можете использовать липкие сеансы на ELB, чтобы упростить управление сеансами, но по мере увеличения трафика вам нужно будет перемещать мультимедиа в CDN (S3 и CloudFront) и сеансы вне отдельных машин.

Области, которые я не просматривал, но все еще обещаю: сценарии CloudFormation для более удобного развертывания стека Magento, создание заказов разгрузки через DynamoDB и рабочие очереди для большей пропускной способности проверки (кто-то уже начал проект, чтобы сделать это через MongoDB на одном из хакатонов недавно) и настройку присутствия в нескольких регионах через маршрутизацию на основе задержки с Route53.

Я думаю, что я своего рода евангелист для облака. Специфично для AWS, c3.large - это достойный размер экземпляра для производственных веб-серверов, но я бы начал с наименьшего из каждого класса экземпляра, а также измерял бы производительность и масштабировал или оптимизировал код по своему усмотрению, поэтому я рекомендую всем xhgui постоянно.

Вот как мы делаем это для интернет-магазина Angrybirds:

Английская презентация на Magento Imagine 2012.

Немецкая презентация на Meet Magento # 6.12

Нынешний немецкий "PHP Magazin" также имеет 6-страничную статью (на немецком языке) с некоторыми подробностями

Прочитав все презентации Фабрицио, связанные выше, много раз, я думаю, что этот ответ действительно лучший, хотя я согласен, что он мог бы использовать больше объяснений и извлечение ключевых идей из презентаций (тем более что оригинальная первая ссылка уже был 404'd к тому времени, когда я разместил это обновление).

Единственное, что я хотел бы добавить к ключевым концепциям в презентациях, - это то, что современные достижения в технологиях AWS / конкурента предполагают некоторые изменения ... например, тот факт, что Cloudfront теперь поддерживает gzip для повышения производительности CDN, хотя и не так быстро, как и это дает вам бесплатное завершение SSL как предложения CloudFlare . DNS Route 53 также не такой быстрый или многофункциональный, как CloudFlares, и при этом AWS не имеет сопоставимого брандмауэра веб-приложений или защиты DDOS, которые все включены в предложения CloudFlare ...

Есть несколько других возможных способов улучшить оригинальную презентацию Фабрицио, но я не был бы хорошим консультантом, если бы отдал все, что я знал в каждом сообщении StackExchange, на которое я ответил, теперь я буду? Кроме того, некоторые из новейших предложений существенно изменили бы предложения в оригинальных презентациях, и все они STILL предлагают отличную производительность, даже если бы из AWS можно было выжать еще больше с использованием различных опций.

Краткое изложение основных понятий :

1. Точно знайте свои узкие места : и оптимизируйте соответствующим образом. Каждый уровень стека имеет определенные узкие места (пропускная способность, процессор, база данных), и для устранения узких мест на каждом уровне требуется отдельное решение, оптимизированное для каждой конкретной задачи, хотя на самом деле кэширование является общим элементом на каждом уровне, что приводит к ...

2. Cache All the Things : по возможности используйте системы AWS (Elasticache для кэширования данных типа Redis / Memcache, изображения Cloudfront для кэширования, js и css, ближайшие к конечным пользователям через CDN) и Varnish для ускорения ответов экземпляров сервера на начальный уровень активов кеширование запросов от CDN. Кроме того, обязательно выполняйте сжатие и минимизацию в своих системах развертывания ПЕРЕД развертыванием в CDN

3. Важное значение имеет автомасштабирование : спрос меняется чаще и быстрее, чем вы можете контролировать и реагировать вручную. Адаптация к этим изменениям в режиме реального времени требует использования средств автоматизации, доступных в AWS, таких как группы автоматического масштабирования, чтобы ускорить работу частей системы, которые лучше всего подходят для этой задачи. AWS делает это прозрачно для CloudFront CDN, DNS-адресов Route 53, Elastic Load Balancers и S3 Bucket. Вы должны справиться с этим путем определения размеров и автоматического масштабирования для экземпляров EC2, а также просто определения размера / настройки для уровней RDS и Elasticache.

4. Автоматизация - единственный способ эффективно связать все это вместе : с таким количеством взаимосвязанных компонентов, некоторые из которых должны быть инициализированы во время развертывания, а некоторые сразу после развертывания, управление системой, настроенной для оптимальной производительности, требует автоматизации. Использование развертывания и системной автоматизации для очистки кэша, его прогрева, обработки изображений и т. Д. - единственный разумный способ управлять этим множеством различных подсистем и поддерживать их в хорошем состоянии и без проблем.

5. Но на самом деле даже это невозможно без автоматизации тестирования : с таким количеством движущихся частей что-то сломается практически при любом изменении. И вам нужно будет измениться, чтобы идти в ногу с событиями в Magento и AWS. И так будет часто . Таким образом, чтобы минимизировать стоимость изменений, все формы тестирования должны быть как реализованы, так и полностью автоматизированы - от модульных тестов до интеграционных тестов и функциональных тестов на основе Selenium реального сайта, запущенного в реальных конфигурациях тестирования, имитирующих производственную среду. Теперь вы ДЕЙСТВИТЕЛЬНО рады, что автоматизировали все процессы развертывания, верно?

Несколько более простое (!) Решение - просто установить, как на любом другом VPS. Несколько лет я предлагал бесплатное изображение ... в последнее время я сконцентрировался на новом Сиднее, потому что он локальный - более подробную информацию можно найти по адресу http://www.greengecko.co.nz/magento_on_amazon_ec2, если вы заинтересованы в этом. Практически безболезненно: один клик - и вы здесь. Укажите ваш браузер на экземпляр для более подробной информации. Это станет хорошей отправной точкой - но посмотрите и измените /etc/rc.local, если вы собираетесь на нем опираться.

Важно понимать, что экземпляры довольно маломощны. Очевидно, что трата огромных денег на приложение улучшит это, но даже для умеренно небольшого интернет-магазина средний экземпляр - это абсолютный минимум, просто чтобы получить несколько ядер, а действительно большой - это наименьшее необходимое.

Кроме того, хранилище Amazon работает медленно. Из-за этого даже важнее, чем обычно, доставлять из памяти все, что возможно: настройка баз данных, кэши с резервной памятью и т. Д. Являются обязательными.

Как только вы это отсортировали, все работает хорошо. требование работать в VPC, если вы хотите> 1 IP-адрес, действительно раздражает (особенно, если вы не понимаете этого, когда начинаете!), и действительно единственное, что вам нужно.

Простое расширение платформы «на лету» - в конце концов, единственным узким местом становится количество вычислительной мощности, доступной PHP (за исключением неэффективного кода!), И параллельное использование нескольких «движков», вероятно, является самым простым вариантом - включение дополнительных функций при необходимо.

Наслаждайтесь!

Стив

Мы используем RDS Multi AZ, два оптимизированных сервера NGINX, 2 сервера Varnish + ELB и на одном сервере Varnish (другой порт для Varnish) SSL Nginx. Мы используем Elasticache и вскоре добавим DynamoDB для управления сессиями Magento. Мы также используем S3 и Cloudfront.

У меня был интересный чат с британской хостинговой компанией, с которой у нас есть сервер за 700 фунтов в месяц. Все, что они делают - это планшет Amazon AWS. При правильной настройке и оптимизации во всех областях, включая отключение Magento, отключение модулей, функцию подсчета категорий и т. Д. (Мы настроили серверы NGINX и Varnish так, чтобы они располагались напротив сервера базы данных, который балансирует нагрузку).

В настоящее время мы можем получать 2400 - 3000 + посещений в секунду на страницах дома, категории, продукта и CMS (страницы лака). Страницы без лака, мы можем обрабатывать 400 - 500 запросов в секунду в зависимости от магазина. Сейчас мы используем RDS Multi с Reads.

Мы также установили Magento Admin на свой собственный узел для запуска crons и трафика администратора. http://administraton.mymagestore.com/admin

Мы никогда не оглядывались назад. Мы использовали одного из лучших в Великобритании, будь то очень дорогие хосты.

Вы можете использовать практически все базовые сервисы AWS, чтобы ваш magento работал. Проще всего было бы использовать EC2 с Elastic IP и AWS VPC для настройки безопасности.

Умный способ состоит в том, чтобы иметь 2 сервера развертывания: веб-сервер + база данных. Веб-сервер включает в себя Magento + Nginx + PHP + внутреннее кэширование (Redis или APC - хороший вариант) и отдельный сервер MySQL в той же подсети. Эти серверы могут быть видны друг другу через частный IP в частной сети (настроенный через VPC). Nginx является предпочтительным веб-сервером, как только он может доставлять статические файлы очень быстро.

Сервер базы данных должен быть скрыт от любого доступа. Веб-сервер будет виден на портах 80 и 443. Можно назначить Elastic IP веб-серверу. Позже будет полезно настроить DNS (например, через AWS Route 53) или балансировку нагрузки AWS.

Как вы упомянули, создание такой конфигурации может быть затруднительным. Таким образом, вы можете ускорить настройку через Deploy4Me. Он настроит всю упомянутую безопасность, виртуальные машины и сети за считанные минуты.