Хабрахабр

БД в облаках: кому и зачем — мнение специалистов Data Egret

Есть мнение, что будущее за DB as Service. Стоит ли всем подряд увольнять DBA и переходить в публичное облако или стремиться создать приватное облако на Docker с Kubernetes? Трое экспертов из Data Egret — Алексей Лесовский, Виктор Егоров и Андрей Сальников — на канале #RuPostgres в прямом эфире поделились мнением, для каких именно проектов подойдут облачные модели.

Модератором и ведущим беседы выступил Николай Самохвалов, основатель Postgres.ai и сооснователь сообщества RuPostgres.org.

И начну с каверзного вопроса: правда, что у вас больше половины клиентов уже в облаках? Под катом — расшифровка беседы.
– Сегодня мы поговорим про Postgres в облаках.

По ощущениям их меньше половины. Алексей: Мне кажется, нет. Все либо сидят в собственных дата-центрах, либо арендуют железки.

Что мы подразумеваем под «облаками»: Amazon, Google Cloud, DB as Service? Но прежде чем говорить об облаках, давайте определимся с терминами.

Их нужно в принципе рассматривать отдельно. – Я бы разграничил Postgres в облаке, приготовленный на инстансе Amazon EC2 (или аналоге от Google), где ты можешь, грубо говоря, зайти по ssh и поправить конфиг, и Postgres под управлением (по-английски «managed»), когда прямого доступа на уровне файлов или ssh нет, а есть только возможность подключаться и выполнять SQL-запросы. И мой первый вопрос был про managed Postgres.

Алексей: Таких клиентов существенно меньше половины.

В чём смысл облака? Виктор: Ну а в первом случае — какие у нас есть существенные преимущества от облака?

Это уже не то же самое, что просто железка. – В первом случае с помощью применения разных современных инструментов, вроде patroni и kubernetes (о них мы еще отдельно поговорим), можно получить эластичность, микросервисы и все такое. Ты уже не знаешь, что за железки там установлены. Это как «питомцы vs стадо» — отношение к железу как к питомцу перерастает в отношение к виртуалкам как к стаду. Ты можешь сэкономить время. Не ты их заказывал, не ты работал с поставщиком, не ты продумывал топологию.

На мой взгляд, первый случай просто упрощает процесс покупки нового железа. Виктор: Да. И ты выбираешь виртуалку из того, что тебе предлагают. Ты знаешь, что тебе нужно: сколько ядер и оперативки, какие диски. Но в остальном тебе все равно приходится этот сервер нормально настраивать и обслуживать. Это быстро.

Кто-нибудь из вас его замерял? – А как вы относитесь к оверхеду, который добавляют виртуалки (процессам внутри виртуалки, которых нет на голом железе, оверхеду перформанса или сложностям администрирования)?

В общедоступных сервисах его нет — что дают, то и используешь. Алексей: Оверхед можно померить, если у тебя есть контроль над гипервизором.

При этом он зависел от настроек виртуальной машины и ворклоада. Оверхед обычных систем виртуализации, которые можно развернуть у себя (KVM, Xen), я мерял лет пять назад, и тогда он был примерно 7–8%. Например, на Redis и Postgres оверхед был значительно больше, чем на Unicorn, который обслуживает бэкенды на Rails.

Возможно, сейчас цифры уже другие.

– Даже 5–7 % — это приемлемый оверхед по сравнению с плюсами, о которых говорил Виктор.

А как у вас меняется состав клиентов: есть ли движения в сторону managed-баз?

Тренд скорее обратный. Алексей: Нет. В итоге мы получаем то же самое отношение «как к питомцам», но в инстансах EC2. Людям, работающим с вещами типа RDS, не хватает гибкости в администрировании и управлении.

Есть клиенты, у которых основные базы на продакшене очень нагружены. Виктор: Вырисовывается такая ситуация. Но когда компания растет, разработка требует большого количества тестовых и девелоперских инстансов, и они уходят в виртуализацию. Естественно, они размещаются на выделенных железках и под постоянным присмотром. Но продакшен остается на нормальном серьезном железе. То есть это гибридный случай: под тесты и dev-окружение может закупаться железо или арендоваться виртуалки.

