Комментарии 91
Бесит термин serverless, ожидаешь нечто true p2p, а видишь тот же сервер, но где-то в облаке.
Полнейшее торжество булшита.
Здесь можно говорить об «эффективном» отсутствии сервера. Т.е. к серверу нельзя подключится по SSH, нельзя писать код в предположении, что под разными
функциями лежит общий диск, оперативка, или хоть что-то общее.
Но ваш код должен приносить деньги.
И вам не доступен тонкий тюнинг на уровне БД.
И данные лежат не у вас.
И код тоже не только ваш в контексте доступа.
Практически все западные стартапы живут в AWS или Azure, это уже данность, все привыкли.потому что это OPEX))) Ни один нормальный инвестор не даст стартапу наращивать CAPEX в виде собственных серверов. Serverless дополнительно к стандартным «облачным плюшкам» переводит DBA и им подобных из зарплатной ведомости в OPEX, что еще более управляемо для инвесторов. Но не все стартапы хотят существовать как стартапы, некоторые становятся регулярным бизнесом, а 1 из 1000 выходит на биржу (и не умирает после выхода). Хотя и в таких топ-менеджмент, сменяющийся каждый год, предпочитает заниматься оптимизацией CAPEX, что отражается на годовых бонусах. Никто не любит думать на 10 лет вперед, т.к. не он будет пожинать плоды инвестиций, которые еще надо протащить через инвестиционный комитет.
Лично мне, как разработчику, конечно же приятно иметь небольшую «железную» избыточность ресурсов под рукой в рамках 200Тб кластера Vertica и специальных людей занимающихся обслуживанием DWH. А не думать о том как ETL-запросом не съесть бюджет Либерии. При этом Serverless, как и условные микро-сервисы, не станет серебряной пулей, а найдет свое место, если пройдет проверку временем.
Николай, рад возвращению на Хабр! Большинство Ваших постулатов (жесткий Anchor Modeling и пр.) не разделяю, но доклады на конференциях по Vertica и статьи здесь — всегда были проработанными и вызывали живой отклик. Удачи!
PS: думал Вы ушли из Avito в mail.ru…
В mail.ru я заглянул совсем ненадолго, понял, что мне важнее дух стартапа, и продолжил путь. Там норм, но перевести аналитику на бессерверное облачное решение вроде Snowflake там я бы не смог.
PS. В течении 2-3 месяцев выйдет еще одна статья от моей команды про нашу архитектуру. Anchor Modeling и бессерверная облачная база — далеко не единственный компонент нашего решения, который ранее в такой роли не применялся, но на удивление хорошо себя показал.
И данные лежат не у васКак вкусно. Успехов с GDPR, 152-ФЗ и прочими.
Компания, работающая в Европе и не соблюдающая GDPR, нарывается на неприятности. Работающая, живущая в AWS и соблюдающая — что ей конкурент сделает?
Честно говоря, все эти законы по защите данных всего лишь инструменты политической и экономической борьбы, а не инструменты защиты пользователей, для примера, сколько утечек за последние годы было из гос органов РФ? Хоть кого-то оштрафовали? Кого-то посадили?
Здесь в Германии у AWS есть местный region, eu-central-1, знакомые мне сервисы S3, EBS, ElastiCache, RDS/Aurora, да и думаю, что и другие тоже, поддерживают шифрование данных, как при хранении, так и при передаче, есть сертификация по GDPR, BSI, FIPS, ISO 27001.
AWS, которая при этом гребет прибыль экскаваторами, больше делать нечего, как таскать и перепродавать чужие данные.
Мы действительно считаем, что надзорные органы, живущие в России, никогда не читали GDPR, не сравнивали его с 152-ФЗ и плевать хотели на все эти тонкости.
У амазона даже gov cloud есть с более строгой сертификацией чисто для гос компаний сша.
PS Были ведь бессерверные БД — файловые. Как вспомню — так вздрогну.
Когда читаю про серверлесс, всегда думаю о CGI из 90-х, ну или о PHP — пришёл запрос, развернули стэк, обработали, умерли.
Увы, слова сейчас значат совсем не то, что они значат...
Чтобы свой сервер не держать? Но свой дешевле
Чтобы легко масштабироваться? Но когда большая нагрузка, то цена огромная
Разница иметь 4 своих админов по базам или иметь ноль очень большая. Особенно если надо платить зарплату калифорнийским работникам :)
А свой это где, дома под кроватью?
В чем разница междую облачным и впс, если и там и там он тебе не принадлежит, но облачный не надо настраивать и менеджить?
Как оно, оказывается, всё просто: docker run mysql и готово, можно увольнять DBA. Тут тебе и прозрачный failover, и multi-master при желании, и read/write split, и автоскалирование числа реплик и snapshots, и maintenance и всё-всё-всё. Докер же :))
Я не уверен, что без DBA даже простейший мастер+пару слейвов получится восстановить после физического сгорания одной из машин… Если машины именно физические, как в посте выше. Покупка нового сервера, настройка, введение его в кластер…
можно увольнять DBA
а как база данных в облаке заменяет DBA, тебе базу проэктируют и запросы пишут сотрудники провайдера?
Ну и в крайности тоже впадать не следует.
docker run mysql и готово
Ну и будем честны, чаще оно так чем не так=)
например на яндексе виртуалка 2ядра(100%) 8 гигов стоит в 2.5 раза больше хетснера — 2800 против 1500 за 2 ядра(выделененные, теже 100%), 8 гигов
за постгрес яндекс просит еще 700р в месяц сверху к 2800. 700р в месяц за инстанс, ок, могу принять, но откуда берется 2800 за саму виртуалку?
А если не страшно железо, то на хетснере i7 6700, 32гига, 2 по 500 ssd стоит теже 3500, там можно 4 виртуалки поднять по 2 выделенных ядра и почти по 8 гигов памяти.
сторонники облаков говорят «Вам не нужен админ девопс», но как-тослабо себе представляю
тебе базу проэктируют и запросы пишут сотрудники провайдера
бэкендеры справляются… Последние годы в современных компаниях позиция DBA исчезает, по моим наблюдениям.
DBA всегда нужен. Но с облачной базой у него будет больше времени на сон и на, собственно, базу.
Взять нашего DBA: с дедиками ему нужно было ещё и следить за железом, ОС и сетью вокруг, IPMI глючил, ECC RAM-модули умирали каждые 3 месяца, бондинг-интерфейсы выпадали. Сейчас у нас ещё даже не Aurora/RDS, а просто EC2. Вместо серверов у него небольшой Terraform-проект. Все.
Интересно кстати услышать разницу, как в деньгах, так и удобстве.
Еще один ньюанс, когда речь заходит о том что современное ПО требует непомерное кол-во ресурсов и работает так же как и ПО которое было 20 лет назад, обычно люди отвечают «Труд программистов слишком дорог» и конечно час программиста дороже чем планка памяти которую покупает пользователь, ведь платит за нее пользователь.
Возвращаясь к облакам. За говнокод программиста уже платит его работодатель в виде оплаты лишних ресурсов.
А почему этим ДБА занимался?
Интересно кстати услышать разницу, как в деньгах, так и удобстве.
Потому что больше некому. У нас не стартап, но и не энтерпрайз, средних размеров контора. Можно было либо нанять кого-то ещё одного, а то и нескольких сотрудников, которые бы занимались железом. После миграции в облако эта необходимость почти сошла на нет. Почти — потому что мы ещё не везде на RDS/Aurora. Центральная база пока на EC2, но миграция в процессе. По деньгам точно не скажу, помню, что по нашим расчётам нанять нового сотрудника вышло бы дороже.
Проблемы качества ПО стали более заметны, т.к. напрямую коррелируют с нашими расходами на облако. В результате повысился приоритет рефакторингов и оптимизаций.
Кроме того, разработчики в восторге от того, что могут легко и запросто подключать и интегрировать другие облачные сервисы: SQS, Lambda, S3, CloudFront и т.д.
Короче, куча плюсов, как прямых, так и косвенных.
А еще обычный ВПС не принадлежит вам также как и облачный, потому что у вас нет гарантий что кто-то в датацентре не сливает ваши данные. Вам тогда свой ДЦ строить надо
Свои ДЦ держат только отдельные старые консервативные компании, вроде не очень крупных банков, которым нужно все переделывать для перехода на облачную инфраструктуру.
Переход в облака (оправданность) можно было обсуждать 5 лет назад, но сейчас то зачем, поезд уехал…
Хм, или наоборот. Дата центр не свернёшь при падении нагрузки и не расширишь при росте. Нужно всегда брать с запасом под пики нагрузки. Всё зависит от проектов.
Богатые, наверное, компании.
Давеча считал альтернативы размещения относительно простого приложения — PHP, mysql, redis, elastic, файло. AWS во Франкфурте — под 2000 (без трафика и балансеров) долларов в месяц, дедики — 500 сложно выбрать на плюс минус то же CPU и RAM.
Разочаровал меня AWS, GC и т. п. Годами читал "платишь за то, что потребляешь" и завидовал, глядя на top, когда за минуту на 4-8 ядрах то вообще нагрузки нет, то LA 5-10.А оказывается нужно заранее выбирать сколько ядер и памяти. И платить, даже если нагрузки нет.
Что касается озвученных костов — т.к. 24к.$ в год… За эти деньги альтернативно можно купить… один? два сервера? + аренда ДЦ.
В итоге облака выгодны тем, кто больше года прожить и не рассчитывает.
Экономия на долгосрочном использовании сервера — это звучит реальным для компании, которая уверена, что перспектив роста на 2-3 года у нее нет никаких… По мне звучит достаточно депрессивно… И риск сгорания 1-2 серверов, замена которым будет ехать 90 дней, но бизнес подождет…
Поднимать инстанс для обработки запроса больше секунды означает, что постоянно надо держать его. Сколько одновременных запросов планируешь — столько инстансов и держать горячими.
За эти деньги можно арендовать в 4 раза больше железа, даже не VDS, а DS
Как ни крути, но у нас всё упирается в реляционную БД. Она скалируется только вертикально и должна быть всё время наготове, потому жрёт бОльшую часть бюджета.
А веб-воркеры требуют не так уж и много, в контейнерах было бы даже ещё меньше. Ну и ещё есть т.н. serverless (в AWS API Gateway + Lambda). У нас он используется на проекте с резкими скачками нагрузки: 95% времени — 5% нагрузки и 5% времени — 95% нагрузки. Проблем с масштабированием с 0 до 1000 запросов в сек. не было никаких, расходы — минимальные.
БД разворачивается по темплейту терраформа, автоматически бэкапится, поднимаются реплики. Чтобы всё это настроить руками нужно изучить много материалов или найти специального человека, а так разработчики могут быстро поднять базу и начать писать код.
Но для домашнего проекта цены облака, увы, кусаются.
Нагрузка началась, расходы не выходят за планируемые.
Описываемые риски были актуальны 5-10 лет назад. Сейчас аргумент за выбор облаков прежде всего финансовый, если расход на команду поддержки не исключать.
2000 за AWS + 4000 за "девопса" или 500 за дедики и 2000 за админа.
Странно как-то, почему девопс стоит дороже админа? По-моему опыту девопсить с дедиками намного муторнее, а значит, и дороже.
Мне всегда так нравилось про "раз — и результат. ни ETL, ни баз данных. Афина или Спектр все за тебя сделают". А потом "Афина — только для спонтанных запросов, иначе слишком дорого"…
Может все-таки следует упоминать экономику serverless решений?
У афина тарификация идёт за размер прочитанных запросом данных. Т.е. 100 запросов читающих 10 Мб и 1 читающий 1000 Мб стоят одинаково. Минимум для запроса 10 Мб, цена: $5 за 1 Тб.
Но сколько что стоить будет в итоге нужно считать под конкретный проект и задачу, иначе всё очень туманно.
Это глубокая тема, если интересно, можно в привате обсудить.
Все аспекты, связанные с деньгами, страшно в публичных статьях обсуждать, можно случайно посчитать не по публичному прайсингу, а по… особым условиям.
Доступны варианты из 16, 32 машин, в зависимости от сложности запросов. Но вы платите только за те минуты, когда кластер реально работает, потому что, когда запросов нет, вы как бы убираете руки, и после 5-10 минут ожидания (настраиваемый параметр) он сам погаснет, освободит ресурсы и станет бесплатным.
Звучит, как мерзкое убожество по сравнению с Google Big Query…
Интересно, вы пишите, что бессерверные базы новинка 2020 года, тогда как DynamoDB существует с 2012 года и спроектирована именно как бессерверная: там нет ни кластеров, ни инстансов. Всё, чем мы можем управлять и масштабировать — число записей и чтений (и регионы репликации, конечно).
Да та же Athena с Presto под капотом, запущенная в 2016: пользователь вообще не видит никаких кластеров, как в Snowflake...
Про 2020 год — я описываю уровень зрелости этих баз, а не год появления. Athena стартовала в 2016, Snowflake начал писаться в 2012, в 2015 уже мог что-то делать. В 2020 можно без страха рекомендовать ими пользоваться.
При этом, к сожалению, для OLTP-нагрузок она еще не применима. Во-первых, эта база колоночная, со всеми вытекающими последствиями.
Строго говоря поколоночное inmemory хранение не является препятствием для создания OLTP решений. Пример СУБД SAP HANA и SAP ERP S/4 HANA.
В SAP Hana, и в одной из новых баз, MemSQL, насколько я знаю, применяется фокус с двойным хранением — данные хранятся дважды, в колонках, и в строках. Строчное хранение держит OLTP нагрузку, колоночное — OLAP нагрузку. Это в некотором роде передний край технологий.
Отличная вводная статья, но я бы выделил Snowflake в отдельную статью. SF не называют свой продукт serverless, по сути — это managed analytical db, т.к. вы указываете какие вычислительные ресурсы использовать. При этом есть serverless фичи, например — Snowpipe. Вот, например, они сравнивают SF с serverless аналогами:
https://www.snowflake.com/blog/snowflake-versus-query-engines/
А вот Google BigQuery является serverless analytical db, в ней вы вычислительными ресурсами не управляете.
Просто есть маркетинг, и есть технические нюансы. В описанной вами статье речь идет не о сравнении с serverless databases, а с serverless query engines, вычленяемых ими, прежде всего, по ценообразованию.
В Snowflake вы не можете «управлять» вычислительными ресурсами, как в managed databases вроде RDS. Вы можете указывать тип вычислительных ресурсов, рекомендовать конкретный ресурс, но без жесткого контроля.
Простейший пример — вы создаете кластер размера M, задаете ему коэффициент скалирования 0-3, и направляете в него, например, 5 последовательных однотипных тяжелых запросов (работающих с идентичными исходными данными, но по разному).
Первый запрос из 5, очевидно, будет сильно медленней, т.к. он упадет в «непрогретый» кластер, и потребует перекачки исходных данных из S3.
Но означает ли это, что остальные 4 выполнятся быстрее, сравнимо быстро? Нет, т.к. возможен, например, следующий сценарий:
1 запрос: старт кластера M1 (Размер Medium, первая копия), наполнение данными из S3, выполнение запроса.
2 запрос: уже поднятый кластер M1, данные уже загружены, только выполнение запросов.
3 запрос: оптимизатор принимает решение, что M1 перегружен. Старт кластера M2 (Размер Medium, вторая копия), наполнение данными из S3, выполнение запроса.
4 запрос: оптимизатор принимает решение, что M1 и M2 перегружены. Старт кластера M3 (Размер Medium, третья копия), наполнение данными из S3, выполнение запроса.
5 запрос: кластер M1 потерян (сбой, перезагрузка), M2 и M3 перегружены. Старт кластера M1 (Размер Medium, первая копия), наполнение данными из S3, выполнение запроса.
В итоге, управление ресурсами — очень опосредованное.
p.s. Хочу тоже пощупать сноуфлейк. Кажется очень перспективным
Раскрытие хинтов Вертики позволило нам выйти на новый уровень использования этой базы в Авито.
Сейчас мы очень плотно работаем с поддержкой Snowflake, чтобы получить хоть немного больше контроля, хотя бы на уровне хинтов.
Но пока доступный контроль минимален.
На пути к бессерверным базам данных — как и зачем