Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Yevgen Lysenko "AWS RDS Aurora Serverless, ECS Fargate and more serverless-pr...Fwdays
Marketing materials and documentation of AWS and other cloud providers do present their Serverless-services as a future of cloud computing, that ought to solve nearly all current problems. Is that so? Is there something marketers and documentation are hiding from us? What are costs and productivity?
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
Клиентские приложения под нагрузкой (HighLoad 2014)Andrey Smirnov
"Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"
Подобный обмен претензиями частенько можно услышать в спорах клиентских и серверных разработчиков. В этом докладе я попробую примирить обе стороны. Только от успешного взаимодействия клиентского приложения и серверной части зависит успех высоконагруженного проекта в целом.
* Как сделать так, чтобы клиент не "завалил" сервер?
* Коммуникация ошибок от сервера к клиенту.
* Синхронизация, разрешение конфликтов.
* Работа в offline-режиме.
* Разработка эффективного и корректного API.
* Асинхронное взаимодействие.
* Почему клиент и сервер на самом деле очень похожи?
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
Многие сайты измеряют время формирования странички, хотя на самом деле надо измерять время у пользователя. Тут рассказывается как это делать, и почему доставка страничек может занимать 10 секунд, при ping 100ms
Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh / Миша Кир...Ontico
Разговор в докладе пойдёт о веб-программировании.
При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.
Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.
Хочу поделиться со слушателями своим личным опытом разработки с использованием подобной связки. Планирую рассказать о плюсах и минусах такого подхода.
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Язык Lua — секреты производительности / Ник Заварицкий (Mail.ru)Ontico
Lua — высокоуровневый язык, похожий на Python/JS, но существенно более простой. Он гибкий и при этом очень быстрый.
Многие слышали про OpenResty. Это решение для разработки Nginx модулей на Lua. Cloudflare, крупнейший CDN/anti-DDOS провайдер, как раз работает на OpenResty.
У нас была задача валидации данных на соответствие схеме; мы переписали валидацию с Си на Lua и получили ускорение в 4 раза (за счет JIT-компиляции).
Что будет в докладе:
* краткое введение в язык Lua;
* как работает трассирующий JIT-компилятор Lua;
* как писать быстрый код, искать и устранять проблемы с производительностью;
* наш опыт: как мы ускорились в 4 раза, переписав валидацию с Си на Lua.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Anton Turetckii "What does it take to build a host?"Fwdays
Real hardware in the data center: everything you wanted to know but didn’t know how to ask.
2020: how to build a server if you don’t use clouds
How to get rid of or reduce problems when ordering, allocating, and mounting the hardware
Yes, there are people working in your data center (If you have one)!
What is hidden in between the server’s power button activation and its appearance in your internal system
Automation and its role in the process: do exactly what is necessary and enough!
Near-realtime аналитика событий в высоконагруженном проекте / Александр Краше...Ontico
Типовой задачей аналитики для любого проекта является получение ответов на вопросы: "сколько у нас регистраций за последний день?", "сколько сообщений было отправлено (товаров добавлено в корзину и пр.) в стране N, мужчинами/женщинами из приложения/сайта?". Поиском ответов на эти вопросы в компании обычно занимается отдел BI.
Инструментарием могут служить различные технологии: файлы Excel, старые-добрые РСУБД (MySQL, PosgtreSQL, MS SQL, Oracle etc.), специализированные аналитические базы данных (Vertica, Exasol, etc.), вычисления на Hadoop-кластере. Естественно, любое решение обладает своими достоинствами и недостатками — что-то ограничено по объему обрабатываемой информации, что-то — по скорости, что-то — по realtime.
Перед нами стояла задача сделать систему аналитики:
+ Горизонтально масштабируемой — уже не хватает ресурсов SQL.
+ Близкой к реальному времени — аналитические базы и Hadoop не дают нам желаемого эффекта.
+ Легкой в конфигурировании — любой новый отчет требует минимума затрат от разработчика.
Мы можем рассказать о том, как мы построили систему, которая прямо сейчас обрабатывает 200к событий в секунду, строит 12М метрик и может еще расти и расти.
Под капотом: Apache Spark для near-realtime обработки событий, Hadoop — как фундамент для масштабирования.
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Yevgen Lysenko "AWS RDS Aurora Serverless, ECS Fargate and more serverless-pr...Fwdays
Marketing materials and documentation of AWS and other cloud providers do present their Serverless-services as a future of cloud computing, that ought to solve nearly all current problems. Is that so? Is there something marketers and documentation are hiding from us? What are costs and productivity?
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
Клиентские приложения под нагрузкой (HighLoad 2014)Andrey Smirnov
"Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"
Подобный обмен претензиями частенько можно услышать в спорах клиентских и серверных разработчиков. В этом докладе я попробую примирить обе стороны. Только от успешного взаимодействия клиентского приложения и серверной части зависит успех высоконагруженного проекта в целом.
* Как сделать так, чтобы клиент не "завалил" сервер?
* Коммуникация ошибок от сервера к клиенту.
* Синхронизация, разрешение конфликтов.
* Работа в offline-режиме.
* Разработка эффективного и корректного API.
* Асинхронное взаимодействие.
* Почему клиент и сервер на самом деле очень похожи?
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
Многие сайты измеряют время формирования странички, хотя на самом деле надо измерять время у пользователя. Тут рассказывается как это делать, и почему доставка страничек может занимать 10 секунд, при ping 100ms
Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh / Миша Кир...Ontico
Разговор в докладе пойдёт о веб-программировании.
При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.
Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.
Хочу поделиться со слушателями своим личным опытом разработки с использованием подобной связки. Планирую рассказать о плюсах и минусах такого подхода.
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Язык Lua — секреты производительности / Ник Заварицкий (Mail.ru)Ontico
Lua — высокоуровневый язык, похожий на Python/JS, но существенно более простой. Он гибкий и при этом очень быстрый.
Многие слышали про OpenResty. Это решение для разработки Nginx модулей на Lua. Cloudflare, крупнейший CDN/anti-DDOS провайдер, как раз работает на OpenResty.
У нас была задача валидации данных на соответствие схеме; мы переписали валидацию с Си на Lua и получили ускорение в 4 раза (за счет JIT-компиляции).
Что будет в докладе:
* краткое введение в язык Lua;
* как работает трассирующий JIT-компилятор Lua;
* как писать быстрый код, искать и устранять проблемы с производительностью;
* наш опыт: как мы ускорились в 4 раза, переписав валидацию с Си на Lua.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Anton Turetckii "What does it take to build a host?"Fwdays
Real hardware in the data center: everything you wanted to know but didn’t know how to ask.
2020: how to build a server if you don’t use clouds
How to get rid of or reduce problems when ordering, allocating, and mounting the hardware
Yes, there are people working in your data center (If you have one)!
What is hidden in between the server’s power button activation and its appearance in your internal system
Automation and its role in the process: do exactly what is necessary and enough!
Near-realtime аналитика событий в высоконагруженном проекте / Александр Краше...Ontico
Типовой задачей аналитики для любого проекта является получение ответов на вопросы: "сколько у нас регистраций за последний день?", "сколько сообщений было отправлено (товаров добавлено в корзину и пр.) в стране N, мужчинами/женщинами из приложения/сайта?". Поиском ответов на эти вопросы в компании обычно занимается отдел BI.
Инструментарием могут служить различные технологии: файлы Excel, старые-добрые РСУБД (MySQL, PosgtreSQL, MS SQL, Oracle etc.), специализированные аналитические базы данных (Vertica, Exasol, etc.), вычисления на Hadoop-кластере. Естественно, любое решение обладает своими достоинствами и недостатками — что-то ограничено по объему обрабатываемой информации, что-то — по скорости, что-то — по realtime.
Перед нами стояла задача сделать систему аналитики:
+ Горизонтально масштабируемой — уже не хватает ресурсов SQL.
+ Близкой к реальному времени — аналитические базы и Hadoop не дают нам желаемого эффекта.
+ Легкой в конфигурировании — любой новый отчет требует минимума затрат от разработчика.
Мы можем рассказать о том, как мы построили систему, которая прямо сейчас обрабатывает 200к событий в секунду, строит 12М метрик и может еще расти и расти.
Под капотом: Apache Spark для near-realtime обработки событий, Hadoop — как фундамент для масштабирования.
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Anton Baranov
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
Прежде всего, мы постараемся сделать доклад не сравнением feature-листов, а рассмотреть особенности практического применения разных систем для конкретной задачи - для сайта, который не должен падать (а точнее - для возможности оперативно отреагировать на аварию, понять что к ней привело, и как можно ее исправить).
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Порядок преодоления болота на маршруте: как не надо писать приложения, основа...HLL
Артём Гавриченков (ximaera), ведущий разработчик сети фильтрации трафика Qrator, описывает типичные ошибки программирования при написании серверных приложений на основе TCP-сокетов в рамках конференции «Российские интернет-технологии» (2-3 апреля 2012, Москва).
Разбирается (вероятно, неисчерпывающий) ряд заблуждений и узких мест, приводящих к проблемам с производительностью и уязвимостям безопасности TCP-приложений; приводится ряд примеров, когда ошибки, неочевидные на этапе программирования, при эксплуатации приводили к финансовым и репутационным потерям у авторов и пользователей приложения. Даются рекомендации по отладке и оптимизации приложений, основанных на TCP, а также операционных систем, в которых эксплуатируются такие продукты.
Среди прочего, разбираются такие аспекты работы обработчика TCP-запросов, как:
• предотвращение атак, аналогичных slow POST в Nginx и Lighttpd;
• предотвращение ошибок, аналогичных проблеме со скачиванием файлов в браузере Internet Explorer;
• возможные изменения в дизайне самописных TCP-based протоколов с целью их ускорения;
• использование опции TCP (таких, как TCP_NODELAY) для ускорения работы специфических приложений.
Доклад "Remote Highload" c Highload++-2016
Созданием еще одной высоконагруженной системы сегодня уже сложно кого-то удивить. Как насчет высоконагруженной системы, которая была создана и эксплуатируется 100% удаленной командой, работающей в 5 часовых поясах?
В докладе пойдет речь о команде Virtustream (Dell Technologies), которая отвечает за Virtustream Storage Cloud.
Экзабайты данных, десятки тысяч серверов, сотни гигабит в секунду, сотни тысяч и миллионы запросов в секунду, 20 датацентров по всему миру и, при этом, команда разработчиков из 15 человек, это возможно?
В докладе мы поговорим о разных аспектах - от культуры разработки и процесса найма до контейнерной платформы запуска микросервисов и выбора языка программирования.
Почему не работает Scrum, и плохо работает парное программирование? Как Mesos, Marathon, Consul и Calico делают возможным выкладывание нового сервиса за 5 минут? Почему каждый разработчик должен иметь доступ в production?
aptly is a swiss army knife for Debian repository management: it allows to mirror remote repositories, take snapshots, pull new versions of packages along with dependencies, publish snapshots.
http://www.aptly.info/
aptly - система управления Debian-репозиториями пакетовAndrey Smirnov
aptly is a swiss army knife for Debian repository management: it allows to mirror remote repositories, take snapshots, pull new versions of packages along with dependencies, publish snapshots.
13. pyFMS
● Плюсы:
● Скорость разработки, переносимость
● Оптимизированный код и event loop
● Доп. протоколы: memcached
● Минусы:
● Однопоточность
14. Qik Push Engine
● Быстрое read-only API
● Независимое от основной БД key-value хранилище
● Обработка и распределение изменений
по подпискам (pubsub)
● AMQP-сервер в качестве шины обмена
сообщениями и хранилища событий