– Используется ли при этом Amazon RDS?

Причина, как я уже говорил, в отсутствии гибкости в управлении.
Алексей: Наши клиенты наоборот от RDS отказываются.

Инстансы крешатся, и в некоторых случаях вопрос не решается только лишь арендой более мощной железки.

Многие проблемы ты не можешь решить сам — только с помощью поддержки.

Казалось бы, недавно Amazon купил OpenSCG — прекрасных ребят, которые должны были развить внутреннюю экспертизу Postgres. – А можно ли привести примеры? Если ты открываешь тикет с саппортом Amazon RDS и натыкаешься на человека, который не может тебе помочь, просто закрываешь тикет и открываешь его снова, попадая уже на более грамотного. И я по своему опыту знаю, что экспертиза есть.

Но покупка такой команды не закрывает 100% возможных ситуаций. Алексей: OpenSCG — это, конечно, команда профессионалов. У нас такое тоже происходит. Бывают проблемы, с которыми поддержка сталкивается впервые.

6 у заказчика load average на хосте внезапно увеличился на 30–40 единиц, хотя нагрузки никакой нет. Из последнего — на одной из реплик PostgreSQL 10. Он не сильно влияет, но сама картина того, что load average подпрыгивает, непонятна. Такой непонятный подземный стук. У нас есть пара гипотез, чем она вызвана, но мы пока не смогли их проверить, потому что система продуктовая и там не все быстро можно сделать. И админов заказчика она напрягает.

А Amazon RDS – это большее количество инстансов, большее количество инсталляций и тикетов, соответственно, и всевозможных ситуаций гораздо больше. И такие «подземные стуки» вылезают где-то раз в год, и ты начинаешь творчески подходить к задаче.

Он обратился за консультацией. Андрей: Я бы хотел добавить про сравнение RDS и EC2 инстансов.
Был у нас клиент с продакшеном на RDS. Dev-контур располагался в Microsoft Azure, видимо, изначально рассматривали Azure как основной облачный сервис.

Я перетащил базу dev-контура из Azure на Amazon в EC2, чтобы было ближе к продакшену, и прогнозирование проблем стало ближе к продуктовой БД.

Хотя сервер EC2 был в два раза проще, чем под RDS-инстансами, а тестовая нагрузка была выше продуктовой, в dev-контуре после моей настройки результаты получились намного лучше, чем в Amazon на RDS-овском инстансе на продакшене.

У меня есть подозрение, что из-за отсутствия экспертизы по PostgreSQL внутри компании заказчика RDS использовался с дефолтным конфигом. Мы же крутим все настройки.

Обратился к руководству с предложением вместо RDS взять и настроить простые инстансы. В итоге клиент был очень впечатлен.

– Кстати, как измеряли, что лучше, что хуже?

Андрей: Клиент смотрел по метрикам своего приложения, насколько быстро происходила загрузка данных и их обработка.

Вы согласны? – Мы сейчас ругаем RDS, но ведь у него есть огромные плюсы – он снимает много головной боли, связанной с разворачиванием, бэкапами, репликацией.

И, скорее всего, основная причина того, что клиент остался в RDS, была как раз в упомянутом отсутствии экспертизы по PostgreSQL. Андрей: Да. Они получают все необходимое с помощью RDS, просто платят больше за инстансы.

Сталкивались ли вы, например, с сервисом Яндекса? – Кроме Amazon RDS есть и другие облачные managed postgres.

По сути там диски, подключенные по сети. Андрей: Я сталкивался с их виртуалками и они мне не очень понравились — там NVMe у дисков не очень честный.

У Google и Amazon есть NVMe, но диски там эфемерные. – Честный NVMe (локальные диски) — это тоже проблема. Если ты перезапускаешь инстанс, то теряешь все данные, потому что тебе дают другую виртуалку.

