Статистика

• Общее
  • Ежедневная аудитория 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 миллиардов долларов в год
  • Капитализация порядка 55 миллиардов долларов

Архитектура

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

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

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

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

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

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

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

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

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

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

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

• Резервное питание, интегрированное в блок питания сервера, обеспеченное стандартными 12V батарейками;
• «Серверный сендвич», где материнские платы с двух сторон окружают водяную систему теплоотвода в центре стойки;
• Датацентр из контейнеров.

В заключении этого раздела хотелось бы взглянуть правде в глаза: идеального оборудования не бывает. У любого современного устройства, будь то сервер, коммутатор или маршрутизатор, есть шанс прийти в негодность из-за производственного брака, случайного стечения обстоятельств или других внешних факторов. Если умножить этот, казалось бы, небольшой шанс на количество оборудования, которое используется в 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 удалось достичь практически линейного масштабирования при увеличении вычислительных мощностей на много порядков (см. график, основан на тесте 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;
• 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

• ~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 в день)
• Много тысяч сбоев жестких дисков, проблем с памятью, ошибок конфигурации и т.п.

Недавно несколько человек довольно независимо друг от друга подтолкнули меня к новой странице-рубрике на Insight IT. Как не трудно догадаться по заголовку, это F.A.Q. по высоконагруженным проектам и связанным темам.

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

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

Платформа

• Windows и openSUSE — основные операционные системы
• Java — основной язык программирования
• С/С++ — для некоторых модулей
• GWT — реализация динамического веб-интерфейса
• Apache Tomcat — сервера приложений
• JBoss 4 — сервера бизнес-логики
• LVS и IPVS — балансировка нагрузки
• MS SQL 2005 и 2008 — основная СУБД
• BerkleyDB — дополнительная СУБД
• Apache Lucene — индексация и поиск текстовой информации

Статистика

• До 2.8 млн. пользователей онлайн в часы пик
• 7,5 миллиардов запросов в день (150 000 запросов в секунду в часы пик)
• 2 400 серверов и систем хранения данных, из которых 150 являются веб-серверами
• Сетевой трафик в час пик: 32 Gb/s

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

Сервера используются двухпроцессорные с 4 ядрами, объемом памяти от 4 до 48 Гб. В зависимости от роли сервера данные хранятся либо в памяти, либо на дисках, либо на внешних системах хранения данных.

Все оборудование размещено в 3 датацентрах, объединенных в оптическое кольцо. На данный момент на каждом из маршрутов пропускная способность составляет 30Гбит/с. Каждый из маршрутов состоит из физически независимых друг от друга оптоволоконных пар, которые агрегируются в общую “трубу” на корневых маршрутизаторах.

Сеть физически разделена на внутреннюю и внешнюю, разные интерфейсы серверов подключены в разные коммутаторы и работают в разных сетях. По внешней сети HTTP сервера, общаются с Интернетом, по внутренней сети все сервера общаются между собой. Топология внутренней сети – звезда. Сервера подключены в L2 коммутаторы (access switches), которые, в свою очередь, подключены как минимум двумя гигабитными линками к aggregation стеку маршрутизаторов. Каждый линк идет к отдельному коммутатору в стеке. Для того, чтобы эта схема работала, используеться протокол RSTP. При необходимости, подключения access коммутаторов к agregation стеку осуществляются более чем двумя линками с использованием link aggregation портов. Aggregation коммутаторы подключены 10Гб линками в корневые маршрутизаторы, которые обеспечивают как связь между датацентрами, так и связь с внешним миром. Используются коммутаторы и маршрутизаторы от компании Cisco.

Для связи с внешним миром используются прямые подключения с несколькими крупнейшими операторами связи, общий сетевой трафик в часы пик доходит до 32Гбит/с.

Архитектура

Архитектура проекта имеет традиционную многоуровневую структуру:

• презентационный уровень;
• уровень бизнес-логики;
• уровень кэширования;
• уровень баз данных;
• уровень инфраструктуры (логирование, конфигурация и мониторинг).

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

Презентационный уровень

• Используем собственный фреймворк, позволяющий строить композицию страниц на языке Jаvа, с использованием собственные GUI фабрик (для оформления текста, списков, таблиц и портлетов).
• Страницы состоят из независимых блоков (обычно портлетов), что позволяет обновлять информацию на них частями с помощью AJAX запросов.
• При данном подходе одновременно обеспечивается минимум перезагрузок страниц для пользователей с включенным JavaScript, так и полная работоспособность сайта для пользователей, у которых он отключен.
• Google Web Toolkit используется для реальзации функциональные компонент, таких как Сообщения, Обсуждения и Оповещения, а также все динамических элементов (меню шорткатов, метки на фотографиях, сортировка фотографий, ротация подарков и.т.д.). В GWT используются UIBinder и HTMLPanel для создания интерфейсов.
• Кешируются все внешние ресурсы (Expires и Cache-Control заголовки). CSS и JavaScript файлы минимизируются и сжимаются (gzip).
• Для уменьшения количества HTTP запросов с браузера, все JavaScript и CSS файлы объединяются в один. Маленькие графические изображения объединяются в спрайты.
• При загрузке страницы скачиваются только те ресурсы, которые на самом деле необходимы для начала работы.
• Никаких универсальных CSS селекторов. Стараются не использовать типовые селекторы (по имени тэга), что повышает скорость отрисовки страниц внутри браузера.
• Если необходимы CSS expressions, то пишутся «одноразовые». По возможности избегаются фильтры.
• Кешируется обращения к DOM дереву, а так же свойства элементов, приводящие к reflow. Обновляется DOM дерево в «оффлайне».

Уровень бизнес-логики

На уровне бизнес логики располагаются около 25 типов серверов и компонентов, общающихся между собой через удаленные интерфейсы. Каждую секунду происходит около 3 миллионов удаленных запросов между этими модулями.
Сервера на уровне бизнес логики разбиты на группы. Каждая группа обрабатывает различные события. Есть механизм маршрутизации событий, то есть любое событие или группу событий можно выделить и направить на обработку на определенную группу серверов. При общении серверов между собой используется свое решение, основанное на JBoss Remoting.

Уровень кэширования

Для кэширования данных используется самописный модуль odnoklassniki-cache. Он предоставляет возможность хранения данных в памяти средствами Java Unsafe. Кэшируются все данные, к которым происходит частое обращение, например: профили пользователей, списки участников сообществ, информация о самих сообществах, граф связей пользователей и групп, праздники, мета информация о фотографиях и многое другое.Для хранения больших объемов данных в памяти используется память Java off heap memory для снятия ненужной нагрузки с сборщика мусора. Кеши могут использовать локальный диск для хранения данных, что превращает их в высокопроизводительный сервер БД. Кеш сервера, кроме обычных операций ключ-значение, могут выполнять запросы по данным, хранящимся в памяти, минимизируют таким образом передачу данных по сети. Используется map-reduce для выполнения запросов и операций на кластере. В особо сложных случаях, например для реализации запросов по социальному графу, используется язык C. Это помогает повысить производительность.

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

Для примера, один сервер, кэширующий граф связей пользователей, в час пик может обработать около 16 600 запросов в секунду. Процессоры при этом заняты до 7%, максимальный load average за 5 минут — 1.2. Количество вершин графа — более 85 миллионов, связей 2.5 миллиарда. В памяти граф занимает 30 GB.

Уровень баз данных

Суммарный объем данных без резервирования составляет 160Тб. Используются два решения для хранения данных: MS SQL и BerkeleyDB. Данные хранятся в нескольких копиях, в зависимости от их типа от двух до четырех. Полное резервное копирование всех данных осуществляется раз в сутки, плюс каждые 15 минут делаются резервные копии новых данных. В результате максимально возможная потеря данных составляет 15 минут.

Сервера с MS SQL объединены в failover кластера, при выходе из строя одного из серверов, находящийся в режиме ожидания сервер берет на себя его функции. Общение с MS SQL происходит посредством JDBC драйверов.

Используются как вертикальное, так и горизонтальное разбиение данных, т.е. разные группы таблиц располагаются на разных серверах (вертикальное партиционирование), а данные больших таблицы дополнительно распределяются между серверами (горизонтальное партиционирование). Встроенный в СУБД аппарат партиционирования не используется — весь процесс реализован на уровне бизнес-логики. Распределенные транзакции не используются — всё только в пределах одного сервера. Для обеспечения целостности, связанные данные помещаются на один сервер или, если это невозможно, дополнительно разработывается логика обеспечения целостности данных. В запросах к БД не используются JOIN даже среди локальных таблиц для минимизации нагрузки на CPU. Вместо этого используется денормализация данных или JOIN происходят на уровне бизнес сервисов, что позволяет осуществлять JOIN как с данными из баз данных, так и с данными из кэша. При проектировании структуры данных не используются внешние ключи, хранимые процедуры и триггеры. Опять же для снижения потребления вычислительных ресурсов на серверах баз данных.
SQL операторы DELETE также используются с осторожностью — это самая тяжелая операция. Данные удаляются чаще всего через маркер: запись сначала отмечается как удаленная, а потом удаляется окончательно с помощью фонового процесса. Широко используются индексы, как обычные, так и кластерные. Последние для оптимизации наиболее высокочастотных запросов в таблицу.

Используется C реализация BerkleyDB версии 4.5. Для работы с BerkleydDB используется своя библиотека, позволяющая организовывать двухнодовые master-slave кластера с использованием родной BDB репликация. Запись происходит только в master, чтение происходит с обеих нод. Данные хранятся в tmpfs, transaction логи сохраняются на дисках. Резервная копия логов делается каждые 15 минут. Сервера одного кластера размещены на разных лучах питания дабы не потерять обе копии одновременно. Помимо прочего, BerkleyDB используется и в роли очереди заданий.

Внутри системы используется взвешенный round robin, а также вертикальное и горизонтальное разбиение данных как на уровне СУБД, так и на уровне кэширования.

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

Уровень инфраструктуры

Для агрегации статистики используется собственная библиотека, основанная на log4j. Сохраняется такая информация, как количество вызовов, среднее, максимальное и минимальное время выполнения, количество ошибок. Данные сохраняются во временные базы, но раз в минуту данные переносятся из них в общий склад данных (data warehouse), а временные базы очищаются. Сам склад реализован на базе решений от Microsoft: MS SQL 2008 и сиситема генерации отчетов Reporting Services. Он расположен на 13 серверах, находящихся в отдельной от production среде. Некоторые из них отвечают за статистику в реальном времени, а некоторые за ведение и предоставление доступа к архиву. Общий объем статистических данных составляет 13Тб. Планируется внедрение многомерного анализа статистики на основе OLAP.

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

Мониторинг логически разделен на две части:

• Мониторинг сервисов и компонентов
• Мониторинг ресурсов, оборудования и сети

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

Команда

Над проектом работают около 70 технических специалистов:

• 40 разработчиков;
• 20 системных администраторов и инженеров;
• 8 тестеров.

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

Разработка ведется итерациями в несколько недель. Как пример жизненного цикла разработки можно привести 3х недельный цикл:

1. определение архитектуры;
2. разработка, тестирование на компьютерах разработчиков;
3. тестирование на pre-production среде, релиз на production среду.

Практически весь новый функционал делается «отключаемым», типичный процесс запуска новой функциональной возможности:

• Функционал разрабатывается и попадает в production релиз;
• Через централизованную систему конфигурации функционал включается для небольшой части пользователей;
• Анализируется статистика активности пользователей, нагрузка на инфраструктуру;
• Если предыдущий этап прошел успешно, функционал включается постепенно для все большей аудитории;
• Если в процессе запуска собранная статистика выглядет неудовлетворительно, либо непозволительно вырастает нагрузка на инфраструктуру, то функционал отключается, анализируются причины, исправляются ошибки, происходит оптимизация и все повторяется с начала.

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

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

Dropbox — это самый простой способ…

• Хранить файлы в безопасном месте
• Делиться файлами с другими людьми
• Постоянно иметь к ним доступ вне зависимости от своего месторасположения

Взрывной рост

• 1 миллион файлов сохраняются в Dropbox каждые 15 минут (по презентации это больше, чем твитов в Twitter за тот же период времени, но это несколько преувеличено)
• Одно из самых скачиваемых приложений, уступает лишь Skype
• Важная часть жизни многих пользователей: «не могу жить без этого»
• Рост обеспечен «сарафанным радио», практически без рекламы

Команда в начале проекта

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

Ранние достижения

• Reverse engineering приложения Finder для Mac OSX 10.4/5 для отображения иконок статуса синхронизации («в процессе», «все готово»)
• Сложная инфраструктура HTTP нотификаций для избежания регулярного опроса серверов на каждом клиенте, основанная на Twisted
• Общая кодовая база, работающая на всех основных операционных системах: Windows, Mac OS, Linux (на основе PyObjC, wxPython, ctypes, py2exe, py2app, PyWin32)
• Горизонтально масштабируемое хранилище для информации о файлах на основе MySQL
• Собственная инфраструктура для аналитики в реальном времени
• Собственный механизм выделения памяти для Python, позволивший сократить её потребление на 90%

