Yugabyte спонсировала этот пост.
Путь от проверки концепции к системе промышленного уровня демонстрирует знакомую закономерность в корпоративном программном обеспечении. Команды стремятся к тому, чтобы продукт соответствовал рынку, а затем тратят годы на устранение операционных проблем, которые они изначально не планировали.
В автомобильной промышленности, где решения, принимаемые платформой данных, влияют на миллионы пользователей ежедневно, решение этой задачи становится еще более важным, что делает эффективное управление данными критически важным.
Будучи директором по разработке платформ в крупной автомобильной компании, я жил в этой реальности. Я работал над решением внутренней платформы разработчиков (IDP), которое обеспечивает баланс между скоростью и устойчивостью предприятия. В процессе разработки мы поняли, что выбор правильной архитектуры распределенной базы данных не менее важен для успеха нашей платформы.
Вызов
Продукты часто начинаются с поиска соответствия рынку, уделяя мало внимания масштабу, устойчивости или качеству. Мы быстро создаем, выполняем итерации и в конечном итоге находим соответствие рынку, но прежде чем мы это узнаем, наш POC уже запущен в производство.
Я испытал на себе последствия этого: разрозненные команды, фрагментированный инструментарий и инженеры, которые тратят больше времени на управление инфраструктурой, чем на обеспечение бизнес-ценности. Мы все участвовали в телефонных звонках по реагированию на инциденты с сотнями людей, которые начинались с вопроса: «Кто-нибудь объединял код за последние 20 минут?»
Этот оперативный труд коренным образом изменил способ распределения инженерных ресурсов, отвлекая таланты от инноваций к оперативному обслуживанию. Решение этой проблемы потребовало переосмысления как архитектуры нашей платформы, так и уровня данных.
Создание Фонда для внутренне перемещенных лиц
Вместо того, чтобы навязывать жесткие стандарты, мы создали централизованную платформу, которая обеспечивает надежность, безопасность и управление непосредственно в рабочем процессе разработчиков. Наша архитектура включала в себя четыре ключевых элемента:
- Стандартизированные SDLC и CI/CD оптимизированные конвейеры доставки с автоматизированными циклами обратной связи, сокращающие ручное вмешательство между командами.
- Декларативная инфраструктура посредством принципов «Инфраструктура как код», которые предоставили разработчикам простой интерфейс для сложных операций подготовки.
- Централизованная наблюдаемость унифицированные метрики и журналирование, что значительно сокращает среднее время восстановления за счет устранения необходимости коррелировать данные из разрозненных систем.
- Встроенная безопасность и аварийное восстановление, автоматизированные проверки соответствия и шаблоны устойчивости, которые устраняют повторяющиеся задачи, обеспечивая при этом защиту корпоративного уровня.
Мощь внутренней платформы разработки заключается в уровнях абстракции, в частности в модели открытого приложения (OAM). Эта платформа позволяет разработчикам определять приложения на основе их характеристик, включая службы, конфигурации и требования к хранению. Это имеет больше смысла, чем особенности времени выполнения.
Начнем с вопроса: что на самом деле определяет приложение? Это не просто среда выполнения, будь то развертывание Kubernetes или контейнер Docker. Приложениям также требуются служебные объекты, ConfigMaps, PersistentVolumeClaims и многое другое.
Организовав эти компоненты как свойства многократного использования, OAM позволил нашим командам по облачной инфраструктуре самостоятельно развивать платформу, в то время как команды разработчиков приложений поддерживали стабильные API. Крайне важно, чтобы этот архитектурный шаблон распространялся на уровень данных.
Почему архитектура базы данных была критически важной
Для автомобильных приложений, обслуживающих миллионы пользователей, выбор базы данных имеет стратегическое значение. Неправильный выбор создает узкие места в работе, ограничивает гибкость развертывания и создает единые точки отказа, которые подрывают устойчивость всей нашей платформы.
У нас были особые требования, которым не могли удовлетворить стандартные подходы к базам данных:
- Суверенитет данных Требования требовали, чтобы данные оставались в определенных географических регионах для соблюдения нормативных требований, исключая централизованные службы баз данных.
- Гео-распределение не подлежит обсуждению для нашей автомобильной платформы, где пользователи охватывают разные континенты, а задержка напрямую влияет на взаимодействие с пользователем.
- Операционная последовательность с нашей облачной архитектурой требовалась база данных, которая соответствовала бы собственным шаблонам Kubernetes, а не боролась с ними.
- Совместимость с PostgreSQL позволило нашим командам использовать имеющиеся навыки и инструменты без переобучения и необходимости полной переписывания приложений.
Оценка параметров распределенной базы данных SQL
Прежде чем выбрать YugabyteDB, мы оценили PostgreSQL, Google Spanner и CockroachDB. Каждый вариант представлял собой разные компромиссы.
- Стандартный PostgreSQL был привычным, но не имел встроенного географического распределения и требовал сложного внешнего управления репликацией.
- Google Spanner обеспечивал географическое распределение, но привязал нас к Google Cloud и потребовал от нас принять новый диалект SQL.
- CockroachDB предлагал дистрибутив, но имел пробелы в совместимости, которые требовали внесения изменений в приложение.
Мы выбрали YugabyteDB в первую очередь из-за суверенитета данных, учитывая характер наших данных, а также различные факторы, связанные с топологиями развертывания и встроенной репликацией.
Архитектура YugabyteDB идеально соответствует нашему видению IDP и обеспечивает:
- Встроенная совместимость с PostgreSQL
- Гибкие топологии развертывания в нескольких облаках
- Встроенная репликация данных без внешней оркестрации.
Крайне важно, что YugabyteDB можно было бы управлять декларативно с помощью тех же операторов Crossplane, которые мы использовали для другой инфраструктуры.
Интеграция распределенного SQL с открытой моделью приложения
Мы разработали интеграцию базы данных в соответствии с шаблоном OAM через трехуровневую архитектуру, которая рассматривает инфраструктуру базы данных как декларативные ресурсы платформы:
API плоскости управления
API плоскости управления централизует управление ресурсами, подготовку экземпляров базы данных, создание учетных записей служб и управление ключами API. Этот уровень предоставляет возможности базы данных через тот же декларативный интерфейс, который разработчики используют для вычислительных ресурсов и ресурсов хранения.
API плоскости данных
Data Plane API управляет жизненным циклом кластеров YugabyteDB, организуя операции масштабирования, резервного копирования и восстановления. Это позволяет нам настраивать политики аварийного восстановления, топологии репликации и расписания резервного копирования, которые применяются автоматически без вмешательства разработчика.
Декларативные ресурсы YugabyteDB
Декларативные ресурсы YugabyteDB управляются через операторы Crossplane для абстрагирования конфигураций базы данных, управления ролями и контроля безопасности в повторно используемые компоненты. Разработчики могут указать требования к базе данных (размер, коэффициент репликации, географическое распределение и т. д.), а платформа предоставляет соответствующим образом настроенные кластеры.
Этот процесс превращает YugabyteDB в примитив платформы, которую разработчики могут использовать без опыта работы с базами данных. Когда разработчик заявляет, что ему нужна геореплицируемая база данных с репликами чтения в трех регионах, он просто определяет эти требования, а платформа обрабатывает детали реализации.
Результат
Наши архитектурные инвестиции принесли измеримые результаты как в производительности разработчиков, так и в операциях с базами данных:
- Операционное упрощение произошло за счет отказа от ручного предоставления и настройки базы данных. Команды, которые раньше тратили несколько дней на настройку репликации PostgreSQL, теперь получают готовые к работе распределенные базы данных за считанные минуты.
- Встроенная устойчивость означало, что аварийное восстановление и переключение при сбое стали возможностями платформы, а не проблемами каждого приложения. При возникновении региональных сбоев автоматический переход на другой ресурс происходит без участия разработчика.
- Аналитика в реальном времени возможности улучшены благодаря распределенной архитектуре YugabyteDB. Мы можем независимо масштабировать емкость чтения, поддерживая как транзакционные рабочие нагрузки, так и аналитические запросы без снижения производительности.
- Ускоренный выход на рынок в результате устранения проблем с управлением базой данных. Команды, выпускающие новые сервисы, больше не блокируют подготовку базы данных и не тратят спринты на реализацию логики репликации.
Уроки по платформенной инженерии
Наш опыт работы над этим проектом преподал нам важный урок: успех или неудача внутренних платформ разработчиков зависит от их самого слабого компонента инфраструктуры. Сложный IDP с плохой архитектурой базы данных создает узкие места, которые подрывают ценность всей платформы.
Ключевым моментом является выбор технологий, соответствующих модели вашей платформы. Для облачных платформ, построенных на декларативной инфраструктуре и уровнях абстракции, базы данных должны интегрироваться как управляемые ресурсы платформы, а не как внешние зависимости, требующие специальных знаний.
Наша цель была простой: предоставить разработчикам инструменты, необходимые для быстрого предоставления согласованных, надежных и безопасных решений. Когда разработчики добиваются успеха, естественно, следует и бизнес.
Для организаций, создающих возможности разработки платформ, мой совет прост: инвестируйте в равной степени в абстракции платформ и в инфраструктуру, которой они управляют.
Уровень базы данных — это больше, чем просто хранилище; это базовая инфраструктура платформы, определяющая возможности уровня приложения. Выбирайте мудро, абстрагируйтесь вдумчиво и с легкостью принимайте будущие архитектурные решения, встраивая их непосредственно в вашу платформу с самого начала.
Встречайте YugabyteDB, распределенную базу данных, совместимую с PostgreSQL, для ваших облачных приложений. Отказоустойчивый, масштабируемый и гибкий. Узнайте больше Последние новости от Yugabyte ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Гаурав Саксена — лидер в области разработки платформ и облачных технологий с более чем 20-летним опытом работы в индустрии программного обеспечения. Его технический опыт включает в себя потоковую архитектуру, Kubernetes, сервисную сетку, разработку данных, безопасность цепочки поставок программного обеспечения и… Подробнее от Гаурава Саксены
