Обсуждение каждого доклада на каждой нашей конференции начинается с простого вопроса: «Какую пользу получат слушатели от этого выступления?» Чему научатся, где сэкономят время, где деньги, что на следующий день они сделают по другому?

Какую же задачу решают доклады и мастер-классы профессионального фестиваля Российские интернет-технологии? Отвечу вам вопросом на вопрос — а чем отличается специалист мидл-уровня от сеньора?

Недавно руководитель Роспотребнадзора назвала ограничение, которое будет отменено последним, — это будет отмена запрета на массовые мероприятия. Онлайн с нами надолго!

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


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

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


На HighLoad++ Пётр Зайцев (Percona) сделал обзор доступной инфраструктуры для трейсинга в Linux и рассказал о bpfTrace, который (как видно из названия) дает много преимуществ. Мы сделали текстовую версию доклада, чтобы вам было удобно пересмотреть детали и дополнительные материалы всегда были под рукой.

Если вы пишете код — готовьтесь к проблемам. Они обязательно будут, и ожидать их стоит со всех сторон: от вашего кода и компилятора, от операционной системы и железа, а еще пользователи иногда подкидывают «сюрпризы». Если вы отмасштабировали кластер до космических масштабов, то ожидайте «космических» багов. Особенно, если речь идёт о данных из интернет-трафика.


Алексей Миловидов (o6CuFl2Q) расскажет о самых нелепых, обескураживающих и безнадёжных проблемах из его опыта разработки и поддержки ClickHouse. Посмотрим, как их приходилось отлаживать и какие меры принимать разработчикам с самого начала, чтобы проблем было меньше.

В 1970 г. американские инженеры запустили аппарат Аполлон-13 к Луне. На борту три батареи топливных элементов, беспокоиться не о чем, всё надежно и многократно продублировано. Но никто не мог предположить, что взрыв кислородного баллона выведет из строя две батареи из трёх. Трагедия! Астронавты вернулись домой, о событии сняли художественный фильм с Томом Хэнксом, а фраза астронавта Джека Свигерта: «Хьюстон, у нас проблема!», вошла в историю.



История Аполлона-13 это еще одно доказательство известного факта, что нельзя подготовиться ко всем возможным неприятностям. Это естественное свойство окружающего мира: железо периодически ломается, код сбоит, а люди ошибаются. Полностью исключить это невозможно.

Для больших распределенных систем такое поведение нормально, это следствие эффекта масштаба и статистики. Именно поэтому Design for Failure (дизайн на отказ) — базовый принцип проектирования облачных сервисов AWS. Системы изначально строятся так, чтобы максимально быстро восстановить штатную работу и минимизировать ущерб от известных и ещё неизвестных сбоев. На HighLoad++ Василий Пантюхин на примерах реальных проблем с боевыми сервисами показал паттерны проектирования распределенных систем, которые используют разработчики AWS.

Квантовая физика родилась в 1900 году, когда Макс Планк предположил, что энергия поглощается не непрерывно, а отдельными порциями — квантами. Его идея получила дальнейшее развитие: фотоэлектрический эффект Эйнштейна, теория атома Бора, Резерфорд опытным путем показал, как выглядит ядро атома, Луи де Бройль стер границу между волнами и материей, Гейзенберг и Шрёдингер разработали квантовую механику.

Квантовую физику тяжело понять — её математический аппарат почти невозможно перевести на «человеческий» язык. Но «потрогать» её проявления в повседневной жизни вполне реально: лазеры, флэшки, компакт-диски, интегральные схемы или графен — все эти технологии появились благодаря квантовой физике. Логично, что ее решили использовать и для вычислений — в квантовых компьютерах.