Сферы применения Python

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

• логика backend синхронизации;
• клиенты для основных ОС (Windows, Mac, Linux);
• контроллер основного сайта;
• обработка API запросов;
• аналитика.

Исключения из-за ограничений по доступной оперативной памяти:

• Android (мог бы быть Jython)
• iPhone (мог бы быть Cpython)

Почему именно Python?

• Легок в изучении и понимании:
  • новые люди легко втягиваются в процесс;
  • позволяет людям переключаться с проекта на проект.
• Легок в написании: важно для быстрой реализации функционала и выпуска новых версий.
• Легок в изменении:
  • нет необходимости в перекомпиляции;
  • высокая скорость итерации;
  • динамическая типизация:
    • рефакторинг очень прост;
    • уменьшение прямых зависимостей модулей;
    • динамические инструменты.
• Позволяет обеспечивать качество путем создания более-менее работающей версии продукта и доведения её до качественного уровня путем быстрых итераций.

Не без трудностей

Аргх!!! Python потребляет слишком много оперативной памяти и о-о-очень медленный!

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

Как с этим бороться?

• Убедитесь, что все длинные внутренние циклы выполняются в C (может сэкономить до 44% процессорного времени)
• С оптимизацией потребления вычислительных ресурсов все просто:
  • есть много готовых решений для профайлинга;
  • проблемный код чаще всего не раскидан по всей кодовой базе.
• С оптимизацией потребляемой памяти все сложнее:
  • нет готовых решений для профайлинга память (одновременно в Python и C);
  • много потенциальных причин для повышенного потребления памяти:
    • утечки в Python и C;
    • фрагментация памяти;
    • неэффективное её использование.
  • Как исправить? Однозначного решения нет — чаще всего приходится перерывать всю кодовую базу в поисках неоптимальных мест и источников утечек.
  • Почему память фрагментируется?
    • Большинство объектов расположены в heap памяти (большой последовательный кусок, выделенный приложению);
    • Много маленьких объектов вперемешку с большими;
    • Много временных объектов вперемешку с постоянными;
    • В CPython нет сборщика мусора, позволяющего собрать объекты компактно в одной части heap’а.
  • Решением проблемы с фрагментацией стал собственный аллокатор памяти (механизм её выделения под определенные типы объектов):
    • В Dropbox обнаружили, что большая часть heap-памяти захламляется контейнерами с метаданными файлов, которые синхронизируется;
    • Было решено вынести их куда-нибудь еще;
    • CPython позволяет управлять процессом выделения памяти для типов данных расширений;
    • Делается это с помощью простых структур на C;
    • «Not Rocket Science, just C code»;
    • Выделяются области памяти по 4Мб, состоящие из заголовка и буфферов фиксированной длины.
    • Что насчет внутренней фрагментации?
      • по идее же даже в одном буффере останутся данные, весь блок нельзя будет освободить…
      • потенциально этот факт может привести к еще большему расходу оперативной памяти;
      • но это оказывается не так, если учесть, что все объекты являются временными, то есть живут не долго!
      • в результате Dropbox редко использует более 100Мб памяти для больших синхронизаций (раньше эта цифра могла достигать 1.5Гб)
    • Но писать C расширение для каждой структуры данных, которую может понадобиться вынести в отдельный аллокатор — дело неблагодарное: в результате эта история закончилась изменением type_new() в Objects/typeobject.c для того, чтобы можно было указывать __use_region_allocator__ = True для тех классов, которым требуется такой механизм выделения памяти.

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

• Python стал ключом к технической реализации обоих сторон Dropbox: серверной и клиентской.
• Залогом успеха является максимальная простота с пользовательской точки зрения: «положил файл в папку и он становится доступен отовсюду»
• Dropbox не брали на себя реализацию стороннего функционала, вроде собственно создания хранилища файлов — используется Amazon S3, что позволило им запуститься очень быстро и стремительно.
• Лучше решать одну задачу, но качественно, чем много, но так себе!

Пользуясь случаем

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

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

• Видео
• Презентация

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

Статистика

• 3 год, 2 месяца и 1 день потребовалось Twitter, чтобы набрать 1 миллиард твитов
• На сегодняшний день, чтобы отправить миллиард твитов пользователям нужна всего одна неделя
• 752% рост аудитории за 2008 год
• 1358% рост аудитории за 2009 год (без учета API, по данным comScore)
• 175 миллионов зарегистрированных пользователей на сентябрь 2010 года
• 460 тысяч регистраций пользователей в день
• 9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
• 50 миллионов твитов в день год назад, 140 миллионов твитов в день месяц назад, 177 миллионов твитов в день на 11 марта 2011г.
• Рекорд по количеству твитов за секунду 6939, установлен через минуту после того, как Новый Год 2011 наступил в Японии
• 600 миллионов поисков в день
• Лишь 25% трафика приходится на веб сайт, остальное идет через API
• Росто числа мобильных пользователей за последний год 182%
• 6 миллиардов запросов к API в день, около 70 тысяч в секунду
• 8, 29, 130, 350, 400 — это количество сотрудников Twitter на январь 2008, январь 2009, январь 2010, январь и март 2011, соответственно

Самая свежая статистика про Twitter.

Платформа

• Apache + mod_proxy
• Unicorn
• Ruby + Ruby on Rails
• Scala
• Flock
• memcached
• Kestrel
• MySQL
• Cassandra
• Scribe
• Hadoop, HBase и Pig

Сравните с аналогичным разделом предыдущей статьи о Twitter — увидите много новых лиц, подробнее ниже.

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

• Сервера расположены в NTT America
• Никаких облаков и виртуализации, существующие решения страдают слишком высокими задержками
• Более тысячи серверов
• Планируется переезд в собственный датацентр

Что такое твит?

• Сообщение длиной до 140 символов + метаданные
• Типичные запросы:
  • по идентификатору
  • по автору
  • по @упоминаниям пользователей

Архитектура

Unicorn

Сервер приложений для Rails:

• Развертывание новых версий кода без простоя
• На 30% меньше расход вычислительных ресурсов и оперативной памяти, по сравнению с другими решениями
• Перешли с mod_proxy_balancer на mod_proxy_pass

Rails

Используется в основном для генерации страниц, работа за сценой реализована на чистом Ruby или Scala.

Столкнулись со следующими проблемами:

• Проблемы с кэшированием, особенно по части инвалидации
• ActiveRecord генерирует не самые удачные SQL-запросы, что замедляло время отклика
• Высокие задержки в очереди и при репликации

memcached

• memcached не идеален. Twitter начал сталкиваться с Segmentation Fault в нем очень рано.
• Большинство стратегий кэширования основываются на длинных TTL (боллее минуты).
• Вытеснение данных делает его непригодным для важных конфигурационных данных (например флагов «темного режима», о котором пойдет речь ниже).
• Разбивается на несколько пулов для улучшения производительности и снижения риска вытеснения.
• Оптимизированная библиотека для доступа к memcached из Ruby на основе libmemcached + FNV hash, вместо чистого Ruby и md5.
• Twitter является одним их наиболее активных проектов, участвующих в разработке libmemcached.

MySQL

• Разбиение больших объемов данных является тяжелой задачей.
• Задержки в репликации и вытеснение данных из кэша является причиной нарушения целостности данных с точки зрения конечного пользователя.
• Блокировки создают борьбу за ресурсы для популярных данных.
• Репликация однопоточна и происходит недостаточно быстро.
• Данные социальных сетей плохо подходят для реляционных СУБД:
  • NxN отношения, социальный граф и обход деревьев — не самые подходящие задачи для таких баз данных
  • Проблемы с дисковой подсистемой (выбор файловой системы, noatime, алгоритм планирования)
  • ACID практически не требуется
  • Для очередей также практически непригодны
• Twitter сталкивался с большими проблемами касательно таблиц пользователей и их статусов
• Читать данные с мастера при Master/Slave репликации = медленная смерть

FlockDB

Масштабируемое хранилище для данных социального графа:

• Разбиение данных через Gizzard
• Множество серверов MySQL в качестве низлежащей системы хранения
• В Twitter содержит 13 миллиардов ребер графа и обеспечивает 20 тысяч операций записи и 100 тысяч операций чтения в секунду
• Грани хранятся и индексируются в обоих направлениях
• Поддерживает распределенный подсчет количества строк
• Open source!

Среднее время на выполнение операций:

• Подсчет количества строк: 1мс
• Временные запросы: 2мс
• Запись: 1мс для журнала, 16мс для надежной записи
• Обход дерева: 100 граней/мс

Подробнее про эволюцию систем хранения данных в Twitter в презентации Nick Kallen.

Cassandra

Распределенная система хранения данных, ориентированная на работу в реальном времени:

• Изначально разработана в Facebook
• Очень высокая производительность на  запись
• Из слабых сторон: высокая задержка при случайном доступе
• Децентрализованная, способна переносить сбои оборудования
• Гибкая схема данных
• Планируется полный переход на нее по следующему алгоритму:
  • Все твиты пишутся и в Cassandra и в MySQL
  • Динамически часть операций чтения переводится на Cassandra
  • Анализируется реакция системы, что сломалось
  • Полностью отключаем чтение из Cassandra, чиним неисправности
  • Начинаем сначала
• Обновление: стратегия по поводу использования Cassandra изменилась, попытки использовать её в роли основного хранилища для твитов прекратились, но она продолжает использоваться для аналитики и географической информации.

Подробнее почему Twitter пришел к решению использовать Cassandra можно прочитать в отдельной презентации.

Помимо всего прочего Cassandra планируется использовать используется для аналитики в реальном времени.

Scribe

Пользователи Twitter генерируют огромное количество данных, около 15-25 Гб  в минуту, более 12 Тб в день, и эта цифра удваивается несколько раз в год.

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

Решение нашлось очень просто: Facebook столкнулся с аналогичной проблемой и разработал проект Scribe, который был опубликован в opensource.

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

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

Поддерживаются различные системы для записи в данным,  в том числе обычные файлы и HDFS (о ней ниже).

Этот продукт полностью решил проблему Twitter со сбором логов, используется около 30 различных категорий. В процессе использования была создана и опубликована масса доработок. Активно сотрудничают с командой Facebook в развитии проекта.

Hadoop

Как Вы обычно сохраняете 12Тб новых данных, поступающих каждый день?

Если считать, что средняя скорость записи современного жесткого диска составляет 80Мбайт в секунду, запись 12Тб данных заняла бы почти 48 часов.

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

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

Hadoop Distributed File System (HDFS) предоставляет возможность автоматической репликации и помогает справляться со сбоями оборудования.

MapReduce framework позволяет обрабатывать огромные объемы данных, анализируя пары ключ-значение.

Типичные вычислительные задачи, которые решаются с помощью Hadoop в Twitter:

• Вычисление связей дружбы в социальном графе (grep и awk не справились бы, self join в MySQL на таблицах с миллиардами строк — тоже)
• Подсчет статистики (количество пользователей и твитов, например подсчет количества твитов занимает 5 минут при 12 миллиардах записей)
• Подсчет PageRank между пользователями для вычисления репутации.

В твиттер используется бесплатный дистрибутив от Cloudera, версия Hadoop 0.20.1, данные храняться в сжатом по алгоритму LZO виде, библиотеки для работы с данными опубликованы под названием elephant-bird.

Pig

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

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

Немного напоминает SQL, но намного проще. Это позволяет писать в 20 раз меньше кода, чем при анализе данных с помощью обычных MapReduce работ.  Большая часть работы по анализу данных в Twitter осуществляется с помощью Pig.

Данные

Полу-структурированные данные:

• логи Apache, RoR, MySQL, A/B тестирования, процесса регистрации
• поисковые запросы

Структурированные данные:

• Твиты
• Пользователи
• Блок-листы
• Номера телефонов
• Любимые твиты
• Сохраненные поиски
• Ретвиты
• Авторизации
• Подписки
• Сторонние клиенты
• География

Запутанные данные:

• Социальный граф

Что же они делают с этим всем?

• Подсчет математического ожидания, минимума, максимума и дисперсии следующих показателей:
  • Количество запросов за сутки
  • Средняя задержка, 95% задержка
  • Распределение кодов HTTP-ответов (по часам)
  • Количество поисков осуществляется каждый день
  • Количество уникальных запросов и пользователей
  • Географическое распределение запросов и пользователей
• Подсчет вероятности, ковариации, влияния:
  • Как отличается использование через мобильные устройства?
  • Как влияет использование клиентов сторонних разработчиков?
  • Когортный анализ
  • Проблемы с сайтом (киты и роботы, подробнее ниже)
  • Какие функциональные возможности цепляют пользователей?
  • Какие функциональные возможности чаще используются популярными пользователями?
  • Корректировка и предложение поисковых запросов
  • A/B тестирование
• Предсказания, анализ графов, естественные языки:
  • Анализ пользователей по их твитам, твитов, на которые они подписаны, твитам их фоловеров
  • Какая структура графа ведет к успешным популярным сетям
  • Пользовательская репутация
  • Анализ эмоциональной окраски
  • Какие особенности заставляют людей ретвитнуть твит?
  • Что влияет на глубину дерева ретвитов ?
  • Долгосрочное обнаружение дубликатов
  • Машинное обучение
  • Обнаружения языка

