My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Где живут Ваши объявления / Тюрин Михаил (Avito)Ontico
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Где живут Ваши объявления / Тюрин Михаил (Avito)Ontico
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
Необходимость использования средств управления конфигурацией в процессе эксплуатации сложных веб систем быстро становится очевидной, тем не менее, использование различных средств управления конфигурацией имеет свои нюансы и тонкости. Разные системы управления конфигурацией создавались с учетом различающихся требований их создателей, и они по-разному решают возложенные на них задачи. Доклад посвящен обобщению практического опыта применения четырех средств управления конфигурацией — Chef, Puppet, SaltStack и Ansible в гетерогенных окружениях разного размера, построенных на базе различных UNIX-подобных платформ, от FreeBSD и Linux до SmartOS.
Целевая аудитория доклада: веб-разработчики, инженеры отделов эксплуатации.
Ее примерный уровень: средний.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление ок...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление окружениями в сложном проекте: Chef и другие", Александр Чистяков (ведущий разработчик Cezurity).
Аннотация
Облачный антивирус, который мы делаем в партнерстве с vk.com, отличается от типичного веб-проекта наличием большого числа специализированных и не очень специализированных подсистем. Это ставит перед отделом эксплуатации принципиально новые вызовы: нужно не только уметь реагировать на случайные сбои и предсказывать неслучайные, но и просто помнить где что лежит и какую задачу выполняет. О том, как мы отвечаем на эти вызовы в компании Cezurity - мой доклад.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуат...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуатация HBase на паре жизненных примеров", Александр Чистяков (ведущий разработчик Git in Sky)
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
2. Давайте познакомимся!
● Меня зовут Саша
● Я работаю главным инженером
● В компании Git in Sky
● Я немного знаю разные языки
программирования
● И умею немного администрировать
сайты
3. А вас как зовут?
● Вы веб-разработчики?
● У вас уже есть опыт
использования CM систем?
● Вам приходится управлять
инфраструктурой?
● Насколько она велика?
● Кстати, что значит понятие “велика”?
4. Возможная задача №1
● МНОГО серверов
● Их нужно БЫСТРО привести
к заданному виду
● Разные роли у разных машин
● Разные роли – это разные приложения
● Гетерогенные среды:
● Linux, FreeBSD, Solaris, ...
5. Возможная задача №2
● Описана эталонная конфигурация
● Разные окружения:
● development, testing
● staging, production
● Окружения различаются
размерами и свойствами
сервисов
6. Как можно решать эти задачи?
● Древний способ – скрипты на bash и пакеты
deb/RPM
● Современный – CM-системы:
● CFEngine
● Puppet, Chef
● Salt, Ansible
● Func, Babushka, Marelle
● Ansible создал автор Func
7. Чем плох древний способ?
● Никто не любит* писать скрипты на bash
● bash: плохо писать, плохо
читать, недекларативный,
неидемпотентный
● deb/RPM-пакеты это тоже
плохо (недекларативно, не
обеспечивается повторяемость)
*Я не люблю
8. Полезные свойства CM-систем
● bash-скрипты не торчат наружу
● Вместо – декларативный DSL
● Исполняется параллельно на
всех узлах
● Объекты предметной области -
иерархия (роли, модули, группы
узлов, атрибуты)
9. Модель предметной области
● Описание конфигурации:
● Описания установленных
пакетов
● Описания разрешенных и
запущенных сервисов
● Шаблоны конфигурационных файлов и
правила их генерации
● Среды, роли, узлы, параметры всего этого
10. Типичное устройство CM-систем
● Клиент-серверная архитектура
● “Толстый клиент”
● Много зависимостей
● Часто – eDSL на Ruby
● ^ (и сама система тоже)
● Pull-модель: клиенты
обращаются к серверу
11. Что нам не нравится?
● Клиент-серверная архитектура
● Нужно развернуть и поддерживать сервер
● Сервер потребляет ресурсы
● Необходимо обеспечить
безопасность сервера
● И его отказоустойчивость
12. Что еще плохо?
● “Толстый клиент”
● Нужно делать бутстреппинг узла при его
введении в инфраструктуру
● Работает не на любой
платформе
● При работе потребляет
ресурсы
13. Что еще плохо?
● Часто – eDSL на Ruby
● Я же на Python секции?
● Вы любите Ruby?
● eDSL сделан “поверх”
основного языка – декларативность не
навязывается на уровне DSL, можно писать
bash скрипты на основном языке
14. Что еще плохо?
● Pull-модель
● Мне кажется, это потеря
смысла:
● Зачем нужен командный
центр, который не имеет
возможности оперативного
управления?
15. Как же быть?
● Больше декларативности:
YAML
● Вернуть серверу возможность
управлять клиентами
● Может, убрать сервер?
● Кстати, может и толстые
клиенты тоже убрать?
16. И, наконец, о практике
● Salt – начинался как средство параллельного
исполнения
● Клиенты постоянно подключены к серверу
через ØMQ
● Эволюционировал в CM-систему
● С документацией на
1668 страниц
17. Чем хорош Salt?
● ОЧЕНЬ быстро развивается
● Уже сейчас предоставляет
много возможностей
● Сервер и клиент относительно
легковесны (в сравнении с Chef)
● Выполнение ad hoc команд сделано идеально
(в сравнении с чем угодно на Ruby)
● Отличная (!) поддержка сообществом
18. Чем плох Salt?
● Слишком быстро развивается
● Инфраструктура, в которой
нужны ad hoc команды -
источник проблем в будущем
● Русские читают документацию только в
критической ситуации, особенно, если ее
1668 страниц
19. Не расходитесь, это не всё!
● Порог вхождения:
● Минимален, это же Python и YAML
● Выразительность:
● Простые вещи делаются просто, вещи
посложнее – сложно (вместо YAML можно
описывать конфигурацию на Python, но будет
некрасиво)
● Кроссплатформенность: Windows, FreeBSD
20. Что еще умеет Salt
● Масштабироваться: Salt Syndic (репитер)
● Управлять частным облаком: Salt Virt
● Управлять публичным облаком: Salt Cloud
● Заменить собой cron: опция “schedule”
● Показывать статус инфраструктуры и
выполнять команды через веб-интерфейс:
Halite
21. Еще один претендент
● Ansible – вторая попытка
Michael DeHaan сделать CM-систему
● На управляемых узлах нужен только
интепретатор Python, никаких клиентов*
● Коммуникация между “сервером” и клиентами
по обычному SSH
*чуть позже мы вернемся к
вопросу о том, что такое “клиент”
22. Звучит очень круто!
● Почему никто не сделал
подобное раньше?
● Потому, что в Ruby нет
нормального быстрого SSH-клиента? :)
● Кстати, как я обеспечиваю безопасность
своего Ansible-сервера?
● Я привез его с собой в своем рюкзаке, он
отключен от сети
23. Работает еще более круто!
● Если мой Ansible-сервер в зале, что же
применяет конфигурацию на клиентах?
● Как применяет конфигурацию CM-система?
● Клиент скачивает файлы с сервера
● И применяет правила из них локально
● Постойте, я знаю много разных способов
передачи файлов с сервера клиенту!
● Некоторые из них даже “high load” :)
24. Сервер не нужен
● На каждом хосте по cron
работает команда ansible-pull
● Она забирает из git-репозитория
новую версию, если она есть
● И применяет ее локально
● Проблема курицы и яйца – как ansible-pull
попадет в cron первый раз?
● При помощи моего “сервера”
25. Нужен ли сервер?
● Пришлось пожертвовать
возможностями, которые
сервер предоставлял в
классических CM-системах:
● autodiscovery, обмен параметрами*
● Autodiscovery через CM сервер? Зачем?
● Для этого есть Serf, etcd, mDNS
*можно, но теперь это peer-to-peer связь
26. Другие свойства Ansible
● Порог вхождения:
● Еще ниже, чем у Salt
● Выразительность:
● Местный диалект YAML менее многословен,
чем у Salt
● Кросплатформенность:
● Разработчики знают такие платформы, о
которых даже я не знаю (DragonFly BSD)
27. Кросплатформенность
● Я использую Ansible под SmartOS:
● SmartOS работает с флешки, и каталоги
/usr/bin и /etc там недоступны на запись
● SmartOS – это Solaris, а не Linux, там SMF, а
не sysvinit, upstart или systemd
● При рестартах некоторая часть
конфигурации теряется
● Ansible отлично справляется со всем этим
28. Что плохо (и там, и там)?
● Выразительности YAML часто
недостаточно – не все сценарии есть
● Управление серверами императивно
● Скрипты “на bash” неизбежны
● Я писал state для Salt на Python
● Он был так же плох, как и на bash
29. Что ужасно (и там, и там)?
● Можно много спорить о необходимости
unit-тестирования
● Но механизмов для него нет ни в Salt, ни в
Ansible (в отличие от Chef)
● Управление модулями, их версиями и их
зависимостями – в зачаточном состоянии (нет
аналогов pip, Bundler или librarian-chef)
● Есть Ansible Galaxy (это как PyPI, но без
версий)
30. Great artists steal
● Open Source-системы могут пользоваться
идеями друг друга не боясь патентных
преследований
● Так появились “salt-ssh” и “Ansible Fireball”
● Последний благополучно умер, вместо
ZeroMQ-транспорта рекомендуется включать
в ansible.cfg SSH pipelining
● (но ansible-pull все равно быстрее)
31. (Chef-)сервер не нужен!
● Все пользуются идеями друг друга:
● В Salt есть salt-call (masterless)
● В Chef есть chef-solo
● Masterless Puppet тоже можно настроить
32. Выводы
● Конкуренция – двигатель прогресса
● Прогресс в области CM-систем пока еще не
остановился
● Python-based CM-системы молоды и бурно
развиваются
● Мы можем им помочь!
● 62
33. Спасибо за внимание!
● Пожалуйста, ваши вопросы!
● С вами был Александр Чистяков,
● Главный инженер Git in Sky
● http://twitter.com/noatbaksap
● alex@gitinsky.com
● http://gitinsky.com,
http://meetup.com/DevOps-40