Привет! Как и обещали, сегодня мы готовы отвечать на вопросы про бэкенд в Avito, разработку серверной части в целом и про высокие нагрузки в частности. Как работается с сайтом, на который ежемесячно заходит почти четверть населения России? Спросите у нас! Отвечать будем с 12 до 19 часов по московскому времени. Под катом я представляю шесть моих коллег, которые сегодня будут с вами на связи и напоминаю о возможных темах диалога.
AMA!
UPD, 19:03 мск: Спасибо всем за вопросы!
Официально мы завершаем АМА и прощаемся, но по возможности будем отвечать на комментарии.
Виталий Леонов, vleonov
Руководитель разработки серверной части.
В Авито 5 лет, начинал бекенд-разработчиком, теперь отвечает за всю серверную разработку.
Виктор Диктор, Rpsl
Техлид в юните монетизации. Более 10 лет опыта в разработке сайтов. В Авито отвечает за кроссплатформенную команду разработки в одном из юнитов монетизации.
Николай Балакирев, madfaill
Ведущий разработчик серверной части, техлид юнита Avito.Pro. Отвечает за сервисы Avito для профессионалов: ActiAgent, ActiDealer, Avito PRO. Ему можно адресовать также вопросы по сервису Autoteka.
Игорь Сомов, Cubist
Ведущий разработчик серверной части. В Avito 2 года. Работает в юните модерации, занимается несколькими внутренними проектами.
Андрей Смирнов, martovskiy
Ведущий разработчик серверной части. До Avito работал в Playfon и Sotmarket — везде были высокие нагрузки и большие требования к надежности систем. Занимался статистикой, поиском и деплоем. В Авито работает над поисковыми системами, чтобы они работали быстро, точно и безотказно.
Сергей Орлов, marrrvin
Архитектор серверной части. Лидер юнита Архитектура. В Avito более двух лет. Занимается развитием архитектуры backend, сбором и внедрением лучших практик. Строит внутренний PAAS. Может ответить на вопросы, связанные с облачной инфраструктурой в целом и Kubernetes в частности, Continuous Integration, Delivery и Deployment, использованием микросервисного подхода в компании.
Возможные темы:
- устройство наших внутренних проектов;
- истории успехов и провалов;
- высокие нагрузки и вот это всё;
- что мы пилим на PHP, а для чего используем Go и Python;
- как работает наш поиск на Sphinx;
- инфраструктура, Kubernetes, Continuous Integration, Delivery и Deployment;
- и так далее.
Цифры
Avito — это 300+ серверов, 10TB в postgres, 270TB картинок, 13Gbit/s трафика вечером в пике, до 20000 rps к бекенду.
Ссылки
В целом о проекте Avito рассказывает наш самый первый пост на Хабре. А вот еще несколько ссылок на публикации, которые вы могли пропустить:
Ждём ваших вопросов, историй и уточнений. Если хотите получить гарантированный ответ — пишите запрос в комментарии первого уровня. Поехали!
Комментарии (120)
boss_lexa
13.10.2017 12:19+1Как боретесь с кликфродом в Avito Контекст?
Какие данные анализируете?
На каких данных обучали первоначально?
Rpsl
13.10.2017 12:27+1Увы, полностью рассказывать все механизмы борьбы с кликфродом и на каких именно данных это обучается мы не можем, т.к. это является коммерческой тайной.
Мы стараемся собирать всю возможную информацию которая нам доступна и передаем нашим специалистам, которые оптимизируют и настраивают различные веса для них. Но если поверхностно, то статистика кликов, история пользователя, параметры объявления.
boss_lexa
13.10.2017 12:44+1А можете порекомендовать какие-то варианты решения задачи?
Rpsl
13.10.2017 12:52+1В первую очередь смотрите на клики которые происходят и собирайте по ним информацию. Кто кликал, когда, куда кликал еще. Нормальный пользователь оставляет за собой след в интернете, а у роботов следов нету.
Почитайте про fingerprint https://habrahabr.ru/company/oleg-bunin/blog/321294/
boss_lexa
13.10.2017 15:06C fingerprint знаком, спасибо, мой вопрос больше о данных.
Как бороться с кликфродом на начальном этапе, пока нет собственных данных о кликфроде?
Например:
Есть сайт-маркетплейс с каталогом товаров от разных поставщиков + исторические данные о переходах/конверсиях (без разметки о кликфроде). Решили продавать рекламу с оплатой за клики (переходы на карточки товаров).
Варианты решения на старте:
- Только вручную
- Обучить модель на собственных исторических данных о переходах и выявлять аномалии?
- Платные сторонние решения? Какие?
akass
13.10.2017 12:36Расскажите какие трудности были с реализацией Autoteka, там же много сторонних сервисов?
madfaill
13.10.2017 12:42+1Сервисов много, основные трудности — согласования.
Все интересное что можно было рассказать, есть в докладе: youtu.be/OGf6mawQwaw
Если появятся более детальные вопросы — готов на них ответить.
madfaill
13.10.2017 13:21Коллега напоминает, что помимо согласований есть еще нормализация, валидация и очистка данных. Универсального подхода тут нет, в конкретных случаях приходится подходить индивидуально. Общее правило в таких условиях, как подсказывает капитан очевидность, — система мониторинга и алертинга. К счастью, для этого у нас есть все инструменты: habrahabr.ru/company/avito/blog/335410.
akass
13.10.2017 13:27Большое спасибо за ответ, я так понимаю взаимодействие с ГИБДД, дилерами и прочими достаточно трудоемкая задача, будете ли вы расширять ассортимент информации или пока остановитесь на отработке текущего? (Сам пользуюсь).
Доклад посмотрел, весьма интересно, но по схеме больше похоже просто на сервисную архитектуру. Расскажите пожалуйста про service discovery и масштабирование всего этого дела.madfaill
13.10.2017 14:39+1Список источников непрерывно пополняется, покрытие постоянно увеличивается. Большая работа предстоит по улучшению UX и повышению скорости получения отчета, но это параллельные задачи, одна не отменяет другой.
Service discovery и инфраструктура у нас общая с Авито, отличие — больше гибкости в выборе стека технологий. Архитектура действительно сервисная, масштабируется и живет все в кубернетисе.
В плане взаимодействия с источниками все непросто, к поставщикам уникальных данных приходится подключаться на их условиях без альтернатив — шифрование проприетарным софтом на сертифицированном железе. Под такие источники заводим отдельные сервисы, которые работает только с ними, а внутри к ним уже ходим как к простым API.
grisme
13.10.2017 12:51+1Рассматривали какие-то аналоги Go? Что было до него? И почему в итоге остановились на нём?
marrrvin
13.10.2017 14:11+1Для разработки backend мы используем 4 языка: php7, python3, go, java. Каждый язык нашел свою область применения. На php пишем проекты с большим количеством бизнес-логики. go используется для высоконагруженных инфраструктурных сервисов. Часто выбор языка определяется командой, в которой он используется — если вся команда пишет на питоне, то при наличии нескольких вариантов новый сервис тоже будет на нем. Также огромную роль играет наличие библиотек — например, есть сервис использует ML, то скорее всего это будет python.
Gr1ver
13.10.2017 13:00+1Учитывая объемы хранимой информации, интересно узнать какие технологии используете для поиска и фильтрации. Как эти технологии используете, как добиваетесь быстрой выдачи результата при постоянно растущих объемах информации.
martovskiy
13.10.2017 14:53Для поиска мы используем поисковый движок sphinxsearch. Данные храним в realtime индексах — это позволяет обновлять данные на выдаче очень быстро.
Чтобы быстро доставлять новые данные в индекс, мы написали GO демон который готовит и рассылает запросы с обновлениями на все поисковые сервера.
Сейчас у нас 38.5млн активных объявлений. В пик мы получаем около 16К запросов в секунду. 95 процентиль времени ответа поиска примерно 12мс.
Realtime индексы со временем деградируют в производительности, поэтому ежедневно делаем полную реиндексацию и еще один раз в день производим оптимизацию индексов.Gr1ver
13.10.2017 15:17Спасибо за ответ! Если я правильно понимаю, то поисковые сервера в этом случае представляют из себя реплики на которые loadbalancer кидает запросы, что позволяет проводить реиндексацию без потери работоспособности, поправьте если ошибаюсь :)
Если не секрет, сколько времени занимает реиндексация одного сервера в вашей ситуации?martovskiy
13.10.2017 15:51У нас нет понятия реиндексация одного сервера, мы реиндексируем кластер серверов.
Индексация происходит на отдельном сервере и уже с него доставка индексов на все сервера кластера через uftp.
Весь этот процесс занимает 500 секунд.
Pahanini
13.10.2017 20:51Вы используете postgres, там есть FTS с аналогичными возможностями, почему все таки sphinx?
martovskiy
13.10.2017 23:14FTS есть, но скорость работы и гибкость иная.
Если нагрузка небольшая и нужен просто поиск, то конечно стоит использовать FTS в postgres.Pahanini
14.10.2017 08:31+1Ну скорость — понятно. А что с гибкостью? Легче настраивается ранжирование или что-то другое?
vic1984
13.10.2017 13:01Расскажите о системе деплоя софта и конфигураций: путь от системы контроля версий до состояния, когда код разложен на все машины
marrrvin
13.10.2017 14:51Тут есть два варианта — унаследованный путь развертывания монолита и путь развертывания сервисов.
Монолит развертывается набором python-скриптов на основе библиотеки fabric.
Сервисы развертываются через CI/CD сервер в Kubernetes кластер при помощи специального пакетного менеджера helm.
noize
13.10.2017 13:02Расскажите(дайте ссылку на статью если есть) про опыт использования языка Go в вашем проекте. Спасибо.
marrrvin
13.10.2017 14:36+1Для обзорного представления можно посмотреть видео
www.youtube.com/watch?v=1KmR_O9NMpU&t=322s
GoodGod
13.10.2017 13:02Добрый день, хотел бы очень хорошо освоить базы данных (оптимизация SQL запросов). Например если взять php, то ты всегда можешь посмотреть как устроена библиотека или фреймворк и стать мега-профессионалом, потому что будешь знать в точности как работает каждая строчка библиотеки, весь стек вызовов конкретной, нужной тебе функции, все детали алгоритмов, используемых в этой функции. Где знания такого же уровня можно получить по оптимизации SQL запросов? Спасибо.
vleonov
13.10.2017 13:14В первую очередь стоит изучить документацию https://www.postgresql.org/docs/, она написана очень хорошо и подробно. Много полезной информации обсуждается в рассылках: https://www.postgresql.org/list/. Также советуем посмотреть обучающие видео или пройти курсы от Postgres Pro: https://postgrespro.ru/education/courses
Cubist
13.10.2017 13:19Конечно, если вам требуется понимание
в точности как работает каждая строчка библиотеки, весь стек вызовов конкретной, нужной тебе функции, все детали алгоритмов, используемых в этой функции
То можете посмотреть исходники на C — https://github.com/postgres/postgres
Если вы используете не PostgreSQL, то просто поищите Ваше название github :)
brozen_zwork
13.10.2017 13:21>Строит внутренний PAAS
Очень интересно. На kubernetes? Для каких нужд (devel/prod)? Кто клиенты и как они заказывают себе ресурсы? Есть ли какие-то ограничения по ресурсам, автоматически ли апрувите или нет?marrrvin
13.10.2017 14:56Да, Kubernetes и Docker.
Как для dev, так и для prod.
В случае dev это автотесты, dev-окружения для разработки, staging, внутренние ресурсы.
В случае prod — сервисы, обрабатывающие запросы пользователей и различные демоны для обработки данных.
Клиенты — другие юниты компании. Каждый юнит отвечает за заказ hardware для своих задач, естественно, мы имеем некоторый запас на всякий случай.
JSmitty
13.10.2017 13:36Что из постгресных фич (или обще-SQL, но не очень типичных) используете? И какие надстройки/расширения к стандартному PostgreSQL, если есть?
Храните ли в базах JSON, и если да — то как работаете (насколько сложные запросы, используете ли индексы по JSON полям)?
Насколько сильно логика бэкенда лежит на базе? Порядок количества баз/таблиц/хранимок?Cubist
13.10.2017 14:37Используем «ванильный» PostgresSQL версий 9.2, 9.4, и 9.5. Из необычного можно отметить прокидывание данных через сессионные переменные внутрь deferred триггеров, отправку метрик через механизм LISTEN/NOTIFY в графит (aka pg_metricus, подробнее https://habrahabr.ru/company/avito/blog/323900/). Активно используем pgq и londiste. Сделали свой деплоер хранимых процедур через переопределение search_path, может быть когда-нибудь расскажем подробнее.
Из contrib используем pg_stat_statements, int_array, dblink и pageinspect.
JSON в базах храним как text, как json, и как jsonb, но индексы не используем и поиск/фильтрацию по jsonb не делаем.
Логика бэкенда пока лежит на базе сильно, но мы работаем над этим.
Баз меньше 100, таблиц от 10 до 1000 на базу. Хранимых процедур тоже где-то от 10 до 1000 на базу, а где-то их и нет совсем.
Blackzeppelin
13.10.2017 13:36Какие трудности были с настройкой медиациеи рекламных сетей? На Авито стоит код не одной крутилки, а они, как известно, не шибко дружат между собой, но у вас всё, вроде бы, работает довольно шустро и, наверное, имеет довольно высокий общий филрейт. Были ли какие-то провалы в процессе выстраивания всего этого добра?
Rpsl
13.10.2017 14:25Не совсем про backend вопрос, но коллега просил передать:
По нашим наблюдениям, до сих пор, к сожалению, самым эффективным способом "медиации" рекламных систем остаётся построение водопадов - по очереди опрашиваем рекламные системы с разными порогами цен.
Это достаточно стандартный подход. Сложность заключается в определении порядка вызова систем и параметров, с которыми мы их вызываем. На порядок может влиять общее соотношение параметров: СРМ, fill rate, latency. Косвенно может определяться через потери трафика.
Ещё следует обратить внимание на техническое решение, которое управляет показами рекламы:
мы пробовали вызывать всё либо из Google DFP, либо из AdFox и получали очень значимые потери при обращении из Google в Яндекс и наоборот. Поэтому поверх Adfox, DFP есть ещё своя оболочка, которая определяет кого, где и с каким приоритетом вызывать.
Для компенсации провалов, любые изменения мы выкатываем через A/B тесты, сначала на малой части трафика, а потом в экспериментах 50/50 трафика. Это позволяет избегать потерь от неудачных решений.
xDimus
13.10.2017 13:53Помнится хотели подумать об API…
vleonov
13.10.2017 14:27+2Про API думаем и даже делаем. Пока обкатываем на внутренних проектах. А расскажите, какие у вас потребности в открытом API Авито?
DarkPreacher
14.10.2017 10:15+1Я, периодически, ищу определённые вещи. Искать на самом сайте достаточно удобно, однако, если среди найденного не находится того, что устраивало бы, либо если оно разлетается как горячие пирожки — приходится заводить самописный парсер, который мониторит интересующие ключевые слова, по мере поступления новых объявлений. Полагаю, что используя API — делать это было бы гораздо удобнее.
xDimus
14.10.2017 10:52Поиск к сожалению не все находит и уведомления не быстрые. Надеюсь в API будет больше возможностей, а парсер для одного-двух товаров… как из пушки по воробьям…
vslobodyan
13.10.2017 13:55Где у вас живет Python и для чего он используется?
Может, на него есть какие-то особенные надежды в рамках проекта или песочниц для новых юнитов?Cubist
13.10.2017 14:24Питон у нас живет в Data Science, почти все аналитики его использут. Так же он есть в антиспаме, рекомендациях и модерации. Все инструменты Computer Vision или Machine Learning конечно же написаны на Python.
Python такой же инструмент как PHP, или Go, который успешно решает определенный круг задач. Те же DBA используют его вместо bash скриптов.vslobodyan
13.10.2017 15:05Модерация, получается, парсинг на Питоне объявлений пользователей, группировка и вывод модераторам подготовленной инфы в интерфейсе для дальнейших быстрых действий принять/отклонить/указать причину?
Cubist
13.10.2017 15:31Да, верно, модерация получает подсказки от системы на питоне, так повышается скорость обработки.
Для модерации обработка действий и интерфейсов у нас на PHP.
PhoenixMSTU
13.10.2017 13:58+2Вот допустим захотел я что-то купить, при этом живу я в Пушкино а работаю в Москве. Я захожу на Авито, и начинается — включаем фильтр по Пушкино, смотрим предложения, потом по Мытищам — то же самое, по Королёву, Ивантеевке, Щёлково (они все рядом друг с другом), Москве. Я могу конечно выбрать «московская область», но предложения из Троицка меня не интересуют. При этом множественного фильтра по городам нет.
Почему его нет? Это какое-то техническое ограничение (данные так побиты что их тяжело объединить), либо считается что и так нормально?
Возможно же вообще сделать поиск товаров в радиусе N километров. Есть такое в планах?martovskiy
13.10.2017 14:40К сожалению, есть такие проблемы.
Работа по их решению уже ведется, и решить их не так просто как кажется изначально.
Пока этого функционала нет, вы можете пользоваться сортировкой по удалённости в приложении.
Вы увидите те объявления, для которых мы знаем (или думаем что знаем) расположение продавца.PhoenixMSTU
13.10.2017 14:48Спасибо за ответ!
Я всегда был уверен что причина есть! Подозреваю что это из-за того что объявления побиты по городам и могут храниться в разных базах. Так? Было бы интереснее подробнее узнать про то как организовано хранилище объявлений.martovskiy
13.10.2017 15:06Подозреваю что это из-за того что объявления побиты по городам и могут храниться в разных базах
База и поисковый индексы общие, тут нет проблемы.
Чуть ниже в комментариях коротко про базы.
vslobodyan
13.10.2017 13:58Может, были истории успеха, связанные именно с Питоном?
vleonov
13.10.2017 14:36+1Все, что связано с машинным обучением в Avito – это все сплошная история успеха Python: антифрод, распознавание изображений, сервисы рекомендаций.
vslobodyan
13.10.2017 15:02А где именно используется распознавание изображений?
Рекомендации полностью автоматизированны? Каким образом проходит ручной тест их эффективности?
Или эффективность меряется тоже полностью в автоматическом режиме по пользовательскому поведению?vleonov
13.10.2017 15:08Распознавание изображений только начинает внедряться и обкатываться, куда именно пока сказать не могу.
Эффективность рекомендаций измеряется конечно автоматически, в т.ч. через A/B-тесты
zip-imp
13.10.2017 14:22По Вашему мнению когда оправдано использование NoSql, если его использование вообще может быть оправдано.
Rpsl
13.10.2017 14:46NoSql оправданно использовать тогда, когда это решение является лучшим для своих задач.
Факторы по которым оно выбирается “лучшим” могут различаться в каждом конкретном примере. Возможно вам нужна mongodb, чтобы быстро проверить прототип фичи, понять что гипотеза работает и приступать к построению космолета, а может вам нужен быстрый и масштабируемый кэш, а надежность данных является вторичным фактором.
Сегментация у нас, например, на Tarantool построена https://youtu.be/1RS6GvK-JfU?t=50m40s
Различная статистика по просмотрам лежит в шардированном редисе на 512Гб.
evnuh
13.10.2017 14:33- Сколько всего разных БД используете в Авито? Перечислите.
- Максимальное кол-во разных БД в одном проекте?
- Любимая БД у Go разработчиков? Почему?
- Какой стек разработки используете для проектов на Go? Для сборки, тестирования, деплоя?
- Используете per-project dependencies или всё в $GOPATH?
- Какой системой управления зависимостями в Go пользуетесь?
- Какой IDE пользуется большинство, какими плагинами?
vleonov
13.10.2017 14:57- PostgreSQL, Memcached, Redis, Tarantool, MongoDB, SphinxSearch, Vertica.
- Все они используются в основном проекте Avito.
- Тут вопрос не про то, что любят разработчики, а про то, что нужно в конкретной задаче.
- Выше в треде про GO.
- Большинство разработчиков используют продукты Jetbrains.
evnuh
13.10.2017 15:05Про 5 и 6 не нашёл, можете дать ссылку?
marrrvin
13.10.2017 15:495 Каждый проект на go лежит в отдельном git репозитории, GOPATH устанавливается динамически в Makefile с основными командами сборки и т.д. Внутри проекта vendoring, пакетные менеджеры используем, но зависимости также коммитим в git. Из менеджеров пока govendor, экспериментируем с github.com/golang/dep как с будущим стандартным решением.
dmirogin
13.10.2017 14:36Были ли факапы, провалы? Очень интересно как вы с ними справлялись. Спасибо.
Cubist
13.10.2017 15:21Конечно, иногда бывают провалы. Но сильный не тот, кто не упал, а кто после падения сумел подняться.
Поэтому если что-то идет не так, то мы быстро (около 10 секунд) откатываем все сервера на предыдущую “стабильную” версию или готовим хотфиксы, которые оперативно загружаем.
Потом проводим работу над ошибками, чтобы не допускать их в будущем.
r_j
13.10.2017 14:43Как насчет мониторинга все этого?
- Что и как используете для инфраструктурного мониторинга?
- Есть APM (Application Performance Monitoring)? Если да, то что и как используете?
vleonov
13.10.2017 14:56Про нашу систему мониторинга есть подробная статья: https://habrahabr.ru/company/avito/blog/335410/
Если кратко, то collectd+heapster+brubeck+graphite+grafana+moira
marrrvin
13.10.2017 15:53для сбора метрик с Kubernetes используем Prometeus — вся экосистема Kubernetes заточена под него.
dkorablinov
13.10.2017 14:511. Какой протокол(ы) используете для взаимодействия между микросервисами?
2. Как заворачиваете PHPшные микросервисы в контейнеры (имею в виду — где размещаются процессы nginx, FPM)?
3. Используете ли API Gateways? Если да — то какие задачи они у вас решают и какая технология используется?vleonov
13.10.2017 15:01- Обычный JSON поверх HTTP. Что-то типа JSONRpc
- Один контейнер с nginx, второй контейнер с php-fpm, где располагается и код.
- В качестве API Gateway в данный момент используется сам монолит Avito :) Но есть отдельные кейсы, когда перед пачкой однотипных микросервисов стоит прослойка-gateway. Например у нас есть несколько разных рекомендательных сервисов, ответы которых собираются такой вот прослойкой и отдаются в Avito.
marrrvin
13.10.2017 14:551 простой самодельный rpc поверх http с сериализацией в json.
2 если правильно понял вопрос — в одном поде два контейнера — один с nginx и один с php-fpm.
3 да, чаще всего для параллельного сбора данных с разных сервисов, иногда с кешированием, а также для проверки авторизации.
viamad
13.10.2017 15:35Работаете ли вы с BigData?
Используете нейросети, предсказываете что-нибудь?vleonov
13.10.2017 15:47Работаем, у нас более 70Тб в Вертике. Храним и анализируем все, что можем. Тут про это писали: https://habrahabr.ru/company/avito/blog/322510/
Нейросети используются для распознавания изображений. Предсказываем всякое, например вероятность клика пользователем по рекламному объявлению в Авито.Контекст.vleonov
13.10.2017 15:53Коллеги подсказывают, что у меня сильно старые данные. На сегодняшний день в Вертике 142Тб.
ls18
13.10.2017 15:45Какие у вас требования к Junior/Middle Python/SQL разработчикам? Требования в профессиональном плане, образование, возраст, опыт работы. Интересно было бы услышать не только требования самой компании, но и самих ведущих разработчиков.
Cubist
13.10.2017 16:13+3Идеальный кандидат хорошо знает Computer Science, знает алгоритмы и структуры данных, и конечно знает тот инструмент, которым он пользуется. Не важно это Python, PostgreSQL, PHP, GO или что-то ещё.
Высшее образование не объязательно, возраст тоже не имеет значение.
В первую очередь мы смотрим не столько знания языка, сколько умение решать прикладные задачи.
Junior мы отличаем от Middle разработчика лишь тем, что Junior всё знает, но реального опыта у него нет.
Список вакансий вы можете посмотреть тут, у нас всегда описаны требования под каждую. Но в данный момент мы не ищем Junior разработчиков.
Так же вы можете напрямую пообщаться с рекрутерами, которые сидят в канале телеграмм — https://t.me/AvitoJob
Filex
13.10.2017 15:49Как у вас организованы бэкапы? Какими инструментами пользуетесь?
vleonov
13.10.2017 16:16+3Про резервное копирование БД подробно рассказывали на HighLoad++ https://habrahabr.ru/company/oleg-bunin/blog/311472/. Для управления бекапами используем Bacula.
Drim
13.10.2017 15:50Если говорить про основную платформу,
1. Что используете для балансировки нагрузки? nginx?
2. Какой rps примерно держит один сервер с php?
3. Сохранение в базу, кеши где происходит? Сразу при получении запроса? Rabbit?
4. Нет ли проблем с too many connections в mysql?Drim
13.10.2017 15:565. Как происходит процесс деплоя БД и кода. В каком порядке — БД схемы, код. Как это делаете в кластерах?
vleonov
13.10.2017 16:14+3Деплой кода хранимых процедур и выкатка миграций – тема для отдельной статьи, когда-нибудь мы её напишем и опубликуем :)
В двух словах, хранимые процедуры выкатываются в новую схему, создаётся пользователь БД у которого в search_path указана эта новая схема. Новый PHP код соединяется с базой под этим новым пользователем и использует код новых хранимых процедур. Это позволяет в любой момент безболезненно откатиться.
Для наката миграций на схемы данных используются небольшие самописные библиотеки. Но автоматически они накатываются только в микросервисах, в большом Avito – только в test и dev средах. Сначала схемы, потом код, чтобы была возможность откатиться.
vleonov
13.10.2017 16:00- Да, nginx.
- У нас 20000rps к бекенду, 65 железных серверов с php-монолитом, 300rps на каждый. С переходом на PHP7 каждый сервер смог держать в три раза больше, т.е. до 1000rps держать можем. Подробнее про переход на 7.0 писали тут: https://habrahabr.ru/company/avito/blog/338140/.
- В зависимости от задачи. В большинстве случаев сразу, в особо тяжелых – через RabbitMQ, либо через pgq. В кэши пишем сразу, в кэши пишем много.
- У нас нет MySQL. Мы используем PostgreSQL с PgBouncer'ами, которые эту проблему решают.
Nerfair
13.10.2017 16:50+1Стало интересно после 20000rps, сколько у вас пользователей находятся на сайте, одновременно, в пике?
wert_lex
13.10.2017 15:52Как выкладка происходит в плане взаимодействия разработки и тестирования?
Разработчики разработали новую фичу, она прошла некоторый QA, а как дальше это попадает на прод? Есть промежуточная площадка (препрод), где фичу гоняют на живых данных, или она сразу уезжает в прод?Cubist
13.10.2017 16:20+3Разработчик разрабатывает новую фичу, затем передает её в review, где другие разработчики смотрят на написаный код и дают различные советы.
После этого, задача передается в тестирование, где собираются тестовые стенды и проходят ручные и авто тесты.
Если фича касается только внутренних отделов, например, она для поддержки или модерации, то стенд с ней передают нескольким командам, которые дают обратную связь.
Часть фич после тестов добавляется в билд через A/B тест, где её будут видеть лишь определенный процент людей.
Если положительное влияние фичи очевидно, то она просто попадает в билд и выкатывается на прод.
viamad
13.10.2017 16:06Можете рассказать какую архитектуру используете для dev-серверов? Как создаете окружения для разработчиков?
Спасибо!vleonov
13.10.2017 16:27+3Поднимаем docker-образы в minikube-окружении на ноутбуках разработчиков. Чтобы упростить и облегчить окружение многие вещи поднимаются в kubernetes-кластере в датацентре, например снепшоты баз данных, индексы sphinx, staging-версии микросервисов.
Ну и конечно набор самописных скриптов, которые помогают все это развернуть и актуализировать.
0t3dWCE
13.10.2017 16:12+2* Как реализована процедура отката? Это снимок версий определенного набора сервисов, реализующих в своей сумме приложение? или при откате указывается по-сервисно до какой версии их откатить?
* Как вводите в боевую эсплуатацию нововведения? Пускаете 10% траффика на измененную часть либо 10% контейнеров обновляете и следите за метриками?
* Чем собираете метрики? Все средствами k8n или есть свои решения, допилки. (ПС прошел по ссылке, там написано, вопрос снят).
* Сколько виртуальных машин занимает дев версия для разработки или быстрого теста?
Rpsl
13.10.2017 18:51+2про деплой/откат: https://habrahabr.ru/company/avito/blog/339996/#comment_10471460
про схему тестирования фич: https://habrahabr.ru/company/avito/blog/339996/#comment_10471484
Про метрики у нас была отличная статья и скоро будет еще одна.
https://habrahabr.ru/company/avito/blog/335410/
Про кол-во виртуальных машин ответить не получится, т.к. сильно зависит от сервиса и фич которые нужно разрабатывать или тестировать.
xDimus
13.10.2017 16:45+3Поиск не ищет по части слова, к примеру по запросу Intel написанное слитно IntelPentium не находится, а найти хочется :)
martovskiy
13.10.2017 18:15+2Для основного поиска мы не делаем индексацию подстрок.
Включении этой опции увеличивает размер индекса в 10 раз, при этом скорость и качество поиска значительно падает.
Coocos
13.10.2017 16:54+1Какое серверное оборудование используете? Фирма, объем (память, диски), количество ЦП и ядер, высота (в юнитах), как часто обновляете. Понятно что зависит от задачи. Хотелось бы максимум подробностей.
Как организуете хранение больших объемом данных в Postgres? Используете шардирование? Какие инструменты для автоматизации обслуживания Postgres применяете?
Рассматривали стек Hadoop? Если рассматривали, то чем не устроил?vleonov
13.10.2017 17:09+4Какое оборудование и сколько рассказать не можем.
Postgres, Redis, Tarantool, Memcache, Sphinx шардируется во многих случаях. Про обслуживание Postgres рассказывали на разных конференциях, например https://habrahabr.ru/company/oleg-bunin/blog/311472/
Hadoop рассматривали. Не подошел, аргументов много, в частности нам нужен был инструмент анализа, позволяющий объединять большие разнородные данные (JOIN друг с другом дюжины многомиллиардных таблиц).
RussianAirBorn
13.10.2017 16:54+2С сайта: «Вы можете добавить ссылки на видео в объявлениях, размещаемых в категориях «Недвижимость» (за исключением категорий «Сниму» и «Куплю»), «Транспорт» и «Животные». Возможно размещение не более 1 видео в каждом объявлении.»
Почему я не могу добавить в видео в категории «Музыкальные инструменты»? Для многих это актуально.Cubist
13.10.2017 19:00+4Это не техническое решение.
Мы учтем ваши пожелания и передадим ответственному менеджеру.
zip-imp
13.10.2017 17:25+2Избыточность или дублирование в угоду скорости работы бд, такое бывало?
Cubist
13.10.2017 18:03+5Очень часто.
Например чтобы показать preview объявления на странице поиска нам не надо знать об объявлении всё, достаточно картинки, цены, названия, ещё нам надо немного информации о пользователе.
Чтобы каждый раз не вынимать эту информацию из большой таблицы соединённой с другой большой таблицей у нас есть материализованное представление содержащее только необходимую нам информацию. Обращение к такой таблице занимает минимум времени и ресурсов.
Более того, такая таблица легко реплицируется на другой сервер и нагрузка на основную базу ещё более снижается.
fxes
13.10.2017 18:49+21. Что используется в качестве рекомендательного демона для рекомендации товаров?
2. Как доставляются данные до демонов (message broker)?
3. При шардировании сколько объявлений умещается на одну тачку?
4. Как происходит деплой, чем выкатываете в прод?
Cubist
13.10.2017 19:55+1- В качестве рекомендательного демона используется микросервис, написанный на питоне.
- Уточните пожалуйста, что вы имеете в виду? Какого типа данные?
- Про шардирование — всё зависит от решаемых с его помощью задач.
- Если цель — просто хранить на диске, то от размеров диска.
- Если распределение большой читающей нагрузки — то от размера оперативной памяти.
- Существуют и другие ограничения, например пропускная способность сети или CPU.
- Про деплой писали комментарии выше, посмотрите.
catlover
13.10.2017 20:27+1Почему вы блокируйте Tor? Я наверное один из немногих людей на территории России, который не может пользоваться вашим сервисом. Сколько раз давали ссылки на объявления — никак не открыть. Я не думаю, что вы можете удачно утверждать, что можете поддерживать высоко-нагруженный сервис, если вы используйте такие нацистские методы и избирательность в сторону пользователей.
Нельзя было хотя-бы капчу сделать, ну или подтверждение по телефону в самом крайнем случае. Я не знаю, какой процент посетителей вы на этом теряйте, но я принципиально не пользуюсь сервисом с таким наплевательским отношением к потенциальному клиенту, так как даже объявления нельзя прочитать, а публиковать мне по-сути и и никогда не было нужно.Londoner
13.10.2017 22:46Это ещё ладно, у Авиты даже с нероссийских IP-адресов не получается разместить объявление. Бьюсь с ними на эту годами, а воз и ныне там, поддержка вообще делает вид что не понимает, о чём я.
bo0rsh201
14.10.2017 00:08Вопрос про микросервисы. Сколько их примерно сейчас? Каким образом продумываете и согласовываете API? Какой характер связности между ними? Все со всеми или каждый с монолитом? Как вносите изменения в API? Какой порядок миграции на новую версию API в куче мест где уже используется старая версия? Насколько я понял, сервисы разнесены по разным репозиториям, поэтому вариант «разработчик API заодно сам меняет все usages» невозможен. Как этот процесс устроен организационно и технически? Какой по вашим ощущениям оверхед по сравнению с монолитом это даёт?
Rpsl
14.10.2017 12:49Сколько их примерно сейчас?
Несколько десятков
Каким образом продумываете и согласовываете API?
Есть требования и разработчики ориентируются на них, стараясь заранее закладывать тот функционал, который может потребоваться в дальнейшем.
Какой характер связности между ними? Все со всеми или каждый с монолитом?
Сильно зависит от ситуации, но четкого деления нет. Сервис предоставляет api, любой другой сервис может взаимодействовать с ним.
Как вносите изменения в API?
Либо расширение существующих методов, либо создание новых, либо версионирование. В любом случае, всегда поддерживаем обратную совместимость.
Какой порядок миграции на новую версию API в куче мест где уже используется старая версия? Насколько я понял, сервисы разнесены по разным репозиториям, поэтому вариант «разработчик API заодно сам меняет все usages» невозможен.
Разработчики сервиса обычно делают библиотеки-“клиенты” для него. Версии библиотек фиксируются. Таким образом внедрение новых фич не задевает остальных. Сейчас работаем над автогенерацией кода клиентов для сокращения времени на поддержку клиентов на разных языках.
Какой по вашим ощущениям оверхед по сравнению с монолитом это даёт?
В первое время с этим трудно жить, сложнее всего когда нужно найти баг, который появляется неизвестно где. В остальном такая компоновка позволяет сократить общие затраты на разработку и поддержку сервиса, даёт гибкость, которая необходима проектах такого масштаба.
Edison
14.10.2017 15:38А как вы храните секреты (разного рода credentials для сервисов)? Как это интегрируете с CI/CD?
sergeyfast
Привет! Расскажите, пожалуйста, где вы используете еще PHP, помимо сайта, и не планируете ли вы полностью от него отказаться в пользу Go? (например, написав на нем свой PHP :)
Второй вопрос: используете ли вы у себя service discovery (везде или точечно) и есть ли история успеха по этому поводу?
Спасибо!
Cubist
Отвечаю на первый вопрос:
От PHP отказываться пока не хотим, он успешно решает поставленные задачи. Помимо самого Avito мы используем его и в других проектах: Автотека, Актидилер и Актиагент.
Маленькие микросервисы, которые не требуют много бизнес логики и должны работать быстро — пишем на Go.
marrrvin
Мы используем Kubernetes для развертывания новых сервисов, соответственно, пользуемся service discovery, который он предоставляет.
vgoloviznin
Кубернетс менеджите сами или используете какие-то готовые решения?