- Основные службы и сервисы на вооружении команды эксплуатации Badoo.
- Почему какие-то инструменты приживаются, а какие-то нет?
- Почему так сложно выбирать инструментарий в существующем проекте?
- Consul для service discovery.
- Docker: мы продолжаем выбирать шедулер/оркестратор, в чем сложность для нас?
- Logs collection: все стандартно – ELK.
- Containers logs collection: так ли тут все просто? Расскажу о нашей истории.
- Backups: нужны ли бэкапы в современном отказоустойчивом и быстрорастущем проекте? Применяем давно известные инструменты в современной архитектуре.
- Для чего нужно регулярно проверять бэкапы.
- Работая в команде – работай в команде, не думай только о себе.

В данном докладе я расскажу об истории появления проекта, что из себя представляет njs, какие задачи можно решать при помощи njs в nginx, а также о том, как все это работает.

Мы решали задачу, как улучшить качество обслуживания пользователей при просмотре видео. Для того чтобы что-то улучшить, надо сначала найти метрику качества. Долгое время мы использовали для этого события, которые происходят на клиентской стороне, интегральные метрики нашего CDN. В какой-то момент этой информации оказалось недостаточно и потребовалось собирать события с каждого узла CDN и уметь связывать эти события с тем, что происходит на стороне клиента, чтобы получить полную историю обслуживания конкретного абонента. Во время просмотра на CDN прилетает очень большое количество запросов, так как плеер каждого пользователя в среднем раз в 2-4 секунды обращается за новым фрагментом видео.

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

В этом докладе я расскажу про сервис звонков на ОК с возможностью звонить между WEB, iOS, Droid.

В докладе будут освещены:
- протокол сигналинга (звонки на множество устройств и прочие нюансы);
- предпрогрев соединения;
- stun/turn, p2p vs relay;
- тюнинг webRTC;
- проблемы отказоустойчивости: потеря ДЦ, обновление сервиса;
- миграция с rtmfp на webRTC.

А также AI внутри платформы звонков собирает такую статистику по подсетям операторов, как пропускная способность интернета, потеря пакетов, искажения звукового сигнала, возможность установки p2p-соединений, и автоматически настраивает параметры сетевого протокола как на этапе дозвона, так и во время звонка.
https://www.ferra.ru/ru/techlife/news/2018/03/07/ok-video-ai/

Полтора года назад в одном из проектов Badoo впервые возникла необходимость не просто принимать деньги от пользователей, но и делать им выплаты. Наша собственная система биллинга была прекрасно настроена на то, чтобы формировать счета и принимать платежи, но в текущей конфигурации выплачивать деньги не могла. Тогда нам пришлось интегрировать три крупные платежные системы самостоятельно. И с каждой (!) возник ворох проблем, связанных с плохой документацией, возвратами денег и многим другим, включая наши собственные ошибки.

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

В booking.com я занимаюсь созданием платформы для вывода в промышленную эксплуатацию продуктов машинного обучения.

Я расскажу о том, как устроена продуктовая разработка в booking.com и о месте машинного обучения в этом процессе. Покажу конкретные примеры применения моделей, расскажу о проблемах мониторинга их качественных характеристик и об архитектуре нашей (постоянно эволюционирующей) ML-платформы.

В Avito я занимаюсь Data Science и разработкой микросервисов в команде Recommendations.

Многорукие бандиты - это один из методов тестирования гипотез, который можно применять в качестве альтернативы A/B-тестированию. Главное отличие в том, что бандиты позволяют оптимизировать выигрыш сразу после начала эксперимента и делают это автоматически. У нас возникла задача тестировать сразу много разных гипотез и автоматически отбрасывать совсем плохие, поэтому мы остановились именно на многоруких бандитах.

В докладе расскажу о том, как применяются многорукие бандиты для различных задач, как применяем их мы для улучшения качества рекомендаций похожих объявлений на карточке товара (item-2-item рекомендации). Также расскажу об архитектурном устройстве сервиса рекомендаций похожих объявлений, сложностях и проблемах, которые возникли в процессе его построения.

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

Основные тезисы:
- Расскажу, как мы поднимали тестовые сервера раньше, когда был монолит и одна БД;
- Почему нас спас Docker, куда ж без него;
- Немного о нашем велосипеде оркестрации на Python, с шедулингом и проксированием ssh в стенд;
- Как мы восприняли новость о внедрении Scrum в разработку и как к этому подготовились;
- Почему версия сервиса заказа TS 2.0 - проблемы, с которыми столкнулись и их решения;

Бонус-треком расскажу, как мы поднимаем по запросу стейдж с полной копией Production-базы за 5 минут, и почему ему не страшен DROP всех таблиц.

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

