Как стать автором
Обновить

Бессерверные БД: зачем переводить Stateful-сервис в Serverless

Анализ и проектирование систем *Администрирование баз данных *Amazon Web Services *Google Cloud Platform *Serverless *

Сегодня бо́льшая часть production-решений продолжает резервировать собственные мощности под базы данных. Да, это надёжно и привычно, но тем не менее всё больше проектов обращается к бессерверным инструментам, в том числе и к базам данных. Создатели находят этим инструментам применение в распределённых приложениях и микросервисах, где важна скорость разработки и возможность масштабирования. 

Бессерверные базы данных развивались последние несколько лет параллельно с бессерверными вычислениями, и сейчас можно условно выделить два типа СУБД: адаптирующие популярные базы данных под бессерверное использование и разработанные под бессерверный режим. В этой статье я расскажу об их особенностях и дам примеры применения.

Ключевые особенности бессерверных СУБД

Бессерверные СУБД — Managed-сервисы для баз данных с выбором бессерверного режима и всеми наследуемыми характеристиками: простота в обслуживании, масштабируемость, отказоустойчивость. При этом по каждому пункту бессерверные базы данных имеют преимущества. Рассмотрим подробно.

Простота в обслуживании. На просторах интернета можно встретить такие заявления, что облачная архитектура — NoOps-решение. Отчасти это так, облачный провайдер берёт на себя львиную долю работы по обслуживанию. В части бессерверных СУБД вы даже не выбираете оборудование, потому что не нужно резервировать мощности. Для компаний с администраторами баз данных можно говорить, что появляется возможность заниматься бизнес-логикой. Важно понимать: кроме обслуживания, есть ещё непосредственная работа с базой, и в зависимости от класса СУБД (SQL, NewSQL, NoSQL) сложность будет разная. Последний требует опытного специалиста в NoSQL, который поможет не собрать на пути все грабли. 

Масштабируемость. Про бессерверные СУБД ещё добавляют — бесконечная. Возможно, это немного преувеличено. Хотя даже SQL-решения имеют в несколько раз превосходящую пропускную способность в сравнении с обычными SQL СУБД, все классы СУБД ограничены пропускной способностью и размером контейнеров. Но архитектура самих бессерверных СУБД разная, поэтому упереться в предельные значения при резервируемых квотах и грамотном проектировании первичного ключа становится невозможным. Тем более что вы опять же не выбираете мощность оборудования. 

Отказоустойчивость. Стандартный набор от облачного провайдера: минимум три зоны доступности, резервное копирование и автоматическое восстановление. В бессерверном режиме вы определённо будете платить за дополнительные резервные копии. У некоторых провайдеров и автоматические резервные копии выделены отдельно из стоимости услуг. В таком случае главное — не забыть оформить эту услугу.

Отличительной особенностью бессерверных баз данных является экономическая эффективность перед Managed-сервисами. В бессерверной архитектуре клиент платит не за резервируемые мощности, а за операции чтения, записи, удаления и (или) время активной работы. Такой подход позволяет более точно рассчитать экономику проекта в условиях невозможности спрогнозировать масштабы. Снимается боль бизнеса — оплата мощностей за время простоя. Но на первое место выходит сложность операций, выполняемых с данными. И здесь важны сразу два аспекта: время обработки запроса и рост стоимости от сложности.

При этом в бессерверном режиме остаётся оплата за хранение данных, восстановление из резервной копии и исходящий трафик. Но это не противоречит пункту об экономии, расчёт будет по фактическим ГБ.

Получается, что привычный Stateful-сервис в бессерверных СУБД разделён на хранение данных, что всё ещё относится к Stateful-части, и обработку. Последнее — Stateless: запрос пришёл — запрос обработан — ответ получен — всё уничтожено.

Базы данных: сравнение основных решений

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

Отсутствие у команды опыта с классом СУБД или конкретной реализацией — основная причина неверного выбора бессерверной базы данных. Осознанный выбор даже между реляционными базами может дать дополнительные преимущества для приложения.

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

Amazon Aurora Serverless

Aurora Serverless — это изначально реляционная база данных, которую переписали под облака, затем доработали бессерверную версию со всеми вытекающими плюшками. Ключевой особенностью представляется совместимость с MySQL и PostgreSQL. Выделены две версии, на выбор. Amazon Aurora является частью сервиса Amazon Relational Database Service (RDS), поэтому есть интеграции с MariaDB, Oracle и SQL Server. 

В сухом остатке Aurora не совсем полноценная бессерверная СУБД. Это всё та же MySQL или PostgreSQL с повышенной пропускной способностью и возможностью выбора бессерверной оплаты за объём хранилища, ресурсы БД и операции ввода/вывода, которые база данных использует во время активной работы.

Amazon DynamoDB

