Going to extreme

Впадая в крайностиРешаем проблемы с Ruby on Rails

http://www.slideshare.net/sergeymoiseev/going-to-extreme

Monday, February 25, 13



О докладчике

• http://www.linkedin.com/in/moiseevsergey

• https://github.com/bopm

• http://www.slideshare.net/sergeymoiseev

• @SergeyMoiseev


http://www.linkedin.com/in/moiseevsergey

http://www.linkedin.com/in/moiseevsergey

https://github.com/bopm

https://github.com/bopm

В прошлых сериях

• https://vimeo.com/51198953

• http://www.slideshare.net/sergeymoiseev/migrate-4843818


https://vimeo.com/51198953

https://vimeo.com/51198953

http://www.slideshare.net/sergeymoiseev/migrate-4843818




Тема доклада

• Боль, давление, рельсы.

• Временной интервал 2011 год.

• Один из трех крупнейших купонных сервисов в РФ.


Начинаем

• У нас тут есть Drupal, что бы ты мог нам предложить.

• Его пилят свои люди, но мы не можем себе позволить больше ждать.

• Пилят уже почти год.• Админа у нас нет, но тут вроде был ДДоС.


Январь 2011 года.


План действий

• Пишем новую версию на RoR.

• Мигрируем и начинаем развивать функционал.

• Изначальная команда для разработки нового проекта - три человека.

• Одного привел, второго забрал из под увольнения.


Пишем ТЗ

• Пишем ТЗ на базе текущей системы.

• Всё на месте? Вроде да.• Окей, будем строить на базе гипотезы, что заказчик читал ТЗ внимательно.

• Вместе с воспроизведением функциональности будем делать редизайн.


Первая итерация: прототип

• Сделки, пользователи, покупки, регистрация.• Дизайн.• В процессе его разработки увольняется делавший его дизайнер.

• Придумываем сами.

• Раз нет дизайна, то нет и формально поставленной задачи.


Postgresql

• Нет извечного конфликта какой storage engine выбрать.

• Лучше тюнится.• Я умею его готовить.


Devise

• Гибкое решение по аунтефикации для Rails.

• Очень эффективно для быстрого начала разработки.

• Крайне гибкое и расширяемое.• Из минусов: написано хакерами. Излучает магию.

devise_for :users, :controllers => {:omniauth_callbacks => 'users/omniauth_callbacks'}


OmniAuth

• Поддержка множества провайдеров аунтефикации.

• Поддерживает из коробки twitter, facebook, гугл и множество других OAuth провайдеров.

• Полный список: https://github.com/intridea/omniauth/wiki/List-of-Strategies


https://github.com/intridea/omniauth/wiki/List-of-Strategies




Globalize3• Поддержка i18n на уровне базы.

• Перевод атрибутов моделей во вспомогательных таблицах.

• Большой минус тесное связывание миграции и моделей.

Используем:class Post < ActiveRecord::Base translates :title, :textend

Создаем:class CreatePosts < ActiveRecord::Migration def up create_table :posts do |t| t.timestamps end Post.create_translation_table! :title => :string, :text => :text end def down drop_table :posts Post.drop_translation_table! endend

Получаем:I18n.locale = :enpost.title # => Globalize3 rocks!

I18n.locale = :hepost.title # => גלובאלייז2 שולט!


Seed-fu• Заполнение справочников в БД.

• Позволяет вам писать сиды, которые могут быть отредактированы, дополнены и перезапущены путем ручного выбора присваеваемых в базе ID.

Locale.delete_allLocale.seed(:id, {:id => 1, :code => 'ru' }, {:id => 2, :code => 'en' }, {:id => 3, :code => 'lv' }, {:id => 4, :code => 'lt' }, {:id => 5, :code => 'ee' },)


Смена курса

• Заказчик меняет ген. дира.• Бывшего представителем заказчика на проекте.

• На месте одного заказчика - четверо.


Старая версия

• Нет VCS.

• Правят прямо на сервере.• Наощупь.• Свои люди доступны в офисе не в полном объеме, живут в одной из среднеазиатских республик.

• И да, они подчины только заказчику.


Технологии старой версии

• Один виртуальный сервер. • Который админят индусы.

• MySQL из коробки.

• MyISAM.


Самое интересное

• Заказчики не ведут формальную постановку задач при работе со старой командой.

• Как потом окажется игнорируют постановку задач вообще.

