Архитектура

• фронты: независимые сервера с nginx, анонсируют общие IP,терминируют HTTPS/WSS.
• бэкенды: http сервера на kPHP, модель работы prefork, вместо перезапуска сбрасывают состояние (global/static vars).

Для распределения нагрузки:

* Бэкенды группируются: general, mobile, api и т.п. Выбирает между ними nginx на фронте.

* Сбор метрик и перебалансировка.

• Content server (cs). Хранят и обрабатывают файлы.

• Часть cs закрыты специальными pu/pp серверами (photo upload / photo proxy). Зачем они нужны?

  • для терминирования HTTPS
  • чтобы использовать серые IP-адреса для cs
  • для отказоустойчивости через общие IP
  • спорно — чтобы клиент держал меньше соединений

  Обычно видео гоняется напрямую, а более лёгкий контент — через прокси.

• sun — новая альтернатива pp. Зачем:

  • у pp один IP на группу, в результате один файл оседает во всех кешах
  • pp нельзя шардировать и ставить в регионах

Как устроены sun:

* маршрутизация anycast
* кеширование
* поддержка весов
* можно ставить в регионах
* шардирование по id контента (например, когда 100000 человек запрашивают аватарку одного пользователя)

• cache — региональные кеши. Регион определяем так:

  1. сбор сетей региона по BGP
  2. инфа загружается в базу, + geoip
  3. по IP пользователя определяем регион

• engines — базы данных

Базы данных

Называем engines, потому что это не совсем базы данных.

В 2008-2009 использовали MySQL и Memcached, но они не выдержали взрывного роста пользователей. Заменили их на велосипеды.

Типов движков очень много. На каждую задачу — новый тип движка. Очереди, списки, сеты — всё что угодно.

Движки одного типа объединяются в кластеры. Код не знает расположения и размера кластеров. Для этого между серверами и базами есть ещё rpc-proxy:

• общая шина
• service discovery, forwarding
• circuit breaker

На каждом сервере есть локальный rpc-proxy, который знает, куда направить запросы и где находятся engines.

Если один engine идёт в другой, то тоже делает это через прокси. Engine не должен знать ничего, кроме себя.

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

• движки пишут бинлоги: binary log (WAL, AOF). Пишутся в одинаковом бинарном формате (TL scheme), чтобы админы их читали своими инструментами.
• снапшоты: слепок данных + offset в бинлоге. Общее начало, тело произвольное.

При перезапуске движок сначала читает снапшот, восстанавливает из него своё состояние. Потом из него находит offset, по нему дочитывает остаток из бинлога, восстанавливает окончательное состояние.

Результат: репликация данных:

• statement-based
• инкрементальный унос «хвоста» бинлога

Эта же схема используется для создания бэкапов.

Логи

Как собираются?

• отправка в memcached. Там кольцевой буфер (ring-buffer: prefix.idx = line).
• отправка в logs-engine (разработан in-house)

Хранятся в ClickHouse. Чтобы это заработало, приходится локальный rpc-proxy заменить на KittenHouse, а на движке добавлять KittenHouse reverse proxy.

А ещё есть nginx, чтобы получать логи по UDP.

Мониторинг

Есть два типа метрик.

Системные и админские метрики:

• netdata собирает статистику,
• отсылает в Graphite Carbon
• ClickHouse
• можно смотреть через Grafana

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

• много метрик
• очень много событий — от 0,6 до 1 триллиона в сутки
• храним 2+ года

Эксперимент: собираем метрики на ClickHouse

• удобнее основной системы
• требует меньше серверов, но сами сервера жирнее

Деплой

Git, GitLab, TeamCity

PHP:

1. git pruduction branch
2. diff файла
3. записывается в binlog copyfast
4. реплицируется на сервера через gossip replication
5. применяется локальными репликами на локальной файловой системе

kPHP:

• большой бинарь, сотни МБ
• git master branch
• версию пишем в binlog copyfast
• реплицируем версию на сервера
• сервер вытягивает свежий бинарник через gossip replication
• graceful-перезапуск на новую версию

Движки:

• бинари в .deb
• git master branch
• версию пишем в binlog copyfast
• реплицируем версию на сервера
• сервер вытягивает свежий .deb
• dpkg -i
• graceful-перезапуск на новую версию

Другие доклады про архитектуру VK

• Системный администратор ВКонтакте. Как?
• Разработка в ненадёжной нагруженной среде
• Как VK вставляет данные в ClickHouse с десятков тысяч серверов: на Highload Siberia и на Highload Moscow
• Архитектура растущего проекта на примере ВКонтакте