Что мы увидим в архитектуре интернет-гиганта?
В отличии от большинства интернет-компаний, которые занимаются лишь одним продуктом (проектом), архитектура Google не может быть представлена как единое конкретное техническое решение. Сегодня мы скорее будем рассматривать общую стратегию технической реализации интернет-проектов в Google, возможно слегка затрагивая и другие аспекты ведения бизнеса в Интернет.
Все продукты Google основываются на постоянно развивающейся программной платформе, которая спроектирована с учетом работы на миллионах серверов, находящихся в разных датацентрах по всему миру.
В традиционных датацентрах потребление электричества серверами
примерно равно его потреблению остальной инфраструктурой, Google же
удалось снизить процент использования дополнительной электроэнергии до
14%. Таким образом суммарное энергопотребление датацентром Google
сравнимо с потреблением только серверов в типичном датацентре и вдвое
меньше его общего энергопотребления. Основные концепции, которые
используются для достижения этого результата:
Если говорить о жизненном цикле оборудования, то используются следующие принципы:
Основными задачами в ранние годы была минимизация точек отказа и обработка больших объемов слабоструктурированных данных. Решением этих задач стали три основных слоя платформы Google, работающие один поверх другого:
Спроектированные с учетом совершенно других требований Интернета пятилетней давности компоненты, составляющие ядро платформы Google, потребовали фундаментальной смены архитектуры индексации и поиска, который около года назад был представлен публике под кодовым названием Google Caffeine. Новые, переработанные, версии старых «слоев» также окрестили броскими именами, но резонанса у технической публики они вызвали намного меньше, чем новый поисковый алгоритм в SEO-индустрии.
В оригинальной же реализации упор был сделан на повышение общей пропускной способности: операции объединялись в очереди и выполнялись разом, при таком подходе можно было прождать пару секунд еще до того, как первая операция в очереди начнет выполняться. Помимо этого в старой версии было большое слабое место в виде единственно мастер-сервера с метаданными, сбой в котором грозил недоступностью всей файловой системы в течении небольшого промежутка времени (пока другой сервер не подхватит его функции, изначально это занимало около 5 минут, в последних версиях порядка 10 секунд) — это также было вполне допустимо при отсутствии требования работы в реальном времени, но для приложений, напрямую взаимодействующих с пользователями, это было неприемлемо с точки зрения возможных задержек.
Основным нововведением в Colossus стали распределенные мастер-сервера, что позволило избавиться не только от единственной точки отказа, но и существенно уменьшить размер одного блока с данными (с 64 до 1 мегабайта), что в целом очень положительно сказалось на работе с небольшими объемами данных. В качестве бонуса исчез теоретический предел количества файлов в одной системе.
Детали распределения ответственности между мастер-серверами, сценариев реакции на сбои, а также сравнение по задержкам и пропускной способности обоих версий, к сожалению, по-прежнему конфиденциальны. Могу предположить, что используется вариация на тему хэш-кольца с репликацией метаданных на ~3 мастер-серверах, с созданием дополнительной копии на следующем по кругу сервере в случае в случае сбоев, но это лишь догадки. Если у кого-то есть относительно официальная информация на этот счет — буду рад увидеть в комментариях.
По прогнозам Google текущий вариант реализации распределенной файловой системы «уйдет на пенсию» в 2014 году из-за популяризации твердотельных накопителей и существенного скачка в области вычислительных технологий (процессоров).
Ключевые архитектурные решения, лежащие в основе MapReduce, не позволяли повлиять на эту особенность и в итоге система индексации была построена заново с нуля, а MapReduce продолжает использоваться в других проектах Google для аналитики и прочих задач, по прежнему не связанных с реальным временем.
Новая система получила довольно своеобразное название Percolator, попытки узнать что оно значит приводит к различным устройствам по фильтрации дыма, кофеваркам и непойми чему еще. Но наиболее адекватное объяснение мне пришло в голову, когда я прочитал его по слогам: per col — по колонкам.
Percolator представляет собой надстройку над BigTable, позволяющую выполнять комплексные вычисления на основе имеющихся данных, затрагивающие много строк и даже таблиц одновременно (в стандартном API BigTable это не предусмотрено).
Веб-документы или любые другие данные изменяются/добавляются в систему посредством модифицированного API BigTable, а дальнейшие изменения в остальной базе осуществляются посредством механизма »обозревателей». Если говорить в терминах реляционных СУБД, то обозреватели — что-то среднее между триггерами и хранимыми процедурами. Обозреватели представляют собой подключаемый к базе данных код (на C++), который исполняется в случае возникновении изменений в определенных колонках BigTable (откуда, видимо, и пошло название). Все используемые системой метаданные также хранятся в специальных колонках BigTable. При использовании Percolator все изменения происходят в транзакциях, удовлетворяющих принципу ACID, каждая из которых затрагивает именно те сервера в кластере, на которых необходимо внести изменения. Механизм транзакций на основе BigTable разрабатывался в рамках отдельного проекта под названием Google Megastore.
Таким образом, при добавлении нового документа (или его версии) в поисковый индекс, вызывается цепная реакция изменений в старых документах, скорее всего ограниченная по своей рекурсивности. Эта система при осуществлении случайного доступа поддерживает индекс в актуальном состоянии.
В качестве бонуса в этой схеме удалось избежать еще двух недостатков MapReduce:
Тем не менее, при выбранной архитектуре Google удалось достичь практически линейного масштабирования при увеличении вычислительных мощностей на много порядков (см. график, основан на тесте TPC-E). Дополнительные накладные расходы, связанные с распределенной природой решения, в некоторых случаях до 30 раз превосходят аналогичный показатель традиционных СУБД, но у данной системы есть солидный простор для оптимизации в этом направлении, чем Google активно и занимается.
Основные особенности:
Вышеизложенные проекты составляют лишь основу платформы Google, хотя она включает в себя куда больше готовых решений и библиотек, несколько примеров из публично доступных проектов:
Поправки и уточнения приветствуются
- Статистика
- Архитектура
- Оборудование
- Платформа
Статистика
- Общее
- Ежедневная аудитория Google составляет около 1 миллиарда человек
- По данным Alexa больше половины аудитории интернета каждый день пользуются Google
- По данным IWS аудитория интернета составляет 2.1 миллиарда человек
- Используется более 900 тысяч серверов
- Планируется расширение до 10 миллионов серверов в обозримом будущем
- 12 основных датацентров в США, присутствие в большом количестве точек по всему миру (более 38)
- Около 32 тысяч сотрудников в 76 офисах по всему миру
- Ежедневная аудитория Google составляет около 1 миллиарда человек
- Поиск
- За последние 14 лет среднее время обработки одного поискового запроса уменьшилось с 3 секунд до менее 100 миллисекунд, то есть в 30 раз
- Более 40 миллиардов страниц в индексе, если приравнять каждую к листу А4 они бы покрыли территорию США в 5 слоев
- Более 1 квинтиллиона уникальных URL (10 в 18 степени); если распечатать их в одну строку, её длина составит 51 миллион километров, треть расстояния от Земли до Солнца
- В интернете встречается примерно 100 квинтиллионов слов, чтобы набрать их на клавиатуре одному человеку потребовалось бы примерно 5 миллионов лет
- Проиндексировано более 1.5 миллиардов изображений, чтобы их сохранить потребовалось бы 112 миллионов дискет, которые можно сложить в стопку высотой 391 километр
- Gmail
- Активных пользователей более 170 миллионов
- Второй по популярности почтовый сервис в США, третий в мире (по данным comScore)
- При текущем темпе роста аудтории GMail и конкурентов, он станет лидером рынка через 2-3 года
- Google+
- Более 40 миллионов пользователей на октябрь 2011, при запуске в июне 2011
- 25 миллионов пользователей за первый месяц
- 70:30 примерное соотношение мужчин и женщин
- Себестоимость разработки больше полумиллиарда долларов
- YouTube
- Загружается более 13 миллионов часов видео в год
- Каждую минуту загружается 48 часов видео, что соответствует почти 8 годам контента или 52 тысячам полнометражных фильмов в день
- Более 700 миллиардов просмотров видео в год
- Месячная аудитория составляет 800 миллионов уникальных посетителей
- Несколько тысяч полнометражных фильмов в YouTube Movies
- Более 10% всех видео в формате HD
- 13% просмотров (400 миллионов в день) происходит с мобильных устройств
- До сих пор работает в убыток, лишь 14% просмотров видео приносят выручку с рекламы
- Финансы
- Выручка порядка 36 миллиардов долларов в год
- Прибыль после налогов порядка 10 миллиардов долларов в год
- Капитализация порядка 200 миллиардов долларов
Архитектура
Google — огромная интернет-компания, неоспоримый лидер на рынке поиска в Интернет и владелец большого количества продуктов, многие из которых также добились определенного успеха в своей нише.В отличии от большинства интернет-компаний, которые занимаются лишь одним продуктом (проектом), архитектура Google не может быть представлена как единое конкретное техническое решение. Сегодня мы скорее будем рассматривать общую стратегию технической реализации интернет-проектов в Google, возможно слегка затрагивая и другие аспекты ведения бизнеса в Интернет.
Все продукты Google основываются на постоянно развивающейся программной платформе, которая спроектирована с учетом работы на миллионах серверов, находящихся в разных датацентрах по всему миру.
Оборудование
Обеспечение работы миллиона серверов и расширение их парка — одна из ключевых статей расходов Google. Для минимизации этих издержек очень большое внимание уделяется эффективности используемого серверного, сетевого и инфраструктурного оборудования.- Точное измерение потребления электроэнергии всеми компонентами позволяет определить возможности по его уменьшению;
- В датацентрах Google тепло, что позволяет экономить на охлаждении;
- При проектировании датацентра уделяется внимание даже незначительным деталям, позволяющим сэкономить даже немного — при таком масштабе это окупается;
- Google умеет охлаждать датацентры практически без кондиционеров, с использованием воды и её испарения (см. как это реализовано в Финляндии).
Если говорить о жизненном цикле оборудования, то используются следующие принципы:
- Уменьшение транспортировки: там, где это возможно, тяжелые компоненты (вроде серверных стоек) закупаются у местных поставщиков, даже если в других местах аналогичный товар можно было бы купить дешевле.
- Повторное использование: прежде, чем покупать новое оборудование и материалы, рассматриваются возможности по использованию уже имеющихся. Этот принцип помог избежать покупки более 90 тысяч новых серверов.
- Утилизация: в тех случаях, когда повторное использование невозможно, оборудование полностью очищается от данных и продается на вторичном рынке. То, что не удается продать, разбирается на материалы (медь, сталь, алюминий, пластик и.т.п.) для последующей правильной утилизации специализированными компаниями.
- Резервное питание, интегрированное в блок питания сервера, обеспеченное стандартными 12V батарейками;
- «Серверный сендвич», где материнские платы с двух сторон окружают водяную систему теплоотвода в центре стойки;
- Датацентр из контейнеров.
Платформа
В Google очень рано столкнулись с проблемами ненадежности оборудования и работы с огромными массивами данных. Программная платформа, спроектированная для работы на многих недорогих серверах, позволила им абстрагироваться от сбоев и ограничений одного сервера.Основными задачами в ранние годы была минимизация точек отказа и обработка больших объемов слабоструктурированных данных. Решением этих задач стали три основных слоя платформы Google, работающие один поверх другого:
- Google File System: распределенная файловая система, состоящая из сервера с метаданными и теоретически неограниченного количества серверов, хранящих произвольные данные в блоках фиксированного размера.
- BigTable: распределенная база данных, использующая для доступа к данным две произвольных байтовых строки-ключа (обозначающие строку и столбец) и дату/время (обеспечивающие версионность).
- MapReduce: механизм распределенной обработки больших объемов данных, оперирующий парами ключ-значение для получения требуемой информации.
Спроектированные с учетом совершенно других требований Интернета пятилетней давности компоненты, составляющие ядро платформы Google, потребовали фундаментальной смены архитектуры индексации и поиска, который около года назад был представлен публике под кодовым названием Google Caffeine. Новые, переработанные, версии старых «слоев» также окрестили броскими именами, но резонанса у технической публики они вызвали намного меньше, чем новый поисковый алгоритм в SEO-индустрии.
Google Colossus
Новая архитектура GFS была спроектирована для минимизации задержек при доступе к данным (что критично для приложений вроде GMail и YouTube), не в ущерб основным свойствам старой версии: отказоустойчивости и прозрачной масштабируемости.В оригинальной же реализации упор был сделан на повышение общей пропускной способности: операции объединялись в очереди и выполнялись разом, при таком подходе можно было прождать пару секунд еще до того, как первая операция в очереди начнет выполняться. Помимо этого в старой версии было большое слабое место в виде единственно мастер-сервера с метаданными, сбой в котором грозил недоступностью всей файловой системы в течении небольшого промежутка времени (пока другой сервер не подхватит его функции, изначально это занимало около 5 минут, в последних версиях порядка 10 секунд) — это также было вполне допустимо при отсутствии требования работы в реальном времени, но для приложений, напрямую взаимодействующих с пользователями, это было неприемлемо с точки зрения возможных задержек.
Основным нововведением в Colossus стали распределенные мастер-сервера, что позволило избавиться не только от единственной точки отказа, но и существенно уменьшить размер одного блока с данными (с 64 до 1 мегабайта), что в целом очень положительно сказалось на работе с небольшими объемами данных. В качестве бонуса исчез теоретический предел количества файлов в одной системе.
Детали распределения ответственности между мастер-серверами, сценариев реакции на сбои, а также сравнение по задержкам и пропускной способности обоих версий, к сожалению, по-прежнему конфиденциальны. Могу предположить, что используется вариация на тему хэш-кольца с репликацией метаданных на ~3 мастер-серверах, с созданием дополнительной копии на следующем по кругу сервере в случае в случае сбоев, но это лишь догадки. Если у кого-то есть относительно официальная информация на этот счет — буду рад увидеть в комментариях.
По прогнозам Google текущий вариант реализации распределенной файловой системы «уйдет на пенсию» в 2014 году из-за популяризации твердотельных накопителей и существенного скачка в области вычислительных технологий (процессоров).
Google Percolator
MapReduce отлично справлялся с задачей полной перестройки поискового индекса, но не предусматривал небольшие изменения, затрагивающие лишь часть страниц. Из-за потоковой, последовательной природы MapReduce для внесения изменений в небольшую часть документов все равно пришлось бы обновлять весь индекс, так как новые страницы непременно будут каким-то образом связаны со старыми. Таким образом задержка между появлением страницы в Интернете и в поисковом индексе при использовании MapReduce была пропорциональна общему размеру индекса (а значит и Интернета, который постоянно растет), а не размеру набора измененных документов.Ключевые архитектурные решения, лежащие в основе MapReduce, не позволяли повлиять на эту особенность и в итоге система индексации была построена заново с нуля, а MapReduce продолжает использоваться в других проектах Google для аналитики и прочих задач, по прежнему не связанных с реальным временем.
Новая система получила довольно своеобразное название Percolator, попытки узнать что оно значит приводит к различным устройствам по фильтрации дыма, кофеваркам и непойми чему еще. Но наиболее адекватное объяснение мне пришло в голову, когда я прочитал его по слогам: per col — по колонкам.
Percolator представляет собой надстройку над BigTable, позволяющую выполнять комплексные вычисления на основе имеющихся данных, затрагивающие много строк и даже таблиц одновременно (в стандартном API BigTable это не предусмотрено).
Веб-документы или любые другие данные изменяются/добавляются в систему посредством модифицированного API BigTable, а дальнейшие изменения в остальной базе осуществляются посредством механизма »обозревателей». Если говорить в терминах реляционных СУБД, то обозреватели — что-то среднее между триггерами и хранимыми процедурами. Обозреватели представляют собой подключаемый к базе данных код (на C++), который исполняется в случае возникновении изменений в определенных колонках BigTable (откуда, видимо, и пошло название). Все используемые системой метаданные также хранятся в специальных колонках BigTable. При использовании Percolator все изменения происходят в транзакциях, удовлетворяющих принципу ACID, каждая из которых затрагивает именно те сервера в кластере, на которых необходимо внести изменения. Механизм транзакций на основе BigTable разрабатывался в рамках отдельного проекта под названием Google Megastore.
Таким образом, при добавлении нового документа (или его версии) в поисковый индекс, вызывается цепная реакция изменений в старых документах, скорее всего ограниченная по своей рекурсивности. Эта система при осуществлении случайного доступа поддерживает индекс в актуальном состоянии.
В качестве бонуса в этой схеме удалось избежать еще двух недостатков MapReduce:
- Проблемы «отстающих»: когда один из серверов (или одна из конкретных подзадач) оказывался существенно медленнее остальных, что также значительно задерживало общее время завершения работы кластера.
- Пиковая нагрузка: MapReduce не является непрерывным процессом, а разделяется на работы с ограниченной целью и временем исполнения. Таким образом помимо необходимости ручной настройки работ и их типов, кластер имеет очевидные периоды простоя и пиковой нагрузки, что ведет к неэффективному использованию вычислительных ресурсов.
Тем не менее, при выбранной архитектуре Google удалось достичь практически линейного масштабирования при увеличении вычислительных мощностей на много порядков (см. график, основан на тесте TPC-E). Дополнительные накладные расходы, связанные с распределенной природой решения, в некоторых случаях до 30 раз превосходят аналогичный показатель традиционных СУБД, но у данной системы есть солидный простор для оптимизации в этом направлении, чем Google активно и занимается.
Google Spanner
Spanner представляет собой единую систему автоматического управления ресурсами всего парка серверов Google.Основные особенности:
- Единое пространство имен:
- Иерархия каталогов
- Независимость от физического расположения данных
- Поддержка слабой и сильной целостности данных между датацентрами
- Автоматизация:
- Перемещение и добавление реплик данных
- Выполнение вычислений с учетом ограничений и способов использования
- Выделение ресурсов на всех доступных серверах
- Зоны полу-автономного управления
- Восстановление целостности после потерь соединения между датацентрами
- Возможность указания пользователями высокоуровневых требований, например:
- 99% задержек при доступе к этим данным должны быть до 50 мс
- Расположи эти данные на как минимум 2 жестких дисках в Европе, 2 в США и 1 в Азии
- Интеграция не только с серверами, но и с сетевым оборудованием, а также системами охлаждения в датацентрах
- 1-10 миллионов серверов
- ~10 триллионов директорий
- ~1000 петабайт данных
- 100-1000 датацентров по всему миру
- ~1 миллиард клиентских машин
Прочие компоненты платформы
Платформа Google в конечном итоге сводится к набору сетевых сервисов и библиотек для доступа к ним из различных языков программирования (в основном используются C/C++, Java, Python и Perl). Каждый продукт, разрабатываемый Google, в большинстве случаев использует эти библиотеки для осуществления доступа к данным, выполнения комплексных вычислений и других задач, вместо стандартных механизмов, предоставляемых операционной системой, языком программирования или opensource библиотеками.Вышеизложенные проекты составляют лишь основу платформы Google, хотя она включает в себя куда больше готовых решений и библиотек, несколько примеров из публично доступных проектов:
- GWT для реализации пользовательских интерфейсов на Java;
- Closure — набор инструментов для работы с JavaScript;
- Protocol Buffers — не зависящий от языка программирования и платформы формат бинарной сериализации структурированных данных, используется при взаимодействии большинства компонентов системы внутри Google;
- Snappy — быстрая компрессия данных, используется при хранении данных в GFS.
Подводим итоги
- Стабильные, проработанные и повторно используемые базовые компоненты проекта — залог её стремительного развития, а также создания новых проектов на той же кодовой базе.
- Если задачи и обстоятельства, с учетом которых проектировалась система, существенно изменились — не бойтесь вернуться на стадию проектирования и реализовать новое решение.
- Используйте инструменты, подходящие для решения каждой конкретной задачи, а не те, которые навязывает мода или привычки участников команды.
- Даже, казалось бы, незначительные недоработки и допущения на большом масштабе могут вылиться в огромные потери — уделяйте максимум внимания деталям при реализации проекта.
- Нельзя полагаться даже на очень дорогое оборудование — все ключевые сервисы должны работать минимум на двух серверах, в том числе и базы данных.
- Распределенная платформа, общая для всех проектов, позволит новым разработчикам легко вливаться в работу над конкретными продуктами, с минимумом представления о внутренней архитектуре компонентов платформы.
- Прозрачная работа приложений в нескольких датацентрах — одна из самых тяжелых задач, с которыми сталкиваются интернет-компании. Сегодня каждая из них решает её по-своему и держит подробности в секрете, что сильно замедляет развитие opensource решений.
Источники информации
Не гарантирую достоверность всех нижеизложенных источников информации, ставших основой для данной статьи, но ввиду конфиденциальности подобной информации на большее рассчитывать не приходится.Поправки и уточнения приветствуются
- Official Google Data Centers Site
- Challenges in Building Large-Scale Information Retrieval Systems (Jeff Dean, WCDMA '09)
- Designs, Lessons and Advice from Building Large Distributed Systems (Jeff Dean, Ladis '09)
- Google Percolator official paper
- Google Megastore official paper
- Google Percolator
- Google Caffeine Explained
- Google Spanner
- Google Software Infrastructure Dubbed Obsolete by ex-Employee
- Google Moves Off the Google File System
- Google Internet Stats
- Google Statistics
- Google Plus — Killer Facts and Statistics
- YouTube statistics
- Alexa on Google
- Internet World Stats
- Google Inc. financials
- Hotmail still on top worldwide; Gmail gets bigger
- Google Server Count
- Google Envisions 10 Million Servers
- Google Data Center FAQ
Бонус: типичный первый год кластера в Google
- ~½ перегрева (большинство серверов выключаются в течении 5 минут, 1-2 дня на восстановление)
- ~1 отказ распределителя питания (~500-1000 резко пропадают, ~6 часов на восстановление)
- ~1 передвижение стойки (много передвижений, 500-100 машин, 6 часов)
- ~1 перепрокладка сети (последовательной отключение ~5% серверов на протяжении 2 дней)
- ~20 отказов стоек (40-80 машин мгновенно исчезают, 1-6 часов на восстановление)
- ~5 стоек становится нестабильными (40-80 машин сталкиваются с 50% потерей пакетов)
- ~8 запланированных технических работ с сетью (при четырех могут случаться случайные получасовые потери соединения)
- ~12 перезагрузок маршрутизаторов (потеря DNS и внешних виртуальных IP на несколько минут)
- ~3 сбоя маршрутизаторов (восстановление в течении часа)
- Десятки небольших 30-секундных пропаданий DNS
- ~1000 сбоев конкретных серверов (~3 в день)
- Много тысяч сбоев жестких дисков, проблем с памятью, ошибок конфигурации и т.п.