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



Облако AWS это мегасуперсложная система, которая эволюционно развивается с 2006 года. Часть этого развития застал Василий Пантюхин — архитектор Amazon Web Services. Как архитектор он видит изнутри не только конечный результат, но и сложности, которые преодолевает AWS. Чем больше понимания работы системы, тем больше доверия. Поэтому Василий поделится секретами облачных сервисов AWS. Под катом устройство физических серверов AWS, эластичная масштабируемость БД, кастомная база данных Amazon и методы повышения производительности виртуальных машин с одновременным уменьшением их цены. Знание архитектурных подходов Amazon поможет эффективнее использовать сервисы AWS и, возможно, даст новые идеи по построению собственных решений.

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



Вообще все в nginx — это модули, которые когда-то кем-то были написаны. Поэтому писать модули под nginx не только можно, но и нужно. Когда это необходимо делать и зачем, расскажет Василий Сошников (dedokOne) на примере нескольких кейсов.

Поговорим о причинах, которые побуждают писать модули на C, об архитектуре и ядре nginx, анатомии HTTP-модулей, о C-модулях, NJS, Lua и nginx.conf. Это важно знать не только тем, кто разрабатывает под nginx, но также тем, кто использует nginx-конфиги, Lua или другой язык внутри nginx.

Примечание: статья написана на основе доклада Василия Сошникова. Доклад постоянно модернизируется и обновляется. Информация в материале довольно техническая и, чтобы извлечь максимум пользы, читателям необходимо иметь опыт работы с кодом nginx на среднем уровне и выше.

Zabbix — это система мониторинга. Как и любая другая система, она сталкивается с тремя основными проблемами всех систем мониторинга: сбор и обработка данных, хранение истории, ее очистка.

Этапы получения, обработки и записи данных занимают время. Немного, но для крупной системы это может выливаться в большие задержки. Проблема хранения — это вопрос доступа к данным. Они используются для отчетов, проверок и триггеров. Задержки при доступе к данным также влияют на производительность. Когда БД разрастаются, неактуальные данные приходится удалять. Удаление — это тяжелая операция, которая также съедает часть ресурсов.



Проблемы задержек при сборе и хранении в Zabbix решаются кэшированием: несколько видов кэшей, кэширование в БД. Для решения третьей проблемы кэширование не подходит, поэтому в Zabbix применили TimescaleDB. Об этом расскажет Андрей Гущин — инженер технической поддержки Zabbix SIA. В поддержке Zabbix Андрей больше 6 лет и напрямую сталкивается с производительностью.

Как работает TimescaleDB, какую производительность может дать по сравнению с обычным PostgreSQL? Какую роль играет Zabbix для БД TimescaleDB? Как запустить с нуля и как мигрировать с PostgreSQL и производительность какой конфигурации лучше? Обо всем этом под катом.

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

Не все так страшно! Собрать нейронную сеть из базовых моделей может любой, кто сколько-то знаком с программированием. И даже не обязательно учить Python, всё можно сделать на родном JavaScript. Как легко начать и зачем машинное обучение фронтендерам, рассказал Алексей Охрименко (obenjiro) на FrontendConf, а мы переложили в текст — чтобы названия архитектур и полезные ссылки были под рукой.

Spoiler. Alert!

Этот рассказ:

• Не для тех, кто «уже» работает с Machine Learning. Что-то интересное будет, но маловероятно, что под катом вас ждут открытия.
• Не о Transfer Learning. Не будем говорить о том, как написать нейронную сеть на Python, а потом работать с ней из JavaScript. Никаких читов — будем писать глубокие нейронные сети именно на JS.
• Не о всех деталях. Вообще все концепции в одну статью не поместятся, но необходимое, конечно, разберем.

