«Собираемся запустить своё облако»: Одноклассники о Java и не только13.10.2016 15:18

Как в Одноклассниках использование sun.misc.Unsafe сочетается с повышенными требованиями к надёжности? Почему там дорабатывали систему мониторинга Cacti? Как работа в ОК пересекается с научной деятельностью? Если соцсеть называется «Одноклассники», то состоит ли весь её Java-код из одного класса?

Ответы на эти и другие вопросы — в нашем посте. В преддверии Joker, где сразу трое сотрудников ОК будут спикерами, а ещё один участвует в программном комитете, мы расспросили всех четверых — и не только их. На наши вопросы ответили:

• Олег Анастасьев, ведущий разработчик (участник программного комитета Joker 2016)
• Андрей Паньгин, ведущий разработчик (спикер Joker 2016)
• Виталий Худобахшов, ведущий аналитик (спикер Joker 2016)
• Дмитрий Бугайченко, инженер-аналитик (спикер Joker 2016)
• Андрей Губа, заместитель технического директора
• Кристина Штейнберга, руководитель отдела персонала

Олег Анастасьев (ведущий разработчик)

— Мы пляшем от задачи: любое техническое действие должно отвечать на простой вопрос «зачем». Если оно отвечает на этот вопрос — мы будем этим заниматься, нет — не будем.

И поэтому с версиями Java получается по-разному. Java 8 мы вводили ускоренными темпами, потому что там были лямбды. В разработке веб-частей портала мы используем собственный функционально-ориентированный фреймворк, приходилось писать много анонимных классов. И Java 8 отлично ложилась на нашу задачу: с ней получалось сократить код лямбдами, он оказывался и читаемее, и быстрее.

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

Более того, в определённом отношении Java 9 сделает нашу жизнь сложнее, а не проще: из-за отказа от sun.misc.Unsafe, который мы используем. Unsafe позволяет удобно, не покидая Java, реализовывать много низкоуровневого кода, без него мне пришлось бы заниматься написанием этого кода, допустим, на C. Даже если бы JNI быстро работал (а это не так), пришлось бы потратить гораздо больше усилий на разработку.

Кроме того, поскольку мы гигантский высоконагруженный проект, для нас, конечно, важна надёжность. Поэтому до перехода мы должны быть уверены, что всё уже работает достаточно стабильно и не хуже предыдущей версии. Так что устанавливать Java 9 в день general availability не собираемся точно, хотя, конечно, начнём её тестирование.

— Слушайте, а как «важна надёжность» сочетается с использованием Unsafe в продакшене?

— Разумеется, при использовании Unsafe легко можно многое сломать. Но если ты очень хорошо понимаешь, что делаешь, то знаешь, что именно можешь сломать, и знаешь, важно ли это конкретно в твоём случае.

Например, в определённых случаях может сломаться принцип «write once, run anywhere»: получится код, который не на всём будет запускаться корректно. Но если для Java в целом это важно, то у нас своя специфика. Мы запускаем код на вполне определённых серверах. Мы явно не поменяем завтра свой серверный парк на что-то совершенно другое. И наша цель в том, чтобы код на этих серверах работал как можно более оптимально.

А в таком случае принципе «write once, run anywhere» начинает не помогать, а мешать: он не позволяет программисту воспользоваться теми возможностями операционной системы, с которыми он мог бы получить значительно более быстрый и оптимальный код. Например, не позволяет брать страницу памяти напрямую у ОС. Не позволяет рекомендовать ОС, как кэшировать определённую область памяти, нужно ли вообще это делать, как долго. В Java таких встроенных возможностей в принципе нет, а с помощью Unsafe это реализуется просто.

Мотивация Oracle для отказа от Unsafe понятна: да, он предоставляет много способов выстрелить себе в ногу, и у многих людей всё заканчивается этим. Но хочется заметить, что есть ещё и наш случай, в котором отказ от Unsafe — это не «у ребёнка отобрали топор, чтобы он себе пальчик не порезал», а «взрослые лишаются простого и полезного рабочего инструмента». И приходящие ему на смену VarHandles помогают лишь в одном из наших кейсов.

А вообще говоря, в идеале мне хотелось бы даже не Unsafe. Мне хотелось бы, чтобы в Java была возможна более тесная интеграция с ОС, множеством библиотек, реализованных на других языках, C и Go, возможность писать низкоуровневый код с ручным управлением памятью, где это нужно, вплоть до возможности в любой момент переходить на ассемблер и попросту писать код на нём в тех местах, где скорость критична.

 — Вы как участник программного комитета Joker уже увидели многие доклады. Понравился ли вам какой-нибудь особенно, на что можете порекомендовать сходить?

— Мне очень понравился своей практичностью доклад Филипа Дельгядо «СУБД: индивидуальный пошив и подгонка по фигуре» — о том, как, хорошо зная возможности своей СУБД, можно быстро решать сложные задачи и одновременно избежать усложнения архитектуры приложения.

