Статистика

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

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

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

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

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

1. Балансировщики нагрузки + не имеющие ничего общего исполнители: в данной модели существует некий входящий поток запросов или заявок, которые поступают через балансировщик(и) нагрузки на один из ряда равноправных узлов-исполнителей, которые каким-то образом генерируют результат запроса и отправляют обратно через балансировщик нагрузки или напрямую. В роли балансировщика нагрузки может использоваться DNS round-robin, различные программные или аппаратные решения, а также их комбинации (иерархии).
2. Балансировщики нагрузки + узлы без состояний + масштабируемое хранилище: для большинства веб-приложений необходимо сохранять некое состояние, и тогда по сравнению с предыдущей моделью вводят в действие систему хранения данных, также приспособленную для горизонтального масштабирования, зачастую ценой отказа от реляционных и прочих комплексных операций, что сводит её интерфейс к простому взять-положить.
3. Принцип «равный-равному» (P2P): заключается в самостоятельном распределении данных и/или задач между равнозначными узлами на основе заранее определенного алгоритма; причем клиент зачастую сам является узлом системы (BitTorrent), либо обращается к произвольному узлу, который становится «агентом» для поиска и делегации конкретного запроса исполнителю (Cassandra).
4. Распределенные очереди: эта модель основывается на выделении очередей, как отдельных сетевых сервисов; используются либо для передачи произвольных данных между компонентами системы, либо для создания очереди выполнения длительных операций (например конвертации фото/видео/аудио).
5. Парадигма подписка/публикация: в системе определяется набор типов событий, одни компоненты системы создают эти события (публикуют сообщения), а другие — хотят узнавать когда произошло событие определенного типа (подписка на сообщения) и каким-то образом реагировать; реализуется обычно в виде отдельного сетевого сервиса, иногда совмещенного с распределенными очередями.
6. «Молва» и прочие похожие на жизнь архитектуры: основная идея заключается в том, что компонентам системы не нужно знать об общей структуре всей сети; узлу достаточно лишь знать о нескольких «соседях», с которыми он будет напрямую взаимодействовать, а распространение информации внутри системы возможно по принципу «молвы», то есть цепного распространения через «соседей»; используется, например, для развертывания кода или упрощения конфигурации в больших кластерах.
7. MapReduce и потоки данных: изначально MapReduce был предложен Google для обработки огромных массивов данных, с которыми они сталкиваются, алгоритм вкратце следующий:
   • Каждый узел в системе считывает с дисков свою часть данных и образует из них пары «ключ-значение»;
   • Эти пары преобразуются в новые промежуточные пары «ключ-значение» по определенному алгоритму (стадия Map);
   • Промежуточные пары сортируются и группируются по ключу и для каждого ключа вычисляется новое значение на основе группы промежуточных значений (стадия Reduce);
   • Результат стадии Reduce обычно и является желаемой информацией, полученной из массива данных, и обычно сохраняется в распределенную файловую систему, либо каким-то образом импортируется в другое хранилище.

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

8. Дерево ответственности: заключается в разложение общей задачи на подзадачи и рекурсивной делегации их выполнения другим узлам системы, что в итоге и образует дерево; используется как часть некоторых других моделей.
9. Обработка входящих потоков: скорее класс задач, чем шаблон, но тем не менее… есть некие внешние события (например сбои в клиентском ПО), обладающие какими-то характеристиками, информация о которых постоянно и непрерывно поступает в систему, которая должна в реальном времени обрабатывать события и получать на основе этих данных требуемую информацию. Реализуется посредством сети обрабатывающих узлов с общем хранилищем информации.
10. Масштабируемое хранилище: их можно рассматривать как отдельный субъект, обладающий свойством масштабируемости; по типам можно выделить базы данных (зачастую не структурированных) и файловые системы.
11. Разделение ответственности запросов на чтение и на запись (СQRS): звучит страшно, на деле еще страшнее, если по-простому, то… модель основывается на обмене сообщениями между равноправными компонентами, хранении, обработке данных в оперативной памяти, асинхронном масштабируемом хранилище данных для их сохранности и репликации компонент для надежности и отказоустойчивости.

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

P.S.: Я недавно участвовал в сессии вопросов-ответов про высоконагруженные и не очень интернет проекты, возможно Вам будет интересно почитать.

В этом году я почти до последнего момента не знал попаду ли на HighLoad++, но благодаря поговорке «не имей сто рублей, а имей сто друзей» все же попал в список участников (огромное спасибо Аксане и ВШБИ). По ходу мероприятия написать традиционный отчет не получилось, но лучше поздно, чем никогда

Начну, как обычно, с организационных моментов и прочих вещей не по делу. Регистрация заняла ровно 30 секунд, никаких очередей. Удивило, что поленились хоть капельку поменять раздаточные материалы и их дизайн с прошлого года — выдали абсолютно идентичные прошлогодним пакетик, блокнот и ручку. На входе стоял стенд с ходящей по беговой дорожке топлесс девушкой с бодиартом, которую потом все кому не лень выкладывали в твиттер с соответствующим хэштегом. На том же стенде разыгрывали Mac Pro между теми, кто оставит контакты. К слову, владельцы стенда оказались разработчиками ужасно работающего под Android 3.1 покерного сервиса, ничего более примечательного о них сказать не могу. Стендов, как обычно, было по пальцам пересчитать: пару хостинг-провайдеров и Битрикс ничем особым не выделались, а в Google тоже разыгрывали технику, один из последних смартфонов Samsung, а еще за прохождение теста в Google Docs дарили футболки с надписью «I’m feeling lucky» на спине — очень актуально на экзаменах и в казино

С WiFi традиционные проблемы почти весь первый день, планшет с 3G спасал ситуацию. Кормили вполне приемлемо, правда ассортимент скудный — я, наверное, за весь год меньше жареной рыбы съел, чем за эти два дня. Первые три ряда мест в залах были «только для VIP», которые, как я понял, включали в себя докладчиков и возможно личных знакомых организаторов, причем таких человек было на вскидку меньше 5% участников и в итоге 95% мест пустовали до тех пор, пока все не забили на эту схему. Определенно не самый удачный ход, если уж и бронировать места, то не в таком количестве. Трансляция одного из залов в коридоре — спорное решение, с одной стороны можно послушать пока ешь, с другой — общаться мешает капитально, особенно когда собираются «тусовки» вокруг докладчика, например во второй день нужно было сильно напрягаться, чтобы услышать Олега Илларионова в кулуарах.

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

Швейцарец Alvaro Videla делился своим опытом работы с RabbitMQ, я, признаюсь, не особо следил за этим проектом, но подал он его достаточно вкусно и судя по обозначенным векторам развития внимания RabbitMQ все же стоит.

Второй докладчик, Buddy Brewer, повествовал о тестировании скорости отрисовки страниц в браузерах как искусственно (посредством диаграммы загрузки компонентов страницы в виде водопада), так и вживую на пользователях (посредством window.performance.timing, о котором я почему-то раньше не слышал, и различных Javascript-библиотек).

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

После обеда шел доклад Domas Mituzas, простого DBA из Facebook, хотя в прошлом году выступал более высокопоставленный представитель. Речь шла на этот раз про MySQL, в частности про основные проблемы и доработки, сделанные в форке от Facebook, также затрагивался вопрос грядущего в следующем году MySQL 5.6.

