Часть 1: Текущая архитектура

Пора!
После нескольких облачных проектов мы приступили к миграции. И не просто любая миграция ... это полноценный, гордый стек Java Spring, в комплекте с БД и всем остальным!

В прошлом, когда возникала проблема миграции монолитных Java-приложений в облако, люди думали, что на это потребуется слишком много времени, потребуется слишком много обновлений. Но сейчас 2021 год, и за последние несколько лет все кардинально изменилось. Итак, мы провели исследование и готовы представить путь перехода к контейнерной архитектуре в облаке.

Приложение, которое мы зонируем для миграции в облако, - это наше приложение Provider Management (ProvMan), приложение для управления поставщиками (то есть фермами), которые предоставляют товары для продажи через наше розничное приложение Magento. Фермеры (поставщики) используют это приложение для регистрации / отмены регистрации своих хозяйств, управления фермами, их запасами и окнами доставки.

Заявление об ограничении ответственности
I Love My Local Farmer - это вымышленная компания, вдохновленная взаимодействием клиентов с архитекторами решений AWS. Любые истории, рассказанные в этом блоге, не относятся к конкретному клиенту. Сходства с любыми реальными компаниями, людьми или ситуациями чисто случайны. Истории в этом блоге отражают точку зрения авторов и не одобрены AWS.

Как все начиналось

В 2010 году ProvMan был внедрен как одно из первых приложений нашей компании. Раньше это был просто каталог фермеров, где фермеры могли подписаться на свою ферму и управлять своим списком в Интернете.
В 2014 году MyLocalFarmer хотел реализовать рынок, где платежи проходят через MyLocalFarmer. Magento представлен как реализация из-за нехватки времени и нехватки ресурсов / опыта. Сначала наши сотрудники вручную синхронизировали данные между ProvMan и Magento, но позже мы автоматизировали этот процесс с помощью пакетных заданий.

В какой-то момент в конце 2010-х компания осознала ценность предложения миграции в облако, и поэтому за последние несколько лет ProvMan был отмечен как «устаревшая система», в то время как наше руководство решало, покупать ли замену в облаке или мигрировать что мы имеем. Это повлекло за собой переход в состояние «только техническое обслуживание», т. Е. Новые разработки были свернуты, и разрешены только обновления системы безопасности или экстренные изменения. Чтобы найти замену, необходимо изучить информацию о новых продуктах, дождаться освобождения ресурсов, документировать все, что ошибочно считалось «самоочевидным», встретиться с поставщиками и т. Д.

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

Приложение

Приложение ProvMan довольно простое: фермеры входят в систему с помощью своего пользователя / пароля, а затем получают информацию о своей ферме. Они могут:

  • обновить детали, добавить фотографии своей фермы
  • управлять своими запасами
  • настройка окон доставки для пользовательских автофургонов или автофургонов (ссылка на проект доставки)
  • отменить заказы
  • получать отчеты по их аналитике

ProvMan работает в веб-браузере, что в наши дни очень удобно, поскольку фермеры иногда обновляют свои запасы на ходу. Чтобы улучшить их взаимодействие с пользователем, несколько лет назад мы представили Bootstrap JSP, чтобы приложение было отзывчивым и хорошо выглядело на маленьких экранах.

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

Инфраструктура и интеграция OnPrem

Приложение ProvMan использует Spring MVC в качестве основы, Hibernate для доступа к базе данных, JSP для обслуживания веб-страниц для пользователей, находится на сервере приложений Tomcat. и взаимодействует с сервером базы данных MySql 5.7 в основном / резервном режиме.

В нашем центре обработки данных есть 4 виртуальных сервера, которые служат серверами приложений, которые подключаются к серверу базы данных. У нас есть F5, выполняющая циклическую балансировку нагрузки с закрепленными сеансами для перенаправления трафика на серверы приложений. Мы также используем Nagios для базового мониторинга работоспособности наших серверов приложений, приложений и сервера баз данных. При возникновении ошибок Nagios отправляет оповещения по электронной почте нашим дистрибутивам.

ProvMan взаимодействует с Magento через двусторонние пакетные процессы, которые выполняются по регулярному расписанию в ночное время. Magento создает CSV-файл о запасах, которые были проданы каждый день, который обрабатывается с помощью хранимой процедуры в базе данных MySql.

В свою очередь, база данных ProvMan генерирует еще один файл CSV с обновленной информацией о запасах и ценах для каждой фермы, которая используется Magento. Еще один файл CSV будет создан для обмена информацией о продукте и окне доставки.

