Highload2016
"Архитектура хранения и отдачи фотографий в Badoo", Артём Денисов
В докладе будет рассмотрен процесс построения масштабируемой отказоустойчивой системы хранения, отдачи и обработки фотографий с точки зрения разработчика.
На примере Badoo, я расскажу о стандартном пути эволюции такого рода проектов. Детально разберу каждый этап и остановлюсь на основных сложностях и неочевидных проблемах.
Вместе с рассказом о наших решениях и подходах будут рассмотрены возможные альтернативы, их плюсы и минусы (вплоть до "мы небольшой стартап, как сделать что-нибудь похожее, но по-быстрому и на коленке").
Основные тезисы:
- Эволюция и типичные узкие места каждого из 3-х компонентов системы (хранение, отдача, обработка).
- Как отдавать фотографии? Когда лучше использовать сторонний CDN, а когда написать свой?
- Что лучше - хранить оригинал фото и ресайзить его на лету или заранее нарезать типовые размеры?
- Как сделать эффективное кэширование? Что такое consistent hashing и зачем он нужен?
- Где лучше хранить фотографии? Локальные диски, облачные хранилища, кластерные ФС?
- Надо ли их бэкапить и как часто? Что может пойти не так?
Highload2016
"Как мы готовим MySQL", Николай Королев
* Исторический экскурс, введение понятия спота, принцип функционального деления баз на группы (споты / не споты), шардирование как способ масштабирования спотов.
* Возникновение второго датацентра на другом континенте, создание самодельной репликации, позволяющей работать по схеме много -> много, краткая схема (структура спотов, схема репликации, служебные базы - очереди, репликация, мониторинг), плюсы и минусы этого решения, инструменты диагностики.
* Альтеры шадрированых спотов - первый вариант утилиты для этой задачи: схема его работы и возникшие проблемы; вторая версия утилиты - улучшения, а также, что осталось неисправленным.
* “Температура” спота, трудности её определения, проблемы, возникающие из-за его “перегрева”, наш способ решения и возникновение проекта “кладбище”.
* Деплой и около - почему мы используем MySQL в chroot, как мы его собираем и как деплоим.
* Бэкапы спотовых данных - первоначальное решение (ленточные хранилища), работа над ошибками, текущая схема.
* Query sampling: проект Minba.
Highload 2016
"5 способов деплоя PHP-кода в условиях хайлоада", Юрий Насретдинов
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Паша Мурзаков: Как 200 строк на Go помогли нам освободить 15 серверов» Badoo Development
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
Techleads Meetup #1
"Как автотесты ускоряют релизы в OK.ru"
Никита Макаров, руководитель отдела тестирования (Одноклассники)
Описание:
начиная с 2012 года Одноклассники прошли огромный путь в области ускорения релизов.
Одним из факторов успеха была автоматизация тестирования, которую внедряли «с нуля».
В своем докладе я расскажу:
— о том как мы учили тестировщиков писать автотесты;
— сколотили команду автоматизаторов и построили инфраструктуру автоматизации тестирования;
— о наших ошибках, поражениях, полезных практиках и процессах.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Highload2016
"Как мы готовим MySQL", Николай Королев
* Исторический экскурс, введение понятия спота, принцип функционального деления баз на группы (споты / не споты), шардирование как способ масштабирования спотов.
* Возникновение второго датацентра на другом континенте, создание самодельной репликации, позволяющей работать по схеме много -> много, краткая схема (структура спотов, схема репликации, служебные базы - очереди, репликация, мониторинг), плюсы и минусы этого решения, инструменты диагностики.
* Альтеры шадрированых спотов - первый вариант утилиты для этой задачи: схема его работы и возникшие проблемы; вторая версия утилиты - улучшения, а также, что осталось неисправленным.
* “Температура” спота, трудности её определения, проблемы, возникающие из-за его “перегрева”, наш способ решения и возникновение проекта “кладбище”.
* Деплой и около - почему мы используем MySQL в chroot, как мы его собираем и как деплоим.
* Бэкапы спотовых данных - первоначальное решение (ленточные хранилища), работа над ошибками, текущая схема.
* Query sampling: проект Minba.
Highload 2016
"5 способов деплоя PHP-кода в условиях хайлоада", Юрий Насретдинов
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Паша Мурзаков: Как 200 строк на Go помогли нам освободить 15 серверов» Badoo Development
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
Techleads Meetup #1
"Как автотесты ускоряют релизы в OK.ru"
Никита Макаров, руководитель отдела тестирования (Одноклассники)
Описание:
начиная с 2012 года Одноклассники прошли огромный путь в области ускорения релизов.
Одним из факторов успеха была автоматизация тестирования, которую внедряли «с нуля».
В своем докладе я расскажу:
— о том как мы учили тестировщиков писать автотесты;
— сколотили команду автоматизаторов и построили инфраструктуру автоматизации тестирования;
— о наших ошибках, поражениях, полезных практиках и процессах.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Badoo в облаках. Решение для запуска cli-скриптов в облаке собственной разраб...Badoo Development
Badoo — крупнейшая в мире социальная сеть для знакомств с новыми людьми. У нас тысячи серверов в двух дата-центрах, и какие-то из них постоянно выходят из строя. Наш кластер машин состоит из различных групп: машины для обслуживания веб-запросов, серверы баз данных, хранилище фотографий, серверы для выполнения cron-заданий, машины для C/C++ сервисов и некоторые другие. Для обработки заданий по расписанию мы используем так называемые «скриптовые» машины, на которых запускаются PHP-скрипты в CLI, которые выполняют нужные действия. До недавнего момента мы использовали обычный cron для запуска скриптов по расписанию, а также самописную утилиту для того, чтобы автоматизировать процесс прописывания нужных строчек в cron. Тем не менее, разработчикам приходилось по каким-то критериям выбирать одну или несколько машин, на которых будут запускаться эти скрипты, и они жестко «привязывались» к конкретным серверам. Если какая-то из машин «падала», мы должны были вручную переносить с неё скрипты на другие машины. Чтобы равномерно распределять нагрузку по серверам, а также обеспечивать автоматическое восстановление в случае отказа (failover), мы решили сделать свое «облако», которое призвано решить эти проблемы. Доклад посвящен процессу создания «облака», а также первым результатам, которые мы получили в связи с его использованием.
Краткий план доклада:
- Требования к «облаку».
- Существующие решения.
- Распределение нагрузки по машинам.
- Обработка сбоев оборудования.
- Мониторинг «облака».
"Великолепный API без Rest", Констатин Якушев (Badoo)Badoo Development
DevConf 2016
"Великолепный API без Rest", Констатин Якушев (Badoo)
О чём пойдёт речь:
1. Мы используем Google Protobuf для документации и как протокол для нативных платформ. На вебе они оборачиваются в JSON через http + server-sent events. Расскажу, как это помогает в документации и в процессах.
2. Все поля и сообщения документируются, для новых функций пишется подробный обзор со скриншотами "по шагам" и примерами сообщений и ответов. Покажу, как это выглядит и зачем нужно.
3. Версионирование осуществляется через флаги "Клиент умеет такую-то возможность" или "Клиент знает о таком-то изменении протокола". Это гораздо лучше, чем номер версии и резко увеличивает гибкость системы. Разберу с конкретными примерами, как это работает.
4. Кроме того, расскажу об отдельной команде в Badoo, занимающейся развитием этой истории.
Techleads Meetup #1
"Технологии vs коммуникации: что важнее?"
Альгис Фатеев, руководитель тестирования (Avito)
Описание:
последние несколько лет проект Avito растёт лавинообразным образом, с 2012 года команда разработчиков выросла в 20 раз. За очень короткое время мы прошли путь от «ну что, будем релизиться?» до отлаженного процесса выкатки кода в продакшн. В докладе речь пойдёт о том, как изменилась команда, процессы разработки и жизненный цикл задач в Avito за последние годы, как внедрялось тестирование в проект.
Кроме того, я отдельно рассмотрю вопросы, касающиеся управляемости проекта при резком росте:
— какие решения, заложенные на начальном этапе, позволили нам быстро масштабироваться;
— с какими главными болезнями роста мы столкнулись и как их решали;
— как подготовиться на случай лавинообразного роста.
Багфиксинг процесса разработки в iOS: взгляд с двух сторонBadoo Development
Techleads Meetup #1
"Багфиксинг процесса разработки в iOS: взгляд с двух сторон"
Екатерина Николаенко, iOS QA Lead и
Катерина Трофименко, iOS Developer (Badoo)
Описание:
Приложение Badoo для iOS существует около 7 лет и пережило уже 4 реинкарнации. Наши процессы и подходы не всегда были оптимальны и мы не единственные, кто познали релизы через боль и страдание всех участников процесса разработки.
Чтобы найти идеальный баланс между скоростью и качеством мы решили отрефакторить процессы разработки и тестирования в iOS команде и добились релизов раз в неделю. Из нашего доклада вы узнаете об эволюции команды с точки зрения разработки и тестирования. А так же мы расскажем как мы уменьшили crash-rate в 40 раз.
— Как сделать сеть между Docker контейнерами и дать доступ к ней во вне без спецрешений;
— Какие есть решения в Docker для сетевого взаимодействия;
— сравнение weave, docker netwirking, macvlan.
— Краткий экскурс в предыдущие доклады;
- Описание нашей системы сбора статистики с контейнеров и рассказ почему мы решили отказаться от cadvisord;
- Автоматическая система сборки контейнеров и интеграция с teamcity;
— Наброс о системе генерации и хранения конфигураций.
— Реальная история из жизни о том, как мы внедряли Docker;
— Хочешь чтобы все коллеги узнавали тебя? Займись внедрением Docker в своей компании!;
— Собрать все шишки? Легко… или «Даунтайм, как неотъемлемая часть внедрения»;
— Будь сильным и смелым, если уверен в перспективах и необходимости своего внедрения;
— «Делать новое не ломая старого» – основная цель любого внедрения;
— Чекпоинт, как инструмент промежуточной оценки результатов;
— Как растут наши аппетиты или о новых инфраструктурных идеях;
— Мы сделали это, значит это вполне осуществимо;
— Самое сложное позади или какие приятные результаты вас ожидают, если все пошло правильно.
Документация на тему архитектуры языка PHP скудна и разрозненна, несмотря на то что тема интересна многим. В моем докладе я постараюсь заполнить этот пробел и рассказать о модулях PHP: как они работают, зачем и как их пишут. В процессе мы рассмотрим опыт Badoo в этой сфере на примерах двух модулей. И еще напишем очень небольшой собственный модуль.
— Что такое модули PHP, как они работают
— Как начать писать свой модуль PHP
— Скелет модуля — Функции, классы, методы
— Разбор параметров функции
— Сборка модуля
— Подгрузка модуля
— Простой пример модуля из Badoo
— Сложный пример модуля из Badoo
Тема: Как перестать беспокоиться и начать запускать фичи
Запуск новых фич для любого продукта – довольно опасная штука, ведь столько всего может пойти не так: может вылезти огромное число разных багов (от device specific до багов в самой фиче), могут не выдержать сервера и в конце концов пользователям может просто не понравиться фича.
Я расскажу о том, как мы запускаем новые фичи, какие проблемы, связанные с запусками, у нас возникали и как это всё работает в Android-клиенте.
Тезисы:
– feature toggles: что это, зачем это и как мы сделали своё;
– как мы мониторим и оцениваем запуски;
– как feature toggles дружат с ручным тестированием и как учитываются в автотестах.
Badoo в облаках. Решение для запуска cli-скриптов в облаке собственной разраб...Badoo Development
Badoo — крупнейшая в мире социальная сеть для знакомств с новыми людьми. У нас тысячи серверов в двух дата-центрах, и какие-то из них постоянно выходят из строя. Наш кластер машин состоит из различных групп: машины для обслуживания веб-запросов, серверы баз данных, хранилище фотографий, серверы для выполнения cron-заданий, машины для C/C++ сервисов и некоторые другие. Для обработки заданий по расписанию мы используем так называемые «скриптовые» машины, на которых запускаются PHP-скрипты в CLI, которые выполняют нужные действия. До недавнего момента мы использовали обычный cron для запуска скриптов по расписанию, а также самописную утилиту для того, чтобы автоматизировать процесс прописывания нужных строчек в cron. Тем не менее, разработчикам приходилось по каким-то критериям выбирать одну или несколько машин, на которых будут запускаться эти скрипты, и они жестко «привязывались» к конкретным серверам. Если какая-то из машин «падала», мы должны были вручную переносить с неё скрипты на другие машины. Чтобы равномерно распределять нагрузку по серверам, а также обеспечивать автоматическое восстановление в случае отказа (failover), мы решили сделать свое «облако», которое призвано решить эти проблемы. Доклад посвящен процессу создания «облака», а также первым результатам, которые мы получили в связи с его использованием.
Краткий план доклада:
- Требования к «облаку».
- Существующие решения.
- Распределение нагрузки по машинам.
- Обработка сбоев оборудования.
- Мониторинг «облака».
"Великолепный API без Rest", Констатин Якушев (Badoo)Badoo Development
DevConf 2016
"Великолепный API без Rest", Констатин Якушев (Badoo)
О чём пойдёт речь:
1. Мы используем Google Protobuf для документации и как протокол для нативных платформ. На вебе они оборачиваются в JSON через http + server-sent events. Расскажу, как это помогает в документации и в процессах.
2. Все поля и сообщения документируются, для новых функций пишется подробный обзор со скриншотами "по шагам" и примерами сообщений и ответов. Покажу, как это выглядит и зачем нужно.
3. Версионирование осуществляется через флаги "Клиент умеет такую-то возможность" или "Клиент знает о таком-то изменении протокола". Это гораздо лучше, чем номер версии и резко увеличивает гибкость системы. Разберу с конкретными примерами, как это работает.
4. Кроме того, расскажу об отдельной команде в Badoo, занимающейся развитием этой истории.
Techleads Meetup #1
"Технологии vs коммуникации: что важнее?"
Альгис Фатеев, руководитель тестирования (Avito)
Описание:
последние несколько лет проект Avito растёт лавинообразным образом, с 2012 года команда разработчиков выросла в 20 раз. За очень короткое время мы прошли путь от «ну что, будем релизиться?» до отлаженного процесса выкатки кода в продакшн. В докладе речь пойдёт о том, как изменилась команда, процессы разработки и жизненный цикл задач в Avito за последние годы, как внедрялось тестирование в проект.
Кроме того, я отдельно рассмотрю вопросы, касающиеся управляемости проекта при резком росте:
— какие решения, заложенные на начальном этапе, позволили нам быстро масштабироваться;
— с какими главными болезнями роста мы столкнулись и как их решали;
— как подготовиться на случай лавинообразного роста.
Багфиксинг процесса разработки в iOS: взгляд с двух сторонBadoo Development
Techleads Meetup #1
"Багфиксинг процесса разработки в iOS: взгляд с двух сторон"
Екатерина Николаенко, iOS QA Lead и
Катерина Трофименко, iOS Developer (Badoo)
Описание:
Приложение Badoo для iOS существует около 7 лет и пережило уже 4 реинкарнации. Наши процессы и подходы не всегда были оптимальны и мы не единственные, кто познали релизы через боль и страдание всех участников процесса разработки.
Чтобы найти идеальный баланс между скоростью и качеством мы решили отрефакторить процессы разработки и тестирования в iOS команде и добились релизов раз в неделю. Из нашего доклада вы узнаете об эволюции команды с точки зрения разработки и тестирования. А так же мы расскажем как мы уменьшили crash-rate в 40 раз.
— Как сделать сеть между Docker контейнерами и дать доступ к ней во вне без спецрешений;
— Какие есть решения в Docker для сетевого взаимодействия;
— сравнение weave, docker netwirking, macvlan.
— Краткий экскурс в предыдущие доклады;
- Описание нашей системы сбора статистики с контейнеров и рассказ почему мы решили отказаться от cadvisord;
- Автоматическая система сборки контейнеров и интеграция с teamcity;
— Наброс о системе генерации и хранения конфигураций.
— Реальная история из жизни о том, как мы внедряли Docker;
— Хочешь чтобы все коллеги узнавали тебя? Займись внедрением Docker в своей компании!;
— Собрать все шишки? Легко… или «Даунтайм, как неотъемлемая часть внедрения»;
— Будь сильным и смелым, если уверен в перспективах и необходимости своего внедрения;
— «Делать новое не ломая старого» – основная цель любого внедрения;
— Чекпоинт, как инструмент промежуточной оценки результатов;
— Как растут наши аппетиты или о новых инфраструктурных идеях;
— Мы сделали это, значит это вполне осуществимо;
— Самое сложное позади или какие приятные результаты вас ожидают, если все пошло правильно.
Документация на тему архитектуры языка PHP скудна и разрозненна, несмотря на то что тема интересна многим. В моем докладе я постараюсь заполнить этот пробел и рассказать о модулях PHP: как они работают, зачем и как их пишут. В процессе мы рассмотрим опыт Badoo в этой сфере на примерах двух модулей. И еще напишем очень небольшой собственный модуль.
— Что такое модули PHP, как они работают
— Как начать писать свой модуль PHP
— Скелет модуля — Функции, классы, методы
— Разбор параметров функции
— Сборка модуля
— Подгрузка модуля
— Простой пример модуля из Badoo
— Сложный пример модуля из Badoo
Тема: Как перестать беспокоиться и начать запускать фичи
Запуск новых фич для любого продукта – довольно опасная штука, ведь столько всего может пойти не так: может вылезти огромное число разных багов (от device specific до багов в самой фиче), могут не выдержать сервера и в конце концов пользователям может просто не понравиться фича.
Я расскажу о том, как мы запускаем новые фичи, какие проблемы, связанные с запусками, у нас возникали и как это всё работает в Android-клиенте.
Тезисы:
– feature toggles: что это, зачем это и как мы сделали своё;
– как мы мониторим и оцениваем запуски;
– как feature toggles дружат с ручным тестированием и как учитываются в автотестах.
Тема: Измерение энергопотребления мобильных и внедрение в Continuous Integration
Во время выступления я буду говорить про:
– проектирование устройства измерения энергопотребления;
– применение устройства анализа энергопотребления смартфона;
– автоматизацию процесса тестирования энергопотребления;
– поиск энергозатратных функций браузера;
– оптимизацию и контроль потребления энергии в браузере.
Тема: Компонентные тесты: как сделать жизнь вашего QA немного проще?
В докладе речь пойдёт о компонентных тестах, в том числе я поделюсь лучшими практиками, которые выработала наша команда, и расскажу, как они помогают нам делать более качественный продукт.
В частности поговорим о том:
– что такое компонентный тест? В чем отличия между юнит-, компонентным и функциональным тестом?
– для чего хороши компонентные тесты и какие проблемы они помогают нам решать?
– как минимизировать стоимость поддержки компонентных тестов без экономии на их надежности.
Я расскажу о нестандартных особенностях языка для реальных проектов. Речь пойдет о том, зачем усложнять себе жизнь и какие преимущества это может дать.
- Protocol-Oriented Programming и его дилеммы
- Когда и зачем использовать обобщения и вложенные типы
- Настоящее и будущее Swift
Cocoaheads Meetup / Kateryna Trofimenko / Feature developmentBadoo Development
Я расскажу о том, что такое feature flags, как они нам в Badoo помогают разрабатывать большие фичи итерационно, силами нескольких разработчиков, и не переживать из-за кода, уходящего в релизы.
И вы узнаете о том, как система таргетированной раскладки фич переросла в систему a/b-тестирования и как все это выглядит со стороны iOS-клиента
Hadoop framework is a popular solution to such tasks as distributed data storage and running. Map/Reduce tasks on cluster. High scalability, mature ecosystem and large community make Hadoop one the most popular framework in distributed data processing. But the more responsibility you put on it, the more important it becomes to provide its fault-taulerance and high availability. This presentation will be useful to those, who have already been using Hadoop. For the rest it will be interesting to learn some architectural solutions applied in Hadoop.
In my presentation I will cover aspects of high availability implementation for Hadoop.
Besides, I will talk on:
– “The zoo” we have to deal with;
– Why we should provide high availability: points of system failure and its consequences;
– Tools and solutions to such problems;
– Our practical experience of implementation: preparation, deploy, testing.
Вероятно, многие пробовали использовать решение Zabbix для мониторинга баз данных. Из моего доклада вы узнаете о нашем опыте его применения, и к чему мы в итоге пришли.
1. Штатный Zabbix-мониторинг баз данных: особенности реализации/настройки в промышленных масштабах
2. Преимущества/недостатки решения мониторинга баз данных от Zabbix SIA
3. Преимущества/недостатки существующих расширений Zabbix для мониторинга баз данных
4. Подробнее о расширении DBforBix v2.3 beta: конфигурирование, возможности
5. Доработка DBforBix: сохраняем преимущества и устраняем недостатки штатного мониторинга баз данных Zabbix
6. Варианты развития идеи
Тема: Как перестать бороться с графиками и начать жить
Я расскажу вам про интеграцию Zabbix и Grafana, чтобы вы могли улучшить возможности визуализации данных мониторинга с помощью Grafana.
1. Зачем нужны графики?
2. Как нарисовать 100 графиков за 10 секунд? (Query Editor, Regex, Templating)
3. И что потом с этим делать? ( Max Data Points, Functions, Performance)
4. События – это тоже Time Series (Annotations)
5. Seek & Destroy (Alerting в Grafana)
6. Бонус: Heatmap
Илья Аблеев – Zabbix в Badoo: реагируем быстро и качественноBadoo Development
В условиях большой инфраструктуры и немалого количества критичных компонентов, время реакции на инцидент должно быть как можно меньше. В докладе я расскажу, какие инструменты помогают увеличить скорость реакции и уведомить о проблеме качественнее.
QA-конференция heisenbug.ru
ChromeDriver Jailbreak, Александр Баяндин (Badoo)
Chrome DevTools — один из наиболее полезных инструментов веб-разработчика. Он позволяет получать исчерпывающую информацию о странице и запросах и эмулировать мобильные браузеры на медленных устройствах. ChromeDriver использует тот же Chrome Debugging Protocol, что и DevTools для реализации Selenium JSON Wire Protocol взаимодействия с браузером. Этот протокол описывает самый базовый набор методов для взаимодействия со страницей, который несомненно уже всего набора методов, доступных в DevTools. В своём докладе Александр расскажет о том, как можно использовать (почти) всю мощь DevTools в Selenium-тестах и как сделать их отладку наиболее удобной.
Techleads Meetup #1
Мобильный веб: назад в будущее"
Виталий Шароватов, Mobile Web Team Lead и Руслан Байрамкулов, Senior Mobile Web QA Engineer (Badoo)
Описание:
Количество пользователей мобильных устройств уже давно превысило количество пользователей стационарных компьютеров и ноутбуков. В свою очередь мобильный веб — это самая быстрорастущая мобильная платформа (по данным comScore, 2015). И если будущее не за этой платформой, то как минимум, она будет его заметной частью.
Давным-давно для Мобильного веба в Badoo были «тёмные времена». Использовались дизайны нативных платформ и эмитировалось их поведение. Даже релизы случались раз в неделю-две. Около года назад ситуация начала меняться в лучшую сторону. Мобильная веб версия Badoo догнала по количеству фич остальные платформы и показала существенный рост по всем показателям. Теперь мобильный веб релизится каждый день.
В докладе мы расскажем о том, что неправильного происходит с процессами внутри и снаружи команды. Для примера возьмем как собственные грабли, так и чужие, но такие распространённые ошибки организации работы.
О том, что не помогло, рассказывать не будем, а о том, что сработало, ничего не утаим. Эта информация поможет вам работать в удовольствие. В ассортименте истории о том:
— как один автоматизатор всю регрессию покрыл;
— как подружились продакты-дизайнеры с командой разработки;
— как жадные программисты забрали себе всю ответственность;
— пуркуа QA любит сидеть с девелоперами плечом к плечу;
— зачем нужно не спускать глаз с багов, ломающих автоматизацию, и как заканчивать фичу после того, как закончили фичу.
«Что надо знать о HTTP/2», Александр Майоров (Tutu.ru)
Протокол HTTP/2 обещает ускорение загрузки страниц и очень активно продвигается. Так ли это и какую пользу от протокола могут получить Frontend разработчики? Стоит ли переходить на новый протокол? В качестве киллер фичи заявлена поддержка Server push. Что это и как этим пользоваться? Эти и другие вопросы будут освещены в докладе.
«Парсим CSS», Роман Дворнов (Avito)
В ходе работы над CSSO мне пришлось погрузиться в процесс парсинга CSS. В результате парсер (тот, что в CSSO) был не раз переписан. Пришло время сделать его отдельным инструментом. Новый быстрый детальный парсер CSS, его AST, области применения и кое-что ещё.
13. ! Меньше $/Gb
! Больше плотность размещения
bphotos2
bphotosN
Storage Area Network
(SAN)
bphotos1
Используем систему хранения данных
14. ! Меньше $/Gb
! Больше плотность размещения
! Быстрая деградация чтения (>500 rps per host)
bphotos2
bphotosN
Storage Area Network
(SAN)
bphotos1
Используем систему хранения данных
25. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon
Хранит статистику запросов по файлам
26. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon
Хранит статистику запросов по файлам
Часто запрашиваемые -> Hot cache
27. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon
Хранит статистику запросов по файлам
Часто запрашиваемые -> Hot cache
Редко запрашиваемые -> Cold cache
28. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon
Хранит статистику запросов по файлам
Часто запрашиваемые -> Hot cache
Редко запрашиваемые -> Cold cache
Постепенно удаляет из Cold cache
46. Кэширование. Результаты
- Hitrate (количество попаданий в кэш) 98%
- Из 80k только 1600 rps доходят до bphotos
- 3 точки присутствия (Прага, Майами, Гонконг)
47. Кэширование. Результаты
- Hitrate (количество попаданий в кэш) 98%
- Из 80k только 1600 rps доходят до bphotos
- 3 точки присутствия (Прага, Майами, Гонконг)
+
- Поддержка webp, progressive jpeg
- Динамический resize/crop
- Динамические вотермарки, фильтры (blur, pixelize)
49. Почему не CDN?
- Хочется больше контроля и предсказуемости
- Система развивалась постепенно
50. Почему не CDN?
- Хочется больше контроля и предсказуемости
- Система развивалась постепенно
- Много специфической логики на фотокэшах
51. Почему не CDN?
- Хочется больше контроля и предсказуемости
- Система развивалась постепенно
- Много специфической логики на фотокэшах
- Невысокая сложность поддержки итогового решения
52. Почему не CDN?
- Хочется больше контроля и предсказуемости
- Система развивалась постепенно
- Много специфической логики на фотокэшах
- Невысокая сложность поддержки итогового решения
Современный CDN — хорошая альтернатива в условиях
дефицита ресурсов и времени
62. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Резервирование v.1
63. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition
Резервирование v.1
64. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition
! NO DATA LOSS
Резервирование v.1
65. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition
! NO DATA LOSS
! POINT OF FAILURE
Резервирование v.1
66. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition
! NO DATA LOSS
! POINT OF FAILURE
! MAINTENANCE
Резервирование v.1
85. Dphotos. Результаты
- Отказоустойчивость
- Простая эксплуатация
- Двойной запас по чтению
- Сложность разработки
Так хранить локально — это хорошо или плохо?
- Проще в эксплуатации
86. Dphotos. Результаты
- Отказоустойчивость
- Простая эксплуатация
- Двойной запас по чтению
- Сложность разработки
Так хранить локально — это хорошо или плохо?
- Проще в эксплуатации
- Производительнее
87. Dphotos. Результаты
- Отказоустойчивость
- Простая эксплуатация
- Двойной запас по чтению
- Сложность разработки
Так хранить локально — это хорошо или плохо?
- Проще в эксплуатации
- Производительнее
- В 1.5 раза дороже, чем SAN
96. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
97. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
98. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
- Immutable фотки
99. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
- Immutable фотки
- Resize на лету
100. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
- Immutable фотки
- Resize на лету
- Инкрементальные асинхронные бэкапы - это хорошо
101. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
- Immutable фотки
- Resize на лету
- Инкрементальные асинхронные бэкапы - это хорошо
- Если что-то может сломаться - оно сломается