По следам HighLoad++ 2012 (Deploy в Mamba, SPDY в nginx, построение highload-систем в Amazon-е)

Mamba рассказывали как эволюционировала их система деплоя. Система контроля версий менялась от CVS к SVN, какое-то время вели всю разработку в SVN, и когда осознали потребность в полноценных ветках, перешли на GIT. Таки что не понравилось в SVN: тяжелые операции переключения веток, тяжелые операции слияния веток. Вся разработка до этого велась фактически в trunk-е, и как следствие возникала сложность с отсутствием стабильного и боевого кода. После перехода на GIT всю разработку стали вести в ветках, «отпочкованных» от мастера. После реализации некой функциональности brunch (у них это почему-то называется «заявка») посылается на проверку в Jenkins, и после прогона тестов, проверки корректности шаблонов и ряда других валидаторов производится автоматическое слияние с мастером и выгрузка на тестовые серверы. Насколько я понял, все это производится в некой системе визуального деплоя (аля gerrit?), где отображаются все текущие ветки и их состояние (были ли конфликты, падали ли тесты и т.п.). В случае конфликта при слиянии ветки с мастером, разрешение конфликта остается на совести того разработчика, чья ветка конфликтует. На основе ряда таких вот веток (заявок) формируется RC, который тестируется перед деплоем на боевые сервера, и в дальнейшем помечается как tag (для случая аварийного отката).

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

• нельзя делать тупо копирование файлов (могут возникать сегфолты при чтении недопереписанных файлов PHP-акселератор аля APC)
• не рекомендуется копировать в соседнюю папку и переключать симлинк (тут, правда, я не очень понял почему… по-моему что-то в духе того, что на момент переключения уже может быть прочитана часть старых скриптов)
• правильно — менять document root и делать reload конфига в nginx-е

После деплоя для проверки состояния системы подключается BTP для сбора метрик (собирает различные счетчики, таймеры и т.п.) — в случае если что-то пошло не так, на графиках в специальном интерфейсе это сразу видно. Изменения схемы (ALTER-ы) делаются админами ночью

Кстати, в докладе краем фразы упоминался шаблонный движок blitz (PHP модуль, написанный на Си), которым они пользуются для шаблонизации, и что через некий UI переводчик может зайти на сайт, накликать переводов для текста, внести изменения и сформировать свой шаблон. Достаточно удобно. Потом эти шаблоны в Jenkins проверяются на наличие непереведённых фраз.

SPDY — бинарный протокол прикладного уровня от Google поверх TCP/TLS соединения. Поддерживается браузерами Google Chrome, Mozilla Firefox с версии 13, Opera с версии 12.50. Для реализации на части web-сервера доступен в виде модуля к Apache от Google (mod_spdy) и в виде патча к nginx-у (обещают включить в основной код через пару месяцев). Основные фичи:

• мультиплексирование (несколько запросов за одно соединение, как от сервера к клиенту, так и наоборот)
• сжатие заголовков (zlib, deflate)
• flow control (окно для tcp-соединения)
• server push («заливка» данных в браузер, инициированная сервером)

Рассматривается как некая альтернатива к Keep Alive. На самом деле, Keep Alive соединение в nginx «дешевле» — одно spdy-соединение требует примерно в 100 раз больше памяти чем одно Keep Alive. В комплекте SSL-шифрование (т.к. поверх TLS как ни крути) — но это как плюс, так одновременно и минус, т.к. за счет шифрования появляется дополнительная нагрузка на процессор.

Касательно сжатия заголовков есть ряд проблем, поскольку вместе с заголовками сжимаются и Cookie, то это потенциальная дыра (уязвимость к атаке типа CRIME). Таким образом Firefox при spdy-соединении в принципе не сжимает заголовки, а Chrome использует хак zlib для того, чтобы сжимать все, кроме Cookie.