Основные тезисы:
— Как VK использует ClickHouse (логи / статистика).
— Производительность ClickHouse в наших условиях, конфигурация кластеров.
— Буфер-таблицы.
— Проблемы в эксплуатации.
— kittenhouse: локальный прокси для ClickHouse.
— LightHouse: легкий веб-интерфейс для просмотра содержимого таблиц.

В докладе расскажу о том, как мы мониторим наше self-hosted-облако на основе kubernetes, об опыте эксплуатации prometheus, его эффективной настройке и его "стоимости" при мониторинге больших k8s-кластеров, про наши подходы к мониторингу: summary-дашборды, SLA/SLO/SLI.

Serverless - это все равно сервер. Выход из строя сервера под нагрузкой причиняет боль. Избыточность оборудования в облаке решает эту проблему.

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

Как я измеряю здоровье "железяки", какие показатели правильны для CPU, памяти и устройств хранения?

За 2017 год наша система проверила порядка 5000 серверов. Очевидные пути для проверки оборудования не подошли для пакетной работы. Методы пришлось подбирать экспериментальным путем. Как понять, какие метрики являются показательными? Стоит ли измерять скорость работы RAM?

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

Расскажу, как 2ГИС непрерывно доставляет микросервисную архитектуру, которая уже в продакшне. А ещё о том, как мы изменили традиционный подход связанности микросервисов: убрали излишние интеграции внутри команды и избавились от преждевременного легаси по поддержанию старых версий API.

Деплой представлю на примере GitLab CI, но концепция хорошо применима и для других CI/CD инструментов, таких как Jenkins или TeamCity.

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

Низкая скорость загрузки сайта может значительно повлиять на бизнес-показатели работы интернет-магазина. Так, например, по данным исследований Akamai секунда задержки уменьшает конверсию на 20%.

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

Необходимо оптимизировать TTFB, время рендеринга и инициализации первого экрана, не теряя возможности SSR и не ухудшая SEO.

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

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

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

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

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

В теории распределенных систем есть несколько типичных ошибок, приводящих в лучшем случае к потере данных, а в худшем - к потере заказов и денег и, как следствие, работы. Чтобы такого не случалось, разработчикам нужно руководство и инструменты, которые уберегут от этих ошибок. К счастью разработчиков на платформе .NET, такой инструмент существует: NServiceBus - “The most developer-friendly service bus for .NET”. 

В докладе пойдет речь о таких архитектурных решениях, как очереди, событийный обмен данными на базе асинхронного обмена сообщениями (publish/subscribe), устойчивые к сбоям долгоиграющие процессы (saga). Это неполный список фич, которых требует любая распределенная система, и которых мы рассмотрим на живых примерах, разработанных на базе NServiceBus. 

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

История про опыт Avito в решении одного из вызовов микросервисной архитектуры - реализации бизнес-транзакций с соблюдением консистентности данных между сервисами при использовании архитектурного паттерна Database per Service.

После разделения приложения на несколько сервисов (как следствие, у каждого сервиса своя база данных) уже невозможно сделать все атомарно в 1 ACID-транзакции. Это можно реализовать 2 способами:
- Two-phase commit 2PC;
- sagas.

Как раз мы выбрали паттерн саг - вот об этом я хочу рассказать, в том числе, как мы его реализовали (PG - потому что в нашей реализации в сервисе саг мы используем PostgreSQL).

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

Доклад состоит из трёх частей, базирующихся на результатах различных научных дисциплин в применении к реалиям высоконагруженных информационных систем.
- Среднее арифметическое против медианы. Различные варианты усреднения случайных выборок, их практическая интерпретация и особенности вычисления.
- Элементы теории систем массового обслуживания. Очевидные и невероятные свойства очередей.
- Системные эффекты в сложных системах. Где прячутся обратные связи в вашей архитектуре, и как они могут вас удивить?

Любой высоконагруженный проект — это сложная система из множества отдельных частей. И ее надежность напрямую зависит от взаимодействия этих частей.

Я подниму простую, на первый взгляд, тему — коннект и выполнение запросов к базе данных или другим сервисам. Расскажу, что идет не так во взаимодействии с сервисами, и как мы решаем такие проблемы в Badoo.

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

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

В докладе будут рассмотрены приёмы "чёрной магии" для низкоуровневой оптимизации под конкретные модели CPU и "белой магии" - использование методов data science для достижения прироста производительности на широком диапазоне вариантов CPU.

Многие компании до сих пор строят аналитику по данным, хранимым в MySQL. При этом активно применяются различные предвычисления для ускорения процесса. ClickHouse позволяет выполнять аналитические запросы очень быстро по исходным данным. Система линейно масштабируемая и способна работать с триллионами записей.

Но есть сложность: данные, как писались в MySQL, так и пишутся. Переделывать исходную систему не всегда просто и чревато рисками. Можно ли как-то перенести аналитику на ClickHouse с минимальными модификациями MySQL-системы?