DynamoDB уже 4 года назад была интересна для разработчиков бессерверных приложений за счёт интерфейса, минимальной настройки на старте и NoSQL. Аргумент по части NoSQL такой, что бессерверные приложения по большей части в стартапах, когда нет истории, нет понимания будущей модели данных, прогнозов трафика. Но мнения формировались неоднозначные, совсем без понимания разработчиками NoSQL нельзя.

Несмотря на отличную масштабируемость и производительность, отсутствие SQL и есть главный минус DynamoDB. В остальном эта СУБД занимает лидирующее положение, отчасти из-за удобства построения всей архитектуры приложения в AWS.

Azure Cosmos DB

Cosmos DB — NoSQL база данных Microsoft с документ-ориентированным API. С одной стороны, есть интерфейсы API с открытым кодом для MongoDB и Cassandra, с другой — SQL API. Это не позволяет делать SQL-запросы в чистом виде, есть некоторые отличия языка, но то, что есть возможность работать с разными моделями данных в едином сервисе, без мучений выбора и сомнений «подойдёт ли для нас», — сильное преимущество. Притом что Cosmos не теряет в производительности, масштабируемости и доступности.

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

Yandex Database

YDB — распределённая NewSQL СУБД. YDB поддерживает реляционную модель данных и оперирует таблицами с предопределённой схемой. При этом поддерживается строгая консистентность и распределённые ACID-транзакции. Важно отметить, что поддерживается язык запросов YQL (Yandex Query Language), диалект SQL и API сервиса в режиме бессерверных вычислений совместим с API Amazon DynamoDB, с помощью этого API можно выполнять операции над документными таблицами.

Google Firestore

Cloud Firestore — это база данных NoSQL от Google Cloud Platform, основанная на Firebase, которая разработана в первую очередь для веб-приложений и мобильных приложений, но при этом подходит для общего использования на стороне сервера.

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

FaunaDB

FaunaDB — транзакционная СУБД от Twitter, она не является частью существующего крупного поставщика облачных услуг. Для запросов создан FQL — это функциональный язык запросов, созданный для расширенной обработки данных. 

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

Astra DB

СУБД от DataStax, в основе Apache Cassandra — NoSQL-база данных с открытым исходным кодом. DataStax предоставляют базу данных в качестве услуги, при этом есть возможность развёртывания в AWS, GCP или Azure. 

Для запросов можно использовать CQL или написанный DataStax API GraphQL, последний предполагает увеличение производительности базы данных. 

Что можно сделать с бессерверными СУБД

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

Масштабирование при пиковых нагрузках в e-commerce

Стартап из Индонезии The Shonet, социальная сеть и e-commerce, вырос до 3 млн пользователей и перед внедрением в проект e-commerce перешёл на беcсерверный подход в архитектуре. Решение было связано с пиковыми периодами покупок.

Экономия на отсутствии резервируемых мощностей в периоды падения трафика

Clive, надстройка к Cascade CMS, — приложение, позволяющее пользователям CMS создавать формы без программирования и персонализировать контент. Объём трафика Clive варьируется в 10 раз в течение суток.

Сокращение времени простоя и потери производительности до нуля

Компания Pokémon Company первоначально выбрала NoSQL и столкнулась со сложностью поддержки бесперебойной работы узлов. Выбор SQL-решения позволил сократить узлы с 300 до 30 и свести к нулю время простоя и снижения производительности.

Освобождение ресурсов эксплуатации баз данных для работы с бизнес-логикой

Перед FINN.no, крупнейшим сайтом объявлений в Норвегии, стояла задача перенести приложение с базой данных Apache Cassandra в облако, чтобы сосредоточиться на разработке, а не управлении инфраструктурой. Приложение поддерживает около двадцати процентов трафика на сайт, это порядка 10 млн посещений в месяц.

Решение проблемы масштабируемости без роста стоимости услуги

Dropbox в 2018 году столкнулся с нехваткой ёмкости в своём локальном хранилище метаданных. Одним из решений было найти легко масштабируемый вариант, не увеличив расходы. Выбор пал на хранилище данных S3 и NoSQL СУБД. Интересный итог: сокращение стоимости одного гигабайта пользователя в 5,5 раза.


Эти кейсы — положительный опыт компаний, с одной стороны, в облачной инфраструктуре, с другой — в переходе на бессерверные СУБД. Успех был определён тем, что команды не бездумно шли за трендами, а понимали свой проект и учли: все ли аспекты позволяют работать в облаках и хранить там данные, будет ли решение экономически выгодным.

П.С. Про коммьюнити

Сама сфера serverless достаточно бурно развивается и у нас есть активно растущее serverless-коммьюнити Yandex Serverless Ecosystem в Telegram, где можно задавать вопросы, возникающие в процессе создания serverless-приложений и получать ответы от единомышленников и коллег.

Теги:
Хабы:
Всего голосов 24: ↑22 и ↓2 +20
Просмотры 9.5K
Комментарии Комментарии 49