Высокая производительность *

Практически все современные программные продукты состоят из нескольких сервисов. Часто большое время отклика межсервисных каналов становится источником проблем с производительностью. Стандартное решение такого рода проблем — это упаковка нескольких межсервисных запросов в один пакет, которую называют пакетной обработкой (batching).

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

Совсем недавно, с 8 по 12 июля, одновременно проходило два знаковых события — конференция Hydra и школа SPTDC. В этом посте хочется отметить несколько особенностей, которые мы заметили по ходу проведения конференции.

Самая большая гордость Гидры и Школы — это докладчики.

• Три лауреата премии Дейкстры: Leslie Lamport, Maurice Herlihy и Michael Scott. Причём Морис получил её целых два раза. Лесли Лэмпорт получил еще и премию Тьюринга — самую престижную премию ACM в информатике;
• Создатель JIT-компилятора Java — Cliff Click;
• Разработчики корутин — Роман Елизаров (elizarov) и Никита Коваль (ndkoval) для Kotlin, и Дмитрий Вьюков для Go;
• Контрибьюторы в Cassandra (Алекс Петров), CosmosDB (Денис Рысцов), Yandex Database (Семен Чечеринда и Владислав Кузнецов);
• И множество других известных людей: Martin Kleppmann (CRDT), Heidi Howard (Paxos), Ori Lahav (C++ memory model), Pedro Ramalhete (wait-free data structures), Алексей Зиновьев (ML), Дмитрий Бугайченко (анализ графов).

В конце июня Новосибирск второй раз принимал HighLoad++. Если в прошлом году эффект новинки сыграл свою немалую роль в том, что все всем были довольны, то в этот раз нам нужно было подготовиться гораздо тщательнее, чтобы сохранить и превзойти впечатление. В первую очередь с утроенной силой мы взялись за главное — программу. Теперь, когда выступления состоялись и даже уже выборочно пересмотрены по второму кругу, собраны и обработаны отзывы участников конференции, можно уверенно заявить, что удалась она на славу. 

Основу HighLoad++ Siberia составили 38 отличных докладов, полных опыта и глубочайшей экспертизы. Международные гиганты и региональные компании — все делились опытом работы с задачами, для решения которых стандартных средств просто не существует. А особенной конференцию сделали люди. Мы честно пытались понять, в чем дело, и как сделать настолько же душевные мероприятия в других местах, но нет — за непередаваемой дружественной атмосферой придется снова ехать в Сибирь, и мы только за. К тому же мы уже думаем над новинками.



Медведя привезли с собой, ни один представитель местной фауны не пострадал.

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

В этой статье я покажу, каким образом такая концепция позволяет быстро и удобно балансировать запись и чтение в базу данных без какого-либо изменения логики работы. Похожий функционал попытались реализовать в современных коммерческих СУБД (в частности, Oracle и Microsoft SQL Server). В конце статьи я покажу, что получилось у них, мягко говоря, не очень.

Здравствуйте, коллеги.

Не так давно наше внимание привлекла почти готовая книга издательства Manning «Programming with types», подробно рассматривающая важность правильной типизации и ее роль при написании чистого и долговечного кода.



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

Все эти годы вы, frontend-разработчик, писали монолиты, хотя и понимали, что это дурная привычка. Вы делили свой код на компоненты, использовали require или import и определяли npm-пакеты в package.json или плодили гит-репозитории в вашем проекте, но все равно писали монолит.
Пришло время изменить положение.

Любимым вопросом о любой распределенной системе от нетехнического специалиста является “Сколько tps в вашем блокчейне?”. Однако, названное в ответ число обычно имеет мало общего с тем, что хотел бы услышать вопрошающий. На деле, он хотел спросить “подойдет ли ваш блокчейн под мои бизнес требования”, и эти требования — это не одно число, а множество условий — здесь и отказоустойчивость сети, и требования к финальности, размеры, характер транзакций и множество других параметров. Так что ответ на вопрос “сколько tps” вряд ли будет простым, и почти никогда не будет полным. Распределенная система с десятками и сотнями узлов, выполняющих довольно сложные вычисления, может находиться в огромном количестве различных состояний, связанных с состоянием сети, содержимым блокчейна, техническими сбоями, экономическими проблемами, атаками на сеть и множеством других причин. Этапы, на которых возможны проблемы с производительностью отличаются от традиционных сервисов, а сервер блокчейн-сети — это сетевой сервис, сочетающий в себе функционал базы данных, web-сервера и torrent-клиента, что делает его крайне сложным в плане профиля нагрузки на все подсистемы: процессор, память, сеть, storage

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

11-12 июля, то есть уже в этот четверг и пятницу, пройдёт конференция Hydra 2019. Это два дня и два трека докладов, посвященных распределённым вычислениям. Доклады ведут лучшие учёные и инженеры, приехавшие в Санкт-Петербург из разных стран мира. Конференция ориентирована на специалистов в области, никаких вводных докладов!