• Старая команда в свою очередь игнорирует часть задач в принципе.

• Каждый день в референсной системе появляется что-то новое.

• О чем нам забыли сказать.


Ищем выход

• С тонущей подводной лодки.

• Плюсы: у нас рельсы и написаный прототип.

• Минусы: нам нужно переломить кучу бизнес-процессов притом быстро.

• Выбираем жертву: региональное зеркало.

• Спасительное но: данные независимы.


Одновременно с этим

• Спасаем вселенную в лице старого проекта каждый день (смотри доклад DevOps).

• Трафик на проекте постоянно растет.• Боремся с ростом штата конторы с 20 до 150 человек.

• Внедряем VoIP.

• Перевозим офис на новое место за одну ночь (среды).

• Покупаем хостинг у RackSpace.

• Пишем новый массовый рассыльщик.


На дворе лето.


Миграция данных

• Главный источник проблем.

• Особенно когда база меняется без учета изменений.

• К примеру с помощью миграций в рельсах.

• В старой базе много данных относящихся к коду которого уже нет в системе.

• А то никогда и не было.


Мигрируем региональное зеркало • Начинаем в 20:00, заканчиваем к 02:30.

• Главная беда - долгая миграция данных. • Даем себе обещание переносить максимум данных заранее.

• На следующее утро узнаем, что заказчик не предупредил региональных менеджеров.

• Все оставшееся время до конца года ругаемся с ними в почте про “верните все обратно”.


Проводим очередную демонстрацию заказчику

• В таком дизайне это внедрять нельзя.

• Не важно, что мы это видели и согласилсь запускать в регионы.

• Будем делать новый дизайн.

• С кнопками как у Apple.


Нам нужны люди побольше

• Заказчик настаивает на наращивании штата.• Организует собеседования через HR.

• Плюс четыре человека в штат программистов.

• Все требуют время на себя.• Если вы не успеваете что-то, нужен PM в штат.


Миграция данных 2

• Выделяем постоянного специалиста.

• Теперь уже на основном объеме данных.

• Все прошлые проблемы плюс:

• больший объем данных;

• больше спрятанного под ковер.


Resque• Решение по созданию фоновых очередей.

• Поддерживает множественные очереди на базе Redis.

Worker:class Archive @queue = :file_serve

def self.perform(repo_id, branch = 'master') repo = Repository.find(repo_id) repo.create_archive(branch) endend

Запуск:class Repository def async_create_archive(branch) Resque.enqueue(Archive, self.id, branch) endend



• Пишем логику переноса в worker’ах.

• При логике одна задача - один пользователь выполнение слабо параллелится.


Nginx

• Один из лучших веб-серверов. Четко ложится в наши планы по развертыванию.

• Кеширует статику на фронтовых серверах.• Балансирует запросы на бековые

unicorn’ы.

• Миграция между площадками: апдейтим dns, указав в nginx proxy_pass на новое место.



Unicorn

• Hot restart.

• Долгие споры с DevOps на тему unix socket (~5-10% прироста производительности) и числа процессов на ядро.


Кнопки как у apple

• Дизайн будет делать наш человек.

• Ему и нам не интересно, что программисты думают о том, что дизайн не совместим с функционалом.

• В переписке начинает вестись практика ответа всем кроме меня.

• Приходится по каждому случаю показывать, что это не работает потому как функционал блокируется дизайном.


На дворе зима.


Кнопки как у Apple 2

• Свой человек уходит.• Как и в прошлый раз продолжаем делать своими силами.

• Но это сильно что-то напоминает.


Коммунистический субботник

• Выгоднее всего работать по ночам.

• По вечерам есть время чтобы успевать делать все накопившееся и еще чуть-чуть.

• Несмотря на это придумываются “блокеры” которые нужно сделать до запуска.

• Команда работает без выходных на регулярной основе.

• Но не вся. Новички не понимают чем обязаны.


Decision Point

• На дворе конец ноября.• Если не запустить проект сейчас, то не понятно когда его вообще запускать.


Запуск

• Ночь с пятницы на понедельник.

• Нагрузка на запущенных ранее зеркалах и основном сайте не сравнима.

• Виртуальная машина дает просадку производительности.• Вынимаем из нее бекэнд.

• Это не помогает. Бекэнды не успевают отвечать и наружу падают 504.

• Посещения падают к 4-5 утра и все кто выжил идут спать.


