Архитектура серверов и баз данных ВКонтакте

6 декабря прошёл первый митап VK Tech Talks | Backend, на котором разработчик Алексей Акулович выступил с докладом об архитектуре серверов и баз данных ВКонтакте.

Алексей работает в команде «ВКонтакте» уже более четырёх лет, и за это время он успел принять участие во множестве проектов, которые так или иначе связаны с мультимедиа и backend.

Общая архитектура

Обработка запросов начинается с фронтов, которые принимают запрос непосредственно от пользователя. Фронт-запросы делятся на три типа, которые представлены ниже на фотографии.

Общая реализация фронтов:

В случае HTTPS-трафика и WSS-соединений на фронтах стоит nginx, с которых принимается запись соединения, а для RTMP был осуществлен переезд на kive — собственный сервер трансляции. Отказоустойчивость машин организована через анонсированные одинаковые IP-адреса для нескольких машин, поэтому при отказе одной из машины не теряются запросы. Для HTTPS-соединений и WSS фронты занимаются дешифровкой потока данных, снимая нагрузку с машин.

За фронтами стоят бекенды — http-сервера на kPHP, которые обрабатывают полученные запросы. Таких серверов у «ВКонтакте» тысячи.

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

Общая структура распределения нагрузки представлена на фотографии ниже:

Следующий тип серверов, которые имеются в большом количестве — это cs-сервера. CS — это контент-сервер. Их основная задача заключается в хранении файлов, но они также занимаются обработкой данных.

Эти сервера зачастую закрываются pu/pp-серверами. PU/PP-сервера нужны для скачивания файлов.

Зачем и как это работает?

Для некоторых видов файлов, например, тяжёлых видеозаписей, происходит подача напрямую на cs-сервера.

Помимо pu/pp-серверов существуют sun-сервера, которые являются более эффективными.

Идея при реализации sun:

Организация sun-серверов:

На фотографии ниже представлено расположение cache-серверов, на которых осуществляется хранение мультимедийных файлов:

Чтобы понимать, с какого cache-сервера отдать файл, нужно как-то определять регион пользователя:

Как работают cache-сервера?

В целом получается сближение контента и пользователей, при этим снимается огромная сетевая нагрузка.

Схема общей архитектуры серверов:

Базы данных

Почему не базы данных, а движки? — Потому что это не базы данных, а самописные решения, которые создаются «под себя».

Коротко пробежимся по архитектуре:

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

Как это работает?

Очень важно, что rcp-proxy работают локально на тех же машинах, на которых запущен код.

Персистентное хранение данных:

Репликация данных на движках:

Шардирование данных в rpc-proxy:

Логи и мониторинг

Самый популярный способ собрать логи — это записать их с memcache.
Другой вариант для долгосрочного хранения логов — это движок logs-engine, который много где используется. Самый большой кластер этого движка хранит примерно 600 ТБ запакованных binlogs. Но этот движок довольно старый и имеет некоторые ограничения, которые по-разному исправляются. Одно из решений — это использование ClickHouse.

Сбор логов в ClickHouse:

Мониторинг на основе ClickHouse:

Есть две метрики: системные (админские) и продуктовые (разработческие).
Системные (админские) метрики:

Продуктовые (разработческие) метрики:

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

Схема сбора хранения продуктовых метрик:

Метрики на ClickHouse:

Подробнее про ClickHouse можно узнать из статьи на «Хабре».

Ссылки

1. Разработка в надёжной нагруженной среде: 2018.codefest.ru/lecture/1250
2. Как VK вставляет данные в ClickHouse с десятков тысяч серверов: highload.ru/2018/abstracts/4066
3. Как переписать с нуля базу данных личных сообщений ВКонтакте и мигрировать на неё без даунтайма: highload.ru/2017/abstracts/3088
4. Системный администратор Vkontakte. Как? highload.ru/2016/abstracts/2416

Посмотреть полную версию доклада можно в трансляции:

Автор: Сергей Котов
Корректор: Арсений Метелев