Хабрахабр

А мишка-то, похоже, высоконагруженный

В конце июня Новосибирск второй раз принимал 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 записей из одного топика в другой. О конкретной реализации Артём тоже рассказал — с одной стороны, в ней все на поверхности, ведь Kafka гарантирует, что если последовательно послать две записи в партицию топика, они будут доставлены в том же порядке. Остановились на продьюсере с асинхронным ожиданием доставки, посчитав, что 20–30 секунд — приемлемое время восстановления. На данный момент уведомления о совершенной операции отправляются в банк примерно за 0,5 секунды. С другой стороны, разработчикам пришлось глубоко погрузиться в особенности работы и документацию.

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

Они организовали целую лаунж-зону, в которой все два дня проводили конкурсы и игры. Раз уж упомянули ЦФТ, расскажем, как их партнерство украсило конференцию. Среди гостей: Владислав Блинов и Валерия Баранова из Тинькофф Банка, Сергей Спорышев из ITSumma, Виктор Еремченко из Miro, Сергей Половко из Яндекса, а также Олег Бунин и Алексей Обровец (разговор, о чем говорят мужчины в 2019). Но гвоздем программы стала StudioCFT — выездная студия по записи подкастов со спикерами и гуру конференции. Интервью выложены на 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 и для задач распознавания образов и для классификации в принципе, и рассказал о трюках, которые делают его более эффективным.

Для текстов классно сработало Byte Pair Encoding, а обучение в FP16 с Apex от Nvidia экономит 20% (двадцать!) времени практически на халяву. А включение довольно несложных knowledge distil и декомпозиции почти даром дают +0,5–1% к AP.

Хороший вариант, как с этим быть, появился недавно. Как нести модели на продакшн — это отдельный большой разговор, потому что data scientist’ы хотя PyTorch, а деплоить его вообще никто не хочет. При такой конвертации все работает точно так, как на Python, а первая волна багов уже отловлена — можно пользоваться.  Разработчики PyTorch осознали всю боль их пользователей и выпустили TorchScript, который сериализует модель на Python в статический граф.

Масштабирование в масштабе Amazon 

Василий Пантюхин (Amazon Web Services)

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

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

Этот доклад полезен и как обзор для тех, кто только начинает работу с AWS, так и тем, кому нужны технические подробности, — то есть всем. Больше всего в выступлении Василия подкупает вдохновение, с которым он рассказывает о решениях, и упомянутый факт, что окунувшись во внутреннее устройство, стал только больше доверять сервисам компании.

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

Бэкенд на NodeJS

Юрий Гавшин (Bolt)

За последние три года компания по всем показателям выросла больше чем в десять раз, поэтому главные требования к бэкенду: быстрый вывод в продакшн, отказоустойчивость и упругость (упавший сервис, не затрагивает работоспособность соседних), масштабируемость. Bolt — с английского быстрое перемещение — платформа для предоставления транспортных услуг: такси, частный извоз, мотоциклы и прокат электросамокатов.

Его отличительная особенность — неблокирующий ввод/вывод и асинхронная работа с сетью. Основа стека — NodeJS. Вроде бы причин, выбрать Node вместо зрелого серверного языка не так много, но короткий time-to-market как раз одна из них, поэтому продакшн-опыт разработки высоконагруженного бэкенда очень интересен. Однозначного мнения, хорошая ли это идея, и насколько сложные сервисы можно сделать на NodeJS, в сообществе пока нет. Уделил внимание такой особенности, как неудобство постройки монолитов. Тем более Юрий подробно и с примерами рассказал, как эффективно использовать плюсы и нивелировать минусы NodeJS, например, порекомендовал использовать TypeScript и переходить на async/await. Затронул темы тестирования и мониторинга. NodeJS вынуждает разработчиков ограничивать размер сервисов, и это, по мнению команды Bolt, плюс.

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

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

Где родился, там и пригодился

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

Контент на наших конференциях не повторяется, поэтому если хотите быть в курсе всего, что творится в мире высоких нагрузок, встретимся в ноябре в Сколково. Тут правда надо заметить, что ездить в Москву мы все равно советуем.

Нетворкинг и др.

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

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

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

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

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

Те же, кто не поддался, шли на митапы.

Когда после этого мозг уже перешел в турборежим, любые задачки на листочке и головоломки становятся нипочем и решаются в два счета.

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

Душевно. Короче, хорошо провели время.

Что дальше

Скажем честно, мы видим много точек роста, и уже планируем, что изменится в HighLoad++ Siberia 2020 и в какие еще темы надо подбросить дров. 

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть