19
2012
По следам HighLoad++ 2012 (Deploy в Mamba, SPDY в nginx, построение highload-систем в Amazon-е)
Цикл разработки, визуальный деплой, автоматизация и интернационализация (Mamba)
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: быстрее на 146% (nginx)
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 модерирует 1 миллиард фотографий в год
У Badoo 2 датацентра, 200+ серверов с фотографиями, 200+ серверов с пользовательскими данными. Загружается 150+ новых фотографий в пике в секунду, 3+ миллиона в сутки. 120+ модераторов онлайн в пике. Время модерации фотографии: 1-2 минуты.
Доклад сводился к расскажу о проблемах ручной модерации фото, и как они постарались свести эти проблемы к минимуму благодаря конкретным техническим реализациям — построению некой определённой структуры БД (чтобы не было проблем с deadlock-ами), очередей сообщений на MySQL, созданию сверхудобных интерфейсов для ручной модерации и т.п. Доклад несомненно интересный, но основанный на достаточно специфической задаче.
Partly cloudy. Построение отказоустойчивых систем в AWS минимальными средствами (itsumma)
Довольно интересный доклад, который можно охарактеризовать двумя тезисами: «нельзя безоговорочно доверять Amazon-у» и «а вообще надо ли идти в этот Amazon?». Тут надо отметить, что в ходе всей конференции критика сервисов Amazon-а (EC2 и подобных) звучала как минимум в 3-4х докладах.
Клиенты компании-докладчика, кто идет в Amazon, мотивированы тремя вещами:
- высокой надежностью
- простой масштабируемостью
- оплатой только за используемые ресурсы
В докладе опровергаются первый и второй пункты, а так же говорится, что цена вопроса построения инфраструктуры в облаке обойдется намного дороже. В качестве примера, приводится стоимость средненького выделенного сервера:
процессор: 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-а:
- Сайт находится на физическом хостинге и переводится в Amazon только в случае аварии (плюсы — выключенные инстансы стоят копейки, минусы — приходится поддерживать две площадки и данные актуальны только на дату последнего бэкапа, ну а так же присутствует некоторое время простоя во время переключения)
- Проект находится на физическом хостинге, но реплицируется на минимально возможно конфигурацию в Amazon. В случае аварии минимальная конфигурация масштабируется до необходимой (плюсы — все так же дешево, т.к. изначально конфигурация минимальна, минусы — время простоя достаточно велико, т.к. это время между реакцией на падение физического хостинга, и окончанием масшабирования, само масштабирование — горизонтальное (добавление инстанса) занимает от 5ти до 10ти минут, вертикальное (апдейт инстанса) — от 4х до 10ти минут.
- Горизонтальное масштабирование v.1. Вариант подходит для случаев когда нагрузка возрастает в сезонные периоды (праздники, выходные и т.п.). Проект находится на физическом хостинге, реплика хранится в AWS, и при необходимости масштабирования необходимое количество инстансов запускается в AWS и синхронизируется с «минимального» инстанса.
- Горизонтальное масштабирование 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)
Позитивный доклад от Андрея Аксёнова (создателя поискового движка Sphinx). Что и как мерить и как избегать ошибок при этом. Весь доклад можно свести к ряду полезных тезисов:
- Нельзя мерить одну конкретную метрику, будь то latency, loadavg, iowait, bandwidth и т.п. Нужно мерить все целевые метрики в совокупности, и уже по общей картине делать какие-то выводы
- Нельзя мерить среднее значение (например, latency), т.к. оно абсолютно ничего не значат. Нужно мерить распределение величины
- Иногда впрочем сгодятся min и max (планироване ёмкости, планирование катастроф)
- Для сравнения (для составления всяческих бенчмарков в духе, «мой фреймворк круче остальных») следует использовать одинаковые сущности (сравнивать сравнимое), и мерить НЕ на дефолтных настройках (тут Аксёнов привел пример, как некто сделал сравнение в духе «Sphinx в 100500 раз медленнее Mamba»)
- Для профайлинга можно использовать стандартные утилиты: ps, top, vmstat, iostat, mpstat, netstat, strace, oprofile
- Всегда помнить про мировые константы, и какое действие «сколько стоит» (по поводу мировых констант — см картинку)
- Помнить о целях, мерить только нужное, а не просто load average
- Думать, когда делаешь тесты для бенчмарков. Так, например, выполнить один запрос 1000 раз равносильно проверке работоспособности кэша (MySQL Query Cache)
- Предсказывать масштабируемость бессмысленно. Линейной масштабируемости не бывает (закон Амдала). 95% работы параллелится, но 5% работы не параллелится. Вообщем, можно вывести некую формулу для производительности:
C(n) = n / (1 + a × (n-1) + b × n × (n-1)), где
a — степень contention (затраты на нераспараллеленный код),
b — степень coherency (затраты на синхронизацию для консистентности),
n — количество ресурсов (тредов/машин)
Если построить график функции C(n), то станет понятно, что есть некий экстремум (так называемый sweet spot) — это то количество тредов/машин/ресурсов, при котором производительность системы будет максимальной, и после которого производительность начнет падать.
Go Language (Google)
Хотя я не фанатею от Go и всяких прочих новомодных языков программирования, но среди всех прочих докладов (шедших в это время) этот, на мой взгляд, оказался самым «адекватным». На самом деле ничего такого гиперинтересного не рассказывали, в основном про аспекты языка, и частные реализации тех или иных особенностей. В частности про одну из фишек — многопоточность (go-routines) и каналы (так называемые chan-ы), которые используются для связи между go-процедурами, запущенными в разных потоках.
Пн | Вт | Ср | Чт | Пт | Сб | Вс |
---|---|---|---|---|---|---|
« Сен | ||||||
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
Метки
Рубрики
- Apache (1)
- Highload (4)
- JavaScript (1)
- Linux (3)
- MongoDB (1)
- MySQL (1)
- Perl (1)
- PHP (5)
- Python (5)
- Web-разработка (5)
- Алгоритмы (1)
- За жизнь (2)
- Конференции (6)
«стоимость выгрузки 3 терабайт данных может дойти до $22082″ — это в каком регионе?
Судя по всему это справедливо для регионов US East (N. Virginia) и US West (Oregon). Вот тут можно прочитать подробнее если интересно: http://news.ycombinator.com/item?id=4412886