Josh Berkus в этом году выступил более удачно, не зря ему дали выступить дважды. Первый был довольно специфичным, но от этого не менее интересным, основной темой был довольно узкий класс приложений, который он называл firehose applications (пожарный шланг). Они представляют собой сборщики данных в реальном времени для последующей аналитики, было два примера: обработчик отчетов о критических сбоях в Mozilla Firefox и анализ работы ферм ветряных мельниц. Забавно оказалось их сравнение с традиционными сайтами:

• в сайтах главное, чтобы данные из базы всегда можно было хотя бы прочитать, и в случае сбоев или плановых работ её делают доступной только для чтения;
• в обсуждаемых же приложениех главное записать все поступающие данные, а пользовательский интерфейс в целом можно запланированно и не очень отключать — кому какое дело, если интерфейс для аналитических отчетов не работал 8 часов в ночь с субботы на воскресенье?

В его решениях обычно использовался та или иная форма NoSQL хранилищ, для сбора текущих данных и PostgreSQL для хранения уже обработанных отчетов и предоставления их пользователям. Второй доклад Josh’а был менее формальным и был посвящен вопросам SQL vs NoSQL, что по сути свелось к тому, что наличие SQL-интерфейса — дело десятое при выборе СУБД для конкретного проекта, важнее понимать другие особенности каждого конкретного хранилища данных.

Mi***ft в этом году, как и Facebook, сменил докладчика, но это не уберегло их от очередного провала. Хоть и после доклада появилось-таки несколько вопросов от аудитории, но разработчиков по-прежнему в целом мало интересует тематика проприетарного ПО, даже при поддержке PHP и Hyper-V. Продавать простым смертным у них получается намного лучше, чем продавать специалистам.

Robert Virding был, пожалуй, одним из лучших докладчиков первого дня. Хоть я и неплохо знаком с Erlang, но послушать о нем из уст одного из создателей — невероятно увлекательно, как-будто переживаешь на своей шкуре историю целого языка программирования. Robert очень подробно объяснил чуть ли не каждое ключевое решение, принятое при проектировании и разработке Beam, основной реализации виртуальной машины Erlang, а также освятил несколько альтернативных воплощений этого языка в жизнь.

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

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

Я немного опоздал на первый доклад от mail.ru, но, судя по всему, не много потерял — они снова пропагандировали свое детище, Tarantool, на этот раз в сравнении с Redis. Штука довольно интересная, но каких-то особых преимуществ перед последним я так и не увидел или, может быть, не хотел увидеть.

Представители Skype рассказывали о своем опыте работы с Redis и, в частности, о конкретном кейсе с решардингом «на живую» — довольно увлекательно, красивое решение с фильтрующим replication proxy, которое правда скорее всего скоро потеряет актуальность при текущем направлении развития проекта Redis. Сам активно им пользуюсь, но что-то подобное проделывать пока не приходилось.

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

На докладе OpenStat я тупо сидел в Интернете, особо не вслушиваясь — после их же доклада в прошлом году слушать еще раз примерно о тех же заморочках с Apache Hadoop было не особо интересно, особенно если учесть, что я в 2008-м с ним очень плотно работал.

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

• кроссбраузерное сохранение работы кнопок вперед/назад/перезагрузить без полной перезагрузки страниц,
• кроссбраузерное же постоянное соединение браузера с сервером (используют long polling, websocket по очевидным причинам пока практически не применим),
• сохранение корректной работы с выключенным JavaScript и в «необычных» браузерах,
• выдача нового контента частями через скрытый iframe для улучшения визуальной скорости загрузки страницы,
• эмуляция процесса загрузки страницы через динамический favicon,
• очистка памяти при переходах между страницами,
• использование одного постоянного соединения для нескольких вкладок посредством локального хранилища из HTML5

…и многие другие проблемы и задачи — все это довольно подробно Олег разложил по полочкам. Помимо этого он рассказал как реализован поиск по друзьям внутри браузера через выгрузку списка друзей в JSON, а также целая куча вопросов о том о сем, например про почту и все ту же «волшебную» базу данных на C. Новую статью про Вконтакте я в этом году не планировал, так что особо не записывал, хотя возможно и зря. Выступление Олега слегка продлили, так как следующий докладчик куда-то пропал, но по факту когда он нашелся выступление про новомодный Node.js оказалось не очень и большая часть зала перекочевала «в кулуары» дальше слушать Олега и задавать ему вопросы.

После кофе-брейка я вернулся в первый зал, где продолжалась эпопея с хранением данных. Одноклассники наконец-то поняли, что их старинное решение на BerkleyDB + Java RMI — не панацея от всех болезней, и перешли на другое решение для одной из задач, хранения изображений, не менее самопальное. Задумка была в основном в замене BerkleyDB на традиционные блобы фиксированного размера, аналогично решению в Facebook, при этом остальная схема работы изменилась не сильно — доступ к системе через HTTP посредствам Tomcat, внутри правда отказались от RMI в пользу сокетов и собственного протокола, для хранения конфигурации — Apache Zookeper, типичный для Java-мира наборчик. Из интересных решений — использование JBOD с созданием уникального идентификатора винчестера и возможностью переткнуть любой из них в другой сервер. В остальном ничего особенного: лог транзакций, репликация, индекс в памяти посредством собственной реализации HashMap и т.п.

Последний доклад, который я послушал, был слегка похож на предыдущий, с той лишь разницей, что хостинг-провайдер Clodo не стал изобретать велосипед и воспользовался «полуфабрикатом» под названием Openstack Swift — хранилище бинарных объектов с HTTP интерфейсом, которыми вполне могут быть и изображения. Доклад был о том как они его допиливали, в основном посредством использования nginx и его модулей. К слову, посмотрел их цены (возможно скоро Insight IT придется снова переезжать, приглядываюсь к вариантам) и был разочарован, очень существенно выше рынка не смотря на неизвестность компании, в такой ситуации наоборот логичнее было бы демпинговать…

В целом впечатления от конференции положительные, процент стоящих докладов близок к 20-30%, что для технических конференций очень прилично. Организация и контингент тоже на уровне. Но нельзя не сказать про ценник (21к за живое участие и 11к за онлайн-трансляцию) — он явно рассчитан на оплату работодателями и посещение конференции за собственный счет определенно того не стоит. Альтернативные варианты попасть на мероприятие хоть и есть, но довольно ограничены — каждый раз приходится изворачиваться, чтобы попасть бесплатно при отсутствии работодателя. Хотя может быть надо было просто заморочиться и попасть в список «информационной поддержки»…

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

До встречи на GDD через пару дней!

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

На конференции O’Reilly MySQL CE 2011 выступил Josh Berkus c пламенной речью о том, как быть уважаемым и известным, при этом не уделяя ни капли внимания масштабируемости. Его очень сильно удивляет, почему самыми популярными, известными и инвестиционно-привлекательными интернет-компаниями становятся именно те, чей интерфейс неработающего состояния (в частности «киты» и «роботы» у Twitter), известен больше, чем когда они работают. Так что Josh предлагает всем придерживаться следующей стратегии:

