Миграция интернет-магазина в AWS — от падений VPS к аптайму 99.9%

Представьте ситуацию: запускается долгожданная маркетинговая кампания, трафик на сайте вырастает в пять раз, и ровно в момент пиковых продаж сервер перестает отвечать. Корзина висит, база данных ложится под количеством транзакций, а бизнес теряет десятки тысяч долларов в час. Знакомая боль?

Для многих растущих e-commerce проектов наступает момент, когда старая архитектура становится главным тормозом развития бизнеса. В этом материале мы подробно разберем наш миграция в AWS кейс — историю о том, как крупный украинский интернет-магазин отказался от арендованных виртуальных серверов. Мы покажем шаг за шагом, почему переезд в облако стал единственным верным решением, какую архитектуру мы выбрали, и как нам удалось добиться показателя доступности 99.9% (SLA) без космических счетов за инфраструктуру.

Исходные данные: почему VPS больше не справлялся

Нашим клиентом выступил ритейлер из топ-20 украинского e-commerce сегмента (одежда и аксессуары). До начала проекта инфраструктура базировалась на двух мощных, но статичных VPS-серверах у локального провайдера.

Стек технологий до миграции:

• Frontend/Backend: Монолитное PHP-приложение (Laravel)
• База данных: MySQL (на том же сервере, что и бэкенд)
• Кэширование: Redis (базовые настройки)
• Медиафайлы: Хранились локально на дисках сервера

Главные «боли» IT-отдела и бизнеса

1. Downtime в периоды распродаж (Black Friday, Cyber Monday). Вертикальное масштабирование (добавление CPU и RAM) требовало перезагрузки машин и занимало часы. В моменты пиков серверы просто не выдерживали I/O операций.
2. Отсутствие отказоустойчивости (High Availability). Падение основного сервера означало полную остановку бизнеса до ручного восстановления бэкапов.
3. Медленная загрузка статики. Пользователи из других регионов и стран жаловались на долгую загрузку фотографий товаров.
4. Проблемы с безопасностью. Отсутствие современного WAF (Web Application Firewall) делало сайт уязвимым к DDoS-атакам на уровне приложения (Layer 7).

Техническому директору (CTO) стало очевидно: классический хостинг исчерпал себя. Требовался полноценный переезд в облако.

Цели проекта: чего мы хотели достичь при переезде в облако?

Перед тем как начать планирование, мы вместе с бизнесом зафиксировали KPI для новой инфраструктуры:

• Доступность (Uptime): Не ниже 99.9% по итогам года.
• Масштабируемость: Автоматическое поднятие новых инстансов при росте CPU > 70% в течение 2-х минут.
• Скорость работы (Performance): Время ответа сервера (TTFB) < 200 мс.
• Безопасность: Защита от ботов, парсеров и DDoS-атак «из коробки».
• Оптимизация затрат (FinOps): Инфраструктура должна масштабироваться вниз ночью и в периоды спада активности, чтобы не платить за простаивающие мощности.

Выбор архитектуры: какие сервисы AWS мы задействовали

Успешная миграция в облако — это не просто перенос виртуальных машин «один к одному» (подход Lift-and-Shift). Чтобы получить реальную выгоду от Amazon Web Services, мы использовали подход Re-platforming, адаптировав архитектуру под cloud-native сервисы.

1. Вычислительные мощности (Compute)

Вместо голых серверов мы внедрили Auto Scaling Groups (ASG) на базе Amazon EC2. Приложение было упаковано в Docker-контейнеры, а оркестрация настроена через Amazon ECS (Elastic Container Service). Это позволило нам забыть о ручном управлении машинами. Трафик между контейнерами распределял балансировщик Application Load Balancer (ALB).

2. База данных (Database)

Самостоятельное управление MySQL — это всегда риски. Мы перевели базу данных на Amazon Aurora (MySQL Compatible).

• Почему Aurora? Она автоматически распределяет данные по трем зонам доступности (Availability Zones) и обеспечивает скорость I/O до 5 раз выше, чем стандартная MySQL. Мы настроили Read Replicas для снятия нагрузки с мастера при сложных поисковых запросах в каталоге.

3. Хранение медиа и кэширование

Все изображения товаров (более 500 ГБ) переехали в объектное хранилище Amazon S3. Для их быстрой раздачи по всему миру мы подключили CDN — Amazon CloudFront. Роль Redis взял на себя полностью управляемый сервис Amazon ElastiCache, что сняло с команды DevOps задачу по мониторингу оперативной памяти кэша.

4. Безопасность и сеть

Вся инфраструктура была развернута внутри изолированной Amazon VPC (Virtual Private Cloud). Публичный доступ имели только балансировщики (ALB), а базы данных и application-серверы находились в приватных подсетях. На входе трафик фильтровался через AWS WAF.

Пошаговая миграция в AWS: кейс в деталях

Любой переезд в облако крупного бизнеса сопряжен с риском потерять данные или уронить сайт в процессе. Мы разбили проект на 4 этапа, чтобы минимизировать риски.

Этап 1: Инфраструктура как код (Infrastructure as Code)

Мы категорически отказались кликать ресурсы руками в консоли AWS. Вся архитектура была описана с помощью Terraform. Это дало нам колоссальное преимущество: мы могли поднять точную копию production-окружения для тестирования всего за 15 минут, а после тестов — так же быстро ее удалить, не переплачивая за аренду.

