Инструменты для проекта на .NET и JavaScript: TDD, PostgreSQL и российское облако

В предыдущей статье рассказал инструментах, которые используются в ByndyuSoft. На этот раз опишу проект, который делался через TDD, на PostgreSQL и российском облаке Infobox.

Что за проект?

Предметная область продукта — наружная видео-реклама на мониторах в транспорте. Управление мониторами работает через единый веб-интерфейс. Если вы пользуетесь общественным транспортом, то видели эти мониторы в трамваях и троллейбусах.

Заказчики пришли к нам с готовым бизнесом — 10 лет опыта на рынке, первые в России, кто создает мониторы и встроенное ПО от сборки до сопровождения. За время роста бизнеса в IT накопились технические и дизайнерские долги. IT тормозило развитие компании, понадобился новый подход и свежие решения.

Основные характеристики

• В БД приходит 1К+ запросов в секунду на запись и 2К+ запросов на чтение.
• CQRS со связкой сырых данных и проекций через очередь сообщений на RabbitMQ. И сырые данные, и проекции хранятся PostgreSQL.
• Объем двух БД 100ГБ+, базы постоянно растут из-за увеличения кол-ва мониторов. БД растет по 1ГБ+ в день.
• Балансировка нагрузки на веб с помощью IIS
• Балансировка нагрузки расчетов через очереди на RabbitMQ
• Около 20 виртуальных машин под Windows Server и Ubuntu на Infobox

TDD, PostgreSQL и российское облако

Успех через TDD

Создание IT-продуктов в ByndyuSoft идет по процессу, который реализует ценности и принципы Agile и Lean. Подробное описание процесса в этой статье. Этот продукт мы делали по тому же процессу.

Начали погружение в тему с Impact Mapping. В ходе общения выяснилось, что важно убрать руководителей компании из операционного управления IT-инфраструктурой, чтобы работа с контрагентами, составление видео-эфира и другие рутинные действия делались в автоматическом режиме.

Мы выдвинули гипотезу, что возможно реализовать составление эфира в автоматическом режиме, создать прогноз загрузки эфира и т.д. Тот, кто реализовывал алгоритмы составления эфира, знает сложность подобной задачи. Составление эфира — задача теории расписаний, но с нюансами. Например, коммерческий контент должен выходить в строго определенные промежутки времени или возле назначенной гео-локации, а некоммерческий контент может появится в эфире в любой момент времени, но ролики должны выходить в выбранной последовательности.

Кроме этого в алгоритме учитывается, что эфир меняется динамически в любой момент, видео-ролики могут быть любой длины, сами алгоритмы запускаются на мониторах с ограниченными вычислительными ресурсами, мониторы теряют связь с сервером, включаются и выключаются в любой момент и ещё пара десятков условий. Этот набор условий и ограничений делал автоматизированную работу с эфиром трудно реализуемой.

Тем не менее мы предложили реализовать алгоритмы и бизнес-логику, которые до нас не формализовались. Здесь в полный рост помог Domain Driven Design и Test Driven Development.

Заказчикам было сложно согласится на такие изменения в работе, т.к. из-за формализации и автоматизации поменялся бы подход к работе. Кроме этого мы могли не реализовать алгоритмы за приемлемое время. Что если мы затянем с исследованием алгоритмов и в итоге не создадим работающее ПО? Чтобы снизить риски, мы предложили сделать прототип критичных функций за месяц.

Чистый TDD

Первый месяц я сам через TDD писал код. Благодаря тестам удалось реализовать и в будущем развивать алгоритмы, не боясь сломать уже работавшее. Через месяц мы доказали, что алгоритмы и бизнес-логика реализуема и создали ПО, которое работало по новым алгоритмам.

TDD использовалось как инструмент для коротких экспериментов. Я делал гипотезу, писал тест, реализовывал, смотрел как поменялись результаты алгоритма на текущем тесте и как изменения в алгоритме повлияли на предыдущие тесты. Стало хуже? Откатываем изменения и проверяем следующую гипотезу. Стало лучше? Значит идем в правильном направлении.

Начало теста по составлению эфира:

