Динамическая аллокация ресурсов или как жить в условиях общежития? RamblerML
При помощи динамической аллокации ресурсов в Spark можно добиться того, чтобы задача получала дополнительные ресурсы, если таковые имеются в свободном пуле. Таким образом, иногда, можно использовать всю мощь кластера и быстрее проводить вычисления. В докладе я расскажу, как динамическая аллокация ресурсов помогла сделать возможной работу 30-40 студентов в условиях приближающегося дедлайна по лабораторным работам и жить всем в счастье.
CI/CD-приложений на Tarantool: от пустого репозитория — до продакшнаMail.ru Group
Константин рассказал про новый подход в структурировании и поставке приложений в Tarantool:
как управлять зависимостями (rockspec + друзья);
как писать и запускать юнит- и интеграционные тесты;
покажу превью нового тестового фреймворка для приложений;
как паковать приложения вместе с зависимостями (и почему мы выбрали статическую линковку);
как задеплоить в продакшн с systemd.
Динамическая аллокация ресурсов или как жить в условиях общежития? RamblerML
При помощи динамической аллокации ресурсов в Spark можно добиться того, чтобы задача получала дополнительные ресурсы, если таковые имеются в свободном пуле. Таким образом, иногда, можно использовать всю мощь кластера и быстрее проводить вычисления. В докладе я расскажу, как динамическая аллокация ресурсов помогла сделать возможной работу 30-40 студентов в условиях приближающегося дедлайна по лабораторным работам и жить всем в счастье.
CI/CD-приложений на Tarantool: от пустого репозитория — до продакшнаMail.ru Group
Константин рассказал про новый подход в структурировании и поставке приложений в Tarantool:
как управлять зависимостями (rockspec + друзья);
как писать и запускать юнит- и интеграционные тесты;
покажу превью нового тестового фреймворка для приложений;
как паковать приложения вместе с зависимостями (и почему мы выбрали статическую линковку);
как задеплоить в продакшн с systemd.
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
Apache Kafka and stream processing peculiarities [ru]Vsevolod Solovyov
This is a presentation about our try at an architecture "Turning the database inside out" by Martin Kleppman https://www.youtube.com/watch?v=fU9hR3kiOK0
I think it's more meaningful to watch a talk https://www.youtube.com/watch?v=d5_fbt5x9yc because the slides were created for talk, not for separate viewing
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Android Cloud... точнее Cloud из Android / Охрименко Алексей (Acronis)Ontico
Вы когда-нибудь плакали, открывая Amazon EC2 калькулятор? Мучились ли вы над тем, куда поставить сервер — на балкон или в кладовку? Готовились ли вы морально платить по 100-200 тысяч рублей за самый примитивный вариант сервера? Из этой ситуации есть выход и это — Android-планшеты :)
Как установить Linux на ваш Android-планшет, как развернуть LAMP, MEAN stack, сколько RPS могут выдать Android-планшеты, как хорошо они масштабируются, map/reduce, готовы ли Android-планшеты для production?
Все это и многое другое вы узнаете из этого доклада.
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Продуктовые проблемы при создании очередной Docker PaaS / Владимир Ярцев (Cas...Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 16:00
Тезисы:
http://rootconf.ru/2017/abstracts/2826.html
Благодаря Docker'у, контейнеры стали доступны каждому. Однако, чтобы развернуть production-систему на Docker'е, нужно решить ряд инфраструктурных задач: логи, мониторинг, бэкапы, отказоустойчивость, апдейты, безопасность. Решить эти задачи "для себя" не сложно, но при попытке превратить свое контейнерное решение в программный продукт возникают проблемы: "глупые" пользователи, нестабильный хостинг, коварные конкуренты и неясное будущее продукта. Эти трудности - системные, и лучше о них знать заранее. Я расскажу о них на примере проекта dockhero.io.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
Apache Kafka and stream processing peculiarities [ru]Vsevolod Solovyov
This is a presentation about our try at an architecture "Turning the database inside out" by Martin Kleppman https://www.youtube.com/watch?v=fU9hR3kiOK0
I think it's more meaningful to watch a talk https://www.youtube.com/watch?v=d5_fbt5x9yc because the slides were created for talk, not for separate viewing
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Android Cloud... точнее Cloud из Android / Охрименко Алексей (Acronis)Ontico
Вы когда-нибудь плакали, открывая Amazon EC2 калькулятор? Мучились ли вы над тем, куда поставить сервер — на балкон или в кладовку? Готовились ли вы морально платить по 100-200 тысяч рублей за самый примитивный вариант сервера? Из этой ситуации есть выход и это — Android-планшеты :)
Как установить Linux на ваш Android-планшет, как развернуть LAMP, MEAN stack, сколько RPS могут выдать Android-планшеты, как хорошо они масштабируются, map/reduce, готовы ли Android-планшеты для production?
Все это и многое другое вы узнаете из этого доклада.
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Продуктовые проблемы при создании очередной Docker PaaS / Владимир Ярцев (Cas...Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 16:00
Тезисы:
http://rootconf.ru/2017/abstracts/2826.html
Благодаря Docker'у, контейнеры стали доступны каждому. Однако, чтобы развернуть production-систему на Docker'е, нужно решить ряд инфраструктурных задач: логи, мониторинг, бэкапы, отказоустойчивость, апдейты, безопасность. Решить эти задачи "для себя" не сложно, но при попытке превратить свое контейнерное решение в программный продукт возникают проблемы: "глупые" пользователи, нестабильный хостинг, коварные конкуренты и неясное будущее продукта. Эти трудности - системные, и лучше о них знать заранее. Я расскажу о них на примере проекта dockhero.io.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Портирование C++ приложений на FLASCC: опыт Unreal Engine 3. Павел Наказненко...Unigine Corp.
Павел Наказненко, разработчик, freelance (Красноярск)
На основе нашего опыта портирования Unreal Engine 3 и Free Heroes 2 на Flash, расскажу немного о технологии FLASCC, а также тонкостях портирования С++ игр с помощью нее.
Rust позволяет писать быстрые и надёжные программы. Особенно когда они многопоточные. Это делает его хорошим выбором для написания серверной части разнообразных веб-приложений.
Но что для этого нужно? Зачем терпеть все эти длиннющие ошибки от borrow checker'а? Что с продуктивностью разработки? Где взять библиотеки? А что если библиотеки нет? Какой веб-фреймворк выбрать? Как отлаживать и профилировать код?
В своём докладе я отвечу на эти и другие вопросы. Ещё я расскажу, что нужно делать, чтобы обойти проблемные места, которые у Rust, конечно, тоже есть.
Всё это — на примере кода инфраструктурного сервера, обеспечивающего «всегда зелёный master» (commit gatekeeper, аналог homu и zuul).
Семинар по Node.js в КПИ 20 октября 2014. Докладчики: Тимур Шемсединов, Никита Савченко, Максим Петренко. Краткое содержание:
* Что такое Node.js и как работает JavaScript в V8
* Профессионалы расскажут, почему они выбрали Node.js
* Вы узнаете его сильные и слабые стороны и где его лучше применять
* Будет полный обзор особеностей и внутреннего строения Node.js
* Примеры внедрения и Highload-проекты
* Вопросы развертывания, хостинг, тестирования, и отладки
* Где и что учить, что читать, как осваивать
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
Пора ли отправлять С на свалку истории? Пишем демонов на PHP с использованием...Vadim Kruchkov
Вадим Крючков [Long], руководитель группы разработки, компания Agunga
Считается (в общем случае — вполне справедливо), что писать демонов на PHP — моветон. Использовать для прототипирования интерфейсов взаимодействия — можно, а вот в продакшене ни-ни. Именно с таким представлением мы начинали разработку новой версии игры — проработаем интерфейсы взаимодействия с демоном, который к запуску будет переписан на высокопроизводительном С. Однако, первые тесты демона, написанного на PHP с использованием libevent, заставили нас серьезно задуматься — а нужен ли нам переход на С? Какую производительность нам удалось достичь? Течет ли память? Обо всем этом будет рассказано в докладе. А так же - особенности использования и недокументированные возможности расширения, облегчающие рутинные операции
Пора ли отправлять С на свалку истории? Пишем демонов на PHP с использованием...
Минуты из жизни со Spark
1. Минуты из жизни с Apache Spark
Шорин Александр
Инженер-разработчик DevOps
Apache Spark Meetup / 2017-04-27
Минуты из жизни
с Apache Spark
2. Минуты из жизни с Apache Spark
• OC FreeBSD 10.2
• Apache Hadoop YARN
2.6.0
• ~65 нод
• ~10TiB memory
• ~2000 vcores
• ~1PiB data
Фантастический Spark и где он обитает
3. Минуты из жизни с Apache Spark
Ожидание: 1.6.1 → 2.0.1
Реальность: 1.6.1 → 2.1.0
Как мы обновляли Apache Spark
4. Минуты из жизни с Apache Spark
Основные поломки:
• SPARK-13594: DataFrame.map → DataFrame.rdd.map
• SPARK-16033: DataFrameWriter.partitionBy() can't be
used together with DataFrameWriter.insertInto()
Полный список: SPARK-11806
В остальном существующий код продолжает работать.
Как мы обновляли Apache Spark
5. Минуты из жизни с Apache Spark
>>> df.collect()
Traceback (most recent call last):
...
Py4JError: An error occurred while calling o79.setCallSite
Падение Spark-драйвера
7. Минуты из жизни с Apache Spark
А что случится, если драйвер упадет?
8. Минуты из жизни с Apache Spark
Тем временем в stderr:
ERROR:py4j.java_gateway:An error occurred while trying to connect to the
Java server (127.0.0.1:40083)
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/py4j/java_gateway.py", line 963,
in start
self.socket.connect((self.address, self.port))
File "/usr/local/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 61] Connection refused
Падение Spark-драйвера
9. Минуты из жизни с Apache Spark
>>> sc.stop()
Traceback (most recent call last):
...
Py4JNetworkError: An error occurred while trying to connect
to the Java server (127.0.0.1:40083)
Нельзя просто так взять
и остановить SparkContext
10. Минуты из жизни с Apache Spark
• Любые операции будут приводить к ConnectionRefused
• Попытка остановить SparkContext - ConnectionRefused
• Попытка запустить SparkContext - RuntimeError
• Безысходность, тлен и потеря
Падение Spark-драйвера
11. Минуты из жизни с Apache Spark
C 2.1.0: SPARK-18523
>>> df.collect()
Traceback (most recent call last):
...
Py4JError: An error occurred while calling o79.setCallSite
>>> sc.stop()
pyspark/context.py:386: RuntimeWarning: Unable to cleanly shutdown Spark
JVM process. It is possible that the process has crashed, been killed or may
also be in a zombie state.
RuntimeWarning
Падение Spark-драйвера [FIXED]
12. Минуты из жизни с Apache Spark
До 2.1.0:
• Инициализация SparkConf инициализировала драйвер;
• Нельзя было задать настройки драйвера без костылей
(SPARK_DRIVER_MEMORY,
PYSPARK_SUBMIT_ARGS, etc.);
С 2.1.0: SPARK-17387
>>> conf = SparkConf().set("spark.driver.memory", "4g")
>>> sc = SparkContext(conf=conf)
SparkConf и spark-submit
13. Минуты из жизни с Apache Spark
>>> rdd = sc.parallelize(range(10))
>>> rdd.toDF
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'RDD' object has no attribute 'toDF'
>>> spark0 = SparkSession(sc)
>>> rdd.toDF
<bound method RDD.toDF of ParallelCollectionRDD[0] at parallelize at
PythonRDD.scala:475>
>>> spark1 = spark0.newSession()
>>> spark1.stop() # что произойдет?
Архитектура PySpark
14. Минуты из жизни с Apache Spark
• До 2.1.0:
• Одноразовые метрики вида spark.application_*
• Как среди них находить метрики периодических задач?
• C 2.1.0:
• Появился spark.metrics.namespace SPARK-5847
• Каждая задача имеет свой понятный namespace
• Все spark.application_* отправляем в /dev/null
Мониторинг Apache Spark c Graphite
15. Минуты из жизни с Apache Spark
Мониторинг Apache Spark c Sentry
16. Минуты из жизни с Apache Spark
Что такое sentry?
• Удобный инструмент для Bug Driven Development;
• Продвинутый баг-треккер;
• Умеет группировать похожие ошибки, следить за
регрессиями;
• Разбирает трейсы и показывает из-за чего именно все
пошло не так;
Мониторинг Apache Spark c Sentry
17. Минуты из жизни с Apache Spark
Apache Spark:
• Интегрируется с log4j;
• Перехватывает все ERROR / WARNING сообщения;
• Можно отслеживать частоту ошибок и исправлять
самые критичные / массовые;
Мониторинг Apache Spark c Sentry
19. Минуты из жизни с Apache Spark
Python:
• Перехватывает исключения;
• Проходит по стектрейсу и извлекает контекст каждого;
• Можно понять из-за чего произошла ошибка и ее
исправить;
Мониторинг Apache Spark c Sentry
21. Минуты из жизни с Apache Spark
Python UDF:
• Поскольку код исполняется удаленно, нужно
прокидывать клиент Sentry в каждую функцию;
• Либо пропатчить pyspark.worker SPARK-20368;
Мониторинг Apache Spark c Sentry
22. Минуты из жизни с Apache Spark
1.Read http://spark.apache.org/contributing.html
2.Fork https://github.com/apache/spark
3.Patch && commit && push
4.Submit New Pull Request
5.…
6.PROFIT!!1
Как пропатчить Apache Spark под
FreeBSD
23. Минуты из жизни с Apache Spark
Спрашивайте свои ответы!
Спасибо за внимание!