Unit-тестирование — это замечательно, но его одного бывает недостаточно. Часто хочется дополнительно убедиться, что запущенное приложение будет работать. На помощь приходит интеграционное тестирование. Оно все чаще применяется для тестирования сервисов, а Docker позволяет удобно управлять тестовым окружением. Но, как всегда, не все так просто, когда микросервисов и зависимостей становится намного больше.

Юрий Бадальянц на РИТ++ рассказал, как в 2ГИС тестируют связку из большого числа сервисов и целого зоопарка технологий. Под катом дополненная и актуализированная под тщательным присмотром спикера версия этого доклада: какие варианты пробовали, к чему пришли, какие проблемы теперь вам не придется решать. Будет про Docker, Testcontainers, а также про Scala.

Записывайте рецепт микровиртуалок Firecracker. Берем два популярных метода изоляции многопользовательской нагрузки — виртуальные машины и контейнеры. Выжимаем лучшее из обоих подходов, максимально упрощаем, тестируем на настоящем хайлоаде. В итоге получаем непробиваемую изоляцию виртуалок, которые можно запускать за сотни миллисекунд. Именно это решение работает под капотом AWS Lambda и Fargate, запуская в облаке миллионы serverless-функций и контейнеров каждую секунду. Оно называется Firecracker.



Этот инструмент микровиртуализации доступен в OpenSource. Если ваши задачи требуют мульти-тенантной изоляции, (ну, например, вы решили сделать собственное облако), Firecracker — это то, что надо.

Василий Пантюхин, архитектор Amazon Web Services, расскажет об архитектуре Firecracker, о том, как он используется AWS Lambda, сравнит его с альтернативными решениями и приведет примеры интеграции.

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

Time series данные или временные ряды — это данные, которые изменяются во времени. Котировки валют, телеметрия перемещения транспорта, статистика обращения к серверу или нагрузки на CPU — это time series данные. Чтобы их хранить требуются специфичные инструменты — темпоральные базы данных. Инструментов — десятки, например, InfluxDB или ClickHouse. Но даже у самых лучших решений для хранения временных рядов есть недостатки. Все time series хранилища низкоуровневые, подходят только для time series данных, а обкатка и внедрение в текущий стек — дорого и больно.



Но, если у вас стек PostgreSQL, то можете забыть о InfluxDB и всех остальных темпоральных БД. Ставите себе два расширения TimescaleDB и PipelineDB и храните, обрабатываете и проводите аналитику time series данных прямо в экосистеме PostgreSQL. Без внедрения сторонних решений, без недостатков темпоральных хранилищ и без проблем их обкатки. Что это за расширения, в чем их преимущества и возможности, расскажет Иван Муратов (binakot) — руководитель отдела разработки в «Первой Мониторинговой Компании».

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

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


Осторожно, под катом 99 иллюстраций и схем и все важные.

Классическое PHP-приложение — однопоточность, тяжелая загрузка (если вы, конечно, не пишите на микрофреймворках) и неизбежная смерть процесса после каждого запроса… Такое приложение тяжелое и медленное, но мы можем дать ему вторую жизнь гибридизацией. Чтобы ускорить — демонизируем и оптимизируем утечки памяти, чтобы добиться большей производительности — внедрим собственный сервер РНР-приложений RoadRunner на Golang, чтобы добавить гибкости — упростим PHP-код, расширим стек и разделим ответственность между сервером и приложением. По сути, заставим наше приложение работать, как если бы мы писали его на Java или другом языке.

Благодаря гибридизации ранее медленное приложение перестало страдать 502 ошибками под нагрузками, уменьшилось среднее время ответа на запросы, производительность увеличилась, а деплой и сборка стали проще за счет унификации приложения и избавления от лишней обвязки в виде nginx + php-fpm.


Антон Титов (Lachezis) — технический директор и соучредитель SpiralScout LLC с опытом активной коммерческой разработки на PHP в 12 лет. Последние несколько лет активно внедряет Golang в стек разработки компании. Об одном из примеров Антон рассказал на PHP Russia 2019.

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