• Всегда следуй трендам: используй только те технологии, которые навели больше всего шумихи в Интернете: NoSQL, «облака», MapReduce,Rails,RabbitMQ. Основным инструментом для выбора технологий должен быть Reddit (или Хабр, если адаптировать к российским реалиям). За что больше голосуют — то и используйте.
• Не следите за текущей ситуацией: математика и статистика — абсолютно бесполезны. Мониторинг использования ресурсов, нагрузочное тестирование, отслеживание трафика, тестирование производительности и тонкая настройка — да кому оно надо? Лучше доверять интуиции — с какими проблемами мы сталкивались на предыдущей работе, с такими же столкнемся и в этот раз
• Ни о чем не беспокойтесь: параллельное программирование не в моде, даже не смотря на то, что Erlang позволяет приложениям работать на кластере из тысяч серверов. Крутые ребята не заботятся об оперативной памяти и управлении потоками. Нужно не париться и использовать однопоточные приложения с кучей блокировок, игнорируя области видимости и контексты памяти. Часто обновляющиеся таблицы из одной строки и мастер-очередь, в которую попадают все задания — лучшие паттерны из всех существующих.
• Каждый запрос должен попадать напрямик в базу данных: кэширование — твой смертный враг. Каждый запрос должен идти напрямую к СУБД, ни шага в сторону!
• Масштабировать нужно невозможные вещи: масштабирование простых и очевидных вещей — для слабаков! Это совершенно не круто заниматься масштабированием веб-серверов, кэшей (хотя ими пользоваться и так категорически запрещено) и серверов предложений.
• Создавайте точки отказа: вне зависимости от того, насколько большой ваш проект, в нем обязательно должно быть место, при отказе которого перестанет работать вся система. Лучшие кандидаты на эту роль: балансировщик нагрузки, очередь задач и мастер база данных.

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

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

Если вы еще не читаете Insight IT регулярно, настоятельно рекомендую подписаться на RSS.

Новая архитектура поиска твитов

Backend

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

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

• Обработка более 12000 запросов в секунду
• Индексация потока в 1000 новых твитов в секунду
• Задержка между написанием твита и его появлением в индексе должна быть менее 10 секунд

Lucene была взята за основу, так как на сегодняшний день это одно из лучших решений для реализации поиска в мире opensource. Но в текущей ее реализации она не была приспособлена к поиску в реальном времени. Команде Twitter пришлось переписать существенную часть основных структур в памяти, особенно списки записей. При этом внешний API Lucene остался неизменным, что позволило использовать поисковые алгоритмы в практически неизменном виде. Среди основных изменений в Lucene можно выделить:

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

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

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

Frontend

Кардинальный переворот в этой части системы можно описать одной фразой: Ruby on Rails заменен на Java-сервер, который они назвали Blender.

За неделю до развертывания Blender, количество поисков по твитам существенно возрасло из-за #tsunami в Японии. Среднее время поиска достигало 800-900мс.

После введения Blender в эксплуатацию среднее время отклика 95% запросов упало втрое: до 250мс, при этом уровень использования вычислительных ресурсов на frontend серверах упал вдвое. Тот же поток запросов стало возможным обрабатывать меньшим количеством серверов.

Чтобы понять, откуда взялся такой прирост производительности, необходимо показать в чем были слабые стороны старого поиска на Ruby on Rails. На каждом frontend сервере было запущено фиксированное количество однопоточных Rails процессов, каждый из которых занимался следующим:

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

Что же, собственно, представляет собой Blender? Это HTTP и Thrift сервер, разработанный на основе Netty, масштабируемой неблокирующей клиент-серверной библиотеки на Java, позволяющей легко и быстро разрабатывать клиенты и серверы для различных протоколов. Выбор пал именно на неё, а не на аналоги (например Jetty или Mina) из-за более чистого API, детальной документации и, что более важно, так как некоторые другие сервисы в Twitter уже используют её. Интеграции с Thrift у нее не было, но этот вопрос решился написанием простого кодека, обрабатывающего сообщения на низком уровне.

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

Заключение

На моей памяти эти нововведения в Twitter — практически единственный случай, когда крупный успешный проект настолько кардинально поменял основную часть стека используемых технологий. Да, они получили существенный выигрыш в производительности не в ущерб масштабируемости, но не поменяли же они большую часть команды разработчиков с Ruby-программистов на Java-программистов… Понятно, что это лишь инструменты, но довольно приличная часть людей, особенно те, кто в возрасте, не способны резко переключиться с привычных технологий на что-то совершенно новое. Хотя, скорее всего, в команде Twitter особо не было разработчиков «за 40″, так что для них это не было особой проблемой.

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

• Twitter Search 3x Faster (cпасибо Сергею Гуляеву за предоставленную ссылку)
• Twitter’s New Search Architecture

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

Оригинал

Не забываем подписываться на RSS

Статистика

• 95 миллионов просмотров страниц в месяц
• 800 HTTP запросов в секунду
• 180 DNS запросов в секунду
• Загруженность интернет-канала в 55 Мбит/с
• 16 миллионов уникальных пользователей в месяц

Технологии

Разработка

• C# — основной язык программирования
• Visual Studio 2010 Team Suite - IDE
• Microsoft ASP.NET 4.0 — framework
• ASP.NET MVC 3 - web Framework
• Razor — генератор шаблонов
• jQuery 1.4.2 — JavaScript framework
• LINQ to SQL и немного чистого SQL — доступ к данным
• Mercurial и Kiln — контроль версий исходного кода
• Beyond Compare 3 — инструмент для сравнения

Программное обеспечение

• WISC стек получен условно-бесплатно с помощью BizSpark
• Windows Server2008 R2 x64 — основная операционная система
• MS SQL Server 2008 R2 на Windows Server 2008 Enterprise Edition x64 — база данных
• Ubuntu Server
• CentOS
• IIS 7.0 — веб-сервер
• HAProxy — балансировка нагрузки
• Redis — используется как распределенная система кэширования
• CruiseControl.NET — сборки и автоматическая система развертывания кода
• Lucene.NET — полнотекстный поиск
• Bacula — резервное копирование
• Nagios (с плагинами n2rrd и drraw) для мониторинга
• Splunk — сбор и агрегация логов
• SQL Monitor от Red Gate — мониторинг SQL Server
• Bind - DNS
• DotNetOpenId — реализация OpenID на .NET
• WMD — текстовый редактор
• Prettify — подсветка синтаксиса
• MarkdownSharp — обработчик разметки Markdown на C#
• Flot — построение графиков на JavaScript

Внешние сервисы

• reCAPTCHA — защита от спама
• Google Analytics — веб-аналитика
• Kiln — Mercurial хостинг
• Pingdom — внешний мониторинг и уведомления
• CDN не используется, его роль выполняет sstatic.net, отдельный домен для статичных файлов SEN без cookie

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

Датацентры

• 1 стойка в Peak Internet, штат Орегон (чат и обнаружение данных)
• 2 стойки в Peer 1, Нью-Йорк (остальная часть SEN)

Серверы

• 10 веб-серверов:
  • Dell R610
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 16 GB RAM
  • Windows Server 2008 R2
  • IIS
• 2 сервера баз данных:
  • Dell R710
  • 2x Intel Xeon Processor X5680 @ 3.33 GHz
  • 64 GB RAM
  • 8 жестких дисков
  • MS SQL Server 2008 R2
• 2 виртуальных сервера для балансировки нагрузки:
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 4 GB RAM
  • Ubuntu Server
  • HAProxy
• 2 сервера для кэша:
  • Dell R610
  • 2x Intel Xeon Processor E5640 @ 2.66 GHz
  • 16 GB RAM
  • CentOS
  • Redis
• 1 сервер для резервного копирования:
  • Dell R610
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 32 GB RAM
  • Linux
  • Bacula
