Есть мнение, что будущее за 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-баз?
Алексей: Нет. Тренд скорее обратный. Людям, работающим с вещами типа RDS, не хватает гибкости в администрировании и управлении. В итоге мы получаем то же самое отношение «как к питомцам», но в инстансах EC2.
Виктор: Вырисовывается такая ситуация. Есть клиенты, у которых основные базы на продакшене очень нагружены. Естественно, они размещаются на выделенных железках и под постоянным присмотром. Но когда компания растет, разработка требует большого количества тестовых и девелоперских инстансов, и они уходят в виртуализацию. То есть это гибридный случай: под тесты и dev-окружение может закупаться железо или арендоваться виртуалки. Но продакшен остается на нормальном серьезном железе.
– Используется ли при этом Amazon RDS?
Алексей: Наши клиенты наоборот от RDS отказываются. Причина, как я уже говорил, в отсутствии гибкости в управлении.
Инстансы крешатся, и в некоторых случаях вопрос не решается только лишь арендой более мощной железки.
Многие проблемы ты не можешь решить сам — только с помощью поддержки.
– А можно ли привести примеры? Казалось бы, недавно Amazon купил OpenSCG — прекрасных ребят, которые должны были развить внутреннюю экспертизу Postgres. И я по своему опыту знаю, что экспертиза есть. Если ты открываешь тикет с саппортом Amazon RDS и натыкаешься на человека, который не может тебе помочь, просто закрываешь тикет и открываешь его снова, попадая уже на более грамотного.
Алексей: OpenSCG — это, конечно, команда профессионалов. Но покупка такой команды не закрывает 100% возможных ситуаций. Бывают проблемы, с которыми поддержка сталкивается впервые. У нас такое тоже происходит.
Из последнего — на одной из реплик PostgreSQL 10.6 у заказчика load average на хосте внезапно увеличился на 30–40 единиц, хотя нагрузки никакой нет. Такой непонятный подземный стук. Он не сильно влияет, но сама картина того, что 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 у дисков не очень честный. По сути там диски, подключенные по сети.
– Честный NVMe (локальные диски) — это тоже проблема. У Google и Amazon есть NVMe, но диски там эфемерные. Если ты перезапускаешь инстанс, то теряешь все данные, потому что тебе дают другую виртуалку.
Андрей: В Яндекс Облако мне прокомментировали, что в DB as service у них честный NVMe, но я с этим сервисом пока не сталкивался. Видимо, там немного другая архитектура на уровне предоставления ресурсов.
Над DB as service они очень сильно работают, так как используют его у себя для своих сервисов. Просто для внешних клиентов и внутреннего использования предусмотрены разные точки входа.
– А как ты думаешь, есть ли перспективы у российского Postgres в облаке? Взлетит или не взлетит?
Андрей:
У Яндекса отличная команда, довольно опытная, с хорошей экспертизой. Думаю, у них взлетит.
Во-первых, они сами эксплуатируют очень много Postgres (более 1000 баз данных на своих проектах), а т.к. эксплуатируют, все шишки и больные места будут отрабатывать и исправлять быстрее. Думаю, клиенту будет предоставлен конечный сервис довольно хорошего качества.
И спрос на такие решения есть. Возьмем стартап, который в начале не может обладать необходимой экспертизой по Postgres по разным причинам: дорого, не видят смысла, пробуют разные технологии. Для него это хорошее решение, потому что в таких сервисах ограничены «крутилки», которые не следует крутить, а если что, думаю, и техподдержка будет.
Правда, «Яндекс облако» пока еще на старте, и представлен не такой большой функционал на данный момент.
– У нас есть вопросы из чатика: что вы думаете о том, что при выдаче виртуалки у нас на этой машине может физически кто-то сидеть (throttling, steal time).
Виктор: Да, есть такой опыт. Как раз хотел это упомянуть. Есть клиенты, у которых развернуты свои системы виртуализации. Периодически они просят посмотреть какой-то не продуктовый сервер, и мы видим непонятную ситуацию: причин, почему оно должно было сломаться на этом сервере, мы не наблюдаем. Тогда мы переадресовываем вопросы их админам с просьбой посмотреть, что там творится на хосте.
– А что делать, есть ли аналогичный эффект в Amazon? Есть ли методы определить, что тебя «поджали»? pgbench гонять?
Алексей: Я такого не припомню. Но обычный способ — это определение через steal time. На графиках мониторинга мы, как правило, не видим каких-то больших значений.
– Я чувствую, что вы не очень любите managed Postgres. Не связано ли это с тем, что RDS у вас отнимает работу?
Алексей: Нет. Это связано скорее с тем, что у нас его просто нет. Managed Postgres хорош тем, что ты можешь развернуть инфраструктуру по нажатию на кнопку. Пока ты — стартап и просто складываешь или читаешь данные без какой-то всякой сложной логики, все хорошо. А когда ты переходишь некую грань, например начинаешь выполнять много JOIN, делать сложный SQL, возникает задача оптимизировать запросы и RDS перестает хватать. Требуется больше свободы и влияния, но имеющиеся инструменты не помогают тебе решать глубокие проблемы, связанные с утилизацией ресурсов внутри самого Postgres. Есть только возможность увеличить мощность железки: заплатил больше денег — получил.
Андрей: Тут не столько нелюбовь к RDS и боязнь за работу. Проблема в другом. Предположим, стартап взял RDS, он все им дает. А экспертизу он свою в Postgres так и не увеличил. Далее, допустим, стартап выстрелил. Нагрузки вырастают — увеличилась запись и чтение. В отсутствии своей экспертизы стартапу приходится искать людей на стороне. Приходят суровые DBA и видят, что не могут выжать больше из RDS, а вот из обычного EC2 инстанса вполне возможно получить больше производительности, как в примере, который я упоминал ранее. Если бы нас пустили на RDS, возможно, мы могли бы настроить и улучшить работу базы данных, но этого не стали делать.
– Вопрос с доступом решается. Есть managed Postgres, которые дают ssh-доступ (и даже полностью root), например, небольшая компания Aiven из Финляндии. По умолчанию они root-доступ не дают, но основатель (а я с ним общался пару раз) говорил о готовности выдать доступ по запросу.
Андрей: Вопрос не только в доступе. Почему мы лучше относимся к чистым железкам? Потому что у нас довольно много разных клиентов, и у каждого своя инфраструктура. И инфраструктуры бывают настолько далеки друг от друга, что общей методологии, работающей везде одинаково, у нас просто не получается. Потому что есть те, у кого свое железо, и они никак не могут хоститься где-то (по каким-то своим правилам и ограничениям), и есть те, кто в облаках.
– Ты хочешь сказать, что определение неиспользуемых индексов зависит от железки? Или какие-то другие банальные вещи?
Андрей: С точки зрения администрирования именно схемы базы данных и определения неиспользуемых индексов ничем не отличаются облака от своего железа. Все унифицировано.
Различие облака и реальной железки — в прослойке между базой и конкретно железом, которое лежит снизу, — это операционная система и используемые виртуализации. Когда у тебя большие базы, тебе важно, насколько быстро диски отдают и принимают данные, насколько эффективно используется память и процессор, поэтому крайне важно уменьшить влияние этой прослойки, чтобы база работала наиболее эффективно.
– Еще один вопрос от зрителей: а как на счет настроек ядра?
Виктор: В EC2 такие вещи настраиваются.
– Появляются новые решения класса «managed Postgres» от известных вендоров, кроме привычных Amazon и Google. Например, Nutanix и SAP заявили в 2018 о создании решений на основе Postgres. Вам не кажется, что все эти ребята ведут нас к появлению каких-то решений, которые будут делать то же самое, но только на вашей железке? Чтобы можно было нажать кнопочку и развернуть новый Postgres, где уже настроены бекапы и репликация.
Алексей: Мне кажется, SAP и другим это не совсем выгодно. Это крупные вендоры железа и программного обеспечения. Они делают продукт с целью зарабатывать деньги. Продать поддержку хотя бы. Поэтому надо смотреть на то, как они будут извлекать из этого прибыль. Если им будет выгодна такая модель предоставления продукта, то почему бы и нет?
– Я имел в виду несколько иное. Конкретно эти ребята не будут ничего выкладывать в open source и отдавать бесплатно. Но вам не кажется, что кто-то из более маленьких, но резвых сделает что-то подобное? Возможно, это будет ориентировано на Kubernetes, Operator Framework. Уже есть пара разработок, которые делают операторы — Zalando, например. И не кажется ли вам, что облачные RDS помогают постепенному переходу к таким решениям? Мы видим, как можно жить, не залезая в конфиги руками.
Алексей: Это получается не совсем managed.
Тебе все равно нужно будет иметь специалистов, которые будут за всем этим следить и лазить под капот, если вдруг что-то пойдет не так.
Даже тот самый Kubernetes — это очень сложная машина, под капотом у которой множество компонентов. Формально это всего пять бинарников. Но их взаимодействие между собой описывается томами документации и кучей информации по чатам, рассылкам и Google Groups. Т.е. все равно нужен специалист, который будет за этой кухней следить.
Плюс все это очень динамично развивается. Обратная совместимость ломается от релиза к релизу. Т.е. все очень зыбкое и нестабильное. Когда все утрясется, может быть, мы получим годный продукт, стабильный и надежный. Но пока все не очень.
Виктор: Мы начинаем говорить о том, что у нас появляется дополнительный слой инфраструктуры, которым нужно управлять – оркестровать этот Kubernetes.
Я не согласен с тем, что он магическим образом по нажатию кнопки будет всегда работать так, как нам хочется. Нужно держать соответствующих специалистов.
А второе – наши клиенты постоянно адаптируются к изменениям в бизнесе. Соответственно, нагрузка в базе постоянно меняется. И если мы три месяца назад все вылизали, в результате чего все запросы работали так, как надо, и все было отлично, то сегодня или завтра может прийти новый запрос, или в связи с изменением данных существующий запрос перестанет работать так, как надо. И нам нужно анализировать ситуацию и лезть в настройки системы. И это та автоматизация, которую, как мне кажется, сделать подобными managed-инстансами очень сложно. Когда облака достигнут такого состояния, что они будут адаптироваться еще и к таким ситуациям, я не знаю. Но пока это значительная часть работы, которую необходимо делать – необходимо адаптировать настройки базы к изменениям паттерна приходящих запросов.
А поскольку само облако – дополнительная нагрузка по администрированию, нам проще, когда этой прослойки просто нет, потому что мы можем сконцентрироваться на вопросах работы базы.
Если клиент желает жить в облаке и у него есть экспертиза, мы ничего не имеем против. Главное, чтобы у нас была возможность, когда базе станет не очень хорошо, залезть (желательно по ssh), все проверить и получить доступ ко всей статистике.
Алексей: Не обязательно по ssh. Но в любом случае нужны инструменты для диагностики. Потому что диагностика по электронной почте – это очень долго и нудно. Раздражает, когда ты отправляешь в чат ссылку на запрос, который нужно выполнить, клиент с другой стороны переходит по этой ссылке, копирует запрос, потом копирует тебе результат или высылает скриншот. Это все время.
Гораздо проще подключиться и посмотреть непосредственно, проверить какие-то свои гипотезы и действовать дальше уже от них.
– А есть у вас активные примеры того, где Kubernetes уже используется и в нем живет Postgres?
Алексей: У меня, к сожалению, нет. Но я бы очень хотел. Мне очень нравится Kubernetes, мне близка его концепция и философия.
На мой взгляд, Kubernetes – это такая штука, которая сподвигает людей больше программировать, больше создавать продукт, не задумываясь о побочных вещах типа внутреннего устройства инфраструктуры.
Аналогичную роль раньше выполняло ООП. Оно появилось, и много людей заинтересовалось этой сферой, потому что программирование стало в какой-то степени легче. Kubernetes тоже замыкает на себе многие вещи, скрывает их под капотом и позволяет человеку сосредоточиться на творческом аспекте и программировать больше.
Kubernetes реализует в себе поддержку инстансов, подов, и приложение работает. Если оно вдруг упало – ну и ладно, Kubernetes запустит его снова. Т.е. разработчик и администратор избавлены от головной боли и постоянного слежения. Мне нравится это реагирование на ситуацию. Когда что-то падает, оно перезапускается автоматически.
Для баз данных, может, это и не совсем корректно и оптимально. Потому что постоянно падающая база — это не очень хорошо, пускай она даже поднимается в других подах, на других кублетах. Но сама эта идея мне очень нравится.
– Думаешь, у него есть хорошее будущее?
Алексей: Я не знаю, мне сложно предсказывать. Мне кажется, у этой штуки есть потенциал. Она как минимум еще какое-то время будет жить, тем более вокруг нее уже есть сложившаяся экосистема. Вокруг нее много разного инструментария, вспомогательных проектов, которые улучшают работу с Kubernetes. И сам Kubernetes растет. В организацию CNCF входят многие крупные вендоры программного обеспечения. Видно, что жизнь идет.
Хотя есть один такой довольно забавный момент – который я недавно наблюдал в телеграмм-канале kubernetes_ru. Там был график активности на github, который показывает снижение активности в цикле разработки Kubernetes: количество коммитов несколько лет плавно снижается. Рядом приводили график Postgres, там все идет стабильно.
Но, это, конечно, все юмор. Мне кажется, Kubernetes – это живая динамичная технология, которая будет развиваться. У нее будет какое-то свое место в истории IT.
– А вы слышали про такую штуку, как Amazon Aurora PostgreSQL Serverless? Фактически это следующий уровень, когда ты не думаешь, какой у тебя инстанс и сколько ему нужно памяти. При необходимости увеличения ресурсов можно поменять на лету инстанс, оставляя соединение. Т.е. мы еще меньше думаем про железки.
Алексей:
Аврора мне кажется интересной. Но это пока такой черный ящик.
Да, мы меньше думаем про железки. Но у нас получается удобство, некая кнопка, на которую ты нажал и у тебя все работает под капотом. Это как ключ зажигания в машине: ты его повернул, завел машину и поехал. И ты не думаешь, что у тебя там под капотом что-то крутится. Детали скрыты от водителя.
– Спасибо за это позитивное мнение. А то до сих пор у нас получался негативный образ облаков и в целом этой идеи сокрытия потрохов от инженеров. На самом деле я тоже придерживаюсь мнения, что это классно, это более высокий уровень.
Андрей: Тут получается большая сепарация. К примеру, мы все сейчас пользуемся смартфонами. Но люди, которые делают микросхемы для этих устройств, – это очень маленькое узкоспециализированное сообщество. Разговаривая с таким человеком, ты понимаешь, что он бог в области микроэлектроники, в то время как раньше таких людей больше на виду было, да и микроэлектроника была куда проще.
Т.е. начинается разделение. Базы данных как сервис – доступная технология, ей пользуются, она покрывает 70% нужд. Люди не заморачиваются и действительно работают над своим продуктом. Им не нужна никакая специализированная экспертиза.
А такие товарищи, как мы, становятся этакими «инженерами микросхемок», о которых мало кто будет знать.
– Я полностью согласен. А как ты думаешь, может такое случиться, что DBA расщепится на несколько профессий: кто-то будет копаться под капотом, а кто-то — анализировать индексы, схему?
Андрей: В принципе, человек, который анализирует запросы, – это не столько DBA, сколько SQL-developer. Когда я работал с Oracle в качестве SQL-developer, половина моих задач заключалась в том, чтобы смотреть, насколько оптимальны запросы, что творится с таблицами. Я совсем не знал, как устанавливать и настраивать Oracle. Моя задача была оптимизировать все с точки зрения схемы БД. А оракловые DBA для меня были отдельными богами, которые занимались чем-то своим.
DBA — это все-таки больше «подкапотный» человек, и тут говорить о разделении не совсем корректно.
Еще я хотел добавить про Kubernetes. В целом я поддерживают позицию Алексея, но хочу рассказать про реалии. Мы все были в эти дни на конференции. И я разговаривал с ребятами, которые активно используют Kubernetes и другие средства оркестрации. И реальные ситуации сейчас у них таковы, что они гвоздями прибивают базу к определенному инстансу и прокидывают volume в нужный контейнер. Т.е. они добавили еще одну прослойку, которую нужно отдельно настраивать. И для меня такой подход выглядит точно так же, как отдельно стоящая железка.
– Все еще сложнее получается?
Андрей: Да.
Сейчас реальность такова, что они усложняют себе работу. Да, они говорят, что у нас все в единой инфраструктуре. Но им нужно делать дополнительные телодвижения, чтобы прибить Postgres (железка для базы и ничего кроме базы там нет). При этом они запрещают поду Postgres подниматься на каком-то другом. Т.е. если база падает (допустим, железка сгорела), то автоматически ее уже не поднимешь.
Нужно бежать в магазин или в облако, покупать точно такую же железку и делать дополнительные телодвижения по новому прибиванию гвоздями.
Год назад на конференции те же люди мне говорили, что это клево, когда база уплывает на другой под. Это позволяет не заботиться ни о чем. Сразу несколько человек вели одинаковые речи. Но в этом году они все прибили базы данных гвоздями к определенным железкам.
– А почему они это сделали?
Андрей: У них начали возникать какие-то проблемы. Правда, я не особо спрашивал, просто заметил такую тенденцию.
Кстати, то же самое касается Cassandra. Ее также прибивают к конкретным инстансам. Т.е. на данный момент все это — усложнение работы человека, который возится с Kubernetes.
Хотя в будущем, я думаю, все будет лучше. Энтузиасты набьют шишек, создадут технологии, и мы получим действительно хорошее решение.
Т.е. у меня двойная позиция. Как DBA, я считаю, что все надо оставить по старому – никого в базу не пускать. С другой стороны, я всегда рад экспериментам, потому что в них рождается что-то новое – новые технологии и улучшение жизни в целом.
– Когда нас ждет это улучшение жизни?
Андрей: Народ в эти полки прибывает. Правда, сейчас наблюдается некоторое спокойствие. Но, видимо, остались те, кому это действительно нужно и кто хочет с Kubernetes работать. Я думаю, пару лет, наверное, еще пройдет, прежде чем мы получим что-то более-менее нормальное с точки зрения использования БД именно в Kubernetes (чтобы мы могли использовать базы данных без проблем).
Алексей: Я бы хотел добавить про Kubernetes. Я разговаривал с Сашей Кукушкиным – это разработчик patroni. У них в Zalando довольно много Kubernetes. Доля серверов в облаке высока, и она постоянно увеличивается, несмотря на более высокую стоимость владения (если ты хочешь запровиженить железку – это долго, а в Amazon все уже есть, можно вводить в оборот). Их это устраивает, потому что разработчикам нужно со всем этим легко работать – им нужны базы. При этом разработчиков много, микросервисов – тоже. Их выход – как раз-таки Kubernetes.
– Но они решили не идти в RDS. Они пошли в EC2 и подготовили Postgres в облаке самостоятельно. Им пришлось это сделать для patroni (https://github.com/zalando/patroni), который сейчас стал лидером на рынке.
Алексей: Да, я считаю, что это уже стандарт де-факто для high availability.
– Согласен. Следующая потребность — сделать волшебную кнопку, чтобы инстанс развернулся и дальше могли подключаться приложения?
Алексей: Я думаю, что у них это уже в какой-то степени реализовано.
Но тем не менее в Zalando есть свой небольшой штат DBA, которые пишут patroni. Т.е. несмотря на то, что у них есть много инстансов под Kubernetes и хорошая экспертиза по нему, DBA нужны.
– Согласен. Это не отменяет востребованности DBA, но один DBA может «пасти» большее «стадо».
Алексей: Да, у него получается меньше работы. Он меньше заморочен на настройке конфигов и файловеров. Все само работает, живет своей жизнью, сообщая результаты в мониторинг.
– А какую проблему все-таки решает Kubernetes? Зачем туда пихать базу?
Алексей: Если ты готовишь стартап или какой-то небольшое проект, на этапе взлета нужно проверять гипотезы. Ты в Kubernetes просто разворачиваешь небольшую базу – у тебя там мало данных, мало запросов. При этом Kubernetes в какой-то степени помогает уменьшить объем администрирования. Разработчик описывает свой деплоймент и там же запрашивает выделить пространство под базу с желаемым объемом. Ему даже не нужно обращаться к администратору инфраструктуры или DBA. Это все происходит уже в Kubernetes (понятно, что есть свой Kubernetes администратор который заранее позаботился об этом, но сам разработчик уже об этом не думает, у него есть заветная кнопка).
Когда база данных переходит в какую-то более взрослую стадию, когда появляются большие нагрузки и объемы данных, может потребоваться переезд на какой-то отдельный инстанс или сервер из-за стремления получить низкие задержки на уровень сети или блочного ввода-вывода.
Андрей: Когда я работал с разработчиками (тогда Kubernetes не был распространен), я готовил им докер-контейнеры с базой данных. Они версионировались и складывались в хранилище артефактов, откуда разработчики могли брать нужный образ — сразу с требуемой схемой БД — и гонять у себя тест на машинке. Если им нужно было что-то дорабатывать, гонять внутренние тесты, использовать роботов, которые, например, автоматизировали тесты, и базы данных туда поставлялись в тех же контейнерах.
Виктор:
Я больше работаю с базами на продакшене. И там видеть Kubernetes мне не очень хочется, потому что я не вижу в нем смысла. Для меня это дополнительная прослойка, с которой нужно считаться. Зачастую она мешает.
А что касается разработки и тестов, проверки гипотез и всего остального — я целиком за. И докером я балуюсь, и даю образы с Postgres-ом и разным дополнительным софтом, установленным в этот образ, знакомым. Ничто человеческое мне не чуждо.
Алексей: Все мы балуемся докером…
– Т.е. это та же самая точка зрения: пока у нас что-то маленькое — либо это dev environment, либо маленький production – мы можем использовать Kubernetes. Но потом...
Виктор: А потом важно ловить latency на всяких разных уровнях, и чем она меньше, тем лучше. Поэтому стараемся выносить все что можно.
– Тем не менее, у облаков есть хорошее будущее. И в России тоже.
Благодарю всех за то, что нашли время поделиться своим опытом и буду рад всех видеть в апреле на нашем питерском HighLoad++.
P.S. Полную видеозапись беседы можно найти тут.
Автор: Олег Бунин
