AMA. Avito. Backend

    Привет! Как и обещали, сегодня мы готовы отвечать на вопросы про бэкенд в Avito, разработку серверной части в целом и про высокие нагрузки в частности. Как работается с сайтом, на который ежемесячно заходит почти четверть населения России? Спросите у нас! Отвечать будем с 12 до 19 часов по московскому времени. Под катом я представляю шесть моих коллег, которые сегодня будут с вами на связи и напоминаю о возможных темах диалога.


    AMA!
    UPD, 19:03 мск: Спасибо всем за вопросы!
    Официально мы завершаем АМА и прощаемся, но по возможности будем отвечать на комментарии.



    image Виталий Леонов, vleonov
    Руководитель разработки серверной части.
    В Авито 5 лет, начинал бекенд-разработчиком, теперь отвечает за всю серверную разработку.


    image Виктор Диктор, Rpsl
    Техлид в юните монетизации. Более 10 лет опыта в разработке сайтов. В Авито отвечает за кроссплатформенную команду разработки в одном из юнитов монетизации.


    imageНиколай Балакирев, madfaill
    Ведущий разработчик серверной части, техлид юнита Avito.Pro. Отвечает за сервисы Avito для профессионалов: ActiAgent, ActiDealer, Avito PRO. Ему можно адресовать также вопросы по сервису Autoteka.


    imageИгорь Сомов, Cubist
    Ведущий разработчик серверной части. В Avito 2 года. Работает в юните модерации, занимается несколькими внутренними проектами.


    image Андрей Смирнов, martovskiy
    Ведущий разработчик серверной части. До Avito работал в Playfon и Sotmarket — везде были высокие нагрузки и большие требования к надежности систем. Занимался статистикой, поиском и деплоем. В Авито работает над поисковыми системами, чтобы они работали быстро, точно и безотказно.


    image Сергей Орлов, 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 рассказывает наш самый первый пост на Хабре. А вот еще несколько ссылок на публикации, которые вы могли пропустить:



    Ждём ваших вопросов, историй и уточнений. Если хотите получить гарантированный ответ — пишите запрос в комментарии первого уровня. Поехали!

    Avito 319,91
    Avito – сайт объявлений №1 в России
    Поделиться публикацией
    Похожие публикации
    Комментарии 122
    • +10
      Привет! Расскажите, пожалуйста, где вы используете еще PHP, помимо сайта, и не планируете ли вы полностью от него отказаться в пользу Go? (например, написав на нем свой PHP :)
      Второй вопрос: используете ли вы у себя service discovery (везде или точечно) и есть ли история успеха по этому поводу?
      Спасибо!
      • +7

        Отвечаю на первый вопрос:
        От PHP отказываться пока не хотим, он успешно решает поставленные задачи. Помимо самого Avito мы используем его и в других проектах: Автотека, Актидилер и Актиагент.


        Маленькие микросервисы, которые не требуют много бизнес логики и должны работать быстро — пишем на Go.

        • +5
          Мы используем Kubernetes для развертывания новых сервисов, соответственно, пользуемся service discovery, который он предоставляет.
          • 0

            Кубернетс менеджите сами или используете какие-то готовые решения?

      • +6
        Как боретесь с кликфродом в Avito Контекст?
        Какие данные анализируете?
        На каких данных обучали первоначально?
        • +4

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


          Мы стараемся собирать всю возможную информацию которая нам доступна и передаем нашим специалистам, которые оптимизируют и настраивают различные веса для них. Но если поверхностно, то статистика кликов, история пользователя, параметры объявления.

          • +4
            А можете порекомендовать какие-то варианты решения задачи?
            • +5

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


              Почитайте про fingerprint https://habrahabr.ru/company/oleg-bunin/blog/321294/

              • +3
                C fingerprint знаком, спасибо, мой вопрос больше о данных.

                Как бороться с кликфродом на начальном этапе, пока нет собственных данных о кликфроде?

                Например:
                Есть сайт-маркетплейс с каталогом товаров от разных поставщиков + исторические данные о переходах/конверсиях (без разметки о кликфроде). Решили продавать рекламу с оплатой за клики (переходы на карточки товаров).

                Варианты решения на старте:
                • Только вручную
                • Обучить модель на собственных исторических данных о переходах и выявлять аномалии?
                • Платные сторонние решения? Какие?

                • +4

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

                  • +2
                    Можете что-то порекомендовать почитать по простым эвристикам и данным?
        • +5
          Расскажите какие трудности были с реализацией Autoteka, там же много сторонних сервисов?
          • +5
            Сервисов много, основные трудности — согласования.
            Все интересное что можно было рассказать, есть в докладе: youtu.be/OGf6mawQwaw

            Если появятся более детальные вопросы — готов на них ответить.
            • +7
              Коллега напоминает, что помимо согласований есть еще нормализация, валидация и очистка данных. Универсального подхода тут нет, в конкретных случаях приходится подходить индивидуально. Общее правило в таких условиях, как подсказывает капитан очевидность, — система мониторинга и алертинга. К счастью, для этого у нас есть все инструменты: habrahabr.ru/company/avito/blog/335410.
              • +4
                Большое спасибо за ответ, я так понимаю взаимодействие с ГИБДД, дилерами и прочими достаточно трудоемкая задача, будете ли вы расширять ассортимент информации или пока остановитесь на отработке текущего? (Сам пользуюсь).
                Доклад посмотрел, весьма интересно, но по схеме больше похоже просто на сервисную архитектуру. Расскажите пожалуйста про service discovery и масштабирование всего этого дела.
                • +5
                  Список источников непрерывно пополняется, покрытие постоянно увеличивается. Большая работа предстоит по улучшению UX и повышению скорости получения отчета, но это параллельные задачи, одна не отменяет другой.
                  Service discovery и инфраструктура у нас общая с Авито, отличие — больше гибкости в выборе стека технологий. Архитектура действительно сервисная, масштабируется и живет все в кубернетисе.
                  В плане взаимодействия с источниками все непросто, к поставщикам уникальных данных приходится подключаться на их условиях без альтернатив — шифрование проприетарным софтом на сертифицированном железе. Под такие источники заводим отдельные сервисы, которые работает только с ними, а внутри к ним уже ходим как к простым API.
            • +6
              Рассматривали какие-то аналоги Go? Что было до него? И почему в итоге остановились на нём?
              • +9
                Для разработки backend мы используем 4 языка: php7, python3, go, java. Каждый язык нашел свою область применения. На php пишем проекты с большим количеством бизнес-логики. go используется для высоконагруженных инфраструктурных сервисов. Часто выбор языка определяется командой, в которой он используется — если вся команда пишет на питоне, то при наличии нескольких вариантов новый сервис тоже будет на нем. Также огромную роль играет наличие библиотек — например, есть сервис использует ML, то скорее всего это будет python.
              • +6
                Учитывая объемы хранимой информации, интересно узнать какие технологии используете для поиска и фильтрации. Как эти технологии используете, как добиваетесь быстрой выдачи результата при постоянно растущих объемах информации.
                • +7

                  Для поиска мы используем поисковый движок sphinxsearch. Данные храним в realtime индексах — это позволяет обновлять данные на выдаче очень быстро.
                  Чтобы быстро доставлять новые данные в индекс, мы написали GO демон который готовит и рассылает запросы с обновлениями на все поисковые сервера.
                  Сейчас у нас 38.5млн активных объявлений. В пик мы получаем около 16К запросов в секунду. 95 процентиль времени ответа поиска примерно 12мс.
                  Realtime индексы со временем деградируют в производительности, поэтому ежедневно делаем полную реиндексацию и еще один раз в день производим оптимизацию индексов.

                  • +3
                    Спасибо за ответ! Если я правильно понимаю, то поисковые сервера в этом случае представляют из себя реплики на которые loadbalancer кидает запросы, что позволяет проводить реиндексацию без потери работоспособности, поправьте если ошибаюсь :)
                    Если не секрет, сколько времени занимает реиндексация одного сервера в вашей ситуации?
                    • +4

                      У нас нет понятия реиндексация одного сервера, мы реиндексируем кластер серверов.
                      Индексация происходит на отдельном сервере и уже с него доставка индексов на все сервера кластера через uftp.
                      Весь этот процесс занимает 500 секунд.

                    • +2
                      Вы используете postgres, там есть FTS с аналогичными возможностями, почему все таки sphinx?
                      • +1

                        FTS есть, но скорость работы и гибкость иная.
                        Если нагрузка небольшая и нужен просто поиск, то конечно стоит использовать FTS в postgres.

                        • +1
                          Ну скорость — понятно. А что с гибкостью? Легче настраивается ранжирование или что-то другое?
                          • 0

                            Да. Легче настраивается сложные случаи ранжирования.

                  • +4
                    Расскажите о системе деплоя софта и конфигураций: путь от системы контроля версий до состояния, когда код разложен на все машины
                    • +6
                      Тут есть два варианта — унаследованный путь развертывания монолита и путь развертывания сервисов.
                      Монолит развертывается набором python-скриптов на основе библиотеки fabric.
                      Сервисы развертываются через CI/CD сервер в Kubernetes кластер при помощи специального пакетного менеджера helm.
                      • 0
                        Статья про версионирование и деплой кода PostgreSQL в условиях высоких нагрузок 24*7 habrahabr.ru/company/avito/blog/342946
                      • +4
                        Расскажите(дайте ссылку на статью если есть) про опыт использования языка Go в вашем проекте. Спасибо.
                      • +4
                        Добрый день, хотел бы очень хорошо освоить базы данных (оптимизация SQL запросов). Например если взять php, то ты всегда можешь посмотреть как устроена библиотека или фреймворк и стать мега-профессионалом, потому что будешь знать в точности как работает каждая строчка библиотеки, весь стек вызовов конкретной, нужной тебе функции, все детали алгоритмов, используемых в этой функции. Где знания такого же уровня можно получить по оптимизации SQL запросов? Спасибо.
                        • +6

                          В первую очередь стоит изучить документацию https://www.postgresql.org/docs/, она написана очень хорошо и подробно. Много полезной информации обсуждается в рассылках: https://www.postgresql.org/list/. Также советуем посмотреть обучающие видео или пройти курсы от Postgres Pro: https://postgrespro.ru/education/courses

                          • +3
                            Спасибо, как раз скоро займусь Postgres, учебные курсы очень кстати.
                        • +4

                          Конечно, если вам требуется понимание


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

                          То можете посмотреть исходники на C — https://github.com/postgres/postgres


                          Если вы используете не PostgreSQL, то просто поищите Ваше название github :)

                        • +4
                          >Строит внутренний PAAS
                          Очень интересно. На kubernetes? Для каких нужд (devel/prod)? Кто клиенты и как они заказывают себе ресурсы? Есть ли какие-то ограничения по ресурсам, автоматически ли апрувите или нет?
                          • +5
                            Да, Kubernetes и Docker.
                            Как для dev, так и для prod.
                            В случае dev это автотесты, dev-окружения для разработки, staging, внутренние ресурсы.
                            В случае prod — сервисы, обрабатывающие запросы пользователей и различные демоны для обработки данных.

                            Клиенты — другие юниты компании. Каждый юнит отвечает за заказ hardware для своих задач, естественно, мы имеем некоторый запас на всякий случай.
                          • +6
                            Что из постгресных фич (или обще-SQL, но не очень типичных) используете? И какие надстройки/расширения к стандартному PostgreSQL, если есть?

                            Храните ли в базах JSON, и если да — то как работаете (насколько сложные запросы, используете ли индексы по JSON полям)?

                            Насколько сильно логика бэкенда лежит на базе? Порядок количества баз/таблиц/хранимок?
                            • +5

                              Используем «ванильный» 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 на базу, а где-то их и нет совсем.

                            • +3
                              Какие трудности были с настройкой медиациеи рекламных сетей? На Авито стоит код не одной крутилки, а они, как известно, не шибко дружат между собой, но у вас всё, вроде бы, работает довольно шустро и, наверное, имеет довольно высокий общий филрейт. Были ли какие-то провалы в процессе выстраивания всего этого добра?
                              • +4

                                Не совсем про backend вопрос, но коллега просил передать:


                                По нашим наблюдениям, до сих пор, к сожалению, самым эффективным способом "медиации" рекламных систем остаётся построение водопадов - по очереди опрашиваем рекламные системы с разными порогами цен. 

                                Это достаточно стандартный подход. Сложность заключается в определении порядка вызова систем и параметров, с которыми мы их вызываем. На порядок может влиять общее соотношение параметров: СРМ, fill rate, latency. Косвенно может определяться через потери трафика.

                                Ещё следует обратить внимание на техническое решение, которое управляет показами рекламы:
                                мы пробовали вызывать всё либо из Google DFP, либо из AdFox и получали очень значимые потери при обращении из Google в Яндекс и наоборот. Поэтому поверх Adfox, DFP есть ещё своя оболочка, которая определяет кого, где и с каким приоритетом вызывать.

                                Для компенсации провалов, любые изменения мы выкатываем через A/B тесты, сначала на малой части трафика, а потом в экспериментах 50/50 трафика. Это позволяет избегать потерь от неудачных решений.
                              • +5
                                Помнится хотели подумать об API…
                                • +7

                                  Про API думаем и даже делаем. Пока обкатываем на внутренних проектах. А расскажите, какие у вас потребности в открытом API Авито?

                                  • +1
                                    Я, периодически, ищу определённые вещи. Искать на самом сайте достаточно удобно, однако, если среди найденного не находится того, что устраивало бы, либо если оно разлетается как горячие пирожки — приходится заводить самописный парсер, который мониторит интересующие ключевые слова, по мере поступления новых объявлений. Полагаю, что используя API — делать это было бы гораздо удобнее.
                                    • 0
                                      Поиск к сожалению не все находит и уведомления не быстрые. Надеюсь в API будет больше возможностей, а парсер для одного-двух товаров… как из пушки по воробьям…
                                • +4
                                  Где у вас живет Python и для чего он используется?
                                  Может, на него есть какие-то особенные надежды в рамках проекта или песочниц для новых юнитов?
                                  • +6

                                    Питон у нас живет в Data Science, почти все аналитики его использут. Так же он есть в антиспаме, рекомендациях и модерации. Все инструменты Computer Vision или Machine Learning конечно же написаны на Python.
                                    Python такой же инструмент как PHP, или Go, который успешно решает определенный круг задач. Те же DBA используют его вместо bash скриптов.

                                    • +4
                                      Модерация, получается, парсинг на Питоне объявлений пользователей, группировка и вывод модераторам подготовленной инфы в интерфейсе для дальнейших быстрых действий принять/отклонить/указать причину?
                                      • +4

                                        Да, верно, модерация получает подсказки от системы на питоне, так повышается скорость обработки.


                                        Для модерации обработка действий и интерфейсов у нас на PHP.

                                  • +8
                                    Вот допустим захотел я что-то купить, при этом живу я в Пушкино а работаю в Москве. Я захожу на Авито, и начинается — включаем фильтр по Пушкино, смотрим предложения, потом по Мытищам — то же самое, по Королёву, Ивантеевке, Щёлково (они все рядом друг с другом), Москве. Я могу конечно выбрать «московская область», но предложения из Троицка меня не интересуют. При этом множественного фильтра по городам нет.
                                    Почему его нет? Это какое-то техническое ограничение (данные так побиты что их тяжело объединить), либо считается что и так нормально?
                                    Возможно же вообще сделать поиск товаров в радиусе N километров. Есть такое в планах?
                                    • +4

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

                                      • +3
                                        Спасибо за ответ!
                                        Я всегда был уверен что причина есть! Подозреваю что это из-за того что объявления побиты по городам и могут храниться в разных базах. Так? Было бы интереснее подробнее узнать про то как организовано хранилище объявлений.
                                        • +4
                                          Подозреваю что это из-за того что объявления побиты по городам и могут храниться в разных базах

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

                                    • +3
                                      Может, были истории успеха, связанные именно с Питоном?
                                      • +4

                                        Все, что связано с машинным обучением в Avito – это все сплошная история успеха Python: антифрод, распознавание изображений, сервисы рекомендаций.

                                        • +3
                                          А где именно используется распознавание изображений?

                                          Рекомендации полностью автоматизированны? Каким образом проходит ручной тест их эффективности?
                                          Или эффективность меряется тоже полностью в автоматическом режиме по пользовательскому поведению?
                                          • +4

                                            Распознавание изображений только начинает внедряться и обкатываться, куда именно пока сказать не могу.
                                            Эффективность рекомендаций измеряется конечно автоматически, в т.ч. через A/B-тесты

                                      • +3

                                        По Вашему мнению когда оправдано использование NoSql, если его использование вообще может быть оправдано.

                                        • +3

                                          NoSql оправданно использовать тогда, когда это решение является лучшим для своих задач.


                                          Факторы по которым оно выбирается “лучшим” могут различаться в каждом конкретном примере. Возможно вам нужна mongodb, чтобы быстро проверить прототип фичи, понять что гипотеза работает и приступать к построению космолета, а может вам нужен быстрый и масштабируемый кэш, а надежность данных является вторичным фактором.


                                          Сегментация у нас, например, на Tarantool построена https://youtu.be/1RS6GvK-JfU?t=50m40s


                                          Различная статистика по просмотрам лежит в шардированном редисе на 512Гб.

                                        • +3
                                          1. Сколько всего разных БД используете в Авито? Перечислите.
                                          2. Максимальное кол-во разных БД в одном проекте?
                                          3. Любимая БД у Go разработчиков? Почему?
                                          4. Какой стек разработки используете для проектов на Go? Для сборки, тестирования, деплоя?
                                          5. Используете per-project dependencies или всё в $GOPATH?
                                          6. Какой системой управления зависимостями в Go пользуетесь?
                                          7. Какой IDE пользуется большинство, какими плагинами?

                                          • +5
                                            1. PostgreSQL, Memcached, Redis, Tarantool, MongoDB, SphinxSearch, Vertica.
                                            2. Все они используются в основном проекте Avito.
                                            3. Тут вопрос не про то, что любят разработчики, а про то, что нужно в конкретной задаче.
                                            4. Выше в треде про GO.
                                            5. Выше.
                                            6. Выше.
                                            7. Большинство разработчиков используют продукты Jetbrains.
                                            • +1
                                              Про 5 и 6 не нашёл, можете дать ссылку?
                                              • +3
                                                5 Каждый проект на go лежит в отдельном git репозитории, GOPATH устанавливается динамически в Makefile с основными командами сборки и т.д. Внутри проекта vendoring, пакетные менеджеры используем, но зависимости также коммитим в git. Из менеджеров пока govendor, экспериментируем с github.com/golang/dep как с будущим стандартным решением.
                                          • +2
                                            Были ли факапы, провалы? Очень интересно как вы с ними справлялись. Спасибо.
                                            • +3

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


                                              Поэтому если что-то идет не так, то мы быстро (около 10 секунд) откатываем все сервера на предыдущую “стабильную” версию или готовим хотфиксы, которые оперативно загружаем.


                                              Потом проводим работу над ошибками, чтобы не допускать их в будущем.

                                            • +2
                                              Как насчет мониторинга все этого?
                                              1. Что и как используете для инфраструктурного мониторинга?
                                              2. Есть APM (Application Performance Monitoring)? Если да, то что и как используете?
                                            • +2
                                              1. Какой протокол(ы) используете для взаимодействия между микросервисами?
                                              2. Как заворачиваете PHPшные микросервисы в контейнеры (имею в виду — где размещаются процессы nginx, FPM)?
                                              3. Используете ли API Gateways? Если да — то какие задачи они у вас решают и какая технология используется?
                                              • +3
                                                1. Обычный JSON поверх HTTP. Что-то типа JSONRpc
                                                2. Один контейнер с nginx, второй контейнер с php-fpm, где располагается и код.
                                                3. В качестве API Gateway в данный момент используется сам монолит Avito :) Но есть отдельные кейсы, когда перед пачкой однотипных микросервисов стоит прослойка-gateway. Например у нас есть несколько разных рекомендательных сервисов, ответы которых собираются такой вот прослойкой и отдаются в Avito.
                                                • +1
                                                  промахнулся мимо треда, ответ чуть ниже
                                                • +3
                                                  1 простой самодельный rpc поверх http с сериализацией в json.
                                                  2 если правильно понял вопрос — в одном поде два контейнера — один с nginx и один с php-fpm.
                                                  3 да, чаще всего для параллельного сбора данных с разных сервисов, иногда с кешированием, а также для проверки авторизации.
                                                  • +2
                                                    Работаете ли вы с BigData?
                                                    Используете нейросети, предсказываете что-нибудь?
                                                    • +3

                                                      Работаем, у нас более 70Тб в Вертике. Храним и анализируем все, что можем. Тут про это писали: https://habrahabr.ru/company/avito/blog/322510/
                                                      Нейросети используются для распознавания изображений. Предсказываем всякое, например вероятность клика пользователем по рекламному объявлению в Авито.Контекст.

                                                      • +5

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

                                                        • +2
                                                          Спасибо большое за ответ!
                                                          А какой тип нейросетей используете, CNN или что-то более накрученное?
                                                          • +3

                                                            Мы используем глубокие сверточные нейросети аля-imagenet для классификации изображений и рекуррентные нейросети для анализа текста.

                                                    • +2
                                                      Какие у вас требования к Junior/Middle Python/SQL разработчикам? Требования в профессиональном плане, образование, возраст, опыт работы. Интересно было бы услышать не только требования самой компании, но и самих ведущих разработчиков.
                                                      • +3

                                                        Идеальный кандидат хорошо знает Computer Science, знает алгоритмы и структуры данных, и конечно знает тот инструмент, которым он пользуется. Не важно это Python, PostgreSQL, PHP, GO или что-то ещё.


                                                        Высшее образование не объязательно, возраст тоже не имеет значение.


                                                        В первую очередь мы смотрим не столько знания языка, сколько умение решать прикладные задачи.


                                                        Junior мы отличаем от Middle разработчика лишь тем, что Junior всё знает, но реального опыта у него нет.


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


                                                        Так же вы можете напрямую пообщаться с рекрутерами, которые сидят в канале телеграмм — https://t.me/AvitoJob

                                                      • +2
                                                        Как у вас организованы бэкапы? Какими инструментами пользуетесь?
                                                      • +2
                                                        Если говорить про основную платформу,
                                                        1. Что используете для балансировки нагрузки? nginx?
                                                        2. Какой rps примерно держит один сервер с php?
                                                        3. Сохранение в базу, кеши где происходит? Сразу при получении запроса? Rabbit?
                                                        4. Нет ли проблем с too many connections в mysql?
                                                        • +2
                                                          5. Как происходит процесс деплоя БД и кода. В каком порядке — БД схемы, код. Как это делаете в кластерах?
                                                          • +4

                                                            Деплой кода хранимых процедур и выкатка миграций – тема для отдельной статьи, когда-нибудь мы её напишем и опубликуем :)
                                                            В двух словах, хранимые процедуры выкатываются в новую схему, создаётся пользователь БД у которого в search_path указана эта новая схема. Новый PHP код соединяется с базой под этим новым пользователем и использует код новых хранимых процедур. Это позволяет в любой момент безболезненно откатиться.
                                                            Для наката миграций на схемы данных используются небольшие самописные библиотеки. Но автоматически они накатываются только в микросервисах, в большом Avito – только в test и dev средах. Сначала схемы, потом код, чтобы была возможность откатиться.

                                                            • +1
                                                              Спасибо за ответ
                                                              Вы выводите БД из балансировки в момент выката новой схемы?
                                                          • +4
                                                            1. Да, nginx.
                                                            2. У нас 20000rps к бекенду, 65 железных серверов с php-монолитом, 300rps на каждый. С переходом на PHP7 каждый сервер смог держать в три раза больше, т.е. до 1000rps держать можем. Подробнее про переход на 7.0 писали тут: https://habrahabr.ru/company/avito/blog/338140/.
                                                            3. В зависимости от задачи. В большинстве случаев сразу, в особо тяжелых – через RabbitMQ, либо через pgq. В кэши пишем сразу, в кэши пишем много.
                                                            4. У нас нет MySQL. Мы используем PostgreSQL с PgBouncer'ами, которые эту проблему решают.
                                                            • +1
                                                              Стало интересно после 20000rps, сколько у вас пользователей находятся на сайте, одновременно, в пике?
                                                          • +2

                                                            Как выкладка происходит в плане взаимодействия разработки и тестирования?
                                                            Разработчики разработали новую фичу, она прошла некоторый QA, а как дальше это попадает на прод? Есть промежуточная площадка (препрод), где фичу гоняют на живых данных, или она сразу уезжает в прод?

                                                            • +3

                                                              Разработчик разрабатывает новую фичу, затем передает её в review, где другие разработчики смотрят на написаный код и дают различные советы.


                                                              После этого, задача передается в тестирование, где собираются тестовые стенды и проходят ручные и авто тесты.


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


                                                              Часть фич после тестов добавляется в билд через A/B тест, где её будут видеть лишь определенный процент людей.


                                                              Если положительное влияние фичи очевидно, то она просто попадает в билд и выкатывается на прод.

                                                            • +1
                                                              Можете рассказать какую архитектуру используете для dev-серверов? Как создаете окружения для разработчиков?
                                                              Спасибо!
                                                              • +3

                                                                Поднимаем docker-образы в minikube-окружении на ноутбуках разработчиков. Чтобы упростить и облегчить окружение многие вещи поднимаются в kubernetes-кластере в датацентре, например снепшоты баз данных, индексы sphinx, staging-версии микросервисов.
                                                                Ну и конечно набор самописных скриптов, которые помогают все это развернуть и актуализировать.

                                                              • +2
                                                                * Как реализована процедура отката? Это снимок версий определенного набора сервисов, реализующих в своей сумме приложение? или при откате указывается по-сервисно до какой версии их откатить?
                                                                * Как вводите в боевую эсплуатацию нововведения? Пускаете 10% траффика на измененную часть либо 10% контейнеров обновляете и следите за метриками?
                                                                * Чем собираете метрики? Все средствами k8n или есть свои решения, допилки. (ПС прошел по ссылке, там написано, вопрос снят).
                                                                * Сколько виртуальных машин занимает дев версия для разработки или быстрого теста?

                                                              • +2
                                                                Какая ОС используется на серверах?
                                                              • +3
                                                                Поиск не ищет по части слова, к примеру по запросу Intel написанное слитно IntelPentium не находится, а найти хочется :)
                                                                • +2

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

                                                                • +1
                                                                  Какое серверное оборудование используете? Фирма, объем (память, диски), количество ЦП и ядер, высота (в юнитах), как часто обновляете. Понятно что зависит от задачи. Хотелось бы максимум подробностей.

                                                                  Как организуете хранение больших объемом данных в Postgres? Используете шардирование? Какие инструменты для автоматизации обслуживания Postgres применяете?

                                                                  Рассматривали стек Hadoop? Если рассматривали, то чем не устроил?
                                                                  • +4

                                                                    Какое оборудование и сколько рассказать не можем.


                                                                    Postgres, Redis, Tarantool, Memcache, Sphinx шардируется во многих случаях. Про обслуживание Postgres рассказывали на разных конференциях, например https://habrahabr.ru/company/oleg-bunin/blog/311472/


                                                                    Hadoop рассматривали. Не подошел, аргументов много, в частности нам нужен был инструмент анализа, позволяющий объединять большие разнородные данные (JOIN друг с другом дюжины многомиллиардных таблиц).

                                                                    • +1
                                                                      Рассматриваете использование Clickhouse?
                                                                      • +4
                                                                        Совсем скоро vkolobaev напишет продолжение своей статьи про мониторинг. Там будет про clickhouse.
                                                                  • +2
                                                                    С сайта: «Вы можете добавить ссылки на видео в объявлениях, размещаемых в категориях «Недвижимость» (за исключением категорий «Сниму» и «Куплю»), «Транспорт» и «Животные». Возможно размещение не более 1 видео в каждом объявлении.»
                                                                    Почему я не могу добавить в видео в категории «Музыкальные инструменты»? Для многих это актуально.
                                                                    • +5

                                                                      Это не техническое решение.
                                                                      Мы учтем ваши пожелания и передадим ответственному менеджеру.

                                                                    • +2

                                                                      Избыточность или дублирование в угоду скорости работы бд, такое бывало?

                                                                      • +5

                                                                        Очень часто.


                                                                        Например чтобы показать preview объявления на странице поиска нам не надо знать об объявлении всё, достаточно картинки, цены, названия, ещё нам надо немного информации о пользователе.


                                                                        Чтобы каждый раз не вынимать эту информацию из большой таблицы соединённой с другой большой таблицей у нас есть материализованное представление содержащее только необходимую нам информацию. Обращение к такой таблице занимает минимум времени и ресурсов.


                                                                        Более того, такая таблица легко реплицируется на другой сервер и нагрузка на основную базу ещё более снижается.

                                                                      • +4
                                                                        clickhouse не пробовали использовать для хранения статистики?
                                                                        • +7
                                                                          Совсем скоро vkolobaev напишет продолжение своей статьи про мониторинг. Там будет про clickhouse.
                                                                        • +3
                                                                          1. Что используется в качестве рекомендательного демона для рекомендации товаров?
                                                                          2. Как доставляются данные до демонов (message broker)?
                                                                          3. При шардировании сколько объявлений умещается на одну тачку?
                                                                          4. Как происходит деплой, чем выкатываете в прод?
                                                                          • 0
                                                                            2. Если я правильно понял вопрос, то ответ — RabbitMQ.
                                                                          • +2
                                                                            1. В качестве рекомендательного демона используется микросервис, написанный на питоне.
                                                                            2. Уточните пожалуйста, что вы имеете в виду? Какого типа данные?
                                                                            3. Про шардирование — всё зависит от решаемых с его помощью задач.
                                                                              • Если цель — просто хранить на диске, то от размеров диска.
                                                                              • Если распределение большой читающей нагрузки — то от размера оперативной памяти.
                                                                              • Существуют и другие ограничения, например пропускная способность сети или CPU.
                                                                            4. Про деплой писали комментарии выше, посмотрите.
                                                                            • +1
                                                                              Почему вы блокируйте Tor? Я наверное один из немногих людей на территории России, который не может пользоваться вашим сервисом. Сколько раз давали ссылки на объявления — никак не открыть. Я не думаю, что вы можете удачно утверждать, что можете поддерживать высоко-нагруженный сервис, если вы используйте такие нацистские методы и избирательность в сторону пользователей.
                                                                              Нельзя было хотя-бы капчу сделать, ну или подтверждение по телефону в самом крайнем случае. Я не знаю, какой процент посетителей вы на этом теряйте, но я принципиально не пользуюсь сервисом с таким наплевательским отношением к потенциальному клиенту, так как даже объявления нельзя прочитать, а публиковать мне по-сути и и никогда не было нужно.
                                                                              • 0
                                                                                Это ещё ладно, у Авиты даже с нероссийских IP-адресов не получается разместить объявление. Бьюсь с ними на эту годами, а воз и ныне там, поддержка вообще делает вид что не понимает, о чём я.
                                                                              • +1
                                                                                Привет. А что у мессенджера за беда, что он частенько ломается?
                                                                                • +1
                                                                                  Вопрос про микросервисы. Сколько их примерно сейчас? Каким образом продумываете и согласовываете API? Какой характер связности между ними? Все со всеми или каждый с монолитом? Как вносите изменения в API? Какой порядок миграции на новую версию API в куче мест где уже используется старая версия? Насколько я понял, сервисы разнесены по разным репозиториям, поэтому вариант «разработчик API заодно сам меняет все usages» невозможен. Как этот процесс устроен организационно и технически? Какой по вашим ощущениям оверхед по сравнению с монолитом это даёт?
                                                                                  • 0
                                                                                    Сколько их примерно сейчас?

                                                                                    Несколько десятков


                                                                                    Каким образом продумываете и согласовываете API?

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


                                                                                    Какой характер связности между ними? Все со всеми или каждый с монолитом?

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


                                                                                    Как вносите изменения в API?

                                                                                    Либо расширение существующих методов, либо создание новых, либо версионирование. В любом случае, всегда поддерживаем обратную совместимость.


                                                                                    Какой порядок миграции на новую версию API в куче мест где уже используется старая версия? Насколько я понял, сервисы разнесены по разным репозиториям, поэтому вариант «разработчик API заодно сам меняет все usages» невозможен.

                                                                                    Разработчики сервиса обычно делают библиотеки-“клиенты” для него. Версии библиотек фиксируются. Таким образом внедрение новых фич не задевает остальных. Сейчас работаем над автогенерацией кода клиентов для сокращения времени на поддержку клиентов на разных языках.


                                                                                    Какой по вашим ощущениям оверхед по сравнению с монолитом это даёт?

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

                                                                                • 0

                                                                                  А как вы храните секреты (разного рода credentials для сервисов)? Как это интегрируете с CI/CD?

                                                                                • 0
                                                                                  Ребята, привет!
                                                                                  Вы используете интроспекцию-рефлексию при разработке кода?
                                                                                  • +1
                                                                                    Существуют ли у вас какие-то способы защиты от парсинга страниц. Например, агенства недвижимости любят мониторить объявления друг друга. Как вы это пресекаете? Да и в целом про защиту от парсинга расскажите, пожалуйста.

                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                    Самое читаемое