Ceph является одной из мнообещающих архитектур для построения облачных хранилищ данных. В презентации приведены основные возможности, описана архитектура, дан краткий обзор команд CLI
Технологии хранения для больших проектов / Сергей Платонов (RAIDIX)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2990.html
Мы ежедневно сталкиваемся с тем, что даже работающие более 15 лет в индустрии специалисты, путаются в понятиях и преимуществах и недостатках тех или иных архитектур больших СХД.
В своем докладе мы расскажем о разнице между distributed (распределенными), shared (общими) и параллельными файловыми системами, покажем, в каких задачах Scale In-системы превосходят Scale Out и наоборот.
...
Как и зачем создавать NginX-модуль — теория, практика, профит. Часть 2 / Васи...Ontico
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2940.html
Почти год назад я выступил с докладом 'Как и зачем создавать NginX-модуль - теория, практика, профит'. У меня не получилось рассказать обо всех возможностях Nginx и, уверяю вас, в этом докладе у меня это тоже не получится - тема слишком большая!
Сразу перейдем к делу. "Так что нового будет в этом докладе?" - спросите вы. В нем будут ответы на вопросы, на которые я не успел ответить в прошлом году, а именно:
- Как и зачем создавать upstream-модули?
...
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
Ceph является одной из мнообещающих архитектур для построения облачных хранилищ данных. В презентации приведены основные возможности, описана архитектура, дан краткий обзор команд CLI
Технологии хранения для больших проектов / Сергей Платонов (RAIDIX)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2990.html
Мы ежедневно сталкиваемся с тем, что даже работающие более 15 лет в индустрии специалисты, путаются в понятиях и преимуществах и недостатках тех или иных архитектур больших СХД.
В своем докладе мы расскажем о разнице между distributed (распределенными), shared (общими) и параллельными файловыми системами, покажем, в каких задачах Scale In-системы превосходят Scale Out и наоборот.
...
Как и зачем создавать NginX-модуль — теория, практика, профит. Часть 2 / Васи...Ontico
HighLoad++ 2017
Зал Дели + Калькутта, 7 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2940.html
Почти год назад я выступил с докладом 'Как и зачем создавать NginX-модуль - теория, практика, профит'. У меня не получилось рассказать обо всех возможностях Nginx и, уверяю вас, в этом докладе у меня это тоже не получится - тема слишком большая!
Сразу перейдем к делу. "Так что нового будет в этом докладе?" - спросите вы. В нем будут ответы на вопросы, на которые я не успел ответить в прошлом году, а именно:
- Как и зачем создавать upstream-модули?
...
HDD, SSD, RAM, RAID, и кого на ком кэшировать / Михаил Конюхов (Perfect Solut...Ontico
Рассуждение, опыт, практика и примеры на тему производительности ввода-вывода.
Мы будем сравнивать "дефолтное" поведение SSD и HDD, сравним "недефолтное" поведение после тюнинга HDD. Я расскажу о плюсах и минусах в надежности HDD и SSD, о проблемах восстановления SSD и HDD после сбоев. Многие моменты будут посвящены кэшированию ввода-вывода, что очень помогает в реальных проектах.
Отдельная тема - оптимизация ФС и сервера для снижения количества операций ввода-вывода (IOPS), попробую оценить, что можно сделать с каким-нибудь проектом-примером.
Будут показаны и рассказаны реальные примеры из моего опыта оптимизации IO, я даже нарисую "карту принятия решения" для выбора накопителей для Вашего проекта.
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Погружение в виртуальную память и большие страницы / Константин Новаковский (...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 12:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2688.html
Современные приложения часто используют большое количество памяти, ещё чаще разработчики не задумываются, как именно приложение работает с памятью, и откуда она берётся. Просим ядро дать кусок памяти и начинаем с ним что-то делать... Но что за память нам выделяет ядро операционной системы? Память на самом деле виртуальная и делится на единицы, называемые страницами. Страницы бывают маленькими, бывают большими и очень большими.
...
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
Защита датацентров и данных от катастроф на базе технологий Nutanix / Максим ...Ontico
* RTO - Recovery Time Objective - максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ
RPO - Recovery Point Objective - максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
* Стратегии защиты и репликации ДЦ (1 to 1, 1 to many, many to many).
далее см. - http://rootconf.ru/2015/abstracts/1817
Андрей Николаенко, IBS. NVMf: 5 млн IOPS по сети своими рукамиIBS
Андрей Николаенко, системный архитектор в IBS, выступил на конференции HighLoad++ 2016.
Тезисы
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Погружение в виртуальную память и большие страницы / Константин Новаковский (...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 12:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2688.html
Современные приложения часто используют большое количество памяти, ещё чаще разработчики не задумываются, как именно приложение работает с памятью, и откуда она берётся. Просим ядро дать кусок памяти и начинаем с ним что-то делать... Но что за память нам выделяет ядро операционной системы? Память на самом деле виртуальная и делится на единицы, называемые страницами. Страницы бывают маленькими, бывают большими и очень большими.
...
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...Ontico
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
Защита датацентров и данных от катастроф на базе технологий Nutanix / Максим ...Ontico
* RTO - Recovery Time Objective - максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ
RPO - Recovery Point Objective - максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные.
* Стратегии защиты и репликации ДЦ (1 to 1, 1 to many, many to many).
далее см. - http://rootconf.ru/2015/abstracts/1817
Андрей Николаенко, IBS. NVMf: 5 млн IOPS по сети своими рукамиIBS
Андрей Николаенко, системный архитектор в IBS, выступил на конференции HighLoad++ 2016.
Тезисы
В выпуске 4.8 ядра Linux появилась поддержка NVMf (NVM Express over Fabrics) — стандартизованной возможности присоединять по сети как блочные устройства твердотельные накопители, установленные в разъёмы PCI Express. NVMf лишён многих недостатков iSCSI, повторяющего по сети SCSI-команды со всеми их издержками времён дисковых накопителей, и главное — позволяет по полной использовать возможности сетей с прямым доступом к оперативной памяти (RDMA). Таким образом, можно под управлением одного узла собрать сверхбыстрый и сверхотзывчивый пул блочных устройств, не прибегая к покупке дорогого флэш-массива. Но как воспользоваться этим пулом, не загубив теоретические показатели программными обёртками?
В докладе будут рассмотрены варианты применения NVMf для различных конфигураций PostgreSQL, Oracle Database, Hadoop, файловых хранилищ, о разработках в направлении «программно-определяемой памяти» с применением NVMe-устройств, доступных по сети, обсуждены текущие проблемы, ограничения и перспективы. Особое внимание будет уделено практическим способам измерения производительности ввода-вывода с учётом задачи, решаемой подсистемой хранения.
Обзор архитектуры и подсистем деплоя и мониторинга.
Как инженеры делают систему прозрачной для разработки.
1) Схема организации репозитория puppet.
Зачем мы сделали репозиторий публичным внутри компании?
Как мы "делим" puppet, и что делать, если все "пропало"?
Собственная реализация механизма puppet kick.
2) Как рассказать всем обо всем и никого не потерять.
"Черный мониторинг" (rbmon). Как мы собираем информацию о серверах и демонах.
Делимся логами с разработчиками. Почему написали "велосипед"?
3) Graphite - система сбора и визуализации данных.
Почему graphite?
1М метрик в минуту?
Какие метрики мы рисуем (nginx-graphite-module, rbmon plugins).
Визуализация работы проекта (Dashboard пульт).
«Agile-тестирование по версии API 2ГИС» — Анастасия Огаркова, 2ГИСDevDay
В свое время, когда мы только запускали API, всё было скромно: небольшая команда, комфортные требования, да и бизнес не требовал от нас подвигов. Но всё коренным образом изменилось, когда API разрослось до 30 серверных компонент в трёх датацентрах, а бизнес «порекомендовал» успевать с ответом в 200 мс и выкатывать релизы раз в неделю. На фоне роста проекта, росла команда и остро встали вопросы «как экологично встроить тестирование в большую scrum-команду большого проекта».
Мы сфокусировались на трёх важных моментах:
Планирование
Большая команда → «большое» планирование. Тестирование планируется отдельно или вместе с разработчиками? Нужна ли выделенная роль крайнего за тестирование на проекте?
Релиз
Нужен ли крайний за релиз и кто отвечает за интеграционные зависимости? Когда надо остановиться и заморозить фичи? Кто и как мониторит продукт после релиза?
Автоматизация — наше всё ;)
Как не «захлебнуться» в регрессии: unit-тесты, json-схема. Как правильно выбрать фичи для автоматизации и как встроить автоматизацию в процесс тестирования.
Порой в погоне за созданием очередной классной штуки для продукта мы забываем о том, как будем выводить это на рынок. В идеальном мире задумываться о запуске мы должны еще до того, как задумались о фиче, ведь именно через потребность аудитории стоит проектировать функционал.
Что делать, если на дворе 2013 год, а вам предстоит запускать поиск проезда на общественном транспорте? Алгоритмы вашего поиска не являются революционными, да и все это уже давно реализовано у конкурентов. Как сместить акценты 4 миллионов пользователей и сделать так, чтобы они оценили ваши старания?
Мы нашли неплохое решение. Хочу рассказать, как это получилось — от подготовки концепции запуска и мотивации команды до самого процесса релиза и работы с обратной связью. Факапы, выводы, рекомендации. Максимально честно, на живых примерах.
Поговорим, как и зачем функционально тестировать хайлоад, получать от тестов больше, чем «прошёл/не прошёл», а их количество превратить в качество продукта.
SQL-ник DevDay. Рубцов. Новое в Percona Server и MariaDB в сравнении с MySQL 5.5DevDay
Григорий Рубцов — руководитель проектов SQLinfo.ru (http://sqlinfo.ru/) и Webew.ru (http://webew.ru/), автор онлайн-курса по MySQL (http://sqlinfo.ru/classes/) и спикер конференции РИТ++.
Новое в Percona Server и MariaDB в сравнении с MySQL 5.5
Обзор возможностей:
— новое для разработчика;
— новое для администратора;
— улучшения производительности;
— миграция и вопросы совместимости.
Технические детали:
— хранилище XtraDB;
— Percona Tools;
— алгоритмы оптимизации подзапросов в MariaDB.
Манипулятор на Ti Stellaris Launchpad, Лёша РоманенкоDevDay
За последние несколько десятков лет робототехника стала очень доступной. Настолько, что можно собрать робота и запрограммировать его даже в домашних условиях, имея подходящий инструментарий. С чего начать? Как попробовать? Именно об этом мы и поговорим на докладе на примере контроллера TI Stellaris Launchpad (аналог Arduino), управляемого с Android-смартфона.
«Роль исследований в формировании продуктового видения компании», Лиза Алексе...DevDay
В своем докладе я расскажу о постановке цели и подготовительном этапе при проведении продуктовых исследований. Мы рассмотрим наиболее популярные виды исследований. Специфику исследований на локальном и междунароных рынках. Прикладную ценность результатов исследований. И это всё на примерах продуктов компании 2ГИС.
Артём Кудзев «Делайте на работе то, что мотивирует»DevDay
Слышали же такое «в другой компании база более реляционнее, процессы более гибкие и тимлид встречает с кофе каждое утро»? В общем, рай для айтишника. Мы в свое время столкнулись с этой проблемой, когда нас стало достаточно много и «2ГИС перестал быть тортом». Я расскажу, что мы придумали, чтобы ребята не теряли мотивацию и увлечённо работали. Поговорим о фича и продакт-командах, «своих» проектах, опенсорсе и внутренних тусовках.
Инструкция по созданию самопального биллинга, Михаил Крестьянинов (Новотелеком)DevDay
В ходе своего доклада я хочу показать пару фокусов и попытаться ответить на следующие вопросы:
- Что такое Enterprise разработка?
- Зачем нужны бизнес-процессы и как их автоматизировать?
- Какие существуют платформы для построения корпоративных приложений?
- В чём особенности архитектуры промышленных приложений?
- Какую БД выбрать для вашего приложения?
- Как быть с тестированием и деплойментом?
- Что делать с нагрузками, и какие могут быть проблемы в корпоративных приложениях?
- Как сделать так, чтобы всё работало и никогда не ломалось?
Матвей Мальков «Ещё один поиск контактов на Android»DevDay
Многие дайлеры не умеют делать поиск по Т9 клавиатуре. Те, что умеют, в большинстве своем делают поиск только по имени/фамилии контакта или по началу номера, а кто-то только с использованием английского алфавита. В 2GIS Dialer нам хотелось искать все контакты по имени, фамилии, телефону (любому из списка и с любого символа), а так же по должности и месту работу (опционально: e-mail и вебсайт, адрес и группы контактов). Кроме того, нам хотелось, чтобы пользователь на любом языке мог найти свои контакты. И в завершение необходимо было, чтобы весь этот поиск работал быстро. О том, как мы добились прогресса в этом деле я и расскажу.
Рендеринг может больше: vue.js vs React, Андрей СолодовниковDevDay
О том, как перестать вручную контролировать DOM, писать логику навигаций и почему DOM-шаблонизация — это классно, а так же немного самокритики и сравнительных тест-кейсов.
Тимофей Чаптыков «Верстальщик должен быть ленивый»DevDay
Большую часть рабочего времени мы занимаемся не написанием новой функциональности, а тестированием, исправлением ошибок, рефакторингом. При этом писать классные фичи всем нравится гораздо больше, чем искать причину очередного хитроумного бага. Как сделать так, чтобы ошибок стало меньше, и мы могли тратить время на то, что доставляет удовольствие?
Вебинар «Дедупликация vs Hеконтролируемый рост данных»
Подробнее о мероприятии http://www.croc.ru/action/detail/5668/
Презентация Дмитрия Дощаного, директора центра решений КРОК на базе технологий EMC
Maksym Bezuglyi "Universal highload patterns on a specific example of a game ...Fwdays
Analysis of the architecture of the game server on Haskell. From a high-level model to code features - transactional memory, immutable data structures, actors, queues, parallel and concurrent computing. The model of dynamic scaling, optimization, solved problems and trade-offs.
Reasons for choosing Haskell
What technologies were considered and why they were not used (no spoilers)
Full stack of used technologies and their highload potential
Universal design patterns
Open source субд глазами обычного программистаSlach
Попытался "быстренько" пробежаться по всем СУБД с которыми работал за 20 лет и постараться вложить слушателям мысль что СУБД надо выбирать под нагрузку
и что для СУБД надо знать "алгоритмы" и "эксплуатацию"
В докладе — гибкая система кэширования, обмен промежуточными данными в процессе сборки, разбиение технологий на более мелкие, субпроцессы для технологий и многое другое.
Компания "Ленвендо" занимается созданием, развитием и поддержкой крупномасштабных онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Эхо Москвы в Петербурге.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление ок...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление окружениями в сложном проекте: Chef и другие", Александр Чистяков (ведущий разработчик Cezurity).
Аннотация
Облачный антивирус, который мы делаем в партнерстве с vk.com, отличается от типичного веб-проекта наличием большого числа специализированных и не очень специализированных подсистем. Это ставит перед отделом эксплуатации принципиально новые вызовы: нужно не только уметь реагировать на случайные сбои и предсказывать неслучайные, но и просто помнить где что лежит и какую задачу выполняет. О том, как мы отвечаем на эти вызовы в компании Cezurity - мой доклад.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Similar to Распределенное хранилище Ceph. Обзор и практические способы использования (20)
Фреймворк Slot, Good Parts, Александр БирюковDevDay
Расскажу о ключевых особенностях продукта: о какой изоморфности идёт речь, как мы управляем состоянием SinglePage-приложения и какой профит для SEO извлекли, с примерами кода. Посмотрим как быстро начать свой проект на Slot.
Devops-практики в разработке решений для бизнеса, Максим ПашукDevDay
Обычно разработчик успокаивается как только написан код, решающий задачи бизнеса. На самом деле есть ещё целый ряд вопросов, которые также необходимо решать.
Как донести изменения разработчика до тестирования в согласованном виде (база данных, приложение, конфиги)? Как донести эти же изменения до production и ничего не потерять по дороге? Что делать если продукт — распределённая многокомпонентная система, работающая в отказоустойчивом кластере? Тогда ситуация требует тесной совместной работы разработчиков и администраторов, а это, как известно, люди немного с разных планет.
Я расскажу на примере конкретного проекта на .NET стеке, как мы построили мост дружбы. Как свели воедино систему сборки, развёртывания и автоматизации, используя библиотеку psake и достигли взаимопонимания.
Inversion of Control в деталях, Дмитрий КожевниковDevDay
Казалось бы всё сказано об инверсии управления, особенно в .NET. Но нетривиальные квесты вокруг дизайна, построенного на DI, продолжают возникать из проекта в проект. Предлагаю поговорить немного о прописных истинах, а потом перейти к более любопытным вещам и болезненным вопросам.
Чем плох ServiceLocator? Почему IoC-контейнер — это фреймворк, а не библиотека? Как быть с множественными реализациями? Convention over configuration?
Отдельно поговорим об архитектуре enterprise решений в свете возможностей IoC-контейнеров.
Год от года многие программисты решают одни и те же задачи, но не всегда среди огромного многообразия решений можно найти что-то подходящее. Вот и мы не смогли найти ни одной библиотеки логирования для C++, которая удовлетворяла бы всем нашим требованиям. Теперь у нас есть свой велосипед, и мы расскажем, чем он лучше других.
Все мы привыкли писать программы, результаты работы которых можно увидеть и услышать. Хотите, чтобы их можно было ещё и потрогать? На примере создания электронной игры «Лабиринт» вы увидите, как не имея знаний и опыта сделать первый шаг в мир hardware.
Расскажу про первый продукт 2ГИС, который не совсем про организации – 2GIS Dialer. О трудностях создания, и почему их не нужно бояться. Делая что-то новое, вы обязательно с ними столкнетесь:
— Команда будет меняться.
— Конкуренты будут поджимать и опережать.
— Промо-кампании не будут стрелять.
«Бегущий по лезвию. Продуктовые сценарии в дизайне», Макс Карпылев DevDay
С чего начинается проектирование и дизайн новых продуктов — со сценариев. Продуктовые сценарии работы — ключевой элемент в пазле проектирования новых взаимодействий. В докладе покажу какое место сценарии занимают в 2ГИСе, почему они важны и какие сценарии бывают.
Олег Годовых «Страх и ненависть в Event Bus»DevDay
У нас было 500 страниц спецификаций, 40000 строк кода, 2 офиса, полдюжины разработчиков, а также целое множество андроидов всех сортов и расцветок. Не то, чтобы это был необходимый запас для приложения крупной торговой сети. Но если начал собирать софт, становится трудно остановиться. Единственное, что вызвало у меня опасение — это сетевая библиотека. Нет ничего более беспомощного, безответственного и испорченного, чем писать AsyncTask на каждый вызов. Я знал, что рано или поздно мы перейдём на Event Bus.
Распределенные приложения и Azure Service BusDevDay
Когда приложения перестают быть монолитными и разделяются на подсистемы, возникает много нюансов. Как спроектировать распределенную систему так, чтобы она оставалась управляемой? Как добиться того, чтобы процессы, в которых задействованы несколько подсистем, остаавалить прозрачными, а данные - согласованными? Какие принципы, технологии и инструменты могут нам помочь? Я расскажу о том, какие задачи мы решаем в одном из внутренних проектов 2ГИС, и почему мы остановились на Azure Service Bus как на инструменте обеспечения взаимодействия подсистем приложения.
Современный веб становится интерактивнее. Сейчас практически все браузеры поддерживают такую технологию как WebSocket, но современные веб-фремймоворки, такие как Django, Yii или RubyOnRails, не поддерживают работу с ними. Я расскажу, как мы сделали наши приложения интерактивным с использованием Erlang. А также что такое Erlang. Для чего он нужен.
Роман Акинфеев «Разработка RESTful API with all bells and whistles»DevDay
Каждый уважающий себя интернет-сервис, ориентированный больше чем на одну платформу, сегодня имеет RESTful API. Но мало кто понимает что такое REST, с чем его едят, как готовят и чем он полезен для здоровья. Кто-то считает, что RESTful API - это API использующее в качестве транспорта протокол HTTP, кто-то думает, что REST - это стандарт в рамках которого разработчики ограничены набором ресурсов и восьмью операциями над ними. Я расскажу о том как мы в Яндекс.Диске понимаем REST, как его готовим и какую пользу он нам приносит.
Александр Щепановский «Почему каждому языку нужен свой _»DevDay
Такие библиотеки как funcy и underscore часто связывают с функциональным программированием, но настоящий их фокус - это практичность. Задача их - упростить манипулирование данными, коллекциями, функциями и даже потоком управления, а также абстрагировать часто встречащиеся полезные поведения. В своём докладе я приведу жизненные примеры использования всего этого, а также расскажу об идеях заложенных в и продвигаемых funcy.
3. Что важно?
- Масштабирование
* ТБ, ПТ, ББ
* гетерогенность среды
* отказоустойчивость
* простота и надежность
- Гибкость
* объекты
* блочные устройства
* файловая система?
* структуры данных
- Дешевизна
* no vendor-lock
* низкая стоимость Гб
* администрирование
* отказоустойчивость
4. Время и деньги
ВРЕМЯ
- легкость управления
- миграция
- балансировка
- масштабирование
ДЕНЬГИ
- гигабайт мало стоит
- софт, а не железо
- гетерогенность
- опенсорс!
низкий порог вхождения админа
6. CEPH
- объекты большие
* и маленькие
- блочные устройства
- файлы
Монитор ceph-mon
Хранилище ceph-osd
Метадата (не нужна) ceph-mds
AmazonS3 like RADOS-GW
7. CEPH?
- Реплицируем N раз
- Балансируем
- Мигрируем
- Восстанавливаемся
Автоматически!
Скорость сопоставима
с обычными дисками!
8. CRUSH Это дерево!
Алгоритм зависит от железа.
- быстрый,
- псевдорандомный,
- настраиваемый.
- Математика. Сложная!
Восстановление
- параллельно
- many2many
- нет hotspare
9. RADOS GW - RESTful
- object=key
- атомарно
- идемпотентно
- права доступа
- балансировка
11. Утилиты
Client-tools
- ceph
API
- python boto
- java
- C*
-
Block-device
- rbd + kernel module
- kvm, qemu, libvirt
- все как обычно
- почти
RADOS
- apache2
AmazonS3 & Openstack
12. CEPH и мы
- фламп и фоточки. Планета?
- хранилище “медленных” бекапов
- shared KVM
- разделяемый контент
- дропбокс
- ???
13. Аналоги - shared file systems
- vendor solutions
- на колене
- elliptics yandex
- Amazons3
- Openstack
Не совсем!
14. Статус проекта
- 12 разработчиков
- инвестиции
- ежедневные коммиты
- мне кажется, у них забрали паспорта!
15. Недостатки тоже есть!
- сыровато
- мало функционала
- необходимо четко планировать инфраструктуру
- ???
16. В планах
- гео-кластер
* мастер, зоны, бекапы, все как у больших дядей
- скорость и стабильность еще выше.
- lock-manager over RBD
- там столько всего наполеоновского!