Вы сможете посмотреть совершенно бесплатную онлайн-трансляцию. На ней будет только первый день и первый зал + онлайн-интервью между докладами. Что это за доклады — обсудим чуть ниже.

Важно, что трансляция начнётся в 9:45 утра (по московскому времени), за 15 минут до открытия, и закончится ближе к 8 часам вечера. Всё это время вы сможете слушать доклады с небольшими перерывами. Ссылка будет работать весь день, поэтому можно открывать её только на наиболее важных для вас докладах.

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

Главные вопросы работы с базой данных связаны с особенностями устройства операционной системы, на которой работает база. Сейчас Linux — основная операционная система для баз данных. Solaris, Microsoft и даже HPUX все еще применяются в энтерпрайзе, но первое место им больше никогда не занять, даже вместе взятым. Linux уверенно завоевывает позиции, потому что open source баз данных все больше. Поэтому вопрос взаимодействия БД с ОС, очевидно, о базах данных в Linux. На это накладывается вечная проблема БД — производительность IO. Хорошо, что в Linux последние годы идет капитальный ремонт IO-стека и есть надежда на просветление.


Илья Космодемьянский (hydrobiont) работает в компании Data Egret, которая занимается консалтингом и поддержкой PostgreSQL, и про взаимодействие ОС и баз данных знает многое. В докладе на HighLoad++ Илья рассказал о взаимодействии IO и БД на примере PostgreSQL, но и показал, как с IO работают другие БД. Рассмотрел стек Linux IO, что нового и хорошего в нем появилось и почему все не так, как было пару лет назад. В качестве полезной памятки — контрольный список настроек PostgreSQL и Linux для максимальной производительности подсистемы IO в новых ядрах.

В середине июня в нашем офисе прошла конференция T+ Conf 2019, на которой прозвучало много интересных докладов про использование Tarantool, in-memory-вычислений, кооперативной многозадачности и Lua для создания высоконагруженных отказоустойчивых сервисов в Digital и Enterprise. И для всех, кто не смог побывать на конференции, мы приготовили видеозаписи и презентации всех выступлений, а также кучу отличных фотографий из гущи событий, так сказать.

Компания Variti специализируется на защите от ботов и DDoS-атак, а также проводит стресс- и нагрузочное тестирование. Поскольку мы работаем как международный сервис, нам крайне важно обеспечить бесперебойный обмен информацией между серверами и кластерами в режиме реального времени. На конференции Saint HighLoad++ 2019 разработчик Variti Антон Барабанов рассказал, как мы используем UDP и Tarantool, почему взяли именно такую связку, и как нам пришлось переписывать модуль Tarantool с Lua на C.

По ссылке можно также почитать тезисы доклада, а ниже под спойлером — посмотреть видео.


Когда мы начали делать сервис фильтрации трафика, мы сразу решили не заниматься IP-транзитом, а защищать HTTP, API и игровые сервисы. Таким образом, мы терминируем трафик на уровне L7 в протоколе TCP и передаем его дальше. Защита на L3&4 при этом происходит автоматически. На схеме ниже представлена схема сервиса: запросы от людей проходят через кластер, то есть серверы и сетевое оборудование, а боты (показаны в виде привидения) фильтруются.



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

Что делать, если ваш запрос к базе выполняется недостаточно быстро? Как узнать, оптимально ли запрос использует вычислительные ресурсы или его можно ускорить? На последней конференции HighLoad++ в Москве я рассказал об интроспекции производительности запросов — и о том, что даёт СУБД ClickHouse, и о возможностях ОС, которые должны быть известны каждому.



Каждый раз, когда я делаю запрос, меня волнует не только результат, но и то, что этот запрос делает. Например, он работает одну секунду. Много это или мало? Я всегда думаю: а почему не полсекунды? Потом что-нибудь оптимизирую, ускоряю, и он работает 10 мс. Обычно я доволен. Но все-таки я стараюсь в этом случае сделать недовольное выражение лица и спросить: «Почему не 5 мс?» Как можно выяснить, на что тратится время при обработке запроса? Можно ли его в принципе ускорить?

В этой статье я расскажу о том, как проект, в котором я работаю, превращался из большого монолита в набор микросервисов.

Проект начал свою историю довольно давно, в начале 2000. Первые версии были написаны на Visual Basic 6. С течением времени стало понятно, что разработку на этом языке в будущем будет сложно поддерживать, так как IDE и сам язык развиваются слабо. В конце 2000-х было решено переходить на более перспективный C#. Новая версия писалась параллельно с доработкой старой, постепенно все больше кода было на .NET. Backend на C# изначально ориентировался на сервисную архитектуру, однако при разработке использовались общие библиотеки с логикой, да и запускались сервисы в едином процессе. Получилось приложение, которое мы называли «сервисный монолит».

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