Квантовые компьютеры кардинально отличаются от обычных: они обрабатывают информацию на порядок быстрее, а памяти у них больше экспоненциально. Уже сейчас экспериментальные образцы решают некоторые задачи быстрее, чем самые мощные суперкомпьютеры. Перспективы от внедрения квантовых компьютеров манят. С их помощью можно создать новые лекарства, композитные материалы прочнее титана и легче пластика, сверхпроводники, которые работают при комнатной температуре, добиться абсолютной безопасности шифрования или разработать универсальный искусственный интеллект. Но в реальности всё не так радужно. Всё потому, что мы пока не понимаем, что действительно умеет квантовый компьютер.


Анатолий Дымарский (Сколтех) — физик-теоретик, работает в области физики квантовых систем. Анатолий расскажет, чем квантовый компьютер отличается от обычного и что сулят его возможности IT-индустрии.

В HTTP/2 появилась компрессия стандартных заголовков, но тело URI, Cookie, значения User-Agent по-прежнему могут составлять десятки килобайт и требуют токенизации, поиска и сравнения подстрок. Задача становится критичной, если HTTP-парсер должен обрабатывать интенсивный злонамеренный трафик. Стандартные библиотеки предоставляют обширный инструментарий обработки строк, но у HTTP-строки есть своя специфика. Именно для этой специфики разработан HTTP-парсер Tempesta FW. Его производительность в несколько раз выше по сравнению с современными Open Source решениями и превосходит быстрейшие из них.


Александр Крижановский (krizhanovsky) основатель и системный архитектор Tempesta Technologies, эксперт в области высокопроизводительных вычислений в Linux/x86-64. Александр расскажет об особенностях структуры HTTP-строк, объяснит, почему стандартные библиотеки плохо подходят для их обработки, и представит решение Tempesta FW.

Под катом: как HTTP Flood превращает ваш HTTP-парсер в узкое место, проблемы x86-64 с branch mispredictions, кэшированием и не выровненной памятью на типичных задачах HTTP-парсера, сравнение FSM с прямыми переходами, оптимизация GCC, автовекторизация, strspn()- и strcasecmp()-like алгоритмы для HTTP-строк, SSE, AVX2 и фильтрация инъекционных атак с использованием AVX2.

В PostgreSQL нет High Availability из коробки. Чтобы добиться HA, нужно что-то поставить, настроить — приложить усилия. Есть несколько инструментов, которые помогут повысить доступность PostgreSQL, и один из них — Patroni.

На первый взгляд, поставив Patroni в тестовой среде, можно увидеть, какой это прекрасный инструмент и как он легко обрабатывает наши попытки развалить кластер. Но на практике в production-среде не всегда всё происходит так красиво и элегантно. Data Egret начали использовать Patroni еще в конце 2018 года и накопили определенный опыт: как его диагностировать, настраивать, а когда вовсе не полагаться на автофейловер.

На HighLoad++ Алексей Лесовский обстоятельно, на примерах и с разбором логов рассказал о типовых проблемах, возникающих при работе с Patroni, и best practice для их преодоления.


В статье не будет: инструкций по установке Patroni и примеров конфигураций; проблем за пределами Patroni и PostgreSQL; историй, основанных на чужом опыте, а только те проблемы, с которыми в Data Egret разобрались сами.

Когда Facebook «лежит», люди думают, что это из-за хакеров или DDoS-атак, но это не так. Все «падения» за последние несколько лет были вызваны внутренними изменениями или поломками. Чтобы учить новых сотрудников не ломать Facebook на примерах, всем большим инцидентам дают имена, например, «Call the Cops» или «CAPSLOCK». Первый так назвали из-за того, что когда однажды соцсеть упала, в полицию Лос-Анджелеса звонили пользователи и просили его починить, а шериф в отчаянии в Твиттере просил не беспокоить их по этому поводу. Во время второго инцидента на кэш-машинах опустился и не поднялся сетевой интерфейс, и все машины перезапускали руками.

