Запуск Magento в среде AWS
Хостинг Magento, как всем известно, не похож на хостинг других PHP-приложений. Насколько возможно запустить Magento в среде Amazon Web Services в 2013 году?
Какую волшебную комбинацию сервисов AWS имеет смысл использовать с Magento? Какие уровни являются разумными по умолчанию для магазина "заурядный"? (да, я знаю, здесь нет обычных магазинов)
Каких из них (EBS?) следует избегать?
Любые советы, рекомендации, стратегии развертывания для избежать недель боли при такой настройке?
5 answers
Я размещал Magento на AWS с 2011 по 2013 год. Многие из преимуществ, которые вы получаете от использования облачной инфраструктуры, а не традиционного выделенного или общего хостинга, более подробно описаны в разделе DevOps, которые не являются эксклюзивными для AWS, но их легче включить с помощью его использования.
- Полный и гибкий контроль планирования ваших мощностей - расширяйте масштаб перед маркетинговыми мероприятиями, включайте динамическую подготовку с помощью эластичного бобового стебля, уменьшайте масштаб при малом объеме периоды, раскрутите сайт за пару недель, снесите его и выбросьте.
- Легко настраивайте среды разработки/тестирования/промежуточной среды и копируйте изменения между ними.
- Размещайте свои страницы администратора на отдельном хостинге.
- Используйте DynamoDB для управления сеансами и ElastiCache для кэша без дополнительных накладных расходов на операции, однако будьте осторожны, ElastiCache в настоящее время не функционирует в VPC.
- используйте ELBS для балансировки нагрузки, но будьте осторожны, если запросы занимают более 60 секунд, они будут закончено нелюбезно
- Используйте AmazonSES для отправки электронных писем (теперь еще проще через обычный SMTP), хотя все еще существуют пробелы в инструментах для отслеживания отказов/жалоб
- Используйте AmazonS3 для размещения носителей и Cloudfront для CDN.
- Снижение операционных затрат на работу с базой данных с помощью RDS, которая включает восстановление на определенный момент времени, автоматическую отработку отказа, автоматическое резервное копирование и автоматическое обновление.
- Управление DNS очень просто в Route53, но обычно рекомендуется для удобства сопоставления поддомены для балансировщиков нагрузки.
- VPC для подключения всех ваших компьютеров к их собственной частной сети, чтобы иметь более детальный контроль и предоставлять доступ по вашему усмотрению через ваши собственные VPN-туннели.
- Простые показатели производительности и оповещения (помимо использования памяти и диска) с помощью CloudWatch и SNS
Минимальный объем будет составлять 1 ELB, 2 веб-сервера EC2 в отдельных AZS, 1 RDS с несколькими az, зона размещения Route53 для домена. Первоначально вы можете использовать липкие сеансы на ELB для сохранения сеанса управление проще, но по мере увеличения трафика вам захочется перемещать носители в CDN (S3 и CloudFront) и сеансы с отдельных компьютеров.
Области, которые я не просматривал, но все еще многообещающие: сценарии CloudFormation для упрощения развертывания стека Magento, разгрузки создания заказов с помощью DynamoDB и рабочих очередей для увеличения пропускной способности при оформлении заказа (кто-то уже запустил проект для этого с помощью MongoDB на одном из хакатонов недавно) и настройки мультирегионального присутствие через маршрутизацию на основе задержки с помощью Route53.
Я думаю, что я своего рода евангелист для облака. Специфичный для AWS, c3.large - это приличный размер экземпляра для производственных веб-серверов, но я бы начал с наименьшего из каждого класса экземпляров, измерил производительность и увеличил или оптимизировал код по вашему усмотрению, поэтому я постоянно отсылаю всех к xhgui.
Вот как мы делаем это для интернет-магазина Angrybirds:
Презентация на английском языке в Magento Imagine 2012.
Презентация немецкого языка на Meet Magento #6.12
Прочитав все презентации Фабрицио, приведенные выше, много раз, я думаю, что этот ответ действительно лучший, хотя я согласен, что он мог бы использовать больше объяснений и извлечения из ключевых идей презентаций (тем более, что к моменту публикации этого обновления первоначальная первая ссылка уже была 404-й).
Единственное, что я хотел бы добавить к ключевым концепциям в презентациях, - это то, что современные достижения в технологиях AWS/конкурентов предполагают некоторые изменения...например, тот факт, что Cloudfront теперь поддерживает gzip для повышения производительности CDN, хотя это не так быстро, как и не дает вам бесплатного завершения SSL, как Cloudflare предложения. Их DNS Route 53 также не так быстры и многофункциональны, как CloudFlares, и у AWS нет сопоставимого брандмауэра веб-приложений или защиты от DDOS, все из которых включены в предложения CloudFlare...
Есть несколько других возможных способов улучшить оригинальную презентацию Фабрицио, но я не был бы хорошим консультантом, если бы выдавал ВСЕ, что знал, в каждом сообщении StackExchange, на которое я отвечал, не так ли? Плюс некоторые из новейших предложений существенно изменят предложения в оригинальных презентациях, все из которых ПО-прежнему обеспечивают отличную производительность, даже если из AWS можно выжать больше при использовании различных опций.
Краткое изложение ключевых концепций:
Тщательно изучите Свои узкие места: и оптимизируйте соответствующим образом. Каждый уровень стека имеет определенные узкие места (пропускная способность, процессор, база данных), и для устранения узких мест на каждом уровне требуется другое решение, оптимизированное для каждого конкретного проблема, хотя на самом деле кэширование является общим элементом на каждом уровне, что приводит к...
Кэшируйте все : Используйте системы AWS, где это возможно (Elasticache для кэширования данных типа Redis/Memcache, Cloudfront для кэширования изображений, js и css-ресурсов, ближайших к конечным пользователям через CDN), и Varnish для ускорения ответов экземпляра сервера на начальные запросы кэширования на уровне активов от CDN. Кроме того, перед развертыванием обязательно выполните сжатие и мининизацию в своих системах развертывания в CDN-х
Автоматическое масштабирование имеет важное значение: Спрос меняется часто и быстрее, чем вы можете отслеживать и реагировать вручную. Адаптация к этим изменениям в режиме реального времени требует использования инструментов автоматизации, доступных в AWS, таких как группы автоматического масштабирования, для развертывания частей системы, которые лучше всего подходят для этой задачи. AWS обрабатывает это прозрачно для CDN CloudFront, DNS Route 53, эластичных балансировщиков нагрузки и сегментов S3, вы должны обрабатывать это, определяя размер и автоматически масштабируя для EC2 Экземпляры, а также просто размер/настройка для уровней RDS и Elasticache
Автоматизация - единственный способ эффективно связать все это воедино: с таким количеством взаимосвязанных компонентов, некоторые из которых должны быть инициализированы во время развертывания, некоторые сразу после развертывания, управление системой, настроенной на оптимальную производительность, требует автоматизации. Использование автоматизации развертывания и систем для очистки кэша, прогрева кэша, обработки изображений и т. Д. Является единственным разумным способом управления это множество различных подсистем и позволяет поддерживать их в хорошем состоянии и без проблем.
Но на самом деле даже это невозможно без автоматизации тестирования: с таким количеством движущихся частей что-то сломается практически при любом изменении. И вам нужно будет измениться, чтобы идти в ногу с развитием Magento и AWS. И это произойдет ЧАСТО. Таким образом, чтобы свести к минимуму затраты на изменения, все формы тестирования должны быть как внедрены, так и полностью автоматизированы - от единицы тесты для интеграции с функциональными тестами на основе Selenium фактического сайта, запущенного в реальных конфигурациях тестирования, имитирующих производственную среду. Теперь вы ДЕЙСТВИТЕЛЬНО рады, что автоматизировали все процессы развертывания, верно?
Немного более простое (!) решение - просто установить, как и на любом другом VPS. Я предлагаю бесплатное изображение уже несколько лет... в последнее время я сосредоточился на новом округе Колумбия в Сиднее из-за того, что он местный - более подробная информация на http://www.greengecko.co.nz/magento_on_amazon_ec2 если вас это интересует. Практически нулевая боль при начале работы - один щелчок, и вы там. Наведите свой браузер на экземпляр для получения более подробной информации. Это станет хорошей отправной точкой, но посмотрите и измените /etc/rc.local, если вы собираетесь использовать его.
Важно понимать, что экземпляры имеют довольно низкую мощность. Очевидно, что вложение больших денег в приложение действительно улучшает это, но даже для умеренно небольшого интернет-магазина средний экземпляр - это абсолютный минимум, просто чтобы получить несколько ядер, а действительно большой - это наименьшее необходимое.
Кроме того, хранилище Amazon работает медленно. Из-за этого еще важнее, чем обычно, доставить все, что вы можете может из памяти: необходимо настроить базы данных, кэш с поддержкой памяти и т. Д.
Как только вы с этим разберетесь, все будет нормально. требование работать в VPC, если вы хотите > 1 IP-адрес, действительно раздражает (особенно если вы не осознаете этого, когда начинаете! ), и действительно единственный попавшийся вам на глаза.
Просто расширить платформу "на лету" - в конечном итоге единственным узким местом становится объем вычислительной мощности, доступной для PHP (помимо неэффективного кода!), и параллельный запуск нескольких "движков", вероятно, является самым простым вариантом - при необходимости подключать дополнительные услуги онлайн.
Наслаждайтесь!
Стив
Мы запускаем RDS Multi A-Z, два оптимизированных сервера NGINX, 2 сервера Varnish + ELB и на тех же серверах Varnish (другой порт для лакирования) SSL Nginx. Мы используем Elasticache и очень скоро интегрируем DynamoDB для управления сеансами Magento. Мы также используем S3 и Cloudfront.
У меня был интересный разговор с британской хостинговой компанией, с которой у нас есть сервер за 700 фунтов стерлингов в месяц. Все, что они делают, - это запускают Amazon AWS. С правильной настройкой и оптимизацией во всех областях, включая чередование Magento, отключение модулей, функция подсчета категорий и т. Д. И т. Д. (Мы настроили серверы NGINX и Varnish так, чтобы они находились перед сервером базы данных, который балансирует нагрузку).
В настоящее время мы можем получать 2400-3000 + просмотров в секунду на страницах главная, категория, продукт и CMS (страницы с лаком). Не лакированные страницы, мы можем обрабатывать 400-500 запросов в секунду в зависимости от магазина. Теперь мы используем RDS Multi с чтением.
Мы также поместили администратора Magento на свой собственный узел для запуска crons, и трафик администратора. http://administraton.mymagestore.com/admin
Мы никогда не оглядывались назад. Мы использовали одного из лучших в Великобритании, будь то невероятно дорогие хосты.
Вы можете использовать практически все основные сервисы AWS, чтобы заставить ваш magento работать. Самым простым вариантом было бы использовать EC2 с эластичным IP и AWS VPC для настройки безопасности.
Разумный способ - это развертывание 2 серверов: Веб-сервер + База данных. Веб-сервер включает в себя Magento + Nginx + PHP + серверное кэширование (Redis или APC - хороший вариант) и отдельный сервер MySQL в той же подсети. Эти серверы могут быть видны друг другу через частный IP-адрес в частной сети (настроен через VPC). Nginx является предпочтительным веб-сервером, как только он может доставлять статические файлы очень быстро.
Сервер базы данных должен быть скрыт от любого доступа. Веб-сервер будет виден на портах 80 и 443. Можно выделить эластичный IP-адрес для веб-сервера. Позже будет полезно настроить DNS (например, через AWS Route 53) или балансировку нагрузки AWS.
Как вы упомянули, сделать такую конфигурацию может быть непросто. Таким образом, вы можете ускорить настройку с помощью Deploy4Me. Он настроит все упомянутая безопасность, виртуальные машины и сеть в считанные минуты.