• 1 сервер для мониторинга, управления и сбора логов:
  • Dell R610
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 32 GB RAM
  • Linux
  • Nagios
• 2 сервера для виртуализации:
  • Dell R610
  • 1x Intel Xeon Processor E5640 @ 2.66 GHz
  • 16 GB RAM
  • VMWare ESXi

Сетевое оборудование

• 2 маршрутизатора на Linux
• 5 свитчей  Dell PowerConnect

Прочее

• Rovio — маленький робот, позволяющий удаленным разработчиком посетить офис «виртуально»

Команда

• 14 разработчиков
• 2 системных администратора

Что нового?

• HAProxy стал использоваться вместо Windows NLB так как HAProxy является быстрым, нересурсоемким, бесплатным решением, которое работает. Полностью прозрачен для серверов, легче обслуживать по сравнению со старым решением, располагается на виртуальных машинах.
• CDN не используется, так как даже «недорогие» решения обходятся в очень приличную сумму по сравнению с тем трафиком, который входит в тарифный план хостинг-провайдера. Самое дешевой решение CDN от Amazon обошлось бы как минимум на тысячу долларов в месяц дороже при текущем уровне использования трафика.
• Резервное копирование на диски для быстрого восстановления и на кассеты для «истории».
• Полнотекстный поиск в SQL Server плохо интегрируется, нестабилен и обладает низким качеством результатов, так что они перешли на Lucene.
• Все сайты в SEN теперь работают на общей платформе: используется общее оборудование и программное обеспечение.
• Проект разделен на разные сайты для разных ниш, чтобы полностью изолировать группы аудитории, специализирующиеся в каждой конкретной области.
• Используется агрессивное кэширование, большинство страниц кэшируются в виде HTML для анонимных пользователей средствами IIS.
• Используется три уровня кэширования: локальный, относящийся к каждому сайту и глобальный.
• Локальный кэш доступен только для каждой пары сайт/сервер:
  • Используется для уменьшения сетевых задержек, по сути просто через HttpRuntime.Cache.
  • Содержит такие вещи как пользовательские сессии, будущие обновления счетчиков просмотров страниц.
  • Располагается полностью в оперативной памяти веб-сервера.
• Кэш сайта доступен для каждого сервера, обрабатывающий запрос к конкретному сайту:
  • Большинство кэшируемых данных располагаются здесь.
  • Располагается в Redis.
  • Redis настолько быстр, что большую часть времени доступа к кэшу занимает передача данных по сети.
  • Данные сжимаются перед отправкой в Redis, так как большинство данных являются строками и у них есть масса свободных вычислительных ресурсов.
  • Использование процессорных ресурсов на серверах с Redis стремится к нулю.
• Глобальный кэш является общим для всех серверов и сайтов:
  • Личные сообщения, квоты по API и несколько других по-настоящему глобальных вещей располагаются здесь.
  • Также используется Redis.
• Большинство данных в кэше удаляются через заданный период времени (обычно в районе нескольких минут) и практически никогда явно не удаляются.
• Когда требуется инвалидация кэша на уровне готовых страниц, используется система подписки внутри Redis для отправки сообщений в соответствующую часть системы кэширования.
• Для системы ввода-вывода они выбрали Intel X25 SSD в RAID10. RAID решил многие вопросы с надежностью, а SSD показывают отличную производительностью по сравнению с FusionIO при существенно более низкой цене.
• Стоимость лицензий используемых продуктов Microsoft составила бы 242 тысячи долларов. Но так как они используют программу BizSpark, им не пришлось платить большую часть этой суммы.
• Сетевые карты от Broadcom заменяются на сетевые карты от Intel на основных production серверах. Это решило большинство проблем с потерями соединений, пакетов и таблицами ARP.

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

• Stack Overflow Architecture Update — Now At 95 Million Page Views A Month
• Stack Overflow Blog
• Stack Overflow’s New York Data Center
• Designing For Scalability of Management and Fault Tolerance
• Stack Overflow Search — Now 81% Less Crappy
• State of the Stack 2010 (a message from your CEO)
• Stack Overflow Network Configuration
• Does StackOverflow use caching and if so, how?
• How does StackOverflow handle cache invalidation?
• Which tools and technologies build the Stack Exchange Network?
• How does Stack Overflow handle spam?
• Our Storage Decision
• How are “Hot” Questions Selected?
• Stack Overflow and DVCS
• Server Fault Chat Room

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

Платформа

• 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. Как раз скоро начнется следующий поток

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

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

Используемая в Cassandra логика целостности данных оказалась не достаточно строгой для использования в этом продукте. В Facebook широко используется MySQL, но производительность существенно снижается с ростом массива данных и увеличением размеров индексов. Возможно они взялись бы за разработку нового решения для этой задачи, но их выбор пал на HBase.

HBase представляет собой горизонтально масштабируемую систему хранения таблиц, поддерживающую высокую частоту обновления строк в массивных наборах данных. Звучит как то что надо, для построения новой системы сообщений в Facebook. В основе модели данных HBase лежит концепция BigTable от Google, которая хорошо подходит для поиска строк по идентификаторам, фильтрации и сканированию наборов строк. Из слабых сторон можно назвать отсутствию поддержки сложных запросов, но этот факт компенсируется широким спектром инструментов по аналитике, в том числе и Hive, разработанном в самом Facebook для работы с их многопетабайтным хранилищем данных. Помимо прочего HBase основана на Apache Hadoop и HDFS, с которыми Facebook и так активно работает для анализа данных.

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

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

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

HBase:

• имеет более подходящую модель консистентности, чем Cassandra;
• отлично масштабируется и показывает неплохую производительность при паттернах использования в FB;
• имеет ряд преимуществ благодаря использованию HDFS для хранения данных: репликация, проверка целостности, автоматическая перебалансировка;
• легко поддерживать в Facebook, так как их системные администраторы уже имеют большой опыт со смежными проектами — Hadoop и HDFS.

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

Для сбора сообщений из различных источников используется собственный сервер приложений.

Поиск новых пользователей основан на ZooKeeper.

Продукт тесно с другими сервисами Facebook для:

• Проверка адресов электронной почты
• Определения отношений дружбы
• Настроек приватности
• Решений о транспорте для отправки сообщения (e-mail, SMS, внутреннее сообщение)

Использование смежных проектов Hadoop и Hive стало одним из ключевых факторов, повлиявших на то, что эта технология прижилась как часть экосистемы в таком крупном проекте, как Facebook. Это идеальный сценарий для практически любого продукта: стать партнером успешного популярного продукта в надежде на то, что пользователь воспользуется обоими за компанию — именно по такому пути развивается HBase.

Хочется добавить пару слов от себя: я имел довольно приличный опыт работы с HBase в (уже) далеком 2008 году, на тот момент HBase был самым нестабильным из всех проектов, составляющих экосистему Hadoop. На бумаге HBase и правда выглядит идеальным решением для многих задач, но малейший сбой в метаданных делал всю базу данных неработоспособной, а таковое случалось достаточно часто, обычно по вине HDFS. В том проекте было убито массу времени на попытки «нормализовать» работу связки Hadoop+HBase, но в итоге от последней пришлось отказаться. Очень рад, что этот проект развивается такими семимильными шагами, задумка у проекта изначально была и правда очень стоящая. HBase буквально за пару лет стал пригоден для production использования, да еще и на таком масштабе.  Пройдет еще год-другой, кардинально изменится архитектура Hadoop в лучшую сторону, и HBase наверняка станет лучшей из распределенных систем хранения структурированных данных, доступных на рынке. Если, конечно, Google к тому времени не успеет опубликовать в opensource её прародителя, BigTable