Даниил Подольский, хоть и евангелист Go, тоже встречает в нем много странного. Все странное и, главное, интересное, собирает и тестирует, а потом рассказывает об этом на HighLoad++. В расшифровке доклада будут цифры, графики, примеры кода, результаты работы профайлера, сравнение производительности одних и тех же алгоритмов на разных языках — и все остальное, за что мы так ненавидим слово «оптимизация». В расшифровке не будет откровений — откуда же они в таком простом языке, — и всего, о чем можно прочесть в газетах.

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

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

Егор Бугаенко знает, что нужно делать уже сейчас, чтобы и через 5–10 лет оставаться востребованным программистом. Его идеи, как и всегда, могут показаться спорными. Вам и не нужно безоговорочно с ними соглашаться, но задуматься, например, о pet project лишний раз не повредит. Да и в том, что программисту необходим английский язык, вряд ли могут быть разные мнения. А вот по остальным пунктам будет интересно узнать мнение сообщества в комментариях.



Дальше идет текстовая версия доклада Егора на AppsConf, но относится он не только и не столько к мобильной разработке, сколько к отрасли в целом. Егор Бугаенко основатель Zerocracy, разработчик Cactoos, Takes Framework, JCabi и других open source проектов. Написал серию книг «Elegant Objects», ведет провокационный блог и выступает с докладами, заставляющими задуматься, такими как этот.

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


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

Если вы бывали на 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, а то мнения разделились.

Интернет кажется сильной, независимой и нерушимой структурой. В теории, прочности сети хватит, чтобы пережить ядерный взрыв. В реальности, интернет может уронить один маленький роутер. Все из-за того, что интернет — это нагромождение противоречий, уязвимостей, ошибок и роликов про котиков. Основа интернета — протокол BGP — содержит кучу проблем. Удивительно, что он еще дышит. Кроме ошибок в самом интернете, его еще ломают все кому не лень: крупные интернет-провайдеры, корпорации, государства и DDoS-атаки. Что с этим делать и как с этим жить?



Ответ знает Алексей Учакин (Night_Snake) — лидер команды сетевых инженеров в компании IQ Option. Главная его задача — доступность платформы для пользователей. В расшифровке доклада Алексея на Saint HighLoad++ 2019 поговорим про BGP, DDOS-атаки, рубильник от интернета, ошибки провайдеров, децентрализацию и случаи, когда маленький роутер отправил интернет поспать. В конце — пара советов, как все это пережить.

Как вы думаете, кто лучше настроит PostgreSQL — DBA или ML алгоритм? И если второй, то пора ли нам задуматься, чем заняться, когда нас заменят машины. Или до этого не дойдет, и важные решения все-таки должен принимать человек. Наверное, уровень изоляции и требования к устойчивости транзакций должны оставаться в ведении администратора. Но индексы уже скоро можно будет доверить машине определять самостоятельно.



Энди Павло на HighLoad++ рассказал про СУБД будущего, которые можно «потрогать» уже сейчас. Если пропустили это выступление или предпочитаете получать информацию на русском языке — под катом перевод выступления.

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

Зачем такой корпорации, как МегаФон, Tarantool в биллинге? Со стороны кажется, что обычно приходит вендор, приносит какую-то большую коробку, втыкает штекер в розетку — вот и биллинг! Когда-то так и было, но сейчас это архаика, и такие динозавры уже вымерли или вымирают. Изначально биллинг это система для выставления счетов — считалка или калькулятор. В современном телекоме — это система автоматизации всего жизненного цикла взаимодействия с абонентом от заключения договора до расторжения, включая real-time-тарификацию, прием платежей и еще много чего. Биллинг в телеком-компаниях похож на боевого робота — большого, мощного и обвешанного оружием.



