В конце июня Новосибирск второй раз принимал HighLoad++. Если в прошлом году эффект новинки сыграл свою немалую роль в том, что все всем были довольны, то в этот раз нам нужно было подготовиться гораздо тщательнее, чтобы сохранить и превзойти впечатление. В первую очередь с утроенной силой мы взялись за главное — программу. Теперь, когда выступления состоялись и даже уже выборочно пересмотрены по второму кругу, собраны и обработаны отзывы участников конференции, можно уверенно заявить, что удалась она на славу.
Основу HighLoad++ Siberia составили 38 отличных докладов, полных опыта и глубочайшей экспертизы. Международные гиганты и региональные компании — все делились опытом работы с задачами, для решения которых стандартных средств просто не существует. А особенной конференцию сделали люди. Мы честно пытались понять, в чем дело, и как сделать настолько же душевные мероприятия в других местах, но нет — за непередаваемой дружественной атмосферой придется снова ехать в Сибирь, и мы только за. К тому же мы уже думаем над новинками.
Медведя привезли с собой, ни один представитель местной фауны не пострадал.
Но что мы не собираемся менять, так это подход в выборе докладов. Разве что начнем утверждать темы раньше, что уже применяем: HighLoad++ в Москве через 4 месяца а некоторые доклады уже объявлены. Пока это единственная в Сибири конференция по высоким нагрузкам, и количество полезной информации и технических хардкорных подробностей составило примерно треть от большого московского брата, а если перейти к плотности на души участников, то она была гораздо выше. Некоторые доклады по мнению программного комитета можно смело внести в топ всех докладов по высоким нагрузкам за последнее десятилетие. Это подтверждают и зрительские оценки — средний балл докладов 4,2.
Чтобы и вы составили свое впечатление о программе HighLoad++ Siberia приводим несколько кратких конспектов. Это не топ рейтинга голосования, и на порядок не надо обращать внимание — это просто набор из интересных тем, достаточно разных, чтобы быть небольшой репрезентативной выборкой. Все видео для полной картины мы постепенно выложим на youtube-канал (подписывайтесь, ставьте лайки, жмите колокольчик — вот эти вот все блогерские штуки, чтобы видеть обновления).
Видеозвонки: от миллионов в сутки до 100 участников в одной конференции
Александр Тоболь (Одноклассники)
Сейчас во всех популярных мессенджерах есть возможность позвонить собеседнику. Конечно, ведь удобно использовать один и тот же инструмент для любой связи. Поэтому, если у вас есть корпоративное средство общение, но звонков там еще нет, их стоит добавить. С чего начать, какие протоколы и технологии использовать, знает Александр Тоболь (alatobol). Даже если в ближайшее время разрабатывать сервис видеозвонков вы не планируете, то в докладе Александра полно хардкорных подробностей о сетях передачи данных вообще. Вероятно, поэтому его доклад получил, кажется, рекордную оценку слушателей в 4,9 из 5.
В прошлом году Александр подробно рассказывал про устройство P2P звонков, а в этот раз только напомнил основные моменты и перешел к особенностям, например, сигналинга и кодирования для звонков один ко многим. Несложно понять, что если у одного из участников просело качество связи (а большая часть подобного трафика идет через мобильные сети), то битрейт придется понизить для всех участников разговора. А вот чтобы решить, что с этим сделать, имеет смысл посмотреть, чего достигли в этом направлении другие, и — очевидно — взять лучшее, а недостатки исправить.
В Одноклассниках выбрали:
- не использовать софтверные кодеки, а кодировать H.264;
- использовать весь канал под один поток, т.е. не кодировать и не отправлять видео в двух разрешениях;
- использовать end mixing для высокого качества, и централизованную схему для низкого;
- до 3–4 участников предпочтительный вариант — Mesh.
В итоговом сравнении это решение сопоставимо с Zoom по задержке, потреблению батарейки и качеству, но Zoom не совместим с WebRTC (и новости про него мы все читали). Когда решите повторить процедуру и тоже сравнить конкурентов — не забудьте OK. Или сразу воспользуйтесь советами Александра, его доклад в очередной раз был полон важных технических подробностей, что, кажется, вполне сойдет за инструкцию DIY.
Как создать высоконагруженную систему отправки уведомлений по событиям
Артём Гашкин (ЦФТ)
Компания ЦФТ яркий представитель региональной IT специфики — большой финтех enterprise. В этом докладе речь шла о работе процессингового центра КартСтандарт, который — только вдумайтесь — обрабатывает платежи по каждой третьей карте в стране.
Как только вы за что-то платите, именно этот процессинг информирует вас по СМС или push. Банк, выпустивший вашу карту — эмитент, тоже хочет получать такое уведомление онлайн. Это и есть цель проекта, о котором рассказал Артём Гашкин: реализовать модуль отправки уведомлений, который справлялся бы с двойной нагрузкой. К сожалению, точных данных Артём назвать не имел права, сказал лишь, что нагрузка на отдельные модули достигает 200 транзакций в секунду. В то же время велись работы по уменьшению нагрузки за счет изменения настроек системы. Разработчики хотели сделать такой запас по производительности, чтобы не возвращаться к этому вопросу как можно дольше. Требования к решению достаточно стандартные, но главное — время обработки авторизаций не должно увеличиться.
Традиционно для enterprise-компании используется Oracle, который, если и можно, то очень сложно горизонтально масштабировать. Поэтому, чтобы не увеличивать нагрузку на БД, т.е. держать минимальное количество соединений с БД, был выбран Apache Kafka.
К выбору варианта реализации подошли как и положено инженерам — измерили время перемещения 400 000 записей из одного топика в другой. Эти данные можно интерпретировать как время, за которое процессинг восстановит свою работоспособность после сбоя. Остановились на продьюсере с асинхронным ожиданием доставки, посчитав, что 20–30 секунд — приемлемое время восстановления. О конкретной реализации Артём тоже рассказал — с одной стороны, в ней все на поверхности, ведь Kafka гарантирует, что если последовательно послать две записи в партицию топика, они будут доставлены в том же порядке. С другой стороны, разработчикам пришлось глубоко погрузиться в особенности работы и документацию. На данный момент уведомления о совершенной операции отправляются в банк примерно за 0,5 секунды.
Масштабировать получившуюся систему легко — если увеличивается нагрузка, нужно увеличить количество конкретных обработчиков. Модули маршрутизации и отправки уведомлений работают без изменений, а за бизнес-логику отвечает модуль, который формирует уведомления. Когда потребуется также быстро отправлять, например, одноразовые пароли, то достаточно будет реализовать новые обработчики. Это доработка никак не затронет существующую систему, и все регрессионные тесты пройдут без проблем.
Раз уж упомянули ЦФТ, расскажем, как их партнерство украсило конференцию. Они организовали целую лаунж-зону, в которой все два дня проводили конкурсы и игры. Но гвоздем программы стала StudioCFT — выездная студия по записи подкастов со спикерами и гуру конференции. Среди гостей: Владислав Блинов и Валерия Баранова из Тинькофф Банка, Сергей Спорышев из ITSumma, Виктор Еремченко из Miro, Сергей Половко из Яндекса, а также Олег Бунин и Алексей Обровец (разговор, о чем говорят мужчины в 2019). Интервью выложены на youtube-канал компании.
Самый лучший GEODIST() к западу от Рио-Гранде
Андрей Аксенов (Авито, Sphinx)
«Используйте линейную интерполяцию, пацаны».
Начал Андрей в привычном ироничном стиле, дескать, если это понятно, то можно расходиться. Понятно-то оно понятно, но если приложить еще и опыт разработчика Sphinx, на котором в Авито работает поиск, то всяко будет лучше. Темой для HighLoad++ Siberia Андрей выбрал функцию GEODIST(), которая в частности используется для сортировки, фильтров, поиска по карте и т.д.
Задача: найти расстояние между двумя точками, заданными двумя координатами. Казалось бы, седьмой класс, вторая четверть. Но если расстояние вычисляется не в пределах тетрадного листочка, а хотя бы в масштабах одной области РФ, то расстояние надо считать на «сфере». А точнее, эллипсоиде. А совсем точно, геоиде. Как все-таки не связываться с геоидом, какие аппроксимации и древние техники оптимизации работают в большом продакшене, пересказывать не будем — смотрите доклад.
Опыт моделеварения от команды ComputerVision Mail.ru
Эдуард Тянтов Mail.ru Group
Команда компьютерного зрения решает задачи для проектов Облака, Почты и специализированного B2B продукта Vision. Это распознавание лиц и достопримечательностей для фотографий, текста с фотографии для почты и т.д. Содержательную часть своего доклада Эдуард Тянтов (EdT) начал с утверждения, подходящего для любой области, но особенно актуального для AI:
«Постановка задачи — критически важный этап».
На этом этапе необходимо постоянная совместная работа Product-менеджера и специалиста по машинному обучению. Если пытаться на нем сэкономить, то вы либо пропустите что-то действительно важное, либо потратите несколько месяцев на то, чтобы научиться распознавать рисованные лица, а продакшн-модель никогда не встретит ни одного такого примера. Кстати, о других особенностях ведения проектов, в основе которых лежат технологии машинного обучения, Эдуард будет рассказывать в сентябре на UseData Conf.
И только, когда постановка ясна для всех участников проекта, можно приниматься за работу над задачей, которая начинается с подготовки данных. Их, очевидно, нужно чистить, как от плохой разметки и мусора внутри классов, так и от излишних либо недостаточных делений на классы. А иногда данные приходится генерировать, и если для задачи распознавания символов достаточно взять PIL и исказить текст, то в других случаях нужно быть куда изобретательнее.
Переходя непосредственно к обучению, в области metric learning Эдуард, опираясь на обширный опыт Mail.ru, однозначно рекомендовал Angular Softmax и для задач распознавания образов и для классификации в принципе, и рассказал о трюках, которые делают его более эффективным.
А включение довольно несложных knowledge distil и декомпозиции почти даром дают +0,5–1% к AP. Для текстов классно сработало Byte Pair Encoding, а обучение в FP16 с Apex от Nvidia экономит 20% (двадцать!) времени практически на халяву.
Как нести модели на продакшн — это отдельный большой разговор, потому что data scientist’ы хотя PyTorch, а деплоить его вообще никто не хочет. Хороший вариант, как с этим быть, появился недавно. Разработчики PyTorch осознали всю боль их пользователей и выпустили TorchScript, который сериализует модель на Python в статический граф. При такой конвертации все работает точно так, как на Python, а первая волна багов уже отловлена — можно пользоваться.
Масштабирование в масштабе Amazon
Василий Пантюхин (Amazon Web Services)
Этот доклад — характерный пример, как мы получаем мировой опыт от международных компаний. Все верно — зовем русскоязычных ребят, выросших в нашей инженерной культуре и на наших конференциях. Иностранные спикеры хороши для рекламы, но по факту участники обычно оценивают их доклады не слишком высоко. Наши, в смысле вообще в России, профессиональные конференции направлены на обмен профессиональным опытом. А за рубежом популярны доклады про новинки компании, которые у нас не возьмет в программу ни одна специализированная техническая конференция. Почему так — отдельный вопрос, но мы при прочих равных стараемся выбирать русскоязычных спикеров. Это и с точки зрения отсутствия языкового барьера и разницы в менталитете хорошо для понимания материала.
Возвращаясь к AWS, миллионы пользователей одновременно обслуживаются их сервисами, достигая желаемых результатов. Система автоматически масштабируется, эластично подстраиваясь под каждого пользователя так, что ему кажется, что он один в этой вселенной. Так думал и Василий Пантюхин, пока не стал архитектором в Amazon. Теперь, конечно, он знает, что под капотом у облачных сервисов AWS, и поделился некоторыми интересными аспектами с гостями конференции. Какие физические серверы стоят за эфемерным понятием облака, какие для них используются оптимизации, как устроен самый масштабируемый сервис AWS Lambda, как Amazon строит собственные базы данных, как устроена сеть.
Больше всего в выступлении Василия подкупает вдохновение, с которым он рассказывает о решениях, и упомянутый факт, что окунувшись во внутреннее устройство, стал только больше доверять сервисам компании. Этот доклад полезен и как обзор для тех, кто только начинает работу с AWS, так и тем, кому нужны технические подробности, — то есть всем.
А еще Василий провел митап на тему «Мозг-фрэндли диаграмминг», который, судя по обсуждению в чате, был очень полезен. А в записи его не будет, такой это специальный формат. Поэтому лайфхак на будущее: если на нашей конференции вы выбираете между докладом и митапом, то отдайте предпочтению митапу, а доклад потом посмотрите в записи, благо, мы все записываем и отдаем видео уже через несколько дней.
Бэкенд на NodeJS
Юрий Гавшин (Bolt)
Bolt — с английского быстрое перемещение — платформа для предоставления транспортных услуг: такси, частный извоз, мотоциклы и прокат электросамокатов. За последние три года компания по всем показателям выросла больше чем в десять раз, поэтому главные требования к бэкенду: быстрый вывод в продакшн, отказоустойчивость и упругость (упавший сервис, не затрагивает работоспособность соседних), масштабируемость.
Основа стека — NodeJS. Его отличительная особенность — неблокирующий ввод/вывод и асинхронная работа с сетью. Однозначного мнения, хорошая ли это идея, и насколько сложные сервисы можно сделать на NodeJS, в сообществе пока нет. Вроде бы причин, выбрать Node вместо зрелого серверного языка не так много, но короткий time-to-market как раз одна из них, поэтому продакшн-опыт разработки высоконагруженного бэкенда очень интересен. Тем более Юрий подробно и с примерами рассказал, как эффективно использовать плюсы и нивелировать минусы NodeJS, например, порекомендовал использовать TypeScript и переходить на async/await. Уделил внимание такой особенности, как неудобство постройки монолитов. NodeJS вынуждает разработчиков ограничивать размер сервисов, и это, по мнению команды Bolt, плюс. Затронул темы тестирования и мониторинга.
Все, что осталось за кадром доклада, и многое другое можно было узнать у разработчиков сервиса на стенде компании. Кроме технологического стека обсуждали и релокацию в Эстонию — но это уже в рамках митапа, под которые традиционно было место и время. Спонтанные маленькие митапы и живые дискуссии — это то, зачем и нужны конференции. Где еще можно посмотреть на трюки Zabbix с лайвкодингом или поделиться болями документирования.
Вообще в этот раз нас поддержало больше компаний. Думаем, мы прошли проверку в прошлом году и доказали местным, что работаем на их благо.
Где родился, там и пригодился
Так нам кажется. И это основная идея, которую мы преследуем, выводя наши конференции за пределы Москвы. Чтобы крутые разработчики не были вынуждены стекаться в столицу или заграничные офисы крупных компаний потому, что только там для них будут челленджевые задачи, нужно развивать профессиональные региональные сообщества. Например, мы специально пригласили активистов сообществ из Новосибирска и Красноярска, а заодно и Санкт-Петербурга и Краснодара, чтобы они делились опытом и успешнее прокачивали свой регион.
Тут правда надо заметить, что ездить в Москву мы все равно советуем. Контент на наших конференциях не повторяется, поэтому если хотите быть в курсе всего, что творится в мире высоких нагрузок, встретимся в ноябре в Сколково.
Нетворкинг и др.
Вкушать дружественную атмосферу начали еще накануне на встрече докладчиков. Такая у нас теперь традиция — после прогонов на площадке, но до конференции, устраивать посиделки. Чтобы спикеры познакомились друг с другом и программным комитетом, увидели, что люди кругом такие же, перестали волноваться из-за выступления и пришли в понедельник в отличном настроении, готовые передавать свой уникальный опыт.
А потом уже во время конференции у нас тоже был простор для общения и даже развлечения. Не все же в хардкор погружаться, иногда надо и переключиться. Стенды для этого самое оно.
У Сбербанка в качестве подвижных игр была стрельба по мишеням, плюс более привычные айтишникам видеоигры.
Спортмастер не могли остаться в стороне — установили настольный хоккей, который не пустовал ни минуты. А пока ждешь, когда закончится партия и наступит твоя очередь, можно было расспросить разработчиков о продуктах Спортмастера, которые, конечно, не ограничиваются интернет-магазином.
После непрерывного кофебрейка, который отлично подходит для общения с коллегами и новых знакомств, размявшихся и подкрепившихся участников ведущие залов зазывали на доклады.
Те же, кто не поддался, шли на митапы.
Когда после этого уже перешел в турборежим, любые задачки на листочке и головоломки становятся нипочем и решаются в два счета.
А вечером заслуженный отдых.Правда, опять с сильной интеллектуальной составляющей — приготовили для гостей викторину «Квиз, плиз».
Короче, хорошо провели время. Душевно.
Что дальше
Скажем честно, мы видим много точек роста, и уже планируем, что изменится в HighLoad++ Siberia 2020 и в какие еще темы надо подбросить дров.
Мы будем экспериментировать с форматами, не только в отдельных точках конференции, но и всего мероприятия в целом. Присмотримся к другим площадкам, потому что говорят, Новосибирцы любят кэмпы. В любом случае, к следующему лету мы успеем протестировать идеи и приедем уже с проверенным гипотезами.
Напишите в комментариях, чего вам не хватило, какие из конференций Онтико вы хотите видеть в Новосибирске или другом вашем городе. DevOps, TeamLead Conf, KnowledgeConf — раз уж новосибирское сообщество технических писателей очень активно участвуют в её организации — предлагайте, а мы придумаем, как реализовать.
Автор: e_finkel