Элина Лобанова работает в Facebook последние 4 года в команде Web Foundation. Участники команды зовутся продакшн-инженерами и следят за надежностью и производительностью всего бэкенда, тушат Facebook, когда он горит, пишут мониторинг и автоматизацию, чтобы облегчить жизнь себе и другим.



В статье, основанной на докладе Элины на HighLoad++ 2019, расскажем, как продакшн-инженеры следят за бэкендом Facebook, какие инструменты используют, из-за чего возникают крупные сбои и как с ними справиться.

Скорее всего, рассказывать, что такое вебхуки (webhooks) — никому не нужно. Но на всякий случай: вебхуки — это механизм оповещения о событиях во внешней системе. Например, о покупке в интернет-магазине через онлайн-кассу, отправке кода в GitHub-репозиторий или действиях пользователей в чатах. В типичном API нужно постоянно опрашивать сервер, написал ли пользователь что-нибудь в чате. С помощью механизма вебхуков можно «подписаться» на оповещения, и сервер сам отправит HTTP-запрос, когда произойдет событие. Это удобнее и быстрее, чем постоянно запрашивать новые данные на сервере.



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

Основная масса сообщений отправляется через Facebook Messenger. У него есть особенность — медленный API. Когда клиент пишет сообщение, чтобы заказать пиццу, Facebook отправляет в ManyChat вебхук. Платформа его обрабатывает, отправляет запрос обратно и пользователь получает сообщение. Из-за медленного API некоторые запросы идут несколько секунд. Но когда платформа долго не отвечает, бизнес теряет клиента, а Facebook может отключить приложение от вебхуков.

Поэтому обработка вебхуков — это одна из главных инженерных задач платформы. Чтобы решить проблему, в ManyChat за три года работы несколько раз меняли архитектуру обработки с простого контроллера в Yii до распределенной системы с «Галактиками». Подробнее об этом под катом расскажет Дмитрий Кушников (@cancellarius).

В 2010 году у компании Wargaming было 50 серверов и простая сетевая модель: бэкенд, фронтенд и файрвол. Количество серверов росло, модель усложнялась: стейджинги, изолированные VLAN с ACL, потом VPN с VRF, VLAN c ACL на L2, VRF с ACL на L3. Закружилась голова? Дальше будет веселее.

Когда серверов стало 16 000 работать без слез с таким количеством разнородных сегментов стало невозможно. Поэтому придумали другое решение. Взяли стек Netfilter, добавили к нему Consul как источник данных, получился быстрый распределенный файрвол. Им заменили ACL на роутерах и использовали как внешний и внутренний файрвол. Для динамического управления инструментом разработали систему BEFW, которую применили везде: от управления доступом пользователей в продуктовую сеть до изоляции сегментов сети друг от друга.



Как это все работает и почему вам стоит присмотреться к этой системе, расскажет Иван Агарков (annmuor) — руководитель группы инфраструктурной безопасности подразделения Maintenance в Минском центре разработки компании. Иван — фанат SELinux, любит Perl, пишет код. Как руководитель группы ИБ, регулярно работает с логами, бэкапами и R&D, чтобы защищать Wargaming от хакеров и обеспечивать работу всех игровых серверов в компании.

Замена зуба на имплант или установка коронки — болезненная и дорогая процедура. Одна из самых сложных частей в восстановлении — дизайн протеза в CAD-системе, которым занимаются зубные техники. Каждая коронка проектируется индивидуально под пациента и его челюсть за 8-10 минут. При этом у каждого техника своё субъективное видение, что такое хорошая зубная коронка, а оценка качества одной и той же коронки у разных специалистов одного уровня может варьироваться от «хорошо» до «можно и лучше».


Поэтому неудивительно, что в стоматологии задались целью убрать человеческий фактор и добавить автоматизацию. Сделать это можно с помощью нейросетей. Они сейчас продвинулись настолько, что могут распознавать объекты, находить преступников в толпе, рисовать картины по наброску, и заменять лица актеров в фильмах, например, Ди Каприо на Бурунова в фильме «Великий Гэтсби». С зубами они также помогают справиться, а как это получилось, расскажет Станислав Шушкевич.

