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 .