• Главная
  • Карта сайта
Не найдено

архітектура Вконтакте

  1. Статистика
  2. архітектура
  3. Чарівна база даних на C
  4. Аудіо та відео
  5. XMPP
  6. Інтеграція з зовнішніми ресурсами
  7. Цікаві факти не по темі
  8. підводимо підсумки

Найпопулярніша соціальна мережа в рунеті пролила трохи світла на те, як же вона працює Найпопулярніша соціальна мережа в рунеті пролила трохи світла на те, як же вона працює. Представники проекту в особі Павла Дурова і Олега Ілларіонова на конференції HighLoad ++ відповіли на шквал запитань з абсолютно різних аспектів роботи Вконтакте , В тому числі і технічним. Поспішаю поділитися своїм поглядом на архітектуру проекту за результатами даного виступу.

  • Debian Linux - основна операційна система
  • nginx - балансування навантаження
  • PHP + XCache
  • Apache + mod_php
  • memcached
  • MySQL
  • Власна СУБД на C , Створена "кращими умами" Росії
  • node.js - прошарок для реалізації XMPP, живе за HAProxy
  • Зображення віддаються просто з файлової системи xfs
  • ffmpeg - конвертація відео

Статистика

  • 95 мільйонів облікових записів
  • 40 мільйонів активних користувачів у всьому світі (порівнянно з аудиторією Інтернету в Росії)
  • 11 мільярдів запитів в день
  • 200 мільйонів особистих повідомлень в день
  • Відеопотік досягає 160Гбіт / с
  • Більше 10 тисяч серверів, з яких тільки 32 - фронтенда на nginx (Кількість серверів з Apache невідомо)
  • 30-40 розробників, 2 дизайнера, 5 системних адміністраторів, багато людей в датацентрах
  • Кожен день виходить з ладу близько 10 жорстких дисків

архітектура

Загальні принципи

  • Cервера багатофункціональні і використовуються одночасно в кількох ролях:
    • перекидання напівавтоматичне
    • Потрібно перезапускати daemon'и
  • Генерація сторінок з новинами (мікроблоги) відбувається дуже схожим чином з Facebook (Див. архітектура Facebook ), Основна відмінність - використання власної СУБД замість MySQL
  • При балансуванні навантаження використовуються:
    • Зважений round robin всередині системи
    • Різні сервера для різних типів запитів
    • Балансування на рівні ДНС на 32 IP-адреси
  • Велика частина внутрішнього софта написано самостійно, в тому числі:
    • Власна СУБД (див. Нижче)
    • Моніторинг з повідомленням по СМС (Павло сам допомагав верстати інтерфейс :))
    • Автоматична система тестування коду
    • Аналізатори статистики і логів
  • Потужні сервера:
    • 8-ядерні процесори Intel (по два на сервер, мабуть)
    • 64Гб оперативної пам'яті
    • 8 жорстких дисків (відповідно швидше за все корпусу 2-3U)
    • RAID не використовується
    • Чи не брендовані
  • Обчислювальні потужності серверів використовуються менш, ніж на 20%
  • Зараз проект розташований в 4 датацентрах в Санкт-Петербурзі і Москві, причому:
    • Вся основна база даних розташовується в одному датацентрі в Санкт-Петербурзі
    • У Московських датацентрах тільки аудіо і відео
    • У планах зробити реплікацію бази даних в інший датацентр в ленінградській області
  • CDN на даний момент не використовується, але в планах є
  • Резервне копіювання даних відбувається щодня і Інкрементальний

Чарівна база даних на C

Цьому продукту, мабуть, приділялася максимум уваги аудиторії, але при цьому майже ніяких подробиць про те, що він власне кажучи собою являє, так і не було оприлюднено. Відомо що:

  • Розроблено "кращими умами" Росії, переможцями олімпіад і конкурсів топкодер; озвучили навіть імена цих "героїв" Вконтакте (писав на слух і можливо не всіх встиг, так що вибачайте):
    • Андрій Лопатин
    • Микола Дуров
    • Арсеній Смирнов
    • Олексій Левін
  • Використовується у величезній кількості сервісів:
    • Особисті повідомлення
    • Повідомлення на стінах
    • Статуси
    • Пошук
    • Конфіденційність
    • списки друзів
  • Нереляційних модель даних
  • Більшість операцій здійснюється в оперативній пам'яті
  • Інтерфейс доступу являє собою розширений протокол memcached , Спеціальним чином складені ключі повертають результати складних запитів (найчастіше специфічних для конкретного сервісу)
  • Хотіли б зробити з даної системи універсальну СУБД і опублікувати під GPL, але поки не виходить через високий ступінь інтеграції з іншими сервісами
  • Кластеризація здійснюється легко
  • є реплікація
  • Якщо чесно, я так і не зрозумів навіщо їм MySQL з такою штукою - можливо просто як legacy живе зі старих часів

Аудіо та відео