Так же выяснилось, что в результате боевого тестирования WordPress-ом, SPDY быстрее HTTPS, но медленнее привычного HTTP. Стоит ли использовать SPDY? как вариант заместо HTTPS, особенно если на странице много статического контента, либо же в случае «big round trip time«. Сама поддержка spdy включается довольно просто:

server {
  listen 433 ssl spdy;
  ssl_certificate path/to/cert.crt;
  ssl_certificate_key path/to/private.key;
  #spdy_headers_comp 1;
}

У Badoo 2 датацентра, 200+ серверов с фотографиями, 200+ серверов с пользовательскими данными. Загружается 150+ новых фотографий в пике в секунду, 3+ миллиона в сутки. 120+ модераторов онлайн в пике. Время модерации фотографии: 1-2 минуты.

Доклад сводился к расскажу о проблемах ручной модерации фото, и как они постарались свести эти проблемы к минимуму благодаря конкретным техническим реализациям — построению некой определённой структуры БД (чтобы не было проблем с deadlock-ами), очередей сообщений на MySQL, созданию сверхудобных интерфейсов для ручной модерации и т.п. Доклад несомненно интересный, но основанный на достаточно специфической задаче.

Довольно интересный доклад, который можно охарактеризовать двумя тезисами: «нельзя безоговорочно доверять Amazon-у» и «а вообще надо ли идти в этот Amazon?». Тут надо отметить, что в ходе всей конференции критика сервисов Amazon-а (EC2 и подобных) звучала как минимум в 3-4х докладах.

Клиенты компании-докладчика, кто идет в Amazon, мотивированы тремя вещами:

1. высокой надежностью
2. простой масштабируемостью
3. оплатой только за используемые ресурсы

В докладе опровергаются первый и второй пункты, а так же говорится, что цена вопроса построения инфраструктуры в облаке обойдется намного дороже. В качестве примера, приводится стоимость средненького выделенного сервера:

процессор: Quad Core Xeon 3450 2.66GHz
оперативная память: 8GB DDR3 Registered 1333
дисковая подсистема: 4x500GB SATA HDD, RAID 10
траффик: 5000 гигабайт
пропускная способность: 1 гигабит

и стоимость аналогичного инстанса в Amazon-е:

процессор: High-CPU Extra LargeInstance (8 virtual cores)
оперативная память: 7 GB
дисковая подсистема: EBS 1000GB
траффик: 1000 гигабайт
пропускная способность: не контролируется

По расчетам месячного активного использования выходит, что «дедик» стоит 399$, а Amazon-овский инстанс 501$. При этом нельзя говорить о супер-надежности (тут приводится пример, что сервисы Amazon-а периодически отказывают в различных зонах, на что Amazon на форумах поддержки дает довольно стандартные комментарии в духе «да ребята, мы облажались, но мы постараемся исправиться»).

Так же приводятся различные «волшебные» аспекты виртуализации. Так, например, производительность EBS нестабильна (подробнее см. эту ссылку), а пропускная способность инстансов довольно разная и непропорциональна типу инстанса (подробнее можно почитать тут, с1.medium — впереди планеты всей).

Далее рассматривается ряд шаблонов построения систем, с использованием Amazon-а:

1. Сайт находится на физическом хостинге и переводится в Amazon только в случае аварии (плюсы — выключенные инстансы стоят копейки, минусы — приходится поддерживать две площадки и данные актуальны только на дату последнего бэкапа, ну а так же присутствует некоторое время простоя во время переключения)
2. Проект находится на физическом хостинге, но реплицируется на минимально возможно конфигурацию в Amazon. В случае аварии минимальная конфигурация масштабируется до необходимой (плюсы — все так же дешево, т.к. изначально конфигурация минимальна, минусы — время простоя достаточно велико, т.к. это время между реакцией на падение физического хостинга, и окончанием масшабирования, само масштабирование — горизонтальное (добавление инстанса) занимает от 5ти до 10ти минут, вертикальное (апдейт инстанса) — от 4х до 10ти минут.
3. Горизонтальное масштабирование v.1. Вариант подходит для случаев когда нагрузка возрастает в сезонные периоды (праздники, выходные и т.п.). Проект находится на физическом хостинге, реплика хранится в AWS, и при необходимости масштабирования необходимое количество инстансов запускается в AWS и синхронизируется с «минимального» инстанса.
4. Горизонтальное масштабирование v.2. Проект целиком находится в AWS, но реплицируется в различные регионы (то есть, если проект находится в US East, то реплицируется в EU West).

Так же были рассмотрены специальные вспомогательные сервисы, для создания отказоустойчивой системы… и вообщем-то все они были раскритикованы. EC2 Spot Instances — с одной стороны дешево, с другой стороны ненадежно (т.к. инстанс будет остановлен, в случае если кто-то предложит большую ставку при дефиците инстансов). Elastic Load Balancing — проекты, которые полагаются только на ELB в пределах одного региона, становятся недоступными в случае падения ELB, а как говорят факты последнее падение Амазона как раз-таки затронуло ELB. Route 53 — с одной стороны сервис работает хорошо, но вот с другой стороны amazon.com использует другие ns, что как бы слегка намекает… Glacier — дико дорогая стоимость восстановления данных. Дешевизна и надежность архивирования компенсируется стоимостью и скоростью выгрузки данных: стоимость выгрузки 3 терабайт данных может дойти до $22082.

Позитивный доклад от Андрея Аксёнова (создателя поискового движка Sphinx). Что и как мерить и как избегать ошибок при этом. Весь доклад можно свести к ряду полезных тезисов:

1. Нельзя мерить одну конкретную метрику, будь то latency, loadavg, iowait, bandwidth и т.п. Нужно мерить все целевые метрики в совокупности, и уже по общей картине делать какие-то выводы
2. Нельзя мерить среднее значение (например, latency), т.к. оно абсолютно ничего не значат. Нужно мерить распределение величины
3. Иногда впрочем сгодятся min и max (планироване ёмкости, планирование катастроф)
4. Для сравнения (для составления всяческих бенчмарков в духе, «мой фреймворк круче остальных») следует использовать одинаковые сущности (сравнивать сравнимое), и мерить НЕ на дефолтных настройках (тут Аксёнов привел пример, как некто сделал сравнение в духе «Sphinx в 100500 раз медленнее Mamba»)
5. Для профайлинга можно использовать стандартные утилиты: ps, top, vmstat, iostat, mpstat, netstat, strace, oprofile
6. Всегда помнить про мировые константы, и какое действие «сколько стоит» (по поводу мировых констант — см картинку)
7. Помнить о целях, мерить только нужное, а не просто load average
8. Думать, когда делаешь тесты для бенчмарков. Так, например, выполнить один запрос 1000 раз равносильно проверке работоспособности кэша (MySQL Query Cache)
9. Предсказывать масштабируемость бессмысленно. Линейной масштабируемости не бывает (закон Амдала). 95% работы параллелится, но 5% работы не параллелится. Вообщем, можно вывести некую формулу для производительности:
   C(n) = n / (1 + a × (n-1) + b × n × (n-1)), где
   a — степень contention (затраты на нераспараллеленный код),
   b — степень coherency (затраты на синхронизацию для консистентности),
   n — количество ресурсов (тредов/машин)
   Если построить график функции C(n), то станет понятно, что есть некий экстремум (так называемый sweet spot) — это то количество тредов/машин/ресурсов, при котором производительность системы будет максимальной, и после которого производительность начнет падать.

Хотя я не фанатею от Go и всяких прочих новомодных языков программирования, но среди всех прочих докладов (шедших в это время) этот, на мой взгляд, оказался самым «адекватным». На самом деле ничего такого гиперинтересного не рассказывали, в основном про аспекты языка, и частные реализации тех или иных особенностей. В частности про одну из фишек — многопоточность (go-routines) и каналы (так называемые chan-ы), которые используются для связи между go-процедурами, запущенными в разных потоках.