Как перенести инфраструктуру с классических виртуальных машин на контейнеры, управляемые Kubernetes

Эта запись в блоге посвящена тому, как ChartMogul удалил последние элементы инфраструктуры в DigitalOcean, пометив переход на AWS как завершенный.

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

В серии статей мы поделимся своим опытом о:

• Наш путь к AWS EKS (управляемый сервис Kubernetes).

• Некоторые из наиболее важных препятствий, с которыми мы столкнулись.

• Наш текущий стек и инструменты.

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

Жизнь с DigitalOcean

С момента создания в 2014 году и до середины 2021 года вся наша инфраструктура работала на дроплетах DigitalOcean (самоуправляемых облачных виртуальных машинах). Нам нужен был облачный провайдер, который быстро, надежно и экономично начал работу.

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

Каждый аспект нашей инфраструктуры был подготовлен, настроен и управлялся собственными силами. Для управления вещами мы использовали управление конфигурацией и инструменты «Инфраструктура как код» (Saltstack и Terraform).

С годами мы продолжали расти, и к 2019 году мы столкнулись с парком из примерно 50 машин, которые постоянно нуждались в управлении, обновлениях программного обеспечения, исправлениях безопасности и так далее. Мы ожидали, что к концу 2020 года наша вычислительная мощность должна удвоиться, учитывая новые проекты, находящиеся в стадии разработки.

Зачем переезжать и почему сейчас?

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

Различные сбои

• Специальные необъявленные окна обслуживания, которые внезапно остановили производство.

• Аппаратные сбои в нескольких случаях, влияющие на нашу первичную настройку базы данных реплики (например, дроплеты переходят в «состояние динамической миграции на другие аппаратные машины» без предварительного уведомления, что означает 1-2 часа простоя для этого дроплета.)

• Необъяснимые сетевые проблемы с задержкой между нашими машинами, которые команда поддержки DigitalOcean так и не устранила (это было критически важно для нашей задержки реплик чтения Postgres, экземпляров Redis и высокой доступности в целом).

Устаревший регион AMS2

Наш регион DigitalOcean (AMS2) был объявлен «скоро выведенным из эксплуатации», что означает ограниченную поддержку. Мы не могли получить дополнительные ресурсы по запросу, а выполнение простых задач обычно означало длительное планирование и трату ресурсов.

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

Ограниченный выбор оборудования

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

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

Отсутствие современных облачных функций и управляемых услуг

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

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

Должны ли мы остаться или должны мы уйти?

Мы начали изучать преимущества пребывания в DigitalOcean и просто переезда в новый регион — более неторопливый, быстрый, дешевый и менее болезненный вариант.

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

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

• Гибкость автоматического масштабирования вычислительных ресурсов.

• Управляемые базы данных.

• Предоставление ресурсов на основе временного использования.

• Низкая задержка.

• Сервисная совместимость.

• Контейнерная инфраструктура с оркестровкой Kubernetes.

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

Почему AWS?

Выбор нового облачного провайдера для инфраструктуры ChartMogul был долгим. Мы исследовали рынок и обнаружили множество компромиссов и преимуществ, которые может предложить новый поставщик.

Нашими вариантами были Amazon Web Services (AWS), Google Cloud (GCP) и Azure. В конце концов, мы решили использовать AWS. Мы перечисляем некоторые из основных причин ниже.

Опыт команды

Мы уже использовали некоторые сервисы AWS в производственной среде (например, S3 для хранения инкрементных резервных копий Postgres). Что еще более важно, некоторые из наших инженеров ранее имели профессиональный опыт использования различных сервисов AWS в производственных системах.

Масштабируемость

• Мы можем увеличивать или уменьшать количество экземпляров AWS одним нажатием кнопки.

• Мы можем мгновенно выделять такие ресурсы, как базы данных RDS и временно вычислять ресурсы.

• Мы можем быстро проводить эксперименты и проверку концепций.

• Гибкость и масштабируемость пулов узлов Kubernetes, поддерживаемых автоматическим масштабированием EC2, трудно превзойти.

Безопасность данных и соответствие нормативным требованиям

Безопасность данных всегда была на первом месте. За прошедшие годы возможности безопасности AWS существенно расширились.

Количество новых сервисов, разработанных AWS для обеспечения безопасности данных, покрывает большую часть наших потребностей в области контейнеров/Kubernetes.

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