А Вы как относитесь к HBase? Использовали ли на практике? Какие впечатления?

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

• Facebook’s New Real-Time Messaging System: HBase To Store 135+ Billion Messages A Month
• The Underlying Technology of Messages
• See The Messages That Matter
• Facebook Messaging — HBase Comes of Agо

Очень давно хотел написать пост про Dropbox, наверное с тех пор как начал пользоваться этим сервисом. Хоть они и у всех на слуху, но сами ведут себя довольно скрытно в плане публикации информации о себе. Я даже писал им на почту, чтобы выяснить более подробно про технические вопросы, но меня тупо игнорят

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

Статистика

• Прыжок от ста тысяч на момент запуска до 4 миллионов занял всего 15 месяцев:
  • 35% регистраций с реферальной программы
  • 20% от разшаренных папок и других виральных возможностей
• Первый миллион пользователей был набран за 7 месяцев
• На рекламу потрачено 1149$
• За первые 30 дней реферальной программы пользователи отправили 2.8 миллионов прямых приглашений

Как они получили инвестиции?

Эту историю наверняка все уже слышали, но мне кажется нельзя писать об этом проекте не упомянув её. Предыстория такова: Dropbox стартовал в 2007 году, когда на рынке было уже несколько десятков решений для хранения данных в «облаках».

Приходит будущий генеральный директор (Drew) в венчурный фонд (VC):

• VC: Существуют миллионы стартапов, занимающихся хранением данных в облаках!
• Drew: Вы пользуетесь хоть одним из них?
• VC: Нет
• Drew: …

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

Когда «лучшие практики» не являются лучшими

После публичного запуска в сентябре 2008го было запланировано:

• Попасть в TechCrunch50
• Купить контекстной рекламы в Google AdWords
• Нанять PR-агенство

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

По результатам посчитали стоимость привлеченного клиента, которых было в районе 4, и получилось что-то в районе 250-300$ за продукт, который стоит 100$ в год. Epic fail.

Почему так получилось?

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

На самом деле проблема не в AdWords:

• Никто не просыпается утром с мыслями вроде «как бы было здорово не таскать с собой флешку или отправлять самому себе письма с приложенными файлами»
• Подобные проекты существовали и раньше, но никто не ищет специально решения таких незначительных проблем
• Поиск — это способ удовлетворения потребности, а не её создания

Как они получают клиентов без вложений в рекламу?

Например, новость об открытии регистрации на закрытую бету в марте 2008го набрала 12000 голосов на Digg, что повысило число зарегистрировавшихся с 5000 до 75000 буквально за один день

Типичный пользователь Dropbox:

• Узнает о Dropbox от друзей, знакомых, в блоге или на форуме
• Устанавливает и пробует его
• «Я и не знал, что мне это может быть нужно»
• «И правда работает!»
• Неожиданно для себя оказывается доволен и рассказывает об этом друзьям

Я, наверное, типичный представитель

Как только Dropbox поняли, как это происходит на самом деле, они кардинально поменяли маркетинговую стратегию:

• Они дали пользователям механизмы, чтобы проще распространять «любовь» к сервису
• Реферальная программа с бонусами обоим сторонам увеличила количество регистраций на 60%
• Опросы, сплит-тестирование, оптимизация процесса регистрации и главной страницы
• Большие инвестиции в аналитику

Техническая сторона медали

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

Dropbox технически так же прост, как и идеологически:

• Примитивный сайт из нескольких страниц с минимальными возможностями для зарегистрированных пользователей
• API представляет собой минимальный функционал по управлению файлами + аутентификация и информация об аккаунте
• Физически файлы хранятся в Amazon S3
• Безопасность обеспечивается за счет AES-256 шифрования и повсеместного использования HTTPS
• Основной упор в разработке делается на простоту и качество работы клиентских программ, которых разработано уже достаточно много как для всех основных операционных систем, так и для большинства распространенных мобильных платформ

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

• Самый большой риск — сделать что-то, что никому не нужно
• Долго не запускать проект — больно, но не узнать нужен ли он пользователям — фатально
• Как можно скорее дайте что-то пользователям (не обязательно код) и получите отклик максимально быстро
• Узнайте где тусуется Ваша аудитория и постарайтесь общаться с ней в естественной среде обитания
• Много стимулов развивать проект «традиционным путем», но далеко не всегда то, что работает для большинства, сработает и в Вашем случае
• Основная суть проекта должна оставаться таковой вне зависимости от обстоятельств

Спасибо за внимание, подписывайтесь на RSS или Twitter — будете всегда в курсе новых материалов!

_{P.S.: Этот пост посвящается Анечке)}

В далеком 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, приглашаю постоянных читателей и всех остальных потестировать

Это было большим достижением, ведь всего несколько компаний во всем мире способны на реализацию по-настоящему меж-датацентровой системы хранения данных. Помимо SimpleDB, как много других публично-доступных сервисов баз данных могут хранить информацию в нескольких датацентрах одновременно? Теперь эта возможность доступна каждому. Но всему есть цена: так как Megastore использует втрое больше ресурсов, чем обычное Master-Slave хранилище в GAE, стоимость так же увеличивается в три раза. Помимо этого стоит учитывать, что с ростом надежности и издержек, понижается производительность. Именно из-за этого, новая система хранения является альтернативой обычному хранилищу GAE для критичных задач, а не полной заменой.

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

