История успешной миграции на облачную платформу Google

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

Предыстория

MeilleursAgents — платформа, обеспечивающая высококачественную информацию о французском рынке недвижимости. Мы действуем как мощный катализатор, сопоставляя людей с проектом (например, buy / sell / rent / invest) с лучшими агентствами недвижимости для своих нужд.

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

Это было самое подходящее время для подготовки к ускорению темпов внедрения инноваций.

Серверы старели, а чтобы получить новые, требовалось много времени, минимум 2 недели. Улучшить инфраструктуру в таких условиях практически невозможно. В облачном же мире мы ожили. Но у нас не было навыков DevOps, и нам нужна была помощь для успешного решения этой задачи.

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

Ключевые принципы

Определите дедлайн. В нашем случае это было 4 месяца.
Не вносите слишком много изменений. Перенеситеинфраструктуру «AS IS», а затем редактируйте ее. Это означает, что изначально ваша инфраструктура не будет идеальной, но у вас будет время для ее улучшения.
Следуйте принципам инфраструктуры как код (см. Главу «Инфраструктура в качестве кода и развертывание по клику» ниже) и автоматизируйте все, что можете.
Создайте смешанную команду (это зависит от того, какими навыками обладают ваши сотрудники). Нам не хватало навыков DevOps, поэтому мы объединились с партнером Google Cloud Platform во Франции (Skale-5) для внедрения лучших методов автоматизации и изучения облачной платформы Google. Поскольку нам было необходимо стремительно развиваться, рабочее время одного из старших инженеров и технического директора было полностью посвящено проекту, чтобы обеспечить учет всех аспектов технического стека и инфраструктуры.
Вовлекайте высшее руководство: достаточно еженедельных отчетов, даже если они технические. Делитесь всеми ключевыми аспектами проекта, включая риски и потенциальное воздействие на скорость работы команды.

Выбор подходящей платформы

Самая легкая часть проекта.

GCP, AWS и Microsoft Azure — довольно прочные платформы. Вы найдете огромное количество информации, которая поможет узнать, какая из них вам подходит.

Несколько причин, по которым мы выбрали Google Cloud Platform:

Каталог услуг был понятен и соответствовал нашим потребностям.
На GCP были размещены отзывы о подобных стартапах.
Команда Google Tech и их партнеры произвели положительное впечатление: они поняли наш контекст и составили индивидуальный план инфраструктуры с учетом сервисов GCP.
Определение четкой области миграции.

Миграция «AS IS»

Возможно, вы захотите изменить сразу все, но это довольно рискованно.

В нашем случае определение «мы мигрировали «AS IS» является не совсем правдой. Мы не вносили никаких существенных изменений в работу служб, а использовали миграцию инфраструктуры как средство для обновления основных компонентов технического стека:

PHP от 5,4 до 5,6;
все приложения Python 2 до Python 3;
PostgreSQL от 9.2 до 9.6;
Redis от 2.2 до 3.

Нам пришлось изменить несколько сервисов и компонентов инфраструктуры, которых не было в стандартах Google Cloud Platform.

Обязательные изменения в техническом стеке

Прежде мы отправляли все электронные письма через внутренние серверы postfix. Поскольку на Google Cloud Platform сделать это невозможно, мы перешли на известную службу электронной почты Sendgrid. В этом нет ничего сложного, за исключением того, что в рамках управления проектами придется думать наперед.

В качестве платформы для недвижимости мы полагались на Netapp, чтобы хранить фотографии (листинг, прошлые продажи и т.д.). Поскольку это означало бы большие изменения в базе кода (мы не могли перенести данные в хранилище облачных объектов Google), мы пошли на альтернативу — GlusterFS.

Инфраструктура как код & развертывание по клику

Инфраструктура как код — не выход. Мы хотели защитить миграцию и гарантировать, что она будет самодокументирована и проста в развертывании и обслуживании. Получение экспертных знаний по методам DevOps было весьма полезным. Команда научилась использовать Ansible, и мы добавили задачи развертывания на сервер Jenkins, который уже строил все наши приложения. Сценарии (как и остальная часть нашей базы кода) управляются на Github с помощью Pull Requests для проверки изменений.

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