Запуск 2

• DevOps с бекграундом во всем вообще очень полезный человек на проекте.

• Когда он не пишет вам в общекомандный чат, что рубисты уроды и им мало руки оторвать.

• В итоге помогает профилировать приложение и говорит о просадке по GC.


Запуск 3

• Ведущий разработчик высказывает версию о том, что GC в ветке 1.9.x не должен так втыкать.

• Быстро собираем 1.9.2 и стабилизируем поток 504тых.

• К концу суток с момента начала работ по запуску можно выдохнуть.


Новая прекрасная жизнь

• Все недовольны.

• Верните как было.• Я не знаю как этим пользоваться.

• У нас не сходятся цифры.

• С начала жизни проекта.



• Все чистые данные на месте, но есть куча проблемных.

• Остатки на счетах съедают нам мозги.

• Правим-перезапускаем-правим.

• Поздняя домиграция. Ставим миграционный таск в очередь при попытке логина.


Деплой

• Больше всего времени съедает перекомпиляция ресурсов.

• Сейчас для того же использую Turbo-sprockets-rails3.

• Тогда в качестве process monitoring был god, сейчас bluepill.


Производительность

• Слишком интерактивная главная страница.

• Переписываем на статическую компоновку главной страницы с выполнением операций показа скрытия акций по cron.

• Фрагментарное кеширование. Его никогда не бывает много.

• В итоге последние цифры которые я видел 150rps на бекэнде. В рельсах.

• В начале года было 20rps на единственном сервере.

• Лендинги. Самое проблемное место в проекте. Нужно писать тонны лидовых данных. Для пользователей которые еще не пользователи. И могут ими не стать.


Sinatra

• Младший брат RoR, фреймворк для создания однофайловых веб-приложений.

• Создание лендинговых страниц без полного инстанцирования модельного слоя.

• В целом гипотеза была ошибочной, стабилизировать лендинги на синатре мы так и не смогли.

• Говорят async_sinatra помогает, но пробовать пока негде.


О высоких нагрузках

• Вы стоите под очень толстой струей воды.

• Пока написанный вами код пропускает ее через себя без задержки, вы ее не замечаете.

• Как только он начинает лагать, последовательно наедается все.

• Кошмар заказчика - 504тые по всем фронтам.

• До тех пор пока в команде кто-то не понимает, что он пишет, любой деплой - катастрофа.


Климат

• http://issendai.livejournal.com/572510.html

• Хочешь привязать к себе людей, держи их слишком занятыми чтобы думать.

• Все задачи идут мимо jira.

• Большинство противоречат друг-другу по приоритетам.

• Релиз в начале декабря, к 20тым числам проект стабилизирован.


http://issendai.livejournal.com/572510.html

http://issendai.livejournal.com/572510.html

Климат 2

• Ведущий разработчик требует время на стабилизацию проекта.

• Заказчик требует все переделать.• Каждый день.• Я беру отпуск по уходу за рассудком.


Климат 3

• В отпуск мне сообщают, что я все испортил.

• Что ничего не работает (команда говорит обратное).

• Знакомые говорят, что их собеседуют на моё место.

• Мне отменяют премию за запуск.


Внутренние цели

• На протяжении всего года я говорил себе, что взявшись за проект я не могу позволить его бросить на середине.

• Начинает возникать понимание.• Что проект закончен.• Лучше чем сейчас мне его не сделать.

• А что терять - есть.


Итог

• В первый рабочий день 2012 года я подаю заявление об увольнении.

• В течении нескольких месяцев все региональные зеркала переведены на новый RoR движок.

• Команда постепенно увольняется.• Заменяясь аутсорсерами.


Выученные уроки

• Дизайн нельзя менять вместе с платформой.

• Дизайн нельзя менять не понимая, что продает.

• Рельсы позволяют соревноваться по скорости с самым пытливым умом.

• Но не когда их четыре.


P.S.


Благодарности

• Андрею, Антону, Лёше, Антону, Степану, Петру, Толе, Сергею, Леониду, Диме и Саше за то, что мы сделали вместе.

• Джасуру, Шавкату, Комилу и Беку за бесценный опыт и то, что теперь я могу всё.


Другой взгляд на события

• http://www.slideshare.net/alexclear/ruby-13262249

• Наш DevOps.


http://www.slideshare.net/alexclear/ruby-13262249




Technology

Going to extreme