Доклад Юрия Насретдинова на конференции Application Developer Days-4. г.Минск 13 декабря 2013

1. Badoo в облаках
(решение для запуска cli-скриптов в облаке собственной разработки)
!
Юрий Насретдинов, Badoo

2. Badoo
•
199+ млн пользователей
•
PHP-FPM: 40+ тыс запросов в сек
•
160 тыс регистраций в день
•
4 млн фото / видео в день
•
50 языков интерфейса
•
2 000+ серверов

3. О чём этот доклад
•
Как мы запускали cron-задания до введения
«облака»
•
Требования к новому «облаку»
•
Существующие решения
•
Общая архитектура
•
Концепция «заданий»
•
Распределение нагрузки
•
Отказоустойчивость

4. Cron
•
1 000 различных скриптов (cron-заданий)
•
Время работы — от 0,1 сек до нескольких
суток
•
Мало CPU-bound скриптов (в основном
нужна память или сеть)
•
Параллельная обработка с помощью fork()
•
2 000 000 строк кода

5. Cron: mcron
config
sendSMS.php
anonChat.php #1
moderation.php
facebook.php
anonChat.php #2
errorlogs.php
scripts1
scripts2
…
translate.php
anonChat.php #9
cleanup.php
scripts50

6. Cron: mcron
config
sendSMS.php
anonChat.php #1
moderation.php
facebook.php
anonChat.php #2
errorlogs.php
scripts1
scripts2
…
translate.php
anonChat.php #9
cleanup.php
scripts50

7. Cron: mcron
config
sendSMS.php
facebook.php
anonChat.php #1
moderation.php
google.php
anonChat.php #2
anonChat.php #3
migration.php
scripts1
scripts3
…
translate.php
errorlogs.php
anonChat.php #9
cleanup.php
scripts50

8. Cron: недостатки
•
Жесткая привязка скриптов к конкретным
машинам
•
«Ручная» балансировка нагрузки
•
Сложный мониторинг запуска заданий
•
Ручной перенос скриптов в случае
«падения»
•
Downtime — несколько часов

9. «Облако»
•
Равномерное распределение
нагрузки по серверам
•
Отказоустойчивость
•
Понятный мониторинг
•
Запуск заданий по расписанию

10. Существующие решения:
•
Gearman
•
SLURM
•
Mesos
•
ZooKeeper
•
Beanstalk
•
Scalr

11. Существующие решения:
SLURM
•
SLURM мы больше всего исследовали
•
2 базовых алгоритма балансировки:
round-robin и последовательная
полная загрузка машины
•
Заточен под математические расчеты,
MPI
•
Не учитывает нагрузку на машине?

12. Существующие решения:
Gearman
•
Создан для синхронной обработки
событий
•
Непрозрачный failover
•
Предполагает наличие
фиксированных worker’ов
•
Нам придется переписывать весь наш
код

13. Решили писать своё
решение

14. Общая архитектура
phproxyd
phproxyd
phproxyd
phproxyd

15. Общая архитектура
phproxyd
phproxyd
phproxyd
phproxyd

16. Введение в строй новой машины
•
Админ: Поставить сервер в стойку
•
Админ: Поставить ОС (xCAT)
•
Админ: Поставить PHP и phproxyd
(puppet)
•
Админ: Прописать heartbeat в cron
•
Программист: радоваться

17. Добавление нового скрипта
Никакой консоли, никакого SVN,
никаких mcron через SSH!

19. «Задания»
•
Задание — запуск скрипта (!)
•
Генерируются с заданной периодичностью
или добавляются через специальный API
•
Должно обрабатываться строго одним
потребителем
•
CAP-теорема (Consistency, Availability, Partition
Tolerance)
•
«Поколения» заданий

20. Распределение нагрузки
•
«Попугаи»
•
Round-robin с весами (по машинам с
наибольшим количеством свободных
«попугаев»)
•
Виртуальное потребление ресурсов
•
Учитывается только свободные CPU и
память на машине

21. Распределение нагрузки
обновляется каждые 10 секунд
1000
300
600
250
2000
230
round-robin
1000
200
2000
180

22. Распределение нагрузки

23. Распределение нагрузки
•
Много «облачных» машин (около 100)
•
Хотим добавить все машины (около 1000)
•
Если машина загружена выше 70% —
новые задания на неё не попадают
•
Алгоритм постоянно улучшается с учётом
потребностей и полученных результатов

24. Реализация
•
Java?
•
Erlang?
•
C?
•
Go?
•
PHP !

25. Реализация: phproxyd
•
Демон на C, писался для других
целей
•
Умеет запускать PHP-скрипты
•
А также следить за ними
•
Пишется на Go примерно за 2 дня
•
Что мы и сделали

26. Реализация: управляющая логика
•
Несколько процессов, работающих в
while(true)
•
Раз в 10 минут всем посылается SIGTERM
•
Максимальное время простоя «облака» — 10
минут
•
Генерация заданий — один процесс
•
Запуск заданий — N процессов, зависит от
общего числа машин в облаке

27. Пример скрипта (до «облака»)

28. Пример скрипта (наше время)

29. Отказоустойчивость
•
«Падение» машины в облаке
•
Проблемы с сетью
•
Проблемы с конфигурацией машин
•
«Падение» базы данных
•
«Падение» мастер-узла

30. Падение «облачной» машины
•
Машина не отвечает нам по сети, но может
продолжать выполнять отданные ей задания
•
Решение — alarm(2), SIGALRM
•
Если задание выполняется больше
отведенного времени, благодаря alarm(2) мы
можем быть уверены, что оно завершилось
•
Максимальный простой определяется
временем работы скрипта

31. Проблемы с сетью
•
Heartbeat перестанет работать —
мониторинг это увидит
•
Жесткие таймауты на обращения к
phproxyd
•
PHP-скрипты «зависнут» — через 10
минут придет SIGTERM
•
Нарушение связности сети: alarm(2) нас
спасет

32. Проблемы с конфигурацией
Проблемы с
конфигурацией машин
решает мониторинг

33. Падение управляющей машины
Другая машина
автоматически становится
«мастером» (без задержки)

34. «Падение» базы данных
•
Master-slave репликация
•
В случае «падения» мастера
переключение происходит
автоматически с помощью service ip

35. Вопросы
Юрий Насретдинов, Badoo (http://badoo.com/)
!
http://habrahabr.ru/company/badoo/
http://habrahabr.ru/users/yourock/
@YNasretdinov
y.nasretdinov@corp.badoo.com