Видимо, там немного другая архитектура на уровне предоставления ресурсов. Андрей: В Яндекс Облако мне прокомментировали, что в DB as service у них честный NVMe, но я с этим сервисом пока не сталкивался.

Просто для внешних клиентов и внутреннего использования предусмотрены разные точки входа. Над DB as service они очень сильно работают, так как используют его у себя для своих сервисов.

Взлетит или не взлетит? – А как ты думаешь, есть ли перспективы у российского Postgres в облаке?

Андрей:

Думаю, у них взлетит. У Яндекса отличная команда, довольно опытная, с хорошей экспертизой.

Во-первых, они сами эксплуатируют очень много Postgres (более 1000 баз данных на своих проектах), а т.к. эксплуатируют, все шишки и больные места будут отрабатывать и исправлять быстрее. Думаю, клиенту будет предоставлен конечный сервис довольно хорошего качества.

Возьмем стартап, который в начале не может обладать необходимой экспертизой по Postgres по разным причинам: дорого, не видят смысла, пробуют разные технологии. И спрос на такие решения есть. Для него это хорошее решение, потому что в таких сервисах ограничены «крутилки», которые не следует крутить, а если что, думаю, и техподдержка будет.

Правда, «Яндекс облако» пока еще на старте, и представлен не такой большой функционал на данный момент.

– У нас есть вопросы из чатика: что вы думаете о том, что при выдаче виртуалки у нас на этой машине может физически кто-то сидеть (throttling, steal time).

Как раз хотел это упомянуть. Виктор: Да, есть такой опыт. Периодически они просят посмотреть какой-то не продуктовый сервер, и мы видим непонятную ситуацию: причин, почему оно должно было сломаться на этом сервере, мы не наблюдаем. Есть клиенты, у которых развернуты свои системы виртуализации. Тогда мы переадресовываем вопросы их админам с просьбой посмотреть, что там творится на хосте.

Есть ли методы определить, что тебя «поджали»? – А что делать, есть ли аналогичный эффект в Amazon? pgbench гонять?

Но обычный способ — это определение через steal time. Алексей: Я такого не припомню. На графиках мониторинга мы, как правило, не видим каких-то больших значений.

Не связано ли это с тем, что RDS у вас отнимает работу? – Я чувствую, что вы не очень любите managed Postgres.

Это связано скорее с тем, что у нас его просто нет. Алексей: Нет. Пока ты — стартап и просто складываешь или читаешь данные без какой-то всякой сложной логики, все хорошо. Managed Postgres хорош тем, что ты можешь развернуть инфраструктуру по нажатию на кнопку. Требуется больше свободы и влияния, но имеющиеся инструменты не помогают тебе решать глубокие проблемы, связанные с утилизацией ресурсов внутри самого Postgres. А когда ты переходишь некую грань, например начинаешь выполнять много JOIN, делать сложный SQL, возникает задача оптимизировать запросы и RDS перестает хватать. Есть только возможность увеличить мощность железки: заплатил больше денег — получил.

Проблема в другом. Андрей: Тут не столько нелюбовь к RDS и боязнь за работу. А экспертизу он свою в Postgres так и не увеличил. Предположим, стартап взял RDS, он все им дает. Нагрузки вырастают — увеличилась запись и чтение. Далее, допустим, стартап выстрелил. Приходят суровые DBA и видят, что не могут выжать больше из RDS, а вот из обычного EC2 инстанса вполне возможно получить больше производительности, как в примере, который я упоминал ранее. В отсутствии своей экспертизы стартапу приходится искать людей на стороне. Если бы нас пустили на RDS, возможно, мы могли бы настроить и улучшить работу базы данных, но этого не стали делать.

Есть managed Postgres, которые дают ssh-доступ (и даже полностью root), например, небольшая компания Aiven из Финляндии. – Вопрос с доступом решается. По умолчанию они root-доступ не дают, но основатель (а я с ним общался пару раз) говорил о готовности выдать доступ по запросу.

