Российские интернет-технологии (РИТ) — профессиональный фестиваль для тех, кто делает Интернет. В 2017 году этот фестиваль проводился в Сколково 5-6 июня. Мероприятие состояло из управленческого, интерфейсного, серверного блоков.

В зависимости от типа билета участнику были доступны доклады разных блоков. Данная статья посвящена серверному блоку в соответствии с имевшимся билетом. Доклады, посещенные в рамках фестиваля, охватывают темы, такие как СУБД, архитектура, инфраструктура и мониторинг, тестирование.

СУБД

СУБД были освещены через призму настоящего и будущего. Tarantool, ClickHouse, CockroachDB, PostgeSQL, MySQL — неполный список СУБД, рассмотренных на конференции.

Tarantool — NoSQL СУБД и сервер приложения на Lua. Tarantool поддерживает два способа хранения: в оперативной памяти (memtx) и на диске, в основе которого лежат идеи современных файловых систем, LSM и B-деревьев. Модель данных основана на концепциях “пространство” (space), “кортеж” (tuple), “поле” (field), “индекс” (index). Пространство представляет собой контейнер данных с уникальным именем. Кортеж — это набор полей, которые могут быть составными структурами (массив или ключ/значение) без обязательного наличия имени. Индекс есть группа ключевых значений и указателей. Функционал Tarantool включает вторичные индексы, составные ключи, запросы по диапазону значений, транзакции, аутентификацию и контроль доступа, репликацию, хранимые процедуры.

ClickHouse — распределенная колоночная СУБД с возможностью генерации аналитических отчетов в режиме реального времени. Эта СУБД поддерживает хранение данных на диске в отличие от некоторых других колоночных СУБД. Функционал ClickHouse включает сжатие данных, параллельную и распределенную обработку запросов, индексы, приближенные вычисления, репликацию, декларативный язык запросов на основе SQL. Стоит заметить, что база данных не поддерживает транзакции и накладывает ограничение на запросы с агрегацией — результат запроса должен помещаться в оперативную память.

CockroachDB — распределенная SQL СУБД, построенная на транзакционном и строго-консистентном хранилище типа “ключ-значение”. Первый релиз для использования в производственных средах состоялся в мае 2017 года. Эта база данных обладает преимуществами традиционных реляционных и NoSQL баз данных. Функционал CockroachDB включает горизонтальное масштабирование, высокую устойчивость, ACID транзакции и SQL. CockroachDB является хорошим вариантом для распределенной обработки транзакций в реальном времени в нескольких дата-центрах. Однако на данный момент её не рекомендуется использовать для запросов со сложными JOIN конструкциями и аналитической обработки данных.

Tarantool, ClickHouse, CockroachDB пока не набрали популярность и по статистике участников доклада “Обзор перспективных баз данных для highload” практически не используются в производственных средах. Несмотря на это, я согласна с автором вышеупомянутого доклада, что их стоит рассматривать как альтернативы при выборе базы данных.

PostgreSQL, являясь широко используемой реляционной СУБД, продолжает развиваться. Так, в версии 10 заявлены поддержка логической репликации и нативного партицирования таблиц, улучшение параллельности запросов, а также множество новых возможностей и улучшений. Одна из функциональностей была освещена в докладе с говорящим названием “Полнотекстовый поиск в PostgreSQL”. Доклад содержал базовые теоретические и практические аспекты полнотекстового поиска, но, к сожалению, не включал показателей производительности и сравнительного анализа со специализированными решениями. На мой взгляд данная функциональность выглядит перспективной с точки зрения её использования, но в реальных проектах потребуется проведение предварительного анализа.

К базам данных как к неотъемлемым частям информационных систем предъявляются высокие требования, заставляющие находить компромисс между масштабируемостью и доступностью с одной стороны и атомарностью и согласованностью с другой стороны. В ответ на эти требования появился новый класс современных баз данных — NewSQL, оказывающий влияние на развитие существующих реляционных и NoSQL баз данных. Этот вектор развития в мире баз данных также был рассмотрен на фестивале.

Архитектура

Архитектура информационной системы играет такую же роль как название корабля в цитате из известного мультфильма. Существует множество типов архитектур, каждый из которых имеет свои преимущества и недостатки. Актуальным трендом остается микросервисная архитектура. Выбор этой архитектуры заставляет иначе оценивать требования по сравнению с другими типами архитектур. Обещанный обзор паттернов микросервисной архитектуры и подходов к проблематичным её аспектам не оправдал ожидания, поскольку содержал лишь общеизвестные факты. Смазанное впечатление произвел и доклад “Ошибки проектирования высоконагруженных проектов”. К положительным сторонам этого доклада можно отнести сформулированные ошибки. Так, в двух приведенных примерах были допущены следующие: ориентированность на вертикальное масштабирование при отсутствии оценок верхнего лимита, выбор неправильного стека технологий (хотя этот пункт в контексте одного примера остался под сомнением), некорректная организация резервного копирования, ложные цели и использование привычных для архитектора методик. Последний пункт подразумевает отсутствие критической оценки готовых или очевидных/первых появившихся решений. Мораль доклада — тщательный анализ требований и профессиональный подход к проектированию архитектуры поможет избежать дорогостоящих ошибок.

