Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

История проекта, который никогда не падает / Андрей Шетухин

803 views

Published on

История проекта, который никогда не падает / Андрей Шетухин

  1. 1. История проекта, которыйникогда не падаетАндрей Шетухин
  2. 2. О докладчикеhttp://slonik-v-domene.livejournal.comhttp://stellar.moikrug.ru
  3. 3. Тема докладаРазработка онлайн-игры для FacebookВыбор новых технологийКак понять, что дела идут скверноЧто делать, когда проект не работаетКак не делать так, чтобы проект не работалНа что обратить внимание после запуска
  4. 4. Начало
  5. 5. Мы, молодая, амбициознаякоманда,..
  6. 6. ...хотим написать игру дляFacebook
  7. 7. Средняя игра для Facebook, это:100 000+ пользователей10 000 игроков онлайн3 - 5 тысяч запросов в секунду
  8. 8. А еще у нас жестко со сроками:Два месяца до сдачи прототипаТри месяца до запуска в тестированиеЧетыре месяца до первых пользователейПолгода — до продакшена
  9. 9. Выбор технологийПишем сервис с нуля, а значит можно выбрать все самоепередовое и интересноеПроблем с идеями нет — спасибо Slideshare, конференциям иOpennetВсегда интересно разобраться с новой технологией иполучить опытМы ничем не хуже других: если у них работает, то и у настоже все получится
  10. 10. Ведущий разработчик слышал,что:ZeroMQ — очередь сообщений которая выглядит как BSD-сокеты с гарантией доставки данныхMongrel — вебсервер-транслятор HTTP в ZeroMQ и обратноGoogle Protobuf — универсальный сериализатор данныхGoogle Logger — отличное решение для ведения логов
  11. 11. Ведущий разработчик не знал,что:ZeroMQ имеет ряд существенных отличий от BSD-сокетовБиблиотека C++ для Mongrel нигде толком не использоваласьСериализация в Google Protobuf требует CPUGoogle Logger вызывает НЕНАВИСТЬ у сисадминов
  12. 12. Началось проектированиеДля проверки идеи написали однопоточный сервер наZeroMQ, пример кода взяли из руководстваОт чтения примера до запуска — всего 15 минут!Затем прикрутили пару функций бизнес-логикиПроверили — все работает (на одном онлайн-пользователе)
  13. 13. Общая идея
  14. 14. Развитие идеиНам нужен один игровой сервер (лучше - два), а еще — серверсессий, кэш для БД и балансировщик запросовВзаимодействие систем построим через Google ProtobufКлиентами будут Flash (со своим протоколом обмена) иjQuery/REST
  15. 15. В теории все отлично, но естьодно «но»...
  16. 16. …или даже не одно...
  17. 17. Но мы — команда,а значит — справимся!
  18. 18. MongrelВерсия 1.7.5 еще не работает, а версия 1.8.0 уже не работаетс C++ клиентомАвтор C++ клиента уехал в Тибет искать ШамбалуИз версий 1.7.5, 1.8.0 и своих патчей собираем рабочийMongrelПатчим С++ клиентПроверяем — вроде, работает
  19. 19. Protobuf•Для каждой функции игры надо писать сериализатор изпротокола Flash в Protobuf и обратно•Таких функций десятки уже сейчас, а в будущем их будутсотни•Структуры Protobuf не имеют механизмов наследования иверсионирования•Сериализация обходится дорого по CPU и потому малопригодна для однопоточных серверов
  20. 20. Готовим прототип к запускуГеймсерверСервер сессийПрокси-кэш для БДC++ клиент для Mongrel, он же — балансировщикMongrelСервер статики - nginx
  21. 21. ЗапускПочему-то всё заметно тормозит уже на 10 пользователяхПадение одного сервиса лечится только рестартом всейсистемыПри этом при падении одного сервиса виснет вообще всёИногда система не стартует вовсеОбсчет игр 40 онлайн-пользователей занимает до 30% CPUсервера
  22. 22. ПричиныZeroMQ гарантирует доставку, поэтому то, что недоставилось при падении сервиса, доставится прирестарте. И сервис упадет еще раз.ZeroMQ требует двустороннего взаимодействия: нельзя неответить на запрос. Поэтому клиент упавшего сервисависнет в ожидании ответа.
  23. 23. У каждой проблемы естьпростое, очевидное для всехи при этомнеправильноерешение.
  24. 24. «Решение»Раз однопоточные сервисы не масштабируются, сделаем ихмногопоточнымиРестартовать всё будем при помощи скриптов и в четкойпоследовательностиКупим еще серверовНапишем миллион правил Nginx для REST
  25. 25. Что-то забыли?ZeroMQ — не BSD-сокеты (хотя и очень похоже), и вмногопоточной среде ведет себя иначеА еще у ZeroMQ есть странные проблемы с таймаутами и IPv6Перезапуск в строго заданной последовательности сервисовна разных серверах очень плохо автоматизируетсяМиллион правил Nginx для REST сложно поддерживать
  26. 26. Внимание, вопрос:
  27. 27. — Знали ли разработчики обэтих проблемах при выборетехнологии?
  28. 28. — Конечно, нет!
  29. 29. Почему?Потому, что на конференциях, в докладах и на сайтахразработчиков — сплошные success stories.А описание проблем — это списки рассылки, багтрекеры иличная переписка.И пока не столкнешься с проблемами, подводная частьайсберга не видна. Особенно, если у команды нет опытаработы с данной технологией
  30. 30. Внезапно!!!
  31. 31. Случился ДедлайнВремени «выкинуть все и переписать с нуля» нетПоэтому запускаемся «как есть», нагрузка небольшаяСразу после запуска — ревью всего проекта
  32. 32. Проект не работает, что делать?Ищем проблемные местаОцениваем стоимость переделокОцениваем рискиПланируем последовательность переделокПерезапускаем сервисы
  33. 33. ПеределкиВместо Mongrel и однопоточного балансировщика будетпроверенная и знакомая разработчикам технологияЗаменяем REST на JSON-RPC и убираем миллион правил NginxПишем врапперы к ZeroMQ для замены на BSD-сокеты.Шедулер — проверенный и работающий libevProtobuf оставляем — слишком дорого менятьЛоггер будет системный (syslog)
  34. 34. РезультатВместо неизвестных технологий используются простые ипонятныеСервисы можно рестартовать отдельно и в любойпоследовательностиСистема масштабируется на большое количество серверовТем не менее, в проекте остались плохие решения
  35. 35. — Можно ли было сделатьлучше?
  36. 36. — Да, но...
  37. 37. Если бы:Было больше времени на проектирование и рефакторингПроект еще не вышел в предпродакшенНе было других задачИ т. д., и т. п...
  38. 38. В итоге:По сравнению с тем, что было, стало лучшеОднако, определенные проблемы остались, и, видимо,исправить их полностью не получитсяТем не менее, проект запущен и работает
  39. 39. Выводы
  40. 40. Плохо:«Я где-то слышал об этой технологии»«Прототип написали по учебнику за 15 минут, весь проектзаймет неделю»«Нет проблем за ночь пропатчить основной компонент»«Разберемся по ходу дела»«На одном пользователе все работает»«Я сам буду учить новичков»
  41. 41. ХорошоКоманда продолжительное работала с этой технологиейНет проблем найти специалистовМы знаем, как растет нагрузка от числа онлайн-пользователейНовички сами учатся, не отвлекая ведущих разработчиков
  42. 42. Менеджер, помни!Новые технологии — хорошо, неизвестные технологии —плохо.Скорость разработки прототипа к скорости разработкипроекта не имеет практически никакого отношения.Сначала — архитектура всей системы, затем — частностиНет плана деплоймента — нет проекта
  43. 43. Тимлид, знай!Реклама может нести заведомо ложную информацию илипоказывать только положительные стороны технологии«Тестирование» «прототипа» на одном пользователе на своемдесктопе — не тестирование вовсе. И это — не прототипНевозможно одновременно учить новичков и писать кодВсегда надо закладывать время на непредвиденныепроблемы
  44. 44. Разработчик, будь готов к:Ошибкам в выборе технологииПереписыванию проекта под нагрузкойК тому, что зачастую единственный результат — знание, какне надо делать и что технология вам не подходит
  45. 45. Вопросы?

×