Почему мы лучше относимся к чистым железкам? Андрей: Вопрос не только в доступе. И инфраструктуры бывают настолько далеки друг от друга, что общей методологии, работающей везде одинаково, у нас просто не получается. Потому что у нас довольно много разных клиентов, и у каждого своя инфраструктура. Потому что есть те, у кого свое железо, и они никак не могут хоститься где-то (по каким-то своим правилам и ограничениям), и есть те, кто в облаках.

Или какие-то другие банальные вещи? – Ты хочешь сказать, что определение неиспользуемых индексов зависит от железки?

Все унифицировано. Андрей: С точки зрения администрирования именно схемы базы данных и определения неиспользуемых индексов ничем не отличаются облака от своего железа.

Когда у тебя большие базы, тебе важно, насколько быстро диски отдают и принимают данные, насколько эффективно используется память и процессор, поэтому крайне важно уменьшить влияние этой прослойки, чтобы база работала наиболее эффективно. Различие облака и реальной железки — в прослойке между базой и конкретно железом, которое лежит снизу, — это операционная система и используемые виртуализации.

– Еще один вопрос от зрителей: а как на счет настроек ядра?

Виктор: В EC2 такие вещи настраиваются.

Например, Nutanix и SAP заявили в 2018 о создании решений на основе Postgres. – Появляются новые решения класса «managed Postgres» от известных вендоров, кроме привычных Amazon и Google. Чтобы можно было нажать кнопочку и развернуть новый Postgres, где уже настроены бекапы и репликация. Вам не кажется, что все эти ребята ведут нас к появлению каких-то решений, которые будут делать то же самое, но только на вашей железке?

 Это крупные вендоры железа и программного обеспечения. Алексей: Мне кажется, SAP и другим это не совсем выгодно. Продать поддержку хотя бы. Они делают продукт с целью зарабатывать деньги. Если им будет выгодна такая модель предоставления продукта, то почему бы и нет? Поэтому надо смотреть на то, как они будут извлекать из этого прибыль.

Конкретно эти ребята не будут ничего выкладывать в open source и отдавать бесплатно. – Я имел в виду несколько иное. Возможно, это будет ориентировано на Kubernetes, Operator Framework. Но вам не кажется, что кто-то из более маленьких, но резвых сделает что-то подобное? И не кажется ли вам, что облачные RDS помогают постепенному переходу к таким решениям? Уже есть пара разработок, которые делают операторы — Zalando, например. Мы видим, как можно жить, не залезая в конфиги руками.

Алексей: Это получается не совсем managed.

Тебе все равно нужно будет иметь специалистов, которые будут за всем этим следить и лазить под капот, если вдруг что-то пойдет не так.

Даже тот самый Kubernetes — это очень сложная машина, под капотом у которой множество компонентов. Формально это всего пять бинарников. Но их взаимодействие между собой описывается томами документации и кучей информации по чатам, рассылкам и Google Groups. Т.е. все равно нужен специалист, который будет за этой кухней следить.

Обратная совместимость ломается от релиза к релизу. Плюс все это очень динамично развивается. все очень зыбкое и нестабильное. Т.е. Но пока все не очень. Когда все утрясется, может быть, мы получим годный продукт, стабильный и надежный.

Виктор: Мы начинаем говорить о том, что у нас появляется дополнительный слой инфраструктуры, которым нужно управлять – оркестровать этот Kubernetes.

Нужно держать соответствующих специалистов.
Я не согласен с тем, что он магическим образом по нажатию кнопки будет всегда работать так, как нам хочется.

А второе – наши клиенты постоянно адаптируются к изменениям в бизнесе. Соответственно, нагрузка в базе постоянно меняется. И если мы три месяца назад все вылизали, в результате чего все запросы работали так, как надо, и все было отлично, то сегодня или завтра может прийти новый запрос, или в связи с изменением данных существующий запрос перестанет работать так, как надо. И нам нужно анализировать ситуацию и лезть в настройки системы. И это та автоматизация, которую, как мне кажется, сделать подобными managed-инстансами очень сложно. Когда облака достигнут такого состояния, что они будут адаптироваться еще и к таким ситуациям, я не знаю. Но пока это значительная часть работы, которую необходимо делать – необходимо адаптировать настройки базы к изменениям паттерна приходящих запросов.

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

