Rate this post

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

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

Вихідні дані: чому 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, ми провели аудит результатів. Переїзд у хмару перевершив очікування бізнесу.

МетрикаДо міграції (VPS)Після міграції (AWS)Поліпшення
Доступність (Uptime)98.5% (близько 10 годин простою на міс.)99.99%Простій зведений до нуля
Час відповіді (TTFB)600 – 800 мс120 – 150 мсПрискорення у ~4 рази
МасштабуванняРучне (займало від 2 до 4 годин)Автоматичне (до 2 хв)Вирішена проблема Black Friday
Швидкість розгортання фіч1-2 рази на тиждень (вночі)За вимогою (до 10 разів на день)Зростання Time-to-Market

Найважливіший бізнес-показник: У період найближчого великого розпродажу магазин витримав х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-інфраструктуру? Досить втрачати клієнтів через повільну роботу бази даних і падіння серверів. Довірте аудит і переїзд у хмару професіоналам. Залиште заявку на технічний консалтинг, і ми розрахуємо вартість міграції та потенційну економію для вашого бізнесу вже сьогодні!