Этап 2: Настройка CI/CD и контейнеризация

Чтобы разработчики клиента могли деплоить код несколько раз в день без простоев (Zero-Downtime Deployment), мы настроили пайплайны в GitLab CI. Сборка Docker-образов происходила автоматически, образы пушились в Amazon ECR (Elastic Container Registry), после чего ECS плавно обновлял контейнеры.

Этап 3: Подготовка к переносу данных (Data Migration)

Самая критичная часть — перенос базы данных без остановки продаж. Мы использовали сервис AWS Database Migration Service (DMS). Сначала мы сделали полный дамп старой БД на VPS и развернули его в Amazon Aurora. Затем AWS DMS подключился к старому серверу в режиме Continuous Data Replication (CDC). Он перехватывал каждую новую транзакцию (покупку, регистрацию) на старом сайте и мгновенно копировал ее в облако. Таким образом, обе базы были синхронизированы с задержкой менее секунды.

Этап 4: Час X — финальное переключение

Финальный переезд занял всего 15 минут глубокой ночью:

1. Мы перевели старый сайт в режим «Только чтение» (Read-Only), чтобы пользователи не могли создавать новые заказы в момент переключения.
2. Дождались, пока AWS DMS допишет последние байты данных в Amazon Aurora.
3. Изменили DNS-записи в Amazon Route 53, направив весь мировой трафик на новый балансировщик (ALB) в AWS.
4. Отключили режим «Только чтение».

Ни один заказ не был потерян. Пользователи даже не заметили, что магазин «переехал».

Результаты: цифры, которые говорят сами за себя

Спустя 3 месяца после миграции в AWS, мы провели аудит результатов. Переезд в облако превзошел ожидания бизнеса.

Самый важный бизнес-показатель: В период ближайшей крупной распродажи магазин выдержал х10 нагрузку от обычного трафика. Инфраструктура автоматически развернула 15 дополнительных контейнеров, справилась с потоком, а затем свернулась до базовых 3-х контейнеров.

FinOps: Как мы оптимизировали затраты на AWS

Частый страх IT-директоров: «Облако — это дорого. Мы разоримся на счетах от Amazon». Да, если переносить серверы «в лоб», стоимость может вырасти. В нашем кейсе миграции мы применили три стратегии снижения костов:

1. Rightsizing (Правильный подбор инстансов): Мы отказались от покупки ресурсов «с запасом». Базовая нагрузка обеспечивалась минимальным набором серверов, а остальное докупалось автоматически только по мере необходимости.
2. Reserved Instances & Savings Plans: Проанализировав постоянную нагрузку (базы данных, кэш), мы зарезервировали вычислительные мощности на 1 год вперед. Это дало скидку до 40% по сравнению с оплатой On-Demand (по требованию).
3. Использование Spot Instances: Для фоновых задач (обработка видео, генерация тяжелых отчетов для бухгалтерии) мы использовали спотовые инстансы — свободные мощности AWS, которые продаются со скидкой до 90%.

В итоге общая стоимость владения (TCO) облачной инфраструктурой оказалась на 15% ниже, чем поддержка старого парка VPS с учетом зарплат администраторов на круглосуточную поддержку.

FAQ: Частые вопросы про переезд в облако

1. Сколько времени занимает полноценная миграция в AWS? Сроки зависят от монолитности приложения и объема данных. В среднем, для крупного e-commerce проекта аудит, подготовка IaC, тестирование и сам переезд занимают от 2 до 4 месяцев.

2. Безопасно ли хранить клиентские данные в публичном облаке? Да, если архитектура спроектирована верно. Amazon Web Services соответствует строжайшим стандартам (PCI DSS, HIPAA, GDPR). Использование приватных подсетей (VPC), шифрования данных в состоянии покоя (KMS) и в транзите гарантирует безопасность на уровне банковских систем.

3. Нужен ли нам постоянный штат DevOps после переезда? Использование управляемых сервисов (PaaS/SaaS) вроде Amazon RDS, ElastiCache и ECS снимает рутину по обновлению ОС и патчингу серверов. Вам потребуется меньше «рук» для поддержки, а фокус инженеров сместится на развитие продукта и CI/CD.

4. Подходит ли AWS для небольших стартапов? Безусловно. Главный плюс облака — модель Pay-as-You-Go (плати только за то, что используешь). На старте инфраструктура будет стоить копейки, но при взрывном росте она не упадет, а легко масштабируется вслед за бизнесом.

Заключение

Разбирая этот миграция в AWS кейс, мы видим главную тенденцию: сегодня серверные мощности — это не железо, это гибкий инструмент для заработка. Использование статических серверов для динамичного бизнеса, такого как e-commerce, подобно попытке выиграть гонку «Формулы-1» на тракторе. Вы можете ехать, но на поворотах конкуренты вас обойдут.

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

Готовы трансформировать свою IT-инфраструктуру? Хватит терять клиентов из-за медленной работы базы данных и падений серверов. Доверьте аудит и переезд в облако профессионалам. Оставьте заявку на технический консалтинг, и мы рассчитаем стоимость миграции и потенциальную экономию для вашего бизнеса уже сегодня!