Highload 2016 "5 способов деплоя PHP-кода в условиях хайлоада", Юрий Насретдинов В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать 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. — Анализ применимости и производительности способов деплоя. — Выводы.

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

29. config:
Atomic deploy
current_link
dir1
dir2
define('ROOT_DIR', __DIR__);

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

41. Multiversion Deployment Kit
root
deadbeef
one
a3f4da63
two
c193497a
map
9c134b68
three
febe6995
four
75ffdb82
root*
f7fc6872
map*
21e05ae6
three*
28e967c5

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

45. MDK deploy protocol
root
deadbeef
one
a3f4da63

46. MDK deploy protocol
root
deadbeef
one
a3f4da63
two
c193497a
tree
9c134b68

47. MDK deploy protocol
root
deadbeef
one
a3f4da63
two
c193497a
tree
9c134b68
three
febe6995
four
75ffdb82

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/ !

53. Thank you!
Юрий Насретдинов
nasretdinov@gmail.com