ведение в систему управления пулом ресурсов Mesos и ее использование для создания масштабируемых приложений с помощью фреймворков Marathon, Chronos, Singularity
Зачем нужны постпроцессоры при живых препроцессорах — Алексей Иванов, JetStyleYandex
Препроцессором сейчас уже никого не удивишь. С их помощью упрощается синтаксис css, добавляются переменные, условия и циклы. Все это хорошо и замечательно, но часто — не достаточно. Препроцессоры не дадут изменить уже существующий css, который вы получаете из внешних источников, не перепишут ссылки на картинки и шрифты при перемещении файлов в новую папку, не отсортируют css-свойства в нужном вам порядке и не удалят из файлов лишние правила. Во всех этих случаях, а также во многих других вам помогут постпроцессоры.
В своем докладе я расскажу, что такое постпроцессоры, какие они бывают и чем отличаются друг от друга. Объясню почему использовать их лучше, чем править css вручную и с помощью регулярных выражений, а также приведу примеры их использования в ежедневной работе.
Зачем нужны постпроцессоры при живых препроцессорах — Алексей Иванов, JetStyleYandex
Препроцессором сейчас уже никого не удивишь. С их помощью упрощается синтаксис css, добавляются переменные, условия и циклы. Все это хорошо и замечательно, но часто — не достаточно. Препроцессоры не дадут изменить уже существующий css, который вы получаете из внешних источников, не перепишут ссылки на картинки и шрифты при перемещении файлов в новую папку, не отсортируют css-свойства в нужном вам порядке и не удалят из файлов лишние правила. Во всех этих случаях, а также во многих других вам помогут постпроцессоры.
В своем докладе я расскажу, что такое постпроцессоры, какие они бывают и чем отличаются друг от друга. Объясню почему использовать их лучше, чем править css вручную и с помощью регулярных выражений, а также приведу примеры их использования в ежедневной работе.
Вячеслав Олиянчук — Яндекс.Авто 2.0 на Node.jsYandex
В докладе рассказывается о том, как наша команда запускала проект Авто 2.0 на Node.js. Обсуждаются проблемы деплоя, архитектура сервиса и некоторые особенности в Node.js, которые удалось обойти в процессе эксплуатации.
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Мы в Avito уже более года используем Kubernetes в качестве платформы для микросервисов.
За это время мы столкнулись с рядом проблем, с которыми может столкнуться каждый, кто использует эту платформу.
В докладе поделюсь опытом решения проблем и настройки кластера для обеспечения его эффективной работы.
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)Ontico
В MySQL 5.7 появился целый ряд новых возможностей, позволяющих использовать MySQL в приложениях и как хранилище JSON-документов, и как реляционную базу данных.
В этом докладе мы расскажем о поддержке JSON в MySQL 5.7, а также поговорим о том, когда имеет смысл её использовать, и насколько хорошо она работает. Кроме того, мы остановимся на новом протоколе доступа к MySQL, поддерживающем SQL. Помимо этого, мы рассмотрим CRUD-операции и такие дополнительные функции, как асинхронная коммуникация и пайплайнинг (pipelining).
В заключительной части доклада мы расскажем о возможностях MySQL 5.7 в качестве хранилища документов.
Чему мы научились разрабатывая микросервисы?Vadim Madison
Доклад с конференции Backend Conf 2016
Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.
Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.
В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.
Расскажу, какие тулзы мы в итоге используем, а от каких отказались.
Оптимизации уровня CPU, Андрей Акиньшин (JetBrains)Ontico
В современном мире многие разработчики перестали стараться писать высокопроизводительный код. Порой их можно понять: в наше время прекрасных облачных решений дешевле докупить дополнительных серверов, чем тратить время на оптимизацию кода. Но что, если у вас нет такой возможности? Что, если для текущей задачи вы ограничены одной машиной или даже одним потоком?
В этом докладе мы обсудим некоторые подходы, которые помогают выжимать максимум производительности из современного железа и позволяют разгонять программы, которые, казалось бы, разогнать нельзя. В числе прочего будем обсуждать следующие вещи: CPU cache, Instruction Level Parallelism, False sharing, Branch Prediction, SEE/AVX instructions и т.д.
SETCON'18 - Vitali Fokin - Kubernetes 101Nadzeya Pus
Обзор возможностей Kubernetes, зачем он нужен, кому и когда, а также немного хороших практик по развертыванию и разработке Kubernetes-powered приложений.
Вячеслав Олиянчук — Яндекс.Авто 2.0 на Node.jsYandex
В докладе рассказывается о том, как наша команда запускала проект Авто 2.0 на Node.js. Обсуждаются проблемы деплоя, архитектура сервиса и некоторые особенности в Node.js, которые удалось обойти в процессе эксплуатации.
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Мы в Avito уже более года используем Kubernetes в качестве платформы для микросервисов.
За это время мы столкнулись с рядом проблем, с которыми может столкнуться каждый, кто использует эту платформу.
В докладе поделюсь опытом решения проблем и настройки кластера для обеспечения его эффективной работы.
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)Ontico
В MySQL 5.7 появился целый ряд новых возможностей, позволяющих использовать MySQL в приложениях и как хранилище JSON-документов, и как реляционную базу данных.
В этом докладе мы расскажем о поддержке JSON в MySQL 5.7, а также поговорим о том, когда имеет смысл её использовать, и насколько хорошо она работает. Кроме того, мы остановимся на новом протоколе доступа к MySQL, поддерживающем SQL. Помимо этого, мы рассмотрим CRUD-операции и такие дополнительные функции, как асинхронная коммуникация и пайплайнинг (pipelining).
В заключительной части доклада мы расскажем о возможностях MySQL 5.7 в качестве хранилища документов.
Чему мы научились разрабатывая микросервисы?Vadim Madison
Доклад с конференции Backend Conf 2016
Начав разработку нового продукта через микросервисы, мы неожиданно для себя обнаружили, что микросервисы — это не просто "вместо одного большого приложения теперь пишем много маленьких". При разработке большой системы она сама собой через какое-то время становится набором отдельных сервисов, которые должны взаимодействовать между собой, поэтому стабильная работа сервисов и их взаимодействие не стало чем-то новым. Неожиданностью стало то, что система стала значительно более динамической, она стала постоянно изменяться отдельными небольшими частями, сервисы стали часто перезапускаться, а количество запущенных нод сервисов стало расти по экспоненте.
Очень быстро стал актуальным вопрос конфигурирования — если раньше, выкатив новую версию монолита с единым конфигом, мы применяли правки на всю систему сразу, то с микросервисами все сложнее — пара сотен работающих нод и всем нужно применить изменения. Требования к деплою также поменялись — он стал частью процесса разработки, а тестирование стало частью деплоя. Количество необходимого ПО для функционирования системы также стало некоторым сюрпризом.
В докладе я расскажу о том, как в итоге это работает у нас, как мы решили такие вопросы как:
- конфигурирование сервисов;
- интеграция между собой;
- тестирование;
- версионирование;
- масштабирование.
Расскажу, какие тулзы мы в итоге используем, а от каких отказались.
Оптимизации уровня CPU, Андрей Акиньшин (JetBrains)Ontico
В современном мире многие разработчики перестали стараться писать высокопроизводительный код. Порой их можно понять: в наше время прекрасных облачных решений дешевле докупить дополнительных серверов, чем тратить время на оптимизацию кода. Но что, если у вас нет такой возможности? Что, если для текущей задачи вы ограничены одной машиной или даже одним потоком?
В этом докладе мы обсудим некоторые подходы, которые помогают выжимать максимум производительности из современного железа и позволяют разгонять программы, которые, казалось бы, разогнать нельзя. В числе прочего будем обсуждать следующие вещи: CPU cache, Instruction Level Parallelism, False sharing, Branch Prediction, SEE/AVX instructions и т.д.
SETCON'18 - Vitali Fokin - Kubernetes 101Nadzeya Pus
Обзор возможностей Kubernetes, зачем он нужен, кому и когда, а также немного хороших практик по развертыванию и разработке Kubernetes-powered приложений.
Сейчас контейнеризация и Kubernetes в частности — стандарт де-факто для запуска приложений «в бою». И запустить-то приложение в «кубе» несложно, но как всегда есть нюанс и не один. Обсудим, что нужно разработчику и админу учесть и сделать для того, чтобы приложение работало быстро и надёжно, не требуя к себе особого внимания. Например, посмотрим, как работают requests и limits на ресурсы, чем должны отличаться liveness и readiness пробы, и на что следует обращать внимание в мониторинге и так далее.
Evolution of web-project requires scalable architecture and scalable development process. In my presentation (in Russian): different techniques, how to achieve this if talking about Perl-based web project.
Solit 2013, Разработка приложений в облаке на примере Amazon Web Services, Сл...solit
Слисенко Константин, Минск. Компания JazzTeam, Senior Software Engineer (R&D), Java/Agile Coach
«Разработка приложений в облаке на примере Amazon Web Services». Development секция. Для разработчиков.
«JVM изнутри: оптимизация и профилирование». Development секция. Для разработчиков.
Презентация технологии веб-кластеров
Основные задачи, которые решает веб-кластер:
Обеспечение высокой доступности сервиса (так называемые HA - High Availability или Failover кластеры)
Масштабирование веб-проекта в условиях возрастающей нагрузки (HP - High Performance кластеры)
Балансирование нагрузки, трафика, данных между несколькими серверами
Создание целостной резервной копии данных для MySQL
Семинар по Node.js в КПИ 20 октября 2014. Докладчики: Тимур Шемсединов, Никита Савченко, Максим Петренко. Краткое содержание:
* Что такое Node.js и как работает JavaScript в V8
* Профессионалы расскажут, почему они выбрали Node.js
* Вы узнаете его сильные и слабые стороны и где его лучше применять
* Будет полный обзор особеностей и внутреннего строения Node.js
* Примеры внедрения и Highload-проекты
* Вопросы развертывания, хостинг, тестирования, и отладки
* Где и что учить, что читать, как осваивать
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.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Готовые решения Cisco для построения «частного облака»Cisco Russia
Что делать с рутинными операциями над инфраструктурой ЦОД, которые администраторам инфраструктуры приходится выполнять чаще чем один раз в три месяца? Ответ простой – автоматизировать при помощи IaaS-платформы. Что делать с такими же рутинными операциями, которые администраторы приложений вынуждены в свою очередь снова и снова повторять на элементах инфраструктуры, подготовленных с нуля их коллегами "инфраструктурщиками"? Ответ такой же простой – автоматизировать при помощи PaaS платформы. В презентации речь пойдет о готовом решении Cisco, которое позволяет реализовать IaaS и PaaS сценарии автоматизации при помощи продуктов Cisco UCS Director (UCS-D) и Cisco Prime Service Catalog (PSC). Изюминкой готового решения является механизм изящной и бесшовной интеграции между IaaS (UCS-D) и PaaS (PSC) платформами Cisco, которая драматически упрощает процесс развертывания и сокращает затраты на внедрение и адаптацию.
1. Масштабирование
сервисов с помощью
Apache Mesos
Введение в систему управления пулом ресурсов Mesos и ее
использование для создания масштабируемых приложений с помощью
фреймворков Marathon, Chronos, Singularity
Автор: Иван А. Кудрявцев
mailto: kudryavtsev_ia@bw-sw.com
www: http://bw-sw.com/
2. В чем проблема
1. Как осуществить “запуск множества экземпляров сервиса на
выделенных серверах”?
2. Как управлять запущенными экземплярами (останавливать,
масштабировать, перезапускать, удалять)?
3. Источники проблемы (1)
1. Горизонтально масштабируемые сервисы
a. две единицы обычного серверного оборудования с 2мя процессорами дешевле чем
1 единица с 4мя:
i. Supermicro 4xXeon E7530 / 256 GB RAM = 927 000
ii. Supermicro 2xE5-2603v3 / 128 GB RAM = 220 000
iii. Supermicro 1xE3-1231v3 / 32 GB RAM = 131 000
b. 10 серверов Supermicro дешевле чем 5 серверов HP при равной мощности (STSS.ru):
i. HP ProLiant DL60 Gen9 2xE5-2603v3 / 128 GB RAM = 425 000
ii. Supermicro 2xE5-2603v3 / 128 GB RAM = 220 000
Тренд: построение систем за счет избыточного масштабирования на обычных
компонентах
4. Источники проблемы (2)
1. Архитектура, основанная на микросервисах
дизайн подразумевает запуск и контроль множества разнородных
сервисов и организацию взаимодействия между ними с
использованием открытых интерфейсов
2. Широкое изменение рабочей нагрузки на сервис в течение дня:
a. ядро сервиса на собственной инфраструктуре
b. арендованная инфраструктура (Cloud) по запросу (автоматизированное
подключение и отключение мощностей внешних поставщиков по API)
5. Проблемы управления инфраструктурой
1. Добавление и удаление новых ресурсов инфраструктуры
2. Аккаунтинг использования ресурсов
3. Планирование использования ресурсов
4. Справедливое распределение ресурсов между задачами
5. Мониторинг задач и обеспечение их работоспособности
6. Обнаружение в комплексных сервисах (Discovery)
7. Обеспечение безопасности и множественного доступа к пулу
ресурсов
6. Методы управления инфраструктурой
1. Управление вычислительными узлами
a. IPMI (IaaS) - включение и отключение аппаратных узлов
b. Amazon EC2 API (IaaS) - выделение и освобождение виртуальных машин в Amazon
c. Openstack/Cloudstack API - выделение и освобождение виртуальных машин в частных и
публичных облаках (например, Rackspace)
2. Управление конфигурациями
a. Chef
b. Puppet
c. Ansible
3. Управление пулом процессоров и памяти:
a. Apache Mesos (generic resource planner) - mature
b. Hadoop YARN (batch resource planner) - mature
c. Docker Swarm (docker specific) - rookie
7. Apache Mesos: экосистема
1. Apache Zookeeper: 1-N шт (DLM, конфигурация).
2. Apache Mesos Master: 1 - M шт (управление планированием ресурсов)
3. Apache Mesos Slave: M+ (агент на узле исполнения)
4. Каркасы Mesos: Marathon, Chronos, Singularity, etc.
a. http://mesos.apache.org/documentation/latest/mesos-frameworks/
8.
9. Marathon Framework
● Каркас для запуска и управления долгоживущими процессами в
Mesos:
○ Mesos native containerizer
○ Mesos docker containerizer
● Интерфейс
○ SPA UI
○ REST API
● Стабильная реализация (production-ready)
● Язык реализации: Java
10. Chronos Framework
● Каркас для запуска и управления долгоживущими процессами в
Mesos по расписанию (Cron-like):
○ Mesos native containerizer
○ Mesos docker containerizer
● Интерфейс
○ SPA UI
○ REST API
● Стабильная реализация (production-ready)
● Язык реализации: Java
12. Mesos run command via REST
$ curl -i -H 'Content-Type: application/json' -d "@Docker.json" localhost:
5052/v2/apps
13. Сложности
1. Выбор узлов, на которых можно развертывать сервис. Проблема
решаема заданием узлам tag-ов и указанием совместимых tag-ов
при создании задачи.
2. Обнаружение сервисов. Заранее не известно где запустится
экземпляр, поэтому необходима интеграция с сервисом
конфигурации (Zookeeper, Etcd, Consul)
a. внешняя интеграция (через API Mesos, Marathon)
b. внутренняя интеграция (подготовка контейнеров)
14. What’s next
1. Singularity от HubSpot - all-in-one framework более продвинутый чем
Marathon:
a. Marathon + Chronos в одном флаконе
b. Различные типы запуска:
i. service
ii. worker
iii. CRON-type
iv. on-demand
c. embedded load-balancing (using Baragon + HAProxy + Nginx)