Badoo — крупнейшая в мире социальная сеть для знакомств с новыми людьми. У нас тысячи серверов в двух дата-центрах, и какие-то из них постоянно выходят из строя. Наш кластер машин состоит из различных групп: машины для обслуживания веб-запросов, серверы баз данных, хранилище фотографий, серверы для выполнения cron-заданий, машины для C/C++ сервисов и некоторые другие. Для обработки заданий по расписанию мы используем так называемые «скриптовые» машины, на которых запускаются PHP-скрипты в CLI, которые выполняют нужные действия. До недавнего момента мы использовали обычный cron для запуска скриптов по расписанию, а также самописную утилиту для того, чтобы автоматизировать процесс прописывания нужных строчек в cron. Тем не менее, разработчикам приходилось по каким-то критериям выбирать одну или несколько машин, на которых будут запускаться эти скрипты, и они жестко «привязывались» к конкретным серверам. Если какая-то из машин «падала», мы должны были вручную переносить с неё скрипты на другие машины. Чтобы равномерно распределять нагрузку по серверам, а также обеспечивать автоматическое восстановление в случае отказа (failover), мы решили сделать свое «облако», которое призвано решить эти проблемы. Доклад посвящен процессу создания «облака», а также первым результатам, которые мы получили в связи с его использованием. Краткий план доклада: - Требования к «облаку». - Существующие решения. - Распределение нагрузки по машинам. - Обработка сбоев оборудования. - Мониторинг «облака».

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
sendSMS.php
anonChat.php #1
moderation.php
config
scripts1 scripts2
facebook.php
anonChat.php #2
errorlogs.php
translate.php
anonChat.php #9
cleanup.php
scripts50
…

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

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

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

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

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

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

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

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

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

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

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