Github;
Jenkins для непрерывной интеграции и построения оркестровки с прямой обратной связью с Github для каждого Pull Request;
Docker для dev-контейнеров;
Ansible для написания сценариев инфраструктуры и развертывания приложений.

Процесс сборки и развертывания:

Стандартизация сборки

Чем более однородны сценарии для упаковки приложений, тем проще конфигурация развертывания Ansible.

В нашем стеке приложений мы используем 2 основных языка: Python и PHP. Для обоих языков мы полагаемся на строго аналогичные Makefile, чтобы использовать, тестировать и упаковывать приложения. Стандартизация стала сложной объемной задачей, но и ключевым фактором успеха, чтобы мигрировать без серьезных проблем.

Работа над процессами и культурой

Архитектура

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

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

Эта стратегия — противоположность философии облачной системы.

Поскольку мы переносили инфраструктуру AS IS, мы стали разделять сервисы на меньшие компоненты: код и его инфраструктуру.

Это необходимо для масштабирования по мере роста трафика.

Навыки DevOps

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

С первого дня мы предоставили разработчикам полный доступ к облачной платформе Google, чтобы они могли привыкнуть к ней. Наиболее распространенное использование — вычисление экземпляра ядра, тестирования и чистка.

Подготовка к важному дню

Очевидно, подготовка будет выглядеть как запуск, перезапуск и ещё один перезапускмиграций. Придерживайтесь этой стратегии. Мы были слишком уверены в некоторых «простых» сервисах, и почти каждый из них должен был быть исправлен сразу после миграции. Да, я уверен, что вы знаете: «нет необходимости проверять миграции, если развертывание работает».
Выполняйте огромные QA на производственной среде и просите как можно больше сотрудников компании выполнять ежедневную работу на платформе. Это нужно для того, чтобы чувствовать себя комфортно при миграции.
Производительность и тестирование нагрузки не подлежат обсуждению. Если у вас нет времени для создания пакета тестов производительности (например, с Gatling), можно эффективно использовать веб-журналы и несколько домашних сценариев для воспроизведения реального трафика и поиска пределов системы.
Определите, подходит ли вам время простоя. Это оказывает большое влияние на сценарий миграции. Мы выполняли миграцию в основном в выходные дни.
Определите команду, ответственную за миграцию, и уточните роль каждого.
После завершения миграции отслеживайте все и закрепите за членами команды обязанности по устранению проблем. У нас было много проблем, но в целом ничего серьезного.

Миграция — только начало

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

Мы уже осуществили некоторые изменения:

Поскольку одна из основных особенностей нашей платформы основана на расширенном использовании карт, мы в значительной степени используем Cloud CDN для кеширования наших фрагментов карты.
Раздробили сервисы для облегчения анализа в случае возникновения проблем и избежания потенциальных побочных эффектов.
Заменили стандартный реест Docker на Google Container Registry.

В ближайшие недели мы будем все больше полагаться на управляемые сервисы:

Мы активно изучаем Google Cloud Storage, чтобы избавиться от кластера GlusterFS.
Управляемый PostgreSQL, все еще находящийся в бета-тестировании на GCP, будет тестироваться, как только достигнет GA. Это была бы отличная возможность избежать сложных задач администрирования в базе данных.
Мы выбрали Google App Engine.

Преимущества

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

Преимущества:

Это позволяет нам адаптироваться к росту трафика. Теперь мы в состоянии реорганизовать инфраструктуру и полагаться на классические шаблоны масштабирования.
Это был идеальный момент для индустриализации всех аспектов управления инфраструктурой: это огромное увеличение скорости, поскольку все процессы инфраструктуры и развертывания теперь версируются и воспроизводятся.
Для наших новых проектов создание базовой инфраструктуры уже не проблема.
Что касается производительности, без существенной реорганизации базы кода мы сократили время отклика в 2 раза.
Работать с командой разработчиков легче: будь то для POC или необходимость создания дампа базы данных по запросу, чтобы что-то исследовать (снимки диска из 700+ Go PostgreSQL просто быстро растут), все становится делать намного проще.