что такое веб сайт вконтакте
Как создать сайт из сообщества ВКонтакте: пошаговый алгоритм
Создание сайта – трудоемкий и долгий процесс, который лучше доверить профессиональной команде: дизайнеру, верстальщику, копирайтеру, юзабилити-специалисту. Конечно, работа такой команды будет стоить денег, и чем масштабнее вы задумали сайт, тем дороже обойдется его разработка. Вопрос ценообразования в этом направлении мы подробно разбирали вот в этой статье.
Но бывают ситуации, когда бюджет не позволяет заложить большую сумму на создание сайта и работу профессиональной команды, да и ресурс требуется не слишком сложный. В этом случае вы можете попытаться сделать ресурс самостоятельно, воспользовавшись специальными конструкторами. Например, Тильдой.
Впрочем, даже с Тильдой придется повозиться, чтобы разобраться во всех ее возможностях и функционале. Для создания несложных сайтов есть еще более удобный вариант – конструктор от ВКонтакте. Суть инструмента проста: вы создаете ресурс на основе имеющегося сообщества ВК. Для использования этого конструктора не нужны специальные знания ни в верстке, ни в дизайне, ни в проектировании, соцсеть всё сделает за вас, ваша задача – максимально подробно оформить сообщество, но об этом дальше.
Конструктор ВКонтакте – инструмент новый, он появился в ноябре 2020 года и сегодня его продолжают активно дорабатываться командой соцсети, поэтому, думаю, функционал еще будет расширен. Но уже сейчас это отличная возможность сделать сайт буквально в пару кликов и к тому же бесплатно. В этой статье подробно расскажу, как и для чего может быть полезен сайт на основе сообщества ВК. 🙂
Как создать сайт из сообщества ВКонтакте: пошаговый алгоритм
Есть несколько условий, в соблюдении которых необходимо удостовериться, прежде чем приступать к работе:
Ну а дальше можем приступить к работе над сайтом.
Шаг 1. Подключите инструмент к работе
Для этого зайдите в свое сообщество. В меню задач в левой части экрана нажмите на кнопку «Сайт из сообщества»:
И еще раз подтвердите свои намерения:
Шаг 2. Оформите главный блок
Текст из названия сообщества и блока «Описание» подгрузится на сайт автоматически, но его можно изменить. В названии уместно отразить брендовое имя компании и, по желанию, основной тематический ключ. Описание по объему куда меньше, чем в сообществе, поэтому здесь пишем только самое основное. Пример:
Кроме того, необходимо подгрузить обложку. Это фоновая фотография, поверх которой будет размещено наше название и описание. Фотографию для обложки лучше выбрать не слишком пеструю, чтобы первый экран не выглядел аляповато, а текст хорошо читался. Если вы не выберете никакое изображение, конструктор автоматически поставит на фон градиент. Для тех, кто все-таки будет искать подходящее фото, рекомендую бесплатные фотостоки, собранные вот тут.
Вот пример отображения обложки на уже готовом сайте:
Следующий элемент главного блока – кнопка действия. Ее можно настроить, выбрав самый подходящий для вас вариант из предложенных: позвонить, перейти по ссылке, написать на почту и др. Формулировка целевого действия тоже может корректироваться. По умолчанию используется кнопка действия, настроенная в сообществе.
И, наконец, завершающий этап – преимущества. Специальная фишка, которая позволяет отразить в первом экране будущего сайта ключевые преимущества вашей компании, всего их может быть 5. Понятно, что здесь лучше говорить о чем-то конкретном и действительном полезном для целевой аудитории. Пример:
Обязательными являются только название и описание, все остальные элементы главного блока подключаются по желанию.
Шаг 2. Настраиваем каталог
Поскольку сайт у нас создается на основе информации, размещенной в сообществе, то и каталог его настраивается за счет товаров, добавленных в вашей группе или паблике.
Если вы все еще думаете, что товары ВК – это по-прежнему плохо проработанный малополезный функционал, спешу изменить ваше мнение и рекомендую прочитать вот эту статью. Если вкратце, товары ВК сегодня – это полноценный магазин с возможностью оформления заказа, оплаты и доставки, с простенькой CRM-системой и даже собственным маркетплейсом.
Так что добавляем необходимый ассортимент в сообщество, а дальше просто настраиваем его отображение на сайте:
Можно добавить вообще все товары, загруженные в сообщество, либо определенную подборку, дать каталогу любое уместное, на ваш взгляд, название. Если товары в сообщество добавлены, но на сайте вы их размещать пока не хотите, просто снимите соответствующую галочку.
На сайте товары отображаются в формате стандартных карточек, вся информация для них подгружается из ВК:
Для связи и заказа нужно связаться с компанией через ВКонтакте. Это не очень удобно, но у меня есть предположение, что в недалеком будущем все крутые фишки товаров в сообществе будут доступны для использования и на сайте.
Шаг 3. Пишем текст о компании
Вам хочется рассказать о себе много полезных вещей и описания на 140 символов в первом экране вам мало? Что ж, в таком случае имеет смысл подключить текстовый блок:
Готовя текст, вспоминаем все правила хорошего копирайтинга. Никакой воды, только польза, все по делу. Кстати, насчет оптимизации и тошноты можете особо не беспокоиться, сайты из сообщества пока что не слишком успешно индексируются поисковыми системами, поэтому гораздо важнее поработать над содержанием и в тексте ответить на все основные вопросы вашей целевой аудитории.
Шаг 4. Подключаем галерею
Для некоторых тематик бизнеса очень важна визуальная сторона вопроса. К примеру, когда невеста ищет свадебное платье, ее будет цеплять красивая картинка. На этот случай на сайте можно сделать галерею фотографий:
Фотографии для галереи подгружаются из фотоальбомов сообщества. Вам лишь нужно выбрать альбом, снимки из которого нужно показать на сайте.
Шаг 5. Подключаем отзывы
Обратная связь – двигатель торговли и главный маркер доверия. На сайт их можно вытащить через раздел «Обсуждения»:
Выбираем нужный топик, и все сообщения, оставленные ранее клиентами, появятся на сайте в виде карточек, которые можно листать и удобно изучать. Ответы от имени сообщества при этом показываться не будут.
Вот, собственно, и всё. Помимо перечисленного выше, на сайте отобразятся контакты компании: телефон, физический адрес, часы работы, карта, ссылки на другие соцсети. Разумеется, при условии, что всё это у вас уже настроено в сообществе.
Как анализировать работу сайта из сообщества
После того, как вы оформите все блоки и опубликуете сайт, в сообществе можно будет отслеживать его результаты его работы. Статистика доступна по нескольким разделам:
Как я уже отметила выше, сайты, сделанные на основе сообщества ВКонтакте, не особенно успешно индексируются Яндексом и Google, их невозможно технически оптимизировать, поэтому единственный вариант привлечения трафика на ваш новенький ресурс – это реклама, причем не только таргетированная, но и контекстная.
Кстати, с недавних пор на сайт из сообщества можно поставить пиксели соцсетей для запуска ретаргетинговых кампаний, а также подключить системы аналитики, Яндекс.Метрику и Google Analytics:
Для этого нужно просто указать код или ID счетчика или пикселя.
Заключение: кому и для чего нужен сайта из сообщества
Инструмент пока что совсем новый и потому сыроват. Во всяком случае, у меня сложилось такое ощущение после его тестирования. Однако факт остается фактом: это бесплатный конструктор, который позволяет создать пусть и простой, но всё же лендинг, не имея вообще никаких знаний в сфере разработки сайтов.
Пока готовила эту статью, нашла целых 3 варианта, кому и для чего может быть полезен сайт, сделанный из сообщества ВКонтакте.
Вариант 1: малый бизнес
Я бы даже сказала, микробизнес. Те небольшие компании, которым так сложно выделить бюджет на работу с полноценной CMS или каким-либо известным конструктором. Чтобы было понятнее, приведу пример. Предположим, у вас вполне успешный бизнес – офлайн-магазин спортивных товаров. Когда-то вы создали для него группу ВКонтакте и продолжаете ее продвигать, успели достичь неплохих результатов, нашли новую аудиторию. Хочется попробовать другие варианты интернет-продвижения, например, контекст и оценить их эффективность, но как это сделать без сайта? Очень легко, ведь сайт можно сделать на основе сообщества.
Вариант 2: дополнительное внимание к сообществу
Сайт пока что на каждом шагу отсылает нас к сообществу, а следовательно, он может стать инструментом к тому, чтобы привлечь к группе больше внимания и новую аудиторию. Создание сайта – это в какой-то степени инфоповод и возможность напомнить о своей компании на площадке соцсети.
Вариант 3: продвижение акции или мероприятия
Иногда лендинги создают временно, если нужно привлечь внимание к чему-то конкретному: новому продукту, текущей акции или планирующемуся мероприятию. Поскольку такой одностаничник не нужен на долгий срок, нет смысла вкладывать большие деньги в его разработку. Более того, можно самому слепить вполне приемлемый по виду сайт в конструкторе ВК буквально за пару часов. 🙂
Думаю, количество идей, как можно использовать сайты из сообществ, будет расти пропорционально росту функциональности конструктора. Обещаю вернуться к этой теме через год-полтора и обновить статью, осветив в ней все изменения, произошедшие с инструментом.
Завершаю свой рассказ и напоминаю, что конструктор, о котором шла речь, все-таки работает на основе сообщества, а значит первым шагом будет его создание либо доработка. С этим всегда можем помочь. Обращайтесь. 🙂
Как создать бесплатно сайт «ВКонтакте»?
Есть мнение, что будущее Интернета — это социальные сети! Поэтому когда мы решили создать бесплатный сайт, то самым простым решением будет регистрация такого сайта в соцсети «ВК». Попробуем разобраться с этим явлением.
Прежде, чем создавать свою страничку «Вконтакте» оценим ее особенности, а также плюсы и минусы по сравнению со standalone-сайтом.
Сначала о плюсах
Во-первых, аудитории очень удобно общаться ВКонтакте. Людям привычно это делать.
Большинство даже не хочет выходить за пределы социальной сети или вообще считает, что Интернет это ВКонтакте.
Поэтому, активность там зашкаливает по сравнению с обычным веб пространством. Там удобно и привычно предлагать свои записи в сообщества и вообще делать все операции с любым типом контента.
Есть даже специальные биржи рекламы для сообществ.
Во-вторых, для создания своих страниц не требуется специальных знаний. Нужно только продумать цель создания группы, а затем управлять ее наполнением и актуализацией.
Добавим к этому возможность вступления в группы без прохождения процедур регистрации, а также отсутствие спама.
Очевидно, что для любителей бесплатных сайтов создание страницы ВКонтакте – идеальный вариант.
Отдачу от затраченного времени на страницу ВКонтакте видно почти сразу, не так как при обычной поисковой оптимизации. Собирать и удерживать аудиторию значительно легче, она более лояльна. Есть много успешных примеров вывода страницы в социальной сети на первые места по ключевым запросам в выдаче Яндекса и Google.
Возникает резонный вопрос, а нужен ли в дополнение к ней классический сайт?
Чем ответит standalone-сайт?
Конечно, дизайном и теоретически неограниченным расширением функционала.
Чем еще он хорош? Возможностью выбора. Свой сайт мы можем наполнить, как хотим.
Мы можем разработать дизайн, раскрутить, а можем попасть под санкции поисковых систем — все в наших руках.
А в автоматически генерируемых страничках этого нет. Нет свободы. Нет ощущения собственности.
Кроме этого, страничку ВКонтакте мы можем потерять в любой момент по мотивам, которые понятны руководству социально сети. В этом вся разница.
Поэтому, для коммерческих проектов обязательно нужно создавать собственный сайт.
Пусть он будет небольшим и чисто информативным. Это может быть простейший сайт-визитка, но он должен быть!
Тем, кто раскрутит свою страницу или группу в контакте будет проще продвигать standalone-сайт. Итак, настало время социальных сетей!
Подготовка — создание личной страницы
Прежде чем создавать группу в ВКонтакте, убедитесь, что у вас есть личная страница в этой социальной сети. Если вы не хотите, чтобы группа была привязана к вашей странице, где вы публикуете личную информацию, выкладываете фотографии и пишете посты, необходимо обзавестись второй личной страницей. В этом случае вам необходимо наличие номера телефона, который еще не был зарегистрирован в ВКонтакте.
Только у создателя группы в ВКонтакте будут максимальные права, а также возможность удаления группы.
Создаем «сайт» ВКонтакте
Для этого нажмем на пункт «мои группы» в левом меню. Далее выбираем «создать сообщество».
В появившемся окне записываем название нашего сайта, выбираем «публичная страница» и жмём на кнопку «создать сообщество».
В появившемся окне ставим пунсон в чек-боксе строки «Компания, организация или веб-сайт», подтверждаем свой статус официального представителя компании, создающей сайт и соглашаемся с правилами пользования сайтом. Затем нажимаем «Создать страницу».
В появившемся окне выбираем сферу деятельности организации на сайте, приводим краткое и возможно емкое описание того, о чем будет рассказывать наш сайт.
После этого мы можем указать адрес standalone-сайта представляемой организации, дату основания веб-сайта (она может быть выбрана по Вашему желанию и не совпадать с текущей датой).
Далее идут настройки содержимого веб-сайта. Эти настройки мы сможем поменять в любое время, если будет желание.
Далее для более корректной работы вашей страницы советуем перевести ее в формат группы, так как после создания по умолчанию ваша страница создается в формате паблика.
Мы предлагаем сделать выбор в пользу группы, так как она больше рассчитана на взаимодействие участников и администраторов. В то время как паблик делает ставку на контент, а также вызывает трудности при заполнении некоторых разделов, таких как «Меню» и «Адреса», которые важны для ведения бизнеса в ВКонтакте.
Описание
Наибольших энергозатрат требует заполнение раздела «Описание». В данном блоке вы должны рассказать о вашей компании с соблюдением следующих правил:
Описание отличный блок, где можно раскрыть ваше УТП и другие преимущества перед конкурентами. В конце описания в специальных блоках вы сможете оставить контактную информацию: адрес, телефон, сайт, режим работы. Не забывайте структурировать ваш текст: делите его на абзацы, формируйте маркированные списки, чтобы текст лучше воспринимался. Описание не стоит делать слишком длинным достаточно будет 1000-1200 знаков. 
Дизайн группы
Лицо группы — ее оформление. Далее мы прорабатываем обложку и аватар. Создавать их лучше в едином стиле, делая ставку на красочность, информативность и индивидуальность.
Примерные размеры: обложка 1590×400, аватар 400×693.
Обложка — верхнее большое поле. Аватар — небольшой значок, в качестве которого зачастую используется логотип компании.
На обложке желательно прописать название вашей компании, краткое описание деятельности, основные преимущества и контакты. Информацию предпочтительно разместить посередине обложки, чтобы все считывалось с экранов мобильных телефонов и не обрезалось.
Теперь осталось загрузить изображение веб-сайта. Для этого подготовим картинку квадратного формата, желательно размером в 50 пикселей для каждой стороны.
После этого нажимаем на надпись «Загрузить фотографию», затем на кнопку «Выбрать файл», потом «Сохранить и продолжить», «Сохранить изменения».
Ура! Первый этап создания нашего веб-сайта закончен!
Для получения обратной связи подойдут «Обсуждения». Подключив этот раздел, вы сможете сформировать темы, на которые вам хотелось бы получать комментарии пользователей, оперативно обрабатывать вопросы.
Стандартно вы можете создать обсуждения: «Задайте нам вопрос», «Отзывы», также можете дать важную для пользователей информацию.
Теперь нам нужно будет наполнить его интересными материалами или, как говорят веб-мастера, «контентом» и привлечь внимание сообщества социальной сети.
Для закрепления полученных знаний рекомендуем посмотреть видео инструкцию от наших коллег.
FAQ по архитектуре и работе ВКонтакте
История создания ВКонтакте есть в Википедии, её рассказывал сам Павел. Кажется, что ее знают уже все. Про внутренности, архитектуру и устройство сайта на HighLoad++ Павел рассказывал еще в 2010 году. Много серверов утекло с тех пор, поэтому мы обновим информацию: препарируем, вытащим внутренности, взвесим — посмотрим на устройство ВК с технической точки зрения.
Алексей Акулович (AterCattus) бэкенд-разработчик в команде ВКонтакте. Расшифровка этого доклада — собирательный ответ на часто задаваемые вопросы про работу платформы, инфраструктуры, серверов и взаимодействия между ними, но не про разработку, а именно про железо. Отдельно — про базы данных и то, что вместо них у ВК, про сбор логов и мониторинг всего проекта в целом. Подробности под катом.
Больше четырех лет я занимаюсь всевозможными задачами, связанными с бэкендом.
Общая архитектура
Все, как обычно, начинается с сервера или группы серверов, которые принимают запросы.
Front-сервер
Front-сервер принимает запросы по HTTPS, RTMP и WSS.
HTTPS — это запросы для основной и мобильной веб-версий сайта: vk.com и m.vk.com, и другие официальные и неофициальные клиенты нашего API: мобильные клиенты, мэссенджеры. У нас есть прием RTMP-трафика для Live-трансляций с отдельными front-серверами и WSS-соединения для Streaming API.
Для HTTPS и WSS на серверах стоит nginx. Для RTMP трансляций мы недавно перешли на собственное решение kive, но оно за пределами доклада. Эти серверы для отказоустойчивости анонсируют общие IP-адреса и выступают группами, чтобы в случае проблемы на одном из серверов, запросы пользователей не терялись. Для HTTPS и WSS эти же серверы занимаются шифровкой трафика, чтобы забирать часть нагрузки по CPU на себя.
Дальше не будем говорить про WSS и RTMP, а только про стандартные запросы HTTPS, которые обычно ассоциируются с веб-проектом.
Backend
За front обычно стоят backend-серверы. Они обрабатывают запросы, которые получает front-сервер от клиентов.
Это kPHP-серверы, на которых работает HTTP-демон, потому что HTTPS уже расшифрован. kPHP — это сервер, который работает по prefork-модели: запускает мастер-процесс, пачку дочерних процессов, передает им слушающие сокеты и они обрабатывают свои запросы. При этом процессы не перезапускаются между каждым запросом от пользователя, а просто сбрасывают свое состояние в первоначальное zero-value состояние — запрос за запросом, вместо перезапуска.
Распределение нагрузки
Все наши бэкенды — это не огромный пул машин, которые могут обработать любой запрос. Мы их разделяем на отдельные группы: general, mobile, api, video, staging… Проблема на отдельной группе машин, не повлияет на все остальные. В случае проблем с видео пользователь, который слушает музыку, даже не узнает о проблемах. На какой backend отправить запрос, решает nginx на front’е по конфигу.
Сбор метрик и перебалансировка
Чтобы понять, сколько машин нужно иметь в каждой группе, мы не опираемся на QPS. Бэкенды разные, у них разные запросы, у каждого запроса разная сложность вычисления QPS. Поэтому мы оперируем понятием нагрузки на сервер в целом — на CPU и perf.
Таких серверов у нас тысячи. На каждом физическом сервере запущена группа kPHP, чтобы утилизировать все ядра (потому что kPHP однопоточные).
Content Server
CS или Content Server — это хранилище. CS — это сервер, который хранит файлы, а также обрабатывает залитые файлы, всевозможные фоновые синхронные задачи, которые ему ставит основной веб-фронтенд.
У нас десятки тысяч физических серверов, которые хранят файлы. Пользователи любят загружать файлы, а мы любим их хранить и раздавать. Часть этих серверов закрыты специальными pu/pp серверами.
Если вы открывали в VK вкладку network, то видели pu/pp.
Pu — это исторически сложившееся название для photo upload, а pp — это photo proxy. То есть один сервер, чтобы загружать фото, а другой — отдавать. Теперь загружаются уже не только фотографии, но название сохранилось.
Эти серверы терминируют HTTPS-сессии, чтобы снять процессорную нагрузку с хранилища. Также, так как на этих серверах обрабатываются пользовательские файлы, то чем меньше чувствительной информации хранится на этих машинах, тем лучше. Например, ключи от шифрования HTTPS.
Так как машины закрыты другими нашими машинами, то мы можем позволить себе не давать им «белые» внешние IP, и даем «серые». Так сэкономили на пуле IP и гарантированно защитили машины от доступа извне — просто нет IP, чтобы на неё попасть.
Отказоустойчивость через общие IP. В плане отказоустойчивости схема работает так же — несколько физических серверов имеют общий физический IP, и железка перед ними выбирает, куда отправить запрос. Позже я расскажу о других вариантах.
Спорный момент в том, что в этом случае клиент держит меньше соединений. При наличии одинакового IP на несколько машин — с одинаковым их хостом: pu.vk.com или pp.vk.com, браузер клиента имеет ограничение на количество одновременных запросов к одному хосту. Но во время повсеместного HTTP/2, я считаю, что это уже не так актуально.
Явный минус схемы в том, что приходится прокачивать весь трафик, который идет в хранилище, через еще один сервер. Так как мы прокачиваем трафик через машины, то пока не можем прокачивать по такой же схеме тяжелый трафик, например, видео. Его мы его передаем напрямую — отдельное прямое соединение для отдельных хранилищ именно для видео. Более легкий контент мы передаем через proxy.
Не так давно у нас появилась улучшенная версия proxy. Сейчас расскажу, чем они отличаются от обычных и зачем это нужно.
В сентябре 2017 компания Oracle, которая до этого купила компанию Sun, уволила огромное количество сотрудников Sun. Можно сказать, что в этот момент компания прекратила свое существование. Выбирая название для новой системы, наши админы решили отдать дань уважения и памяти этой компании, и назвали новую систему Sun. Между собой мы называем ее просто «солнышки».
У pp было несколько проблем. Один IP на группу — неэффективный кэш. Несколько физических серверов имеют общий IP-адрес, и нет возможности контролировать, на какой сервер придет запрос. Поэтому если разные пользователи приходят за одним и тем же файлом, то при наличии кэша на этих серверах, файлик оседает в кэше каждого сервера. Это очень неэффективная схема, но ничего нельзя было сделать.
Как следствие — мы не можем шардировать контент, потому что не можем выбрать конкретный сервер этой группы — у них общий IP. Также по некоторым внутренним причинам у нас не было возможности ставить такие серверы в регионы. Они стояли только в Санкт-Петербурге.
С солнышками мы изменили систему выбора. Теперь у нас anycast маршрутизация: dynamic routing, anycast, self-check daemon. У каждого сервера свой собственный индивидуальный IP, но при этом общая подсеть. Все настроено так, что в случае выпадения одного сервера трафик размазывается по остальным серверам той же группы автоматически. Теперь есть возможность выбрать конкретный сервер, нет избыточного кэширования, и надежность не пострадала.
Поддержка весов. Теперь мы можем себе позволить ставить машины разной мощности по необходимости, а также в случае временных проблем менять веса работающим «солнышкам» для уменьшения нагрузки на них, чтобы они «отдохнули» и снова заработали.
Шардирование по id контента. Забавная вещь, связанная с шардированием: обычно мы шардируем контент так, что разные пользователи идут за одним файлом через одно «солнышко», чтобы у них был общий кэш.
Недавно мы запустили приложение “Клевер”. Это онлайн-викторина в live-трансляции, где ведущий задает вопросы, а пользователи отвечают в реальном времени, выбирая варианты. В приложении есть чат, где пользователи могут пофлудить. К трансляции одновременно могут подключаться больше 100 тысяч человек. Они все пишут сообщения, которые рассылаются всем участникам, вместе с сообщением приходит еще аватарка. Если 100 тысяч человек приходит за одной аватаркой в одно «солнышко», то оно может иногда закатиться за тучку.
Чтобы выдержать всплески запросов одного и того же файла, именно для некоторого вида контента у нас включается тупая схема, которая размазывает файлики по всем имеющимся «солнышкам» региона.
Sun изнутри
Реверс proxy на nginx, кэш либо в RAM, либо на быстрые диски Optane/NVMe. Пример: http://sun4-2.userapi.com/c100500/path — ссылка на «солнышко», которое стоит в четвертом регионе, второй сервер-группы. Он закрывает собой файл path, который физически лежит на сервере 100500.
Cache
В нашу архитектурную схему мы добавляем еще один узел — среду кэширования.
Ниже схема расположения региональных кэшей, их примерно 20 штук. Это места, где стоят именно кэши и «солнышки», которые могут кэшировать трафик через себя.
Это кэширование мультимедиа-контента, здесь не хранятся пользовательские данные — просто музыка, видео, фото.
Чтобы определить регион пользователя, мы собираем анонсированные в регионах BGP-префиксы сетей. В случае fallback у нас есть еще парсинг базы geoip, если мы не смогли найти IP по префиксам. По IP пользователя определяем регион. В коде мы можем посмотреть один или несколько регионов пользователя — те точки, к которым он ближе всего географически.
Как это работает?
Считаем популярность файлов по регионам. Есть номер регионального кэша, где находится пользователь, и идентификатор файла — берем эту пару и инкрементируем рейтинг при каждом скачивании.
При этом демоны — сервисы в регионах — время от времени приходят в API и говорят: «Я кэш такой-то, дай мне список самых популярных файлов моего региона, которых на мне еще нет». API отдает пачку файлов, отсортированных по рейтингу, демон их выкачивает, уносит в регионы и оттуда отдает файлы. Это принципиальное отличие pu/pp и Sun от кэшей: те отдают файл через себя сразу, даже если в кэше этого файла нет, а кэш сначала выкачивает файл на себя, а потом уже начинает его отдавать.
При этом мы получаем контент ближе к пользователям и размазывание сетевой нагрузки. Например, только с московского кэша мы раздаем больше 1 Тбит/с в часы наибольшей нагрузки.
Но есть проблемы — серверы кэшей не резиновые. Для суперпопулярного контента иногда не хватает сети на отдельный сервер. Серверы кэшей у нас 40-50 Гбит/с, но бывает контент, который забивает такой канал полностью. Мы идем к тому, чтобы реализовать хранение более одной копии популярных файлов в регионе. Надеюсь, что до конца года реализуем.
Мы рассмотрели общую архитектуру.
Базы данных или движки
Мы называем их не базами, а движками — Engines, потому что баз данных в общепринятом смысле у нас практически нет.
Это вынужденная мера. Так получилось, потому что в 2008-2009 году, когда у VK был взрывной рост популярности, проект полностью работал на MySQL и Memcache, и были проблемы. MySQL любил упасть и испортить файлы, после чего не поднимался, а Memcache постепенно деградировал по производительности, и приходилось его перезапускать.
Получается, что в набирающем популярность проекте было персистентное хранилище, которое портит данные, и кэш, который тормозит. В таких условиях развивать растущий проект тяжело. Было принято решение попробовать переписать критические вещи, в которые проект упирался, на собственные велосипеды.
Решение оказалось успешным. Возможность это сделать была, как и крайняя необходимость, потому что других способов масштабирования в то время не существовало. Не было кучи баз, NoSQL еще не существовал, были только MySQL, Memcache, PostrgreSQL — и все.
Универсальная эксплуатация. Разработку вела наша команда C-разработчиков, и все было сделано единообразно. Независимо от движка, везде был примерно одинаковый формат файлов, записываемых на диск, одинаковые параметры запуска, одинаково обрабатывались сигналы и примерно одинаково вели себя в случае краевых ситуаций и проблем. С ростом движков админам удобно эксплуатировать систему — нет зоопарка, который надо поддерживать, и заново учиться эксплуатировать каждую новую стороннюю базу, что позволяло быстро и удобно наращивать их количество.
Типы движков
Команда написала довольно много движков. Вот лишь часть из них: friend, hints, image, ipdb, letters, lists, logs, memcached, meowdb, news, nostradamus, photo, playlists, pmemcached, sandbox, search, storage, likes, tasks, …
Под каждую задачу, которая требует специфическую структуру данных или обрабатывает нетипичные запросы, C-команда пишет новый движок. Почему бы и нет.
У нас есть отдельный движок memcached, который похож на обычный, но с кучей плюшек, и который не тормозит. Не ClickHouse, но тоже работает. Есть отдельно pmemcached — это персистентный memcached, который умеет хранить данные еще и на диске, причем больше, чем влезает в оперативную память, чтобы не терять данные при перезапуске. Есть разнообразные движки под отдельные задачи: очереди, списки, сеты — все, что требуется нашему проекту.
Кластеры
С точки зрения кода нет необходимости представлять себе движки или базы данных как некие процессы, сущности или инстанции. Код работает именно с кластерами, с группами движков — один тип на кластер. Допустим, есть кластер memcached — это просто группа машин.
Коду вообще не нужно знать физическое расположение, размер и количество серверов. Он ходит в кластер по некому идентификатору.
Чтобы это работало, требуется добавить еще одну сущность, которая находится между кодом и движками — proxy.
RPC-proxy
Proxy — связующая шина, на которой работает практически весь сайт. При этом у нас нет service discovery — вместо него есть конфиг этого proxy, который знает расположение всех кластеров и всех шардов этого кластера. Этим занимаются админы.
Программистам вообще не важно, сколько, где и что стоит — они просто ходят в кластер. Это нам многое позволяет. При получении запроса proxy перенаправляет запрос, зная куда — он сам это определяет.
При этом proxy — точка защиты от отказа сервиса. Если какой-то движок тормозит или упал, то proxy это понимает и соответствующе отвечает клиентской стороне. Это позволяет снять таймаут — код не ждет ответа движка, а понимает, что он не работает и надо как-то по-другому себя вести. Код должен быть готов к тому, что базы не всегда работают.
Специфичные реализации
Иногда мы все-таки очень хотим иметь какое-то нестандартное решение в качестве движка. При этом было принято решение, не использовать наш готовый rpc-proxy, созданный именно для наших движков, а сделать отдельный proxy под задачу.
Для MySQL, который у нас еще кое-где есть используем db-proxy, а для ClickHouse — Kittenhouse.
Это работает в целом так. Есть некий сервер, на нем работает kPHP, Go, Python — вообще любой код, который умеет ходить по нашему RPC-протоколу. Код ходит локально на RPC-proxy — на каждом сервере, где есть код, запущен свой локальный proxy. По запросу proxy понимает куда нужно идти.
Если один движок хочет пойти в другой, даже если это сосед, то идет через proxy, потому что сосед может стоять в другом дата-центре. Движок не должен завязываться на знание расположения чего-либо, кроме самого себя — у нас это стандартное решение. Но исключения, конечно, бывают 🙂
Пример TL-схемы, по которой работают все движки.
Это бинарный протокол, ближайший аналог которого protobuf. В схеме заранее описаны опциональные поля, сложные типы — расширения встроенных скаляров, и запросы. Все работает по этому протоколу.
RPC over TL over TCP/UDP… UDP?
У нас есть RPC-протокол выполнения запросов движка, который работает поверх TL-схемы. Это все работает поверх TCP/UDP соединения. TCP — понятно, а зачем нам UDP часто спрашивают.
UDP помогает избежать проблемы огромного количества соединений между серверами. Если на каждом сервере стоит RPC-proxy и он, в общем случае, может пойти в любой движок, то получается десятки тысяч TCP-соединений на сервер. Нагрузка есть, но она бесполезна. В случае UDP этой проблемы нет.
Heт избыточного TCP-handshake. Это типичная проблема: когда поднимается новый движок или новый сервер, устанавливается сразу много TCP-соединений. Для маленьких легковесных запросов, например, UDP payload, все общение кода с движком — это два UDP-пакета: один летит в одну сторону, второй в другую. Один round trip — и код получил ответ от движка без handshake.
Да, это все работает только при очень небольшом проценте потерь пакетов. В протоколе есть поддержка для ретрансмиттов, таймаутов, но если мы будем терять много, то получим практически TCP, что не выгодно. Через океаны UDP не гоняем.
Персистентное хранение данных
Движки пишут бинлоги. Бинлог — это файлик, в конце которого дописывается событие на изменение состояния или данных. В разных решениях называется по-разному: binary log, WAL, AOF, но принцип один.
Чтобы движок при перезапуске не перечитывал весь бинлог за много лет, движки пишут снапшоты — состояние на текущий момент. При необходимости они читают сначала из него, а потом дочитывают уже из бинлога. Все бинлоги пишутся в одинаковом бинарном формате — по TL-схеме, чтобы админы могли их своими инструментами одинаково администрировать. Для снапшотов такой необходимости нет. Там есть общий заголовок, который указывает чей снапшот — int, magic движка, а какое тело — никому не важно. Это проблема движка, который записал снапшот.
Бегло опишу принцип работы. Есть сервер, на котором работает движок. Он открывает на запись новый пустой бинлог, пишет в него событие на изменение.
В какой-то момент он либо сам решает сделать снапшот, либо ему приходит сигнал. Сервер создает новый файл, полностью записывает в него свое состояние, дописывает текущий размер бинлога — offset на конец файла, и продолжает писать дальше. Новый бинлог не создается.
В какой-то момент, когда движок перезапустился, на диске будет и бинлог и снапшот. Движок читает полностью снапшот, поднимает свое состояние на определенный момент.
Вычитывает позицию, которая была на момент создания снапшота, и размер бинлога.
Дочитывает конец бинлога для получения текущего состояния и продолжает писать дальше события. Это простая схема, все наши движки работают по ней.
Репликация данных
В результате репликация данных у нас statement-based — мы пишем в бинлог не какие-нибудь изменения страниц, а именно запросы на изменения. Очень похоже на то, что приходит по сети, только чуть измененное.
Эта же схема используется не просто для репликации, но еще и для создания бэкапов. У нас есть движок — пишущий мастер, который пишет в бинлог. В каком угодно другом месте, куда настроят админы, поднимается копирование этого бинлога, и все — у нас есть бэкап.
Если нужна читающая реплика, чтобы снизить нагрузку на чтение по CPU — просто поднимается читающий движок, который дочитывает конец бинлога и выполняет эти команды в себе локально.
Отставание здесь очень маленькое, и есть возможность узнать, насколько реплика отстает от мастера.
Шардирование данных в RPC-proxy
Как работает шардирование? Как proxy понимает, на какой шард кластера отправить? Код не сообщает : «Отправь на 15 шард!» — нет, это делает proxy.
Самая простая схема — firstint — первое число в запросе.
get(photo100_500) => 100 % N.
Это пример для простого memcached текстового протокола, но, конечно, запросы бывают сложные, структурированные. В примере берется первое число в запросе и остаток от деления на размер кластера.
Это полезно, когда мы хотим иметь локальность данных одной сущности. Допустим, 100 — юзер или ID группы, и мы хотим, чтобы для сложных запросов все данные одной сущности были на одном шарде.
Если нам все равно, как запросы размазаны по кластеру, есть другой вариант — хеширование шарда целиком.
hash(photo100_500) => 3539886280 % N
Также получаем хеш, остаток от деления и номер шарда.
Оба этих варианта работают только если мы готовы к тому, что при наращивании размера кластера мы будем дробить или увеличивать его в кратное количество раз. Например, у нас было 16 шардов, нам не хватает, хотим больше — можно безболезненно получить 32 без даунтайма. Если хотим наращивать не кратно — будет даунтайм, потому что не получится аккуратно передробить все без потерь. Эти варианты полезны, но не всегда.
Если нам нужно добавлять или убирать произвольное количество серверов, используется консистентное хеширование на кольце a la Ketama. Но при этом мы полностью теряем локальность данных, приходится делать merge запроса на кластер, чтобы каждый кусочек вернул свой маленький ответ, и уже объединять ответы на proxy.
Есть супер-специфические запросы. Это выглядит так: RPC-proxy получает запрос, определяет, в какой кластер пойти и определяет шард. Тогда есть либо пишущие мастеры, либо, если кластер имеет поддержку реплик, он отсылает в реплику по запросу. Этим всем занимается proxy.
Мы пишем логи несколькими способами. Самый очевидный и простой — пишем логи в memcache.
ring-buffer: prefix.idx = line
Есть префикс ключа — имя лога, строка, и есть размер этого лога — количество строчек. Берем случайное число от 0 до числа строк минус 1. Ключ в memcache — это префикс сконкатенированный с этим случайным числом. В значение сохраняем строчку лога и текущее время.
Когда необходимо прочитать логи, мы проводим Multi Get всех ключей, сортируем по времени, и таким образом получаем продакшн лог в реальном времени. Схема применяется, когда нужно что-то продебажить в продакшн в реальном времени, ничего не ломая, не останавливая и не пуская трафик на другие машины, но этот лог не живет долго.
Для надежного хранения логов у нас есть движок logs-engine. Именно для этого он и создавался, и широко используется в огромном количестве кластеров. Самый большой известный мне кластер хранит 600 Тбайт запакованных логов.
Движок очень старый, есть кластеры, которым уже по 6–7 лет. С ним есть проблемы, которые мы пытаемся решить, например, начали активно использовать ClickHouse для хранения логов.
Сбор логов в ClickHouse
Эта схема показывает, как мы ходим в наши движки.
Есть код, который по RPC локально ходит в RPC-proxy, а тот понимает, куда пойти в движок. Если мы хотим писать логи в ClickHouse, нам нужно в этой схеме поменять две части:
А чтобы ходить в ClickHouse, мы сделали KittenHouse. Если мы пойдем напрямую из KittenHouse в ClickHouse — он не справится. Даже без запросов, от HTTP-соединений огромного количества машин он складывается. Чтобы схема работала, на сервере с ClickHouse поднимается локальный reverse proxy, который написан так, что выдерживает нужные объемы соединений. Также он может относительно надежно буферизировать данные в себе.
Иногда мы не хотим реализовывать RPC-схему в нестандартных решениях, например, в nginx. Поэтому в KittenHouse есть возможность получать логи по UDP.
Если отправитель и получатель логов работают на одной машине, то вероятность потерять UDP-пакет в пределах локального хоста довольно низкая. Как некий компромисс между необходимостью реализовать RPC в стороннем решении и надежностью, мы используем просто отправку по UDP. К этой схеме мы еще вернемся.
Мониторинг
У нас два вида логов: те, которые собирают администраторы по своим серверам и те, которые пишут разработчики из кода. Им соответствуют два типа метрик: системные и продуктовые.
Системные метрики
На всех серверах у нас работает Netdata, которая собирает статистику и отсылает ее в Graphite Carbon. Поэтому как система хранения используется ClickHouse, а не Whisper, например. При необходимости можно напрямую читать из ClickHouse, или использовать Grafana для метрик, графиков и отчетов. Как разработчикам, доступа к Netdata и Grafana нам хватает.
Продуктовые метрики
Для удобства мы написали много всего. Например, есть набор обычных функций, которые позволяют записать Counts, UniqueCounts значения в статистику, которые отсылаются куда-то дальше.
Впоследствии мы можем использовать фильтры сортировки, группировки и сделать все, что хотим от статистики — построить графики, настроить Watсhdogs.
Мы пишем очень много метрик, количество событий от 600 миллиардов до 1 триллиона в сутки. При этом мы хотим хранить их хотя бы пару лет, чтобы понимать тенденции изменения метрик. Склеить это все воедино — большая проблема, которую мы еще не решили. Расскажу, как это работает последние несколько лет.
У нас есть функции, которые пишут эти метрики в локальный memcache, чтобы уменьшить количество записей. Один раз в небольшой промежуток времени локально запущенный stats-daemon собирает все записи. Дальше демон сливает метрики в два слоя серверов logs-collectors, которые агрегирует статистику с кучи наших машин, чтобы слой за ними не умирал.
По необходимости мы можем писать напрямую в logs-collectors.
Но запись из кода напрямую в коллекторы в обход stas-daemom — плохо масштабируемое решение, потому что увеличивает нагрузку на collector. Решение подойдет, только если по какой-то причине на машине мы не можем поднять memcache stats-daemon, либо он упал, и мы пошли напрямую.
Дальше logs-collectors сливают статистику в meowDB — это наша база, которая еще и метрики умеет хранить.
Потом из кода можем бинарным «около-SQL» производить выборки.
Эксперимент
Летом 2018 у нас был внутренний хакатон, и появилась идея попробовать заменить красную часть схемы на что-то, что может хранить метрики в ClickHouse. У нас есть логи на ClickHouse — почему бы не попробовать?
У нас была схема, которая писала логи через KittenHouse.
Мы решили добавить в схему еще один «*House», который будет принимать именно метрики в том формате, как их пишет наш код по UDP. Дальше этот *House превращает их в inserts, как логи, которые понимает KittenHouse. Эти логи он умеет прекрасно доставлять до ClickHouse, который должен их уметь читать.
Схема с memcache, stats-daemon и logs-collectors базы заменяется на такую.
Схема с memcache, stats-daemon и logs-collectors базы заменяется на такую.
Схема не экономит железо. Нужно меньше серверов, не нужны локальные stats-daemons и logs-collectors, но ClickHouse требует сервера жирнее, чем те, что стоят на текущей схеме. Серверов нужно меньше, но они должны быть дороже и мощнее.
Деплой
Сначала посмотрим на деплой PHP. Разработку ведем в git: используем GitLab и TeamCity для деплоя. Ветки разработчиков вливаются в мастер-ветку, из мастера для тестирования вливаются в стейджинг, из стейджинга — в продакшн.
Перед деплоем берутся текущая ветка продакшна и предыдущая, в них считается diff файлов — изменение: создан, удален, изменен. Это изменение записывается в binlog специального движка copyfast, который может быстро реплицировать изменения на весь наш парк серверов. Здесь используется не копирование напрямую, а gossip replication, когда один сервер рассылает изменения ближайшим соседям, те — своим соседям, и так далее. Это позволяет обновлять код за десятки и единицы секунд на всем парке. Когда изменение доезжает до локальной реплики, она применяет эти патчи на своей локальной файловой системе. По этой же схеме производится и откат.
Мы также много деплоим kPHP и у него тоже есть собственная разработка на git по схеме выше. Так как это бинарник HTTP-сервера, то мы не можем производить diff — релизный бинарник весит сотни Мбайт. Поэтому здесь вариант другой — версия записывается в binlog copyfast. С каждым билдом она инкрементируется, и при откате она тоже увеличивается. Версия реплицируется на серверы. Локальные copyfast’ы видят, что в binlog попала новая версия, и тем же самым gossip replication забирают себе свежую версию бинарника, не утомляя наш мастер-сервер, а аккуратно размазывая нагрузку по сети. Дальше следует graceful перезапуск на новую версию.
Для наших движков, которые тоже по сути бинарники, схема очень похожа:
Алексей Акулович один из тех, кто в составе Программного комитета помогает PHP Russia уже 17 мая стать самым масштабным за последнее время событием для PHP-разработчиков. Посмотрите, какой у нас крутой ПК, какие спикеры (двое из них разрабатывают ядро PHP!) — кажется, что если вы пишите на PHP, это нельзя пропустить.