PHP 7.4 только-только объявлена stable, а нам уже подавай еще больше усовершенствований. И лучше всех о том, что ждет PHP, может рассказать Дмитрий Стогов — один из ведущих разработчиков Open Source PHP и, наверное, старейший активный контрибьютор.

Все доклады Дмитрия только о тех технологиях и решениях, над которыми он работает лично. В лучших традициях Онтико под катом текстовая версия рассказа о самых интересных с точки зрения Дмитрия нововведениях PHP 8, которые могут открыть новые use-case-ы. В первую очередь JIT и FFI — не в ключе «потрясающих перспектив», а с подробностями реализации и подводными камнями.


Для справки: Дмитрий Стогов познакомился с программированием в 1984, когда еще далеко не все из читателей появились на свет, и успел внести существенный вклад в развитие инструментов разработки, и PHP в частности (хоть Дмитрий повышает производительность PHP не специально для российских разработчиков, они выразили свою благодарность в виде Премии HighLoad++). Дмитрий автор Turck MMCache для PHP (eAccelerator), майнтейнер Zend OPcache, лидер проекта PHPNG, легшего в основу PHP 7, и лидер разработки JIT для PHP.

Официальная позиция Программных комитетов Highload++ и других IT-конференций на претензии к Игорю Сысоеву и Максиму Коновалову

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

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

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

Также хотим отметить, что претензии к open source продуктам в целом, и к nginx, в частности, ставят под сомнение экономическую безопасность крупнейших российских и мировых сервисов, использующих nginx и другие open source-продукты. К тому же, подобные действия негативно повлияют на инвестиционный климат в IT-отрасли России и могут привести к деградации самой отрасли.

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

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

Сейчас, кажется, невозможно найти мессенджер без функции звонков. Это удобно для пользователей, потому что все коммуникации можно вести в одном приложении. Если объединить всю доступную в СМИ статистику, то получится, что люди разговаривают через интернет более миллиарда минут в день. И по мере развития технологий растет доля видеосвязи, потому что видео лучше передает эмоции собеседника и позволяет создать эффект присутствия.

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

Руководитель разработки платформ Видео и Лента Александр Тоболь (alatobol) покажет, что под капотом у сервиса видеозвонков, какие технологии и хаки применить, чтобы сделать свой сервер конференций, и как правильно передавать видео. Заходите под кат и узнаете, как перевести сервис звонков один на один к групповым звонкам на 100 человек и зачем вообще нужна поддержка такого количества участников.

Что такое магия в PHP? Обычно под этим подразумевают методы вроде _construct() или __get(). Магические методы в PHP — это лазейки, которые помогают разработчикам выполнять удивительные вещи. В сети полно инструкций по их использованию, с которыми вы наверняка знакомы. Но что если мы скажем, что вы даже не видели настоящую магию? Ведь, чем больше вам кажется, что вы знаете все, тем больше магии ускользает от вас.



Давайте отбросим установленные рамки правил ООП и сделаем невозможное возможным в школе магии PHP. Главный и первый волшебный преподаватель школы — Александр Лисаченко (NightTiger). Он научит магическому мышлению и, возможно, вы полюбите магические методы, нестандартные способы доступа к свойствам, изменение контекстов, аспектно-ориентированное программирование и потоковые фильтры.

В эфире главное событие для разработчиков высоконагруженных систем. По хорошей традиции 7 и 8 ноября мы собираемся, чтобы делиться опытом в построении веб-сервисов, позволяющих одновременно помогать десяткам, сотням тысяч пользователей решать свои задачи. Если в этот раз мы с вами не увидимся в СКОЛКОВО, подключайтесь к открытой трансляции Главного зала конференции.

