Simple Group: Как мигрировать веб-приложение и сайт в облако

Эта статья создана на основе видео в нашем Youtube-канале. Смотрите и подписывайтесь!

Спикер: Сергей Чернов, руководитель управления развития бизнес-приложений Simple Group.

О компании Simple Group

Коллеги, добрый день! Меня зовут Сергей Чернов, я руководитель управления развития бизнес-приложений Simple Group. Хочу поделиться проектом по миграции нашего e-commerce в облако.

Немного о том, что такое Simple. Simple — это один из лидеров импорта и дистрибуции вина в России. Помимо большого B2B, у нас есть более сотни винотек, свой e-commerce, рестораны, издательство, школа сомелье. В целом мы нацелены на повышение качества жизни людей за счёт развития винной культуры.

Почему решили перенести e-commerce в облако

Решение перенести наш e-commerce в облако мы приняли в 2023 году. В Чёрную пятницу у нас внезапно сгорел один из физических серверов, вся нагрузка перешла на резервную ноду, и та тоже не выдержала. В самый ответственный день года мы получили деградацию систем. Это было больно вдвойне, особенно когда пришлось объясняться с бизнесом после инцидента.

Кроме того, мы активно растём из года в год, причём очень существенно. Поэтому мощности приходится постоянно наращивать, и желательно делать это гибко и оперативно. Облако казалось подходящим выходом.

Ещё один аргумент в пользу облака — высокая сезонность спроса. Спрос в конце декабря и в июне отличается в разы. Нам хотелось так же гибко управлять и мощностями, и бюджетом на них.

Сложив все эти факторы вместе, мы решили, что переход в облако будет правильным шагом.

Какая инфраструктура была у компании

Что такое Simple? Это в первую очередь наш интернет-магазин Simple, наше мобильное приложение, B2B-порталы, порталы для премиальных клиентов, большое количество лендингов.

По сути, это порядка 80 виртуальных серверов на физических серверах, 2 ТБ памяти, 450 виртуальных процессоров.

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

Команда проекта

В итоге мы в этот проект пошли вместе с нашими подрядчиками. В части разработки e-commerce — это компания АWG, в части облака — это наши партнёры, компания OXYGEN. И, собственно, внутренняя команда, которая на себя взяла менеджмент и основную архитектуру всего проекта.

Всё было хорошо: выделен бюджет, команда, мы погнали. И начались самые интересные грабли, о которых, собственно, хочется рассказать.

С какими трудностями столкнулись во время миграции

1. Потеря ключевых участников проекта

Первый момент: почти сразу после старта проекта нас покидают руководитель проекта и технический лид.

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

Ну, мы справились, но это заняло время. Поэтому, наверное, один из выводов — берегите команду проекта, это важно.

2. Проблемы с интеграциями

Второй момент, с которым мы столкнулись, — это интеграции с внешними сервисами. Они могут работать не всегда так, как было описано.

Компания Simple более 30 лет работает, поэтому много-много всякого ландшафта у нас накопилось. И по факту интеграции с e-commerce не всегда работали так, как было документировано.

Тестировали, правили. Но этого изначально не было в планах проекта.

Поэтому вывод — закладывать силы и время на интеграционные тесты.

3. Отличия в производительности облака и физических серверов

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

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

Сняли все лимиты, повторили ещё раз тесты и пожили, наверное, с месяц на полных мощностях.

В итоге после этого по данным мониторинга подрезали мощности до реальной производительности с некоторым запасом.

Наверное, в общей сложности у нас вышло четыре таких больших масштабных нагрузочных теста.

Стресс-тесты от OXYGEN

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

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

Заказать

4. Неучтённые сервисы

Некоторые сервисы нашлись уже после запуска, причём по жалобам пользователей.

Приходит пользователь, говорит: «Знаете, у меня очень важный лендинг не работает уже неделю. Не знаете, почему?».

По нашему техническому мнению он уже давно выключен — а оказалось, что бизнес им пользуется.

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

5. Не все технологии работают в облаке так же, как на физических серверах

Ещё один неожиданный для нас вывод: некоторые вещи в облаке просто не работают так, как работали на физических серверах.

Например, у нас кластер RabbitMQ, прекрасно работающий на физических серверах, отказался работать в облаке.

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

Что получили в результате миграции

В сухом остатке у нас появилась новая архитектура решения.

• Мы научились работать с нашей инфраструктурой как с кодом на базе Terraform и Ansible. То есть следующие проекты Infrastructure as a Code для нас подобного толка уже будут сильно проще.
• Мы повысили наши мощности в части CPU примерно на 100 виртуальных ядер и сэкономили на памяти. По итогам всех наших тестов мы сэкономили порядка 500 ГБ оперативной памяти.
• Очень серьёзно мы поработали с безопасностью: сегментировали сеть, MFA, VPN, связь с корпоративными сервисами через интранет, настроили политики безопасности.
• Также мы объединили инфраструктуру в единый ЦОД с нашими другими системами. В итоге получился очень быстрый, 10-гигабитный канал между всеми нашими площадками. Это принесло много пользы с точки зрения производительности.

Бизнес-результаты проекта

В итоге производительность в облаке выросла вдвое.

Это подтвердил и сезонный пик: пользовательская нагрузка вдвое превысила прошлогоднюю, и мы прошли её идеально. У нас был большой запас по производительности, а бизнес остался в полном восторге от результатов по сравнению с прошлым годом.

Ещё одно важное достижение — мы научились гибко управлять мощностями. В сезон мы увеличивали их в разы, а когда пик закончился, сворачивали. Благодаря этому средняя годовая стоимость в облаке осталась на уровне физических серверов: общая стоимость владения изменилась в пределах 10%.

Таким образом, с технологической точки зрения проект оказался для нас очень выгодным.

Благодарности команде проекта

Хочу сказать большое спасибо нашей команде. Это команда IT Simple, команда информационной безопасности, архитекторы Simple, коллеги из AWG и коллеги из OXYGEN.

Суммарно на проект у нас было затрачено порядка 2 000 часов всеми командами.

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

С точки зрения сервиса для нас это было прям вау и классно.

Спасибо большое!

Вопросы и ответы

Вопрос из зала:

Сергей, спасибо, было очень интересно. Ресурсы, которые оптимизированы, — порядка 600 виртуальных ядер. Это пики или базовый сценарий?

Сергей Чернов:

Смотрите, ну вот это сейчас состояние на пике. Может быть, мы ещё немного догоним под Чёрную пятницу.

Вопрос из зала: 

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

Сергей Чернов:

 Нагрузка в межсезонье меньше в разы. Если смотреть по ядрам, то мы пока отталкиваемся от того, что запустили проект не так давно и вошли в сезон уже с его итогами.

Мы следим за мониторингом. Если он показывает недозагрузку, снижаем мощность, например, на 30%, и наблюдаем, как ведёт себя система. Если, скажем, после 10 января нагрузка упала ещё, мы снижаем мощность ещё раз.

Поэтому для нас переход в облако — в первую очередь вопрос экономики.