Спроектированные с учетом совершенно других требований Интернета пятилетней давности компоненты, составляющие ядро платформы Google, потребовали фундаментальной смены архитектуры индексации и поиска, который был представлен публике под кодовым названием Google Caffeine. Новые, переработанные, версии старых "слоев" также окрестили броскими именами, но резонанса у технической публики они вызвали намного меньше, чем новый поисковый алгоритм в SEO-индустрии (Search Engine Optimization - комплекс мер для поднятия позиций сайта в результатах выдачи поисковых систем) (рисунок 7).

Рисунок 7 - Архитектура типовой поисковой системы.

Хранилища контента и индексной базы в ней играют важнейшую роль

3.1.4.1 Google Colossus

Новая архитектура GFS была спроектирована для минимизации задержек при доступе к данным (что критично для приложений вроде GMail и YouTube), не в ущерб основным свойствам старой версии: отказоустойчивости и прозрачной масштабируемости.

В оригинальной же реализации упор был сделан на повышение общей пропускной способности: операции объединялись в очереди и выполнялись разом, при таком подходе можно было прождать пару секунд еще до того, как первая операция в очереди начнет выполняться. Помимо этого в старой версии было большое слабое место в виде единственно мастер-сервера с метаданными, сбой в котором грозил недоступностью всей файловой системы в течении небольшого промежутка времени (пока другой сервер не подхватит его функции, изначально это занимало около 5 минут, в последних версиях порядка 10 секунд) - это также было вполне допустимо при отсутствии требования работы в реальном времени, но для приложений, напрямую взаимодействующих с пользователями, это было неприемлемо с точки зрения возможных задержек.

Основным нововведением в Colossus стали распределенные мастер-сервера, что позволило избавиться не только от единственной точки отказа, но и существенно уменьшить размер одного блока с данными (с 64 до 1 мегабайта), что в целом очень положительно сказалось на работе с небольшими объемами данных. В качестве бонуса исчез теоретический предел количества файлов в одной системе.

Детали распределения ответственности между мастер-серверами, сценариев реакции на сбои, а также сравнение по задержкам и пропускной способности обоих версий, к сожалению, по-прежнему конфиденциальны.

По прогнозам Google текущий вариант реализации распределенной файловой системы "уйдет на пенсию" в конце 2015 года из-за популяризации твердотельных накопителей и существенного скачка в области вычислительных технологий (процессоров).

3.1.4.2 Google Percolator

MapReduce отлично справлялся с задачей полной перестройки поискового индекса, но не предусматривал небольшие изменения, затрагивающие лишь часть страниц. Из-за потоковой, последовательной природы MapReduce для внесения изменений в небольшую часть документов все равно пришлось бы обновлять весь индекс, так как новые страницы непременно будут каким-то образом связаны со старыми. Таким образом, задержка между появлением страницы в Интернете и в поисковом индексе при использовании MapReduce была пропорциональна общему размеру индекса (а значит и Интернета, который постоянно растет), а не размеру набора измененных документов.

Ключевые архитектурные решения, лежащие в основе MapReduce, не позволяли повлиять на эту особенность и в итоге система индексации была построена заново с нуля, а MapReduce продолжает использоваться в других проектах Google для аналитики и прочих задач, по-прежнему не связанных с реальным временем.

Новая система получила название Percolator.

Percolator представляет собой надстройку над BigTable, позволяющую выполнять комплексные вычисления на основе имеющихся данных, затрагивающие много строк и даже таблиц одновременно (в стандартном API BigTable это не предусмотрено).

Веб-документы или любые другие данные изменяются/добавляются в систему посредством модифицированного API BigTable, а дальнейшие изменения в остальной базе осуществляются посредством механизма "обозревателей". Если говорить в терминах реляционных СУБД, то обозреватели - что-то среднее между триггерами и хранимыми процедурами. Обозреватели представляют собой подключаемый к базе данных код (на C++), который исполняется в случае возникновении изменений в определенных колонках. Все используемые системой метаданные также хранятся в специальных колонках BigTable. При использовании Percolator все изменения происходят в транзакциях, удовлетворяющих принципу ACID, каждая из которых затрагивает именно те сервера в кластере, на которых необходимо внести изменения. Механизм транзакций на основе BigTable разрабатывался в рамках отдельного проекта под названием Google Megastore.

