Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)Ontico
Tarantool - отечественная Opensource NoSQL база данных.
В докладе мы обсудим:
- Какое место занимают NoSQL базы данных в highload проектах?
Почему и для чего вам стоит NoSQL решения?
Какие NoSQL решения вы можете использовать?
- Рассмотрим, что из себя представляет Tarantool 1.6 - база данных и сервер приложений в одном лице.
Какие основные особенности Tarantool как NoSQL базы данных?
Lua как встроенный язык сервера приложений.
- Посмотрим, как можно начать использовать Tarantool в своих проектах, и сделаем первые шаги.
Как установить Tarantool.
Первый запуск и основы конфигурирования.
Модель данных.
Как создавать и работать с хранилищем данных.
Как использовать пакеты tarantool.
- Узнаем об интересных модулях и фичах Tarantool
Чем полезен application server
Tarantool http
Tarantool queue
- Познакомимся с сообществом Tarantool opensource
Почему сообщество - это важно?
Чем полезны opensource проекты начинающему разработчику?
Highload на GPU, опыт Vinci / Олег Илларионов (ВКонтакте)Ontico
Vinci - это второе по популярности приложение в мире для обработки фотографий с помощью нейронных сетей.
Расскажу, как менее чем за месяц с нуля разработать и развернуть приложение, обработать 3 миллиона фотографий на GPU в день запуска и не упасть.
Доклад будет разделен на 3 части:
1) Менеджинг задач при работе с GPU, как найти компромисс между надежностью и максимальной производительностью.
2) Обзор инструментов, подводных камней и софта.
3) Что можно и нужно оптимизировать, какие есть дальнейшие перспективы.
Цель доклада – развеять миф, что нейросети это сложно.
10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...Ontico
Веб-сайт нужно делать так, чтобы о перипетиях его разработки и поддержки бессонными ночами через пару лет можно было рассказать на конференции Highload++, а тамошнюю аудиторию сложно удивить велосипедом с треугольными каменными колесами. Большинство разработчиков свято следуют этому принципу то ли в силу природной любознательности и трудолюбия, то ли по причине отсутствия конференции LowLoad--.
Примерно такие мысли приходят в голову практически любому специалисту по хранилищам данных, когда он видит успешный веб-проект, испытывающий стандартные проблемы с базой данных.
В этом докладе я расскажу о 10-ти очень распространенных ошибках проектирования и эксплуатации хранилища в веб-проекте — от преждевременного шардирования базы и непродуманной системы архивации ненужных данных до особенностей работы всеми любимых фреймворков. Про каждую из них я расскажу подробно и поделюсь рецептами, как такие ошибки исправлять.
В докладе мы поделимся опытом создания content-based рекомендательной системы для электронной коммерции, работающей на семантическом ядре рунета (десятки миллионов профилей). Расскажем, как организовали централизованный сбор и обработку информации о посещении пользователями более 100 000 сайтов различной направленности на основе Amazon Kinesis. Поделимся опытом многопоточной онлайн-индексации потоков данных в Lucene. Продемонстрируем используемые базовые алгоритмы ранжирования и формирования персональных рекомендаций для посетителей более 20 000 интернет-магазинов.
Поговорим о плюсах и минусах лямбда-архитектур и обоснуем выбранное нами архитектурное решение. Отдельно остановимся на тонкостях технической реализации многопоточных алгоритмов и особенностях обеспечения реального времени - поступившая информация о действиях посетителя практически мгновенно учитывается рекомендательным движком, обеспечивая максимальную конверсию.
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...Ontico
Facebook использует MySQL в качестве основного хранилища данных. MySQL работает на десятках тысяч серверов в нескольких ЦОДах. В качестве дисков используются Flash-накопители. Они дают большую производительность, но дорогой ценой — MySQL хранит данные на диске в структуре B-tree, которая использует flash-диск неоптимальным образом. В масштабах Facebook'a цена вопроса измеряется миллионами долларов.
Для оптимального использования Flash-дисков в Facebook была разработана библиотека RocksDB. Она основана на LSM-деревьях и оптимизирована для работы в условиях высокой загрузки. Чтобы использовать ее из MySQL, [совместно с MariaDB] был разработан табличный движок — MyRocks.
Данный доклад посвящен RocksDB и MyRocks. Мы расскажем о принципах их работы и преимуществах, как их настраивать, и какие возможны подводные камни.
Авторы доклада — ведущие разработчики MyRocks от Facebook и MariaDB.
RocksDB и MyRocks доступны на GitHub для свободного использования, участие в разработке также приветствуется.
Artisto: опыт запуска нейросетей в production / Эдуард Тянтов (Mail.ru Group)Ontico
Artisto - первое в мире мобильное приложение для обработки видео с помощью нейросетей в стиле картин художников и любых исходных изображений. Приложение вошло в топы AppStore и Google Play в США.
В рамках доклада расскажу:
- как научить нейросети рисовать, а, главное, красиво и быстро;
- про особенности переноса стиля на видео;
- про технологический стек.
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Ontico
Unity3D - это внушительный набор средств для кроссплатформенной разработки игр и 3D-приложений. Однако ряд его особенностей может привести к внезапному падению производительности продукта на мобильных платформах.
Где же прячутся подводные камни? Как обеспечить оптимальный user experience на старом смартфоне? Каких "граблей" стоит избегать при написании кода и подготовке графики? Рассмотрим на примере RPG "Гильдия Героев" для Android и iOS.
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Zabbix в Badoo или о чем не пишут в мануале, Илья Аблеев (Badoo)Badoo Development
Доклад с Zabbix Meetup.
Рассказали про:
• Сколько инстансов используем, зачем, какая конфигурация и нагрузка, какие дополнительные тулзы используем.
• Деплой скриптов/конфигов/обновлении.
• Флоу появления новых сущностей в мониторинге: хостов, проверок, графиков в заббикс. Самописный дискавери (серверов, сервисов): почему свой и что он умеет.
• Штуки для удобства: нотификации на рабочий стол, быстрая навигация по графикам.
Принципы и приёмы обработки очередей / Константин Осипов (Mail.ru)Ontico
Насколько повысится среднее время обработки одного запроса если увеличить нагрузку вдвое? Почему производительность базы данных может снизиться при росте числа клиентов? Как добиться эффективного распределения большого числа задач на весь кластер? О практике и о теории обработки очередей на которой основана практика в моём докладе.
smart balancing with nginx+lua / Андрей Кононов (IPONWEB)Ontico
В этом докладе я планирую осветить следующие проблемы:
- Почему стандартных механизмов балансировки бывает недостаточно.
- Как выбирать фундамент для решения, и какие принципы проектирования использовались.
- Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество.
Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения.
Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Сейчас OpenStack на слуху, но детальных отзывов и описаний дизайна инфраструктуры все еще не много. Постараемся немного упростить задачу для тех, кто еще только планирует развертывание инфраструктуры виртуализации, и расскажем, как это делали мы в некоторых наших проектах:
погрузимся в нюансы реализации окружения OpenStack в боевой среде;
поговорим об отказоустойчивости;
рассмотрим варианты организации резервного копирования;
обратим внимание на конфигурацию «железок»: СХД и сети.
Deployment to production with an unexpected loadGrid Dynamics
In his talk, Max Mazur a DevOps Engineer at Grid Dynamics, shares his experience deploying to production despite unexpected loads using the example of the web application (RTB). There you can find specific cases of using MySQL and resolving solutions. Technology stack: Linux, MySQL, PHP, Nginx, Kafka, Redis, Gearman
Zabbix Moscow Meetup 2016
Доклад Ильи Аблеева, руководителя Отдела мониторинга Badoo на тему: "От LLD к Super Discovery или как переложить мониторинг на девелопера".
В докладе Илья рассказал про то как его отдел покрыл в Badoo мониторингом довольно большое количество бизнес- и аппликейшн-метрик, не заставляя девелоперов изучать Zabbix API и как расширили стандартные возможности уведомлений Zabbix.
This document discusses declarative configuration management using Kubernetes and Helm. It begins with an overview of DevOps and configuration management processes. It then provides background on tools like Puppet, Chef, and Ansible before introducing Kubernetes as an operating system for microservices and Helm as a package management system. Key points covered include how Helm works by generating Kubernetes YAML configurations and using Tiller to apply them in the cluster. The document also notes that the Helm chart repository is large and actively maintained on GitHub. It concludes by acknowledging issues with Golang and configuration tools while also noting the presenter does not really care to criticize them.
This document discusses configuration management (CM) tools like Chef, Puppet, and Ansible and container orchestration tools like Docker and Kubernetes. It provides an overview of what each tool is used for. Helm is introduced as a package manager and configuration management tool for Kubernetes that uses templates. While template usage is noted as a potential issue, Helm is described as having a large community and being a de facto standard in the Kubernetes world. Alternatives to Helm are also mentioned. In the conclusions, Helm is said to be an improvement over Ansible and that the author's personal experiences have been financially beneficial.
The document discusses Ansible and its shortcomings. It proposes alternatives like Stonic and s1onique that were intended to improve on Ansible but also faced issues. The document suggests rewriting Ansible in different languages like Haskell, Kotlin, Rust to address its problems in enforcing a clearly defined desired state. It concludes by questioning the use of configuration management systems and expressing fatigue with the topic.
This document discusses profiling Python performance. It begins by acknowledging that Python can be slow due to the Global Interpreter Lock (GIL) and lack of a just-in-time (JIT) compiler. It then demonstrates how to profile a Python program using the pyflame tool to collect stack samples and convert them to a flamegraph for analysis. The document shows pyflame being used to profile a simple Sanic web application under load testing. It finds that pyflame has surprisingly little overhead and concludes that while Python has limitations, it is not inherently slow when profiled and optimized properly.
This study analyzed over 50 million code repositories on GitHub to evaluate the relationship between programming languages and code quality metrics like bugs, complexity, and duplication. The findings suggest that languages like Python, PHP, and Java tend to have lower code quality than languages like TypeScript, Rust, and Go as measured by several metrics. The results provide insights for both language designers and developers on how languages and practices impact code quality attributes at large scale.
This MariaDB workshop covers database concepts like tables, queries, indexes, and transactions. It discusses performance monitoring using the slow query log and tools like Percona Toolkit and Anemometer. Replication in MariaDB is explained, including traditional master-slave replication and Galera clusters. Hands-on exercises reinforce key concepts.
The document discusses open data and mining GitHub for the greater good. It defines open data as any data available under an open license. It notes that GitHub is the largest social network of IT and CS professionals and contains lots of open source code. While the data on GitHub Archive is available, it questions whether it is truly open since it requires use of Google BigQuery. The document encourages mining GitHub to help work for the greater good.
4. Проблемы все те же
• Тормоза в неизвестном месте
• Отказы
• Недостаточно быстрая работа
• Недостаточная пропускная способность
• Performance issues
• У нас есть новые *wands!
5. Немного истории
• Давным-давно великие маги
из компании Sun создали ОС Solaris
• И открыли исходный код –
так получился OpenSolaris
• Но злые подколдуи из Oracle уничтожили Sun
и наложили великое заклятие на OpenSolaris
• В наше время
• Силы добра объединились, чтобы продолжить дело, начатое Sun
6. Почему мы выбрали потомка Solaris?
• ZFS
• DTrace
• Zones
• Crossbow virtualization
7. Почему мы выбрали SmartOS?
• SmartOS бесплатна
• SmartOS делается компанией Joyent
• Применяется в Joyent как гипервизор для их облака
• Работает с флешки, целиком в памяти
• Позволяет организовать облачную инфраструктуру
• Кстати, что такое «облачная инфраструктура»
• Joyent портировали KVM из Linux в SmartOS
• And now: Manta!
9. Словарик для людей из мира Linux
• «физический том» = «vdev»
• «группа томов» = «pool»
• «раздел» = «dataset»
• «логический том» = «ZVOL»
• «RAID1» = «mirror»
• «RAID5» ~ «raidz», «raidz1»
• «RAID5» ~ «raidz2»
• «RAID7(?)» ~ «raidz3»
10. Особенности ZFS
• Умное двухуровневое кэширование:
• ARC – кэш в памяти
• L2ARC – кэш на SSD
• Запись (record) размером от 512 байт до 128 Кбайт
• ^ каждая запись имеет контрольную сумму
• Размер записи задается отдельно для каждого dataset
• Возможность сжатия записей (больше размер записи –
эффективное сжатие)
• Снэпшоты!
• Copy on Write – данные никогда не перезаписываются
11. Особенности ZFS
• Дедупликация
• Не бесплатна – требует место в оперативной памяти под таблицы
дедупликации
• zfs send/receive – чтение данных из снэпшота в stdout и наоборот
• zfs send/receive можно делать инкрементально (между двумя
последовательными снэпшотами, что позволяет организовать
подобие репликации на read-only раздел в другой локации
12. Снэпшоты
• Создание – практически бесплатно
• Я делал несколько тысяч снэпшотов на пуле (3-4 тысячи)
• Удаление – не бесплатно, может вызывать нагрузку на диск
• Снэпшоты – только для чтения
• Клоны снэпшотов – возможна запись
13. Сценарии использования снэпшотов
• Сценарий 1:
• Частые локальные бэкапы для защиты от логических сбоев
• Так нельзя защититься от физического сбоя, нужен zfs send/receive
• Сценарий 2:
• Создание однотипных окружений путем клонирования эталонного
снэпшота
• Девелоперская база в несколько десятков гигабайт – каждому
девелоперу делается свой клон эталонного снэпшота
• Уменьшает время развертывания окружений
• Экономит место на диске
14. DTrace
• Динамический фреймворк профайлинга приложений
• В том числе, позволяет профайлить ядро ОС
• Предназначен для работы в продакшне с минимальным оверхедом
• ^ Оверхед зависит от числа активных DTrace probes (датчиков)
• Язык D (не путать с языком программирования D) – скрипты
описания сессий профилирования
• Необходимо инструментировать фреймворки/библиотеки/VMs –
расстановка probes
15. Язык D
provider : module : function : name
/ predicate /
{
action
}
•Нет циклов/ветвлений
•Нет пользовательских функций
16. Пример 1 – «горячие» точки
PostgreSQL
• Задача – посмотреть, чем занят движок базы данных
• Задача имеет классическое решение – сборка сэмплов
стектрейсов через равные промежутки времени и их анализ
• Как можно собирать сэмплы?
• gdb, http://poormansprofiler.org – нужны debug symbols и
агрегация/анализ в (полу)ручном режиме
• DTrace!
• Кстати, готов поспорить, база, в основном, занята работой с
диском!
18. Пример 2 – поиск пути исполнения
• Задача – найти, как мы попали в это неуютное (функция
возвращает ошибку при (не)определенных условиях)
• Как решать без DTrace?
• Вызвать падение по SIGSEGV в месте возврата ошибки, собрать
coredump, поглядеть backtrace
• Необходима модификация и пересборка приложения
• Упасть по SIGSEGV в продакшн окружении? Нет пути!
• DTrace не требует пересборки и модификации и позволяет
получить стектрейс вплоть до вызовов ядра
19. Пример 2 – поиск пути исполнения
#!/usr/sbin/dtrace -s
pid$target::zpool_vdev_attach:entry
{
self->trace = 1;
}
pid$target:libzfs::return
/self->trace && (int)arg1 == -1/
{
ustack ();
exit(0);
}
20. Пример 2 – поиск пути исполнения
zfs_ioctl:return
libzfs.so.1`zfs_ioctl+0x2c
zpool_worker`do_zpool_attach_or_replace+0x154
zpool_worker`zpool_rpc_attach+0x9f
zpool_worker`attach_invoke+0x70
zpool_worker`rpc_invoke+0xbb
zpool_worker`rpc_server_loop+0x9d
zpool_worker`rpc_worker_main_mode+0xc9
zpool_worker`rpc_worker_main+0x20
zpool_worker`main+0x6c
zpool_worker`_start+0x83
21. Zones
• Контейнерная виртуализация или
• ОС-виртуализация
• Аналоги – OpenVZ, jails во FreeBSD
• Минимальный оверхед
• Ограничение потребления ресурсов
• ^ можно менять динамически
22. Network virtualization
• VNICs over NICs
• Virtual switching
• Link aggregation
• Routing
• NAT & IPFilter
• VLANs over VNICs
23. Manta
• Выпущена 4 месяца назад
• Объектное хранилище для
BigData
• Если гора не идет к Магомету
(integrated computing)
• Реализовано на динамически
создаваемой Zone
• Время создания зоны 9 мкс
• Обработчики на любом языке
24. Почему всего этого нет в мире Linux?
• В мире Linux своя магия
• Кроме того, CDDL несовместима с GPL
26. Кейс 1. Git in Sky. Новостной сервис
• Посещаемость около 20 тыс. уников в день
• UMI.CMS
• Жалобы на тормоза в админке,зависания до 2 минут
• Было: CentOS, dedicated, 8GbRAM, 4Gb-InnoDB pool.
• Стало: Virtual SmartOS, ZFS with ARC on SSD, 8Gb, 6Gb for
InnoDB
• DTracing time of php functions and mysql queries – удалены
ненужные JOINs в UMI ORM SQL выражениях.
• Улучшили на 30-40% время запросов. Ушли тормоза.
27. Кейс 2. Git in Sky. Маркетинговый
сервис
• Посещаемость около 100 тыс. уников в день
• LAMP-стек
• Организованы бэкапы через ZFS snapshots
• Была утеряна почта с важной коммерческой информацией
на сумму несколько миллионов рублей
• Восстановление из ZFS-snapshots по указанной дате спасло
деньги!
28. Кейс 3. Joyent & LinkedIn
• Все мобильные сервисы LinkedIn
расположены в облаке Joyent на
SmartOS.
• Balance across multiple cloud providers.
Instead of just using Amazon Web
Services, use a combination of AWS with
Joyent, Azure, Rackspace, and/or
another provider, diverting traffic to an
available cloud in the event of a failure.
29. Кейс 4. Joyent & Voxer
• Voxer делает из вашего телефона
рацию walkie-talkie.
• База пользователей выросла за месяц
в 30 раз. Linux based storage не
справился.
• DTracing Node.js apps
• DTracing процессы низкого уровня
• Улучшили производительность
• Сократили в разы время ожидания
30. Кейс 5. Joyent & Digital Chocolate
• Digital Chocolate – игровой сервис
• Galaxy Life, Millionaire City, Zombie
Lane, Army Attack, Crazy Penguin Wars,
Tower Bloxx, Rollercoaster Rush
• Затраты на инфраструктуру росли
быстрее доходов
• 50% уменьшение затрат на
инфраструктуру в SmartOS Cloud
• 99.999% cloud uptime SLA performance
31. Выводы
• Linux – это хорошо, но недостаточно хорошо
• Если выйти за пределы экосистемы Linux, можно получить новые
возможности, такие как
Возможность профилирования приложений
Расширенные возможности организации хранилища
Легкая защита от логических сбоев
Легкая, с массой новых возможностей, организация
бэкапов/восстановлений
• Новый способ работы с BigData
•
•
•
•
32. Вопросы?
• Спасибо за внимание!
• С вами были Сергей Житинский и Александр Чистяков
• sergey@gitinsky.com
• alex@gitinsky.com
• Компания Git In Sky