Что касается соответствия, мы планируем получить сертификат SOC II как можно скорее, и мы считаем, что AWS [программы соответствия] (https://aws.amazon.com/compliance/programs/) являются преимуществом, которое может помочь ускорить этот процесс.

Управляемые службы

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

Высокая доступность и надежность баз данных становились все более опасными, поэтому мы решили оценить несколько предложений от крупных облачных провайдеров с управляемым PostgreSQL. AWS RDS стал явным победителем.

Управляемый Kubernetes был еще одним важным фактором, который необходимо учитывать, и это было на равных с Google Cloud (GCP). Управляемый Google Kubernetes (GKE) чувствовал себя лучше, чем то, что было у AWS в то время, но сравнение RDS с CloudSQL не было близким по функциональности.

Однако в настоящее время кажется, что AWS догоняет EKS; Мы извлекаем выгоду из замечательных функций RDS, таких как гибкость моментальных снимков, надежность резервного копирования (с соглашением об уровне обслуживания), реплики чтения для Postgres, безболезненные обновления, выделенный IOPS, метрики Cloudwatch, Performance Insights и этот список можно продолжить.

Безумное количество сервисов AWS

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

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

Аварийное восстановление

Облако AWS — неотъемлемая часть нашего плана аварийного восстановления. Это связано с тем, что инстансы легко разворачивать, мы можем повышать реплики чтения RDS до первичных одним нажатием кнопки, делать моментальные снимки очень просто, мы можем размещать их в нескольких регионах, и у нас есть первоклассная интеграция с нашим инструментом IaC для выбор.

Кредиты AWS

Мы получили кредиты на сумму 100 000 долларов США в рамках программы AWS Startup. Мы смогли спланировать, протестировать и завершить миграцию без значительных затрат.

Миграция на AWS

Наш переход с DigitalOcean на AWS занял десять месяцев. Все усилия были поддержаны добровольцами из всех наших инженерных команд и управлялись инженером DevOps, бэкэнд-инженером и нашим руководителем инженерного отдела.

Некоторые вещи включали пробы и ошибки. Мы пробовали несколько способов:

• Перемещение данных из Postgres в RDS с почти нулевым временем простоя.

• Перенос нашего приложения и сервисов с архитектуры на основе виртуальных машин на контейнерную архитектуру в Kubernetes.

• Принципиально изменить способ развертывания.

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

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

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

Тщательное планирование тоже творило чудеса; Учитывая наши возможности, мы заранее установили, что лучше всего будет разбить фактическую миграцию на три этапа (или дня).

За неделю до дня "Д"

• Запустите репликацию Postgres из DigitalOcean в экземпляры RDS.

• Просмотрите нашу будущую производственную инфраструктуру AWS.

• Конфигурация секретов (хранилище параметров AWS).

• Убедитесь, что конвейеры CI/CD готовы к развертыванию в наших новых кластерах Kubernetes.

За день до дня "Д"

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

• Заранее переместите некоторые данные (например, DigitalOcean Spaces на S3).

• Обновите все секреты хранилища параметров до производственных значений.

• Подготовьте изменения DNS.

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

Д-день: щелкнуть выключателем

• Перенаправить все веб-перехватчики на временный рекордер AWS.

• Остановите все службы в DigitalOcean.

• Подождите, пока репликация Postgres догонит последние обновления.

• Сравните данные DigitalOcean и RDS Postgres (чтобы обеспечить целостность и репликацию).

• Отменить подписку с RDS на Postgres, работающий в DigitalOcean.

• Создание реплик чтения RDS.

• Обновите секреты нашего хранилища параметров новыми конечными точками и секретами RDS.

• Разверните в Kubernetes и перезапустите PgBouncer, чтобы загрузить новые конфигурации.

• Переключите записи DNS для app.chartmogul.com на AWS.

В этот момент мы запускали производственную рабочую нагрузку в новой блестящей инфраструктуре! Мы закончили все это дело за 10 часов (сначала мы рассчитывали на 8 часов — неплохо).

Проблемы с AWS

Самая большая проблема была со службой DMS (управляемая служба AWS для перемещения баз данных в RDS).

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

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

Подробнее об этих нестандартных подходах в следующих статьях.

Будущие статьи в серии

Следите за будущими статьями, описывающими наш переход с DigitalOcean на AWS. Мы коснемся таких тем, как:

• Почему мы выбрали Kubernetes для поддержки ChartMogul.

• Как мы перенесли PostgreSQL на RDS.

• Как мы перенесли наше приложение Rails на Kubernetes.

• Как мы настроили IPSEC-туннель к AWS VPC.