Таким образом, при добавлении нового документа (или его версии) в поисковый индекс, вызывается цепная реакция изменений в старых документах, ограниченная по своей рекурсивности. Эта система при осуществлении случайного доступа поддерживает индекс в актуальном состоянии.

В качестве бонуса в этой схеме удалось избежать еще двух недостатков MapReduce:

- проблемы "отстающих": когда один из серверов (или одна из конкретных подзадач) оказывался существенно медленнее остальных, что также значительно задерживало общее время завершения работы кластера;

- пиковая нагрузка: MapReduce не является непрерывным процессом, а разделяется на работы с ограниченной целью и временем исполнения. Таким образом помимо необходимости ручной настройки работ и их типов, кластер имеет очевидные периоды простоя и пиковой нагрузки, что ведет к неэффективному использованию вычислительных ресурсов.

Но все это оказалось не бесплатно: при переходе на новую систему удалось достичь той же скорости индексации, но при этом использовалось вдвое больше вычислительных ресурсов. Производительность Percolator находится где-то между производительностью MapReduce и производительностью традиционных СУБД. Так как Percolator является распределенной системой, для обработки фиксированного небольшого количества данных ей приходится использовать существенно больше ресурсов, чем традиционной СУБД; такова цена масштабируемости. По сравнению с MapReduce также пришлось платить дополнительными потребляемыми вычислительными ресурсами за возможность случайного доступа с низкой задержкой. Тем не менее, при выбранной архитектуре Google удалось достичь практически линейного масштабирования при увеличении вычислительных мощностей на много порядков. Дополнительные накладные расходы, связанные с распределенной природой решения, в некоторых случаях до 30 раз превосходят аналогичный показатель традиционных СУБД, но у данной системы есть солидный простор для оптимизации в этом направлении, чем Google активно и занимается.

3.1.4.3 Google Spanner

Spanner представляет собой единую систему автоматического управления ресурсами всего парка серверов Google.

Основные особенности:

- единое пространство имен:

а) иерархия каталогов;

б) независимость от физического расположения данных;

- поддержка слабой и сильной целостности данных между датацентрами;

- автоматизация:

а) перемещение и добавление реплик данных;

б) выполнение вычислений с учетом ограничений и способов использования;

в) выделение ресурсов на всех доступных серверах;

- зоны полу-автономного управления;

- восстановление целостности после потерь соединения между датацентрами;

- возможность указания пользователями высокоуровневых требований, например:

а) 99% задержек при доступе к этим данным должны быть до 50 мс;

б) расположить эти данные на как минимум 2 жестких дисках в Европе, 2 в США и 1 в Азии;

- интеграция не только с серверами, но и с сетевым оборудованием, а также системами охлаждения в датацентрах;

- проектировалась из расчета на:

а) 1-10 миллионов серверов;

б) ~10 триллионов директорий;

в) ~1000 петабайт данных;

г) 100-1000 датацентров по всему миру;

д) ~1 миллиард клиентских машин.

Об этом проекте Google известно очень мало, официально он был представлен публике лишь однажды в 2009 году, с тех пор лишь местами упоминался сотрудниками без особой конкретики. Точно не известно развернута ли эта система на сегодняшний день и если да, то в какой части датацентров, а также каков статус реализации заявленного функционала.

3.1.4.4 Прочие компоненты платформы

Платформа Google в конечном итоге сводится к набору сетевых сервисов и библиотек для доступа к ним из различных языков программирования (в основном используются C/C++, Java, Python и Perl). Каждый продукт, разрабатываемый Google, в большинстве случаев использует эти библиотеки для осуществления доступа к данным, выполнения комплексных вычислений и других задач, вместо стандартных механизмов, предоставляемых операционной системой, языком программирования или opensource библиотеками.

Вышеизложенные проекты составляют лишь основу платформы Google, хотя она включает в себя куда больше готовых решений и библиотек, несколько примеров из публично доступных проектов:

- GWT (Google Web Toolkit - свободный Java-фреймворк для AJAX-приложений) для реализации пользовательских интерфейсов на Java;

- Closure - набор инструментов для работы с JavaScript;

- Protocol Buffers - не зависящий от языка программирования и платформы формат бинарной сериализации структурированных данных, используется при взаимодействии большинства компонентов системы внутри Google;

- LevelDB - высокопроизводительная встраиваемая СУБД;

- Snappy - быстрая компрессия данных, используется при хранении данных в GFS.

3.1.5 Подводим итоги

