Сегодня бо́льшая часть 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-приложений и получать ответы от единомышленников и коллег.
