Комментарии 20
А вы попробуйте высоконагруженную базу запихнуть. 96 кор, 2Тб RAM, локальные SSD чтобы выжать максимальную скорость
Мы скорее пытаемся автоматизировать жизненный цикл БД для множества микросервисов для обеспечения polyglot persistence. Если какой-то микросервис упирается по ресурсам, то применяем шардирование для горизонтального масштабирования как раз, чтобы конкретные инстансы не распухали.
Ну и в целом не понимаю, что мешает засетапить подобную базу в Kubernetes, если есть соответствующие ноды в кластере.
Добрый день.
Не сочтите оффтопом, но может будет какой-то шанс через вас достучаться до руководства Авито...
Вы не в курсе, будет когда-то создан сервис поиска по картинке?
Я помню какое-то длительное время назад это уже было, видимо в качестве эксперимента, но потом отменили...
Такой функционал (пусть даже будет платным) невероятно сократит время поиска по однообразным объявлениям!
Пример: такой раритет как видеокассеты продаются на Авито тысячами.
И чтобы найти нужную приходится искать иголку в стоге сена. Это дико раздражает...
Добрый день!
К сожалению, не могу ответить, т.к. сильно далеко от разработки самого продукта. Наша команда пилит платформенную автоматику :)
Понял, спасибо. А куда написать еще можно? Обычный саппорт первой линии бесполезен четь более чем полностью...
Я немного изучил этот вопрос. Ранее функция поиска по картинкам действительно была доступна, вот, например, доклад с Highload: https://youtu.be/AVNeOgT1ms0?t=418. Однако сейчас она, к сожалению, недоступна по внутренним причинам. Возможно, лучше обратиться через официальные каналы коммуникации, но, к сожалению, я не могу подсказать конкретные. В любом случае ваши комментарии в блоге компании — хороший способ поделиться своей потребностью, и, возможно, кто-то из команды обратит на них внимание!
С текущими и давно стабильными CAS Latency у вас нереально крутая банда-команда!!
А для чего это делать в кубере? Столь большие инстансы DB обычно редки. Их не нужно разворачивать в день по 100 новых инстансов.
С такими потреблениями впору выделять физический сервер, заодно чтобы конфигурация NUMA была нативная (без всяких скрывающих её виртуализаций). Кубер в общем случае про другое, про то, как даже не на физическом сервере (физический сервер раз в 10-100 мощнее, чем стоило бы отдавать нодам), а на виртуалке, позапускать кучу не очень больших сервисов.
Если есть необходимость в базе 96 кор и 2Тб RAM то это прямым образом указывает на то, что архитектура сервиса плохо заточена под масштабирование. Если у вас возрастает нагрузка, вы покупаете другой сервер, куда вставляете 2 процессора по 96 кор и переливаете базу?
А кубернетес же не про это. Он предполагает, что вы можете скейлить ворклоад почти бесконечно, просто создавая больше подов приложения. А так как с базами это плохо работает, то используется другие подходы. Примеры: для каждого сервиса своя небольшая база, использование баз, поддерживающих шардирование, запись через брокеры сообщений, использование нескольких слоев кэширования.
Да, тут теряется консистентность, которую гарантирует БД. Например, если один клиент что-то записал и другой тут же прочитал - данные будут уже обновленные. А использование очередей и кэшей приводит к задержкам доставки актуальных данных. Ну или вы не сможете сделать select.. join из таблиц разных сервисов, потому что одна таблица - это clickhouse из 40 нод, а вторая это opensearch из 10 нод.
Но зато при этом каждый шард базы получается не очень большой, и если ещё имеет реплику - можно обращаться с базами почти как со stateless. То есть включать, выключать, перемещать на другие ноды или другие хранилища. В конце концов раздуть каждый инстас до 96 кор и 2Тб RAM в моменте.
А чтобы не менеджить много маленьких баз с большим количеством шардов или реплик вручную, в кубернетес можно использовать операторы, которые сделают бОльшую часть работы за вас. Не все операторы идеальны, но они хотя бы предсказуемы, так как работают по конкретным алгоритмам. В отличие от части инженеров )
Подскажите пожалуйста, какие преимущества дает развертывание БД в k8s по сравнению с развертыванием в виртуальных машинах или на выделенных серверах?
Стоит ли овчинка выделки?
Преимущества становятся видны, когда вам нужно разворачивать десятки, а может быть сотни баз, и при этом ваши приложения работают в кубернетес.
Тогда ямл-девелопер описывает манифесты приложений проекта, основываясь на примитивах кубернетес. Deployment, Statefulsets. А когда нужна база - описывает базу прям там же, используя те же примитивы кубернетес. Например, пишет CR (Custom Resource) нужной базы.
Таким образом нет двух мест, где нужно описать проект: для приложений - манифесты кубернетес, а для баз данных - terraform для виртуалок и ansible для конфигурации. Копировать и удалять проекты целиком становится проще. Создал новое окружение - базы там появились вместе с приложениями. Удалил окружение - базы исчезли вместе с окружением. Вернул окружение - базы вернулись обратно, и даже переналились из последнего бэкапа сами.
Для локальной разработки тоже не нужно делать отдельные схемы. Если сейчас у вас база на виртуалке, а локально разработчик запускает ее в докере - это две разных конфигурации. А так он может запускать все в kind/minikube или в dev-кластере, и все будет одинаково.
При этом никто вам не запрещает запускать контейнеры (поды) с базами на выделенных виртуалках или вообще на выделенных железных нодах. Или для дев-сред на виртуалках, а для прод - на железных нодах. Ведь нет никакой разницы для процесса, где он запущен, в контейнере или нет. У вас только меняется средство доставки конфигурации и бинарей. В случае с виртуалками это какой нибудь terraform + ansible/puppet. А в случае с контейнерами - бинари лежат в образе, а конфигурации - в configmap/secrets в etcd kubernetes. Если у вас уже есть kubernetes, то зачем вам еще terraform+ansible/puppet?
Унификация хорошо, но k8s еще сыроват для кластерных приложений с персистентностью. В статье и описывается часть острых углов и борьба с ними.
В результате сложнее все получается, чем по классике.
А terraform с ansible/pupet все равно нужны для разверывания нод для кластера k8s.
Утверждение про "сыроват" - это относительно очень, смотря с чем сравнивать.
А вот для создания нод вполне можно обойтись без terraform и ansible/puppet. Ноды могут создаваться и управляться через machine controller manager прямо из кубернетес. Как в облаках, так в общем то и дя bare metal серверов актуально
https://github.com/gardener/machine-controller-manager
https://deckhouse.ru/products/kubernetes-platform/documentation/v1/kubernetes.html
Кластерам с персистентностью стало тяжко без кубера? 8-/
базы в Kubernetes (k8s) — сложные, ненадёжные и их неудобно поддерживать. Но я считаю, что это не так. Если систему немного «допилить», то результат точно окупится: бизнес будет расти и масштабироваться быстрее.
Вопрос не в удобстве или ненадежности. По моему мнению, основная и довольно весомая проблема баз в кубере - вам нужен не просто хороший DBA, а хороший DBA с опытом внедрения и эксплуатации БД в K8S. K8S так или иначе привносит свои нюансы работы в систему, дополнительные абстракции, о которых DBA должен знать и помнить. Ну типа вы понимаете проблему для большинства компаний? DBA и так толковых не найдешь, а тут ещё таких.
Это у вас вот есть целый DBaaS, вы можете себе позволить такое, команда как раз и нацелена решать именно такие вопросы. Но DBaaS ну вот вообще не везде есть, не все могут такое себе позволить. Не все компании размером с Авито.
Запихнуть то базу as is в кубер - это то без проблем, вот вообще без проблем. А вот что делать при проблемах, что делать с тонкими настройками у конкретной компании.
Я бы кстати послушал опыт Oracle в k8s
Да, вы совершенно правы. Такое решение подходит не для каждой компании, а только для крупных, где менеджить нужно тысячи инстансов. Для наших DBA мы стараемся упрощать жизнь как можем: пилим отдельные CLI-утилиты, которые уходят от абстракций k8s; предоставляем более понятый API, согласованный с DBA, чтобы базами можно было управлять напрямую через платформу и т.д. И вообще держим тесный контакт с ними как с основными стейкхолдерами. Но даже с такими подходами ребятам все равно необходимо знать какой-никакой минимум по k8s, хотя бы на уровне чтения логов контейнеров Pod-a.
Эксплуатация Stateful-приложений в Kubernetes на примере баз данных в Авито