Подведем итоги:

- стабильные, проработанные и повторно используемые базовые компоненты проекта - залог её стремительного развития, а также создания новых проектов на той же кодовой базе;

- если задачи и обстоятельства, с учетом которых проектировалась система, существенно изменились - не стоит бояться вернуться на стадию проектирования и реализовать новое решение;

- использовать стоит инструменты, подходящие для решения каждой конкретной задачи, а не те, которые навязывает мода или привычки участников команды;

- даже, казалось бы, незначительные недоработки и допущения на большом масштабе могут вылиться в огромные потери - необходимо уделять максимум внимания деталям при реализации проекта;

- нельзя полагаться даже на очень дорогое оборудование - все ключевые сервисы должны работать минимум на двух серверах, в том числе и базы данных;

- распределенная платформа, общая для всех проектов, позволит новым разработчикам легко вливаться в работу над конкретными продуктами, с минимумом представления о внутренней архитектуре компонентов платформы.

Прозрачная работа приложений в нескольких датацентрах - одна из самых тяжелых задач, с которыми сталкиваются интернет-компании. Сегодня каждая из них решает её по-своему и держит подробности в секрете, что сильно замедляет развитие opensource решений.

3.2 Вконтакте

Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции HighLoad++ ответили на шквал вопросов по совершенно разным аспектам работы Вконтакте, в том числе и техническим.

3.2.1 Платформа

Платформа Вконтакте:

- Debian?Linux - основная операционная система;

- nginx - балансировка нагрузки;

- PHP + XCache;

- Apache + mod_php;

- memcached;

- MySQL;

- собственная СУБД на C, созданная "лучшими умами" России;

- node.js - прослойка для реализации XMPP, живет за HAProxy;

- изображения отдаются просто с файловой системы xfs;

- ffmpeg - конвертирование видео.

3.2.2 Статистика

Немного статистики:

- 95 миллионов учетных записей;

- 40 миллионов активных пользователей во всем мире (сопоставимо с аудиторией интернета в России);

- 11 миллиардов запросов в день;

- 200 миллионов личных сообщений в день;

- видеопоток достигает 160Гбит/с;

- более 10 тысяч серверов, из которых только 32 - фронтенды на nginx (количество серверов с Apache неизвестно);

- 30-40 разработчиков, 2 дизайнера, 5 системных администраторов, большой персонал в датацентрах;

- каждый день выходит из строя около 10 жестких дисков.

3.2.3 Архитектура

3.2.3.1 Общие принципы

Общие принципы работы Вконтакте:

- сервера многофункциональны и используются одновременно в нескольких ролях:

а) перебрасывание полуавтоматическое;

б) требуется перезапускать daemon'ы;

- генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook, основное отличие - использование собственной СУБД вместо MySQL;

- при балансировке нагрузки используются:

а) взвешенный round robin внутри системы;

б) различные сервера для различных типов запросов;

в) балансировка на уровне DNS (Domain Name System - система доменных имен) на 32 IP-адреса;

- большая часть внутреннего софта написано самостоятельно, в том числе:

а) собственная СУБД;

б) мониторинг с уведомлением по СМС;

в) автоматическая система тестирования кода;

г) анализаторы статистики и логов;

- мощные сервера:

а) 8-ядерные процессоры Intel (по два на сервер);

б) 64Гб оперативной памяти;

в) 8 жестких дисков;

г) RAID не используется;

д) не брендированные;

- вычислительные мощности серверов используются менее, чем на 20%;

- сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем:

а) вся основная база данных располагается в одном датацентре в Санкт-Петербурге;

б) в Московских датацентрах только аудио и видео;

в) в планах сделать репликацию базы данных в другой датацентр в Ленинградской области;

- CDN (Content Delivery Network - сеть доставки контента) на данный момент не используется, но в планах возможно его использование;

- резервное копирование данных происходит ежедневно и инкрементально.

3.2.3.2 Собственная база данных на C

Этому продукту, уделялось максимум внимания аудитории на конференции HighLoad++, но при этом почти никаких подробностей о том, что он, собственно говоря, собой представляет, так и не было обнародовано.

Известно, что:

- разработана "лучшими умами" России, победителями олимпиад и конкурсов топкодер; были озвучены даже имена этих "героев" Вконтакте:

а) Андрей Лопатин;

б) Николай Дуров;

в) Арсений Смирнов;

