Хостинг Magento, як всі знають, не схожий на розміщення інших програм PHP. Наскільки це можливо запустити Magento в середовищі веб-служб Amazon в 2013 році?
Яке магічне поєднання послуг AWS має сенс використовувати з Magento? Які рівні є розумними за замовчуванням для магазину "пробіг млина"? (так, я знаю, магазинів млини немає)
Яких (СРС?) Слід уникати?
Будь-які поради, підказки, стратегії розгортання, щоб уникнути больових тижнів, щоб отримати цю настройку?
Відповіді:
Я влаштовував Magento на AWS у 2011 році до 2013 року. Багато речей, які ви отримуєте від використання хмарної інфраструктури, а не традиційного виділеного або спільного хостингу, більш доречно описані в темі DevOps, які не є ексклюзивними для AWS, але вони легше включаються через його використання.
Мінімальний слід складатиме 1 ELB, 2 веб-сервери EC2 в окремих АЗ, 1 мультиаз. RDS, розміщена зона Route53 для домену. Спочатку ви можете використовувати липкі сеанси на ELB, щоб полегшити керування сеансами, але у міру збільшення трафіку вам потрібно буде перенести медіа в CDN (S3 та CloudFront) та сеанси поза окремими машинами.
Сфери, які я не дивився, але все ще перспективні: сценарії CloudFormation для більш простого розгортання стека Magento, розвантаження створення замовлень за допомогою DynamoDB та черги працівників для більшої пропускної спроможності (хтось уже розпочав проект для цього через MongoDB на одному з хакатонів останнім часом) і налаштування присутності в декількох регіонах за допомогою маршрутизації на основі затримки.
Я певно є євангелістом для хмари. Характерні для AWS, c3.large - це пристойний розмір екземплярів для виробничих веб-серверів, але я б почав з найменшого з кожного класу екземплярів і міряти продуктивність і масштабувати або оптимізувати код, як вважаєте за потрібне, саме тому я посилаю всіх на xhgui постійно.
Ось як ми це робимо для веб-магазину Angrybirds:
Англійська презентація на Magento Imagine 2012.
Німецька презентація на Meet Magento # 6.12
Прочитавши всі презентації Фабрізіо, пов'язані вище багато разів, я вважаю, що ця відповідь справді найкраща, хоча я згоден, що вона могла б використовувати більше пояснень та вилучення ключових ідей з презентацій (тим більше, що в оригіналі першого посилання вже було до моменту публікації цього оновлення був 404'd).
Єдине, що я хотів би додати до ключових понять у презентаціях, - це те, що сучасний прогрес в технологіях AWS / конкурента може запропонувати певні зміни ... як те, що Cloudfront підтримує gzip для покращення продуктивності CDN зараз, хоча це не так швидко, як ні це дає вам безкоштовне припинення SSL, як пропозиції CloudFlare . Їх маршрутизатор 53 DNS також не настільки швидкий або багатий на функції CloudFlares, а також AWS не має порівнянного брандмауера веб-додатків або захисту DDOS, які входять до пропозицій CloudFlare ...
Є кілька інших можливих способів покращити оригінальну презентацію Fabrizio, але я б не був хорошим консультантом, якби я віддав ВСЕ, що я знав на кожній публікації StackExchange, на яку я відповів, чи не так? Крім того, деякі з найновіших пропозицій істотно змінить пропозиції в оригінальних презентаціях, всі з яких STILL пропонують велику ефективність, навіть якщо більше AWS може бути витіснене із застосуванням різних варіантів.
Короткий огляд основних понять :
Знайте свої пляшки нескінченно : та оптимізуйте належним чином. Кожен рівень стека має специфічні вузькі місця (пропускна здатність, процесор, база даних), а вирішення вузьких місць на кожному рівні вимагає різного рішення, оптимізованого під кожен конкретний виклик, хоча дійсно кешування є загальним елементом на кожному рівні, що призводить до ...
Кешуйте всі речі : Використовуйте системи AWS, де це можливо (Elasticache для кешування даних Redis / Memcache типу, Cloudfront для кешування зображень, js та активи css, найближчих до кінцевих користувачів за допомогою CDN) та Varnish для прискорення відповідей екземплярів сервера до початкового рівня активів кешування запитів від CDN. Крім того, не забудьте стиснути та мінімізувати в системах розгортання ПЕРЕД розгортання на CDN
Автоматичне масштабування є важливим : попит змінюється часто та швидше, ніж ви можете контролювати та реагувати вручну. Адаптація до цих змін у режимі реального часу вимагає використання засобів автоматизації, доступних у AWS, таких як Групи автоматичного масштабування, для розкручування частин системи, які найкраще підходять для цього завдання. AWS прозоро обробляє це для CloudFront CDN, маршруту 53 DNS, еластичних балансирів навантаження та ковшів S3, вам потрібно обробити це шляхом розміщення та автоматичного масштабування для інстанцій EC2, а також просто розмір / налаштування для рівнів RDS та Elasticache
Автоматизація - це єдиний спосіб ефективно зв'язати все це разом : з такою кількістю взаємопов'язаних компонентів, деякі з яких потрібно ініціалізувати під час розгортання, а деякі відразу після розгортання, управління системою, налаштованою на оптимальну продуктивність, вимагає автоматизації. Використання системи розгортання та автоматизації систем для очищення кешу, зігрівання кешу, обробки зображень тощо - єдиний розумний спосіб керувати цією кількістю різних підсистем і підтримувати їх добре змащені та без проблем.
Але насправді навіть це неможливо без тестової автоматизації : При цьому багато рухомих частин щось порушиться практично з будь-якими змінами. І вам потрібно буде змінитись, щоб бути в курсі подій у Magento та AWS. І це відбудеться ЧИСТО . Щоб мінімізувати витрати на зміни, усі форми тестування повинні бути як впроваджені, так і автоматизовані повністю - від тестових одиниць до тесту інтеграції до функціональних тестів на основі селену фактичного сайту, запущених у фактичних конфігураціях тестування, що імітують виробниче середовище. Тепер Ви дійсно раді, що ви автоматизували всі процеси розгортання, правда?
Трохи простіше (!) Рішення - це просто встановити так, як і на будь-який інший VPS. Я пропоную безкоштовне зображення вже кілька років ... останнім часом я сконцентрувався на новому Сіднейському окрузі Колумбія через те, що він локальний - детальніше на http://www.greengecko.co.nz/magento_on_amazon_ec2, якщо ви я зацікавлений у цьому. Практично нульовий біль - початок роботи - одним клацанням і ти вже там. Наведіть веб-переглядач на примірник, щоб отримати докладнішу інформацію. Це стане хорошою відправною точкою - але загляньте та змініть /etc/rc.local, якщо ви збираєтесь будувати на ньому.
Важливо усвідомити, що екземпляри мають досить низьку потужність. Очевидно, що кидати багато грошей на додаток, це покращує це, але навіть для помірно невеликого веб-магазину середній екземпляр - це абсолютний мінімум, просто щоб отримати декілька ядер, а насправді великий - найменший необхідний.
Також зберігання Amazon відбувається повільно. Через це навіть важливіше, ніж зазвичай, доставити все, що можливо, з пам’яті: налаштування баз даних, кеш-пам’яті, що підтримуються пам’яттю, тощо.
Після того, як ви їх відсортуєте, це справно працює. вимога запуститись у VPC, якщо ви хочете> 1 IP-адреса насправді дратує (особливо, якщо ви цього не усвідомлюєте, коли ви починаєте!), і справді єдиний випадок, на який ви натрапите.
Розширити платформу "на льоту" досить просто - зрештою єдиним вузьким місцем стає об'єм процесорної потужності, доступний для PHP (неефективний код убік!), А запуск декількох "двигунів" паралельно, мабуть, найпростіший варіант - приносять додаткові послуги в Інтернеті, коли необхідні.
Насолоджуйтесь!
Стів
У нас працює RDS Multi AZ, два оптимізовані сервери NGINX, 2 сервера лаків + ELB, і на тих же серверах лаків (різний порт для лаку) SSL Nginx. Ми використовуємо Elasticache і з надією незабаром інтегруємо DynamoDB для управління сеансами Magento. Ми також використовуємо S3 та Cloudfront.
Я провів цікавий чат із британською хостинговою компанією, з якою у нас є 700 фунтів на місяць. Все, що вони роблять, - це шифер Amazon AWS. При правильному налаштуванні та оптимізації в усіх областях, включаючи відведення Magento, відключення модулів, функцію підрахунку категорій тощо тощо (ми налагодили сервери NGINX і лаки для сидіння перед сервером бази даних, який завантажує баланс).
Наразі ми можемо отримувати 2400 - 3000 + звернень за секунду на домашній, категорійній, товарній та CMS-сторінці (сторінки лаку). Не лакові сторінки, ми можемо обробляти 400 - 500 запитів в секунду в залежності від магазину. Зараз ми використовуємо RDS Multi з читаннями.
Ми також розміщуємо Magento Admin у своєму власному вузлі для запуску кронів та адміністрування трафіку. http://administraton.mymagestore.com/admin
Ми ніколи не озиралися. Ми використовували одного з найкращих у Великобританії, будь то масово дорогих господарів.
Ви можете використовувати майже всі основні сервіси AWS, щоб ваш магенто працював. Найпростішим ароматом буде використання 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. Він налаштує всю згадану безпеку, VM та мережу за лічені хвилини.