Открытая трансляция первого дня конференции HighLoad++

7 ноября трансляция докладов начинается в 9:45, в 18:00 они закончатся, и начнется церемония вручения Премии HighLoad++.

Открытая трансляция второго дня конференции HighLoad++

8 ноября первый доклад в Главном зале и трансляция начинается в 11:00.



Под катом расписание и информация о докладах.

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

А если все сделать по уму, то получится обрабатывать запросы многих тысяч пользователей. Поэтому в расписании HighLoad++ традиционно много докладов по базам данных. У нас есть треки по PostgreSQL, MySQL и ClickHouse, есть несколько докладов по MongoDB (в лучших традициях спикер —инженер по производительности в MongoDB). Кроме того, есть выступления, посвященные сравнению разных подходов или рассматривающие специализированные решения. И для общности прибавим сюда Tarantool и in-memory. Итого 33 доклада прямо относятся к секции «Базы данных и системы хранения» и как минимум 10 — косвенно. И это не считая митапов, которых уже не меньше десяти, а еще будут добавляться новые по ходу дела.

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

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

Если логирование хорошо организовано, то позволяет понимать, что, когда и как идет не так, как задумано, и передавать нужную информацию людям, которым предстоит эти ошибки исправлять. Для системы, в которой каждую секунду отправляется 100 тысяч сообщений в 10 дата-центрах на 190 стран, а 350 инженеров каждый день что-то деплоят, система логирования особенно важна.



Иван Летенко — тимлид и разработчик в Infobip. Чтобы решить проблему централизованной обработки и трассировки логов в микросервисной архитектуре при таких огромных нагрузках, в компании пробовали различные комбинации стека ELK, Graylog, Neo4j и MongoDB. В итоге, спустя много грабель, написали свой лог-сервис на Elasticsearch, а как БД для дополнительной информации взяли PostgreSQL.

Под катом подробно, с примерами и графиками: архитектура и эволюция системы, грабли, логирование и трассировка, метрики и мониторинг, практика работы с кластерами Elasticsearch и их администрирования в условиях ограниченных ресурсов.

Масштаб сети Amazon Web Services — это 69 зон по всему миру в 22 регионах: США, Европа, Азия, Африка и Австралия. В каждой зоне находится до 8 ЦОД — Центров Обработки Данных. В каждом ЦОД тысячи или сотни тысяч серверов. Сеть построена так, что все маловероятные сценарии перебоев в работе принимаются в расчет. Например, все регионы изолированы друг от друга, а зоны доступности разнесены на расстояния в несколько километров. Даже если перерубить кабель, то система перейдет на резервные каналы, а потери информации составят единицы пакетов данных. О том, на каких еще принципах построена сеть и как она устроена, расскажет Василий Пантюхин.



Василий Пантюхин начинал Unix-админом в .ru-компаниях, 6 лет занимался большими железками Sun Microsystem, 11 лет проповедовал дата-центричность мира в EMC. Естественным путем эволюционировал в приватные облака, потом подался в публичные. Сейчас, как архитектор Amazon Web Services, техническими советами помогает жить и развиваться в облаке AWS.

В предыдущей части трилогии об устройстве AWS Василий углубился в устройство физических серверов и масштабирование базы данных. Nitro-карты, кастомный гипервизор на базе KVM, база данных Amazon Aurora — обо всем этом в материале «Как AWS «варит» свои эластичные сервисы. Масштабирование серверов и базы данных». Прочитайте, чтобы погрузиться в контекст, или посмотрите видеозапись выступления.

В этой части речь пойдет о масштабировании сети — одной из сложнейших систем в AWS. Эволюция от плоской сети к Virtual Private Cloud и ее устройство, внутренние сервисы Blackfoot и HyperPlane, проблема шумного соседа, а в конце — масштабы сети, backbone и физические кабели. Обо всем этом под катом.

Дисклеймер: всё, что ниже — личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.