г) Алексей Левин;

- используется в огромном количестве сервисов:

а) личные сообщения;

б) сообщения на стенах;

в) статусы;

г) поиск;

д) приватность;

е) списки друзей;

- нереляционная модель данных;

- большинство операций осуществляется в оперативной памяти;

- интерфейс доступа представляет собой расширенный протокол memcached, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса);

- хотели сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами;

- кластеризация осуществляется легко;

- есть репликация.

3.2.3.3 Аудио и видео

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

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

3.2.3.4 XMPP

Как известно, некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.

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

- реализован на node.js (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи);

- работа с большими контакт-листами - у многих пользователей количество друзей на Вконтакте измеряется сотнями и тысячами;

- высокая активность смены статусов - люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях;

- аватарки передаются в base64;

- тесная интеграция с внутренней системой обмена личными сообщениями Вконтакте;

- 80-100 тысяч человек онлайн, в пике - 200 тысяч;

- HAProxy обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий;

- данные хранятся в MySQL;

- сервис работает на 5 серверах разной конфигурации, на каждом из них работает код на node.js (по 4 процесса на сервер), а на трех самых мощных - еще и MySQL;

- в node.js большие проблемы с использованием OpenSSL, а также происходят утечки памяти;

- группы друзей в XMPP не связаны с группами друзей на сайте - сделано по просьбе пользователей, которые не хотели, чтобы их друзья из-за плеча видели в какой группе они находятся.

3.2.3.5 Интеграция с внешними ресурсами

Во Вконтакте считают данное направление очень перспективным и осуществляют массу связанных с этим работ. Основные предпринятые шаги:

- максимальная кроссбраузерность для виджетов на основе библиотек easyXDM и fastXDM;

- кросс-постинг статусов в Twitter, реализованный с помощью очередей запросов;

- кнопка "поделиться с друзьями", поддерживающая openGraph теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега <title> и атрибутов alt у изображений, чуть ли не побуквенно);

- возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и т.д.), открыты к интеграции с другими.

3.2.4 Интересные факты о Вконтакте

Некоторые интересные факты о Вконтакте:

- процесс разработки близок к Agile, с недельными итерациями;

- ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для Debian;

- фотографии загружаются на два жестких диска одного сервера одновременно, после чего создается резервная копия на другом сервере;

- есть много доработок над memcached, в том числе для более стабильного и длительного размещения объектов в памяти;

- фотографии не удаляются для минимизации фрагментации;

- решения о развитии проекта принимают Павел Дуров и Андрей Рогозов, ответственность за сервисы - на них и на реализовавшем его разработчике;

- Павел Дуров откладывал деньги на хостинг с 1 курса.

3.2.5 Подводим итоги

В целом Вконтакте развивается в сторону увеличения скорости распространения информацию внутри сети. Приоритеты поменялись в этом направлении достаточно недавно, этим обусловлено, например, перенос выхода почтового сервиса Вконтакте, о котором очень активно говорили, когда появилась возможность забивать себе текстовые URL вроде vkontakte.ru/denis.gulak. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.

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

Заключение

компьютерный сервер google вконтакте

Результаты данной выпускной квалификационной работы заключаются в следующем:

1 рассмотрены основные понятия высоконагруженных систем;

2 исследованы высоконагруженные системы Google и Вконтакте;

3 изучены архитектуры заявленных высоконагруженных систем, а также их особенности и различия;

4 изучены платформы, на которых они реализованы, и оборудование, с помощью которого реализуются данные системы.

Результаты данной выпускной квалификационной работы будут полезны в исследовательских работах специалистов в области информационных технологий, а также разработчикам социальных сетей или различных многопользовательских приложений, как основа для создания улучшенной системы.

Список использованных источников

1. Календарев А. М. HighLoad в WEB проектах / Календарев А. М. // Системный Администратор №6. 2011. - С. 12-14.

2. Календарев А. М. Использование Tarantool в WEB проектах / Календарев А. М. // Системный Администратор №7-8. 2011. - С. 8-9.

3. Сайфутдинова Л. Ж. Высоконагруженные системы (Back-End) // Материалы конференции «Дни науки ОТИ НИЯУ МИФИ - 2012». Озерск, 25-26 апреля 2012 г. - Челябинск: ОТИ НИЯУ МИФИ., 2012. - Том 1. - С. 86-87.

Размещено на Allbest.ru