Подробнее про обработку данных в презентации Kevin Weil.

HBase

Twitter начинают строить настоящие сервисы на основе Hadoop, например поиск людей:

• HBase используется как изменяемая прослойка над HDFS
• Данные экспортируются из HBase c помощью периодической MapReduce работы:
  • На этапе Map использются также данные из FlockDB и нескольких внутренних сервисов
  • Собственная схема разбиения данных
  • Данные подтягиваются через высокопроизводительный, горизонтально масштабируемый сервис на Scala (подробнее о построении распределенных сервисов на Scala)

На основе HBase разрабатываются и другие продукты внутри Twitter.

Основными её достоинствами являются гибкость и легкая интеграция с Hadoop и Pig.

По сравнению с Cassandra:

• «Их происхождение объясняет их сильные и слабые стороны»
• HBase построен на основе системы по пакетной обработке данных, высокие задержки, работает далеко не в реальном времени
• Cassandra построена с нуля для работы с низкими задержками
• HBase легко использовать при анализе данных как источник или место сохранения результатов, Cassandra для этого подходит меньше, но они работают над этим
• HBase на данный момент единственную точку отказа в виде мастер-узла
• В твиттере HBase используется для аналитики, анализа и создания наборов данных, а Cassandra — для онлайн систем

Loony

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

Реализована с использованием:

• Python
• Django
• MySQL
• Paraminko (реализация протокола SSH на Python, разработана и опубликована в opensource в Twitter)

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

Murder

Система развертывания кода и ПО, основанная на протоколе BitTorrent.

Благодаря своей P2P природе позволяет обновить более тысячи серверов за 30-60 секунд.

Kestrel

Распределенная очередь, работающая по протоколу memcache:

• set — поставить в очередь
• get — взять из очереди

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

• Отсутствие строгого порядка выполнения заданий
• Отсутствие общего состояния между серверами
• Разработана на Scala

Daemon’ы

Каждый твит обрабатывается с помощью daemon’ов.

В unicorn обрабатываются только HTTP запросы, вся работа за сценой реализована в виде отдельных daemon’ов.

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

Как они справляются с такими темпами роста?

Рецепт прост, но эффективен, подходит практически для любого интернет-проекта:

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

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

• Автоматический сбор метрик (причем в агрегированном виде)
• Построение графиков (RRD, Ganglia)
• Сбор и анализ логов
• Все данные должны получаться с минимальной задержкой, как можно более близко к реальному времени
• Анализ:
  • Из данных необходимо получать информацию
  • Следить за динамикой показателей: стало лучше или хуже?
  • Особенно при развертывании новых версий кода
  • Планирование использования ресурсов намного проще, чем решение экстренных ситуаций, когда они на исходу

Примерами агрегированных метрик в Twitter являются «киты» и «роботы», вернее их количество в единицу времени.

Что такое «робот»?

• Ошибка внутри Rails (HTTP 500)
• Непойманное исключение
• Проблема в коде или нулевой результат

Что такое «кит»?

• HTTP ошибка 502 или 503
• В твиттер используется фиксированный таймаут в 5 секунд (лучше кому-то показать ошибку, чем захлебнуться в запросах)
• Убитый слишком длинный запрос к базе данных (mkill)

Значительное превышение нормального количества китов или роботов в минуту является поводом для беспокойством.

Реализован этот механизм простым bash-скриптом, который просматривает агрегированные логи за последние 60 секунд, подсчитывает количество китов/роботов и рассылает уведомления, если значение оказалось выше порогового значения. Подробнее про работу команды оперативного реагирования в презентации John Adams.

«Темный режим»

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

Имеется около 60 выключателей, в том числе и полный режим «только для чтения».

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

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

• Не бросайте систему на самотек, начинайте собирать метрики и их визуализировать как можно раньше
• Заранее планируйте рост требуемых ресурсов и свои действия в случае экстренных ситуаций
• Кэшируйте по максимуму все, что возможно
• Все инженерные решения не вечны, ни одно из решений не идеально, но многие будут нормально работать в течение какого-то периода времени
• Заранее начинайте задумываться о плане масштабирования
• Не полагайтесь полностью на memcached и базу данных — они могут Вас подвести в самый неподходящий момент
• Все данные для запросов в реальном времени должны находиться в памяти, диски в основном для записи
• Убивайте медленные запросы (mkill) прежде, чем они убьют всю систему
• Некоторые задачи могут решаться путем предварительного подсчета и анализа, но далеко не все
• Приближайте вычисления к данным по возможности
• Используйте не mongrel, а unicorn для RoR

Спасибо за внимание, жду Вас снова! Буду рад, если Вы подпишитесь на меня в Twitter, с удовольствием пообщаюсь со всеми читателями

Платформа

• Linux — операционная система
• Python — язык программирования
• Django — основной framework
• Apache 2.2 + mod_wsgi — веб-сервер
• PostgreSQL — СУБД
• memcached — кэширование
• HAProxy — балансировка нагрузки
• Slony — репликация данных
• heartbeat — обеспечение доступности

Статистика

• До 17 тысяч запросов в секунду
• 500 000 сайтов
• 15 миллионов зарегистрированных пользователей
• 75 миллионов комментариев
• 250 миллионов посетителей (на август 2010г.)

Основные трудности

• Непредсказуемость нагрузки (основными причинами шумихи в Интернете являются катастрофы и выходки знаменитостей)
• Обсуждения никогда не теряют актуальность (нельзя держать в кэше все дискуссии с 2008 года)
• Нельзя угадать на каком сайте из тысяч возникнет пик трафика
• Персональные настройки, динамическое разбиение на страницы и сортировки снижают эффективность кэширования
• Высокая доступность (из-за разнообразия сайтов и их аудитории сложно запланировать технические работы)

Архитектура

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

• Оборудование, в сумме около 100 серверов:
  • 30% веб-серверов (Apache + mod_wsgi)
  • 10% серверов баз данных (PostgreSQL)
  • 25% кэш-серверов (memcached)
  • 20% балансировка нагрузки и обеспечение доступности (HAProxy + heartbeat)
  • 15% прочие сервера (Python скрипты)
• Балансировка нагрузки:
  • HAProxy:
    • Высокая производительность
    • Интеллектуальная проверка доступности
    • Неплохая статистика
• Репликация:
  • Используется Slony-I
  • Основана на триггерах
  • Master/Slave для обеспечения большего объема операций чтения
• Высокая доступность:
  • heartbeat
  • Пассивная копия мастер баз данных на случай сбоя основной
• Партиционирование:
  • Реализовано на уровне кода
  • Простая реализация, быстрые положительные результаты
  • Два метода разделения данных:
    • Вертикальное:
      • Создание нескольких таблиц с меньшим количеством колонок вместо одной (она же нормализация)
      • Позволяет разделять базы данных
      • Данные объединяются в коде (медленнее, чем на уровне СУБД, но не намного)
      • Бартер производительности на масштабируемость
      • Более эффективное кэшировние
      • Механизм роутеров в Django позволяет достаточно легко реализовать данный функционал
    • Горизонтальное:
      • Некоторые сайты имеют очень большие массивы данных
      • Партнеры требуют повышенного уровня доступности
      • Помогает снижать загрузку по записи на мастер базе данных
      • В основном используется все же вертикальное партиционирование
• Производительность базы данных:
  • Особое внимание уделяется тому, чтобы индексы помещались в оперативную память
  • Логгирование медленных запросов (автоматизировано с помощью syslog-ng + pgFouine + cron)
  • Использование пулов соединений (Django не умеет этого, используется pgbouncer, позволяет экономить на ресурсоемких операциях установления и прекращения соединений)
  • Оптимизация QuerySet’ов:
    • Не используется чистый SQL
    • Встроенный кэш позволяет выделять части выборки
    • Но это не всегда нужно, они убрали этот кэш
  • Атомарные операции:
    • Поддерживают консистентность данных
    • Использование update(), так как save() не является thread-safe
    • Отлично работают для таких вещей, как счетчики
  • Транзакции:
    • TransactionMiddleware поначалу использовалось, но со временем стало обузой
    • В postgrrsql_psycopg2 есть опция autocommit:
      • Это означает что каждый запрос выполняется в отдельной транзакции
      • Обработка каждого пользовательского HTTP-запроса не начинает новую транзакцию
      • Но все же транзакции из нескольких операций записи в СУБД нужны (сохранение нескольких объектов одновременно и полный откат в  случае ошибки)
      • В итоге все HTTP-запросы по-умолчанию начинаются в режиме autocommit, но в случае необходимости  переключаются в транзакционный режим
• Отложенные сигналы:
  • Постановка в очередь низкоприоритетных задач (даже если они не длинные по времени)
  • Асинхронные сигналы очень удобны для разработчика (но не так, как настоящие сигналы)
  • Модели отправляются в очередь в сериализованном виде
• Кэширование:
  • Используется memcached
  • Новый pylibmcна основе libmemcached в качестве клиента (проекты django-pylibmc и django-newcache)
  • Настраиваемые алгоритмы поведения клиента
  • Используется _auto_reject_hosts и _retry_timeout для предотвращения повторных подключений к вышедшим из строя кэш-серверам
  • Алгоритм размещения ключей: консистентное хэширование на основе libketama
  • Существует проблема, когда одно очень часто используемое значение в кэше инвалидируется:
    • Множество клиентов одновременно пытаются получить новое значение из СУБД одновременно
    • В большинстве случаев правильным решением было бы вернуть большинству устаревшие данные и позволить одному клиенту обновить кэш
    • django-newcache и MintCache умеют это делать
    • Заполнение кэша новым значением вместо удаления при инвалидации также помогает избежать этой проблемы
• Мониторинг:
  • Информация о производительности запросов к БД, внешних вызовов и рендеринге шаблонов записывается через собственный middleware
  • Сбор и отображение с помощью Ganglia
• Отключение функционала:
  • Необходим способ быстро отключить новый функционал, если оказывается, что он работает не так, как планировалось
  • Система должна срабатывать мгновенно, по всем серверам, без записи на диск
  • Позволяет запускать новые возможности постепенно, лишь для части аудитории
  • Позволяет постоянно использовать основную ветку кода
  • Аналогичная система используется и в Facebook
• Масштабирование команды разработчиков:
  • Небольшая команда
  • Месячная аудитория / количество разработчиков = 40 миллионов
  • Это означает:
    • Автоматическое тестирование
    • И максимально простой процесс разработки
  • Новый сотрудник может начать работать уже через несколько минут, нужно лишь:
    • Установить и настроить PostgreSQL
    • Скачать исходный код из git
    • С помощью pip и virtualenv установить зависимости
    • Изменить настройки в settings.py
    • Выполнить автоматическое создание структуры данных средствами Django
• Непрерывное тестирование:
  • Ежедневное развертывание с помощью Fabric
  • Hudson обеспечивает регулярно осуществляет и тестирует сборки
  • Интегрирован Selenium
  • Быстрое тестирование с помощью Pyflakes и post-commit hooks
  • 70 тысяч строк Python кода, 73% покрытие тестами, прогон всех тестов занимает 20 минут
  • Собственная система исполнения тестов с поддержкой XML, Selenium, подсчета количества запросов, тестирования Master/Slave базы данных и интеграцией с очередью
• Отслеживание проблем и задач:
  • Переключились с Trac на Redmine (из-за поддержки под-задач)
  • Отправка исключений на e-mail — плохая идея
  • Раньше использовали django-db-log, но теперь опубликовали свою систему сбора ошибок и логов под названием Sentry

Делаем выводы

• Язык программирования, каким бы он ни был, не является проблемой
• Django в целом очень хорош (но приходится все же использовать набор собственных патчей)
• Даже при использовании низкопроизводительного framework можно построить масштабируемую систему
• Вертикальное партиционирование позволяет пожертвовать производительностью в пользу масштабируемости
• Даже небольшой командой разработчиков можно добиться высоких результатов, если не пренебрегать автоматизацией тестирования
• Большое значение имеет возможность вовремя отслеживать и оперативно реагировать на сбои

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

Данная статья написана на основе выступления Jason Yan и David Cramer на DjangoConf 2010. В презентации можно найти примеры кода, ссылки на упоминаемые проекты и дополнительные материалы:

Другие статьи по масштабируемости высоконагруженных систем можно почитать в соответствующем разделе, а вовремя узнавать о новых — подписавшись на RSS. Вчера, кстати, прикрутил DISQUS к Insight IT, приглашаю постоянных читателей и всех остальных потестировать

В большом бизнесе использование нескольких больших кластеров с финансовой точки зрения более эффективно, чем много маленьких. Чем больше машин в кластере, тем большими наборами данных он может оперировать, больше задач могут выполняться одновременно. Реализация MapReduce в Apache Hadoop столкнулась с потолком масштабируемости на уровне около 4000 машин в кластере. Разрабатывается следующее поколение Apaсhe Hadoop MapReduce,  в котором появится общий планировщик ресурсов и отдельный мастер для каждой отдельной задач, управляющий выполнением программного кода. Так как простой оборудования по техническим причинам обходится дорого на таком масштабе, высокий уровень доступности проектируется с самого начала, ровно как и безопасность и многозадачность, необходимые для поддержки одновременного использования большого кластера многими пользователями. Новая архитектура также будет более инновационной, гибкой и эффективной с точки зрения использования вычислительных ресурсов.

Предыстория

Текущая реализация Hadoop MapReduce устаревает на глазах. Основываясь на текущих тенденциях в размерах кластеров и нагрузок на них, JobTracker требует кардинальных доработок, чтобы исправить его дефекты в области масштабируемости, потребления памяти, многопоточности, надежности и производительности. С точки зрения работы с Hadoop при каждом обновлении кластера (даже если это просто багфикс), абсолютно все компоненты кластера, так и приложений, которые на нем работают, должны быть обновлены одновременно. Это так же очень неудобно, так как каждый раз необходимо тестировать все приложения на совместимость с новой версией.

Требования

Прежде чем кардинально что-то менять в Hadoop mapreduce, необходимо понять какие же основные требования предъявляются к вычислительным кластерам на практике. Наиболее значительными требованиями к Hadoop следующего поколения являются:

• Надежность
• Доступность
• Масштабируемость — кластеры из как минимум 10 тысяч машин, 200 тысяч вычислительных ядер и даже больше
• Обратная и прямая совместимость — возможность быть уверенным, что приложение будет работать на новой версии так же, как оно работало на старой
• Контроль над обновлениями
• Предсказуемые задержки
• Эффективное использование ресурсов

Среди менее значительных требований:

• Поддержка альтернативных парадигм разработки (помимо MapReduce)
• Поддержка сервисов с коротким жизненным циклом

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

MapReduce следующего поколения

Фундаментальной идеей смены архитектуры является разделение двух основных функций JobTracker’а на два отдельных части:

• управление ресурсами;
• планирования и мониторинга задач.

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

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

Архитектура

Улучшения по сравнению с текущей реализацией MapReduce

Масштабируемость

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

Масштабируемость особенно важна в свете текущих трендов в оборудовании — на данный момент Hadoop может быть развернут на кластере из 4000 машин. Но 4000 средних машин 2009го года (т.е. по 8 ядер, 16Гб памяти, 4Тб дискового пространства) только вдвое менее  ресурсоемки, чем 4000 машин 2011го года (16 ядер, 48гб памяти, 24Тб дискового пространства). Помимо этого с точки зрения операционных издержек было выгоднее работать в еще больших кластере от 6000 машин и выше.

Доступность

• ResourceManager использует Apache ZooKeeper для обработки сбоев. Когда ResourceManager перестает работать, аналогичный процесс может быстро запуститься на другой машине благодаря тому, что состояние кластера было сохранено в ZooKeeper. При таком сценарии все запланированные и выполняющиеся приложения максимум лишь перезапустятся.
• ApplicationMaster — поддерживается создание точек восстановления на уровне приложений. ApplicationMaster может восстановить работу из состояния, сохраненного в HDFS, в случае сбоя.

Совместимость протокола

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

Инновационность и гибкость

Основным плюсом предложенной архитектуры является тот факт, что MapReduce по сути становится просто пользовательской библиотекой. Вычислительная же система (ResourceManager и NodeManager) становятся полностью независимыми от специфики MapReduce.

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

Эффективность использования вычислительных ресурсов

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

Таким образом эта схема избавляет от текущего механизма map и reduce слотов в Hadoop, который негативно влияет на эффективную утилизацию вычислительных ресурсов.

Поддержка других парадигм программирования помимо MapReduce

В предложенной архитектуре используется общий механизм вычислений, не привязанный конкретно к MapReduce, что позволит использовать и другие парадигмы. Имеется возможность реализовать собственный ApplicationMaster, способный запрашивать ресурсы у ResourceManager и использовать их в соответствии с задачей, при этом сохраняются общие принципы изоляции и гарантированного наличия полученных ресурсов. Среди потенциально поддерживаемых парадигм можно назвать MapReduce, MPI, Мaster-Worker, итеративные модели. Все они могут одновременно работать на одном и том же кластере. Это особенно актуально для приложений (например К-средний или Page Rank), где другие подходы более чем на порядок эффективнее MapReduce.

Выводы

Apache Hadoop, и в частности Hadoop MapReduce — очень успешный opensource проект по обработке больших объемов данных. Предложенный Yahoo путь его переработки направлен на исправление недостатков архитектуры текущей реализации, при этом повышая доступность, эффективность использования ресурсов и предоставляя поддержку других парадигм распределенных вычислений.

Осталось дело за малым — собственно реализовать задуманное!

Источник информации: http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/

Подписаться на RSS можно здесь.

Piccolo — это система для распределенных вычислений, использующая новую ориентированную на данные модель программирования для разработки приложений по параллельным вычислениям в памяти в масштабах дата-центров. В отличии от существующих моделей, основывающихся на потоках данных, Piccolo позволяет вычислениям выполняться на различных машинах, при этом имея общее изменяющееся состояния через интерфейс таблиц пар «ключ-значение». Традиционные ориентированные на данные модели (такие как используются в Apache Hadoop) предоставляют пользователю для работы лишь единственный объект в определенный момент времени, когда в Piccolo используется глобальная таблица состояний, одновременно доступная для всех частей вычисления. Это позволяет пользователям указывать алгоритм вычисления в интуитивно-понятной манере, очень похожей на разработку программ для одного компьютера.

Использование хранилища, позволяющего хранить в памяти пары «ключ-значение», сильно отличается от канонического подхода map-reduce, который основан на распределенных файловых системах. Результаты впечатляют:

Эксперименты показали, что Piccolo очень быстр и отличные возможности по масштабируемости для многих прикладных задач. Производительность вычисления PageRank и k-средних выросла в 11 и 4 раза, соответственно, по сравнению с Hadoop. Вычисление PageRank для связанного графа из 1 миллиарда страниц заняло лишь 70 секунд на 100 машинах в Amazon EC2. Распределенная система по скачиванию веб-страниц легко может полностью загрузить 100Мбит интернет-канал при работе на 12 машинах.

Проект реализован в виде библиотеки для Python и C++. Более детально примеры использования и принципы работы системы разбираются в источниках информации (правда на английском), не поленитесь — загляните. Вместо заключения хотелось бы по традиции порекомендовать подписаться на RSS блога, если Вы еще этого не сделали.

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

• Russell Power — автор проекта Piccolo
• Piccolo: Building Fast, Distributed Programs with Partitioned Tables

• Проект был презентован на OSDI10: презентация и видео

Организационные моменты

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

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

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

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

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

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

День первый

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

После приветственного слова Олега Бунина (одного из основных организаторов конференции) слово взял Joe Damato, которого позиционировали как известного хакера, активно работающего над развитием Ruby. Темой выступления был обзор различных инструментов и приемов для анализа ситуации в серверном Linux-окружении. Некоторые моменты были мне известны и ранее, но в целом больше половины доклада было для меня очень интересно и ново. Перечислять упомянутые им приемы я, честно говоря, не вижу смысла — будет просто дублирование презентации. Если ранжировать доклады первого дня по интересу лично для меня, то это выступление заняло бы, пожалуй, второе место.

Вторым докладчиком был также приверженец секты Рубистов, James Golick, один из основателей социальной сети для фетишистов (простите за отсутствие ссылки). Основной фишкой доклада было «разоблачение мифов», в частности об облачных вычислениях и NoSQL. Количество пользователей этой социальной сети, но они очень активны и генерируют достаточно много контента (особенно по Российским меркам). Проект изначально располагался в компании, которая предоставляла услуги managed hosting (хостинг на арендуемых серверах + за тебя администрируют), но они посчитали, что слишком много переплачивают за этот самый «managed», и решили поддаться тренду и переехать в облако (Amazon EC2). По деньгам получилось не сильно дешевле, но больше всего из расстроила производительность виртуальных машин (кажется, был слайд со скоростью доступа к дисковой подсистеме, выставляющий облако не в лучшем свете). Второй эпопеей в их проекте были попытки оптимизировать подсистему хранения данных путем перенесения ее части в NoSQL хранилище: пробовали MongoDB (выкинули из-за блокировок на операциях удаления) и Cassandra (выкинули из-за медленного случайного чтения). Финальным решением стал Redis + MySQL, просто и со вкусом — их всецело устраивает на данный момент, как я понял.

Третьим выступал Robert Johnson из Facebook, доклад был практически таким же, как и в ГУ-ВШЭ за несколько дней до этого — о нем я уже писал, так что подробно останавливаться не буду. Основным отличием были дополнительные технические детали, но подавляющее большинство из них и так уже были описаны в статье «Архитектура Facebook».

После обеда выступал Patrice Pelland из Microsoft, доклад  был о том, как работают их облачные сервисы (видимо live, skydrive и прочие). Естественно все на их же продуктах, большинство названий я даже не слышал. Единственное, что запомнил из выступления — у мелкомягких есть даже клон memcached, но с какими-то дополнительными плюшками. Это был единственный доклад, после которого никто не захотел задать даже одного вопроса, что в целом наглядно продемонстрировало незаинтересованность аудитории в платных решениях. В твиттере после этого выступления проскользнула обиженная фраза докладчика, что-то в духе: «До них просто не дошло, о чем я говорил».

После этого недоразумения от MS началась длинная серия докладов от людей, причастных к созданию PostgreSQL:

• Simon Riggs из 2nd Quadrant
• Robert Treat из Omni TI
• Bruce Momjian из EnterpriseDB

Было 5 выступлений о PostgreSQL подряд:

• Повышение производительности
• Управление репликацией
• Масштабирование
• Быстрая смена версии средствами pg_update
• Потоковая репликация

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

• очень качественный английский у докладчиков
• забавная манера выступления Роберта, особенно про красные кроки (что-то типа галош)
• активная реклама новых вкусностей PostgreSQL 9.0, релиз которой я по каким-то причинам проворонил — надо будет обязательно попробовать ее в деле

После кофе-брейка я пошел на больше всего понравившийся мне доклад (за первый день) — выступал Stoyan Stefanov из Yahoo! Темой доклада была заявлена неочевидная формулировка «Progressive Downloads and Rendering», хотя на самом деле все свелось к грамотно построенному докладу о клиентской оптимизации: несколько вводных картинок, один слайд с базовыми приемами и много-много примеров очевидных и не очень случаев, когда с точки зрения пользователя сайт начинает тупить, даже если серверная часть проекта написано грамотно и работает достаточно быстро. По некоторым аспектам, в частности про кроссбраузерному использованию data:URL+MHTML, он ссылался на русские источники, а также очень позитивно отзывался о Николае Мациевском.

Последним, что я посетил в первый день, была «открытая встреча» c James Golick и Joe Damato про сам Ruby. Ожидал большего: в итоге Joe вообще не выступил, а большая часть времени ушла на разжёвывание базовых возможностей языка и несколько мелких холиваров.

День второй

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

После докладов на английском «отечественные» выступления смотрелись совсем блекло. Конец выступления Андрея Смирнова про Twisted не принес мне хоть какой-либо полезной информации, тем более мне все равно больше по душе Tornado. Вопрос про их сравнение от одного из слушателей вызвал у докладчика рассказать историю о том, как будущий автор Tornado тусовался в сообществе Twisted, а потом взял и сделал свой продукт.

Следующий доклад был про профилирование памяти в Python от Антона Грицая — начал он историю очень издалека, с того что такое утечки памяти, какие бывают «сборщики мусора», какие есть варианты искать утечки в Python и чем они плохи, собственно до «дела» он дошел лишь к концу доклада. Было предложено пользоваться продуктом под названием heapy, который обладает широким спектром возможности, но при этом документация сильно хромает.

Последним докладом в секции про Python было выступление трех бравых ребят из HeadHunter, которые рассказывали про их внутренний продукт под названием Frontik, представляющий собой надстройку над Tornado, аггрегирующую данные с нескольких HTTP-сервисов. В целом идея мне понравилась, но ввиду исторических причин реализация у них накручена очень муторно:

• основной формат передачи данных — XML по HTTP
• генерация HTML посредством XSLT
• регулярные выражения где надо и где не надо (для повышения производительности)

Основным событием оставшейся части второго дня, как Вы уже наверное поняли, был аншлаг с участием Вконтакте и лично Павлом Дуровым в главной роли. Результаты подробно расписаны в статье «Архитектура Вконтакте», повторяться не буду, с Вашего позволения.

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

• Юрий Востриков из Mail.ru рассказывал про Tarantool/Silverbox — еще после их технологического форума подумываю попробовать этот продукт в деле, но после этого выступления понял, что пока рановато: не известно ни об одном успешном применении вне компании-разработчика, да и библиотеки с реализацией полноценного протокола есть далеко не под все языки программирования.
• На доклад про реализацию одного из топовых приложений Вконтакте на Rails я попал почти к самой сессии вопросов-ответов, запомнился только тот факт, что после того как компания, в которой работал докладчик, передала приложение заказчику — они почти сразу же переписали его на PHP. Заставляет задуматься.
• В третьем, дополнительном, зале во второй половине дня расположился тренинг Start in Garage для людей, планирующих сделать свой стартап; ребята рассказывали весело и непринужденно, но по сути все было очень примитивно — ушел минут через 20 после начала на аншлаг вконтакте.
• Про Scalaxy было бы интересно написать отдельную статью, больно часто они всплывают на конференциях и в онлайн-сообществах. На этот раз рассказывали о том, как они выделяют избыточные дисковые массивы для виртуальных машин (которые они собственно в аренду сдают). Технология называется Vast Sky, родом откуда-то из Азии, позволяет легко выделять заданное количество блоковых устройств на разных дисковых системах и подключать их к виртуальной машине в виде софтверного RAID. В сочетании с их QDR Infiniband от Voltaire работает очень даже шустро (по крайней мере если верить их бенчмаркам по сравнению с альтернативными технологиями).
• Scalaxy же запускает сервис ddosme, предназначенный для нагрузочного тестирования интернет-проектов. Попал опять только на вопросы-ответы, из них понял, что они предлагают через прокси походить по своему ресурсу, затем на основе логов составляются маршруты движения ботов по сайту и тестирование запускается на нужных мощностях. Сколько стоит не понял.
• Последним докладом, который я застал краем глаза, было обсуждение основных косяков, мешающих 1С-Битрикс обслуживать пристойное количество пользователей — для меня совершенно не актуальный вопрос, так что после этого я начал собираться в сторону выхода и отправился смотреть «Социальная сеть».

Заключение

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

Хотелось бы видеть больше докладов не о конкретных инструментах и технологиях, а о их применении в рамках построения общей архитектуры проекта или решения конкретных нетривиальных задач. Доклады в духе «у нас вот такая классная штука есть, но стоит денег» и «приходите к нам работать, чтобы попробовать в деле эту технологию» как обычно скучны, но вроде их было довольно мало (надеюсь докладчики хотябы платят организатором за возможность порекламироваться?). Приглашенные иностранные гости — ход очень классный, мне кажется основной ключ успеха прошедшего мероприятия, в этом направлении определенно стоит двигаться — хотелось бы увидеть представителей известных проектов (Google, Ebay, Amazon, Flickr, Twitter, Baidu, QQ и.т.д.) и людей, решающих реально нетривиальные задачи, вроде Joe Damato.

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

Да, думаю Вы уже заметили, что блог Insight IT снова потихоньку возвращается к жизни, так что подписываться на RSS никогда не поздно.

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

Данный пост является переводом англоязычной статьи, автор оригинала: Todd Hoff.

Статистика

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

Наверняка все прекрасно знают о лидерах интернет-поиска в российской части интернета: про Google, Яндекс или Рамблер сказано уже не мало слов, все много раз о них читали, пользовались, обсуждали — ведь уже прошло больше 10 лет с момента создания каждой из этих поисковых систем и, как следствие, их конкуренции на просторах рунета. Намного меньше же внимания на российских информационных сайтах уделяется национальным проектам других стран, а ведь среди них тоже есть заслуживающие внимания экземпляры, об одном из них я бы и хотел сегодня поведать.

Источники данных

• Baidu Aladdin Technology Guashudila
• Rachel Liao, лекция директора по архитектуре Baidu
• Baidu Chief Architect: алгоритмы на службе разработчиков Baidu
• Aladdin Plans

Если кто-то достаточно любопытен, чтобы нажать на приведенные ссылки — они все на китайском, так что статья написана на основе перевода Google Translate со всеми вытекающими последствиями. Даже за название «Aladdin» не ручаюсь, его тоже он придумал

О компании Baidu

Baidu.com является лидером китайского рынка интернет-поиска, объем которого достаточно значителен. На данный момент Китай насчитывает около 340-360 миллионов интернет-пользователей, что превышает общую численность населения США. Не трудно представить с каким трафиком приходится сталкиваться крупнейшей китайской поисковой системе.

Чтобы не быть голословным, еще немного цифр о Baidu:

• 100 миллионов поисковых запросов в день
• Более миллиарда проиндексированных страниц
• 300-400 миллионов проиндексированных сайтов

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

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

Aladdin

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

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

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

Перед разработчиками Aladdin встают две основные проблемы с точки зрения технической реализации: «как определить пользовательские потребности» и «как сортировать». Конечно же они очень тесно связаны между собой, это хорошо демонстрирует пример с поисковым запросом «полное солнечное затмение»: до затмения пользователи хотят когда оно будет и откуда лучше смотреть, а во время и после него намного актуальнее будет увидеть видео-запись или прямую трансляцию, а также прочитать и поделиться комментариями. Самым простым методом решения данного класса задач является статистический анализ — Aladdin выделяет два основных фактора, используемых для сортировки результатом в соответствии с потребностями пользователей: «удовлетворенность потребностей» и «уровень отклика на спрос». Конечно же оценочные характеристики спроса и потребностей не означают сам спрос, то есть возможны и более сложные ситуации, когда за пользовательским запросом стоит целый комплекс более простых потребностей.

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

Возможности платформы

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

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

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

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

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

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

Взгляд с другой стороны

Да, вся платформа Aladdin по своей задумке очень искуственна: практически все делается вручную, но по сути это лишь процесс интеграции, а не работа с самим контентом. Для большинства других поисковых систем такой подход неприемлем: где найти столько людей, чтобы управлять огромными массивами данных вручную? Наоборот все поисковые системы стремятся по максимуму все автоматизировать и борятся с искуственным вмешательством в поисковый индекс (т.н. SEO), но… если вспомнить, что Baidu работает в Китае — вся затея начинает обретать здравый смысл. Как сама компания Baidu, так и большинство их потенциальных партнеров, клиентов и пользователей находится в примерно одинаковой ситуации: большое количество дешевой рабочей силы, относительно низкий уровень образования и профессиональной подготовки, а также прочие национальные особенности. В их ситуации не выгодно идти по пути Google и делать основной акцент на построении полностью автоматизированных систем анализа контента, добавления дополнительного материала к поисковым результатам и самим делать различные дополнительные приложения и сервисы. Намного выгоднее пойти по собственному пути, более адаптированному к ситуации в Китае, большое количество трудолюбивых людей позволяет строить сервисы коллективно, с привлечением партнеров, клиентов и заинтересованных лиц. Да, во многом вручную, за счет интеграции совершенно различных систем и сервисов, но зато более качественно и продуманно. В этом-то и заключается вся магия Китая.

Stack Overflow является любимым многими программистами сайтом, где можно задать профессиональный вопрос и получить ответы от коллег. Этот проект был написан двумя никому не известными парнями, о которых никто никогда раньше не слышал. Хорошо, не совсем так. Stack Overflow был создан топовыми программистами и звездами блогосферы: Jeff Atwood и Joel Spolsky. В этом отношении Stack Overflow похож на ресторан, владельцами которого являются знаменитости. По оценкам Joel’а около 1/3 программистов всего мира использовали этот интернет-ресурс, так что должно быть он представляет собой что-то достаточно полезное и интересное.

Одним из ключевых моментов в истории Stack Overflow является использование вертикального масштабирования, как достаточно работоспособного решения достаточного большого класса проблем. Не смотря на то, что публика на сегодняшний день больше склоняется к подходу с использованием горизонтальным масштабирования и не-SQL баз данных.

Если Вы стремитесь к масштабу Google, у Вас нет другого выхода, как двигаться в направлении не-SQL. Но Stack Overflow — это не Google, ровно как и подавляющее большинство других сайтов. Когда Вы задумываетесь о возможных вариантов дизайна Вашего проекта, попробуйте учесть и историю Stack Overflow, она тоже имеет право на жизнь. В этот век многоядерных машин с большим объемом оперативной памяти и невероятными темпами развития методов параллельного программирования, вертикальное масштабирование все еще является жизнеспособной стратегией и не должна сразу же отбрасываться в сторону просто так как это теперь больше не модно. Возможно в один прекрасный день мы получим лучшее из обоих миров, но на сегодняшний момент перед нами лежит большой болезненный выбор стратегии масштабирования, от которого определенно зависит судьба Вашего проекта.

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

Перевод статьи, автор оригинала — Todd Hoff. Возможно будет еще один пост с менее формальной информацией на ту же тему.

Статистика

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

• Легкодоступность: данные доступны посредством повсеместно используемого протокола HTTP.
• Распреденность: узлы могут работать и существовать на любых доступных серверах.
• Эластичность: имеется возможность динамического добавления и удаления узлов кластера на лету, без малейшего простоя системы и каких-либо изменений в конфигурации.
• Масштабируемость на уровне данных: документы разбиваются на группы и распределяются между доступными узлами с автоматической прозрачной балансировкой, в том числе и при добавлении и исключении узлов в кластере.
• Масштабируемость на вычислительном уровне: запросы и обновление данных распределяются по узлам, которые физически хранят используемые данные, тем самым минимизируется трафик и распределяется вычислительная нагрузка.
• Консистентность: система обеспечивает по-документную консистентность данных, таким образом гарантируя тот факт, что пользователь всегда получает самую свежую версию документа, обеспечивая изоляцию для параллельных модификаций документов.
• Отсутствие схемы: предоставляет JSON интерфейс, основанный на коллекциях; пользователям предоставляется возможность просто создать свою коллекцию и положить туда что угодно.
• Простота в работе: установка полностью работоспособного кластера заключается в вводе всего нескольких команд и не требует какого-либо редактирование XML-конфигов.
• Богатый функционал: поддерживаются push-down предикаты, запросы по диапазонам и серверные функции обновления.

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

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

Кстати про Terracotta, на основе которой работает данный продукт, тоже давно пора было уже написать, в ближайшее время займусь

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

Данная статья является переводом статьи MySpace Architecture, автором которой является Todd Hoff. Когда-то давно один из читателей этого блога просил меня осветить и эту тему, тогда я так и не решился из-за отсутствия моего личного интереса, но сейчас снова случайно наткнулся на эту статью и подумал: а почему бы и нет?

• Презентация: за сценой MySpace.com
• Внутри MySpace.com

Платформа

• ASP .NET 2.0
• Windows
• IIS
• MSSQL Server

Что внутри?

• 300 миллионов пользователей.
• Отдает 100Gbps в Интернет. 10Gbps из них является HTML контентом.
• 4,500+ веб серверов со связкой: Windows 2003 / IIS 6.0 / ASP .NET.
• 1,200+ кэширующих серверов, работающих на 64-bit Windows 2003. На каждом 16GB объектов находятся в кэше в оперативной памяти.
• 500+ серверов баз данных, работающих на 64-bit Windows и SQL Server 2005.
• MySpace обрабатывает 1.5 миллиарда просмотров страниц в день, а также 2.3 миллионов одновременно работающих пользователей в течении дня.
• Вехи по количеству пользователей:
  - 500 тысяч пользователей: простая архитектура перестает справляться
  - 1 миллион пользователей: вертикальное партиционирование временно спасает от основных болезненных вопросов с масштабированием
  - 3 миллиона пользователей: горизонтальное масштабирование побеждает над вертикальным
  - 9 миллионов пользователей: сайт мигрирует на ASP.NET, создается виртуализированная система хранения данных (SAN)
  - 26 миллионов пользователей: MySpace переходит на 64-битную технологию.
• 500 тысяч учетных записей было многовато для двух веб-серверов и одного сервера баз данных.
• На 1-2 миллионах учетных записей:
  - Они использовали архитектуру базы данных, построенную на концепции вертикального партиционирования, с отдельными базами данных для разных частей сайта, которые использовались для выполнения различных функций, таких как экран авторизации, профили пользователей и блоги.
  - Схема с вертикальным партиционированием помогала разделить нагрузку как для операций чтения, так и для операций записи, а если пользователям в друг оказывалась нужна новая функциональная возможность — достаточно было просто добавить еще один сервер баз данных для её обслуживания.
  - MySpace переходит от использования систем хранения, подключенных к серверам баз данных напрямую, к сетям хранения данных (SAN), при таком подходе целый массив систем хранения объединяется вместе специализированной сетью с высокой пропускной способностью, и сервера баз данных также получают доступ к хранилищам через эту сеть. Переход к SAN оказал положительное влияние как на производительность, так и на доступность и надежность системы.
• На 3 миллионах учетных записей:
  - Решение с вертикальным партиционированием не протянуло долго, так как им приходилось реплицировать какую-то часть информации (например информацию об учетных записях) по всем вертикальным частям базы данных. С таким большим количеством операций репликации данных один узел даже при незначительном сбое мог существенно замедлить обновление информации во всей системе.
  - Индивидуальные приложения вроде блогов на под-секциях сайта достаточно быстро стали слишком большими для нормальной работы с единственным сервером базы данных
  - Произведена реорганизация всех ключевых данных для более логичной организации в единственную базу данных
  - Пользователи были разбиты на группы по миллиону в каждой и каждая такая группа была перемещена на отдельный SQL Server
• 9–17 миллионов учетных записей:
  - Переход на ASP .NET, который требовал меньше ресурсов по сравнению с их предыдущим вариантом архитектуры. 150 серверов, использовавших новый код могли обработать нагрузку, для которой раньше требовалось 246 серверов.
  - Снова пришлось столкнуться с узким местом в системе хранения данных. Реализация SAN решило какую-то часть старых проблем с производительностью, но на тот момент потребности сайта начали переодически превосходить возможности SAN по пропускной способности операций ввода-вывода — той скорости, с которой она может читать и писать данные на дисковые массивы.
  - Столкнулись с лимитом производительности при размещении миллиона учетных записей на одном сервере, ресурсы некоторых серверов начали исчерпываться.
  - Переход к виртуальному хранилищу, где весь SAN рассматривается как одно большое общее место для хранения данных, без необходимости назначать конкретные диски для хранения данных определенной части приложения. MySpace на данный момент работает со стандартизированным обородуванием от достаточно нового вендора SAN — 3PARdata
• Был добавлен кэширующий уровень — прослойка из специализированных серверов, расположенных между веб-серверами и серверами данных, чья единственная задача была захватывать копии часто запрашиваемых объектов с данными в памяти и отдавать их веб-серверам для минимизации количества поиска данных в СУБД.
• 26 миллионов учетных записей:
  - Переход на 64-битные сервера с SQL Server на правах решения проблемы с недостатком оперативной памяти. С тех пор их стандартеый сервер баз данных оснащен 64 GB RAM.
• Горизонтальная федерация баз данных. Базы данных партиционируются в зависимости от своего назначения. У них есть базы данных с профилями, электронными сообщениями и так далее. Каждая партиция основана на диапазоне пользоваталей. По миллиону в каждой базе данных. Таким образом, у них есть Profile1, Profile2 и все остальные базы данных вплоть до Profile300, если считать, что у них на данный момент зарегистрировано 300 миллионов учетных записей.
• Кэш ASP не используется, так как он не обеспечивает достаточного процента попаданий на веб серверах. Кэш, организованный как промежуточный слой, имеет существенно более высокое значение данного показателя.
• Изоляция сбоев. Внутри веб-сервера запросы сегментируются по базам данным. Разрешено использование только 7 потоков для работы с каждуой базой данных. Таким образом, если база данных по каким-то причинам начинает работать медленно, только эти потоки замедлятся, в то время как остальные потоки будут успешно продолжать обрабатывать поток трафика.

Работа сайта

• Коллектор данных о производительности. Централизованная система сбора информации о производительности через UDP. Такой подход более надежен, чем стандартный механизм Windows, а также позволяет любому клиенту подключиться и увидеть статистику.
• Веб-система по просмотру дампов стеков процессов. Можно просто сделать клик правой кнопкой мыши на проблемном сервере и увидеть дамп стека процесов, управляемых .NET. И это после привычки каждой раз удаленно подключаться к серверу, влючать дебаггер и через полчаса получать свой ответ о том что же все таки происходит. Медленно, немасштабируемо и утомительно. Эта же система позволяет увидеть не просто стек процесса, но и предоставляет большое количество информации о контектсе, в котором он работает. Обнаружение проблем намного проще при таком подходе, например можно легко увидеть, что база не отвечает, так как 90 ее потоков заблокировано.
• Веб-система создания дампа heap-памяти. Создает дамп всей выделенной памяти. Очень удобно и полезно для разработчиков. Сэкономьте часы на выполнение этой работы вручную.
• Профайлер. Прослеживает запрос от начала до конца и выводит подробный отчет. В нем можно увидеть URL, методы, статус, а также все, что поможет идентифицировать медленный запрос и его причины. Обнаруживает проблемы с блокировкой потоков, непредвиденными исключениями, другими словами все, что может оказаться интересным. В то же время остается очень легковесным решением. Работает на одной машине из каждой VIP (группа из 100 серверов) в production-среде. Опрашивает 1 поток каждые 10 секунд. Постоянно следит за системой в фоновом режиме.
• Powershell. Новая программная оболочка от Microsoft, которая работает в процессе и передаем объекты между командами вместо работы с текстовыми данными. MySpace разрабатывает множество так называемых commandlets’ов для поддержки различных операций.
• Разработана собственная технология асинхронной коммуникации для того, чтобы обойти проблемы с сетевыми проблемами Windows и работать с серверами как с группой. Например, она позволяет доставить файл .cs, скомпилировать его, запустить, и доставить результат обратно.
• Развертывание. Обновление кодовой базы происходит с помощью упомянутой выше собственной технологии. Ранее происходило до 5 таких обновлений в день, сейчас же они происходят лишь раз в неделю.

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

• С помощью стека Microsoft тоже можно делать большие веб-сайты.
• Стоит использовать кэширование с самого начала.
• Кэш является более подходящим местом для хранения временных данных, не требующих персистентности, например информации о пользовательских сессиях.
• Встроенные в операционные систему возможности, например по обнаружению DDoS-атака, могут приводить к необъяснимым сбоям.
• Храните свои данные в географически удаленных датацентрах для минимизации проблем, связанных со сбоями в электросети.
• Рассматривайте возможности использования виртуализированных систем хранения данных или кластерных файловых систем с самого начала. Это позволит существенно параллелизировать операции ввода-вывода, а также увеличивать дисковое пространство без необходимости какой-либо реорганизации.
• Разрабатывайте утилиты для работы с production окружением. Невозможно смоделировать все ситуации в тестовой среде. Масштабируемость и все различные варианты использования API не могут быть симулированы в процессе тестирования качества программного обеспечения. Обычные пользователи и хакеры обязательно найдут такие способы использования вашего продукта, о которых вы даже никогда и не подумаете в процессе тестирования, хотя конечно большая часть все же обнаружима в процессе QA тестирования.
• Когда это возможно — лучше просто использовать дополнительное оборудование для решения проблем. Это намного проще, чем изменять поведение программного обеспечения для того чтобы решать задачи как-то по-другому. Примером может служить добавление нового сервера на каждый миллион пользователей. Возможно было бы более эффективным изменить подход к самой работе с СУБД, но на практике все же проще и дешевле добавлять все новые и новые сервера. По крайней мере на данный момент.

Хотя да, достаточно давно уже Google выпустили в свет платформу Google App Engine. Описание этого продукта меня заинтересовало еще до открытия публичного доступа к системе и я даже записался на полу-закрытое тестирование. Вскоре пришло подтверждение, что мол «мы рады сообщить, что Ваша учетная запись активирована и теперь у Вас есть возможность попробовать наш новый продукт, для этого нажмите ссылку такую-то». Но пришло оно как-то не очень удачно, когда ни лишнего свободного времени не было, да и идеи подходящей для создания чего-нибудь эдакого на новой платформе тоже на горизонте не наблюдалось. В общем зашел на их сайт, посмотрел админку, поставил демо-приложение, поигрался чуток и забросил. Но с тех пор руки так и не прекращали чесаться от желания попробовать GAE на каком-нибудь более приближенном к реальности приложении, что мне совсем недавно и довелось сделать. Спешу поделиться впечатлениями.

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

Если взглянуть издалека, то GAE представляет собой условно-бесплатный хостинг для веб-приложений, для разработчиков предоставляется все необходимое: начиная от минимально-необходимого SDK со встроенным веб-сервером, локально эмулирующим саму платформу, заканчивая неплохой документацией по самой системе и доступным из нее API от Google. Почему условно-бесплатный? Бесплатно приложениям выделяется лишь ограниченное количество вычислительных ресурсов, при превышении которых по выбору владельца приложения либо взимается вполне скромная плата, либо всем пользователям начинают показывать «извиняйте, заходите завтра» (в прямом смысле, счетчики потребления ресурсов сбрасываются ежедневно).

Но финансовый вопрос далеко не самый интересный, давайте взглянем на техническую сторону медали. Написанное с использованием SDK приложение загружается в production-окружение, которое физически размещается на тех самых известных кластерах Google, о которых у меня даже есть пост (конечно же под GAE используется только очень небольшая часть их вычислительных можностей). Причем все заботы о распределенной работе приложения на большом количестве машин платформа берет на себя: разработчику не нужно думать ни о балансировке нагрузки, ни о партиционировании данных, ни о других аспектах. Сразу же после окончания процессов загрузки и развертывания приложение готово становится готово к работе и доступно по домену третьего уровня на *.appspot.com, либо можно подключить свой отдельный домен.

Технические ограничения тоже имеют быть: для разработки под GAE можно использовать лишь небольшой набор языков программирования, в частности Python 2.5, а также Java и все остальные языки, компилируемые или интерпретируемые под JVM (JRuby, Scala, Rhino, etc.). Все приложения исполняются в песочнице, ограничивающей доступ к окружающему миру, то есть определенные подмножества языков становятся недоступны, например: доступ к файловым системам, встроенные средства обработки изображений, доступ к сторонним ресурсам по HTTP, отправка почты. Про реляционные базы данных, memcached и библиотеки, использующие нативный, платформозависимый код, также стоит забыть. Но не все так плохо, как кажется: для реализации всех «отобранных» у разработчиков функциональных компонент Google предоставляет собственные сервисы-заменители, доступные через хорошо документированный API или вовсе замаскированные под стандартные методы языка. В качестве дополнительных бонусов предоставляются и возможности по интеграции с другими продуктами Google, скажем можно легко сделать авторизацию пользователей в приложении по учетным записям от GMail или нотификацию пользователей по Jabber через GTalk.

Отдельного внимания заслуживает используемая в данной платформе система хранения данных, основанная на BigTable, о которой более подробно можно почитать в уже упомянутом посте об архитектуре Google. Если в двух словах, то она представляет собой распределенное нереляционное хранилище данных, автоматически обеспечивающее репликацию и кеширование данных, а также практически гарантирующее постоянную доступность данных вне зависимости от сбоев низлежащего оборудования. Для доступа к нему разработчикам предоставляется специальный API и язык доступа к данным GQL, слегка напоминающий упрощенный диалект SQL (лишь отдаленно). Продукт в обращении достаточно своеобразен, как оказалось самый простой способ привыкнуть к работе с ним — выкинуть из головы все знания о традиционных СУБД и взглянуть на процесс хранения данных с чистого листа. Разномастные JOIN’ы и прочие изыски лишь мешают думать в терминах подобных систем.

Закончив тему с рекламой GAE, позвольте перейти к моим личным впечатлениям. Попробовал я данную платформу на вполне конкретном примере (в конце поста дам ссылочку на частично-готовый результат, если кому интересно), надо же в конце-концов на что-то с пользой убивать внезапно появившееся свободное время. ОтJava и прочей компании языков, основанных на JVM, я невероятно устал на теперь уже «прошлой» работе, так что взор мой упал на Python и давно находящийся у меня на слуху (в основном благодаря Ивану Сагалаеву) фреймворк Django. Ни с тем, ни с другим я ранее почти не был знаком на практике, разве что когда-то пытался помогать своим очень хорошим подругам с прохождением Python в университете (пользуясь случаем, передаю привет Полине, Кате и Юле, очень по вам скучаю ). Стоит упомянуть, что существует несколько сборок Django, адаптированных под GAE, наиболее продуманным и готовым к эксплуатации мне показался проект под названием app engine patch, которым я и воспользовался для экспериментов.

Django, как известно, является вполне традиционным веб-фрейморком, пропагандирующим свою вариацию на тему MVC (именуемую MVT — Model-View-Template, но по сути абсолютно то же самое), а также целый ряд философских верований (вроде DRY, Don’t repeat yourself), которым даже отведена отдельная страница на официальном сайте. Адаптированная под GAE версия фреймворка отличается от стандартной по большому счету лишь замененной частью Model, в которую очень неплохо вписался предоставляемый API к уже упоминавшемуся хранилищу данных. По всем остальным компонентам системы официальная документация по Django практически полностью актуальна и сильно помогла понять всю картину разработки веб-приложений с использованием данных технологий.

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

Предложение Google по использованию платформы GAE выглядит очень заманчиво, не смотря на все ограничения под нее можно как портировать существующие приложения, так и легко создавать новые. Бесплатное использование до превышения квот также не может не радовать (кстати квоты там рассчитаны на мировой рынок, превысить большинство из них в рамках рунета — надо постараться, мне кажется). Но закончить данное повествование мне всетаки хотелось парой недокументированных или вкратце официально упоминавшихся «ложек дегтя». Первая неприятная особенность: процессы, обрабатывающие пользовательские запросы приложений, умирают после очень небольшого времени простоя (таймаут судя по всему секунд 20-30). По истечении таймаута система освобождает использующиеся приложением ресурсы и когда после перерыва приходит очередной пользователь система вынуждена заново инициализироваться (чуть ли не заново компилировать байткод, хотя не уверен), что занимает около 5 секунд, а то и больше, во время которых пользователю ничего не остается кроме как терпеливо ждать. Сделали данный механизм видимо в связи с тем фактом, что подавляющее большинство развернутых приложений были сделаны просто чтобы побаловаться и были сразу же заброшены, что делает неэффективным постоянное держание в готовом состоянии даже одного процесса для каждого приложения. Таким образом использование GAE для тяжелых веб-приложений с небольшой целевой аудиторией не очень эффективно.  Минус второй: существуют некоторые жесткие ограничения, которые не разрешают увеличивать даже за деньги (по крайней мере расценок не видно). В их число входят максимальное время обработки одного запроса (30 секунд, правда не ясно распространяется ли это на выполнение задач в Task Queue и местном аналоге Cron’а), 30 активных процессов, обрабатывающих запросы приложения (что влечет за собой достаточно жесткое ограничение на количество запросов в секунду в районе нескольких сотен), максимальный размер HTTP запроса/ответа в 10 мегабайт и некоторые другие. В итоге «тяжелые» вычисления на GAE не погоняешь (хотя есть варианты с применением AJAX и, соответственно, большого количества запросов к GAE), от Digg-эффекта или DDOS’а есть шанс не уберечься, хостинг файлов не соорудить, но… разве это ограничения? Есть масса более интересных типов веб-приложений, способных прекрасно существовать в такой среде. Да и в крайнем случае всегда можно связаться с представителями Google с просьбой в виде исключение для Вашего приложения, судя по их заявлениям все ограничения носят искусственный характер и служат лишь для защиты от потребления неоправданно большого количества вычислительных ресурсов плохо спроектированных приложениями.

Этот пост написан по мотивам истории сайта CargoBook, который задумывался как сообщество для логистов, с плавным выходом на корпоративный рынок с продуктом в виде логистической информационной системы, предоставляемой по принципу SaaS. Сходив по ссылке можно заценить, что можно сделать средствами сладкой парочки Django+GAE и одного студента с почти гуманитарным образованием за часов эдак 20 работы в свободное время. Сейчас в задумке кроме меня участвует всего еще один человек: на правах автора идеи, но  если Вас заинтересовал данный проект и может быть Вы хотите присоединиться в каком-либо амплуа — пишите об этом в комментариях или по другим контактным данным.

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

Предистория

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

Само же тестирование меня несколько позабавило. Не знаю кто его составлял, но суть его была примерно в следующем: за полтора часа предлагплось ответить на 10 вопросов, семь из которых формулировалось примерно как «какой результат будет получен после выполнения программы <код на перле>«. Основной прикол был в том, что этот код написан на Perl там сказано не было, если честно с первого вопроса я его даже не признал, приняв за какой-то псевдо-код. На втором вопросе до меня дошла-таки истина, благодаря не столь отдаленному во времени посещению YAPC::Russia 2008 «May Perl» и, в частности, проходившему там мастер-классу Ивана Сережкина. Дальнейшее тестированме проходило с открытым vim‘ом и /bin/perl под рукой, лишь один или два вопроса пришлось неторопливо погуглить…

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

День первый

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

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

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

После непродолжительного перерыва на кофе слово перешло еще одному представителю компании Яндекс — Филиппу Дельгядо. На этот раз речь пошла о веб-проектах средних размеров, которым необходимо справляться с серьезной нагрузкой (наравне с прочими нефункциональными требованиями) но с несколько другой точки зрения, программиста. Выступление также носило обзорный характер и содержало в себе повествования о достаточно большом количестве граблей, на которые могут натыкаться те или иные проекты. На самом деле по затрагиваемым темам мне в свое время довелось прочитать достаточно много материалов, пару раз споткнуться на практике и даже написать пару постов, так что лично я рассматривал этот доклад как закрепление знакомых тем. Разве что затронутый вопрос горизонтального масштабирования хранения данных меня несколько смутил: не знаю, может быть я несколько не в теме или еще что, но суть была примерно такова, что под partitioning’ом рассматривались только псевдо-универсальные решения, входящие в комплект некоторых СУБД, в то время как sharding’ом было предложено понимать все остальные, «самопальные», решения, специфичные для конкретного проекта. Я же почему-то всегда рассматривал такой подход как нечто концептуально-общее, так как конкретика реализации не важна, а важна сама идея данного подхода, и считаю эти два слова достаточно близкими синонимами (ровно как и многочисленные их русские аналоги), хотя может быть я и не прав…

Следующее выступление было, пожалуй, лучшим из увиденных мной в первый день. В программке оно значилось как: «Как писать высокопроизводительные веб-сервера», Антон Самохвалов (Яндекс). Были рассмотрен ряд возможных подходов к написанию веб-серверов: начиная банальными неработоспособными однопоточными вариантами и заканчивая противопоставлению вполне рабочих вариантов: threads, FSM и co-routine. Докладчик оказался убежденным сторонником подхода с использованием co-routine или на худой конец thread’ов, а также использующего схожую идеологию веб-сервера от ASF. Презентация сыграла лишь роль детонатора для последующей бурной дискуссии с участием многих слушателей, а также ведущего этой секции — Игоря Сысоева, по совместительству разработчика известного в «узких» кругах проекта nginx. Ничего удивительного, что обсуждение плавно перетекло в Holy War: Threads vs FSM, но в отличии от знаменитых войн анонимусов на linux.org.ru, шоу выдалось захватывающим и информационно-полезным. Основными аргументами были даже не цифры о производительности, полученные ребятами из Яндекса в полу-синтетических тестах (Антон активно упоминал тот факт, что на примере базового поиска Яндекса использованние thread’ы давало примерно 10% прирост производительности по сравнению с FSM), а скорее споры о maintenability кода и его простоте, а также теоретических пределах использования этих подходов в разных условиях (речь даже дошла до гипотетических ситуаций с использованием более чем четырехядерных процессоров). Довелось выслушать мнения профессионалов по обе стороны «баррикад» и самостоятельно сделать все требуемые выводы, самый банальный и немаловажный из которых заключается просто в том факте, что оба подхода имеют право на жизнь в реальных проектах и какой из них использовать очень во многом зависит от личных предпочтений разработчиков и специфики проекта.

Далее по расписанию был запланировал обеденный перерыв, на котором я решил заглянуть в аудиторию параллельного потока (где весь день рассказывали о различных системах хранения данных). В это время там как раз проходил доклад Павла Уварова из Рамблер о их собственной разработке для хранения и передачи данных под названием HCS (читается почему-то как «хикс»). Самое начало доклада я, к сожалению, пропустил, но почти с первых же увиденных мной слайдов проект меня заинтересовал. Суть данной технологии примерно характеризуется ее названием: Hierarchically Compressed Stream. С одной стороны это формат хранения иерархически структурированных данных, с другой же — данные в нем представляют обычный файл, который легко обернуть в произвольный протокол передачи потоковых данных (т.е. например просто раздавать через любой HTTP-сервер). По представленным в презентации benchmark’ам запись и линейный доступ к данным в этом формате происходит в разы, а то и порядки быстрее по сравнению с РСУБД, а для ускорения случайного доступа, на сколько я понял, имеется возможность построения индекса по верхнему уровню иерархии. Помимо всего прочего, Павел обрадовал аудиторию, что данная технология в ближайшем времени будет опубликована в opensource, обязательно надо будет попробовать ее в деле как только появится возможность.

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

После этого доклада можно было стать свидетелем повествования работников mail.ru сначала об их собственной разработке под названием Imagine Framework, которая тоже вполне соответствует своему названию: ее можно разве что представить — ни одного примера кода, закрыт для использования только в рамках mail.ru, много слов ни о чем и общий стиль изложения в духе «вот какую клевую штуку мы придумали, но никому не дадим и не покажем». В общем я даже, если честно, не понял для какого он языка программирования предназначен и чем он лучше (или хотябы просто отличается) от opensource аналогов (упоминались собственные системы кэширования, мониторинга и бинарный протокол). В итоге я до конца так и не дослушал и ушел снова в соседний поток слушать про хранение слабосвязанных данных.

Илья Космодемьянцев из SUP Fabrik вел рассказ о том, как могут развиваться события, если тот или иной проект сталкивается с хранением данных, плохо вписывающихся в модель РСУБД. Разработчикам приходят мысли о создании собственного специфического формата хранения данных, о том с какими проблемами могут столкнуться в процессе. Возможные варианты решения проблем также рассматривались, например в виде написания не формата хранения данных, а собственного хранилища для, например, MySQL — это может помочь избежать части проблем. Помимо этого выдвигалось очень спорное предложение о создании некого «UseCase API», которое могло бы позволить инкапсулировать для бэкэнда все особенности хранения данных в случае их нетрадиционности. Хотя на практике подобные методики применяются достаточно давно, особенно в объектно-ориентированных языках программирования в виде data-access objects.

После еще одного кофе-брейка оставалось лишь два заключительных доклада первого дня, из которых я решил посетить нечто под названием «Масштабный Jaabber-кластер, IM и не только» от Андрея Федоровского из РБК. Начало доклада было достаточно примитивным — что такое Jabber и с чем его едят, всем это и без того было известно, так что было достаточно скучно. Даже обзор доступных расширений не открыл ничего нового — все те же давно знакомые вещи, разве что некий интерес вызвал процесс отправки бинарных данных (т.е. произвольных файлов): было заявлено что отправка файла временно обрывает поток XML-данных и отправляет вместо него бинарный поток, но не заставил себя ждать очевидный вопрос: а как же тогда происходит общение в этот момент. Вокруг этого образовалась небольшая дискуссия, но к консенсусу прийти так и не удалось. Далее пошел рассказ собственно о том как на сегодняшний день можно построить Jabber-кластер — подробностей повествованию явно не хватало, но суть была примерно такова: единственным более-менее сносным Jabber-сервером является ejabberd, написанный на до сих пор экзотическом языке Erlang (что впоследствии подтвердили сотрудники Яндекс: в своем проекте Я.Онлайн они используют тоже его). По-умолчанию он использует нативное для Erlang хранилище данных под названием Mnesia, но в том проекте РБК, на основе которого и строился весь доклад (правда я так и не понял как он называется), почему-то побоялись его использовать (видимо из-за нежелания разбираться в том как оно функционирует) и использовали имеющуюся возможность интеграции с более традиционной СУБД — PostgreSQL. В дискуссии после доклада речь шла скорее о самом ejabberd, Erlang’е, острой нехватке программистов на нем и тому подобных вещах, чем о самом докладе.

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

День второй

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

Предисловие

Сообщение о публикации двух презентаций c JavaOne 2008 о LinkedIn и их обобщении от Overn Hurvitz пронеслось по русскоязычным новостным ресурсам уже достаточно давно, но время черкнуть пару строк обо всем этом нашлось у меня только сейчас.

Статистика

• 22 миллиона пользователей;
• 4+ миллиона уникальных посетителей в день;
• 40 миллионов просмотров страниц в день;
• 2 миллиона поисковых запросов в день;
• ежедневно отправляются 250 тысяч приглашений;
• 1 миллион ответов в день;
• 2 миллиона электронных сообщений ежедневно.

Платформа

• Solaris (как x86, так и SPARC)
• Tomcat и Jetty
• Oracle и MySQL
• Никакого ORM
• ActiveMQ для JMS
• Lucene в качестве основы для поиска
• Spring в роли «клея»

Серверная архитектура

2003-2005

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

2006

• Добавлена репликация для уменьшения нагрузки на основную базу данных. Реплики предоставляют данные в режиме «только для чтения», а репликация ведется в асинхронном режиме с помощью дополнительного компонента под названием Databus, с его появлением обновление данных стало выглядеть следующим образом:

  – сначала какие-либо изменения происходят в веб-приложении;

  – веб-приложение обновляет основную базу данных;

  – она, в свою очередь, отправляет обновления на Databus;

  – далее уже Databus обновляет: реплики, Облако и поисковый индекс.

• Поиск был вынесен на отдельный сервер.

2008

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

Облако

• «Облаком» в LinkedIn называют сервер, который кэширует весь граф социальной сети в памяти;
• его размеры: 22 миллиона вершин и 120 миллионов ребер;
• занимает 12GB оперативной памяти;
• одновременно держится в памяти в 40 экземплярах;
• построение Облака из данных, в дисковой системе, занимает 8 часов;
• обновления происходят в режиме реального времени с помощью Databus;
• во время остановки данные записываются на диск;
• кэш реализован с помощью C++, а доступ предоставляется по JNI;
• они выбрали именно C++ так как требовалось использовать минимум оперативной памяти, а также, задержки, связанные с Garbage Collection, были неприемлемыми.
• размещение всех данных в памяти является ограничением, но, как удалось выяснить в LinkedIn, разбиение графов на части — не самая тривиальная задача.

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

Помимо этого используется кэширование профилей пользователей средствами EHcache. Одновременно в памяти хранится до 2 миллионов профилей (из 22 миллионов). Изначально планировалось использовать алгоритм LFU, но оказалось, что иногда EHcache зависал секунд на 30 во время перерасчета LFU, таким образом было принято решение о использовании вместо него алгоритма LRU.

Архитектура коммуникации

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

Сервис постоянных сообщений

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

• вся система работает асинхронно и активно использует JMS;
• клиенты отправляют сообщения так же через JMS;
• далее сообщения перенаправляются с помощью сервиса маршрутизации в соответствующий почтовый ящик или напрямую в обработку электронной почты;
• доставка сообщений происходит как с помощью Pull (клиенты запрашивают свои сообщения), так и с использованием Push (т.е. отправки сообщений);
• помимо этого используется Spring с их собственными закрытыми расширениями, использующими HTTP-RPC.

Приемы, способствующие масштабируемости

• Функциональное сегментирование: отправленные, полученные, архивные сообщения. (т.е. вертикальное сегментирование)
• Классовое сегментирование: пользовательские, гостевые, корпоративные почтовые ящики.
• Сегментирование по диапазонам: по идентификаторам пользователей или по лексикографическим диапазонам самих сообщений. (т.е. горизонтальное сегментирование)
• Асинхронное выполнение операций.

Сервис сетевых обновлений

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

Изначальная архитектура (до 2007 года)

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

В 2008 году вся эта система поэтапно эволюционировала собственно в сам сервис сетевых обновлений:

Первая итерация

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

Вторая итерация

• стал использоваться метод Push: каждый раз, когда происходит какое-либо событие, они помещаются в пользовательский «почтовый ящик», в момент запроса пользователя ему возвращается просто содержимое, уже ожидающее своего звездного часа в специально том самом «ящике»;
• такой подход сильно ускоряет процесс чтения, так как на тот момент данные уже готовы;
• с другой стороны, какая-то часть данных может так никогда и не понадобиться, что приводит к бесполезным передвижениям данных и лишнему используемому дисковому пространству;
• небольшая часть обработки данных все же производится уже в момент запроса пользователя (например, объединение нескольких обновлений от определенного пользователя в одно);
• обновления хранятся в CLOB‘ах: по одному CLOB‘у на каждый тип обновления для каждого пользователя (то есть в сумму около 15 CLOB‘ов на каждого пользователя);
• сначала использовался размер CLOB‘ов равный 8 KB, что было явно больше требуемого и приводило к существенному количеству неиспользуемого дискового пространства.
• вместо CLOB‘ов можно было бы использовать дополнительные таблици по одной на каждый тип обновлений, но в этом случае пришлось бы постоянно удалять из них устаревшие записи, что было бы чрезвычайно неэффективно.
• в дополнение к этому использовался JMX для мониторинга и изменения конфигурации в реальном времени, что оказалось очень удобным и полезным.

Третья итерация

• Цель: повысить производительность путем сокращения количества обновлений CLOB‘ов, так как они требуют много вычислительных ресурсов.
• Был добавлен буфер: колонки в таблицах типа varchar(4000), в которых данные помещались изначально. При полном заполнении ячейки данные перемещаются в CLOB; это позволило на порядок сократить количество их обновлений.
• Уменьшен размер самих сообщений об обновлениях.

И напоследок пару советов от LinkedIn

• нельзя бесконечно долго ограничиваться одной базой данных: используйте много баз данных как с вертикальным, так и с горизонтальным сегментированием данных;
• забудьте о ссылочной целостности и кросс-серверных JOIN’ах;
• забудьте о 100% целостности данных;
• при большом масштабе издержки могут стать проблемой: оборудование, базы данных, лицензии, системы хранения данных, электроэнергия и так далее;
• как только вы станете достаточно крупны и популярны, спаммеры и прочие злые люди не заставят себя долго ждать;
• не забывайте про кэширование!!!
• используйте асинхронные потоки данных;
• аналитика и построение отчетов может стать непростой задачей, постарайтесь задуматься о них заранее в процессе планирования системы;
• имейте всегда ввиду, что Ваша система может упасть в любой момент;
• не стоит недооценивать траекторию своего роста.

P.S.

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

Кстати если Вы еще не успели подписаться на RSS — сейчас самое время!

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

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

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

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

Еще более быстрые веб-сайты
7 этапов построения масштабируемых веб-приложений. Стратегии для системных архитекторов

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

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

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

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

Этот текст является переводом статьи, автор — Todd Hoff. Извиняюсь за не сильно оригинальный контент (да и, как выяснилось, практически не технической направленности), но на написание своих полноценных текстов у меня последнее время все никак не хватает то креатива, то времени .

• Спросите 37signals: цифры?
• Спросите 37signals: как вы работаете с кредитными картами?
• За сценой 37signals: поддержка.
• Спросите 37signals: почему вы перезапустили Highrise?

Платформа

• Ruby on Rails
• Memcached
• Xen
• MySQL
• Amazon S3 для хранения изображений

Статистика

• 30 серверов: от простых однопроцессорных файловых серверов до восьмипроцессорных серверов приложений, в сумме около 100 процессоров и 200 GB оперативной памяти.
• В планах диагональное масштабирование: уменьшение количества серверов до 16, но более производительных — в сумме 92 процессоров и 230 GB RAM.
• Виртуализация средствами Xen для более гибкого управления системой.
• Basecamp (управление проектами)

  2000000 пользователей с учетными записями

  13200000 задач

  9200000 сообщений

  12200000 комментариев

  5500000 записей о распределении времени

• Backpack (управление информацией для личного использования и малого бизнеса)

  Около миллиона страниц

  6800000 задач

  1500000 записей

  829000 фотографий

  370000 файлов

• Общая статистика проектов (на ноябрь 2007 г.)

  5.9 TB загруженных пользователями данных

  888 GB загружено (upload)

  2 TB скачано (download)

Архитектура

• Кэширование средствами memcached уже используется, но они ищут способы более активно его применять. Позволяет достичь впечатляющих результатов в плане производительности.
• Методы для составления URL используются вместо ручного их составления.
• Используются стандартные ActiveRecord запросы, но при необходимости они используют и ручную настройку.
• Иногда они дорабатывают Rails, если сталкиваются с проблемами с производительностью.
• Amazon S3 используется для хранения данных, загруженных пользователями. Разработчики очень довольны результатами.

Работа с кредитными картами

• Ежемесячное выписывание счетов. Это позволяет компаниям, занимающимся кредитными картами, чувствовать себя более комфортно, так как им не придется столкнуться с огромным количеством работы, если ваша фирма вдруг выйдет из бизнеса. Пользователям такой подход также по душе, так как издержки в итоге оказываются относительно невелики, а также не требуется подписание контракта, имеется возможность пользоваться сервисами необходимый промежуток времени и оплачивать именно ту сумму, которую потратили.
• Получение учетной записи продавца услуг. Кто-то определенно должен обрабатывать операции с кредитными картами. Они используют Chase Bank. Воспользуйтесь услугами кого-нибудь, кому вы доверяете, а когда масштаб ваших сделок станет существенным — будет возможность получить более выгодные условия контракта.
• Они используют authorize.net в роли шлюза для процессинга операций с кредитными картами.
• Ежемесячным выписыванием счетов занимается специально написанная для этого проекта система. Она запускается каждую ночь, отправляет счета нужным людям и записывает результаты выполненных операций.
• В случае успеха счет-фактура высылается по электронной почте.
• В случае каких-либо сбоев — пользователю отправляется объяснение причин.
• Если три раза с помощью кредитной карты не удается оплатить счет — учетная запись замораживается до тех пор, пока не будет предоставлен платежеспособный номер кредитной карты.
• Обработка ошибок является критичным моментом, так как проблемы с оплатой возникают достаточно часто.
• Все продукты конвертируются для использования централизованным биллинговым сервисом.
• Необходимо быть совместимыми с PCI DSS (Payment Card Industry Data Security Standard).
• Пользуйтесь услугами шлюзов, это позволит не хранить номера кредитных карт на своем сайте, что сильно упрощает жизнь в плане безопасности. Некоторые из них предоставляют и биллинговые услуги, что позволяет также не заниматься этим самостоятельно.

Поддержка пользователей

• Campfire используется для работы с клиентами. По сути эта система представляет собой групповой веб-чат с расширенными возможностями в виде опциональной защиты паролем, личных сообщений, обмена файлами, предпросмотра изображений, а также коллективного принятия решений.
• Поднимаемые вопросы используются для поиска ошибок в коде, а обновление данных в SVN отображается прямо в процессе общения. Bugtracking система обходится стороной, что казалось бы должно лишь усложнять испровление неполадок, например из-за отсутствия возможности проследить связь между конкретным изменением в коде и вызвавшей его неполадкой.
• Зато служба поддержки может решать проблемы клиентов с помощью общения в чате в реальном времени, с возможностью обмена изображениями и снимками экранов, демонстрирующими неисправность.
• Разработчики также всегда доступны с помощью Campfire для помощи в решении проблем клиентов.

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

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

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

Список основных ее особенностей по большей части мало чем отличается от других кластерных файловых систем:

• Состоит из клиентской и серверной частей. Клиентская часть позволяет монтировать файловую систему, а серверная — glusterfsd — экспортировать в нее локальное дисковое пространство.
• Масштабируемость близка к O(1).
• Широкий спектр возможностей за счет использования модульной архитектуры.
• Имеется возможность восстановления файлов и директорий из файловой системы даже без ее инициализации.
• Отсутствие централизованного сервера метаданных, что делает ее более устойчивой к потенциальным сбоям.
• Расширяемый интерфейс выполнения задач, с поддержкой загрузки модулей в зависимости от особенностей выполнения пользователями операций по работе с данными.
• Расширяющий функциональность механизм трансляторов.
• Поддержка Infiniband RDMA и TCP/IP.
• Возможность автоматического восстановления в случае сбоев.
• Полностью реализована на уровне приложений, что упрощает ее поддержание в рабочем состоянии, портирование и дальнейшую разработку.

Но некоторые моменты все же заслуживают отдельного внимания:

Совместимость

Как уже упоминалось, файловая система реализована полностью на уровне пользовательских приложений, что делает возможным ее монтирование без каких-либо дополнительных патчей в ядре операционной системы, единственное требование к нему: поддержка FUSE. Серверная часть GlusterFS может функционировать на любой POSIX-совместимой операционной системе и протестирована на Linux, FreeBSD, OpenSolaris, в отличии от клиентской части, которая может работать только в Linux.

Модули

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

• TCP/IP;
• Infiniband-verbs;
• Infiniband-SDP.

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

• ALU — использует целый ряд факторов, включающий объем свободного локального дискового пространства, активность операций чтения и записи, количество одновременно открытых файлов, скорость физического вращения дисков. Значимость, придаваемая каждому из показателей, может достаточно гибко настраиваться.
• RR — по очереди размещает файлы последовательно на каждом узле, после чего начинает процесс заново, образуя своеобразный цикл. Этот метод эффективен если файлы имеют примерно одинаковый размер, а узлы кластера — одинаковый размер экспортированного локального дискового пространства.
• Random — распределяют файлы случайным образом.
• NUFA — приоритет отдается созданию файлов локально, а не на других узлах кластера.
• Switch — располагает файлы по определенным указанным особенностям имен файлов, по аналогии со switch(filename) в программировании, обычно в качестве критерия распределения файлов имеет смысл использовать их расширение.

Трансляторы

Они представляют собой очень мощный механизм для расширения возможностей GlusterFS, сама идея трансляторов бала позаимствована у GNU/Hurd и заключается она в загрузке бинарных библиотек (.so) в процессе работы системы в зависимости от использованных настроек и использовании их в виде своеобразной цепочки обработчиков при работе с файлами как на серверной, так и на клиентской стороне. В GlusterFS практически все дополнительные возможности реализованы именно виде трансляторов, начиная от дополнений, увеличивающих производительность, заканчивая средствами отладки. Вкратце перечислю основные из них:

• AFR — автоматическая репликация файлов.
• Stripe — разбивает файлы на блоки фиксированного размера.
• Unify — объединяет несколько узлов кластера в один большой виртуальный узел, один узел выделяется для обеспечения внутреннего namespace. Директории создаются на всех узлах, составляющих unify, а каждый файл — лишь на одном (если не используется AFR).
• Trace — предоставляют информацию для отладки в виде дополнительных записей в лог.
• Filter — фильтрация файлов на основании их имен и/или атрибутов.
• Posix-locks — обеспечивает POSIX блокировку записей независимую от используемой системы хранения.
• Trash — предоставляет функциональность сопоставимую с libtrash (или «корзиной» — если так понятнее).
• Fixed-id — обеспечивает доступ только для пользователей с определенными UID и GUID.
• Posix — соединяет GlusterFS с низлежащей локальной файловой системой.
• rot-13 — транслятор обеспечивает возможность шифрования и дешифрования данных по примитивному одноименному алгоритму.

Список возможностей, обеспечиваемых широким набором модулей и транслятором, впечатляет, большинство других opensource кластерных файловых систем не могут похвастаться подобной функциональностью (GlusterFS выпускается под GPL). Благодаря возможности работы через Infiniband производительность передачи данных также достаточно высока — она может достигать десятков гигабит в секунду. Обработка сбоев в отдельных узлах также осуществляется достаточно эффективно, так как может быть автоматизирована. Из потенциальных недостатков можно назвать некоторое количество редко проявляющих себя багов в коде, а также достаточно большой размер заголовков в используемом протоколе (несколько сотен байт). В целом эта система вполне работоспособна и полноценно выдерживает конкуренцию со стороны своих opensource «коллег».