• Megastore совмещает масштабируемость NoSQL систем хранения данных с удобством традиционных СУБД. Оно использовалось для внутренних проектов Google на протяжении нескольких лет. Более 100 приложений, 3 миллиардов транзакций на запись и 20 миллиардов на чтение, более петабайта данных распределены по множеству датацентров по всему миру.
• Megastore — хранилище, разработанное для удовлетворения требований современных интерактивных онлайн сервисов. Используется синхронная репликация для достижения высокого уровня доступности и консистентности. Вкратце, оно предоставляет полную ACID семантику для удаленных реплик с достаточно низкой задержкой, чтобы использоваться в интерактивных приложениях. Хранилище партиционируется и каждая часть реплицируется отдельно, позволяя достичь полного соответствия ACID внутри партиции, но консистентность между ними гарантируется лишь ограниченно. Предоставляются некоторый функционал традиционных СУБД, такой как вторичные индексы, но только те из них, которые масштабируются без сильного негативного влияния на задержки и которые укладываются в семантику используемой схемы партиционирования.
• Paxos используется для управлением синхронной репликацией между датацентрами. Это позволяет достичь очень высокого уровня надежности ценой повышения времени выполнения операций записи. Обычно Paxos используется только для координации, но в Megastore он также используются и для управления записью данных.
• Поддерживается три уровня консистентности при чтении: текущий, снимок и неконсистентный.
• Группы сущностей являются единицей консистентности и транзакционности. Они рассматриваются как маленькие независимые базы данных. Сами же данные внутри каждого датацентра хранятся в масштабируемом NoSQL хранилище.
• Megastore, как и обычное хранилище в GAE, не поддерживает транзакции с использованием нескольких групп сущностей, это существенно повысило бы время их выполнения.
• Группы сущностей — основной механизм группировки данных для быстрого осуществления операций. Их размер и композиция должны быть сбалансированы. В каждом приложении должен найтись способ естественным образом очертить границы групп сущностей. При оптимальном выборе групп сущностей ресурсоемкие кросс-групповые операции будут сведены к минимуму. По сути этот процесс чем-то напоминает нормализацию в реляционных СУБД.
• Запросы с высокими требованиями по консистентности должны быть ограничены одной группой сущностей. Кросс-групповые запросу могут вернуть устаревшие результаты. Это является серьезным отличием в поведении от обычного хранилища GAE, где по-умолчанию используется высокий уровень консистентности для всех запросов, так как операции записи и чтения по-умолчанию происходят с мастера.
• В обычном хранилище GAE иногда отключается в связи с запланированными техническими работами, а также вовремя непредвиденных проблем с инфраструктурой. Megastore в большинстве случаев не страдает этими проблемами.
• Резервирование данных и избыточность достигаются посредством синхронной репликации, снимков и инкрементального лога транзакций.
• API для доступа к данным остался прежним.
• Операции записи могут достигать секунды для каждой группы сущностей, так что для приложений с высокой нагрузкой на запись оно подходит не так хорошо.
• Только новые приложения могут воспользоваться опцией Megastore, существующие приложения необходимо пересоздать, чтобы использовать эту возможность. Впоследствии изменить тип хранилища невозможно.
• Одно приложение не может использовать одновременно обычное хранилище и Megastore. Напрашивается использование одного приложения с Google Megastore для критически важных данных, а другое приложение с обычным хранилищем для всего остального, но такая схема противоречит правилам использования сервиса.
• Автоматической миграции данных между Master/Slave хранилищем и Megastore не существует, разработчики приложения должны сами позаботиться об этом. Google предоставляют лишь набор инструментов и примеров кода, чтобы облегчить процесс миграции.
• В приложениях, использующих Megastore, еще большее  значение приобретает эффективное кэширование данных.

Материалы по теме

• Google Megastore — 3 Billion Writes And 20 Billion Read Transactions Daily
• Megastore: Providing Scalable, Highly Available Storage for Interactive Services
• May 25th Datastore Outage Post-mortem
• Paxos Made Live – An Engineering Perspective
• Choosing a Datastore
• Using the High Replication Datastore
• Bigtable: A Distributed Storage System for Structured Data
• How Google Serves Data From Multiple Datacenters
• Consensus Protocols: Paxos
• Performance comparison

P.S.: По традиции хочу напомнить, что читать Insight IT удобнее всего через RSS-reader.

Что обычно происходит за 20 минут на Facebook?

• Люди делятся миллионом ссылок
• Отмечают друзей на 1323 тысячах фотографий
• Приглашают 1 484 000 знакомых на мероприятиях
• Отправляют 1 587 000 сообщений на стену
• Пишут 1 851 000 новых статусов
• 2 миллиона пар людей становятся друзьями
• Загружается 2.7 миллиона фотографий
• Появляется 10.2 миллиона комментариев 10,208,000
• Отправляется 4 632 000 личных сообщения

За 2010 год:

• 43 869 800 изменили свой статус на «не женат / не замужем»
• 3 025 791 изменили свой статус на «все сложно»
• 28 460 516 изменили свой статус на «есть парень / девушка»
• 5 974 574 изменили свой статус на «помолвлен»
• 36 774 801 изменили свой статус на «женат /замужем»

Хочется узнать больше? Прочитайте статью про архитектуру Facebook.

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

С того момента, как Mollom запустили систему анализа цифрового контента, они выявили более 373 миллионов спам сообщений, обнаружив в процессе что впечатляющие 90% всех прошедших через них сообщений оказались спамом. Весь этот поток спама в 100 сообщений в секунду обрабатывается всего двумя географически распределенными серверами. На каждом из них работает сервер Java-приложений и Cassandra. Так мало ресурсов требуется лишь из-за того, что они создали очень эффективную систему машинного обучения. Разве не круто? Так как же они это делают?

Статистика

• Обслуживаются 40000 активных веб-сайтов, многие их которых принадлежат крупным клиентам, таким как Adobe, Sony BMG, Warner Brothers, Fox News и The Economist. Много крупных брендов, с крупными сайтами, масса комментариев.
• Обнаруживают пол-миллиона спам-сообщений ежедневно.
• Обрабатывается около 100 запросов к API в секунду.
• Проверка сообщения на спам занимает очень мало времени, обычно около 30-50 миллисекунд, 95% запросов укладывается в 250 миллисекунд, когда самые медленные обрабатываются пол секунды.
• Эффективность определения спама составляет 99.95%. Это означает, что из 10000 спам-сообщений Mollom пропустит только 5.
• Netlog, европейская социальная сеть, имеет отдельный Mollom-сервер в своем датацентре. Netlog проверяют на спам около 4 миллионов сообщений каждый день на классификаторах, специально натренированных на их данных.

Платформа

• Java — исторически сложилось, что Mollom был с самого начала был разработан на Java.
• Два сервера обслуживают основную часть клиентов:
  • Один сервер на восточном побережье США, другой — на западном
  • В случае сбоя один сервер может полностью подменить другой
  • Конфигурация обоих: Intel Xeon Quad core, 2.8GHz, 16GB RAM, 4 диска по 300 GB, RAID 10.
• SoftLayer — хостинг-провайдер.
• Cassandra — NoSQL база данных, выбранная из-за высокой производительности на запись и способности работать на серверах, располагающихся в разных датацентрах (была разработана в Facebook, но там практически не используется).
• MySQL — Java Persistence API используется для обычных наборов данных, когда Cassandra используется для больших объемов данных.
• Glassfish — open source сервер приложений для платформы Java EE. Они выбрали именно Glassfish за его возможности корпоративного уровня, такие как репликация и обработка сбоев.
• Hudson — предоставляет непрерывное тестирование и развертывание кода серверной части на всех используемых машинах.
• Munin — измерение и построение графиков, касающихся здоровья серверов.
• Pingdom — внешний мониторинг.
• Zendesk — используется для оказания поддержки клиентам.
• Drupal — используется для основного сайта со специализированным модулем интернет-магазина.
• Unfuddle — хостинг Subversion для взаимодействия удаленной команды разработчиков.

Как это работает?

Процесс выглядит следующим образом:

• Когда пользователь отправляет комментарий на сайт, происходит запрос к API Mollom.
• Контент анализируется, если он оказывается спамом, то сайту сообщается, что необходимо его заблокировать, если же алгоритм не уверен на 100% — сайту советуют показать CAPTCHA, которую сервис также предоставляет.
• После того, как CAPTCHA будет успешно заполнена, контент принимается. В большинстве случаев пользователи не будут ее видеть и контент будет приниматься сразу же.

Обнаружение спама является сложным балансом между отказом нормальному контенту и принятию спама.

Бизнес-модель

• Основным залогом популярности Mollom является бесплатная возможность попробовать сервис, ограничение составляет 100 нормальных (не спам) сообщений в день. Небольшие сайты могут никогда и не достичь этого ограничения.
• Далее есть два тарифа: 1 евро в день и 3600 евро с возможностями вполне соответствующими этим суммам
• Сайты, использующие бесплатный тариф, вовсе не зря тратят ресурсы системы, как кажется на первый взгляд, а являются жизненно-важным источником данных для тренировки системы. Без этих данных алгоритмы были бы существенно менее точны.

Архитектура

