архітектура Вконтакте
- Статистика
- архітектура
- Чарівна база даних на C
- Аудіо та відео
- XMPP
- Інтеграція з зовнішніми ресурсами
- Цікаві факти не по темі
- підводимо підсумки
Найпопулярніша соціальна мережа в рунеті пролила трохи світла на те, як же вона працює. Представники проекту в особі Павла Дурова і Олега Ілларіонова на конференції 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 .