До первого мастер-класса о высоких нагрузках и надежности осталась неделя, свободных мест уже давно нет, но можно записаться на второй заход 4-го, 5-го и 6-го июля. Кто еще не собрался в отпуск, приходите, будем вместе разбираться с тем, как построить высоконагруженную и надежную систему.

Я уже публиковал отрывки из курса про хранение данных, сетевой ввод-вывод и очереди. Кроме теоретической части на мастер-классе будет и практическая часть, вот темы основных заданий:

1. memcached: выделение памяти, каковы накладные расходы;
2. "битва" моделей сетевого программирования: процессы, нити, асинхронный ввод-вывод;
3. PostgreSQL vs. Redis: скорость и чем она достигается;
4. шардирование, консистентное хеширование, что происходит при отказах шард;
5. влияние алгоритма повтора на клиенте на восстановление работоспособности сервера;
6. ØMQ на практике: взаимодействие сервисов;
7. протоколы соглашения и распределенная консистентная конфигурация.

Еще одно задание проходит "красной нитью" через весь курс, оно связано с проектированием Twitter-подобного проекта: от схемы базы данных до архитектуры клиентского приложения, схемы отказоустойчивости и оценок масштабируемости.

Новая версия aptly 0.5 была выпущена сегодня. aptly можно скачать в виде исполняемых файлов или подключив Debian-репозиторий:

deb http://repo.aptly.info/ squeeze main

При установке из репозитория в первый раз, не забудьте проимпортировать ключ, которым подписан релиз:

$ gpg --keyserver keys.gnupg.net --recv-keys 2A194991
$ gpg -a --export 2A194991 | sudo apt-key add -

Вот самые важные новые возможности в этой версии:

