Мастер-класс про высокие нагрузки и надежность: второй заход

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

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

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

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

aptly 0.5

aptly 0.5 has been released today. It is available for download as binary executables or from Debian repository:

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

When installing from repository, don't forget to import key used to sign the release:

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

Most important new features are:

Local Repository Publishing

Local repositories could be used in two ways:

  • test new versions of software
  • provide stable distribution of new versions

For the second case, it is best to create snapshots of local repositories and publish them. However, when testing out new versions, there isn't much sense in creating snapshot each time repository is updated. So aptly since version 0.5 supports direct publishing of repositories. Moreover, when local repository is updated, published repository could be updated as well in one step.

When local repository is created, default publishing options (distribution and component) could be specified, so that these options don't need to be specified when publishing:

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

Read more…

Мастер-класс: высокие нагрузки и надежность

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

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

Read more…

aptly: Call for Help

In Russian version of this blog there's a post about my talk on aptly at one of the conferences in Moscow. As this won't be that interesting for my non-Russian friends and it isn't significantly different from my previous talk </posts/aptly-02-moscow-devops-meetup.html>, I decided to call for your help with aptly documentation.

As I'm not native English speaker, could you please help me to fix my bad English in two places:

Please fork and submit pull requests. For website, please submit pull requests against develop branch.

Thanks in advance!

P.S. As PackageCloud has launched, what do you think about aptly launching as a paid service in the cloud with:

  • API
  • Package Storage
  • Web UI
  • All current features of aptly, including mirroring, snapshotting and local repositories?

Анатомия веб-сервиса (РИТ-2014)

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

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

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

Мастер-класс про высокие нагрузки и надежность, РИТ-2014

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

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

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

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

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

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

Brainwashing про Go

gopher

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 version 0.4 has been released today. Major feature in this version is local package repository management which allows to manage collection of your own packages, publish, take snapshots, mix with upstream repositories mirrors. Please download it or install from source, raise issues, disscuss in aptly-discuss group, follow me (@smira) to get information about updates.

Other features in 0.4 worth mentioning are: support for source packages for mirrors and local repositories, ability to delete unused package files and DB entries, and memory usage optimizations.

Full list of changes in this version:

  • local package repositories are supported
  • aptly supports mirroring remote repos with source packages and publishing repositories with sources
  • new command: aptly db cleanup to remove unreferenced DB entries and files
  • aptly peak memory usage has been reduced by factor of 3x
  • new flags: -keyring & -secret-keyring for aptly snapshot publish command
  • new config: downloadSourcePackages to enable source package downloading
  • new flag: -with-sources for aptly mirror create command
  • new config & flag: dependencyFollowSource & -dep-follow-source to follow Source: dependencies
  • new commands in aptly repo family: add, copy, create, drop, import, list, move, remove and show
  • command aptly snapshot create supports creation of snapshots from local repos
  • new flag`` -no-remove`` for aptly snapshot pull: don't remove other version of packages when pulling (e.g. keep old versions)
  • command aptly mirror create supports shorthand PPA url: ppa:user/project
  • new config: ppaDistributorID & ppaCodename to specify PPA url expansion rules
  • packages are printed in lists with underscores instead of dashes, e.g. pkg_1.3-3_amd64 instead of pkg-1.3-3-amd64

With addition of local package repositories, schema of aptly entities and transitions looks like that:

aptly schema

aptly Memory Usage Optimization

Next aptly version (0.4) would contain some changes to lower memory requirements while doing general operations: memory usage will be decreased by factor of 3. aptly is written in Go language, so this is a short story of optimizing Go program memory usage.

When I have been developing aptly, I suspected that memory usage would be not optimal, as aptly is processing huge amounts of package metadata (for example, when mirroring upstream Debian repositories consisting of 30000 packages). Memory usage went unnoticed until I was testing aptly in virtual machine with just 512 MB of memory, aptly was performing poorly because Linux was busy in swapping. This was something completely unexpected: so much memory? how could that be?

First I applied some general optimizations which were trivial:

  • some long operations (like mirroring) were happening in single function and some big data structures weren't required full time during function execution. So assigning nil to them allowed Go's garbage collector to reclaim unused memory faster.
  • reusing buffers for structure encoding (this is safe, as there're no concurrent operations and resulting byte slice is copied immediately).

Instead of creating buffer every time...

// 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()
}

... re-use buffer:

// 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()
}

Second, I had to find reliable way to measure memory consumption, that was easy thanks to CloudFlare blog post. What I discovered first was:

mem stats for aptly snapshot verify mem stats for aptly snapshot verify

Read more…

aptly 0.3

Today I've released aptly version 0.3. It's the first version I would recommend for production usage. Please download it or install from source, raise issues, disscuss in aptly-discuss group, follow me (@smira) to get information about updates.

New features:

  • using aptly serve command you can quickly serve your published repositories over HTTP, aptly would even advise right settings for apt sources;
  • aptly checks signatures and verifies checksums for downloaded files while mirroring remote repositories, if you don't have key that was used to sign the mirror in your trusted GnuPG keychain, aptly would give some hints, some hints;
  • flat format of Debian repositories is now supported (e.g. OBS creates repositories in such format);
  • now you can drop mirrors and snapshots;
  • aptly can draw graph of relationships between your mirros, snapshots and published repositories;
  • bash completion is available for aptly, try it out, it's amazing!
  • aptly gained ability to create empty snapshot, it could be useful if you'd like to extract part of repository by pulling packages;
  • custom config location could be given with flag -config.

Nice picture (actually it's output of aptly graph command):

output of aptly graph command
Contents © 2015 Andrey - Powered by Nikola