Главное, чтобы у нас была возможность, когда базе станет не очень хорошо, залезть (желательно по ssh), все проверить и получить доступ ко всей статистике. Если клиент желает жить в облаке и у него есть экспертиза, мы ничего не имеем против.

Но в любом случае нужны инструменты для диагностики. Алексей: Не обязательно по ssh. Раздражает, когда ты отправляешь в чат ссылку на запрос, который нужно выполнить, клиент с другой стороны переходит по этой ссылке, копирует запрос, потом копирует тебе результат или высылает скриншот. Потому что диагностика по электронной почте – это очень долго и нудно. Это все время.

Гораздо проще подключиться и посмотреть непосредственно, проверить какие-то свои гипотезы и действовать дальше уже от них.

– А есть у вас активные примеры того, где Kubernetes уже используется и в нем живет Postgres?

Но я бы очень хотел. Алексей: У меня, к сожалению, нет. Мне очень нравится Kubernetes, мне близка его концепция и философия.

На мой взгляд, Kubernetes – это такая штука, которая сподвигает людей больше программировать, больше создавать продукт, не задумываясь о побочных вещах типа внутреннего устройства инфраструктуры.

Аналогичную роль раньше выполняло ООП. Оно появилось, и много людей заинтересовалось этой сферой, потому что программирование стало в какой-то степени легче. Kubernetes тоже замыкает на себе многие вещи, скрывает их под капотом и позволяет человеку сосредоточиться на творческом аспекте и программировать больше.

Если оно вдруг упало – ну и ладно, Kubernetes запустит его снова. Kubernetes реализует в себе поддержку инстансов, подов, и приложение работает. разработчик и администратор избавлены от головной боли и постоянного слежения. Т.е. Когда что-то падает, оно перезапускается автоматически. Мне нравится это реагирование на ситуацию.

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

– Думаешь, у него есть хорошее будущее?

Мне кажется, у этой штуки есть потенциал. Алексей: Я не знаю, мне сложно предсказывать. Вокруг нее много разного инструментария, вспомогательных проектов, которые улучшают работу с Kubernetes. Она как минимум еще какое-то время будет жить, тем более вокруг нее уже есть сложившаяся экосистема. В организацию CNCF входят многие крупные вендоры программного обеспечения. И сам Kubernetes растет. Видно, что жизнь идет.

Там был график активности на github, который показывает снижение активности в цикле разработки Kubernetes: количество коммитов несколько лет плавно снижается. Хотя есть один такой довольно забавный момент – который я недавно наблюдал в телеграмм-канале kubernetes_ru. Рядом приводили график Postgres, там все идет стабильно.

Мне кажется, Kubernetes – это живая динамичная технология, которая будет развиваться. Но, это, конечно, все юмор. У нее будет какое-то свое место в истории IT.

Фактически это следующий уровень, когда ты не думаешь, какой у тебя инстанс и сколько ему нужно памяти. – А вы слышали про такую штуку, как Amazon Aurora PostgreSQL Serverless? Т.е. При необходимости увеличения ресурсов можно поменять на лету инстанс, оставляя соединение. мы еще меньше думаем про железки.

Алексей:

Но это пока такой черный ящик. Аврора мне кажется интересной.

Да, мы меньше думаем про железки. Но у нас получается удобство, некая кнопка, на которую ты нажал и у тебя все работает под капотом. Это как ключ зажигания в машине: ты его повернул, завел машину и поехал. И ты не думаешь, что у тебя там под капотом что-то крутится. Детали скрыты от водителя.

А то до сих пор у нас получался негативный образ облаков и в целом этой идеи сокрытия потрохов от инженеров. – Спасибо за это позитивное мнение. На самом деле я тоже придерживаюсь мнения, что это классно, это более высокий уровень.