aptly repo create -distribution=wheezy testing-wheezy
aptly repo add -remove-files testing-wheezy incoming/*.deb
aptly publish repo testing-wheezy
...
aptly repo add -remove-files testing-wheezy incoming/*.deb
aptly publish update wheezy

На мой мастер-класс про высокие нагрузки и надежность 24-26 мая осталось совсем мало мест! Выкладываю еще два небольших отрывка курса.

Выбор языка программирования, фреймворка, на котором будет написан backend - дело непростое, необходимо взвесить большое количество факторов и принять правильное решение. Одним из таких факторов является сетевая архитектура backendа. Здесь тесно переплетаются два вопроса: организация сетевого ввода-вывода и многозадачная обработка запросов. Backend по сути представляет из себя "сложный прокси-сервер", который принимает HTTP-запросы, выполняет запросы к базе данных, другим хранилищам и сервисам, связывая их бизнес логикой, и формирует ответ. Это означает, что вопрос обработки соединений, переключение между обработкой конкурентных соединений играет важную роль в общей производительности приложения. Особенно ярко эти факторы проявляются при обслуживании долгих запросов (Websocket, long-polling, ...). Каждый язык программирования и фреймворк предоставляет (или не предоставляет) выбор механизмов многозадачности и сетевого ввода-вывода, мы поговорим подробно о Javascript, PHP, Java, Python, Ruby, Go и Erlang.

Читать далее…

Еще одним докладом на РИТ был рассказ про aptly. Презентация не очень сильно отличалась от доклада на Devops Meetup, из существенного нового была только поддержка локальных репозиториев.

Было много вопросов про поддержку yum-репозиториев, надо будет обязательно добавить возможность работать с ними как с Debian репозиториями.

Слайды доклада:

Новая версия aptly 0.5 все еще задерживается, никак не могу выделить достаточное количество времени, чтобы закончить разработку. Но скоро уже все должно быть!

Сегодня я выступил на РИТ-2014 с докладом о том, как устроен backend внутри, как он обрабатывает запросы, отправляет запросы в другие сервисы, базы данных и другие хранилища. Я немного поговорил о том, как может быть организована многозадачность и какие выводы можно из этого сделать.

Доклад был небольшой частью моего мастер-класса по высоким нагрузкам и надежности, который я проведу 24-26 мая. Если доклад показался интересным, приходите на мастер-класс. Там мы поговорим обо всем более детально, разберем практические задачи.

P.S. Записывайтесь на мастер-класс скорее, всего будет 20 участников, а мест осталось уже не так много!

24-26 мая я буду три дня подряд вести мастер-класс о высоких нагрузках и надежности. На мой взгляд, это две достаточно сложные темы, которые вызывают наибольшее количество трудностей при практической реализации. Я не ставлю целью дать набор конкретных практических знаний ("делай так, и все будет хорошо"), потому что не бывает универсальных архитектур, одинаковых проектов и "серебряных пуль". Моя задача - дать такой набор знаний и приемов, чтобы после мастер-класса каждый мог построить подходящую архитектуру самостоятельно. Это не будет курс о тюнинге MySQL или о настройке отказоустойчивого nginx, но мы будем говорить о том, почему MySQL устроен так, как он устроен, какие из этого вытекают характеристики, и, соответственно, что делать, чтобы заставить его работать быстрее.

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

• базовая часть любой системы - хранение данных, принципы хранения, от встроенной базы данных до распределенного хранилища;
• application server (backend) - организация многозадачности, прикладные frameworkи;
• взаимодействие - переход от монолитной архитектуры с сервис-ориентированной, от очередей до RPC и паттернов взаимодействия;
• клиентское приложение - сложность мобильного или web-приложения может быть даже выше, чем серверной части; как написать клиента так, чтобы вся система в целом была надежной и масштабируемой?
• вопросы тестирования с одной стороны крайне важны, а с другой окружены мифами о том, что они могут решить все проблемы;
• когда разработка завершена, осталось все собрать вместе, пришло время эксплуатации и обеспечения отказоустойчивости.

Мастер-класс рассчитан на тех, кто уже занимается разработкой web-приложений и хочет существенно повысить свой уровень. За три дня мы рассмотрим и попробуем решить реальные проблемы, каждый раз последовательно улучшая нашу модельную систему.

В качестве примера привожу небольшую часть курса:

Также в апреле на РИТ-2014 я сделаю два доклада: один про мой open-source проект, aptly, который позволяет обеспечить повторяемый и точно изменяемый набор пакетов на Debian-серверах, а второй будет одной из глав мастер-класса.

UPDATE: курс был отменен.

17 и 18-го мая на платформе Brainwashing мы (я, Леша Палажченко и Кир Шатров) собирались два дня вместе c вами разбираться с Go и пробовать его на практике. Вначале я воспринял язык Go как "еще один модный язык", но, присмотревшись поближе, я полностью изменил свое мнение. Go для меня заполнил нишу между Python и С. Я всегда любил Python, но мучался угрызениями совести: то, что я написал, могло работать на C гораздо быстрее. С другой стороны, на C я бы подобное не написал за такое же количество времени. Go оказался ровно посередине: с одной стороны, это небольшой язык программирования, спецификацию которого можно прочитать за пару часов, а с другой стороны то, что я на нем напишу, работает быстро.

Я никогда не любил Java за ее выдуманную сложность, я преподавал студентам C++ и чувствовал, что издеваюсь над ними, когда мы разбираем связь private/protected/public с friend, наследованием и перегрузкой. Go тщательностью выбора минимального множества конструкций языка напомнил последнюю работу Вирта, язык Оберон.

Когда я начинал писать на Go, я думал, что буду одним из первопроходцев, мне придется написать самому кучу библиотек, но я был удивлен, обнаружив огромное количество качественных Go библиотек в самых разных областях. Это уже похоже на питоновский "with batteries", то есть Go уже идет с батарейками в комплекте. Одним из хороших примеров производительности Go является то, что он делит первое место с C и Java в Web Performance Benchmark.

Вы хотите научиться писать на Go высокопроизводительные Web-сервисы? Тогда записывайтесь на Brainwashing про Go, а мы постараемся сделать так, что бы в эти два дня вы получили максимум знаний и практических навыков. Приходите сами или записывайте всю команду разработки, скучно не будет!

UPDATE: курс был отменен.

Сегодня вышла версия aptly 0.4: теперь aptly поддерживает работу с локальными репозиториями пакетов. Теперь с помощью aptly можно управлять коллекцией собственных пакетов, публиковать их, создавать snapshotы, объединять их с upstream репозиториями. Скачивайте или собирайте из исходников, пишите багрепорты, обсуждайте в группе aptly-discuss, читайте меня (@smira) в Twitter, чтобы получить информацию о новых релизах.

К заметным нововведениям в версии 0.4 также можно отнести поддержку source пакетов, возможность удаления неиспользуемых файлов, очистка базы данных и оптимизация объема используемой памяти.

Полный список изменений:

• поддержка локальных репозиториев пакетов
• aptly поддерживает зеркалирование и публикацию source-пакетов в дополнение к бинарным пакетам
• новая команда: aptly db cleanup убирает неиспользуемые файлы пакетов и записи в БД
• пиковое использование памяти было уменьшено в три раза
• новые параметры: -keyring и -secret-keyring в команде aptly snapshot publish
• новый конфигурационный параметр: downloadSourcePackages включает зеркалирование source-пакетов
• новый параметр: -with-sources в команде aptly mirror create
• новые параметры: dependencyFollowSource и -dep-follow-source, позволяющие отслеживать``Source:`` зависимости
• новый команды в группе aptly repo: add, copy, create, drop, import, list, move, remove and show
• команда aptly snapshot create поддерживает создание snapshot локальных репозиториев
• новый параметр `` -no-remove`` в команде aptly snapshot pull: не удалять другие версии пакетов при перетаскивании (сохранять старые версии)
• команда aptly mirror create поддерживает сокращенные PPA url: ppa:user/project
• новый конфигурационные параметры: ppaDistributorID и ppaCodename для указания правил обработки PPA url
• пакеты в списках печатаюся с подчеркиваниями вместо дефисов, например, pkg_1.3-3_amd64 вместо pkg-1.3-3-amd64

С возможностью работы с локальными репозиториями, схема сущностей aptly и связей между ними теперь выглядит так:

В следующей версии (0.4) aptly использование памяти в самых частых операциях сократится в три раза благодаря несложным оптимизациям. Т.к. aptly написана на Go, это будет короткая история об оптимизации использования памяти программами на Go.

Когда я начинал разрабатывать aptly, я подозревал, что использование памяти будет далеко не оптимальным, т.к. aptly "переваривает" большое количество метаданных пакетов (например, зеркало Debian репозитория может содержать информацию о 30 тыс. пакетов). Я не замечал, что aptly использует много памяти до того, как не начал тестировать на виртуалке с 512 Мб памяти. aptly работала крайне медленно из-за постоянного свопирования. Я такого никак не ожидал: почему используется столько памяти?

Для начала я применил тривиальные оптимизации:

• некоторые долгие операции (например, зеркалирование репозитория), происходят в рамках выполнения одной функции, и некоторые структуры данных становятся ненужными до окончания работы функции. Так, обнуляя (присваивая nil) переменные, можено дать возможноть garbage collectorу освободить ненужную память до окончания выполнения функции.
• повторное использование буферов для сериализации структур (это безопасно, т.к. нет конкурентного доступа, а результат сериализации немедленно копируется).

Вместо того, чтобы создавать буфер каждый раз...

// Encode does msgpack encoding of Package
func (p *Package) Encode() []byte {
    var buf bytes.Buffer

    encoder := codec.NewEncoder(&buf, &codec.MsgpackHandle{})
    encoder.Encode(p)

    return buf.Bytes()
}

... можно использовать его повторно:

// Internal buffer reused by all Package.Encode operations
var encodeBuf bytes.Buffer

// Encode does msgpack encoding of Package, []byte should be copied, as buffer would
// be used for the next call to Encode
func (p *Package) Encode() []byte {
    encodeBuf.Reset()

    encoder := codec.NewEncoder(&encodeBuf, &codec.MsgpackHandle{})
    encoder.Encode(p)

    return encodeBuf.Bytes()
}

Во-вторых, необходимо начать измерять то, что мы пытаемся оптимизировать: использование памяти. С помощью поста в блоге CloudFlare это сделать совсем несложно. Вот что я обнаружил:

Читать далее…

Сегодня вышла новая версия 0.3 aptly. Это первая версия, которую я рекомендую для широкого использования, скачивайте или собирайте из исходников, пишите багрепорты, обсуждайте в группе aptly-discuss, читайте меня (@smira) в Twitter, чтобы получить информацию о новых релизах.

Новые возможности:

• с помощью команды aptly serve можно быстро раздать по HTTP все опубликованные репозитории, aptly подскажет строчки для apt sources;
• при зеркалировании удаленных репозиториев aptly проверяет цифровую подпись и контрольные суммы загружаемых файлов, если в в вашей связке ключей GnuPG не хватает ключа для данного репозитория, aptly подскажет что делать;
• поддерживается flat-формат Debian-репозиториев (такие создает, например, OBS);
• теперь можно удалять зеркала (mirror) и слепки (snapshot);
• aptly может визуализировать граф зависимостей между созданными зеркалами, слепками и опубликованными репозиториями;
• для aptly есть bash completion, попробуйте, это очень удобно!
• aptly теперь умеет создавать пустой слепок (snapshot);
• можно указать расположение конфигурационного файла с помощью ключа -config.

Картинка для привлечения внимания (пример того, что может сделать aptly graph):