Много было сказано про Serverless в нагрузках без сохранения состояния. Действительно, когда у вас есть контейнеры или функции их легко почти мгновенно масштабировать и нет большой разницы, на какой именно машине это делать.
Но данные имеют очень конкретную привязку к диску, на котором размещены. Что создает немало сложностей к самой концепции бессерверных вычислений.
В этой статье я хочу показать, где бессерверная архитектура может быть применима, и рассмотрю несколько новых, и весьма перспективных решений в этой области.
А наибольший эффект бессерверные технологии дают там, где много арендаторов с разной нагрузкой. А именно в публичных облаках. Бессерверный подход позволяет максимально хорошо утилизировать физическое оборудование за счет переподписки и распределения разнородной нагрузки на оборудование.
Если вы развернете любую бессерверную технологию у себя в контуре/локально, вы столкнетесь с тем, что вы не сможете потребить ресурса больше, чем у вас есть. Ваши мощности просто будут простаивать полупустыми в ожидании кратковременных пиковых нагрузок.
И вы столкнетесь с еще одной проблемой – «точками кипения» (общепринято их называть hotspots или управление температурой). Скорее всего, ваш профиль нагрузки не очень разнообразен. Допустим, вам периодически нужно считывать или записывать большой набор данных на S3. В облаке, где присутствует множество других арендаторов, ваши данные равномерно распределятся по нодам/дискам и при запросах будут минимально нагружать конкретный диск. А вероятность того, что еще множество арендаторов обратится к своим данным на этом же диске, мала. Когда вы размещаете все в своей инфраструктуре, вы не можете так равномерно распределить данные и нагрузку на них. И это приведет к точкам перегрева, своеобразным узким горлышкам, которые убьют производительность. Это одна из причин, почему такие компании, как Snowflake и Databricks не создают свое S3, а размещают инфраструктуру поверх AWS и подобных облаков. Так они более равномерно распределяют нагрузку и получают очень высокую скорость работы.
Хорошо, бессерверные технологии дают экономический эффект и позволяют достичь высокой производительности. Но какие технологии уже нашли подобное применение, а какие только проходят проверку на ценность?
Пожалуй, самая известная и одна из первых технологий, это объектное хранилище S3. И, несмотря на то, что это был первый сервис AWS в далеком 2006 году, именно эта технология меняет парадигму построения СУБД прямо сейчас.
S3 хранит метаданные и содержимое файлов отдельно. Метаданные хранятся в большой базе данных, а содержимое файлов — это просто фрагменты данных в массивах. База данных метаданных содержит указатели на эти файлы, а также хэши содержимого файлов. При этом каждый фрагмент хранится на нескольких независимых серверах.
Все началось с OLAP нагрузок. В 2012 году, компания Snowflake предложила революционную по тем временам идею разделения хранения и вычисления. Разумеется, формат таблиц хранения у компании был свой, как и движок запросов, но само хранение было делегировано S3.
Следом последовала компания Databricks, которая предлагает решения на базе Spark для обработки неструктурированных данных и ряд аналитических сервисов. Как и Snowflake, вычисления и хранение были разделены. Хранение осуществлено на базе их формата Delta в S3-совместимых хранилищах.
Аналитические нагрузки хорошо подходят для S3. Задержка в микросекунды не важна, требуется считывать данные редко, но много. И хранить их долго и дешево.
Из последних примеров, бессерверный подход с разделением хранения и вычисления, недавно был реализован в облаке Clickhouse. Подробнее про архитектуру бессерверного Clickhouse можно почитать по ссылке.
Следует упомянуть и бессерверную аналитику BigQuery.
Во всех этих случаях мы говорим о стандартах на рынке, которые вытеснили устаревшие решения.
Но это аналитические нагрузки. Подойдет ли эта парадигма к потоковым данным и транзакционным базам данных.
Отчасти это становится возможным, так как сеть перестает быть узким горлышком.
Но облачное хранение объектов имеет задержку, несравнимую с задержкой при работе с блочными хранилищами.
И предварительно на это можно ответить положительно.
Буквально в 2023 году появился стартап Warpstream, который предложил Kafka-совместимое решение, где вместо дисков используется S3, а брокеры можно легко масштабировать как вверх, так и вниз (что для оригинальной Kafka весьма затруднительно). Коллеги написали статью, утверждающую, что «Kafka мертва», чем, видимо, напугали Confluent (ведущий вендор Kafka), который их благополучно и купил.
Надо отметить, что у решения присутствует задержка до секунды, которая затрудняет его использование в сценариях где нужен моментальный отклик.
Пример архитектуры Warpstream
Брокеры не имеют сохранения состояния, хранение данных осуществляется в S3, а управление идет через сервис метаданных. Причем на оборудовании Warpstream размещается только управление метаданными, а хранение и брокеры могут быть размещены в контуре клиента, что позволяет не передавать данные во внешний мир.
Технология обладает преимуществами простоты эксплуатации. Можно легко скейлить кластер как вверх, так и вниз, не думая о партициях, перебалансировке и подобном. И в случае большой ширины канала и геораспределенности текущего кластера, может быть дешевле за счет экономии на хранении и сетевом трафике.
Для похожих целей есть две технологии Яндекса – YDB и YTsaurus. В них используются диски, а не S3, но вычисления также отделены от хранения, а динамические таблицы YTsaurus позволяют использовать его и как распределенную транзакционную базу данных, так и как очередь без головной боли о реализации распределенных транзакций. А шардирование позволяет масштабировать решения.
Говоря о классических OLTP нагрузках, в 2021 году появился бессерверный PostgreSQL от компании NEON, которую на днях купила Databricks за 1 млрд.$
Архитектура бессерверного PostgreSQL из документации NEON.
При этом для хранения использовано опять же объектное хранилище S3. Но это именно для долгосрочного хранения.
Neon разделяет монолит Postgres на вычислительный уровень и уровень хранения.
Каждая база данных Postgres от NEON не имеет состояния, поскольку любое состояние, которое она поддерживает, не требуется для долговечности. Если экземпляр Postgres потерян, его можно воссоздать из состояния, сохраненного в слое хранения.
Чтение и запись теперь распределены по парку серверов хранения, что помогает рассеивать пики нагрузки.
Особенностью Neon, помимо того, что он не требует сервера, является его способность поддерживать запросы на определенный момент времени, восстановления на определенный момент времени и ветвление. Все это требует, чтобы данные никогда не перезаписывались и не накладывались друг на друга и история сохранялась эффективным образом.
Ключевым компонентом этого подхода к многоуровневым данным является номер последовательности журнала (LSN), монотонное целое число, назначенное каждой записи WAL, которое представляет собой определенный момент времени в линеаризованной истории изменений данных. Чтения могут выполняться по определенным LSN, а ветви могут совместно использовать общую историю на основе общего LSN.
Подробнее про архитектуру NEON можно почитать в источнике.
Другим примером является MySQL-совместимая бессерверная база данных TiDB. Особенностью которой является сочетание транзакционных и аналитических нагрузок. Сложно сказать, насколько MySQL имеет перспективы в сравнении с PostgreSQL, но сочетание транзакционности и быстрых аналитических запросов в одной БД делают TiDB привлекательным для определенного типа нагрузок.
Как видно, тренд в бессерверных базах данных идет на использование S3-совместимого хранилища, либо шардирование данных. При этом надо понимать, что хранение в S3 дешево, а вот частые запросы очень дороги. Поэтому почти во всех решениях выше, либо используется кеширование на дисках, либо приносится в жертву задержка.
Недавно появилась технология сверхбыстрого S3 – S3 Express One Zone с миллисекундными задержками. Пока она проприетарная и стоит как чугунный мост. Но, возможно, скоро все изменится и ускорит приход бессерверных данных. Главное, что уже сейчас бессерверные СУБД дают новые эксплуатационные свойства и позволяют делать сложные вещи проще.