Ці підпроекти є побічними для соціальної мережі, на них особливо не фокусуються. В основному це пов'язано з тим, що вони рідко корелюють з основною метою використання соціальної мережі - спілкуванням, а також створюють велику кількість проблем: відео трафік - основна стаття витрат проекту, плюс всім відомі проблеми з нелегальним контентом і претензіями правовласників. Медіа-файли банятся по хешу при видаленні на прохання правовласників, але це неефективно і планується удосконалити цей механізм.

1000-1500 серверів використовується для перекодування відео, на них же воно і зберігається.

XMPP

Як відомо, деякий час назад з'явилася можливість спілкуватися на Вконтакте через протокол Jabber (він же XMPP). Протокол абсолютно відкритий і існує маса opensource реалізацій.

По ряду причин, серед яких проблеми з інтеграцією з іншими сервісами, було вирішено за місяць створити власний сервер, який представляє собою прошарок між внутрішніми сервісами Вконтакте і реалізацією XMPP протоколу. Основні особливості цього сервісу:

  • реалізовано на node.js (Вибір обумовлений тим, що JavaScript знають практично всі розробники проекту, а також хороший набір інструментів для реалізації завдання)
  • Робота з великими контакт-листами - у багатьох користувачів кількість друзів на Вконтакте вимірюється сотнями і тисячами
  • Висока активність зміни статусів - люди з'являються і зникають з онлайну частіше, ніж в інших аналогічних ситуаціях
  • Авторка передаються в base64
  • Тісна інтеграція з внутрішньою системою обміну особистими повідомленнями Вконтакте
  • 60-80 тисяч чоловік онлайн, в піку - 150 тисяч
  • HAProxy обробляє вхідні з'єднання і використовується для балансування навантаження і розгортання нових версій
  • Дані зберігаються в MySQL (Думали про MongoDB, але передумали)
  • Сервіс працює на 5 серверах різної конфігурації, на кожному з них працює код на node.js (По 4 процесу на сервер), а на трьох найпотужніших - ще й MySQL
  • В node.js великі проблеми з використанням OpenSSL , А також тече пам'ять
  • Групи друзів в XMPP не пов'язані з групами друзів на сайті - зроблено на прохання користувачів, які не хотіли щоб їх друзі з-за плеча бачили в якої групи вони знаходяться

Інтеграція з зовнішніми ресурсами

Під Вконтакте вважають даний напрямок дуже перспективним і здійснюють масу пов'язаної з цим роботи. Основні зроблені кроки:

  • Максимальна кроссбраузерность для віджетів на основі бібліотек easyXDM і fastXDM
  • Крос-постинг статусів в Twitter , Реалізований за допомогою черг запитів
  • Кнопка "поділитися з друзями", що підтримує openGraph теги і автоматично підбирає підходящу ілюстрацію (шляхом порівнювання умістів тега <title> і атрибутів alt у зображень, мало не побуквенно)
  • Можливість завантаження відео через сторонні відео-хостинги (YouTube, RuTube, Vimeo, і.т.д.), відкриті до інтеграції з іншими

Цікаві факти не по темі

  • Процес розробки близький до Agile, з тижневими ітераціями
  • Ядро операційної системи модифікований (на предмет роботи з пам'яттю), є своя пакетна база для Debian
  • Фотографії завантажуються на два жорсткі диски одного сервера одночасно, після чого створюється резервна копія на іншому сервері
  • Є багато доробок над memcached , в т.ч. для більш стабільного і тривалого розміщення об'єктів в пам'яті; є навіть persistent версія
  • Фото які не видаляються для мінімізації фрагментації
  • Рішення про розвиток проекту беруть Павло Дуров і Андрій Рогозів, відповідальність за сервіси - на них і на реалізовувало його розробника
  • Павло Дуров відкладав гроші на хостинг з 1 курсу :)

підводимо підсумки

В цілому Вконтакте розвивається у бік збільшення швидкості поширення інформацію всередині мережі. Пріоритети помінялися в цьому напрямку досить недавно, цим обумовлено, наприклад, перенесення виходу поштового сервісу Вконтакте, про який дуже активно говорили коли з'явилася можливість забивати собі текстові URL начебто vkontakte.ru/ivan.blinkov. Зараз цей підпроект має низький пріоритет і чекає свого часу, коли вони зможуть запропонувати щось більш зручне і швидке, ніж Gmail.

Завіса таємниці щодо технічної реалізації Вконтакте була трохи розвіяна, але багато моментів все ж залишилися секретом. Можливо в майбутньому з'явиться більш детальна інформація про власну СУБД Вконтакте, яка як виявилося є ключем до вирішення всіх найскладніших моментів у масштабованості системи.

Як я вже згадував цей пост написаний майже на пам'ять, на основі невеликого конспекту "круглого столу Вконтакте", так що хочеться відразу вибачитися за можливі неточності і непорозумінь. Я лише структурував хаотичну купу відповідей на питання. Буду радий уточненням і доповненням.

Якщо хочете бути в курсі нових віянь у сфері масштабованості високонавантажених інтернет-проектів - за традицією рекомендую підписатися на RSS .

Новости
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью