О том, какие моменты необходимо учитывать при проектировании архитектуры микросервисов с платформой данных реального времени, на портале The New Stack рассказывает Анхель Камачо, директор по маркетингу продуктов компании Redis.

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

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

Рост данных реального времени

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

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

К числу распространенных сценариев использования относятся:

  • Персонализация. Приложения, предоставляющие индивидуальные рекомендации и предложения на заказ, стали нормой в постпандемическую эпоху, а еще раньше — в индустрии онлайновой розничной торговли или в любой системе, которая вносит коррективы на основе поведения пользователя.
  • Принятие решений. Системы, использующие данные реального времени для принятия решений, чрезвычайно ценны на финансовых, промышленных и медицинских рынках для совершения сделок, минимизации рисков и улучшения результатов лечения пациентов.
  • Системы мониторинга. Это могут быть системы промышленного контроля или отслеживания киберугроз, позволяющие администраторам реагировать на изменяющиеся сигналы для сокращения времени простоя или повышения безопасности, выявления мошенничества или аномальных закономерностей, на что в противном случае потребовалось бы слишком много времени.
  • Совместная работа в реальном времени. Людям необходим быстрый отклик в удаленных средах совместной работы. Пандемия подчеркнула необходимость обеспечения конференц-связи, доступа к документам и их редактирования в режиме реального времени для компаний любого размера.
  • Приложения ИИ/МО. Векторные базы данных и онлайновые хранилища функций предоставляют данные реального времени для моделей машинного обучения, включая большие языковые модели (LLM), на основе которых работают чатботы, виртуальные помощники и поиск документов.

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

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

Что подразумевается под эффективностью?

Время работы? Пропускная способность? Масштабируемость? Стоимость? Ответов много. Это многомерная проблема, имеющая две основные составляющие: производительность и операционализацию.

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

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

Пользователи отказываются от приложений и сайтов, которые кажутся им медленными. Задержки даже в несколько секунд существенно влияют на пользовательский опыт.

Вы, наверное, думаете: «А как соотносится традиционная база данных с платформой реального времени? И как это связано с микросервисами?».

Архитектура микросервисов предполагает наличие группы небольших и независимых сервисов, часто слабо связанных между собой, предназначенных для выполнения минимального набора функций, отсюда и их название — «микросервисы». Эти микросервисы связаны между собой через легкие API для обмена сообщениями, получения и отправки запросов или ответов. Полезной нагрузкой этих сообщений являются данные, которые необходимо перемещать между ними, — слой данных.

Какие моменты необходимо учитывать при проектировании архитектуры микросервисов с платформой данных реального времени?

Простой ответ — планировать эти два основных аспекта: производительность и операционализацию.

Производительность

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

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

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

  • Модели данных. Требуется ли вашему приложению несколько представлений данных? Строки, списки или JSON?
  • Репликация данных. Нужны ли вам несколько копий данных для повышения доступности?
  • База данных «active-active». Если у вас есть удаленные пользователи, нужны ли вам геораспределенные данные?
  • Масштабируемость. Готовы ли ваши приложения и слой данных реагировать на неожиданные или сезонные потребности?

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

Следующий момент, который необходимо рассмотреть, — это то, как вы будете управлять этой сложной архитектурой.

Операционализация

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

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

В заключение

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

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