[Test]
public void IgnoreAdsIfEndDateIsNotReached()
{
 var entertainmentVideo1 = new Video(VideoType.Noncommercial, 30) {Id = 1};

 var adsVideo1 = new Video(VideoType.Ads, 10) {Id = 2};
 var adsCampaign = new AdsCampaign(adsVideo1, 120, new DateTime(2014, 09, 10), new DateTime(2014, 10, 25));

 var videoTimeline = new VideoTimeline(new List<AdsCampaign> {adsCampaign},
  new List<NoncommercialContent> {new NoncommercialContent(entertainmentVideo1)}, new DateTime(2015, 09, 09), 30);

 IEnumerable<TimelineItem> playlist = videoTimeline.CreatedPlaylist;

Хостинг Infobox

Хостинг изначально искали облачный, выбирали среди нескольких десятков. Infobox привлек ценами и тем, что там трудится Юрий Трухин.

До Infobox мы 3 года работали с AWS и Azure, а с российскими облачными решениями мы не сталкивались. С Infobox начали работу в октябре 2014 года. В тот момент нужные сервера с SSD-дисками у них находились только в Европе. Поэтому первую инфраструктуры мы разворачивали в Европе, но хостеры обещали настроить требуемые нам мощности до конца 2014 года в России. Дело в том, что на мониторы выводится видео-контент и информация МЧС и других спец. служб. Из-за интеграции с этими службами, сервера должны размещаться в России.

Infobox купили и настроили SSD-диски незадолго до релиза нашего продукта, заодно они  сами перенесли нам виртуалки из Европы на хостинг в Россию. Вот тут случился первый фейл. При переносе виртуалок они не перенесли настройки фаервола, точнее фаервол выключили, порты по-умолчанию оказались открыты. Системный администратор обнаружил подозрительную активность на серверах БД, из-за которых виртуалки могли быть скомпрометированы. Пришлось пересоздавать часть виртуальных машин, чтобы не подвергать остальные сервера риску.

Дальнейшая работа с Infobox принесла нам много проблем. Раз в неделю обнаруживалась проблема, правда чинили они в течение пары часов. После каждого фейла предлагали нам скидку на следующий месяц, так что полгода мы жили со скидкой на хостинг.

Вспоминается один случай, который происходил в день показа инвесторам. У Infobox упала хост машина и мы ждали восстановления сутки. После этого случая мы в серьез задумались о переезде на другой хостинг.

Что я скажу о Infobox после полутора лет работы? Они заработали без сбоев (тьфу-тьфу). Уже полгода мы не вспоминаем о проблемах с хостингом. Цены у них по-прежнему приятные.

PostgreSQL

До PostgreSQL мы имели дело с нагрузками на БД и объемами данных от 100ГБ до 2ТБ на MSSQL, Sphinx, MongoDB, CouchDB, elasticsearch и других реляционных и нереляционных СУБД. PostgreSQL привлекла в первую очередь набором функций и зрелостью. Плюсом для клиентов было то, что не требуются лицензии на СУБД.

В проекте работает две базы на PostgreSQL. Одна используется для хранения сырых данных, а во второй хранятся насчитанные данные и доменные сущности. В среднем нагрузка в 1К+ запросов в секунду на запись и 2К+ запросов на чтение. Объем двух БД 100ГБ+, базы постоянно растут из-за увеличения кол-ва мониторов. БД растет по 1ГБ+ в день.

Я вижу два минуса PostgreSQL, которые затрудняют работу с этой СУБД:

1. Из коробки PostgreSQL готов на минимальную нагрузку и отсутствие параллельной работы на нескольких процессорах. После установки рекомендую найти руководства по настройке этой СУБД.
2. Инструменты для работы с PostgreSQL сводятся к командной строке. Если вы привыкли к MSSQL Profiler или Tuning Advisor, то забудьте о них. С PostgreSQL вы погрузитесь в команды в консоле и псевдографику. Сами разработчики и консультанты PostgreSQL не видят в этом проблемы. Я неоднократно задавал вопросы на тему визуальных инструментов в группе PostgreSQL в России, но там подобные вопросы или не понимают, или предлагают самостоятельно написать нужный инструмент.

Front-end

Пользователи работают с системой через браузер. UI сделан как JS-приложение с единой точкой входа. Основные библиотеки:

• sass (grunt-sass, grunt-autoprefixer)
• RequireJS (grunt-contrib-requirejs)
• Скрипты собираются автоматически посредством node.exe
• jQuery UI и несколько других плагинов
• underscore: использование шаблонов
• d3.js: используется для рисования графиков
• tools: инструментальная библиотека для работы с различными типами данных

Другие инструменты

Часть инструментов обсудили в прошлой статье, поэтому здесь пишу их списком:

• ASP.NET MVC, WebAPI, Windows-сервисы и другие стандартные инструменты для .NET Framework
• Git
• log4net
• IIS
• zabbix
• dapper

Результаты и выводы

Сейчас эта система работает на СНГ, образцы уже есть у потенциальных клиентов по всему миру. Заказчики считают этот проект успешным.

Коротко подведу итоги по инструментам:

1. TDD и DDD незаменимы, когда у вас впереди высокая неопределенность и когда нужно работать в условиях лаборатории, изучая гипотезы и погружаясь в предметную область продукта.
2. Infobox стал надежным и доступным по цене, могу рекомендовать.
3. PostgreSQL силен, но требуется много времени, чтобы его узнать и настроить под ваши задачи.