Вопрос безопасности программных продуктов становится все более важным для конечных пользователей и, следовательно, для разработчиков и специалистов по безопасности. Базовые рекомендации по реализации защиты информационных систем были озвучены в докладе “Application Security — ответы на ежедневные вопросы”. Стоит отметить, что среди рекомендаций была указана необходимость оценки безопасности используемых технологий.

DevOps

Климат IT-команды зависит напрямую от степени удовлетворенности клиентов и отсутствия авралов в DevOps отделе. Человеческий фактор, ручное развертывание, некорректно выбранные для мониторинга метрики и их пороговые значения, неподтвержденные предположения о перечне или объеме услуг провайдеров — все это может негативно повлиять на конечных пользователей и, соответственно, команду или даже компанию. Популярным подходом к решению проблемы ручного развертывания является использование технологий, таких как Docker, Ansible, Puppet. Об успешном внедрении GitLab CI в связке с подмножеством перечисленных выше технологий поведал доклад “How to build solid CI-CD pipeline”. Наличие автоматического развертывания снижает риски, связанные с человеческим фактором, однако не исключает проблем коммуникации между командами разработки и DevOps. Своим опытом перехода от ручного развертывания к автоматическому и построения коммуникации между командами поделилась компания 2ГИС. Полезным на мой взгляд решением стало введение технических ревью, комитет которых включает разработчиков, инженеров DevOps, инженеров по тестированию, менеджера проекта. Входное ревью предназначено для валидации решения, результатом которого является список заданий. Выходное ревью проводится в присутствии специалистов технической поддержки для проверки готовности к релизу. Такое двухэтапное ревью сотрудниками разных отделов позволяет оценить планируемые изменения с необходимых ракурсов и повысить качество программных продуктов.

Инфраструктура

Огромное влияние на доступность и работоспособность информационной системы оказывает среда, в которой она развернута. Частично или полностью эта среда обеспечивается услугами сторонних провайдеров, сотрудничество с которыми имеет свою специфику. На первый взгляд кажется очевидным, что это сотрудничество строго регламентировано договором об оказании услуг. Однако случаи неоправданных ожиданий со стороны клиентов не единичны. Распространенные заблуждения клиентов с точки зрения провайдера были рассмотрены в докладе “Как заранее соломки подстелить или путь к 99.99% uptime”. Этот доклад был рассчитан на IT специалистов, не имеющих достаточного опыта конфигурирования инфраструктуры, однако содержал список пунктов самопроверки, о которых не следует забывать и опытным специалистам.

Реальность такова, что полностью без сбоев информационные системы не существуют. Принимая это как факт, следует позаботиться о мониторинге. Для его реализации существуют специализированные программные продукты и сервисы. Среди рассмотренных на фестивале — Zabbix, Prometheus, Okmeter. Вне зависимости от выбранного решения для мониторинга важно правильно выбрать метрики, а также их пороговые значения. Ответ на вопрос “В каком смысле правильно?” содержался в докладе “MathOps или математика в мониторинге”. Основной вывод этого доклада заключался в том, что нет рекомендаций, подходящих для любой информационной системы, а главным ориентиром при выборе пороговых значений является степень удовлетворения пользователей.

Программный продукт без багов — цель, к которой стремятся при разработке. Средств достижения этой цели много. Жаркие дискуссии об одном из них, а именно test-driven development, не утихают до сих пор. Этой технике разработки программного обеспечения было посвящено несколько докладов и даже “митап”, на котором данная техника была продемонстрирована в режиме реального времени на примере программы, подсчитывающей очки для игры в боулинг. Доклад “Держим дизайн системы под контролем, используя изолированное юнит-тестирование” содержал аргументы “за” и их обоснование, а также, как видно из названия, описывал взаимосвязь дизайна системы и тестирования. С другой позиции техника рассматривалась в докладе “TDD: когда нужно и, самое главное, когда не нужно”. Доклад понравился тем, что были сформулированы критерии, опираясь на которые можно оценить применимость этой техники в конкретных проектах. Предпосылками успешного внедрения TDD были названы наличие спецификации интерфейсов и единый подход к их реализации, описание реализации в задачах, дробление задач на подзадачи до уровня покрытия одним тестом, присутствие высокоуровнего фреймворка для тестирования в стеке технологий, отсутствие команды инженеров по тестированию. С осторожностью рекомендовалось использовать TDD при отсутствии должной проработки задач, реализации сложных вычислений, акцентах на безопасность и большие нагрузки. Резюмируя обсуждения TDD на фестивале, можно сказать, что знание сильных и слабых сторон этой техники поможет избежать финала басни “Мартышка и очки”.

Вместо заключения

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