К примеру, мы все сейчас пользуемся смартфонами. Андрей: Тут получается большая сепарация. Разговаривая с таким человеком, ты понимаешь, что он бог в области микроэлектроники, в то время как раньше таких людей больше на виду было, да и микроэлектроника была куда проще. Но люди, которые делают микросхемы для этих устройств, – это очень маленькое узкоспециализированное сообщество.

начинается разделение. Т.е. Люди не заморачиваются и действительно работают над своим продуктом. Базы данных как сервис – доступная технология, ей пользуются, она покрывает 70% нужд. Им не нужна никакая специализированная экспертиза.

А такие товарищи, как мы, становятся этакими «инженерами микросхемок», о которых мало кто будет знать.

– Я полностью согласен. А как ты думаешь, может такое случиться, что DBA расщепится на несколько профессий: кто-то будет копаться под капотом, а кто-то — анализировать индексы, схему?

Когда я работал с Oracle в качестве SQL-developer, половина моих задач заключалась в том, чтобы смотреть, насколько оптимальны запросы, что творится с таблицами. Андрей: В принципе, человек, который анализирует запросы, – это не столько DBA, сколько SQL-developer. Моя задача была оптимизировать все с точки зрения схемы БД. Я совсем не знал, как устанавливать и настраивать Oracle. А оракловые DBA для меня были отдельными богами, которые занимались чем-то своим.

DBA — это все-таки больше «подкапотный» человек, и тут говорить о разделении не совсем корректно.

В целом я поддерживают позицию Алексея, но хочу рассказать про реалии. Еще я хотел добавить про Kubernetes. И я разговаривал с ребятами, которые активно используют Kubernetes и другие средства оркестрации. Мы все были в эти дни на конференции. Т.е. И реальные ситуации сейчас у них таковы, что они гвоздями прибивают базу к определенному инстансу и прокидывают volume в нужный контейнер. И для меня такой подход выглядит точно так же, как отдельно стоящая железка. они добавили еще одну прослойку, которую нужно отдельно настраивать.

– Все еще сложнее получается?

Андрей: Да.

Да, они говорят, что у нас все в единой инфраструктуре. Сейчас реальность такова, что они усложняют себе работу. При этом они запрещают поду Postgres подниматься на каком-то другом. Но им нужно делать дополнительные телодвижения, чтобы прибить Postgres (железка для базы и ничего кроме базы там нет). если база падает (допустим, железка сгорела), то автоматически ее уже не поднимешь. Т.е.

Нужно бежать в магазин или в облако, покупать точно такую же железку и делать дополнительные телодвижения по новому прибиванию гвоздями.

Это позволяет не заботиться ни о чем. Год назад на конференции те же люди мне говорили, что это клево, когда база уплывает на другой под. Но в этом году они все прибили базы данных гвоздями к определенным железкам. Сразу несколько человек вели одинаковые речи.

– А почему они это сделали?

Правда, я не особо спрашивал, просто заметил такую тенденцию. Андрей: У них начали возникать какие-то проблемы.

Ее также прибивают к конкретным инстансам. Кстати, то же самое касается Cassandra. на данный момент все это — усложнение работы человека, который возится с Kubernetes. Т.е.

Энтузиасты набьют шишек, создадут технологии, и мы получим действительно хорошее решение. Хотя в будущем, я думаю, все будет лучше.

у меня двойная позиция. Т.е. С другой стороны, я всегда рад экспериментам, потому что в них рождается что-то новое – новые технологии и улучшение жизни в целом.
Как DBA, я считаю, что все надо оставить по старому – никого в базу не пускать.

– Когда нас ждет это улучшение жизни?

Правда, сейчас наблюдается некоторое спокойствие. Андрей: Народ в эти полки прибывает. Я думаю, пару лет, наверное, еще пройдет, прежде чем мы получим что-то более-менее нормальное с точки зрения использования БД именно в Kubernetes (чтобы мы могли использовать базы данных без проблем). Но, видимо, остались те, кому это действительно нужно и кто хочет с Kubernetes работать.

