Skip to content

Latest commit

 

History

History
169 lines (108 loc) · 8.42 KB

2.1-vk-architecture.md

File metadata and controls

169 lines (108 loc) · 8.42 KB

FAQ по архитектуре и работе ВКонтакте

Алексей Акулович, ВКонтакте

Содержание

Архитектура

  • фронты: независимые сервера с 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