5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)
1 like2,410 views
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки. В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности. План доклада: — Наша старая система деплоя, достоинства и недостатки. — Существующие решения: * "svn up" / "git pull". * rsync. * phar, hhbc (HHVM-specific), "loop". * rsync + 2 директории + realpath_root (Rasmus-style). — Требования для новой системы деплоя. * быстрый деплой на стейджинг (5-10 секунд на 50 серверов). * возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер). * совместимость с docker. * поддержка «долгоиграющих» CLI-скриптов (несколько часов). * низкое потребление ресурсов на принимающей стороне. * отсутствие необходимости сбрасывать opcache. * высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов). — MDK — multiversion deployment kit. — Анализ применимости и производительности способов деплоя. — Выводы.
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to 5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo) (20)
Ad
More from Ontico (20)
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)
- 1. 5 способов деплоя PHP-кода в условиях хайлоада Юрий Насретдинов
- 2. ✦ Крупнейшая в мире социальная сеть для знакомства с новыми людьми ✦ 2 000 серверов с PHP ✦ 150 000 файлов объемом 900 Мб
- 3. План ✦ Понятие деплоя кода ✦ Старая система деплоя в Badoo ✦ Другие существующие решения ✦ Новая система — MDK ✦ Заключение
- 4. План ✦ Понятие деплоя кода ✦ Старая система деплоя в Badoo ✦ Другие существующие решения ✦ Новая система — MDK ✦ Заключение
- 5. Deploy move (troops) into position for military action
- 6. Процесс деплоя ✦ Получение кода из репозитория (clone / fetch / checkout) ✦ Сборка (build) ✦ Доставка на конечные сервера (deployment)
- 7. План ✦ Понятие деплоя кода ✦ Старая система деплоя в Badoo («лупы») ✦ Другие существующие решения ✦ Новая система — MDK ✦ Заключение
- 8. Deploy move (troops) into position for military action Loop a pseudo-device that makes a file accessible as a block device
- 9. Loop ✦ packages/ ✦ templates/ ✦ config/ ✦ public/ build directory cp -r mounted loop ✦ packages/ ✦ templates/ ✦ config/ ✦ public/ umount loop 900 MiB loop 900 MiB mount
- 10. План ✦ Понятие деплоя кода ✦ Старая система деплоя в Badoo ✦ Другие существующие решения ✦ Новая система — MDK ✦ Заключение
- 11. Deploy move (troops) into position for military action GPL GNU General Public Licence
- 12. Существующие решения ✦ Система контроля версий (svn up / git pull / hg up) ✦ rsync (в новую директорию или «поверх») ✦ Один файл (phar, hhbc, loop) ✦ rsync + 2 директории + realpath_root
- 13. Существующие решения ✦ Система контроля версий (svn up / git pull / hg up) ✦ rsync (в новую директорию или «поверх») ✦ Один файл (phar, hhbc, loop) ✦ rsync + 2 директории + realpath_root
- 14. svn up + «Ленивый» + Быстрый + Легковесный (в случае SVN) - Неатомарный +/- Подходит для небольших проектов
- 15. Существующие решения ✦ Система контроля версий (svn up / git pull / hg up) ✦ rsync (в новую директорию или «поверх») ✦ Один файл (phar, hhbc, loop) ✦ rsync + 2 директории + realpath_root
- 16. Rsync в новую директорию + Атомарный -- Нагрузка по I/O (заливка нового + удаление старого) -- Много трафика
- 17. Rsync в новую директорию
- 18. Существующие решения ✦ Система контроля версий (svn up / git pull / hg up) ✦ rsync (в новую директорию или «поверх») ✦ Один файл (phar, hhbc, loop) ✦ rsync + 2 директории + realpath_root
- 19. Rsync поверх ++ Отправка только изменений - Неатомарный - Высокий CPU% на отправляющей стороне - Отправка и прием списка всех файлов с их stat() - 3 мб и 1 сек CPU на 150к файлов - 40-60 сек на 1000 серверов (24 ядра и 1 Гбит/с)
- 20. Существующие решения ✦ Система контроля версий (svn up / git pull / hg up) ✦ rsync (в новую директорию или «поверх») ✦ Один файл (phar, hhbc, loop) ✦ rsync + 2 директории + realpath_root
- 21. Один файл ++ Возможность использования uftp / bittorent + Простота + Атомарность + Легкость проверки целостности (md5 от одного файла) + Последовательная запись - Большой объем записи - Большая нагрузка на сеть
- 22. UFTP ✦ Загрузка по протоколу UDP (Multicast) + NACK ✦ Подходит для загрузки на сотни машин ✦ В наших условиях работает лучше bittorrent ✦ Open-source
- 23. Один файл (tar.gz) -- Нагрузка по I/O (создание 150к файлов)
- 24. Один файл (phar) + Нативный для PHP - Необходимость адаптировать код для работы из архива - Нельзя поменять один файл - OPCache сбрасывается полностью
- 25. Один файл (hhbc) +/- Нативный для HHVM + Дополнительные оптимизации (+30% к скорости) - Необходимость адаптировать код для работы из архива - Запрещено использовать eval и динамические include - Нельзя поменять один файл
- 26. Один файл (loop) + Выглядит, как обычная директория + Можно поменять один файл (rw mount) -- Не совместим с docker (no dynamic mounts) - OPCache сбрасывается полностью - Требуется sudo для mount - Не забывать монтировать при (ре)старте
- 27. Один файл (loop), docker ✦ Docker не поддерживает dynamic mounts ✦ loop монтируется динамически ✦ Пробовали понимать локальные NFS, SSHFS ✦ rsync /var/loop/<N>/ /var/www/ ✦ /var/www/ — директория, прокинутая в контейнер ✦ Решение плохое, rsync не атомарный
- 28. Существующие решения ✦ Система контроля версий (svn up / git pull / hg up) ✦ rsync (в новую директорию или «поверх») ✦ Один файл (phar, hhbc, loop) ✦ rsync + 2 директории + realpath_root
- 30. Atomic deploy current_link -> dir2 Requests: deploy current_link -> dir1
- 31. Atomic deploy ✦ atomic symlink change using rename(2) ✦ php-fpm reload / apache reload ✦ fork(2) ✦ child: exec(2) and adopt listen socket ✦ parent: close listen socket, drain and exit - or -
- 32. Rasmus-style document_root A B nginx.conf root $realpath_root; apache.conf <IfModule mod_realdoc.c> RealpathEvery 2 </IfModule> https://github.com/etsy/mod_realdoc - or - rsync
- 33. Rasmus-style + Не требуется адаптация кода + Не требуется reload — переиспользуется OPCache - Требуется в 2 раза больше памяти под OPCache - Нельзя деплоиться чаще, чем раз в max_execution_time сек - Для Apache нужен сторонний модуль
- 34. План ✦ Понятие деплоя кода ✦ Старая система деплоя в Badoo ✦ Другие существующие решения ✦ Новая система — MDK ✦ Заключение
- 35. Требования ✦ Быстрый деплой на staging и production ✦ Атомарные патчи ✦ Скрипты могут работать несколько часов (CLI) ✦ Малое потребление ресурсов ✦ Сохранность OPCache ✦ Быстрый откат
- 36. Требования ✦ Быстрый деплой на staging и production ✦ Атомарные патчи ✦ Скрипты могут работать несколько часов (CLI) ✦ Малое потребление ресурсов ✦ Сохранность OPCache ✦ Быстрый откат
- 37. Возможные решения ✦ loop xN (-staging, -docker, -opcache) ✦ rsync xN (-production, -opcache xN) ✦ SVN xN (-production, -opcache xN)
- 38. Deploy move (troops) into position for military action © https://www.youtube.com/watch?v=P2HhjHo1EQA
- 39. Multiversion Deployment Kit ✦ Возьмем архитектуру хранения деревьев (tree) из Git ✦ Переименуем все файлы из file.php в file.php.<version> ✦ Для скорости напишем её на Go ✦ Готово!
- 40. Multiversion Deployment Kit map: array( one => f/a3f4da63, two => f/c193497a, map => d/9c134b68, ) root deadbeef one a3f4da63 two c193497a map 9c134b68 three febe6995 four 75ffdb82
- 42. Multiversion Deployment Kit |- current.map -> f7fc6872.map |- deadbeef.map |- f7fc6872.map |- one.php.a3f4da63 |- two.php.c193497a |- tree/ | |- 9c134b68.map | |- 21e05ae6.map | |- three.php.febe6995 | |- three.php.21e05ae6
- 43. Multiversion Deployment Kit |- current.map -> f7fc6872.map |- deadbeef.map |- f7fc6872.map |- one.php |- one.php.a3f4da63 |- two.php |- two.php.c193497a |- mdk.inc |- tree/ | |- 9c134b68.map | |- 21e05ae6.map | |- three.php | |- three.php.febe6995 | |- three.php.21e05ae6 one.php: <?php require_once "mdk.inc"; require mdk_resolve_path("a.php");
- 44. MDK deploy protocol 1. Получаем корневой map 2.Смотрим, каких файлов не хватает 3.Запрашиваем недостающие файлы 4.Переходим к пункту 2
- 48. Multiversion Deployment Kit + Быстрый атомарный деплой небольших изменений + Низкое потребление CPU + OPCache переиспользуется + Позволяет скриптам работать сутками + Легкий мониторинг + Быстрый откат изменений + Написана на Go
- 49. Multiversion Deployment Kit - Требуется модификация кода - Сложная - Требуется Garbage Collector - Для редактирования файлов нужны спец. утилиты (mdk-vim)
- 50. MDK numbers Staging deploy 3-5 seconds Production deploy 2 minutes Patch deploy 5-10 seconds Full deploy 40 minutes Fails count 2 Epic fails count 1
- 51. План ✦ Понятие деплоя кода ✦ Старая система деплоя в Badoo ✦ Другие существующие решения ✦ Новая система — MDK ✦ Заключение
- 52. Заключение ✦ Rasmus не врет, rsync + realpath_root хорош ✦ «Лупы» тоже работают вполне неплохо ✦ Используйте то, что подходит лично вам ✦ Частый деплой + долгая работа => MDK ✦ Расскажите о своем опыте ✦ Заходите на https://tech.badoo.com/ !