Содержание
Читайте в Telegram
|
Привет! В ИТ-сфере часто думают, что продуктовая разработка и прикладная наука — вещи, в реальной жизни довольно мало пересекающиеся.
Отличается примерно всё, например, оценки времени и результата в компании — это фичи, размер их аудитории и количество заработанных денег, а в университетах — научная новизна, число публикаций в рецензируемых научных журналах и индекс цитируемости.
Однако иногда получается настроить симбиоз и достичь довольно значимых (на практике) результатов. В эксклюзивном материале для «Кода Дурова» коллеги из Яндекс 360 поделились, как они решили доверить R&D-задачу учёным из ИТМО и что из этого вышло: барьеры, ограничения классической инженерии, важность постановки ТЗ и многое другое.
Когда классической инженерии уже недостаточно
Яндекс Диск — довольно взрослый сервис с большой историей, и за годы мы добились высокой надёжности, отказоустойчивости и качества сервиса. Но нет предела совершенству, и мы решили поисследовать, что ещё можно улучшить в наших сервисах, где, возможно, уже не хватает инженерного, и требуется более глубокий научный подход. Мы много работаем над скоростью загрузки в Диск, и одной из первых областей для исследований в плане «А что ещё можно улучшить?» стала именно она.
Штука вот в чём. В архитектуре Диска есть очень важный компонент с милым для русского слуха названием «Кладун». Он отвечает за загрузку файлов и без него никак, но при работе с ним возникает одна сложность — абсолютная непредсказуемость пользовательского поведения, производительности сети последней мили и устройств. Когда стартует загрузка файла, система не может предсказать заранее, с какой скоростью файл будет загружаться и будет ли эта скорость стабильной или сильно упадёт после начала загрузки. Мы не знаем, когда пользователь включит торренты или переместится в зону с плохим сотовым сигналом, или наоборот — когда скорость возрастёт, потому что пользовательский канал освободится от просмотра видео в 4K, например. В общем, переменных много, а хрустального шара нет.
А вот что есть в таком случае — это критический дисбаланс ресурсов (CPU, диски, сеть). Нагрузка неравномерная, один сервер мог в процессе забиться под завязку из-за тяжёлых файлов и медленной сети, а соседний — откровенно простаивать. Как следствие — на перегруженных «кладунах» просто может закончиться место, если с этим ничего не делать.
Чтобы место не закончилось, мы создавали в разные периоды времени жизни Диска разные механизмы распределения нагрузки по текущей загрузке «кладунов», а на случаи непредсказуемого изменения нагрузки на них в будущем просто держали резерв свободного места и сети на «кладунах» побольше.
Трудности перевода
Мы подробно описали нашу задачу и разослали клич по нескольким вузам. В итоге остановились на ИТМО, причём не столько из-за общей сильной экспертизы, сколько из-за наличия у учёных практического опыта в смежных областях.
Звучит, конечно, хорошо, но есть нюансы: Яндекс 360 — большая компания, ИТМО — университет со своими процессами. Самых главных барьера было два.
Первый — ожидаемый корпоративный скепсис. Именно в коммерческой разработке к академическим исследованиям часто относятся с недоверием. Не все в таких случаях уверены, что вложенное во взаимодействие с университетом время принесёт хоть какой-то выхлоп. Это проблема, но ожидаемая, и вот почему: часто в таких случаях на выходе получают набор красивых дипломных работ (очень далёких от прода) и несколько пресс-релизов об эффективной совместной работе.
Однако специалистам ИТМО удалось почти сразу нивелировать эти сомнения — учёные тщательно проанализировали наши реальные паттерны нагрузки, предложили несколько вариантов оптимизаций и смогли убедить нас, что результат тут будет. Спойлер: и он действительно будет осязаемым.
Второй — разница в подходах и языках. Со стороны тоже кажется немного очевидным, но вот тут нам по-настоящему пришлось попотеть. Мы де-факто заново учились ставить задачи. Ведь то, как долгие годы ставят задачи в компании, и то, как к этому привыкли в университетах, это две разных вселенных. В академическом мире на самом деле своя атмосфера и скорость течения времени, а также парадигмы мышления. И наш бизнес-запрос вида «сделайте, чтобы “кладуны” были более равномерно загружены» надо было нормально и полноценно переложить на язык математики — «нужно уменьшить дисперсию объёма трафика, заливаемого в каждый “кладун” в единицу времени».
Что нам помогло
То, что мы не взялись за задачу единым куском, а чётко поделили всё на смысловые этапы. Большой проект мы разбили на три фазы — обзор и анализ возможных вариантов решения, моделирование и разработка алгоритма, а также исполнение.
ИТМО в этой схеме стал партнёром по исследовательской части, учёные провели поиск потенциально подходящих методов и алгоритмов, математическое моделирование и разработку нужного алгоритма. А вот именно техническую реализацию проекта и программирование для прода мы отдали нашим инженерам.
Для полноценной синхронизации привычного ритма бигтеха с рабочим подходом университета нам хватало статусных созвонов раз в неделю.
В итоге учёные проанализировали множество методов и алгоритмов, потенциально подходящих под решение задачи оптимизации дисперсии. Затем провели моделирование и подстройку наиболее перспективных методов и алгоритмов под наши паттерны нагрузки и предложили нам наиболее эффективный, который мы и реализовали в продакшне.
Итог — экономия на железе и трансфер технологий
Скажем честно, пилот ощутимо превзошёл ожидания и принёс сразу несколько важных результатов.
- Технологическая польза и экономия ресурсов. С помощью наших реальных данных с прода учёные смогли подобрать алгоритм, который смог не просто уменьшить дисперсию нагрузки, а уменьшить её вдвое, и теперь нагрузка равномерно распределяется по доступным серверам. Для бизнеса это в первую очередь возможность отказаться от большого парка железа «про запас», читай — серьёзная экономия средств. Для пользователей — загрузка осталась стабильной и предсказуемой, и скорость передачи данных на Диск быстро подстраивается под их актуальное состояние сети.
- Трансфер технологий. Нам кажется, это важный прецедент — вышло так, что научные исследования в итоге стали не просто диссертациями, а были успешно раскатаны в прод на многомиллионную аудиторию. А бизнес на практике понял, что взаимодействие с наукой работает.
- Развитие инженерной культуры. В целом наши внутренние практики разработки не изменились, а вот майндсет команды — да. Ведь инженеры получили проверенный на практике инструмент для решения сложных нестандартных задач. Можно сказать, это обнулило страх «белого листа» — если раньше к какой-то инициативе могли подходить не сразу просто потому, что вообще непонятно, с какой стороны этого слона есть, то теперь мы знаем: для глубокой исследовательской базы можно взять и призвать на помощь научное сообщество.
Как дальше мы будем работать с наукой
После этого проекта мы официально выводим работу с научными центрами из стадии рискованного эксперимента на уровень стабильного процесса и уже запускаем несколько новых коллабораций.
Одна из них — с МФТИ. Если с ИТМО мы решали задачу силами уже состоявшихся учёных, то в случае с МФТИ хотим поработать с аспирантами. Задача для них будет более хардкорной и низкоуровневой: исследование протоколов загрузки файлов, чтобы ещё больше повысить скорость и надёжность работы Диска. Как пойдёт — расскажем отдельно.