И, конечно, я пристрастен, но очень интересен доклад Андрея Паньгина. Также точно стоит послушать Дмитрия Бугайченко из Одноклассников о том, как применять стриминговый анализ десятков миллионов событий в секунду. Для такой задачи «просто взять Spark» — не вариант.

Андрей Паньгин (ведущий разработчик)

— У меня было на примете несколько тем, но слушатели сами выбрали мифы про performance. Что ж, значит, буду рассказывать про то, как Java тормозит. Или не тормозит — у кого как:)

В общем, поделюсь особенностями JVM, касающихся производительности, и расскажу, как легко ошибиться при анализе performance-проблем.

— Год назад вы в «Без слайдов» рассказывали о том, как всё технически устроено в ОК —, а за этот год что-либо ощутимо изменилось? Хоть количественно, хоть качественно.

— Конечно. Количество серверов, объём хранилищ и трафик — это то, что растёт постоянно. Один только трафик за минувший год удвоился.

Мы запустили несколько новых самостоятельных проектов, в частности, OK Live и OK Сообщения. Естественно, они требовали и новых технических решений.
Год назад у нас вообще видеостриминга толком не было, теперь же онлайн-трансляции доступны всем пользователям на любых устройствах.

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

Научились «нарезать» видео на GPU. По нашим замерам, видеокарты транскодируют распространённые форматы видео в 3 раза быстрее, чем CPU.

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

Есть и много других технических интересностей, которые пока ещё в исследовательской стадии. Когда дойдёт дело до запуска — непременно расскажу и о них.

— Из-за названия «Одноклассников» не удержимся от такого вопроса:, а сколько всего в их коде Java-классов?

— Сложно сказать. Программный код «Одноклассников» включает более 300 модулей. Все вместе я их никогда не видел. У меня на работе выкачана примерно четверь, и это порядка 50 тысяч классов. Самый крупный модуль насчитывает свыше 8000 классов.

— Класс!

Виталий Худобахшов (ведущий аналитик)

— Я ведущий аналитик. Мне приходится делать много разных вещей, по большей части моя работа связана с анализом больших объёмов данных с помощью Spark/Scala или других подобных средств. Занимаюсь обработкой данных и построением всяких моделей. Иногда приходится придумывать разные алгоритмы и писать реализацию на всех уровнях, включая раздачу данных пользователями по средствам высоконагруженных сервисов на Java, но по большей части я занимаюсь разработкой матмоделей.

— В материале «Хакера» вы упомянули о ситуациях, когда int-адресации не хватает —, а часто ли вам в ОК с их объёмами данных приходится сталкиваться с подобными ситуациями на практике?

— При обработке больших данных ситуация с нехваткой int-адресации несколько раз действительно случалась. Не могу пока назвать эту проблему распространённой, но она будет всё чаще встречаться на практике. Int-адресация является только частью проблемы. К примеру, многие люди говорят, что LinkedList — это плохая структура данных, однако использование ArrayList большого объёма часто невозможно из-за фрагментации или Promotion Failure — так что это немного более глубокая проблема, чем люди о ней думают. Я действительно использовал код, подобный тому, что описал в «Хакере» для больших расчётов, и я бы сказал, что структур данных с long-адресацией не хватает. Собственно, если найду время, напишу свою библиотеку.

— Очевидно, что данных для анализа у ОК много —, а если подходить не количественно, а качественно, есть ли у них своя уникальная специфика?

— На самом деле, объём не является единственной характеристикой больших данных даже в общем случае. Да, есть, конечно своя специфика. Самая очевидная — это социальный граф, и это уже очень много специфики. Более того, когда контент генерируется в таком объёме и настолько разный по типу (и языку), это создаёт массу разных трудностей. Пользователи довольно изобретательны и своих ухищрениях и простодушны в других своих действиях, всё это вместе создаёт очень много трудностей и интересных задач на разных уровнях.

— О чём вы расскажете на Joker?

— Я буду говорить об очень популярной теме функционального программирования в контексте обработки больших данных с примерами на Scala/Spark. Расскажу, чем живёт функциональное программирование на практике и почему оно стало популярно именно сейчас. Про основные черты ООП и область его применения многое известно, есть паттерны, есть инкапсуляция/наследование/полиморфизм, многие думают, что это какие-то особенные черты именно ООП, и мало кто может сходу сказать, про что вообще функциональная парадигма. И, конечно, всё это особенно интересно в контексте модели MapReduce.

Дмитрий Бугайченко (инженер-аналитик)

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

В какой-то момент подошли и к такому сложному объекту, как лента, и здесь понадобилось фундаментально менять подход к разработке системы: большие объёмы, жёсткие требования на скорость реакции, разнородность типов контента и так далее. В результате задачи ленты стали мощным драйвером для нашей аналитической инфраструктуры, развитием которой занимался и я.

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

