HighLoad++ 2013

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

2. Badoo
• 195+ млн пользователей
• 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. Существующие решения:
•
SLURM
•
Mesos
•
ZooKeeper
•
• Beanstalk
Scalr
•
Gearman

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

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

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

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

15. Heartbeat
каждые 10 секунд
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. Распределение нагрузки
• Много «облачных» машин (около 100)
• Хотим добавить все машины (около 1000)
• Если машина загружена выше 70% —
новые задания на неё не попадают
•
Алгоритм постоянно улучшается с учётом
потребностей и полученных результатов

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

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

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

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

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

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

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

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

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

32. Падение управляющей машины
Вручную переносим все скрипты
на другую машину (5 минут)

33. «Падение» базы данных
•
• Заливаем «чистую» базу (только настройки
Задания генерируются по расписанию!
скриптов)
• Убиваем все запущенные задания в «облаке»
• Перезапускаем управляющие скрипты
Downtime — 30 минут
•

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