Решением видится фоновое копирование вида «из БД в БД». Это возможно сделать двумя способами:
1. Встроенными средствами ClickHouse, в котором уже есть средства для работы с MySQL.
2. Используя репликатор MySQL → ClickHouse, который подключается к MySQL как replication slave и получает данные на лету, сразу же перекладывая их в ClickHouse, возможно, с дополнительной обработкой.

В докладе будут подробно рассмотрены эти способы, описана утилита репликации из MySQL в ClickHouse от Altinity, а также представлен реальный сценарий переноса аналитики из MySQL в ClickHouse через репликацию, успешно реализованный в компании Ivinco.

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

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

Любой плагин для мониторинга PostgreSQL в любой системе мониторинга основывается на встроенной в PostgreSQL-статистике. При грамотном умении пользоваться этой статистикой можно настроить любой мониторинг для эффективного наблюдения за PostgreSQL.

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

Многие знают, что соединения в PostgreSQL дорогие, а потому их надо экономить. Для решения этой задачи давно есть PgPool-II и PgBouncer.

В Яндексе никого не удивить десятками тысяч соединений к одной базе и с незапамятных времён мы используем PgBouncer. Однако с ним мы столкнулись с множеством проблем. Попытки их решения привели сначала к патчам и костылям, а затем и вовсе к написанию нового пулера, который мы назвали Odyssey. В нём мы устранили архитектурные проблемы PgBouncer'а и сделали много нового. Обо всём этом и расскажем в докладе.

В докладе предлагается и демонстрируется простой метод выявления узких мест в работе серверной части ПО на примере БД Oracle. Применение данного метода на регулярной основе 2 раза в год позволило значительно сократить (примерно раз в 10) количество инцидентов производительности на боевой БД с ЦФТ-Ритейл банк, на которую новый функционал поставляется большими порциями каждые 2 недели. Под инцидентами производительности здесь понимается ситуация сильной деградации производительности прикладного кода (его серверной части, расположенной в БД), который в обычных условиях работает нормально.

ИБСО - это неофициальное название продукта ЦФТ-Банк, которое является лидером рынка core bank-систем в России уже более 15 лет.

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

В Postgres 10 в значительной степени была расширена возможность параллельного выполнения запросов; появилась статистика на несколько колонок; в 11 версии будет JIT-компиляция запросов; наша компания также не остается от этого в стороне.

Доклад будет интересен разработчикам прикладного ПО, желающим использовать все возможности PostgreSQL.

В условиях непрерывного повышения конкуренции в бизнесе, когда преимуществом над конкурентами является любая мелочь, к Автоматизированным Системам выставляются всё более настойчивое требование работы 24x7.

В докладе мы расскажем, насколько компания ЦФТ продвинулась в решении этого вопроса для АБС "ЦФТ-Банк": как мы решали этот вопрос, какие варианты рассматривали, с чем не стали связываться, что попробовали и не получилось, и что получилось в итоге.

На дворе 2018 - все любят микросервисы и пилить монолиты.

При этом у монолита с единой базой есть плюс - целостность и согласованность данных о, например, списании денег за услугу и применении услуги можно гарантировать обычной транзакцией на уровне СУБД (PostgreSQL, Oracle и т.п.).

А что будем делать, если деньги в одном сервисе, а услуги - в другом, и у каждого сервиса своя изолированная база? И подобных бизнес-кейсов все больше и больше. Сколько-нибудь опытный человек сразу отбросит попытку сделать распределенные транзакции. Что же делать?

Разумеется, у идеологов микросервисной архитектуры (Крис Ричардсон и т.п.) есть ответ. И не один. Давайте я расскажу об этих ответах, их плюсах, минусах и рисках, насколько мы в Авито смогли разобраться.

Задумываетесь над автоматизацией call-центра или хотите поговорить с «умным» домом? Время для системы распознавания устной речи. На рынке предложений хоть отбавляй — тут и гиганты IT-индустрии, и фирмы «калибром» поменьше.

А что, если хочется создать собственную систему — бесплатно и кастомно, под конкретную задачу? Расскажу, как это сделать. Начнём с акустических, лингвистических и математических аспектов распознавания речи. Затем перейдём к практике и узнаем, из каких opensource-компонент собрать собственный Speech-to-Text, где взять данные для обучения и как понять, хорошо получилось или так себе.

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

Кто же в итоге победит - BM25, Excel или CatBoost? А хрен его заранее знает - доклад же пока не написан, и примеры не изготовлены. Узнаем на конференции!

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

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

Системы, которые будут упоминаться в докладе, функционируют на RDBMS Oracle Server.

Один из операторов "большой четверки" задумал совершить полную трансформацию своего биллинга и осуществить переход от 8 больших легаси к единой централизованной системе. Наша компания много лет разрабатывала эту самую легаси и выиграла тендер на осуществление новой задумки Заказчика.

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

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