Tags: highload devops infrastructure zalando badoo vkontakte
Categories: None

Сегодня прошел первый день конференции HighLoad++ 2016. По свежим следам пишу свои впечатления о наиболее интересных докладах, которые я посетил. Ходил я в основном по секциям DevOps и «Архитектуры…». Про саму конференцию в целом, думаю, смысла смысла писать особого нет. Так что перехожу сразу к докладам.

Remote Highload

Очень интересная для меня тема, так как есть представление и некоторый опыт работы в небольшой распределенной команде (Формат стартапа на несколько человек). Автор доклада, же, рассказывает как их команда из 15-и человек работотает распределенно в нескольких часовых поясах и создает высоконагруженный крупный продукт.

Ребята делают распределенное хранилище данных, что-то типа Amazon’овского S3. Внушительные цифры: экзабаты данных, несколько датацентров и т.д. И все это они разрабатывают и поддерживают распределенной командой. Автор немного затронул тему хантинга, что распределенность позволяет нанимать лучших из лучших по всему миру. Процесс интервью основан на выдаче задания, типа «Спроектировать сервис» и часового технического интервью на разные темы.

Дальше разговор пошел про процессы, архитектуру и взаимодействие. Распределенность накладывает свой отпечаток. Все процессы должны быть «… as a Code»: описание инфраструктуры, автоматизация выкладок, мониторинги и т.д. Это дает возможность всей команде видеть техническую хронологию изменений в продукте. Ну и естесственно Code Review. Так же разработчикам дается полная ответственность за продакшен, грубо говоря доступ в прод имеет каждый.

Для устранения вакуума, чтобы не сходить с ума в своих 4-х стенах дома, устраивают некое подобие стендапов (Вот тут не совсем понял как оно устроено, это чатик или скайп с привязкой ко времени). Никакого скрама естесственно нет.

Несколько слов было сказано о проблемах распределенности. Каждый разработчик занимается своей частью работы, и хоть и все его изменения видны остальным участникам команды, знания все равно по большей части завязаны на этом разработчике и сами собой не распространяются. Тут я может немного не так уловил мысль, так как уже собирался.
Еще автор хотел рассказать про конкретные тулы, но время поджимало. Кейворды были примерно такие: Mesos, Marathon, Consul, Calico и т.д

5 способов деплоя PHP-кода в условиях хайлоада (Или как выкатывают в Badoo)

Пошел на этот доклад, чтобы послушать как выкатываются в Badoo. Тут понятное дело проблемы крупной компании, тысячи серверов, разные окружения (prod, stage), надо катить релизы и хотфиксы.

Автор рассказывал как они в течение 10-и лет меняли подход к выкладке и разработали свою систему MDK, которую, возможно, скоро можно будет увидеть в Open Source.

В кратце те самые 5 способов принести пачку файлов проекта на сервер следующие:

  • git pull
  • rsync
  • архив или loopback устройство. До написания своей тулзы они катили какраз через loop.
  • rsync и переключение realpath_root в nginx. Это вариант автор предлагал подавляющему большенству php проектов.
  • Multiversion Deployment Kit. Собственно к чему пришли в Badoo.

Что касается цифр: MDK доставка на сервера выглядела что-то типа минуты для выкатки релиза и секунды для хотфикса

Как работают системные администраторы Vkontakte

Название доклада говорящее. Автор рассказал как работает эксплуатация и как устроен DevOps. Есть 35 тыс. серверов, есть большой бинарь, который компилируется из php кода, который надо раскладывать по серверам и обслуживают все это менее 10-и администраторов. Неплохо.

Тулы все самописные. Для доставки файлов на сервера используется протокол gossip и тулза copyfast, для запуска процессов (команд) на серверах утилита copyexec. Есть и общая утилита для управления и разграничения доступа - Delegate. Да, все в опенсорсе.

Как devops исчерпывается себя, и что будет дальше

В этом докладе с заманчивой темой автор больше рассказывал про пакетный менеджер Nix, про систему, которая разрабатывается в их компании и т.д. Ну и сама тема доклада, о том как же devops исчерпывает себя и что будет дальше немного терялась из-за таких деталей.

В целом автор дал небольшой экскурс в историю, как развивались методы эксплуатации. От традиционных инструментов управления конфигурацией вроде Chef/Ansible /etc до Docker и immutable images, что в итоге должно прийти к автономным окружениям, оторванным от ОС.

Мне показалось все это представляет из себя что-то типа: управление зависимостями (например Mysql зависит от libc), управление конфигурацией инфраструктуры (Для запуска инстанса бекенда мне нужны БД) и линковкой всего в один бинарь (Похоже на историю с Unikernels).

В общем, надо будет пробежаться по продукту, который они делают (JetWare) и другим инструментам пакетирования (Snappy/Nix/Habitat).

События, шины и интеграция данных в непростом мире микросервисов (Zalando)

Прямо бомба-доклад. Я уже неоднократно слышал о трансформации Zalando, как они из неповоротливого монолита реструктурировались в гибкую компанию с микросервисами и кхмкхм. В этом докладе автор рассказал что же у них сейчас есть.

Каждая команда отвечает за свой сервис сама. Вроде как нет запрета на языки. Но есть система стандартизованных интерфейсов между сервисами. Это REST и Swagger. Если хочешь запилить новый сервис, предоставь его интерфейс специальной команде архитекторов для одобрения. Внутри пиши на чем хочешь, храни данные где хочешь. Это все я считаю здорово, хотя не верю что есть прямо такая степень демократии в выборе технологий для своего сервиса.
Еще автор сказал, что автономность команд доходит до того, что они работают под разными учетками AWS (¯_(ツ)_/¯).

Дальше рассказ пошел в тему аналитики. Бизенс гайс захотели собирать данные со всех этих микросервисов и анализировать как привыкли, но так как в каждом из сервисов внутри все свое, надо было построить систему аггрегации данных. Они написали свою шину, в которую микросервисы шлют свои данные, задается формат трансформации, с возможностью версионирования (чтобы в хранилише поступала уже структурированная информация) и в итоге аналитики могут извлекать данные и анализировать своими инструментами. Называется Nakadi, внутри Kafka со своими обертками для нормальной работы в распределенной среде AWS.

Да, и еще рассказали про свой подход к новым продуктам - Open Source first. То есть новый продукт изначально проектируется с целью стать опенсорсным, так что никаких паролей и ключей в репозитории с кодом и все остальное вытекающее. Вот их гайд.

End

На этом все. Завтра второй день, который, кажется, будет еще интереснее по докладам.

comments powered by Disqus