Сегодня бо́льшая часть 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-приложений и получать ответы от единомышленников и коллег.
Комментарии (49)
sereneli
06.08.2021 11:17+2Всегда удивляло словосочетание «бессерверные базы данных», это же очевидный оксюморон и маркетинговая придумка. Это не бессерверные БД, а просто облачные БД, в которых можно хранить данные.
golodnyj Автор
06.08.2021 11:21+7Термин serverless — бессерверные, уже прижился и мы будем с этим жить. По факту это «managed database service» с моделью оплаты «pay as you go» развернутый на стороне облачного провайдера.
katzen
06.08.2021 19:15+1Ну то есть сервер есть, на самом деле, а втюхивают повременную оплату, поэтому давайте использовать бессмысленный термин только потому, что он прижился?
Очаровательно.golodnyj Автор
07.08.2021 10:55+1В том-то и дело, что у тебя в распоряжении сервера нет. Ты не управляешь им, не обновляешь, не следишь за его секьюрностью и т.д. И в этом смысле, сервера у тебя нет. И в этом смысле, это очень осмысленный термин.
katzen
07.08.2021 18:00+1У меня-то его нет. Но он где-то есть, просто он чужой. Почту джимейловскую никто же не-почтой не называет.
JustAndrei
08.08.2021 01:39+1Рекомендую почитать про IaaS, PaaS и SaaS.
Суть термина serverless - не про отсутствие сервера как такового, а про то, что его можно выкинуть из головы и перестать думать о количестве памяти, ядер и т.п., потому что всё это подбирается под текущую нагрузку и управляется автоматически - не клиентом.
Когда переезжаешь из онпрема в ИааС, тебя всё ещё заботят такие вещи как подбор оборудования, просто становится гораздо легче "выкинуть и заменить" при росте нагрузки, потому что "железо" стало виртуальным. А на уровне ПааС ты уже не думаешь даже об этом, тебя волнует только схема БД и данные в ней, но не "железо". Сервера больше "нет".
JustAndrei
08.08.2021 01:51+1Еще подумалось, что с таким же успехом можно прицепиться к термину "облако". Знаем мы, как же - пар тут ни при чём! На самом-то деле это автоматически масштабируемая виртуальная инфраструктура, управляемая провайдером. Но всем приятно называть это сказочным облаком, где за туманом скрыты вещи, которые больше не должны волновать клиентов. Ровно так же и с серверлесс - сервер накрыло тем же сказочным туманом.
ScarferNV
08.08.2021 20:17Вот зашел почитать про какое-то новое чудо "бессервенрные БД", а оказалось что это всего лишь давно известные облачные БД и разочаровался. Когда уже перестанем термины коверкать.
dth_apostle
09.08.2021 12:10на удивление даже с точки зрения конечного пользователя сервер есть - настройки доступа регулируются пользователем именно на его уровне (в Azure - как минимум; в AWS это вынесено типа на уровень БД - хотя, понятное дело, что регулируется все же серверная часть).
sergeyns
06.08.2021 11:31+4Вангую лет через 10-15 начнется абсолютно новый тренд в IT: "Купите свой собственный сервер! Не надейтесь на облака! Свое железо - самое надежное и прогнозируемое! Контроллируйте свои данные сами! Прогнозируйте свои затраты (а не получайте сюрпризы от облачных тарифов)" )))
fobo
06.08.2021 13:56+5но к нему все равно будет нужна подписка, т. к. сервер не будет работать без облака и все на нём будут админить сотрудники облачной конторы (возможно даже будет выбор какой). и, да, еще будет подписка на электроэнергию от своей солнечной или другой возобновляемой электростанции.
snuk182
06.08.2021 18:24Как с языка сняли. "Смартфон в кармане у вас, но принадлежит нам".
Очень выгодная схема получается - датацентры с дорогущим железом и потреблением строить не надо, достаточно условного РАдмина и админов. Ну и протокол синхронизации постабильней.
ihost
06.08.2021 11:50+4Сама по себе AWS RDS Mysql/Postgres serverless отличная база, с автоматическим вертикальным масштабированием, но предоставляемый по умолчанию интерфейс взаимодействия RDS Data API - это не просто недостаточно некачественный сервис, а абсолютно мусорного уровня, включая перепутывание запросов с ответами, бесчисленные недокументированные сервисные ошибки, наполовину работающие транзакции и так далее, и абсолютно наплевательное отношение техподдержки (Если интересно ознакомиться, в этом посте AWS Postgresql Serverless - tricks and caveats : serverless (reddit.com) мной рассказывается вся история с начала до текущих дней :)
golodnyj Автор
06.08.2021 12:02+1Набредал на тред, давненько это было. Скажи, что-то поменялось за прошедший год? На сколько помню там было все утыкано значками «beta».
ihost
06.08.2021 12:12+3Ситуация вышла интересная: в течение года часть проблем с RDS Data API была решена со стороны aws, часть проблем заткнута набором workaround-ов и эвристик с нашей стороны, и в принципе, все работало довольно стабильно
Но 27 мая этого года, без объявления войны, aws намертво все разломал - внес без предупреждения breaking changes в API (которые до сих пор не задокументированы), а запросы с ответами снова стали перепутываться случайным образом - весь stage, использовавший Rds Data API, развалился фактически без возможности починки
Поэтому было предпринято срочное решение по переезду в VPC - сейчас пользоваться Aurora Postgres Serverless можно с подключением к СУБД напрямую, минуя сломанное Rds Data API, но из приватной VPC-сети - что в конечно итоге было сделано, и с тех пор проблем больше лет - все летает и вертикально масштабируется
golodnyj Автор
06.08.2021 12:37+2Мимо меня прошло, а можно где-то почитать подробнее?
ihost
06.08.2021 12:49+4Что именно почитать? Если про инцидент с перепутыванием запросов, то я больше не публиковал на reddit, поскольку это довольно бессмысленная операция - только немного попинал их в твиттере (1, 2, 3), но фактически тоже безрезультатно - если год назад, когда Data API было в бета-версии и они предпринимали какие-то шаги (к примеру, можно было пообщаться с PM-ом этого сервиса), то сейчас стало понятно, что единственный вариант - это съехать с Rds Data API на VPC
Если про БЧ в API, то здесь BeginTransaction - Amazon RDS Data Service разломали протокол - теперь поле transactionId не ограничено 192 байтами, а могут прислать и 240, при этом БЧ внесли на горячую в работающем кластере, и нигде не заявили об этом, да и документация как видно до сих пор не правленная
Если про доступ через VPC, то толком это нигде не описано, но схема рабочая - краешком это упоминается здесь Using Amazon Aurora Serverless v1 - Amazon Aurora и здесь Best practices for working with Amazon Aurora Serverless | AWS Database Blog
ihost
06.08.2021 13:32+1И конечно важная ремарка касательно всего вышесказанного - все описанные проблемы возникают стабильно при нагрузке >500 одновременных соединений, а при нагрузке >100 соединений могут проявиться с некоторой вероятностью (за 24 часа вероятность хотя бы одного инцидента стремится к 100%)
Но рассматривать и использовать условно-бесконечно-масштабируемый сервис без нагрузки, конечно, смысла никакого нет - хотя на малой нагрузке все работает терпимо
ihost
06.08.2021 12:18+4К вопросу о бета-версии ситуация еще интереснее - они вроде как вышли из беты, но работать так ничего толком не стало. В итоге они сейчас в процессе выпуска Aurora Serverless 2.0 - учитывая предыдущий опыт ошибок, они выкинули в нем RDS Data API, обещают прямое подключение к СУБД и хорошие нагрузки, правда доступен только MySQL 5.7
Плюс хитрецы-маркетологи переобулись на лету и откровенно пишут Amazon Aurora Serverless | MySQL PostgreSQL Relational Database | Amazon Web Services , что Aurora Serverless 1.0, то есть текущая версия, вообще предназначен для малых нагрузок или тестирования, а если хотите настоящую нагрузку, то переходите на 2.0 и ждите, когда она выйдет из бета-тестирования
andreyverbin
06.08.2021 23:29Прочитал пост на Reddit, выглядит как fake news. По пунктам
Mixed results выглядит как попытка использовать коннект к БД в разных потоках. Характерно, что вылезает на нагрузке.
Timeout error это проблема любой БД, а не только serverless. Если случилась ошибка сети, то вы знаете, что стало с транзакцией.
Too many connections и прочие ошибки вам нужно обрабатывать в любом случае, если у вас high-load.
Предьявить AWS можно за документацию. Остальное выглядит как столкновение с реальностью распределённых и нагруженных систем.
ihost
07.08.2021 13:22+1К сожалению, все на реальных событиях - давайте внимательно рассмотрим исходную архитектуру RDS Serverless Aurora+ Rds Data API по пунктам из статьи на reddit:
1) База данных Postgres serverless лежит спрятанная в приватной VPC-сети, Амазон сам управляет вертикальным масштабирование сервера СУБД, сам перезапускает его и т.д. - физического доступа к серверу у вас нет, возможности покдлючения по TCP тоже нет
2) Амазоновский сервис с незамысловатым названием Rds Data Api - это именно сервис, а не библиотечка, и представляет он собой HTTPS-сервер, в который можно отправлять stateless HTTP-запросы с SQL-запросами и получать в ответ строчки из СУБД. Этот сервис имеет публичный хост+порт + авторизацию по aws secret manager, и это единственный способ общаться с serverless-базой
3) Набор однопоточных лямбд на nodejs, каждая из которых общается с сервисом Rds Data Api, и условно говоря, случайным образом делает "SELECT 0" или "SELECT 1" из СУБД. Если этих лямбд достаточно много, то ответы начинают перепутываться - условно тем, кто запросил "SELECT 0" приходит ответ "1" и наоборот
Конечно же, Вы правы в том смысле, что это проблема highload и многопоточности, только вот нюанс в том, что у лямбд вообще нет соединений с базой данных, и все однопоточные и stateless, а запросы перепутываются **внутри** амазоновского сервиса Rds Data Api, поскольку его разработчики, в отличие от нас с Вами, видимо никогда с настоящим highload-ом в жизни не встречались :)
То же самое и по остальным пунктам. Конечно же, при нагрузке СУБД и сеть могут отбиваться с разнообразными ошибками, и необходимо правильно их retry-ить по смыслу и с правильным дрожанием времени (jitter) между попытками. Однако здесь между вами и СУБД есть многострадальный сервис Rds Data Api, который сам внутри падает с неопределенными ошибками, список которых нигде не задокументирован.
Список ошибок удалось составить только эвристически за несколько недель синтетической нагрузки на сервис. При этом эксперементальным путем было выяснено, что Rds Data Api написан на Java, поскольку часть сыпавшихся ошибок - это необработанные исключение с соответствующим стектрейсом из JDK :)
Как минимум амазоновцы должны были не допускать необрабобанных исключений, и обернуть их в какой-то набор осмысленных error-ов - что в итоге и было сделано, только не амазоновцами, а мной - составлен огромный список приходящих исключений и их обертка в осмысленные ошибки, на основании которых можно предпринять какую-то бизнес-логику
Только в чем тогда вообще задача AWS, если они не могут ни структуризировать ошибки, ни работать с многопоточностью, за что им платить денежку, причем немалую? :)
Единственный приятный момент во всей этой истории случился после обнаружения способа прямого подключения к СУБД в приватной VPC-сети и работы с Postgres-ом напрямую. Rds Data Api был успешно выключен и выкинут, а его разработчики (мысленно) отправлены учить матчасть highload сервисов
CyboMan
09.08.2021 22:36+1Простите, но утверждение "и это единственный способ общаться с serverless-базой" кажется неверно:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.requirements
обычное подключение например по 3306 и все дела. Код понятия не имеет с чем он работает, RDS Serverless, RDS или c Maria в контейнере EKS кластера. Так работает несколько нагруженных MySQL Serverless в продакшен. Data API не используем, ну кроме как "побыстрому сделать запрос через вебморду AWS", которая работает через Data API.
Великолепный сервис, как по мне. И альтернатив не очень то и видно в RDBMS, а NoSQL не для всего подходит. Ждем v2 release...ihost
10.08.2021 00:43Насчет RDBMS абсолютно плюсую, ACID-база имеет отличные гарантии и консистентность, и функционал на порядки шире новомодного Nosql
Насчет подключения к Rds serverless V1 - там же только два варианта - или VPC, или Rds data api, а еще в относительно недавнем прошлом класть лямбды в VPC имело множество неприятных последствий - лямбды имели медленный холодный старт из VPC, и после перехода в VPC переставали работать с некоторыми другими AWS-сервисами
Сейчас когда лямбды быстро стартуют из VPC и отлично привязываются к HTTPS через Lambda@edge proxy, собственно и было принято выкинуть Rds data api и работать с базой через нативный драйвер посредством TCP-соединения на порт 5432 (Ну или если был бы mysql, то 3306)
Плюс под нагрузкой возникает нюанс, что лямбды периодически аварийно падают, а tcp-соединения к базе висят до tcp timeout , что создает их переизбыток и невозможность подключиться из новых лямбд - но это конечно все дело техники и давно решено (Есть даже готовые npm-пакеты вроде postgres-serverless и mysql-serverless)
ihost
07.08.2021 13:33+1С транзакциями вообще отдельная история - из-за общения с СУБД через Stateless REST API, которым фактически является Rds Data Api, единственный способ организовывать транзакции - это передавать их в специальном HTTP-заголовочке, чтобы SQL-запрос был ассоциирован с транзакцией
При этом транзакции именуются специальным guid-ом (не имеющим ничего общего с xid/virtualxid в postgres), который видимо под капотом Rds Data Api использует, чтобы знать, в какую транзакцию направлять поступивший по HTTP SQL-запрос
Так вот, при определенной нагрузке Rds Data Api в лучших традициях начинает обманывать - при отправке "commit" он отвечает, что все ок, а на самом деле транзакция откачена. Из-за этого пришлось заводить специальные служебные таблицы по схемам, чтобы хранить в них глобальный журнал примененных guid-ов транзакций
user_man
06.08.2021 15:01Очередная реклама "облаков". Ну и навязывание новых смыслов старым терминам, заодно.
Бессерверным что-то бывает только тогда, когда сервера нет. А когда он есть, но называют его маркетинговым словечком "облако", то это опять всё тот же безумный маркетинг.
>> Такой подход позволяет более точно рассчитать экономику проекта в условиях невозможности спрогнозировать масштабы.
А вот это есть просто наглая ложь. Но, как всегда, слово "ложь" проплатившая рекламу контора возмущённо заменит на "маркетинг". Только замена слов на смысл не влияет. Прогнозировать что-то в ужасно глючных и практически неконтролируемых разработчиком решениях невозможно по определению. Ошибки и отсутствие возможности понять, где нам опять насчитали лишние десятки тысяч долларов - вот реальность "облаков". И как в таких условиях "точно рассчитать экономику проекта"?
>> Снимается боль бизнеса — оплата мощностей за время простоя.
А это откуда выросло? Во время простоя сервер БД потребляет, например, 100 ватт. За сутки - 2400 ватт. Один киловатт-час стоит 6 рублей. То есть в сутки имеем 14.4 рублей. В месяц не более 450 рублей. Да, это адская боль бизнеса!
>> Аргумент по части NoSQL такой, что бессерверные приложения по большей части в стартапах, когда нет истории, нет понимания будущей модели данных, прогнозов трафика.
А это очень правильное замечание - когда нет понимания (модели данных, прогнозов трафика и т.д.), тогда выбирают "сердцем", то есть покупаются на убогую рекламу "облаков".
>> Компания Pokémon Company первоначально выбрала NoSQL и столкнулась со сложностью поддержки бесперебойной работы узлов. Выбор SQL-решения позволил сократить узлы с 300 до 30 и свести к нулю время простоя и снижения производительности.
А это уже, видимо, что бы развеселить читателей. Компания покемонов решила "делать бизнес". Ничего не понимая, выбрали "облака". В результате получили 300 попгуаев нагрузки. Потом пришёл кто-то немного слышавший про нормальную разработку и в результате нагрузка уменьшена до 30 попугаев. Браво, в рекламе "облаков для дураков" такой пример очень выигрывает! Приходите, делаете адски тормозящий продукт на "облаке", а потом, возможно, вы даже найдёте способ сократить нагрузку на "облако" не менее чем в 10 раз. Но ради чего это всё? И это уже вопрос к недуракам. Ради больших затрат на разработку того, что будет в 10 раз медленнее, чем в случае выбора более проверенного временем решения? А есть ведь ещё одно проверенное временем решение - вообще отказаться от облаков, а не просто поменять NoSQL на SQL.
andreyverbin
06.08.2021 23:43+1У вас пиковая нагрузка такова, что вам нужно 300 машин. Но 99% времени вам хватит 30. Так и получается экономия на serverless - за счёт автомасштабирования. Можно его сделать на основе API облака и пачки костылей, но работать будет хуже и поддержка будет дорогой.
Это единственный кейс где serverless рулит, если система под него заточена. Но на практике скачки нагрузки в десятки раз именно на базу редко где встретишь. А там где они есть можно пошаманить и данные хранить в Redis, а писать в БД пачками.
user_man
07.08.2021 15:44>> Это единственный кейс где serverless рулит, если система под него заточена.
Если вы готовы потратить большой бюджет на адаптацию ко всем косякам "облаков", тогда, возможно, вы как-то сумеете реализовать предложенный вариант масштабирования.
Но есть ещё традиционный подход. С ним не нужно тратить большие деньги на адаптацию. Хотя да, масштабироваться без заметных для пользователя тормозов сразу в сто раз будет непросто. Если бюджет ограничен и железом проблему не закидать, то в традиционном решении пользователь будет ждать, например, 10 секунд вместо одной. Опасно ли это для бизнеса? Скорее всего нет, поскольку это пиковая нагрузка, она затрагивает малую часть пользователей, остальные её не заметят, или заметят один раз из нескольких десятков посещений сервиса.
Но тут важнее другое - если у вас денег на железо нет, то значит и на облака у вас денег гарантированно нет. И характер этих денег отличается. Железо - одноразовые капитальные вложения, которые можно частично вернуть посредством продажи. Вложения же в адаптацию к убогости облачных решений являются постоянными. Облачные вендоры постоянно что-то меняют, а нормальных инструментов для анализа не предоставляют, поэтому выход один - постоянно держать дорогую команду ради этой самой адаптации. Такой вариант, очевидно, ни разу не подходит для экономии.
Но если с точки зрения экономии нет выгоды, то где же тогда она есть?
В целом вопрос сводится к оценке вложений в железо против оценки вложений в постоянную адаптацию. На мой взгляд выбор здесь очевиден. Хотя на взгляд бюрократа из толстой конторы, выделяющего деньги на вечно неэффективные проекты, особой разницы нет, оплачивать ли ими адаптацию как к косякам облачных сервисов, так и к косякам управления в большой конторе, или оплачивать ими одни только косяки управления в большой конторе, потому что последние стоят на порядок больше, чем косяки облачных решений.
То есть облака - для богатых и ленивых. Для тех, кто деньги всё же считает, облака в принципе не подходят. Никак. Никогда. Ни при каких условиях (кроме перехода на модель "богатый и ленивый").
andreyverbin
07.08.2021 23:51Со многим согласен. Но не понятно как на своём выделенном железе отмасштабироваться в 10 раз, пусть даже на это уйдёт 10 и более минут.
user_man
08.08.2021 23:46Железо берут с запасом. Разве вы про это не знали?
Расчитывать строго на среднесуточную нагрузку и выбирать железо ровно по этой планке - очевидный признак идиота. Поэтому выбирают что-то более производительное, например раз в 10. Экономически это очень дёшево, поскольку железо окупится примерно за месяц на одной только рекламе, была бы нагрузка (посетители).
Второй момент - архитектура и реализация должны обеспечивать близкую к линейной деградацию времени отклика при перегрузке.
Если два обозначенных критерия выполнены, то при выбросах до 10 раз деградации не произойдёт. А при выбросах более 10 раз начнёт копиться долг, под который требуется память. Памяти на один запрос обычно требуется немного, поэтому узким местом при нагрузке *10max память станет лишь при большой длительности пика. Но "длительный пик" даст существенный прирост средней нагрузки, а потому такие варианты мы не рассматриваем, поскольку они предполагают нашу ошибку в расчёте средней нагрузки (что маловероятно в давно работающей среде, ну либо результат экспериментов всё тех же идиотов).
andreyverbin
09.08.2021 16:44Понятно, что по среднему никто не берет. Поэтому если для средней нагрузки нужно 30 машин, то вы возьмете 300, чтобы выдержать прыжок в 10 раз. Мы тут считаем, что архитектура хороша и 300 машин действительно нужны.
В облаке вы 350 дней в году используете 30 машин, а 15 дней в году 300. В своем дата центре вы 365 дней в году используете 300 машин на 1% в среднем. Вот в такой ситуации и возникает экономия, а serverless упрощает масштабирование, но имеет свои нюансы.
Есть другие нюансы. В большой организации вы можете ждать сервер по полгода и больше, пока отдел закупок тендер сделает, пока привезут. Если та же организация использует облако, то вы просто заказываете сервер. С другой стороны компания где я сейчас работаю платит AWS миллионы $ в год за железо, которое никому не нужно. С третьей стороны, найти и отдать это железо AWS задача на несколько дней, что регулярно происходит. А отдать лишнее железо производителю не получится. И это лишнее железо, скорее всего, будет привязано к конкретному отделу/команде, а сделать так, чтобы лишнее железо можно было найти и переместить из отдела в отдел это та еще организационная задача.
Также IAM - то есть возможно управлять доступом. В облаке это встроено и работает на любом масштабе, будь то 10 или 10 000 разработчиков. С своим железом и в большой компании вы будете иметь отдел админов, которые будут пилить правила контроля доступа. Обыденные штуки, вроде перешел человек из команды в команду и ему нужны доступы, могут стать целой задачей, с тикетами, менеджерами, админами-исполнителями.
Свое железо - хорошо, облако - тоже хорошо. Просто есть нюансы где одно и другое работает лучше или хуже. Я сначала мигрировал свой небольшой бизнес из AWS на bare metal в OVH и сэкономил несколько тысяч USD в месяц. А сейчас думаю над обратной миграцией, потому что подрос и хочется IAM, ECS, Secrets Manager, Systems Manager и RDS. Делать все это руками на своем железе очень долго и дорого.
user_man
10.08.2021 01:41>> В облаке вы 350 дней в году используете 30 машин, а 15 дней в году 300. В своем дата центре вы 365 дней в году используете 300 машин на 1% в среднем.
Посчитайте снова. Ваш расчёт должен дать коэффициент использования 10%, а не 1%. И такая ошибка сильно повлияет на выбор технологии.
>> В большой организации вы можете ждать сервер по полгода и больше
Это тоже искажающее картину соображение. Если бизнесу что-то реально надо - они найдут сервера за один день (ну поусть неделю). А если не надо, то вы по сути выдаёте стремление к каким-то личным достижениям за истину. Ваши личные достижения на самом деле интересны только вам лично. И хорошо, если контора готова иплачивать ваши игры даже через пол-года после их начала. Но к выбору технологии удовлетворение ваших потребностей не относится, потому что это совсем другая область оптимизации с кардинально отличающимися целями.
>> А отдать лишнее железо производителю не получится
И это не проблема. Вспомним, как сбербанк нашёл мощности для тренировки сети GPT-3. Или вы думаете они все 100% этого железа купили под одну единственную задачу? Нет, они нашли способ утилизировать коэффициент простоя оборудования. То есть если бизнесу надо - всегда найдётся способ загрузить или ещё как-то окупить мощности.
>> Также IAM - то есть возможно управлять доступом
А что не так с доступом? Я не спец по деталям настройки толстых серверов, но я отлично знаю, как выделяют виртуальные сервера и как нарезают для них ограничения по ресурсам. Так же и вы - выделяйте виртуалку и нарезайте ресурсы кому нужно. А если проблема в бюрократии, то значит вы опять подменяете реальные проблемы бизнеса своим представлением о них. Бюрократия всегда там, где бизнесу что-то не надо. Хотя вам может показаться, что ваше решение принесёт миллионы и т.д., но это всего лишь мираж. Для этого вы должны стать руководителем, тогда ваши идеи прорастут, даже если они ошибочные. А пока бизнесом рулят другие - прорастают их идеи, даже если они ошибочные. И вам не стоит убиваться по их проблемам, особенно если это следствие принятия ими ошибочных решений.
>> А сейчас думаю над обратной миграцией, потому что подрос и хочется IAM, ECS, Secrets Manager, Systems Manager и RDS. Делать все это руками на своем железе очень долго и дорого.
Я вам не подскажу конкретные инструменты такого плана, но я очень сильно сомневаюсь в том, что их нет для обычных серверов, но есть исключительно для облаков. Обычные сервера развивались многие десятки лет, а облака всего где-то десяток. Скорее всего вы просто не в курсе существующих решений, ну а реклама вам подсказывает - в облаках всё есть! Или вы познакомились с облачным решением и увидели там какие-то инструменты, которые никогда не использовали с обычными серверами, потому что обчные сервера админят обычные админы, а не вы. А теперь, не зная про инструменты для обычных серверов и обладая только лишь представлением об облаках, вы делаете неверный вывод.
В целом я соглашусь, что если сами хозяева облачных решений сильно захотят, то они для каких-то нишевых решений обеспечат реальные преимущества. Но пока хозяева не хотят. Их бизнесу это не надо. Они приняли вот такое решение. И судя по тому, что постоянно находятся желающие им заплатить, возможно это решение вполне правильное для сложившейся ситуации. А вы же пытаетесь доказать, что на самом-то деле хозяева не бизнес ведут, а благотворительностью занимаются, раздавая всем лучшие в мире технологии. Раздают, да ещё и бесплатно, только некачественные решения. Бесплатно заманивают и обещают обещать. Обычный бизнес, ничего личного.
andreyverbin
10.08.2021 03:55>Посчитайте снова. Ваш расчёт должен дать коэффициент использования 10%, а не 1%. И такая ошибка сильно повлияет на выбор технологии.
В моем расчете нет никакого коэффициента использования. Есть пиковая нагрузка, для которой нужно 300 машин, которая бывает 15 дней в году. Что изменится если она бывает 100 дней в году? Только то, что облако станет менее эффективным с точки зрения денег. А если 300 машин надо 365 дней в году и никаких всплесков нет, то облако вообще пролетает. Предсказывать всплески на этапе выбора архитектуры так себе занятие.
>Это тоже искажающее картину соображение. Если бизнесу что-то реально надо - они найдут сервера за один день (ну поусть неделю).
Бизнес это не человек, ему ничего не надо и он ничего не чувствует. Как по вашему "ему надо" должно работать? Железного сервера нужной комплектации от нужного производителя может не быть в России или в вашем городе. Можно закупать что есть и получить зоопарк железа, каждое с своими особенностями. А еще договор на поставку нужно с юристом обсудить, а затем в фин. дирктором. А он в отпуске. А затем менеджер со стороны поставщика ушел в отпуск или заболел. А затем поставщик не ту конфигурацию прислал или не те реквизиты выслал. И пошло поехало.
Пусть менеджер проекта сам закупает технику без лишнего контроля и процедур? И вот у нас откаты менеджеру от поставщиков и полный бардак с тем, кто кому сколько должен, какой товар уже пришел, какой к возврату, а какой получили, где все это находится и в каком состоянии.
И пример закупок из практики - купить и вернуть полотенцесушитель за 20 тыр. - 50 писем поставщику и обратно, пара рабочих дней времени. И это ИП покупает для себя, без процессов и контроля. Боюсь реальность закупок чего-то сложнее еды в магазине или книги на озоне вас может очень разочаровать.
>> А отдать лишнее железо производителю не получится
>И это не проблема.
Предлагаете все тренировать GPT-3 на свободных мощностях? Вот только как инициатор этого проекта вообще узнает о том, что есть свободные мощности? Сколько людей и ИТ систем должно слажено работать вместе, чтобы появилась таблица с свободными серверами, чтобы к ним был доступ у кого надо, чтобы на них можно было запускать GPT-3 и так далее. Все можно, но это не просто так дается.
>Так же и вы - выделяйте виртуалку и нарезайте ресурсы кому нужно.
Это очень упрощенное представление о правах доступа и сценариях с ними. Дело не в виртуалках совсем.
>Я вам не подскажу конкретные инструменты такого плана, но я очень сильно сомневаюсь в том, что их нет для обычных серверов, но есть исключительно для облаков.
Есть конечно. Для каждой задачи есть какой-то отдельный тул, который ее решает. Связывать и настраивать все это для совместной работы - фул тайм работа для нескольких, далеко не дешевых, человек.
Например, взяли вместо AWS Systems Manager альтернативу, которая на самом деле даже круче - RunDeck. А еще у нас есть Active Directory где юзеры живут. И в RunDeck тоже есть юзеры, с какими-то правами на запуск тех или иных скриптов. И вот кто-то сидит и пилит интеграцию Active Directory <-> RunDeck чтобы из AD можно было рулить тем, кто что может и не может делать.
Или хотим логи - подняли ELK, интегрировали его с AD. Но как теперь разделить права юзеров, кто может видеть логи проекта А, а кто нет? И опять кто-то сидит и пилит интеграцию. Можно забить и в каждый проект свой приватный ELK развернуть. Теперь у вас N источников проблем с обновлением софта и починкой сломавшихся индексов.
Бекапы БД, ну да, есть open source тулы, но их надо настроить, а они еще могут ломаться. А затем нужно права доступа для бекапов настроить. И вот опять AD и интеграция. И так далее до бесконечности.
user_man
11.08.2021 14:30>> В моем расчете нет никакого коэффициента использования.
Есть, и он занижен в 10 раз. Это к вопросу о вашей объективности, если что.
>> Бизнес это не человек, ему ничего не надо и он ничего не чувствует.
Ну ладно, если вам так понятнее, то пусть будут хозяева бизнеса. Но связь здесь неразрывная, жаль, что вы её не видите.
>> И пример закупок из практики - купить и вернуть полотенцесушитель за 20 тыр. - 50 писем поставщику и обратно
Смысл здесь такой - вы находитесь на самом дне бюрократического болота, которое из себя представляет ваша контора. Вы видите вокруг много развесистых деревьев (трудностей), но не видите леса (причины проблем). Ваш взгляд из глубины искажён непониманием общей картины. А картина всё та же - бизнесу это не надо. Далее вам нужно объяснять длинную цепочку причинно-следственных отношений, которые приводят к вашему положению, но это долго, поэтому кратко скажу - это называется кусочная автоматизация (погуглите на досуге). Следствием такого подхода является неизбежный бардак и соответсвующее ему болото, в которое вы и погрузились, и похоже других (нормальных) условий обитания не представляете (иначе не указывали бы на следствия бардака как на причину "выгодности" облаков). На самом деле в вашем положении находятся, скорее всего, большинство работников IT-сектора, то есть в большинстве контор царствует бардак той или иной степени тухлости. И когда везде бардак - давление среды становится недостаточным, что бы бизнес захотел что-то исправить. Ну и далее попробуйте довести короткую цепочку выводов до "бизнесу это не надо".
>> Для каждой задачи есть какой-то отдельный тул, который ее решает. Связывать и настраивать все это для совместной работы - фул тайм работа для нескольких, далеко не дешевых, человек.
Здесь опять не то. Опять взгляд из подземелья. Вы видели некую интеграцию в каком-то из вариантов "облака", но не видели аналога в своей конторе, поэтому вам кажется, что нигде в мире нет ничего лучше "облака". Но ситуация почти противоположная. Облака писали постоянно подглядывая решения у взрослых, то есть в норамльно работающих цепочках обработки данных. И эти цепочки не могли быть ни в каком другом месте, кроме обычных серверов. То есть всё давно и основательно придумано и реализовано, но конкретно вы просто не встречались на своём жизненном пути с нормально построенными системами. Здесь "нормально" следует понимать как "не хуже, чем в облаках". И к тому же у вас задачи довольно мелкого уровня (все эти RunDeck-и и ELK-и). Проблемы логирования должны решаться на этапе проектирования, но разумеется, в вашей конторе никто и никогда не занимался серьёзным проектированием, а потому никто эти небольшие проблемы не решил, всё свесили на вас, видимо разработчика одной из подсистем. И вы с энтузиазмом принялись строить свой велосипед, но поняли, что на его строительство нужно много времени, ну и от безысходности начали выть на луну (на облака), мол вот там всё есть, а здесь меня мучают логами. Но нет никаких причин для неповторения ситуации один в один в случае, если вы перейдёте в облака. Бардак достанет вас и там. Так что не надо возлагать необоснованные надежды на сырую и от того убогую технологию, и тем более, выдвигать ваш бардак в качестве аргумента "за облака", потому что это лишь аргумент в доказательство отсутсвия у вас опыта работы в условиях с существенно меньшим бардаком.
andreyverbin
11.08.2021 18:20+1Преклоняюсь перед вашим опытом, расскажите же мне, сирому и убогому, как решаются обозначенные мной проблемы в конторах «без бардака» И не стесняйтесь, расскажите как называются эти чудо организации.
alexeivanov
07.08.2021 17:03в контексте redis речь про "appendfsync always", или о "In the case of a complete system failure on default settings, only a few seconds of data would be lost."?
если о первом варианте, то будут ли преимущества при обработке скачков относительно dbms с wal-ом?andreyverbin
07.08.2021 23:46Если append fsync always то разница будет только на чтении, запись может быть даже медленне чем в БД. У Redis есть ещё кластер, можно смириться с возможной потерей данных, можно организоваться свой WAL на уровне app server. Вариантов много, зависит от профиля нагрузки. Основная идея в том, чтобы использовать очень быстрый, специализированный storage, который позволит пики проходить, не упираясь в БД.
andreyverbin
06.08.2021 15:06Какому бизнесу хорошо от того, что в один день счёт за облако 3 цента, а в другой $30 000 мне не понятно. Хотя AWS такая ситуация точно нравится.
golodnyj Автор
06.08.2021 17:10Тому, который понимает и оценивает стоимость бизнес транзакции. Вот допустим ты на транзакции клиента зарабатываешь X, а с serverless решениями ты можешь посчитать сколько это будет тебе стоить — обсчитать стоимость бизнес-процесса по обработке именно этой транзакции равна Y. Вот у тебя трафик ты заработал X - Y на каждой транзакции, если разница положительная то профит очевиден. Гоним трафик, зарабатываем. Трафика нет, не зарабатываем, но и не тратим.
maslyaev
06.08.2021 15:34+1Поделюсь опытом использования Managed PostgreSQL в Azure. Всё хорошо, но производительность в 100 (прописью: сто) раз хуже того же Постгреса, поднятого в докер-контейнере на моём ноутбуке. Одна и та же база (восстановленная из бэкапа), один и тот же запрос, идентичный результат, но у меня 1 секунда, а в облаке полторы мать её минуты. В последний раз я видел такую потрясающую производительность в начале 90-х на DBF файлах в 486-м компьютере.
Короче, дурят доверчивых граждан поставщики облачных сервисов.
golodnyj Автор
06.08.2021 17:06Тут бы конечно позвать ребят из Azure и совместно попрофилировать/подебажить, может быть это какая-то локальная проблема?
Fafhrd
06.08.2021 22:18+2Ну да, позвать. Когда мы нашли баг в ажуровском датафактори, через 2 месяца удалось-таки пообщаться с индусом, который баг признал и сказал типа не делайте так, а мы когда-нибудь исправим.
maslyaev
07.08.2021 13:24+3Не надо никого звать. После того, как наши [censored] девопсы полтора месяца кормили меня завтраками и футболили тикет друг другу, я психанул и со словами "горбатого могила исправит" поднял Постгрес на запасной виртуалке в Digital Ocean.
Я предполагаю, что все эти прекрасные Managed заманухи хранят свои данные в облачных же хранилищах, которые по-любому медленнее, чем железная SSDшка, подключённая через железный PCI-Express. Вот и получается, что ты, дорогой клиент, можешь наслаждаться бесконечным объёмом хранимых данных, но всё будет работать нормально и не вставать колом ровно до момента, как база перестанет целиком помещаться в кэш. Для демок и прототипов такое прокатывает, а для настоящего использования... да кому оно нахрен интересно это настоящее использование?
maxzh83
06.08.2021 17:26+2Стоит упомянуть еще и про вендорлок. Как только сядете на одного "бессерверного" провайдера, слезть с него будет крайне проблематично.
ISPsystem_software
13.08.2021 19:45Было бы интересно попробовать интеграцию нашей платформы с serverless решением
Rive
Т.е. если бизнес не устраивает "определённый вендор", ему придётся помимо непосредственных затрат на переезд потратиться на переписывание всего куска кодовой базы вокруг БД (поскольку совместимость API запросов к БД у нового вендора может быть, а может и не быть).
golodnyj Автор
Вопрос переездов, конечно острый, и не везде возможен. В самом плохом случае прийдется слой работы с данными переписать, в лучшем это произойдет бесшовно.
Смотри есть пара примеров. Первый, Amazon Aurora Serverless по сути это MySQL и PostgreSQL и переезд из одного облака в другое неприятное дело но не страшное. Второй, Amazon DynamoDB и Yandex Database в Serverless варианте, тут за счет поддержки промежуточного слоя практически бесшовный переезд.