Исследование высоконагруженных компьютерных систем

Исследование высоконагруженных компьютерных систем

Исследование высоконагруженных компьютерных систем

Обозначения и сокращения

Web 2.0методика проектирования систем, путем учета сетевых взаимодействийNoSQLnot only SQL - ряд подходов, направленных на реализацию хранилищ баз данныхБДбаза данныхHTMLHyperText Markup LanguageNginxвеб-сервер <https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80> и почтовый прокси-сервер <https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%BA%D1%81%D0%B8-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80>, работающий на Unix <https://ru.wikipedia.org/wiki/Unix>-подобных операционных системахURLUniform Resource Locator - единообразный локатор (определитель местонахождения) ресурсаAPIинтерфейс создания приложенийGFSGoogle File System <https://www.insight-it.ru/goto/479dfa95/> - распределенная файловая системаСУБДсистема управления базами данных

Введение

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

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

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

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

1.Что такое высоконагруженные компьютерные системы

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

Итак, что же такое высоконагруженная система? Ответ на этот вопрос стоит начать с описания качественных свойств такого рода систем.

1.1Традиционные качества высоконагруженной системы

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

это не вся правда;

приведенные факторы являются количественными, а не качественными.

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

1.1.1Многопользовательская система

Высоконагруженное приложение в первую очередь является многопользовательским. То есть в один момент времени с ним работает более чем один человек. Сейчас, в эру стремительного развития Интернета, это тысячи и сотни тысяч человек.

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

Если посмотреть на статистику Московского метрополитена за 2010 год, то окажется, что средняя часовая нагрузка на систему максимальна в диапазоне от 8 до 9 часов утра. За этот час через турникеты проходят приблизительно 720 тысяч человек. Что порождает необходимость не менее 200 раз в секунду проверять статус предъявленных проездных и принимать решение о пропуске того или иного человека через турникет. В Интернете существует масса высоконагруженных ресурсов с подобными показателями пропускной способности. Например, статистика по StackOverflow за тот же 2010-й год показывает, что их средняя пропускная способность находится в диапазоне 100-150 хитов в секунду.

Определенно у метрополитена более высокие требования к пропускной способности. Но значит ли это что Московский метрополитен можно считать более высоконагруженным чем StackOverflow? Вряд ли, в частности потому, что эти две системы оперируют несравнимыми объемами информации.

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

1.1.2Распределенная система

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

необходимости обрабатывать возрастающие объемы данных;

необходимости живучести системы в случаях отказа части серверов.

Большинство высоконагруженных приложений являются Интернет-приложениями. А отличительной особенностью современного Интернета основанного на концепции Web 2.0 является тот факт, что сами пользователи генерируют данные, которые они сами же в итоге и потребляют. Это приводит к тому, что чем больше пользователей, тем больше потенциальный объем хранимых данных.

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

Но большие объемы данных - это не все. Система должна работать в режиме 24x7 без остановок и перерывов. Но, любое даже самое надежное оборудование иногда выходит из строя. Встает естественная задача обеспечения доступности системы в случаях отказа оборудования.

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

1.1.3Позитивная динамика по пользователям и данным

Если приложение представляет хоть какой-то интерес, то даже если ничего не делать, аудитория будет расти просто с ростом аудитории Интернета. Поэтому характерной чертой высоконагруженных систем является не просто большое количество пользователей, но и позитивная динамика количества пользователей.

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

1.1.4Интерактивность

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

1.1.5Управление ресурсами

Качество интерактивности очень важно для понимания сути высоконагруженных приложений, потому что по вышеизложенным причинам разрабатывая такую систему нужно быть уверенным в том, что каждый раз, когда приложение получает очередной запрос, у него должно быть достаточно свободных ресурсов (CPU, память, диск, сеть) для обработки запроса за приемлемое время.

Контроль над ресурсами является неотъемлемой частью работы с высоконагруженным проектом.

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

Высоконагруженная система - это интерактивная распределенная система, которая требует постоянного контроля над собственными ресурсами. В противном случае она перестает работать.

Причина в том, что со временем системе просто перестанет хватать ресурсов. А нехватка ресурсов провоцируется факторами, часть из которых уже были рассмотрены, а именно:

рост аудитории;

рост объема данных;

изменения паттернов поведения аудитории, в том числе и сезонные.

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

как решать существующие задачи, используя меньше ресурсов (практически все NoSQL БД, оптимизация);

как имея больше ресурсов решать пропорционально больший объем задач (message queueing, распределенные вычисления, распределенные БД, параллелизм).

1.2Высоконагруженный проект - это интернет приложение

Если исходить из того что неотъемлемой частью высоконагруженного проекта является постоянный рост данных и аудитории, то становится понятно почему высоконагруженные проекты - это поголовно Интернет приложения.

В реальной жизни всегда есть некий предел, который не позволяет использовать систему все возрастающему количеству людей. В том же метрополитене человеку требуется некоторое время, чтобы пройти через турникет. Исходя из этого времени, а также общего количества турникетов можно достаточно точно рассчитать верхний предел возможной нагрузки. Ведь это невозможно, чтобы за секунду через один турникет могло пройти 10 человек.

В сфере High Performance Computations приложения могут выполнять просто гигантское количество операций в единицу времени. Больше чем любое Интернет-приложение. Но это количество зависит только от объема входных данных, а также алгоритма обработки (например, от точности моделирования, если речь идет о моделировании динамических систем). Тяжело придумать причину, почему нагрузка на такую систему может вырасти сама по себе без вмешательства персонала ее сопровождающего.

Интернет-приложения это единственная сфера, в которой нагрузка есть переменная, не имеющая верхнего предела.

В контексте высокой нагрузки список первостепенных задач, которые стоят перед разработчиками:

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

определение звеньев системы нуждающихся в масштабировании в ближайшем времени и выбор стратегии масштабирования этих звеньев;

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

2.Три кита HightLoad

2.1Отложенные вычисления

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

Отложенные вычисления позволяют сократить общий объём вычислений за счёт тех вычислений, результаты которых не будут использованы. Программист может просто описывать зависимости функций друг от друга и не следить за тем, чтобы не осуществлялось «лишних вычислений».

В общем случае, отложенные вычисления осуществляются по принципу:

(!res)

{= someCalculation();

}

Одной из разновидностей предварительных вычислений является кэширование.

2.1.1Кэширование и memcached

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

Кэширование сегодня является неотъемлемой частью любого Web-проекта, не обязательно высоконагруженного. Для каждого ресурса критичной для пользователя является такая характеристика, как время отклика сервера. Увеличение времени отклика сервера приводит к оттоку посетителей. Следовательно, необходимо минимизировать время отклика: для этого необходимо уменьшать время, требуемое на формирование ответа пользователю, а ответ пользователю требует получить данные из каких-то внешних ресурсов (backend). Этими ресурсами могут быть как базы данных, так и любые другие относительно медленные источники данных (например, удаленный файловый сервер, на котором мы уточняем количество свободного места). Для генерации одной страницы достаточно сложного ресурса нам может потребоваться совершить десятки подобных обращений. Многие из них будут быстрыми: 20 миллисекунд и меньше, однако всегда существует некоторое небольшое количество запросов, время вычисления которых может исчисляться секундами или минутами (даже в самой оптимизированной системе они могут быть, хотя их количество должно быть минимально). Если сложить всё время, которое мы затратим на ожидание результатов запросов (если же мы будем выполнять запросы параллельно, то возьмем время вычисления самого долгого запроса), мы получим неудовлетворительное время отклика.

Решением этой задачи является кэширование: мы помещаем результат вычислений в некоторое хранилище (например, memcached), которое обладает отличными характеристиками по времени доступа к информации. Теперь вместо обращений к медленным, сложным и тяжелым backendам нам достаточно выполнить запрос к быстрому кэшу.

2.1.2Принцип локальности

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

Кэш всегда лучше, чем исходный источник данных: кэш ЦП (центральный процессор) на порядки быстрее оперативной памяти, однако мы не можем сделать оперативную память такой же быстрой, как кэш - это экономически неэффективно и технически сложно. Буфер жесткого диска удовлетворяет запросы за данными на порядки быстрее самого жесткого диска, однако буфер не обладает свойством запоминать данные при отключении питания - в этом смысле он хуже самого устройства. Аналогичная ситуация и с кэшированием в Webе: кэш быстрее и эффективнее, чем backend, однако он обычно в случае перезапуска или падения сервера не может сохранить данные, а также не обладает логикой по вычислению каких-либо результатов: он умеет возвращать лишь то, что мы ранее в него положили.

2.1.3Memcached

Memcached <#"justify">2.1.4Общая схема кэширования

В общем случае схема кэширования выглядит следующим образом: frontendу (той части проекта, которая формирует ответ пользователю) требуется получить данные какой-то выборки. Frontend обращается к быстрому как гепард серверу memcached за кэшом выборки (get-запрос) (рисунок 1). Если соответствующий ключ будет обнаружен, работа на этом заканчивается. В противном случае следует обращение к тяжелому, неповоротливому, но мощному (как слон) backendу, в роли которого чаще всего выступает база данных. Полученный результат сразу же записывается в memcached в качестве кэша (set-запрос). При этом обычно для ключа задается максимальное время жизни (срок годности), который соответствует моменту сброса кэша.

Рисунок 1 - Общая схема кэширования

Такая стандартная схема кэширования реализуется всегда. Вместо memcached в некоторых проектах могут использоваться локальные файлы, иные способы хранения (другая БД, кэш PHP-акселератора и т.п.).

2.1.5Архитектура memcached

Каким же образом устроен memcached? Как ему удаётся работать настолько быстро, что даже десятки запросов к memcached, необходимых для обработки одной страницы сайта, не приводят к существенной задержке. При этом memcached крайне нетребователен к вычислительным ресурсам: на нагруженной инсталляции процессорное время, использованное им, редко превышает 10%.

Во-первых, memcached спроектирован так, чтобы все его операции имели алгоритмическую сложность O(1), т.е. время выполнения любой операции не зависит от количества ключей, которые хранит memcached. Это означает, что некоторые операции (или возможности) будут отсутствовать в нём, если их реализация требует всего лишь линейного (O(n)) времени. Так, в memcached отсутствуют возможность объединения ключей «в папки», т.е. какой-либо группировки ключей, также мы не найдем групповых операций над ключами или их значениями.

Основными оптимизированными операциями является выделение/освобождение блоков памяти под хранение ключей, определение политики самых неиспользуемых ключей (LRU) для очистки кэша при нехватке памяти. Поиск ключей происходит через хэширование, поэтому имеет сложность O(1).

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

По сути, можно сказать, что время отклика сервера memcached определяется только сетевыми издержками и практически равно времени передачи пакета от frontendа до сервера memcached (RTT). Такие характеристики позволяют использовать memcached в высоконагруженных web-проектах для решения различных задач, в том числе и для кэширования данных.

2.1.6Потеря ключей

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

ключ был удален раньше окончания его срока годности в силу нехватки памяти под хранение значений других ключей. Memcached использует политику LRU, поэтому такая потеря означает, что данный ключ редко использовался и память кэша освобождается для хранения более популярных ключей;

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

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

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

«Можно потерять».

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

«Не хотелось бы потерять».

Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано новое значение.

«Совсем не должны терять». удобен для хранения сессий пользователей - все сессии равнодоступны со всех серверов, входящих в кластер frontendов. Так вот содержимое сессий не хотелось бы терять никогда - иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно дублировать ключи сессий на нескольких серверах memcached из кластера, так вероятность потери снижается.

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

Существует много разных вариантов формирования WEB-страниц с использованием кэширования: кэширование HTML, кэширование результатов запросов из БД, кэширование HTML блоков, кэширование опкода, кэширование промежуточных результатов и т.д.

Кэширование осуществляется на разных уровнях, начиная от сохранения в кэше браузера HTML страниц, логотипов и картинок, сохранения HTML-страниц и статического контента (картинки) в прокси-серверах и кэше WEB-сервера.

Кэширование результатов трансляции опкода специальными кэшерами и акселераторами. Применительно к РНР: АРС, XCache, eAccelerator, ZendAccelerator и т.д.

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

2.2Предварительные вычисления

Если вычисления трудоемкие, такие как расчет статистики или подсчет топов/голосов/рейтингов, но нет необходимости ждать первого запроса, чтоб осуществлять вычисления, если есть возможность их подготовить заранее. Незачем тратить столь дорогое процессорное время нагруженного фронт-сервера. Такие, расчетные задачи выполняются по расписанию, cron, или через "сервера задач", на удаленных компьютерах.

Как правило, первое сочетается со вторым. Первоначально рассчитывается некоторая задача, например 10 лучших товаров/блогов/фотографий, формируется набор данных или уже готовый HTML и кладется в кэш.

Далее, фронтэнд, по мере необходимости выбирает нужную информацию из кэша, формирует HTML страницу и отдает запрашиваемому браузеру. В результате имеем 5-10 кратное повышение производительности.

2.2.1А как же это всё использовать

Вся суть HighLoad проектов сводится к принципу "Быстро взял - быстро отдал". Как минимизировать скорость отдачи страницы. Логика отдачи такова:

часть данных выносим в отдельную логику, подготавливать их отдельными скриптами или демонами. Отдавать их отдельными AJAX запросами, а HTML формировать на стороне клиента (браузера). Тем самым мы уменьшаем время на формирование и передачу выходных данных. Такими данными могут быть счетчики сообщений, просмотров, "Что нового у друзей" и так далее;

минимизировать обращение к БД.

2.2.1.1Кэшировать запросы к БД

Например, стоит задача постраничной навигации по списку некоторой выборки: определенной категории товаров или объектов. Классическое решение - это использование в операторе SELECT (на примере MySQL) ключевых слов LIMIT/OFFSET. Для первой страницы выдачи значение LIMIT равно кол-во записей выдачи, как правило, это 10, 20 или 50, а OFFSET равно 0. Для последующих страниц, OFFSET равно (Np -1)* Psize, где Np - номер страницы, Psize = значению LIMIT - размер выдачи на одной странице.

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

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

2.2.1.2Виды кэширования

Выделяют следующие виды кэширования:

данных;

HTML блоков;

страниц целиком.

2.2.1.3Кэширование данных

Обычно хранят сериализованный массив данных. Ключом может быть:

элемент данных запроса в ключевом слове WHERE, например id, наименование категории и прочие. Обычно с префиксом: catid_12321;

значение хеша (md5) от всего текста запроса.

Общий код будет выглядеть так:

$data = cache->get($key);(!$data)

{

$data = db->query($sql);>set($key, $data)

}

2.2.1.4Кэширование блоков

Многие современные фреймворки осуществляют кэширование блоками. Блоком является некий блок вывода, который рассчитывается отдельным бэкенд-контроллером.

Однако можно использовать для кэширования средства ssi (server side include - включение на стороне сервера). В частности в nginx используется следующий подход:

общий HTML собирается как ssi;

каждый блок вызывает не тяжелый php скрипт, который формирует HTML;

после отработки скрипт кладется c некоторым ключом в memcache;

при обращении на внутренний url, который указан в шаблоне-сборщике (ssi шаблоне), идет обращение к модулю ngx_http_memcached. Если данных там нет, HTTP ERROR 404, то происходит переориентирование на внутренний url, который вызывает необходимый PHP скрипт.

2.2.1.5Кэширование страниц

Можно осуществить кэширование страницы, по принципу кэширования данных, но уже кэшировать результирующий HTML, который формируется бэкендом. Однако, производительней если кэширование будет осуществлять WEB сервер. Обычно кэшируют домашнюю страницу (index.html) и статические наиболее часто запрашиваемые страницы.

2.3Распараллеливание задач

Отдача контента в HighLoad проектах сводится к задаче "как можно быстрее отдать". Как этого достичь:

быстро изъять или рассчитать необходимые данные;

быстро сформировать HTML;

как можно быстрее отдать, полученный HTML.

Как можно быстро собрать данные - это либо изъять уже готовые данные (кэширование). Либо раскидать поиск данных по нескольким машинам, если многочисленные данные у нас распределены по нескольким серверам.

Для поиска в распределенных хранилищах данных используется технология от Google для обработки больших массивов данных MapReduce.

Алгоритм следующий:

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

сформированные пары преобразуются по определенному алгоритму в новые пары «ключ-значение» в соответствии от месторасположения (стадия Map);

эти новые пары группируются по ключу, и для каждого ключа вычисляется новое значение на основе группы промежуточных значений (стадия Reduce).

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

2.4Фоновые вычисления

Отдача и формирование динамического контента - это задача, требующая относительно большого количества процессорного времени. Если в проекте есть задачи, например расчетные или по обработке графики, то их желательно отдать на другие сервера. Обычно это делается через специальные сервера задач или очереди. Например, задачу загрузки медиа контента можно поручить отдельному серверу и не задействовать фронтэнд, используя специальные модули nginx для загрузки файлов: ngx_http_upload_module, ngx_http_upload_progress_module.

2.4.1Сервера задач

Наиболее известным продуктом по распределению задач является Gearman <#"justify">2.4.2Сервера очередей

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

Какие задачи могут решать сервера очередей:

обмен сообщений между клиентами;

новостная лента, всякого рода подписки;

асинхронная обработка фоновых "тяжелых" задач;

обработка медиа контента: фото и видео;

почтовая рассылка;

взаимодействие между приложениями.

Протоколы:

AMQP - Advanced Message Queue Protocol;

STOMP - Simple (or Streaming) Text Oriented Message Protocol;

XMPP - Extensible Messaging and Presence Protocol.

2.4.2.1Сервера очередей software

Простой сервер очередей MemcachedQ, использует memcached протокол get/set, реализован как надстройка над memcached. Простой, эффективный и не требует дополнительных клиентов и библиотек.- (так же ØMQ, ZeroMQ, 0MQ или ZMQ) высокопроизводительный сервер, реализующий протокол AMQP 1.0., ActiveMQ - сервера очередей, реализуют протокол AMQP.- REST надстройка над redis, реализация redis с версии 2.0 имеет возможность работать с подписками.

Очереди в redis реализовались, как работа со списками: писалось (клалось в очередь) в начало списка LPUSH, а читалось с конца спичка (бралось из очереди) RPOP.

2.5Балансировка нагрузки

Балансировка (выравнивание) нагрузки - распределение процесса выполнения заданий между несколькими серверами сети с целью оптимизации использования ресурсов и сокращения времени вычисления.

Производительность Web узла в целом увеличиться, если увеличить количество фронт серверов, с размещением на узле "зеркальных" копий WEB серверов (горизонтальное масштабирование) (рисунок 3). Распределяя общую нагрузку по всем компонентам системы, в итоге сокращается общее время обработки информации, обрабатывая ее на одном из серверов. Кроме увеличения мощности, горизонтальное масштабирование добавляет надежности системе - при выходе из строя одного из серверов, нагрузка будет сбалансирована между работающими и приложение будет жить.

Рисунок 3 - Балансировка WEB-сервера

Типы балансировок:

WEB-сервера;

кластер серверов БД;

кластер кэшей.

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

При получении запроса от клиента, балансировщику нужно определить, какому из WEB-серверов переслать запрос. Алгоритм принятия решения называется методом или стратегией балансировки, наиболее распространенные стратегии:

Round robin. Из доступных серверов строится очередь и балансировщик выбирает первый в очереди. После выполнения запроса сервер перемещается в конец очереди;

меньшее количество соединений. Балансировщик ведет учет количества незакрытых соединений и выбирает тот сервер, у которого таких соединений меньше;

использование "веса" серверов. Каждому серверу в зависимости от мощности присваивается вес, который используется для ранжирования.

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

При балансировке часто возникает проблема хранения сессий, ведь сессия доступна только на создавшем ее сервере, что нужно учитывать в алгоритме перенаправления запроса. Или же хранить сессии на отдельном сервере либо в БД (рисунок 4).

Рисунок 4 - Тривиальная схема балансировщика нагрузки двух WEB-серверов

Для реализации программного балансировщика есть много решений, например:

- Nginx;

Apache + mod_proxy_balancer;

- Прокси сервер.

2.5.1Балансировка серверов БД

Балансировка серверов БД, осуществляется специальными прокси серверами. Для MySQL - это MySQLProxy. Для PostgreSQL это сочетание PgProxy и PgBouncer. Один является пулом соединений, а второй балансировщиком нагрузки.

2.5.2Балансировка КЭШей

Такой продукт, как memcached и redis имеют встроенные средства балансировки.

Если для балансировки WEB запросов и запросов к БД используется алгоритм round-robin.

То для балансировки кэшей используется алгоритм ketama, суть которого в том, чтобы закрепить ключи за серверами и при добавлении нового сервера в кластер кэшей не нарушить распределение ключей по серверам кластера. Например, если номер сервера будет выбираться хаотично (хоть и постоянно при одинаковом количестве серверов memcached), то при добавлении нового сервера ключи изменят свое положение на серверах и закэшированные данные будут потеряны.

Используя ketama можно безболезненно добавлять новые серверы memcached, старые ключи будут лежать на старых серверах. Доступ к данным будет сохранен.

3.Исследование конкретной высоконагруженной системы

3.1Google

3.1.1Статистика

Общее:

ежедневная аудитория Google составляет около 1 миллиарда человек;

- по данным Alexa (Alexa Internet - дочерняя <https://ru.wikipedia.org/wiki/%D0%94%D0%BE%D1%87%D0%B5%D1%80%D0%BD%D0%B5%D0%B5_%D0%BE%D0%B1%D1%89%D0%B5%D1%81%D1%82%D0%B2%D0%BE> компания Amazon.com <https://ru.wikipedia.org/wiki/Amazon.com>, известная своим сайтом, где собирается статистика о посещаемости других сайтов) больше половины аудитории интернета каждый день пользуются Google;

по данным IWS аудитория интернета составляет 2.1 миллиарда человек;

используется более 900 тысяч серверов;

планируется расширение до 10 миллионов серверов в обозримом будущем;

12 основных датацентров в США <https://www.insight-it.ru/goto/4cb67b65/>, присутствие в большом количестве точек по всему миру (более 38);

около 32 тысяч сотрудников в 76 офисах по всему миру.

Поиск:

за последние 14 лет среднее время обработки одного поискового запроса уменьшилось с 3 секунд до менее 100 миллисекунд, то есть в 30 раз;

более 40 миллиардов страниц в индексе, если приравнять каждую к листу А4 они бы покрыли территорию США в 5 слоев;

более 1 квинтиллиона уникальных URL (10 в 18 степени); если распечатать их в одну строку, её длина составит 51 миллион километров, треть расстояния от Земли до Солнца;

в интернете встречается примерно 100 квинтиллионов слов, чтобы набрать их на клавиатуре одному человеку потребовалось бы примерно 5 миллионов лет;

проиндексировано более 1.5 миллиардов изображений, чтобы их сохранить потребовалось бы 112 миллионов дискет, которые можно сложить в стопку высотой 391 километр.:

активных пользователей более 170 миллионов;

при текущем темпе роста аудитории GMail и конкурентов, он станет лидером рынка через 2-3 года.+:

более 110 миллионов пользователей на март 2015, при запуске в июне 2011;

25 миллионов пользователей за первый месяц;

70:30 примерное соотношение мужчин и женщин;

себестоимость разработки больше полумиллиарда долларов.:

загружается более 13 миллионов часов видео в год;

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

более 700 миллиардов просмотров видео в год;

месячная аудитория составляет 800 миллионов уникальных посетителей;

несколько тысяч полнометражных фильмов в YouTube Movies <https://www.insight-it.ru/goto/18cd7d94/>;

более 10% всех видео в формате HD;

13% просмотров (400 миллионов в день) происходит с мобильных устройств;

до сих пор работает в убыток, лишь 14% просмотров видео приносят выручку с рекламы.

Финансы:

выручка порядка 36 миллиардов долларов в год;

прибыль после налогов порядка 10 миллиардов долларов в год;

капитализация порядка 200 миллиардов долларов.

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

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

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

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

3.1.3Оборудование

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

В традиционных датацентрах потребление электричества серверами примерно равно его потреблению остальной инфраструктурой, Google же удалось снизить процент использования дополнительной электроэнергии до 14% (рисунок 5).

Рисунок 5 - Использование электроэнергии Google

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

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

в датацентрах Google тепло, что позволяет экономить на охлаждении;

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

Google умеет охлаждать датацентры практически без кондиционеров, с использованием воды.

В Google активно пропагандируют максимальное использование возобновляемой энергии. Для этого заключаются долгосрочные соглашения с её поставщиками (на 20 и более лет), что позволяет отрасли активно развиваться и наращивать мощности. Проекты по генерации возобновляемой энергии, спонсируемые Google, имеют суммарную мощность более 1.7 гигаватт, что существенно больше, чем используется для работы Google. Этой мощности хватило бы для обеспечения электричеством 350 тысяч домов.

Если говорить о жизненном цикле оборудования, то используются следующие принципы:

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

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

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

резервное питание, интегрированное в блок питания сервера <https://www.insight-it.ru/goto/ca5b8b43/>, обеспеченное стандартными 12V батарейками;

"Серверный сендвич" <https://www.insight-it.ru/goto/c7f3ff41/>, где материнские платы с двух сторон окружают водяную систему теплоотвода в центре стойки;

датацентр из контейнеров <https://www.insight-it.ru/goto/8dc33e81/>.

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

3.1.4Платформа

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

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

- Google File System <https://www.insight-it.ru/goto/479dfa95/>: распределенная файловая система, состоящая из сервера с метаданными и теоретически неограниченного количества серверов, хранящих произвольные данные в блоках фиксированного размера;

BigTable <https://www.insight-it.ru/goto/f56e059a/>: распределенная база данных, использующая для доступа к данным две произвольных байтовых строки-ключа (обозначающие строку и столбец) и дату/время (обеспечивающие версионность);

MapReduce <https://www.insight-it.ru/goto/dbd8fea6/>: механизм распределенной обработки больших объемов данных, оперирующий парами ключ-значение для получения требуемой информации. Взаимодействие всех этих слоев изображено ниже (рисунок 6).

Рисунок 6 - Схема работы трех основных слоев платформы Google

Google File System (GFS) - распределенная файловая система <https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0>, созданная компанией Google <https://ru.wikipedia.org/wiki/Google_(%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D1%8F)> в 2000 году для своих внутренних потребностей. Используемая реализация является коммерческой тайной <https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D1%82%D0%B0%D0%B9%D0%BD%D0%B0> компании Google, однако общие принципы построения системы были опубликованы в 2003 году. Несовместима с POSIX <https://ru.wikipedia.org/wiki/POSIX>, тесно интегрирована с MapReduce <https://ru.wikipedia.org/wiki/MapReduce>. Обновленная GFS второй версии (2009 год) имеет кодовое название Colossus.- кластерная <https://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80_(%D0%B3%D1%80%D1%83%D0%BF%D0%BF%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BE%D0%B2)> система, оптимизированная для центрального хранилища данных <https://ru.wikipedia.org/wiki/%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B5_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85> Google и нужд поискового механизма <https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B8%D1%81%D0%BA%D0%BE%D0%B2%D0%B0%D1%8F_%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%D0%B0>, обладающая повышенной защитой от сбоев. Система предназначена для взаимодействия между вычислительными системами, а не между пользователем <https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C> и вычислительной системой.

Вся информация копируется и хранится в трёх (или более) местах одновременно, при этом система способна очень быстро находить реплицированные копии <https://ru.wikipedia.org/wiki/%D0%94%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B0%D1%82>, если какая-то машина вышла из строя. Задачи автоматического восстановления после сбоя решаются с помощью программ, созданных по модели MapReduce <https://ru.wikipedia.org/wiki/MapReduce>.- проприетарная высокопроизводительная база данных <https://ru.wikipedia.org/wiki/%D0%A1%D0%A3%D0%91%D0%94>, построенная на основе Google File System <https://ru.wikipedia.org/wiki/Google_File_System> (GFS), Chubby Lock Service и некоторых других продуктах Google. В настоящий момент не распространяется и не используется за пределами Google

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

Спроектированные с учетом совершенно других требований Интернета пятилетней давности компоненты, составляющие ядро платформы Google, потребовали фундаментальной смены архитектуры индексации и поиска, который был представлен публике под кодовым названием Google Caffeine. Новые, переработанные, версии старых "слоев" также окрестили броскими именами, но резонанса у технической публики они вызвали намного меньше, чем новый поисковый алгоритм в SEO-индустрии (Search Engine Optimization - комплекс мер для поднятия позиций сайта в результатах выдачи <https://ru.wikipedia.org/wiki/SERP> поисковых систем <https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B8%D1%81%D0%BA%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0>) (рисунок 7).

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

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

3.1.4.1Google Colossus

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

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

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

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

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

3.1.4.2Google Percolator

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

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

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

Веб-документы или любые другие данные изменяются/добавляются в систему посредством модифицированного API BigTable, а дальнейшие изменения в остальной базе осуществляются посредством механизма "обозревателей". Если говорить в терминах реляционных СУБД, то обозреватели - что-то среднее между триггерами и хранимыми процедурами. Обозреватели представляют собой подключаемый к базе данных код (на C++ <https://www.insight-it.ru/tag/c/>), который исполняется в случае возникновении изменений в определенных колонках. Все используемые системой метаданные также хранятся в специальных колонках BigTable. При использовании Percolator все изменения происходят в транзакциях, удовлетворяющих принципу ACID, каждая из которых затрагивает именно те сервера в кластере, на которых необходимо внести изменения. Механизм транзакций на основе BigTable разрабатывался в рамках отдельного проекта под названием Google Megastore <https://www.insight-it.ru/storage/2011/google-megastore/>.

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

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

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

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

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

3.1.4.3Google Spanner

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Платформа Google в конечном итоге сводится к набору сетевых сервисов и библиотек для доступа к ним из различных языков программирования (в основном используются C/C++ <https://www.insight-it.ru/tag/c/>, Java <https://www.insight-it.ru/tag/java/>, Python <https://www.insight-it.ru/tag/python/> и Perl <https://www.insight-it.ru/tag/perl/>). Каждый продукт, разрабатываемый Google, в большинстве случаев использует эти библиотеки для осуществления доступа к данным, выполнения комплексных вычислений и других задач, вместо стандартных механизмов, предоставляемых операционной системой, языком программирования или opensource библиотеками.

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

GWT <https://www.insight-it.ru/goto/f5686a9/> (Google Web Toolkit - свободный Java-фреймворк для AJAX-приложений) для реализации пользовательских интерфейсов на Java <https://www.insight-it.ru/tag/java/>;

Closure <https://www.insight-it.ru/goto/7f9cb797/> - набор инструментов для работы с JavaScript <https://www.insight-it.ru/tag/javascript/>;

Protocol Buffers <https://www.insight-it.ru/goto/41604156/> - не зависящий от языка программирования и платформы формат бинарной сериализации структурированных данных, используется при взаимодействии большинства компонентов системы внутри Google;

LevelDB <https://www.insight-it.ru/goto/bb496d06/> - высокопроизводительная встраиваемая СУБД <https://www.insight-it.ru/tag/subd/>;

Snappy <https://www.insight-it.ru/goto/44c46d8/> - быстрая компрессия данных, используется при хранении данных в GFS.

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

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

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

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

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

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

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

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

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

3.2Вконтакте

Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции HighLoad++ <https://www.insight-it.ru/event/2010/highload-2010/> ответили на шквал вопросов по совершенно разным аспектам работы Вконтакте <https://www.insight-it.ru/goto/1a5d3494/>, в том числе и техническим.

3.2.1Платформа

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

- Debian <https://www.insight-it.ru/tag/debian/>Linux <https://www.insight-it.ru/tag/linux/> - основная операционная система;

nginx <https://www.insight-it.ru/tag/nginx/> - балансировка нагрузки;

PHP <https://www.insight-it.ru/tag/php/> + XCache <https://www.insight-it.ru/tag/xcache/>;

- Apache <https://www.insight-it.ru/tag/apache/> + mod_php <https://www.insight-it.ru/tag/mod_php/>;

memcached <https://www.insight-it.ru/tag/memcached/>;

MySQL <https://www.insight-it.ru/tag/mysql/>;

- собственная СУБД на <https://www.insight-it.ru/tag/c/>, созданная "лучшими умами" России;

node.js <https://www.insight-it.ru/tag/node-js/> - прослойка для реализации XMPP, живет за HAProxy <https://www.insight-it.ru/tag/haproxy/>;

изображения отдаются просто с файловой системы xfs <https://www.insight-it.ru/tag/xfs/>;

ffmpeg <https://www.insight-it.ru/tag/ffmpeg/> - конвертирование видео.

3.2.2Статистика

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

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

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

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

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

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

- более 10 тысяч серверов, из которых только 32 - фронтенды на nginx <https://www.insight-it.ru/tag/nginx/> (количество серверов с Apache <https://www.insight-it.ru/tag/apache/> неизвестно);

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

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

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

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

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

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

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

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

- генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook <https://www.insight-it.ru/tag/facebook/>, основное отличие - использование собственной СУБД вместо MySQL;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CDN <https://www.insight-it.ru/tag/cdn/> (Content Delivery Network - сеть доставки контента) на данный момент не используется, но в планах возможно его использование;

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

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

Этому продукту, уделялось максимум внимания аудитории на конференции HighLoad++ <https://www.insight-it.ru/event/2010/highload-2010/>, но при этом почти никаких подробностей о том, что он, собственно говоря, собой представляет, так и не было обнародовано.

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

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

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

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

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

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

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

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

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

в) статусы;

г) поиск;

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

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

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

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

интерфейс доступа представляет собой расширенный протокол memcached <https://www.insight-it.ru/tag/memcached/>, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса);

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

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

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

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

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

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

3.2.3.4XMPP

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

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

- реализован на node.js <https://www.insight-it.ru/tag/node-js/> (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи);

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

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

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

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

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

HAProxy <https://www.insight-it.ru/tag/haproxy/> обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий;

данные хранятся в MySQL <https://www.insight-it.ru/tag/mysql/>;

сервис работает на 5 серверах разной конфигурации, на каждом из них работает код на node.js <https://www.insight-it.ru/tag/node-js/> (по 4 процесса на сервер), а на трех самых мощных - еще и MySQL <https://www.insight-it.ru/tag/mysql/>;

в node.js <https://www.insight-it.ru/tag/node-js/> большие проблемы с использованием OpenSSL <https://www.insight-it.ru/tag/openssl/>, а также происходят утечки памяти;

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

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

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

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

- кросс-постинг статусов в Twitter <https://www.insight-it.ru/tag/twitter/>, реализованный с помощью очередей запросов;

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

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

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

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

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

- ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для Debian <https://www.insight-it.ru/tag/debian/>;

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

есть много доработок над memcached <https://www.insight-it.ru/tag/memcached/>, в том числе для более стабильного и длительного размещения объектов в памяти;

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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