В рамках же самой конференции Юрий будет рассказывать о том, как социальная сеть вставляет данные в ClickHouse с десятков тысяч серверов, чего в текущей беседе мы коснулись лишь вскользь.
— Расскажи, пожалуйста, о своей работе?
На текущий момент я работаю во ВКонтакте. Правда, не так уж долго — с начала этого года. Занимаюсь видеоинфраструктурой и инфраструктурой сайта. Сайт в основном написан на PHP, и я разрабатываю сервисы и утилиты на PHP и Go.
— Что побудило тебя пойти работать в VK?
Меня пригласили работать в VK. И я подумал — почему бы и нет? ВКонтакте — это самый высоконагруженный сайт России и один из самых больших сайтов во всём интернете. Мне всегда было интересно поработать над таким большим проектом — принять участие в разработке сайта и мобильного приложения. Возможно, даже повлиять на их развитие, как-нибудь улучшить. Наверное, это самый мотивирующий фактор — ВКонтакте все знают и используют. И это очень приятно работать над таким продуктом, помогать ему становиться лучше.
— До этого тебе приходилось сталкиваться с чем-то похожим по масштабу?
Да, около пяти лет я работал в компании Badoo на похожей должности — в разработке инфраструктуры. Но нагрузки в VK на порядок больше.
— Возникли ли какие-то проблемы при переходе в VK?
Офис ВКонтакте находится в Санкт-Петербурге. А я до этого жил в Подмосковье, поэтому мне пришлось переехать. Сам переезд прошёл достаточно легко — компания помогает. Но в Санкт-Петербурге бывает очень холодно зимой. Наверное, это было самым тяжелым, с чем пришлось столкнуться.
— Нет ощущения, что жизнь осталась где-то внутри МКАД?
Поначалу мне действительно так казалось, несмотря на то, что я и ранее бывал в других городах России, помимо Москвы. Но на самом деле мне Санкт-Петербург нравится, наверное, даже больше, чем Москва. Он более спокойный — меньше людей, они никуда не торопятся, и это приятно.
— А с точки зрения используемых в работе технологий — что было для тебя принципиально новым?
ВКонтакте очень большой, соответственно, здесь действительно есть некоторые нюансы, с которыми я раньше не сталкивался. Например, в Badoo практически нет очень популярных профилей, на которые заходит значимый процент людей. У ВКонтакте такое есть, как есть и целый ряд интересных инструментов, позволяющих быстро масштабировать очень популярные аккаунты.
Кроме того, ВКонтакте отличается тем, что по историческим причинам здесь практически всё своё. В отличие от, к примеру, Badoo, который в основном использует MySQL и Memcache (плюс свои сервисы), ВКонтакте использует свои базы данных и даже свою версию Memcache. Разработчики VK могли позволить себе создавать более высокоэффективные сервисы (на фоне того же MySQL), которые хорошо работают на таком огромном масштабе. Большинство готовых инструментов без напильника нельзя использовать в инфраструктуре, включающей десятки тысяч серверов, как у VK, и это создает существенные трудности.
— Сложно ли было быстро вникнуть в такие «внутренние» инструменты?
Я работаю в отделе инфраструктуры, а здесь не так много нестандартных вещей. В основном это даже более стандартный стек, чем тот, с которым я работал ранее. Но если бы я работал, например, в отделе, который занимается фичами на back-end, то там, конечно, пригодились бы знания того, как в принципе строится Highload-система, но не конкретные детали. В таких ситуациях помогают страницы для новых сотрудников, описания внутренних механизмов.
В принципе, ощутимая часть инфраструктуры VK была выложена Павлом Дуровым в open source вместе с документацией. Любой желающий может ознакомиться с ней, почитать, как это все работает. Но, конечно, намного легче это воспринимать в контексте того, как оно используется внутри. Вы приходите и начинаете делать задачи, постепенно изучая то, что нужно для их решения. Смотрите, как это уже сделано, и делаете так же. И этого достаточно. Ведь даже если вы осилите прочтение всей документации по инфраструктуре VK, пока вы не начнете это использовать, скорее всего, не поймете, как это все работает в деталях.
Замечу, что все вышесказанное касается моего отдела (в других может быть иначе).
— Есть ли у тебя внутри VK какая-то специализация? В решении каких задач ты успел поучаствовать?
Специализации как таковой нет. Делаю то, что в данный момент требуется.
Я работаю в отделе, деятельность которого затрагивает разные части инфраструктуры социальной сети, а это огромный проект (чтобы полностью охватить пониманием устройство VK, нужно много времени).
Например, я участвовал в частичном переходе на PHP7. Это в принципе касается всего сайта, но в то же время не относится к каким-то конкретным деталям.
Еще пример — проблема со сбором логов, для решения которой мы использовали ClickHouse. Об этом я как раз и буду рассказывать на HighLoad++.
— Дадим небольшой спойлер — в чем была особенность этой проблемы?
Загвоздка была в сочетании двух факторов: с одной стороны, у нас пишется очень много логов, а с другой — нам их нужно быстро просматривать.
Существующая система по сути не умела хранить большие объемы данных, быстро отдавая только свежую информацию. Чтобы получить историю, нужно было вручную выполнять очень тяжелые запросы.
— Читателям, возможно, будет интересно, почему для решения использовалась именно колоночная ClickHouse?
Колоночная — из-за специфики работы. Зачастую при поиске информации в логах нам нужно фильтровать по серверу или пользователю. Если речь идет о чтении с диска, колоночная БД позволяет многократно ускорить чтение (на фоне строчной), что достигается за счет чтения только нужных колонок и более эффективного поколоночного сжатия. К тому же, ClickHouse хорошо распараллеливает запросы по ядрам. Т.е. в отличие от классических баз данных он может выполнять один запрос даже на целом кластере, используя почти все ресурсы как процессора, так и диска. Таких баз данных, тем более бесплатных, не очень много, если они вообще есть. ClickHouse подошел для задачи хранения логов очень хорошо.
Отмечу также, что ClickHouse и до моего прихода использовался в VK админами в довольно узкоспециализированной задаче — в качестве back-end инструмента Grafana. Это система сбора данных и построения графиков по серверам. Правда, было развернуто всего несколько серверов с ClickHouse, то есть по сути для программистов он был недоступен.
После того, как было принято решение об использовании ClickHouse для хранения логов, я помогал создавать соответствующую инфраструктуру, чтобы это было для всех удобно и понятно.
— Используются ли в VK в каком-то значимом количестве сторонние решения (помимо упомянутых выше)?
Конечно, используются. Например, Linux, на котором всё это крутится. Не стоит преуменьшать долю работы, которую за нас делает операционная система.
Как ни странно, используется PHP. У нас есть самописный движок под названием KittenPHP, который транслирует PHP в C++, но для ряда задач, в том числе в продакшене, применяется и обычный PHP.
Используется nginx. До сих пор в некоторых местах задействован MySQL, но постепенно мы от него отказываемся — используем самописную базу данных.
— А как построен процесс разработки?
Я не вижу больших отличий процессов в VK от того, что принято в индустрии. У нас есть баг-трекер, отделы, которые занимаются разной функциональностью, отвечая за свою часть проекта; есть спринты, ответственные за компоненты и т.д.
— Вместо итогов можно ли обозначить направление, в котором развивается отдел, в котором ты работаешь?
Насколько я знаю, раньше отдел, в котором я сейчас работаю, состоял из 1-2 человек.
И заниматься инфраструктурой в том виде, в каком это делается сейчас (наверное, это похоже на DevOps), начали не так давно. Поэтому пока рано говорить о планах — мы решаем существующие проблемы, и пока работы у нас хватает. А дальше посмотрим.
Подробнее о внутренностях VK, использовании ClickHouse и других деталях Юрий расскажет в своём докладе на сибирском HighLoad++ 25-26 июня. Также вас наверняка заинтересуют и вот эти доклады:
- Репликация данных из MySQL в ClickHouse в реальном времени для плавной миграции аналитики из MySQL в ClickHouse (Владислав Клименко, Валерий Панов)
- Учимся немного ранжировать (Андрей Аксенов)
- Эволюция инструментов и сервисов в Badoo: наши критерии выбора и что из этого получилось (Антон Турецкий)
Комментарии (44)
peresada
22.06.2018 15:09Интересно было бы узнать, что умеет или какие преимущества дает самописная СУБД по сравнению с готовыми решениями.
AterCattus
22.06.2018 16:21Все движки кастомно заточены под свои задачи. И просто эффективнее (обычно), чем более универсальные решения.
peresada
22.06.2018 19:47Это я понимаю, но я имел ввиду конкретно VK, насколько эффективнее или какой функционал они добавили. Тут много ньюансов. Просто когда слышишь, что один из крупнейших сайтов в интернете работает на PHP + MySQL, сразу понимаешь что это не совсем так.
AterCattus
23.06.2018 02:25И я конкретно про ВК. Разных типов баз/движов несколько десятков видов. Каждый делается под конкретные задачи + оптимально встраивается в общую инфраструктуру.
altrus
23.06.2018 15:09Правильно я понимаю, что «кастомная СУБД» это просто определенным образом подточенный MySQL?
youROCK
23.06.2018 15:19Нет, как правило, движки имеют свои структуры данных, которые заточены под конкретные задачи. Есть и СУБД общего назначения, но она не имеет отношения к MySQL и не очень широко используется.
altrus
23.06.2018 15:24То есть, это даже и не реляционная СУБД со своими обычными качествами?
youROCK
23.06.2018 15:54Вы можете сами почитать о том, что умеют и что не умеют разные движки. Как правило, они поддерживают набор операций, которые нужны для работы существующих фич ВК. Обычно нет ни транзакций ни изменяемой схемы. Примеры:
Друзья: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Friends.wiki
Списки: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Lists.wiki
Фото, Документы, и т.д: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Storage.wiki
youROCK
22.06.2018 17:24Ещё немаловажно, что все сишные движки умеют работать по UDP, что важно, когда у вас много серверов, иначе довольно значимая часть памяти на сервере расходуется под поддержание информации о TCP соединениях в ядре, буферах, и т.д.
JekaMas
22.06.2018 18:01+2Неоднозначный вопрос. Когда-то давно был удивлен, что Alibaba со своими дикими нагрузками живет на MySQL и не кашляет.
Тут возникает вопрос, так ли плохи "универсальные" решения.
greabock
22.06.2018 18:58+2Мне кажется, тут дело не в преимуществах. Проблема в том, что все сторонние решения имеют один фатальный недостаток.
youROCK
22.06.2018 19:10+2На большом масштабе, если вы смогли написать свою специализированную базу данных для, например, сообщений, которая требует на 30% меньше ресурсов, то вам вместо условно 1000 серверов нужно будет 700, то есть на 300 штук меньше. Это экономия в миллионы долларов, так что обычно затраты на разработку в таком случае оправданы. Если у вас все помещается в 10 серверов и вы пишете самописную базу, то, возможно, это и правда будет время, потраченное впустую.
greabock
22.06.2018 19:36Простите мне мою оплошность, я забыл что на хабре каждый второй — Шелдон Купер*. Впредь, во избежание недоразумений, я все свои шутки буду помечать курсивом и делать сноску** — дабы не вводить в заблуждение писателей, читателей и комментаторов.
*Шутка.
**Шутка встроенная в шутку — одновременно рекурсия и самоирония.
JekaMas
22.06.2018 22:05А сколько будет стоить ее создание и поддержка? Как эти цифры соотносятся со стоимостью железа? Был проведен анализ и на его основе принято бизнес-решение?
Fesor
22.06.2018 22:48+4300 серверов тоже надо поддерживать. Вы должны это учитывать так же при анализе. А так математика в целом простая. Что бы написать кастомную СУБД под задачу много людей не надо, достаточно человека 2-3. Кушать допустим они будут сумарно баксов 150 в час. 300 серверов предположим что кушать будут баксов 60 в час (предположим что у нас 300 штук каких m4.xlarge).
Предположим что разработка СУБД в целом займет месяц-два работы и потом затраты на поддержку оной будут составлять уже каких-нибудь $15/h (типа часов 16 часов в месяц например). Итого инвестиция окупится через каких-нибудь месяцев 6.
Возможно эта инвестиция сможет убавить издержки и на другие вещи, суппорт серверов, трафик, хранение логов. Возможно специализированное решение позволит существенно снизить задержки, что позитивно скажется на общем UX приложения и пользователи будут более лояльны. Ну то есть масса вещей есть.
Понятно что если вы просто вася пупкин — не надо вам делать свои СУБД. Разве что как хобби.
p.s. я все ж подозреваю что кушать эти разработчики будут чуть меньше.JekaMas
22.06.2018 23:37Можем предложить, что серваки стоят в нашем ДЦ, и кушают 5$ час, а разработчики выкатили mvp за два месяца, а потом сказали, что надо допиливать еще года два и команда нужна человек 6-10, которую надо хантить на особые условия, ибо БД не каждый сделает.
Тогда цифры другие.
Не думаю, что оно продуктивно, представлять сферических коней.
Клево было бы услышать экономическое обоснование от разработчиков. Ну или действительно дело с "фатальным недостатком".
youROCK
23.06.2018 01:02Здесь стоит учесть, что сервера обычно помощнее, чем m4.xlarge, я бы считал, что на каждом хотя бы по 16 логических CPU (8 физических ядер), а то и больше. Плюс разработчик каждого движка обычно только один и кушает он только в рабочее время, и все-таки немного поменьше :).
Грубо говоря, даже если мы считаем цены амазона завышенными вдвое, то выходит 300$ в час против не более 25$ в час одного разраба (сервера на ночь не выключаем, потому что это сервера с данными). Такое окупится даже если разработка займет 300/25=12 месяцев.Fesor
23.06.2018 18:23кушает он только в рабочее время
Я и считал 160 часов в месяц.
и все-таки немного поменьше
Суть была не в том что бы конкретные цифры обсудить, а в простом соотношении и времени окупаемости. cost/benifit анализ. Подставляя свои цифры мы можем прикинуть что и как.
Например Вася пупкин начитался статей о том как люди делают всякие кафки, касандры и прочие кликхаусы, и подумал "а чем я хуже, я ж тоже могу!". И введение кастомного решения у него затратит его времени на $10K а сэкономит он $100 в месяц, окупаемость ~10 лет. Вместо этого инвестировать время можно в другие вещи.
А вот если вы фэйсбук со своими датацентрами, и у вас все на php, то выгодно нанять команду высококвалифицированных C/C++ разработчиков что бы они вам на LLVM JIT компилируемый язык нарисовали, который позволит вам в 2-3 раза уменьшить нагрузки на железо (вот ту миллионы) +, поскольку у вас контроль за языком — позволят ввести новые фичи в язык, которые существенно упростят тот же статический анализ (array shapes, type aliases).
Ну то есть помимо очевидного бенифита в виде сокращения издержек на сервера, мы имеем косвенные бенифиты.
ну и да, реально довольно часто хочется что-то маленькое, специализированное и скучно. А потом уже под это дело можно и бенифиты придумать.
Вспомните такое приложение как маскарад. Там внутри очень даже кастомное решение которое пилилось насколько я помню больше года явно, как хобби. А потом хакатончик, чуть допилить и вот вас уже покупает фэйсбук.
ALexhha
23.06.2018 23:54За 2 месяца разработать субд?! Я конечно все понимаю, но как то очень оптимистично. А тестирование? А затраты на внедрение? И это ещё не факт что вообще взлетит. А если не взлетит, то какие будут затраты на возврат к старой субд? Да и поддержка у вас выглядит очень оптимистично. Разве что они наняли гениев, которые за два месяца написали весь функционал. Как по мне то это очень сложные вопросы
Fesor
24.06.2018 00:33Я конечно все понимаю, но как то очень оптимистично.
специализированная СУБД, под конкретную задачу. Это не база данных общего назначения. Потому да, не вижу ничего страшного в 2-х месяцах.
А тестирование? А затраты на внедрение?
Вы можете внедрять новую систему планомерно, получая профит постепенно и тестируя в реальных условиях. Это существенно упрощает вопрос.
И это ещё не факт что вообще взлетит.
обычно перед тем как решаться на такое уже должен быть некий proof of concept который доказывает эффективность решения.
Разве что они наняли гениев, которые за два месяца написали весь функционал.
Решение после обкатки было выложено в опенсурс как раз что бы уменьшить и эти издержки (хотя сам факт выкатки в опенсурс это тоже дорогое удовольствие).
Как по мне то это очень сложные вопросы
суть вопроса проста — вы должны оценить риски, затраты и профит. Можно проиграть, можно выйграть. Конечно ответы на эти вопросы — это сложно. Но это не настолько сложные вопросы с учетом масштабов.
И да, я забыл рассказать еще об одном аспекте таких решений. Предположим что ваша компания может себе позволить такое удовольствие как написать свою СУБД. Помимо решения каких-то внутренних проблем, это вам даст еще возможность отправлять людей на конференции и повышать престиж компании среди разработчиков. А это в свою очередь будет создавать конкуренцию за рабочее место. И если вам позвонят из компании и скажут "а не хотите ли вы придти на собес" то большинство ответят "конечно хочу".
У многих компаний существует такая практика. Найм людей тоже штука дорогая.
altrus
24.06.2018 07:07специализированная СУБД, под конкретную задачу.
Людей смущает громкая аббревиатура СУБД, как я понимаю. С тем же успехом можно было назвать это оптимизированным мемкэшем, с прозрачной записью на диск, так?
Fesor
24.06.2018 00:45+1но вообще — просто поресерчите истории популярных опенсурс продуктов. Подавляющее большинство рождались в недрах каких-то компаний.
Возьмите тот же angular — его пилили в гугле как хобби. А сегодня это один из самых популярных фреймворков. Или react — его так же пилили в facebook годами перед тем как зарелизить. Тот же graphql это так же был внутренний проект.
nginx — писался под рамблер, и стал популярным решением так же далеко не сразу и был намного проще в начале своего пути. Кафка так же пилится с 11-ого года, но из всех щелей она лезет только последние год-два.
ClickHouse так же пилится с 2009-ого года, и на тот момент когда начинали пилить только только появились сырые хадупы и касандры. Потому на тот момент рисков явно было меньше а профита явно было больше.
Fesor
22.06.2018 22:54Ну и да, в некоторых ситуациях смена модели данных и разработка эффективного стораджа под эту модель единственный способ вписаться в нефункциональные требования. Благо обычно хватает существующих моделей (документы, графы, колонки)
nefone
22.06.2018 16:38перехал из Петербурга в Подмосковье и теперь только и мечтаю вернуться обратно.
А есть еще где почитать про структуру VK?youROCK
22.06.2018 17:44+1Почитать — на хабре: habr.com/company/vkontakte
Ещё можно посмотреть доклады (в т.ч. с хайлоада) на YouTube, например www.youtube.com/watch?v=P4HkWuVtsdA
zvermafia
22.06.2018 18:01В принципе, ощутимая часть инфраструктуры VK была выложена Павлом Дуровым в open source вместе с документацией.
Можно ссылку?youROCK
22.06.2018 18:37Gemorroj
22.06.2018 19:46+1но это выглядит как заброшенный проект
alexkrash
23.06.2018 02:014 года, может ещё очухается, раз про него рассказывают
AterCattus
23.06.2018 02:35Это скорее как «слепок» на тот момент, который приведен скорее для желающих ознакомиться.
С тех пор развитие убежало далеко вперед, но пока, увы, не до планов по актуализации и поддержанию публичной версии.
DmitrySpb79
23.06.2018 12:54-1Простите за тупой вопрос, а VK вообще сейчас развивается?
Заходил как-то на странички знакомых, последние апдейты у многих 5-летней давности, такое ощущение что надоело всем. С Одноклассниками аналогично, когда-то был бум интереса, потом затихло все.
Сам тоже давно не пользуюсь.youROCK
23.06.2018 15:20vk.com/page-47200925_44240810
Вроде бы вполне нормально себя чувствует :).altrus
23.06.2018 15:44А чего на апреле 2017 года остановились?
По SimilarWeb уже на 8 месте в мире по посещаемости, а не на 5.
DmitrySpb79
23.06.2018 16:07Спасибо. Интересно, с чем связан такой волнообразный график, сезон отпусков что ли? (или школьных каникул?;)
immaculate
По-моему, разница с Подмосковьем незначительная. Мне больше в СПб не нравились более пасмурная погода и частые дожди, если говорить о климате.
Alozar
Нужно учитывать, что в Питере очень влажный климат и соответственно мороз воспринимается гораздо острее, как собственно и жара.
nafgne
Так ли это?
Есть мнение, что зимой относительная влажность на улице близка к 100%, так что при равных температурах содержание водяного пара в воздухе будет одинаково.
Alozar
Могу сказать по себе, что находясь в Северной осетии с +37 в тени, я не потел вообще, а только чувствовал тепло на коже, при этом в Таганроге при +30 я уже сильно потел, т.к. дикая влажность из-за моря.
И отец мне рассказывал, что во время службы в забайкалье он спокойно переносил гораздо более сильные морозы по сравнению с центральной частью России, т.к. воздух был сухой.
Captcha
Был как-то в спб в декабре. По термометру было где-то 0-+2 градуса, я ходил в термобелье и ватных штанах, и все равно через полчаса прогулки становилось капец как холодно.
youROCK
Да, только в Питере еще и любит дуть холодный ветер :). В сочетании с высокой влажностью и температурой до -25 это с непривычки переносится очень тяжело.
bro-dev0
И благодаря той же влажности, погода меняется плавно, в отличии от внутриконтинентального климата, так что сильной жары или мороза почти нету.