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

!

Юрий Насретдинов, Badoo
Badoo
• 195+ млн пользователей

• PHP-FPM: 40+ тыс запросов в сек

• 160 тыс регистраций в день

• 4 млн фото / видео в день

• 50 языков интерфейса

• 2 000+ серверов
О чём этот доклад
• Как мы запускали cron-задания до введения «облака»

• Требования к новому «облаку»

• Существующие решения

• Общая архитектура

• Концепция «заданий»

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

• Отказоустойчивость
Cron
• 1 000 различных скриптов (cron-заданий)

• Время работы — от 0,1 сек до нескольких суток

• Мало CPU-bound скриптов (в основном нужна
память или сеть)


• Параллельная обработка с помощью fork()

• 2 000 000 строк кода
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
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
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
Cron: недостатки

•

Жесткая привязка скриптов к конкретным
машинам


• «Ручная» балансировка нагрузки

• Сложный мониторинг запуска заданий

• Ручной перенос скриптов в случае «падения»

Downtime — несколько часов
•
«Облако»

•

Равномерное распределение нагрузки
по серверам


•
Понятный мониторинг

•
Запуск заданий по расписанию
•
Отказоустойчивость
Существующие решения:

•
SLURM

•
Mesos

•
ZooKeeper

•
• Beanstalk

Scalr
•
Gearman
Существующие решения:
SLURM

• SLURM мы больше всего исследовали

• 2 базовых алгоритма балансировки: round-robin
и последовательная полная загрузка машины


• Заточен под математические расчеты, MPI

• Не учитывает нагрузку на машине?
Существующие решения:
Gearman

• Создан для синхронной обработки событий

• Непрозрачный failover

• Предполагает наличие фиксированных
worker’ов


• Нам придется переписывать весь наш код
Решили писать своё решение
Общая архитектура

phproxyd

phproxyd

phproxyd

phproxyd
Heartbeat
каждые 10 секунд

phproxyd

phproxyd

phproxyd

phproxyd
Введение в строй новой машины

• Админ: Поставить сервер в стойку

• Админ: Поставить ОС (xCAT)

• Админ: Поставить PHP и phproxyd (puppet)

Админ: Прописать heartbeat в cron

•
• Программист: радоваться
Добавление нового скрипта
Никакой консоли, никакого SVN,
никаких mcron через SSH!
«Задания»
• Задание — запуск скрипта (!)

• Генерируются с заданной периодичностью или
добавляются через специальный API


• Должно обрабатываться строго одним потребителем

• CAP-теорема (Consistency, Availability, Partition Tolerance)


• «Поколения» заданий
Распределение нагрузки

• «Попугаи»

• Round-robin (по машинам с наибольшим
количеством свободных «попугаев»)


• Виртуальное потребление ресурсов

Учитывается только свободные CPU и
•
память на машине
Распределение нагрузки
обновляется каждые 10 секунд

1000	

300

600	

250

2000	

230

round-robin

1000	

200

2000	

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

• Много «облачных» машин (около 100)

• Хотим добавить все машины (около 1000)

• Если машина загружена выше 70% —
новые задания на неё не попадают


•

Алгоритм постоянно улучшается с учётом
потребностей и полученных результатов
Реализация

•
Erlang?

•
C?

•
Go?

•
PHP !
•
Java?
Реализация: phproxyd

• Демон на C, писался для других целей

• Умеет запускать PHP-скрипты
А также следить за ними

•
Пишется на Go примерно за 2 дня

•
• Что мы и сделали
Реализация: управляющая логика

• Несколько процессов, работающих в while(true)

• Раз в 10 минут всем посылается SIGTERM
• Максимальное время простоя «облака» — 10 минут

• Генерация заданий — один процесс

• Запуск заданий — N процессов, зависит от общего
числа машин в облаке
Пример скрипта (до «облака»)
Пример скрипта (наше время)
Отказоустойчивость

•
• Проблемы с сетью

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

•
«Падение» базы данных

•
«Падение» мастер-узла
•
«Падение» машины в облаке
Падение «облачной» машины
• Машина не отвечает нам по сети, но может продолжать
выполнять отданные ей задания


• Решение — alarm(2), SIGALRM

• Если задание выполняется больше отведенного времени,
благодаря alarm(2) мы можем быть уверены, что оно
завершилось


• Максимальный простой определяется временем работы
скрипта
Проблемы с сетью

• Heartbeat перестанет работать — мониторинг
это увидит


• Жесткие таймауты на обращения к phproxyd

• PHP-скрипты «зависнут» — через 10 минут
придет SIGTERM


• Нарушение связности сети: alarm(2) нас спасет
Проблемы с конфигурацией
Проблемы с конфигурацией
машин решает мониторинг
Падение управляющей машины

Вручную переносим все скрипты
на другую машину (5 минут)
«Падение» базы данных

•
• Заливаем «чистую» базу (только настройки
Задания генерируются по расписанию!

скриптов)


• Убиваем все запущенные задания в «облаке»

• Перезапускаем управляющие скрипты

Downtime — 30 минут
•
Вопросы
Юрий Насретдинов, Badoo (http://badoo.com/)

!

http://habrahabr.ru/company/badoo/

http://habrahabr.ru/users/yourock/

@YNasretdinov

y.nasretdinov@corp.badoo.com

Юрий Насретдинов, Badoo