Свою работу по декомпозиции мы начали примерно в 2015 году. Пока еще мы не достигли идеального состояния — остались части большого проекта, которые уже трудно назвать монолитами, но и на микросервисы они не похожи. Тем не менее, прогресс существенный.
О нем я и расскажу в статье.

В реальном внедрении ML само обучение занимает от силы четверть усилий. Остальные три четверти — подготовка данных через боль и бюрократию, сложный деплой часто в закрытом контуре без доступа в интернет, настройка инфраструктуры, тестирование и мониторинг. Документы на сотни листов, ручной режим, конфликты версий моделей, open source и суровый enterprise — все это ждет data scientist’а. Но такие «скучные» вопросы эксплуатации ему не интересны, он хочет разработать алгоритм, добиться высокого качества, отдать и больше не вспоминать.

Возможно, где-то ML внедряется легче, проще, быстрее и одной кнопкой, но мы таких примеров не видели. Все, что выше — опыт компании Front Tier в финтехе и телекоме. О нем на HighLoad++ рассказал Сергей Виноградов — эксперт в архитектуре высоконагруженных систем, в больших хранилищах и тяжелом анализе данных.

Если вы бывали на HighLoad++, то знаете о традиционном митапе по Go. Активисты, интересующиеся Go, занимали зал на пару часов, представляли небольшие доклады, обсуждали насущные темы, холиварили. Были на HighLoad++ и отдельные доклады по Go.

Теперь, нам кажется, что пора выходить на новый уровень, поэтому 7 октября мы проведем GolangConf. Из названия понятно, что это конференция про Go, но этого явно недостаточно.



Мы готовим эту конференцию для:

• Go-разработчиков — тех, кто уже давно сидит на Go, кому интересно обсудить новинки, поговорить о производительности и «кишках», узнать, что меняется в Go, похоливарить о дженериках, например.
• Кроме того, поскольку Go-общество расширяется, мы ждем программистов, которые только-только переходят на Go или даже только подумывают об этом. Покажем им истории успеха, реализовавшегося с переходом на Go, или истории провала. Узнаем, что не получается, почему, какие их первые чувства, мнения, впечатления.
• Третья категория посетителей — пользователи инструментов, написанных на Go. Это популярные в рамках Cloud Native инфраструктур: Kubernetes, Docker, Terraform, Consul и другие продукты Hashicorp. На Go-конференции гости, с одной стороны, узнают, какие у этих инструментов есть проблемы, связанные с особенностями языка, а с другой — увидят, какие в Go есть вызовы и задачи, чтобы начать, например, контрибьютить в эти проекты.

Чтобы определить, какие именно темы нужно обсудить на конференции по Go, какие проблемы и задачи важны для каждой из категорий слушателей, мы собрали Программный комитет и активистов Go-сообщества. Устроили своего рода мозговой штурм. Результатами делимся с вами и, поскольку главная наша цель — развивать сообщество, надеемся на ваш отклик. Напишите в комментариях, что нужно раскрыть полнее, что совсем неинтересно, а что именно то что нужно. Посоветуйте, например, стоит ли обсуждать особенности эксплуатации Go под Windows, а то мнения разделились.

На проходившем в июне Intel Software Technology Day ведущие инженеры компании рассказали о софтверном проекте под названием «Intel oneAPI» — унифицированной модели программирования для облегчения разработки ПО под разнообразные вычислительные архитектуры, включающей в себя новый язык программирования. В этом посте мы приведем краткое описание данного проекта — как говорится, to be continued…

Redis Stream — новый абстрактный тип данных, представленный в Redis с выходом версии 5.0
Концептуально Redis Stream — это List, в который вы можете добавлять записи. Каждая запись имеет уникальный идентификатор. По умолчанию идентификатор генерируется автоматически и включает в себя временную метку. Поэтому вы можете запрашивать диапазоны записей по времени или получать новые данные по мере их поступления в поток, как Unix команда «tail -f» читает лог-файл и замирает в ожидании новых данных. Обратите внимание, что поток могут слушать одновременно несколько клиентов, как многие «tail -f» процессы могут одновременно читать файл, не конфликтуя друг с другом.

Чтобы понять все преимущества нового типа данных, давайте бегло вспомним давно существующие структуры Redis, которые частично повторяют функциональность Redis Stream.

Samsung и AMD начали совместный проект в области архитектур GPU. Разберемся, какие есть предпосылки для этого партнерства и обсудим другие компании, работающие в этой сфере.

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

Друзья, мы договорились с компанией Онтико, что будем публиковать лучшие доклады с их конференций на своём Youtube-канале и делиться ими с вами. Так мы хотим не только распространять знания, но и помогать нашим читателям и зрителям профессионально развиваться. Ловите подборку 15 лучших докладов, которые прозвучали на Highload++ 2018.

Репликация в Tarantool: конфигурация и использование

Георгий Кириченко, Mail.ru Group


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

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