3. Тема доклада
Разработка онлайн-игры для Facebook
Выбор новых технологий
Как понять, что дела идут скверно
Что делать, когда проект не работает
Как не делать так, чтобы проект не работал
На что обратить внимание после запуска
9. Средняя игра для Facebook, это:
100 000+ пользователей
10 000 игроков онлайн
3 - 5 тысяч запросов в секунду
10. А еще у нас жестко со сроками:
Два месяца до сдачи прототипа
Три месяца до запуска в тестирование
Четыре месяца до первых пользователей
Полгода — до продакшена
11. Выбор технологий
Пишем сервис с нуля, а значит можно выбрать все самое
передовое и интересное
Проблем с идеями нет — спасибо Slideshare, конференциям и
Opennet
Всегда интересно разобраться с новой технологией и
получить опыт
Мы ничем не хуже других: если у них работает, то и у нас
тоже все получится
12. Ведущий разработчик слышал,
что:
ZeroMQ — очередь сообщений которая выглядит как BSD-
сокеты с гарантией доставки данных
Mongrel — вебсервер-транслятор HTTP в ZeroMQ и обратно
Google Protobuf — универсальный сериализатор данных
Google Logger — отличное решение для ведения логов
13. Ведущий разработчик не знал,
что:
ZeroMQ имеет ряд существенных отличий от BSD-сокетов
Библиотека C++ для Mongrel нигде толком не использовалась
Сериализация в Google Protobuf требует CPU
Google Logger вызывает НЕНАВИСТЬ у сисадминов
14. Началось проектирование
Для проверки идеи написали однопоточный сервер на
ZeroMQ, пример кода взяли из руководства
От чтения примера до запуска — всего 15 минут!
Затем прикрутили пару функций бизнес-логики
Проверили — все работает (на одном онлайн-пользователе)
16. Развитие идеи
Нам нужен один игровой сервер (лучше - два), а еще — сервер
сессий, кэш для БД и балансировщик запросов
Взаимодействие систем построим через Google Protobuf
Клиентами будут Flash (со своим протоколом обмена) и
jQuery/REST
21. Mongrel
Версия 1.7.5 еще не работает, а версия 1.8.0 уже не работает
с C++ клиентом
Автор C++ клиента уехал в Тибет искать Шамбалу
Из версий 1.7.5, 1.8.0 и своих патчей собираем рабочий
Mongrel
Патчим С++ клиент
Проверяем — вроде, работает
22. Protobuf
•
Для каждой функции игры надо писать сериализатор из
протокола Flash в Protobuf и обратно
•
Таких функций десятки уже сейчас, а в будущем их будут
сотни
•
Структуры Protobuf не имеют механизмов наследования и
версионирования
•
Сериализация обходится дорого по CPU и потому мало
пригодна для однопоточных серверов
23. Готовим прототип к запуску
Геймсервер
Сервер сессий
Прокси-кэш для БД
C++ клиент для Mongrel, он же — балансировщик
Mongrel
Сервер статики - nginx
24. Запуск
Почему-то всё заметно тормозит уже на 10 пользователях
Падение одного сервиса лечится только рестартом всей
системы
При этом при падении одного сервиса виснет вообще всё
Иногда система не стартует вовсе
Обсчет игр 40 онлайн-пользователей занимает до 30% CPU
сервера
26. Причины
ZeroMQ гарантирует доставку, поэтому то, что не
доставилось при падении сервиса, доставится при
рестарте. И сервис упадет еще раз.
ZeroMQ требует двустороннего взаимодействия: нельзя не
ответить на запрос. Поэтому клиент упавшего сервиса
виснет в ожидании ответа.
27. У каждой проблемы есть
простое, очевидное для всех
и при этом
неправильное
решение.
28. «Решение»
Раз однопоточные сервисы не масштабируются, сделаем их
многопоточными
Рестартовать всё будем при помощи скриптов и в четкой
последовательности
Купим еще серверов
Напишем миллион правил Nginx для REST
29. Что-то забыли?
ZeroMQ — не BSD-сокеты (хотя и очень похоже), и в
многопоточной среде ведет себя иначе
А еще у ZeroMQ есть странные проблемы с таймаутами и IPv6
Перезапуск в строго заданной последовательности сервисов
на разных серверах очень плохо автоматизируется
Миллион правил Nginx для REST сложно поддерживать
33. Почему?
Потому, что на конференциях, в докладах и на сайтах
разработчиков — сплошные success stories.
А описание проблем — это списки рассылки, багтрекеры и
личная переписка.
И пока не столкнешься с проблемами, подводная часть
айсберга не видна. Особенно, если у команды нет опыта
работы с данной технологией
35. Случился Дедлайн
Времени «выкинуть все и переписать с нуля» нет
Поэтому запускаемся «как есть», нагрузка небольшая
Сразу после запуска — ревью всего проекта
36. Проект не работает, что делать?
Ищем проблемные места
Оцениваем стоимость переделок
Оцениваем риски
Планируем последовательность переделок
Перезапускаем сервисы
37. Переделки
Вместо Mongrel и однопоточного балансировщика будет
проверенная и знакомая разработчикам технология
Заменяем REST на JSON-RPC и убираем миллион правил Nginx
Пишем врапперы к ZeroMQ для замены на BSD-сокеты.
Шедулер — проверенный и работающий libev
Protobuf оставляем — слишком дорого менять
Логгер будет системный (syslog)
38. Результат
Вместо неизвестных технологий используются простые и
понятные
Сервисы можно рестартовать отдельно и в любой
последовательности
Система масштабируется на большое количество серверов
Тем не менее, в проекте остались плохие решения
42. Если бы:
Было больше времени на проектирование и рефакторинг
Проект еще не вышел в предпродакшен
Не было других задач
И т. д., и т. п...
43. В итоге:
По сравнению с тем, что было, стало лучше
Однако, определенные проблемы остались, и, видимо,
исправить их полностью не получится
Тем не менее, проект запущен и работает
45. Плохо:
«Я где-то слышал об этой технологии»
«Прототип написали по учебнику за 15 минут, весь проект
займет неделю»
«Нет проблем за ночь пропатчить основной компонент»
«Разберемся по ходу дела»
«На одном пользователе все работает»
«Я сам буду учить новичков»
46. Хорошо
Команда продолжительное работала с этой технологией
Нет проблем найти специалистов
Мы знаем, как растет нагрузка от числа онлайн-пользователей
Новички сами учатся, не отвлекая ведущих разработчиков
47. Менеджер, помни!
Новые технологии — хорошо, неизвестные технологии —
плохо.
Скорость разработки прототипа к скорости разработки
проекта не имеет практически никакого отношения.
Сначала — архитектура всей системы, затем — частности
Нет плана деплоймента — нет проекта
48. Тимлид, знай!
Реклама может нести заведомо ложную информацию или
показывать только положительные стороны технологии
«Тестирование» «прототипа» на одном пользователе на своем
десктопе — не тестирование вовсе. И это — не прототип
Невозможно одновременно учить новичков и писать код
Всегда надо закладывать время на непредвиденные
проблемы
49. Разработчик, будь готов к:
Ошибкам в выборе технологии
Переписыванию проекта под нагрузкой
К тому, что зачастую единственный результат — знание, как
не надо делать и что технология вам не подходит