Я разговаривал с Сашей Кукушкиным – это разработчик patroni. Алексей: Я бы хотел добавить про Kubernetes. Доля серверов в облаке высока, и она постоянно увеличивается, несмотря на более высокую стоимость владения (если ты хочешь запровиженить железку – это долго, а в Amazon все уже есть, можно вводить в оборот). У них в Zalando довольно много Kubernetes. При этом разработчиков много, микросервисов – тоже. Их это устраивает, потому что разработчикам нужно со всем этим легко работать – им нужны базы. Их выход – как раз-таки Kubernetes.

Они пошли в EC2 и подготовили Postgres в облаке самостоятельно. – Но они решили не идти в RDS. Им пришлось это сделать для patroni (https://github.com/zalando/patroni), который сейчас стал лидером на рынке.

Алексей: Да, я считаю, что это уже стандарт де-факто для high availability.

Следующая потребность — сделать волшебную кнопку, чтобы инстанс развернулся и дальше могли подключаться приложения? – Согласен.

Т.е. Алексей: Я думаю, что у них это уже в какой-то степени реализовано.
Но тем не менее в Zalando есть свой небольшой штат DBA, которые пишут patroni. несмотря на то, что у них есть много инстансов под Kubernetes и хорошая экспертиза по нему, DBA нужны.

Это не отменяет востребованности DBA, но один DBA может «пасти» большее «стадо». – Согласен.

Он меньше заморочен на настройке конфигов и файловеров. Алексей: Да, у него получается меньше работы. Все само работает, живет своей жизнью, сообщая результаты в мониторинг.

Зачем туда пихать базу? – А какую проблему все-таки решает Kubernetes?

Ты в Kubernetes просто разворачиваешь небольшую базу – у тебя там мало данных, мало запросов. Алексей: Если ты готовишь стартап или какой-то небольшое проект, на этапе взлета нужно проверять гипотезы. Разработчик описывает свой деплоймент и там же запрашивает выделить пространство под базу с  желаемым объемом. При этом Kubernetes в какой-то степени помогает уменьшить объем администрирования. Это все происходит уже в Kubernetes (понятно, что есть свой Kubernetes администратор который заранее позаботился об этом, но сам разработчик уже об этом не думает, у него есть заветная кнопка). Ему даже не нужно обращаться к администратору инфраструктуры или DBA.

Когда база данных переходит в какую-то более взрослую стадию, когда появляются большие нагрузки и объемы данных, может потребоваться переезд на какой-то отдельный инстанс или сервер из-за стремления получить низкие задержки на уровень сети или блочного ввода-вывода.

Они версионировались и складывались в хранилище артефактов, откуда разработчики могли брать нужный образ — сразу с требуемой схемой БД — и гонять у себя тест на машинке. Андрей: Когда я работал с разработчиками (тогда Kubernetes не был распространен), я готовил им докер-контейнеры с базой данных. Если им нужно было что-то дорабатывать, гонять внутренние тесты, использовать роботов, которые, например, автоматизировали тесты, и базы данных туда поставлялись в тех же контейнерах.

Виктор:

И там видеть Kubernetes мне не очень хочется, потому что я не вижу в нем смысла. Я больше работаю с базами на продакшене. Зачастую она мешает. Для меня это дополнительная прослойка, с которой нужно считаться.

А что касается разработки и тестов, проверки гипотез и всего остального — я целиком за. И докером я балуюсь, и даю образы с Postgres-ом и разным дополнительным софтом, установленным в этот образ, знакомым. Ничто человеческое мне не чуждо.

Алексей: Все мы балуемся докером…

это та же самая точка зрения: пока у нас что-то маленькое — либо это dev environment, либо маленький production – мы можем использовать Kubernetes. – Т.е. Но потом...

Поэтому стараемся выносить все что можно. Виктор: А потом важно ловить latency на всяких разных уровнях, и чем она меньше, тем лучше.

И в России тоже.
Благодарю всех за то, что нашли время поделиться своим опытом и буду рад всех видеть в апреле на нашем питерском HighLoad++.
– Тем не менее, у облаков есть хорошее будущее.

S. P. Полную видеозапись беседы можно найти тут.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть