Архитектура Google 2011

Архитектура Google была одной из первых статьей на Insight IT. Именно она дала толчок развитию проекта: после её публикации посещаемость блога увеличилась в десятки раз и появились первые сотни подписчиков. Прошли годы, информация устаревает стремительно, так что пришло время взглянуть на Google еще раз, теперь уже с позиции конца 2011 года. Что мы увидим нового в архитектуре интернет-гиганта?

Статистика

  • Общее
    • Ежедневная аудитория Google составляет около 1 миллиарда человек
      • По данным Alexa больше половины аудитории интернета каждый день пользуются Google
      • По данным IWS аудитория интернета составляет 2.1 миллиарда человек
    • Используется более 900 тысяч серверов
      • Планируется расширение до 10 миллионов серверов в обозримом будущем
    • 12 основных датацентров в США, присутствие в большом количестве точек по всему миру (более 38)
    • Около 32 тысяч сотрудников в 76 офисах по всему миру
  • Поиск
    • За последние 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 же удалось снизить процент использования дополнительной электроэнергии до 14%. Таким образом суммарное энергопотребление датацентром Google сравнимо с потреблением только серверов в типичном датацентре и вдвое меньше его общего энергопотребления. Основные концепции, которые используются для достижения этого результата:

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

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

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

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

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

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

Платформа

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

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

  • Google File System: распределенная файловая система, состоящая из сервера с метаданными и теоретически неограниченного количества серверов, хранящих произвольные данные в блоках фиксированного размера.
  • BigTable: распределенная база данных, использующая для доступа к данным две произвольных байтовых строки-ключа (обозначающие строку и столбец) и дату/время (обеспечивающие версионность).
  • MapReduce: механизм распределенной обработки больших объемов данных, оперирующий парами ключ-значение для получения требуемой информации.

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

Спроектированные с учетом совершенно других требований Интернета пятилетней давности компоненты, составляющие ядро платформы 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 не является непрерывным процессом, а разделяется на работы с ограниченной целью и временем исполнения. Таким образом помимо необходимости ручной настройки работ и их типов, кластер имеет очевидные периоды простоя и пиковой нагрузки, что ведет к неэффективному использованию вычислительных ресурсов.

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

Google Percolator Benchmark

Тем не менее, при выбранной архитектуре Google удалось достичь практически линейного масштабирования при увеличении вычислительных мощностей на много порядков (см. график, основан на тесте TPC-E). Дополнительные накладные расходы, связанные с распределенной природой решения, в некоторых случаях до 30 раз превосходят аналогичный показатель традиционных СУБД, но у данной системы есть солидный простор для оптимизации в этом направлении, чем Google активно и занимается.

Google Spanner

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

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

  • Единое пространство имен:
    • Иерархия каталогов
    • Независимость от физического расположения данных
  • Поддержка слабой и сильной целостности данных между датацентрами
  • Автоматизация:
    • Перемещение и добавление реплик данных
    • Выполнение вычислений с учетом ограничений и способов использования
    • Выделение ресурсов на всех доступных серверах
  • Зоны полу-автономного управления
  • Восстановление целостности после потерь соединения между датацентрами
  • Возможность указания пользователями высокоуровневых требований, например:
    • 99% задержек при доступе к этим данным должны быть до 50 мс
    • Расположи эти данные на как минимум 2 жестких дисках в Европе, 2 в США и 1 в Азии
  • Интеграция не только с серверами, но и с сетевым оборудованием, а также системами охлаждения в датацентрах

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

  • 1-10 миллионов серверов
  • ~10 триллионов директорий
  • ~1000 петабайт данных
  • 100-1000 датацентров по всему миру
  • ~1 миллиард клиентских машин

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

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

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

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

  • GWT для реализации пользовательских интерфейсов на Java;
  • Closure - набор инструментов для работы с JavaScript;
  • Protocol Buffers - не зависящий от языка программирования и платформы формат бинарной сериализации структурированных данных, используется при взаимодействии большинства компонентов системы внутри Google;
  • LevelDB - высокопроизводительная встраиваемая СУБД;
  • Snappy - быстрая компрессия данных, используется при хранении данных в GFS.

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

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

Источники информации

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

Поправки и уточнения приветствуются :)

Бонус: типичный первый год кластера в Google

  • ~1/2 перегрева (большинство серверов выключаются в течении 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 в день)
  • Много тысяч сбоев жестких дисков, проблем с памятью, ошибок конфигурации и т.п.
28 ноября 2011 |  Иван Блинков  |  Высокие нагрузки
BigTable   Caffeine   Closure   GFS   Google   GWT   highload   Percolator   Protocol Buffers   Snappy   Spanner   архитектура Google   датацентры   Масштабируемость   энергоэффективность  
Иван Блинков