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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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