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

739 views
610 views

Published on

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

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
739
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Badoo в облаках (решение для запуска cli-скриптов в облаке собственной разработки) ! Юрий Насретдинов, Badoo
  2. 2. Badoo • 199+ млн пользователей • PHP-FPM: 40+ тыс запросов в сек • 160 тыс регистраций в день • 4 млн фото / видео в день • 50 языков интерфейса • 2 000+ серверов
  3. 3. О чём этот доклад • Как мы запускали cron-задания до введения «облака» • Требования к новому «облаку» • Существующие решения • Общая архитектура • Концепция «заданий» • Распределение нагрузки • Отказоустойчивость
  4. 4. Cron • 1 000 различных скриптов (cron-заданий) • Время работы — от 0,1 сек до нескольких суток • Мало CPU-bound скриптов (в основном нужна память или сеть) • Параллельная обработка с помощью fork() • 2 000 000 строк кода
  5. 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. 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. 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. 8. Cron: недостатки • Жесткая привязка скриптов к конкретным машинам • «Ручная» балансировка нагрузки • Сложный мониторинг запуска заданий • Ручной перенос скриптов в случае «падения» • Downtime — несколько часов
  9. 9. «Облако» • Равномерное распределение нагрузки по серверам • Отказоустойчивость • Понятный мониторинг • Запуск заданий по расписанию
  10. 10. Существующие решения: • Gearman • SLURM • Mesos • ZooKeeper • Beanstalk • Scalr
  11. 11. Существующие решения: SLURM • SLURM мы больше всего исследовали • 2 базовых алгоритма балансировки: round-robin и последовательная полная загрузка машины • Заточен под математические расчеты, MPI • Не учитывает нагрузку на машине?
  12. 12. Существующие решения: Gearman • Создан для синхронной обработки событий • Непрозрачный failover • Предполагает наличие фиксированных worker’ов • Нам придется переписывать весь наш код
  13. 13. Решили писать своё решение
  14. 14. Общая архитектура phproxyd phproxyd phproxyd phproxyd
  15. 15. Общая архитектура phproxyd phproxyd phproxyd phproxyd
  16. 16. Введение в строй новой машины • Админ: Поставить сервер в стойку • Админ: Поставить ОС (xCAT) • Админ: Поставить PHP и phproxyd (puppet) • Админ: Прописать heartbeat в cron • Программист: радоваться
  17. 17. Добавление нового скрипта Никакой консоли, никакого SVN, никаких mcron через SSH!
  18. 18. «Задания» • Задание — запуск скрипта (!) • Генерируются с заданной периодичностью или добавляются через специальный API • Должно обрабатываться строго одним потребителем • CAP-теорема (Consistency, Availability, Partition Tolerance) • «Поколения» заданий
  19. 19. Распределение нагрузки • «Попугаи» • Round-robin с весами (по машинам с наибольшим количеством свободных «попугаев») • Виртуальное потребление ресурсов • Учитывается только свободные CPU и память на машине
  20. 20. Распределение нагрузки обновляется каждые 10 секунд 1000 300 600 250 2000 230 round-robin 1000 200 2000 180
  21. 21. Распределение нагрузки
  22. 22. Распределение нагрузки • Много «облачных» машин (около 100) • Хотим добавить все машины (около 1000) • Если машина загружена выше 70% — новые задания на неё не попадают • Алгоритм постоянно улучшается с учётом потребностей и полученных результатов
  23. 23. Реализация • Java? • Erlang? • C? • Go? • PHP !
  24. 24. Реализация: phproxyd • Демон на C, писался для других целей • Умеет запускать PHP-скрипты • А также следить за ними • Пишется на Go примерно за 2 дня • Что мы и сделали
  25. 25. Реализация: управляющая логика • Несколько процессов, работающих в while(true) • Раз в 10 минут всем посылается SIGTERM • Максимальное время простоя «облака» — 10 минут • Генерация заданий — один процесс • Запуск заданий — N процессов, зависит от общего числа машин в облаке
  26. 26. Пример скрипта (до «облака»)
  27. 27. Пример скрипта (наше время)
  28. 28. Отказоустойчивость • «Падение» машины в облаке • Проблемы с сетью • Проблемы с конфигурацией машин • «Падение» базы данных • «Падение» мастер-узла
  29. 29. Падение «облачной» машины • Машина не отвечает нам по сети, но может продолжать выполнять отданные ей задания • Решение — alarm(2), SIGALRM • Если задание выполняется больше отведенного времени, благодаря alarm(2) мы можем быть уверены, что оно завершилось • Максимальный простой определяется временем работы скрипта
  30. 30. Проблемы с сетью • Heartbeat перестанет работать — мониторинг это увидит • Жесткие таймауты на обращения к phproxyd • PHP-скрипты «зависнут» — через 10 минут придет SIGTERM • Нарушение связности сети: alarm(2) нас спасет
  31. 31. Проблемы с конфигурацией Проблемы с конфигурацией машин решает мониторинг
  32. 32. Падение управляющей машины Другая машина автоматически становится «мастером» (без задержки)
  33. 33. «Падение» базы данных • Master-slave репликация • В случае «падения» мастера переключение происходит автоматически с помощью service ip
  34. 34. Вопросы Юрий Насретдинов, Badoo (http://badoo.com/) ! http://habrahabr.ru/company/badoo/ http://habrahabr.ru/users/yourock/ @YNasretdinov y.nasretdinov@corp.badoo.com

×