Причем же здесь Tarantool? Об этом расскажут Олег Ивлев и Андрей Князев. Олег — главный архитектор компании МегаФон с огромным опытом работы в зарубежных компаниях, Андрей — директор по бизнес-системам. Из расшифровки их доклада на Tarantool Conference 2018 вы узнаете, зачем нужен R&D в корпорациях, что такое Tarantool, как тупик вертикального масштабирования и глобализация стали предпосылками появления этой БД в компании, про технологические вызовы, трансформацию архитектуры, и чем техностек МегаФон похож на Netflix, Google и Amazon.

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



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


О спикере: Алексей Лесовский (lesovsky) начинал системным администратором Linux. От задач виртуализации и систем мониторинга постепенно пришел к PostgreSQL. Сейчас PostgreSQL DBA в Data Egret — консалтинговой компании, которая работает с большим количеством разных проектов и видит много примеров повторяющихся проблем. Это ссылка на презентацию доклада на HighLoad++ 2018.

Все хорошие стартапы либо быстро умирают, либо дорастают до необходимости масштабироваться. Мы смоделируем такой стартап, который сначала про фичи, а потом про перфоманс. Перфоманс будем улучшать с MongoDB — это популярное NoSQL-решение для хранения данных. С MongoDB легко стартовать, и многие проблемы имеют решения «из коробки». Однако, когда нагрузка растет, вылезают грабли, о которых вас заранее никто не предупреждал… до сегодняшнего дня!



Моделирование проводит Сергей Загурский, который отвечает за инфраструктуру бэкенда вообще, и MongoDB в частности, в Joom. Также был замечен в серверной части разработки MMORPG Skyforge. Как сам себя описывает Сергей — «профессиональный набиватель шишек собственным лбом и граблями». Под микроскопом — проект, который использует стратегию накопления для управления техническими долгом. В этой текстовой версии доклада на HighLoad++ будем двигаться в хронологическом порядке от возникновения проблемы до решения с помощью MongoDB.

РИТ++ — это профессиональный фестиваль для тех, кто делает Интернет. Прямо как на музыкальном фестивале у нас много потоков, только вместо музыкальных жанров — IT-тематики. Мы, как организаторы, стараемся угадать тренды и найти новое звучание. В этом году это «качество» и конференция QualityConf. Не обходим стороной любимые мотивы в новых интерпретациях: распил монолита и микросервисы, Kubernetes и CI/CD, CSS и JS, рефакторинг и performance. Конечно, представляем новые и хитовые темы. Всё как у людей, включая горы сложного оборудования, мерч и выпивку!

Последние два — только для гостей фестиваля. А вот оборудование пойдет в дело для трансляции. И по хорошей традиции Главный зал — то есть как раз самые востребованных «исполнителей» — мы бесплатно транслируем на нашем youtube-канале.



Подключайтесь к трансляции 27 мая в 9:30, увидите и услышите много айтишно интересного, расписание под катом.

Если бы хайлоад преподавали в школе, в учебнике по этому предмету была бы такая задача. «У соцсети N есть 2 000 серверов, на которых 150 000 файлов объемом по 900 Мб PHP-кода и стейджинг-кластер на 50 машин. На серверы код деплоится 2 раза в день, на стейджинг-кластере код обновляется раз в несколько минут, а еще дополнительно есть „хотфиксы“ — небольшие наборы файлов, которые выкладываются вне очереди на все или на выделенную часть серверов, не дожидаясь полной выкладки. Вопрос: считаются ли такие условия хайлоадом и как в них деплоить? Напишите не менее 5 вариантов деплоя». Про задачник по хайлоаду можем только мечтать, но уже сейчас мы знаем, что Юрий Насретдинов (youROCK) точно бы решил эту задачу и получил «пятерку».


На простом решении Юрий не остановился, а дополнительно провел доклад, в котором раскрыл тему понятия «деплой кода», рассказал про классические и альтернативные решения масштабного деплоя кода на PHP, проанализировал их производительность и презентовал самописную систему деплоя MDK.