— У вас научный бэкграунд — помогает ли он при работе в Одноклассниках?

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

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

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

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

Вторая причина — это, конечно, данные. Работая в Одноклассниках, мы имеем доступ к очень большим объёмам статистических данных, который в академической среде просто так получить очень сложно.

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

— При работе в ОК продолжаете ли параллельно вы (а также ваши коллеги) научную деятельность? Публикуются ли научные статьи, основанные на полученном в ОК опыте?

— Я работаю в университете как преподаватель. Кроме того, мы стимулируем развитие российского data science-сообщества: устраиваем конкурсы, хакатоны, публикуем в открытом доступе часть анонимизированных датасетов, построенных на основе реальных данных. И в этом отношении продолжаю.

Что касается научных статей, действительно появлялись связанные с ОК: например, у нас есть запатентованная система музыкальных рекомендаций, про которую были опубликованы статьи. Но выпускать их получается нечасто, самой свежей полтора года. Мы компенсируем это выступлениями на разных конференциях, как технологических вроде Joker, так и академических — там есть что рассказать про рекомендательные системы, про анализ данных.

— К вопросу о Joker: о чём расскажете там?

— Расскажу о системе, которая в Одноклассников используется для подсчёта CTR объектов в нашей ленте. А также о разных особенностях стандартных хранилищ, которые используются в Java-экосистеме, и об альтернативном подходе к обработке данных: не с использованием хранилища key-value, а с использованием потокового анализа.

Андрей Губа (заместитель технического директора)

— Наверное, можно сказать, что я «занимаюсь эксплуатацией». Формально курирую направления системного администрирования, информационной безопасности. Руковожу командами API и платформы. Команда платформы — это разработчики, занимающиеся одними из самых сложных задач. Они пишут свои собственные протоколы, по которым общаются наши приложения, свои собственные системы хранения данных — недавно запустили новую.

— Про запуск хочется узнать подробнее: зачем эту систему понадобилось писать, в чём её особенности?

— У нас и раньше уже работала своя собственная система, в которой мы хранили фотографии, музыку, видео. Но поскольку объёмы растут (в частности, сервис видео очень активно развивается), всё актуальнее вопрос стоимости хранения. А кроме того, поскольку количество серверов увеличивается, встаёт вопрос удобства эксплуатации. И мы приняли решение переделать имеющуюся систему, исходя из этих двух соображений. Собрали список того, чего хотим добиться, и написали новую согласно нему. Сейчас она уже работает в продакшене.

Вот, скажем, наглядная метрика: в ней replication factor 2.1, то есть мы храним все данные в 2.1 копии. А до этого была система, распределённая между тремя дата-центрами, где было три копии, в каждом по одной. Сейчас мы храним копии и некие контрольные суммы, и могли бы потерять целиком любой из дата-центров, не потеряв при этом данные и сохранив функциональность.

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

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

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

— А в случае с системным администрированием у вас тоже есть какие-то собственные решения?

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

Например, так произошло с системами мониторинга и статистики. Если использовать популярную систему Cacti на нескольких сотнях серверов, она будет успешно работать. Но у нас 8500 серверов, и на таких масштабах она в стандартном виде работать не станет, приходится модифицировать.

— Помимо собственных инструментов, в чём специфика администрирования в «Одноклассниках»?

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

И важная часть работы оказывается не технической, а организационной: добиться того, чтобы в относительно небольшой и распределённой команде все определённым образом действовали и обменивались информацией. Должны быть выработаны стандартные процедуры, все должны их знать, и при добавлении новых людей они тоже должны узнавать всё необходимое.

Кристина Штейнберга (руководитель отдела персонала)

— На данный момент в компании около 120 разработчиков. Расположены в трёх городах: Москва, Петербург и Рига. Релокации происходят не очень часто, но время от времени кто-то переезжает в другой офис.

— Поскольку Joker пройдёт в Петербурге, отдельно уточним: какие команды/процессы находятся в петербургском офисе?

— Там почти вся разработка продуктов: мобильные приложения, видео, музыка и так далее.

— Какую отдачу приносит вам участие в Java-конференциях, какой фидбэк получаете?

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

— У части разработчиков существует предубеждение по отношению к ОК. Хочется ли что-то сказать таким?

— Хочется сказать, что все люди разные, кому-то нравятся велосипеды, а кому-то автомобили :) Разработчики, которые знакомы с тем, что мы делаем, знают, что в ОК очень интересные технически задачи. Тут есть очень много вызовов для решения проблем высоконагруженных систем.

— Спасибо! Будем ждать вас всех на Joker 2016 —, а пока что вспомним некоторые предыдущие докладов спикеров из Одноклассников:

Комментарии (0)