Поскольку ни одна из этих интеграций не осуществляется в режиме реального времени, очевидно, что существует задержка, а также вероятность недооценки / перепродажи. Чтобы избежать обновлений, которые выполняются во время синхронизации обеих систем, мы ежедневно 2-часовой перерыв на техническое обслуживание.

данные ProvMan копируются постепенно каждую ночь, и мы также делаем полные снимки еженедельно за 3 недели, причем резервные копии хранятся в другом центре обработки данных. В настоящее время нет надлежащего аварийного восстановления. До сих пор базе данных приходилось несколько раз переключаться на отказ, что приводило к отключению около 30 минут. Во время производственного развертывания также несколько раз случался сбой, который приводил к часовым отключениям, пока мы не смогли исправить проблему или отменить развертывание.

Локальная разработка + развертывание

Вот где мы полностью упустили лодку CI / CD. Изначально сборка велась по старинке с помощью скриптов Ant, а затем через несколько лет была обновлена ​​до Maven. Развертывание в средах разработки и тестирования по-прежнему осуществляется в соответствии с общепринятой практикой того времени, то есть с помощью сценариев bash, запускаемых разработчиками вручную. Производственные развертывания выполняются сторонним поставщиком через систему продажи билетов, которую разработчики используйте, чтобы ввести заявку и отправить ее на утверждение.

О, как весело! Особенно, если вам нужно экстренное исправление ошибки ... этот процесс не предназначен для нетерпеливых.

Версия масштабирования для сервера OnPrem

Ежеквартально мы принимаем решение о том, стоит ли нам устанавливать новый сервер, в зависимости от структуры трафика на веб-сайт. Даже если трафик упадет на весь квартал (например, зимой), мы не сможем позволить себе вернуть сервер, поскольку добавление сервера слишком дорого с точки зрения эксплуатации. Это связано с тем, что, если у нас нет достаточного количества оборудования, нам может потребоваться заказать сервер, а это нетривиально. Помимо оформления документов, иногда требуются недели планирования и ожидания доставки заказа. И даже когда он здесь, есть еще более интересная часть - установка и настройка всего.

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

Решение о миграции

Теперь, когда мы рассмотрели то, что у нас есть в настоящее время, давайте поговорим о том, чего мы хотим достичь:

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

Тем не менее, мы провели комплексную проверку и исследовали несколько решений SaaS. Первый фактор, который следует принять во внимание, - это стоимость подписки, которая нанесет бесконечный урон нашему бюджету. Нам пришлось бы заменить наши зрелые пакетные интеграции на совершенно новые (не только для импорта данных и данных в систему SaaS, но и для взаимодействия с Magento), что сильно нервировало людей. Поскольку эти решения обычно достаточно универсальны, чтобы их можно было применять к разным типам систем, они могут быть сложными в настройке, а проблемы могут быть трудными и медленными для решения. Мы также поняли, что использование такого решения означало, что наши интерфейсы могут в конечном итоге выглядеть очень похожими на интерфейсы наших конкурентов, и наша способность оптимизировать рабочие процессы для наших клиентов будет ограничена, что означает, что у нас не будет уникального, индивидуального предложения в рынок больше.

Вдобавок к этому добавьте время, необходимое для того, чтобы действительно, ДЕЙСТВИТЕЛЬНО изучить эти решения, составить контракты, реализовать все и все это протестировать. Это не то, что можно сделать в условиях ограниченного времени, поэтому мы решили изучить варианты переноса кодовой базы ProvMan в облако.

Вот наши требования к миграции в облако:

  • Автоматизация сборки и развертывания, включая процесс утверждения для производства
  • Масштабирование реагирует на трафик, чтобы сократить расходы
  • Настройте нашу инфраструктуру как код (IaC), чтобы он повторялся
  • Сведите к минимуму простои во время отработки отказа или обслуживания базы данных.
  • По возможности измените интеграцию на в режиме реального времени.
  • Более надежный мониторинг состояния нашего приложения и сервера баз данных.
  • Самовосстановление при возникновении проблем (например, проблемы с памятью JVM!)
  • Исторические данные о показателях приложения и сервера базы данных (например, масштабирование, ошибки http)
  • Необходимо соблюдать рекомендации по безопасности в облаке
  • Сведите к минимуму расходы!

Дальнейшие действия

Вот и все, вот и вся история о том, где мы были и к чему стремимся.

В течение следующих недель мы расскажем, как нам удалось легко перенести наше Java-приложение на ECS Fargate, бессерверное контейнерное предложение, и как выглядит наша новая инфраструктура! Быть в курсе…!