• Разработчики Mollom уделяют максимум внимания времени отклика, эффективности кода и использования серверных ресурсов.
• Физически каждый сервер может справиться со всеми запросами, два сервера нужны для избежания перерывов в работе системы. Когда оба сервера в строю — работа распределяется между ними, когда один падает — второй перехватывает его запросы.
• Mollom прошел через несколько этапов развития:
  1. Изначально маленькая команда из двух человек работала вечерами над основными алгоритмами, классификаторами и реальными бизнес-задачами, которые они пытались решить. Для построения инфраструктуры серверной части они использовали свои реализации базовых механизмов по управлению ресурсами, соединениями и потоками. В итоге они обнаружили, что тратят слишком много времени на эти вещи. После этого они переключились на Glassfish, что позволило им намного меньше беспокоится об управлении памятью, REST-запросах, парсинге XML и поддержании пула соединений с базой данных.
  2. В прошлом основной проблемой была пропускная способность дисковой подсистемы. Они должны хранить информацию о репутации всех IP-адресов и URL по всему Интернету, что привело к массивному набору данных с большим количеством случайных обращений.
  3. Поначалу они использовали MySQL на недорогой виртуальной машине, что в итоге не смогло масштабироваться.
  4. Они перенесли данные на твердотельные жесткие диски (SSD) и стали все хранить в файлах. Этот шаг решил проблемы с записью, но возникли новые проблемы:
     1. Это правда дорого.
     2. Очень чувствительно к типу используемой файловой системы
     3. Запись стала происходить быстрой, но итерация по большим наборам данным (что они делали довольно часто для очистки данных и обучения классификаторов) по-прежнему была очень медленным процессом.
  5. В итоге они отказались от твердотельных накопителей и стали использовать Cassandra.
• Cassandra сейчас используется для обработки интенсивного потока запросов на запись и в роли кэша:
  • Работает на RAID10, что хорошо подходит для высоких смешанных нагрузок на запись/чтение.
  • Cassandra оптимизирована для записи, а в Mollom запись как раз происходит намного чаще, чем чтение.
  • Разработана для распределенной работы как внутри датацентра, так и между датацентрами.
  • Обратной стороной медали является отсутствие стандартного NoSQL интерфейса, что усложняет реализацию приложений.
  • Механизм кэширования строк в Cassandra позволяет им не использовать отдельную систему для кэширования, что существенно упростило код приложения.
  • Cassandra имеет функцию удаления устаревшей информации после определенного периода времени. В Европе существуют строгие законы о приватности личных данных, согласно которым они должны храниться не более определенного срока (штаб-квартира Mollom находится в  Бельгии). В этом плане эта функция очень удобна. Эта функция опять же избавляет от необходимости реализовывать данный функционал вручную.
• Типичный путь одного комментария внутри системы:
  • Балансировка нагрузки между серверами лежит на клиентской библиотеке, в роли типичного клиента может выступать сайт на Drupal, осуществляющий запрос к API через XML-RPC или REST.
  • Запросы обрабатываются сервером приложений Glassfish и проходят стандартный процесс обработки с помощью сервлетов и специфичных классов.
  • Платящие клиенты обслуживаются в первую очередь, что приводит к тому, что клиенты на бесплатном тарифе могут ожидать результата несколько дольше.
  • Запрос анализируется и оценка вероятности спама возвращается пользователю. Помимо этого отдельная часть кода Mollom отвечает за генерацию, выдачу и проверку CAPTCHA.
  • Классификаторы полностью располагаются в оперативной памяти. Небольшой кусок контента разбивается на тысячи и тысячи крошечных частей, которые могут быть идентифицированы как спам. Такие классификаторы хранят в памяти до нескольких миллионов признаков, характерных для спама. Анализ должен выполняться очень быстро, так что никаких других вариантов кроме расположения всех требуемых данных в оперативной памяти просто не было.
  • В Cassandra хранятся очки репутации, частоты, URL и IP-адреса.
  • Струтуры данных в памяти не реплицируются напрямую. Они записываются в Cassandra, которая и передает их на второй сервер. Промежуток времени, когда данные не консистентны, очень невелик, так что это не сказывается негативно на алгоритмах.
• Балансировка нагрузки с помощью клиента:
  • Mollom использует такой подход к балансировке, так как стартап не может себе позволить дорогой железный балансировщий нагрузки. Если учесть, что им нужна балансировка между датацентрами, решение от любого из вендоров было бы комплексным и дорогим.
  • У каждого клиента есть индивидуальный список серверов, которыми он может воспользоваться. Этот список изменяется через API.
  • Каждый клиент может использовать разный список, платящим клиентам могут предоставлять отдельные сервера для уменьшения задержек.
  • Если сервер упал — клиент пытается подключиться к следующему серверу в списке.
  • С другой стороны такой подход усложняет разработку неофициальных клиентов: авторам проекта приходится тесно работать с разработчиками сторонних клиентов для обеспечения правильной реализации в них балансировки нагрузки.
• Машинное обучение:
  • Mollom — это набор самообучающихся систем. Отдельные CAPTCHA-решения, не учитывают ни пользовательское поведение, ни источник контента, заставляя каждого пользователя вводить проверочный код при каждом сообщении. В случае с Mollom это происходит только когда система анализа контента не уверена в конкретном решении.
  • Средняя длина сообщения — 500 символов, обычно оно разбивается на 3000 характеристик. Принадлежность контента к спаму определяется путем оценки репутации IP адреса или Open ID, пользовательского идентификатора, эмоциональной окраски, языка, профанации, проверки на наличие специфичных слов и фраз, также учитывается качество написания текста и многие другие факторы. Все эти данные основываются на классификаторах. Некоторые из них статистические по природе, так что обучение происходит автоматически. Другие же основываются на правилах для того, чтобы быть уверенными, что они никогда не могут быть настроены неверно. Комбинация результатов всех тестов после нормализации и образует финальный рейтинг принадлежности к спаму каждого конкретного сообщения.
  • Классификаторы и внутренние метрики обучаются с каждым новым сообщением и обновляются в реальном времени.
• Glassfish берет на себя планировку нагрузки, учитывая многоядерность системы:
  • Ключ к дизайну системы в многопроцессорном окружении заключается в максимальном параллелизации работы при минимальном простое из-за блокировок.
  • Они используют 16 thread’ов на сервер.
  • Большинство запросов обрабатываются сессионными объектами (Java Bean), не имеющими состояний. Они хорошо подходят для управления параллельными запросами.
  • Они держат пул из нескольких cессионных объектов, но определение их количества делегируется Glassfish. В пиковую нагрузку это число увеличивается для более эффективной обработки запросов, порой оно достигает 32.
  • Все классификаторы реализованы как раз как такие объекты, повторно использующиеся различными thread’ами.
  • У каждого объекта есть свое клиентское соединение с Cassandra, чтобы гарантировать отсутствие блокировок.
  • Когда пользователь не отвечает на CAPTCHA сессия очищается и Mollom узнает что это скорее всего был спам.
  • На каждом сервере запущено по одной копии каждого классификатора.
  • В момент очистки сессии происходит небольшая блокировка, когда происходит обновление классификаторов.
  • Обновленные классификаторы записываются в Cassandra каждые пол часа.
• Интеграция приложений:
  • Mollom использует открытый API, который может быть интегрирован в любую систему.
  • Библиотеки: Java, PHP, Ruby и другие.
  • Готовые модули: Drupal, Joomla, WordPress и прочие системы управления контентом.
  • Решения от сторонних разработчиков, основанные на примерах кода от  Mollom.
• Для мониторинга здоровья серверов они используют Munin:
  • Каков размер heap памяти после сбора мусора?
  • Каково количество доступных соединений?
  • Каково количество thread’ов в пуле?
  • Оценка времени блокировок в каждом thread’е.
• Если взглянуть в целом на архитектуру Mollom, можно увидеть, что они стараются построить систему, способную прозрачно работать в нескольких датацентрах, чтобы позволить горизонтально расширить систему, когда они перерастут текущую двухсерверную конфигурацию:
  • Балансировка нагрузки на клиенте позволяет выбирать оптимальный сервер и справляться со сбоями одного из них.
  • Кластеризация Glassfish облегчает добавление/удаление новых машин и позволяет перехватывать запросы, когда один из серверов выходит из строя.
  • Cassandra используется для управления данными между серверами в нескольких датацентрах.
• Инсталляция Mollom в Netlog обладает некоторыми интересными характеристиками. Она обрабатывает больше сообщений, чем основные сервера Mollom, но распределение спама в ней совершенно другое, так как люди в ней общаются в рамках социальной сети. Внутри Netlog лишь 10% сообщений является спамом, когда в суровом мире информационных порталов распределение обратно. Интересным следствием является тот факт, что обработка нормальных сообщений требует меньше вычислительных ресурсов, так что на аналогичном оборудовании удается обрабатывать больший поток сообщений.
• Изначально они думали о виртуализированных серверах, в частности об Amazon EC2, но в итоге обнаружилось, что наиболее узким местом являются операции ввода-вывода — низкая производительность дисковой подсистемы в виртуальных машинах создавали реальные проблемы, так что они решили воспользоваться вертикальным масштабированием и переехали на более дорогие физические машины с большим объемом дискового пространства:
  • На удивление они не упираются в вычислительные ресурсы: лишь два ядра из 8 занимаются вычислениями, когда остальные же работают над операциями ввода-вывода.
  • Трафик Mollom практически постоянен, так что физические сервера более эффективны с финансовой точки зрения. Они рассматривают Amazon лишь как запасной вариант для обработки непредвиденных пиков нагрузки.
• Процесс разработки:
  • Команда распределена: трое в Бельгии, остальные в Техасе, Бостоне и Германии.
  • Scrum используется в процессе разработки и они довольны этой методологией. Scrum-собрание проходит через Skype в два часа дня по Бельгии.
  • Разработчики работают локально и отправляют код на Unfuddle.
  • Hudson используется для непрерывного интеграционного тестирования. Hudson позволил облегчить миграцию, так как перед развертыванием все тесты должны быть пройдены. Они не теряли лишнего времени на проблемах, обнаруженных уже в развернутом приложении.
  • Они активно используют автоматическое тестирование: юнит-тесты, системные тесты, тесты Drupal.
  • Развертывание по-прежнему делается вручную для минимизации риска простоя (что правда спорный момент).
  • Для обнаружения утечек памяти они используют анализ дампов оперативной памяти. Анализ дампа сервера с 16Гб памяти — дело непростое, практически невозможное на обычном компьютере, так что они арендуют большую виртуальную машину на Amazon для проведения анализа. Весь процесс занимает всего около 2 часов. Они сравнивают два дампа: через 10 и 20 часов после запуска сервера. Если обнаруживаются значительные отличия, то скорее всего дело в утечке памяти.

Пути развития

• Mollom API основано на XML-RPC, REST-интерфейс находится на стадии тестирования для облегчения интеграции других сервисов.
• Они мигрировали на Cassandra, чтобы облегчить процесс горизонтального масштабирования, когда нагрузка достигнет соответствующего уровня.
• Скоро будут выпущены корпоративные возможности, которые позволят работать с сотнями сайтов как с единым целым. Появится возможность легко модерировать несколько сайтов одновременно по эмоциональной окраске сообщений, рейтингу спама или удалить все сообщения с определенного IP-адреса.
• Они думали над участием в бизнесе потоковых данных вроде Twitter, но они сильно ограничены европейскими более строгими требованиями по приватности.
• Планируются эксперименты по использованию Glassfish для балансировки нагрузки в рамках каждого датацентра.
• Если нагрузка увеличится десятикратно им придется добавить больше серверов в Cassandra. Дисковый ввод-вывод является узким местом. Дополнительные сервера приложения понадобятся только если нагрузка вырастет более, чем на порядок.

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

• Mollom очень серьезно относится к разработке высокопроизводительной системы. Они гордятся тем, что Mollom очень эффективно использует вычислительные и финансовые ресурсы. Множество запросов может обрабатываться одним сервером с низкой задержкой, что очень радует как клиентов, так и владельцев проекта, так как издержки очень низки. Этот вопрос был выбран приоритетным с самого начала и они выбрали подходящие технологии для реализации своих целей. Это позволило им вкладывать средства в маркетинг, построить базу клиентов и создавать новые продукты на основе Mollom.
• Машинное обучение требует много исходных данных для успешного обнаружение спама. Для сбора этих данных предлагает бесплатные услуги. Крупные клиенты обеспечивают доход и получают выгоду от данных, полученных от более мелких клиентов. Эта модель очень хорошо себя проявила в машинном обучении, за которым как известно будущее.
• Старайтесь избавиться от проблем, не связанных напрямую с продуктом. Большие системы требуют серьезных усилий на разработку инфраструктуры. Можно убить все время на построение инфраструктуры, вместо создания по-настоящему ценного продукта (классификаторов, системы репутации, клиентских библиотек). Mollom постоянно пытались максимально избавляться от лишних проблем, именно по-этому они выбрали Cassandra и Glassfish.
• Будьте осторожны с клиентским кодом. Выполнение кода на клиентской части привлекательно тем, что он тратит чужие ресурсы, а не серверные. Проблемы начинаются когда сторонние библиотеки разрабатываются некачественно, что заставляет систему в целом работать плохо. Плотно работайте с разработчиками клиентских библиотек для повышения качества их продукции.
• Отдавайте приоритет платящим клиентам. Платящие клиенты получают более высокое качество услуг, обрабатываются вне очереди, получают меньше задержек и получают доступ к запасному серверу когда основной дал сбой. Этого вполне достаточно, чтобы подтолкнуть клиентов платить.
• Уменьшайте объем кода, позволяя используемым сторонним продуктам брать на себя грязную работу. Поначалу код Mollom был существенно большим по объему, чем сейчас. Использование Cassandra и Glassfish позволило убрать массу кода, связанного с кэшированием, кластеризацией, репликацией и обработкой сбоев. Упрощайте систему со временем.
• Минимизируйте блокировки. Mollom потратили много времени на устранение блокировок внутри Glassfish, так как это начинало становиться узким местом. Минимизируйте простой от блокировок для достижения полного параллелизма.

Источники информации и дополнительные материалы

• Mollom Architecture — Killing Over 373 Million Spams At 100 Request Per Second (основной источник информации)
• Mollom Technical Whitepaper
• Episode #072 — Mollom.com’s GlassFish backend with Dries and Johan
• Mollom gets a new backend
• Fighting spam with Mollom on Glassfish
• Mollom API

Если Вам понравилась данная статья, можете ознакомиться с другими материалами по архитектуре высоконагруженных систем и подписаться на 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 никогда не поздно.