Insight IT

Архитектура Plenty of Fish

Иван Блинков — Mon, 18 Jan 2010 16:43:00 +0300

Plenty of Fish представляет собой очень популярный сервис онлайн знакомств, насчитывающий более 45 миллионов посетителей в месяц и 30+ миллионов просмотров страниц в сутки (что составляет около 500-600 страниц в секунду). Но это не самая интересная часть истории... Все это управляется единственным человеком при использовании нескольких серверов, при этом он тратит на работу всего пару часов в день и зарабатывает 6 миллионов долларов на рекламе от Google. Завидуете? Я тоже :) Как же ему удалось соединить столько влюбленных пар, используя так мало ресурсов?

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

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

Платформа

Microsoft Windows
ASP.NET
IIS
Akamai CDN
Foundry ServerIron Load Balancer

Статистика

PlentyOfFish (POF) имеет 1.2 миллиарда просмотров страниц в месяц, в среднем 500 тысяч уникальных авторизованных пользователей в день. Пиковый сезон приходится на январь каждого года, когда эти цифры возрастают на 30%.
POF имеет единственного сотрудника: создатель и генеральный директор Markus Frind.
Зарабатывает до 10 миллионов долларов в год на рекламе от Google, работает при этом только около двух часов в день.
30+ миллионов просмотров страниц в день (500 - 600 страниц в секунду).
1.2 миллиарда просмотров страниц и 45 миллионов посетителей в месяц.
Имеет CTR в 5-10 раз выше, чем Facebook.
Находится в top 30 сайтов США по данным Competes Attention, top 10 в Канаде и top 30 в Великобритании.
Нагрузка балансируется между двумя веб-серверами с 2 Quad Core Intel Xeon X5355 @ 2.66Ghz, 8GB RAM (используется около 800 MB), 2 жесткими дисками, работают под управлением Windows x64 Server 2003.
3 сервера баз данных. Информация об их конфигурации не предоставляется.
Приближается к 64000 одновременных соединений и 2 миллионам просмотрам страниц в час.
Интернет-канал в 1Gbps, из которых используется только 200Mbps.
1 TB трафика от отдачи 171 миллионов изображений через Akamai.
6TB система хранения данных для обработки миллионов полноразмерных изображений, которые загружаются на сайт каждый месяц.

Что внутри?

Модель монетизации заключалась в использовании рекламы от Google. Match.com, для сравнения, получает 300 миллионов долларов в год, в основном с платных подписок. Источник дохода POF должен измениться, чтобы позволить ему получать больше выручки от имеющихся пользователей. Планируется нанять больше сотрудников, в частности людей, которые будут заниматься продажей рекламы напрямую вместо того, чтобы полностью полагаться на AdSense.
При 30 миллионах просмотрах страниц в день можно зарабатывать неплохие деньги на рекламе, даже если CPM будет всего 5-10 центов.
Akamai используется для отдачи более 100 миллионов изображений в день. Если на странице 8 изображений и каждое загружается за 100 миллисекунд - их загрузка займет почти секунду, так что распределение изображений целесообразно.
Десятки миллионов изображений отдаются с серверов POF, но большинство из них размером меньше 2KB и практически полностью закешированы в оперативной памяти.
Все динамично. Практически никакой статики.
Все исходящие данные сжимаются с использованием Gzip, что обходится всего 30% использованием процессорного времени. Используется много вычислительных ресурсов, но зато существенно сокращается использование пропускной способности интернет-канала.
Кэширование ASP .NET не используется, так как данные теряют свою актуальность практически сразу же.
Встроенные компоненты ASP также не используется. Почти все написано с чистого листа. Ничего не может быть более сложным, чем кучка простых if-then-else и циклов. Все максимально элементарно.
Балансировка нагрузки:
IIS произвольно ограничивает общее количество соединений до 64000, таким образом балансировщик нагрузки был добавлен для обработки большего количества одновременных соединений. Вариант с добавлением второго IP адреса и использованием round robin DNS также рассматривался, но вариант с балансировщиком нагрузки выглядел более избыточным и позволял более легко расширять количество серверов. Помимо этого ServerIron позволял использовать более продвинутую функциональность, вроде блокировки ботов и балансировку запросов по cookies, сессиям или IP-адресам пользователей.
Windows Network Load Balancing (NLB) функция не использовалась, так как не поддерживает привязку сессий к серверам. Обходным путем было бы хранение сессионных данных в базе данных или общей файловой системе.
8-12 NLB серверов могут объединяться в кластер и может использоваться неограниченное количество таких кластеров. Схема DNS round robin может использоваться для распределения запросов между кластерами. Теоретически такая архитектура могла бы позволить 70 веб-серверам обрабатывать более 300 тысяч одновременных соединений.
NLB имеет опцию для отправки каждого пользователя на конкретный сервер, таким образом не используется внешнее хранилище для сессионных данных и если сервер выходит из строя - пользователи просто разлогиниваются из системы. Если это состояние включает в себя например корзину интернет-магазина или какую-то другую важную информацию, то такой подход мог бы показаться неприемлемым, но для сайта знакомств это было бы не так критично.
Было решено, что хранение и получение сессионных данных программными средствами слишком дорого. Аппаратная балансировка нагрузка проще: пользователи просто назначаются конкретным серверам и в случае сбоя сервера назначенным ему пользователям предлагается пройти процесс авторизации еще раз.
Покупка ServerIron была дешевле и проще, чем использование NLB. Многие крупные сайты используют их для создания пулов TCP соединений, автоматическому определению ботов и так далее. ServerIron может делать намного больше, чем просто балансировать нагрузку и такие функции достаточно привлекательные за эту цену.
Была большая проблема с выбором системы размещения рекламы. Многие из них хотели несколько сотен тысяч в год и многолетний контракт.
В процессе избавления от ASP.NET повторителей и использование взамен конкатенации строк или response.write. Если у вас миллионы просмотров страниц в день - просто напишите весь код для отображения на экране пользователя.
Большинство изначальных вложений ушло на построение SAN. Избыточность любой ценой.
Рост был за счет вирусного эффекта. Портал начал набирать популярность в Канаде, затем о нем узнали в Великобритании и Австралии, и только потом в США.
База данных:
Одна база данных является основной.
Две базы данных для поиска. Поисковые запросы распределяются по их типу.
Производительность наблюдается через диспетчер задач. Когда появляются пики - ситуация рассматривается более детально. Проблемы обычно заключались в блокировках на уровне СУБД. Собственно говоря почти всегда это были проблемы с базами данных, очень редко они возникают на уровне .NET. Так как POF не использует библиотеки .NET, отследить проблемы с производительностью оказывается достаточно просто. Если бы использовалось много уровней framework'ов, поиск мест, где скрываются проблемы, был бы трудным и утомляющим.
Если Вы делаете запрос к базе данных 20 раз при отображении одной страницы, Вы проиграли в любом случае, вне зависимости от того, что Вы будете делать.
Разделяйте запросы чтения и записи к базе данных. Если у вас нет избыточного количества оперативной памяти не следование этому правилу может заставить систему зависнуть на несколько секунд.
Постарайтесь делать базы данных только для чтения.
Денормализуйте данные. Если Вам приходится доставать данные из 20 разных таблиц, попробуйте сделать просто одну таблицу, где будут лежать все нужные для чтения данные.
Один день может проработать почти что угодно, но когда Ваша база данных удвоится - использованные подход может внезапно перестать работать.
Если система делает только что-то одно, она будет делать это реально хорошо. Только записывайте данные и все будет нормально. Только читайте данные и все будет нормально. Делайте и то и другое - и все испортится. База данных погрязнет в проблемах с блокировками.
Если Вы полностью используете вычислительные мощности, Вы либо делаете что-то не так, либо Ваша система на самом деле очень оптимизирована. Если вы можете разместить всю базу в оперативной памяти - обязательно делайте это.
Процесс разработки выглядит примерно следующим образом: появляется идея, быстро реализуется и выдается пользователям в пределах 24 часов. Отклик от пользователей получается по слежению за тем, что они делают на сайте: выросло количество сообщений на пользователя? среднее время сессий выросло? Если пользователям новая фишка не пришлась по вкусу - просто уберите её.
При небольшом количестве серверов системные сбои достаточно редки и краткосрочны. Наибольшими сложностями были проблемы с DNS, когда некоторые интернет-провайдеры говорили, что POF больше не существует. Но так как сайт бесплатен, пользователи нормально относятся к небольшим периодам его недоступности. Люди часто не замечают простой сайта, так как думают, что это какая-то проблема у них, с интернет-соединением или еще чем-то.
Переход от миллиона пользователей к 12 миллионам пользователей был большим прыжком. Система может обслуживать и 60 миллионов пользователей с двумя веб-серверами.
Часто смотрите на конкурентов для идей новых функциональных возможностей.
Рассмотрите использование чего-то вроде S3, когда система начнет требовать географической балансировки.

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

Вам не нужны миллионы в финансировании, размашистая инфраструктура и целое здание сотрудников для того, чтобы создать вебсайт мирового уровня, который обслуживает кучу пользователей и приносит неплохие деньги. Все что нужно - всего лишь привлекательная идея, которая понравится большому количеству идей, сайт, который становится популярным благодаря слухам, а также опыт и видение для построения сайта, не наступая на типичные "грабли". Вот и все, что Вам нужно :-)
Необходимость - мать всех изменений.
Когда вы растете быстро, но не слишком быстро, у Вас появляется шанс расти, модифицировать и адаптироваться.
Максимальное использование оперативной памяти решает массу проблем. После этого рост возможен просто за счет использование более мощных серверов.
В начале старайтесь держать все максимально простым. Практически все дают этот же самый совет, а Markus говорит, что все что он делает - всего лишь очевидный здравый смысл. Но то что просто, не всегда означает всего лишь осмысленную вещь. Создание простых вещей является результатом многих лет практического опыта.
Поддерживайте время доступа к базе данных быстрым и у Вас не будет проблем.
Одной из основных причин, по которой POF может работать с таким небольшим количеством сотрудников и оборудования, является использование CDN для отдачи активно используемого контента. Использование CDN может оказаться секретным соусом для многих крупных сайтов. Markus считает, что в top 100 не существует ни одного сайта, не использующего CDN. Без CDN время загрузки страницы в Австралии возросло бы до 3-4 секунд только за счет изображений.
Реклама на Facebook принесла плохие результаты. Из 2000 кликов только 1 человек регистрировался. С CTR равным 0.04% Facebook выдавал 0.4 клика на 1000 показов рекламы (CPM). При 5 центах CPM = 12.5 центов за клик, 50 центах CPM = 1.25\$ за клик. 1 доллар CPM = 2.50\$ за клик. 15\$ CPM = 37.50\$ за клик.
Это просто продавать несколько миллионов просмотров страниц с высоким CPM, но НАМНОГО сложнее продавать миллиарды просмотров с высоким CPM, как это делают Myspace и Facebook.
Модель монетизации, основанная на рекламе, ограничивает Ваши доходы. Вам придется переходить к платной модели чтобы повышать прибыль. Генерировать 100 миллионов долларов в год за счет бесплатного сайта практически невозможно - Вам потребуется слишком большой рынок.
Повышение количества просмотров за счет Facebook не работает для сайтов знакомств. Иметь посетителя на собственном сайте намного более прибыльно. Большинство просмотров страниц на Facebook находятся за пределами США и Вам придется делить 5 центов CPM с Facebook.
Предложение пользователям при регистрации получить информацию об ипотеке или каком-то другом продукте, может стать неплохим источником дополнительной выручки.
Вы не можете постоянно прислушиваться к отзывам пользователей. Кому-то всегда будут нравиться новые функции, а кто-то всегда будет их ненавидеть, но только часть из них сообщит Вам об этом. Вместо этого лучше смотреть как новые функции влияют на то, чем люди на самом деле занимаются, просто смотря на Ваш сайт и статистику его использования.

Aladdin от Baidu

Иван Блинков — Thu, 14 Jan 2010 00:01:00 +0300

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

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

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

О компании Baidu

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

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

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

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

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

Aladdin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нам два годика

Иван Блинков — Sun, 03 Jan 2010 23:59:00 +0300

В общем судя по всему я решил считать 3 января 2008 года Днем Рождения Insight IT, так что как раз самое время написать очередной бестолковый "праздничный" пост, по совместительству выполняющий роль "новогоднего" (надо же поздравить всех читателей с Наступившим, хоть и несколько поздновато; отметил я просто замечательно и три дня провел без интернета). В повестке дня у нас сегодня обзор основных событий прошедшего года и планы на наступивший, кому интересно - читаем дальше ;)

Как не сложно увидеть по датам постов - первые 10 месяцев года прошли очень пассивно для данного блога. Я был весь в работе и учебе, постов писал мало, на комментарии отвечал редко - в общем халтурил по полной программе. Впрочем время для меня зря не прошло - успел получить степень бакалавра Бизнес-Информатики и поступить в магистратуру на программу "Электронный бизнес". В дополнение к общему затишью ложку дегтя добавлял теперь уже бывший хостинг провайдер (по прежнему не хочу устраивать анти-рекламу, российская компания с доменом из двух букв, кому было интересно уже наверное давно успели посмотреть) - возможно кто-то из читателей помнит эти регулярные проблемы с доступностью сайта, некоторые из которых даже доходили до простоев более двух недель подряд.

На этом в общем-то негативные стороны заканчиваются, так что перейдем к положительным моментам. Во-первых, блог переехал-таки на новый хостинг в США: там существенно более ответственно относятся к клиентам, отличная техподдержка, пока никаких сбоев, современное оборудование, никаких фиксированных ограничений по трафику/дисковому пространству/процессорному времени/чему-то еще в этом духе - в целом пока вижу в данном решении почти только плюсы, из минусов разве что чуть больший пинг и цена на 500р./год выше. Во-вторых, в октябре я остался без работы - про это я уже рассказывал достаточно подробно, повторяться не буду. В общем у меня стало появляться существенно больше свободного времени, которое я мог позволить себе тратить на блог. Не трудно заметить возросшую активность как в постах, так и в комментариях, циферки в статистике Google Analytics, Feedburner и Wordpress.com Stats достаточно резво растут вверх и я надеюсь, что эта тенденция продолжится и на протяжении всего наступившего года. Уже накопилась масса идей для новых постов - осталось только найти в себе силы материализовать их.

Вообще я уже почти три месяца сижу без работы и почему-то чем дальше - тем менее активно ищу новую. Некоторое время назад, примерно одновременно с принятием решения о смене хостинга, мне пришла в голову идея попробовать зарабатывать на Insight IT, чтобы позволить себе оттягивать процесс поиска работы как можно дальше. Сначала попробовал наиболее "гуманный" по отношению к читателям метод, который более-менее сносно работал в 2008 году - поставил побольше блоков Google AdSense. Оказалось больше не работает, цены за клик упали в 3-5 раз, да и CTR ниже плинтуса. Этот факт подтолкнул меня создать появившуюся в меню навигации несколько дней назад страничку "Реклама" (возможно кто-то уже успел ознакомиться), основная идея - я готов размещать ту или иную форму рекламы напрямую, без посредников в виде бирж или каких-то других автоматизированных систем. Очень надеюсь, что кто-то заинтересуется и откликнется, иначе у меня останется только очень не нравящийся мне самому вариант со всяким бредом из области SEO: вроде продажи ссылок на биржах, размещении чужих статей и тому подобного... Либо вообще отказываться от затеи с монетизацией блога и возвращаться к поиском "офисной" работы, но вообще мне очень не хотелось бы снова забрасывать Insight IT, одно из самых любимых хобби как-никак.

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

До новых встреч!

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

Иван Блинков — Tue, 29 Dec 2009 18:17:00 +0300

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

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

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

Возможно Jack Menzel, старший продукт-менеджер, лучше всего это выразил, когда пошутил о "неблагодарности" работы над веб-поиском в Google: "Вы демонстрируете [новую функцию поиска] людям, а они говорят: 'Да, вроде она работает, ну и что?'" (Как быстро все мы забываем, каково это было искать информацию в Интернете всего несколько лет назад.) Что ж, без дальнейших предисловий, перейдем к основным моментам, связанным с различными аспектами работы Google.

По мотивам статьи на xconomy.com, автор Gregory T. Huang.

Поиск в реальном времени

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

Menzel, бывший сотрудник Microsoft, который изучал компьютерное ремесло в University of Washington, возглавляет продуктовую группу на данном фронте. Он говорит, что компания Google работала над ускорением процесса индексации и ранжирования на протяжении уже многих лет: когда-то данные обновлялись раз в месяц, потом обновление стало ежедневным, чтобы поспевать за блогами и новостными сайтами. В течении прошлого года Twitter стал популярен и, как следствие, появилась достаточно критичная потребность в обновлении информации за считанные секунды или в крайнем случае минуты. "Мы двигались по направлению к тому, чтобы становиться все быстрее и быстрее, на протяжении уже достаточно длительного периода времени", говорит Menzel. "Данная траектория развития была выбрана уже давно. Каждый шаг в данном направлении приводит к все новым и новым проблемам и трудностям. Мы верим, что именно получение доступа к свежей информации является одним из ключевых факторов, являющихся залогом успеха Google." (В число остальных факторов, относящихся к самому поиску, входят такие показатели как релевантность, быстрота получения результата и полнота контента.)

Menzel считает, что самой сложной задачей является не просто быстродействие, а релевантность результатов потребностям пользователей (возможно, кто-то привык называть этот показатель словом "пертинентность"). "Это очень, очень непросто собирать свежий короткоживущий контент и ранжировать его рядом с, скажем, статьями из New York Times или просто постами из блогов." Стоит заметить, что когда контент появился буквально только что, обычно на него еще практически никто не успел сослаться, а значит Google не может полноценно использовать PageRank, их классическую технологию.

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

Говоря о будущем, Menzel повторил то, что казалось бы на сегодняшний день говорят все о поиске: еще рано. "На самом деле мы лишь начали работать над данной задачей и у нас все еще очень долгий путь впереди". Он надеется, что в течении 5 лет Google сделает поиск намного более персонализированным, чем он есть сегодня. Например, Google будет знать что ты увлекаешься футболом, но привык называть его не "soccer", а "football", то есть помимо прочего поисковая система должна понимать кем является каждый ее конкретный пользователь, как и с кем он связан, кем он является в реальной жизни, где находится, и, тем самым, помогать ему организовывать всю информацию вокруг него.

"Поиск - все еще очень далекая от решения проблема," - говорит Menzel. "Существует еще масса вещей, которые очень не просто найти в Интернете."

Локальный поиск

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

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

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

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

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

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

Облачные вычисления

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

Ken Norton, старший продукт-менеджер Google (а также выпускник Boston University и бывший предприниматель), поведал о Google Apps и стратегии компании в области облачных вычислений. Команда Norton'а работает конкретно над Google Calendar, но Google Apps также включают в себя и другие продукты, такие как Gmail, Google Talk, Google Docs и Google Sites. “Сеть выигрывает на том, как приложения будут потребляться” - он сказал.

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

Работа Google в области облачных вычислений сфокусирована на двух уровнях: на первом располагаются готовые программные продукты вроде Google Apps, направленные на прямое потребление конечными пользователями (как индивидуальными, так и корпоративными); второй же уровень занимает App Engine, "облачная" платформа, предназначенная для использования разработчиками программного обеспечения для эффективного построения их собственных веб-продуктов.

Относительно прогнозов на следующий год на фронте облачных вычислений, Norton сказал, что "мы постоянно совершенствуемся". В 2009 году было запущенно более 100 основных новых функциональных возможностей в Google Apps - таких вещей, как видео чат в GTalk или Gmail offline. Он считает, что Google "продолжит делать акцент на коммуникационных предложениях". Помимо развития Gmail и Calendar, это включает в себя доведение до ума Google Docs и придание более завершенного вида набору их возможностей. Norton говорит, что Google также ищет возможности по расширению своих предложений в области коллаборации, в том числе в виде продуктов для крупного бизнеса, совместимыми с различными системами обеспечения безопасности для аутентификации.

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

Освобождение данных

Последнее время в компании все больше внимания уделяется предоставлению пользователям легко экспортировать их данные из продуктов Google, таких как Blogger, Google Maps, Google Docs, Chrome и App Engine (пользовательские данные разработчиков). На первый взгляд это может показаться очередным капризом PR-менеджеров, но на самом деле за этим фактом стоит более глубокая и интересная инновационная стратегия.

Brian Fitzpatrick, ветеран opensource разработок, возглавляет двухлетний проект от офисов Google в Чикаго. Основная идея заключается в оказании помощи пользователям, если они хотят получить свои файлы и другие данные из облака Google, чтобы у них была возможность перейти на какую-то другую систему, если они захотят. "Большинство людей не думает о возможности экспорта данных до тех пор пока не станет слишком поздно" - говорит Fitzpatrick. "Мы надеемся, что если вы прекратите использование одного нашего продукта сегодня, то у вас будет возможность попробовать другой продукт завтра."

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

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

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

Дизайн, верстка и RSS

Иван Блинков — Mon, 28 Dec 2009 20:44:00 +0300

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

Для затравки пара опросов:

В добавок хочется услышать отзывы об этих и других нововведениях (вроде нового хостинга) в комментариях.

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

Всем, проявившим инициативу, заранее спасибо за помощь в улучшении блога Insight IT.

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

Иван Блинков — Mon, 21 Dec 2009 16:15:00 +0300

MySpace.com является одним из наиболее быстро набирающих популярность сайтов в Интернете с 65 миллионами пользователей и 260000 регистрациями в день. Этот сайт часто подвергается критике из-за не достаточной производительности, хотя на самом деле MySpace удалось избежать ряда проблем с масштабируемостью, с которыми большинство других сайтов неизбежно сталкивались. Как же им это удалось?

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

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

Платформа

ASP .NET 2.0
Windows
IIS
MSSQL Server

Что внутри?

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

Работа сайта

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

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

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

Google Chrome

Иван Блинков — Sat, 06 Sep 2008 00:36:00 +0400

Наверное многие из вас уже успели за последние пару дней стать свидетелями всей этой шумихи на просторах Сети, связанной с выходом Google на рынок браузеров. Сопутствующие релизу комиксы произвели на меня вполне положительное впечатление, благодаря достаточно большой актуальности поднятых в них проблем и интересным вариантам их решений. Так что я определенно решил, что поглядеть что за зверь такой - Google Chrome, определенно стоит, а что из этого вышло я и хотел бы тут рассказать, так что очередную рекламу нового продукта или какие-либо практически полезные советы у Вас врядли получится здесь обнаружить. Первым делом я посетил официальную страничку браузера и практически сразу немного разочаровался, увидев в заголовке надпись Google Chrome (BETA) for W****ws. Сразу напросился вопрос: а где версия для Linux? Покопавшись в соседних страничках ничего подобного обнаружить не удалось - пришлось пожать плечами с мыслью "наверное еще не сделали".

Зато через какое-то время наткнувшись на очередную заметку про все ту же довольно избитую тему, я заметил ма-а-аленькую неприметную ссылку на "инструкцию по компиляции Google Chrome из исходников в Linux". В очередной раз пожав плечами с мыслью "а нам не привыкать, все равно Gentoo пользуюсь" отправился вводить заветное заклинание в свежесозданную консольку.

Заклинание это выглядит примерно следующим образом:

#!/bin/bash
CHROME=/usr/local/src
mkdir $CHROME/chrome
cd $CHROME/chrome
export LANG=C
$CHROME/depot_tools/gclient config http://src.chromium.org/svn/trunk/src
$CHROME/depot_tools/gclient sync
cd $CHROME/src/chrome
../third_party/scons/scons.py Hammer

Для успешного каста требуются следующие ингридиенты:

subversion >= 1.4
pkg-config >= 0.20
python >= 2.4
perl >= 5.x
gcc/g++ >= 4.2
bison >= 2.3
flex >= 2.5.34
gperf >= 3.0.3
libnss3-dev >= 3.12

Начался процесс вполне оптимистично - строчки, генерируемые svn co побежали по экрану вполне весело, но когда этот процесс затянулся на более чем час – стало очевидно, что даже Google оказалось не по зубам выдержать такой наплыв желающх "заценить" новую игрушку и обеспечить достаточную пропускную способность на сервере с SVN. Правда и масштабы проекта мягко говоря впечатляют - директория с исходным кодом перед инициализацией компиляции оказалось очень даже весомой: 2.6 GB. В общем в итоге я не придумал ничего лучше, чем по старой традиции оставить браузер компилироваться на ночь и с чистой совестью уползти спать.

В итоге оказалось, что в результате получается не вовсе браузер, а лишь некоторые непонятно зачем нужные бинарники: надо было внимательно читать инструкцию, особенно обведенный в красную рамку блок - студенческая привычка при чтении чего-либо подсознательно отфильтровывать всю на первый взгляд второстепенную информацию, попадающую в категорию "слишком много букв", дала о себе знать :( В общем там об этом все заранее предупреждали - я просто не заметил, ну да ладно: в wine-то оно точно заведется, все тот же Google с легкостью помог обнаружить соответствующий мануал, для моего Gentoo он свелся к следующему:

#!/bin/bash
emerge --sync; emerge -av wine cabextract
cd /usr/bin
sudo wget www.kegel.com/wine/winetricks
sudo chmod +x winetricks
winetricks riched20 riched30 flash allfonts
cd ~
wget gpdl.google.com/chrome/install/149.27/chrome_installer.exe
wine chrome_installer.exe
rm chrome_installer.exe

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

wine ~/.wine/drive_c/windows/profiles/blinkov/Local Settings/Application Data/Google/Chrome/Application/chrome.exe--new-http --in-process-plugins

(если кто соберется копипастить - не забываем подменять blinkov на свое имя пользователя)

Первое впечатление - ужасный V**ta-like дизайн, вернее не то чтобы он совсем ужасный - минималистичность очень даже полезное свойство для дизайна браузера, но в мое KDE 3.5.9 темно-фиолетовой раскраски он не вписывается ну совсем никак. Ну да ладно - пока он стоит "просто побаловаться", то можно и потерпеть. Далее я решил пройтись по основным "фишечкам", заинтересовавшим меня в комиксах - все реализовано вполне "как обещали", очень много концептуально правильных решений, которых в старом-добром FF определенно не хватает (перечислять наверное смысла нет - все и так уже, наверное, в курсе что там есть "вкусненького"). Но и многих абсолютно жизненно-важных вещей я там не обнаружил - начиная с блокировки рекламы и заканчивая все тем же стандартно-фиксированным дизайном и отсутствием центрального репозитория плагинов. Кое-какие неприятности можно свалить на все еще не окончательную доведенность до ума wine (проблемы с SSL/TSL, скажем), но на них я смело закрывал глаза - пока не будет полноценной Linux-версии о регулярном использовании данного продукта речи быть просто не может. Скорость работы новинки также произвела впечатление - на его фоне даже FF чисто субъективно показался медлительным (не смотря на все огрехи wine, как оно будет выглядить в native-версии - предсказать сложно).

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

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

P.S.: А вот тут есть RSS, если вдруг кто еще не в курсе.

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

Иван Блинков — Tue, 24 Jun 2008 18:17:00 +0400

Ваш пьяный друг когда-либо вдохновлял Вас на создание первого в своем роде интернет-сервиса, который пришелся бы по вкусу миллионам пользователей и при этом неприхотливо обрабатывал миллиарды электронных писем ежегодно? Именно так Paul Tyma и создал Mailinator.

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

Как же Mailinator справляется со своей ролью анти-спам супергероя?

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

Да-да, это снова перевод статьи от Todd'а (цифры правда не первой свежести, но все же). На что-то более глобальное я в ближайшее время способен не буду, в основном благодаря незаметно подкравшейся сессии и, отчасти, работе.

Платформа

Статистика

Сервис обработал: 1.29 миллиардов электронных писем за 2007 год. 450.74 миллионов за 2006. 280.68 миллионов за 2005.
В период пиковых нагрузок обрабатывается 6.5 миллионов электронных писем в сутки или 4513 сообщений в минуту или 75 в секунду.
Mailinator работает на всего одном весьма средненьком компьютере с AMD Athlon 2GHz процессором, 1 GB оперативной памяти (которая используется не целиком) и низкопроизводительным IDE жестким диском объемом 80 GB. И она в общем-то загружена далеко не полностью.
Mailinator работает месяцами без присмотра и теряется очень небольшое количество сообщений, даже при постоянных спам-атаках и высоких пиковых нагрузках.

Архитектура

Так как система бесплатна, она не должна быть идеальной. Таким образом основные цели:
- Создание системы, которая ценит выживание превыше всего, даже пользователей. Основным ключом является именно выживание, так как Mailinator вынужден ежедневно отражать спам-атаки.
- Предоставить пользователям 99,99% доступность и точность данных. Более высокие гарантии будут существенно менее практичными и приведут к большим затратам. И так как сервис бесплатен, этот небольшой риск для пользователей становится просто частью правил игры.
- Поддержка следующей модели сервиса: пользователь регистрируется где-то, заходит в Mailinator, жмет на пришедшую ссылку и забывает об этом. Это означает, что письма не должны храниться постоянно. Они могут размещаться в оперативной памяти, так как являются временными (живут три-четыре часа). Если Вам нужен обычный настоящий почтовый ящик - воспользуйтесь любым другим соответствующим сервисом.
Изначально письма обрабатывались следующим образом:
- Sendmail получал письмо в общий ящик на диске.
- Java-приложение доставало сообщение используя IMAP и/или POP (с течением времени это менялось) и удаляло их.
- Система загружала все письма в память и оставляла их там.
- Наиболее старые сообщения вытеснялись как только накапливался лимит в 20000 сообщений.
Данный принцип работал вполне неплохо:
- Он стабилен и работал месяцами без каких-либо проблем.
- Использовался практически весь гигабайт оперативной памяти.
- Проблемы начались, когда количество сообщений в сутки начало превышать 800000. Система начала давать сбои из-за использования жесткого диска между Mailinator и email подсистемой.
- Наиболее старые сообщения вытеснялись как только накапливался лимит в 20000 сообщений.
Новая архитектура:
- Идея заключалась в отказе от временного хранения данных на жестком диске путем полного переписывания всей системы с нуля.
- Веб-приложение, почтовый сервер и все хранилище писем функционируют в рамках одной JVM.
- Sendmail был заменен на специально написанный для этого проекта SMTP сервер. Так как природа Mailinator не требовала полноценного SMTP сервера. Mailinator не отправляет писем, основная цель - принимать или отвергать входящие письма. Это является недостатком многоуровневой архитектуры. Она часто является залогом успеха в процессе масштабирования веб-приложения, но порой она может и наоборот полностью убить всю производительность благодаря неверному принятию ответственных решений. Решение о создании собственного SMTP сервера было достаточно интересным и смелым, многие другие руководители проектов вместо этого просто добавили бы дополнительное оборудование в систему. Это не было бы ошибкой, но, согласитесь, создание своего собственного решения задачи - намного более интересный подход.
- Сейчас Mailinator получает почту напрямую, обрабатывает ее и хранит в оперативной памяти. Жесткие диски полностью обходятся и практически не используются.
- Основное их применение - хранение сообщений в случае остановки сервиса для того, чтобы они могли быть восстановлены при запуске.
- Ведение логов было отключено.
- Система использует менее 300 потоков. Это оказалось вполне достаточно.
- При принятии сообщения, система пропускает его через набор фильтров и хранит его в памяти только в том случае, если все фильтры были успешно пройдены.
- Каждый почтовый адрес ограничен только 10 письмами, так что популярные адреса вроде joe@mailinator.com не могут "взорвать" систему.
- Письма не могут превышать 100 kb, а все приложения автоматически уничтожаются. Это позволяет существенно сэкономить в плане используемой оперативной памяти..
Электронные письма сжимаются в оперативной памяти:
- 99% писем никто даже не открывает, компрессия позволяет сэкономить место в оперативной памяти. Письмо разжимается в исходное состояние только если кто-то решает его открыть.
- Mailinator может хранить около 80000 писем в оперативной памяти, используя лишь 300 MB памяти, по сравнению с 20000 писем, занимающих 1 GB без использования компрессии.
- С таким подходом к хранению писем, они живут в среднем 3-4 часа.
- В память поместится и 200000 писем, но на практике это и не требуется.
- Оперативная память ценна, а процессорное время - вовсе нет. Именно из-за этого используется компрессия для экономии памяти и использования излишков вычислительных мощностей.
Mailinator не гарантирует анонимность или приватность:
- Любой пользователь может получить доступ к любому почтовому ящику.
- Отказ от ограничений доступа делает схему работы системы намного более простой.
- Со стороны пользователя такой подход очень прост, так как не требуется абсолютно никакой регистрации. Когда сайт требует ввести почтовый адрес достаточно лишь просто ввести любой адрес Mailinator. Вам не нужно создавать отдельный аккаунт. Банальный ввод адреса создает почтовый ящик. Все просто.
- На практике же, не смотря на вышесказанное, пользователи все же получают изрядную степень приватности.
Стремление к выживанию требует агрессивной борьбы со спамом:
- Mailinator не имеет ничего против спама, но так как спама приходит нереально много, когда он подвергает риску работоспособность сервиса приходится его фильтровать.
- Этот факт привел к правилу: если Вы делаете что-то (получаете спам или что-то еще), что мешает работе системы - Ваши письма не будут приниматься и Вы можете быть временно заблокированы.
Для успешного приема письмо должно пройти следующую цепочку фильтров:
- Все письма, которые не смогли быть доставлены, отклоняются.
- При слишком большом количестве писем с одного IP они перестают приниматься.
- Слишком много писем с одинаковой темой не принимаются.
- Письма, содержащие в заголовках запрещенные сервисом слова, также не попадают в почтовые ящики.
Выживание в условиях наплыва писем с одного IP адреса:
- Для этого типа фильтрации используется AgingHashMap. Когда сервис получает очередное письмо, IP помещается в массив и счетчик, соответствующий этому ключу, увеличивается на единицу в момент получения каждого последующего письма с этого IP.
- Спустя определенное время без получения писем с IP, соответствующие ему счетчик обнуляется.
- Когда счетчик достигает определенного порога, IP блокируется, предотвращая поток сообщений.
- Этим простым методом пользуются многие интернет-ресурсы для защиты различных своих компонентов, например комментариев. В роли хранилища для такого массива при распределенном функционировании системы часто используют memcached.
Защита от "зомби" атак:
- Спам может приходить и с больших координированных сетей с разными IP адресами, как раз участников таких сетей и называют "зомби". Одинаковые письма приходят со множества разных адресов, так что защита по IP адресам становится бессильна.
- Этот фильтр несколько более сложный, чем блокировка по IP, так как требуется достать из письма строку с заголовком, да и их сравнение - несколько ресурсоемкая задача.
- Когда около 20 писем с одинаковыми темами приходят в течении 2 минут, этот заголовок блокируется на час.
- Что интересно, Mailinator не хранит заблокированные темы вечно, так как это значило бы, что этот список неуклонно рос и приходилось бы вечно отслеживать соответствия с ним. Это никак не приемлемо для мимолетной природы Mailinator. Более комплексные алгоритмы защиты от спама нужны лишь только если ставятся цели с более жесткой борьбой со спама, для Mailinator же данный вариант - наиболее эффективный.
- Этим фильтром блокируется около 9% писем.
- Mailinator фильтрует сообщения только по теме и IP, так что системе не приходится прочитывать и анализировать все письмо целиком. Это позволяет неплохо сэкономить на вычислительных ресурсах при достаточно эффективной итоговой фильтрации.
Для уменьшения угрозы DDoS атак:
- Все соединения, неактивные какое-то время обрываются.
- Mailinator отвечает отправителям писем очень медленно, 10, 20 или даже 30 секунд, даже для небольших объемов данных. Это замедляет работу спаммеров, пытающихся отправлять спам как можно быстрее, и заставляет их лишний раз задуматься о целесообразности отправки снова спама на этот адрес. Период ожидания уменьшается во время повышенных нагрузок на сервис, так что письма не теряются из-за этого.

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

Идеальность - всего лишь ловушка. Как много систем были кардинально усложнены лишь для того, чтобы достичь 100%-го результата во всех аспектах. Если Вы участвовали в подобных совещаниях, Вы понимаете о чем идет речь. О нет, мы не можем сделать этого, так как есть 0,01% шанс, что что-то пойдет не так. Лучше спросите себя: насколько неидеальными можно позволить себе быть, чтобы все равно оставаться достаточно неплохим сервисом?
То, что Вы отвергаете, ничуть не менее важно, чем то, что Вы оставляете в системе. Существует масса концепций по построению архитектуры системы. Нужно не только выбрать подходящие, но и отказаться от тех, которые излишни.
Знайте предназначение своей системы и разрабатывайте ее в соответствии с этим. Быть всем для всех значит быть ничем для никого. Временное хранение электронных писем, позволяя небольшой части спама пробиться через фильтры, в совокупности с не 100% временем работы системы производят достаточно хорошее впечатление на пользователей. Построение собственного SMTP-сервера необходимо лишь в случае, если у Вас есть весомые аргументы в пользу того, что он Вам необходим. Далеко не факт, что такая идея придет в голову, возможно выбор пал бы и на более тривиальное решение, связанное просто с добавлением дополнительного оборудования.
Постарайтесь как можно быстрее свести механизм работы системы к наиболее общему случаю. Очень большой процент писем отвергается, так что это оправданно сделать это как можно раньше, чтобы минимизировать ресурсы, требуемые для их обработки. Найдите способ сделать это как можно быстрее в отношении наиболее частых случаев. то очень часто становится важным компонентом стратегии масштабирования.
Эффективность часто означает "постройте это самостоятельно". Готовые решения обычно решают большой спектр задач, но на практике часто нужна лишь небольшая часть функционала, в таких случаях можно написать небольшой компонент с нуля самостоятельно, чтобы он мог выполнять только нужные функции, но более эффективно.
Небольшое количество сбоев - вполне допустимо. Все заблокированные адреса не должны быть запомнены навечно. Позвольте этим спискам генерироваться на основе локальных данных, а не глобального состояния. Это очень простая и эффективная архитектура.
Java совсем не обязательно должна быть медленной. На эту тему сказано уже достаточно.
Избегайте работы с жесткими дисками. Многие приложения требуют работы с дисковой системой, но очень часто именно она оказывается узким местом в системе. Можете ли Вы обойтись без него, используя более креативные подходы к архитектуре системы?
Ограничте использование ресурсов. Задайте рамки для размеров почтовых ящиков и других подобных элементов системы, это позволит избежать неконтролируемых скачков нагрузок. Неограниченное использование ресурсов недопустимо при ограниченности ресурсов.
Сжимайте данные. Компрессия данных может стать неплохим достижением в попытках сэкономить оперативную память. Можно сократить использование памяти вдвое с лишь небольшой дополнительной нагрузкой, связанной с компрессией и декомпрессией информации. Если обмен данными происходит локально, достаточно лишь закодировать данные и предоставить API для доступа к данным без полной декомпрессии.
Используйте фиксированные объемы ресурсов для обработки запросов. Многие приложения не могут контролировать используемые ресурсы, в частности - оперативную память, таким образом они могут порой давать сбой при использовании излишне больших ее объемов. Для более стабильной работы стоит ограничить используемые ресурсы и откладывать выполнение новых задач пока они используются полностью. Для управление доступом к ресурсам можно использовать определенную логику в зависимости от ситуации: по времени, по приоритету, "честный" доступ, но так как ресурсы ограничены, система несколько ослабнет под серьезной нагрузкой.
Если данные не хранятся длительное время, они не могут стать причиной возбуждения судебного дела о нарушении чьих-либо прав.
Пользуйтесь тем, что знаете лучше всего. Этот урок не раз оправдывал себя. Paul знал Java лучше, чем что-либо еще, именно по-этому он заставил приложение на этом языке работать и выполнить все поставленные задачи.
Найдите свои собственные Mailinator'ы. Конечно, Mailinator является очень небольшой системой. В более крупной системе этот проект был бы лишь небольшой дополнительной возможностью, но такие системы обычно состоят просто из нескольких подпроектов размером с Mailinator. А что если подойти к разработке некоторых из них так же как и к Mailinator?
KISS работает, правда довольно редко. Простота систем часто обсуждается, но практические примеры появляются достаточно редко. Чаще всего разговор остается на уровне: твоя система сложная, а моя - простая, просто так как она моя. Mailinator является хорошим примером простой архитектуры системы.
Надежность является функцией архитектуры системы. Для построения системы, эффективно использующей память и выживающей серьезные атаки спаммеров, потребовалось серьезно подойти к каждому уровню ее архитектуры.

it's a pic

Иван Блинков — Tue, 27 May 2008 19:35:00 +0400

Не удивлюсь, если заголовок этого поста вам не сказал ровным счетом ничего - это вполне логично. Именно эту ситуацию я и хотел бы сегодня исправить: it's a pic представляет собой... ...очередной интернет-проект. Хотели увидеть что-то более грандиозное? - читайте дальше!

Начать наверное стоит с обозначения основной сути: поисковая система изображений, ориентированная на глобальный рынок. Да-да, мы уже видели поиск картинок в исполнении Google/Yahoo!/MSN/Яндекс/Рамблер (нужное подчеркнуть) - скажете вы, так в чем же разница?

Сейчас объясню. Никогда не возникало мысли, что частенько поиск картинок в обычных поисковых системах по большей части выдает всякий бред, очень слабо коррелирующий с тем, что Вы на самом деле искали? Основная их проблема заключается в том, что способов провести ассоциацию между текстом и изображением не так-то много. Чаще всего в их распоряжении лишь HTML-документы, ссылающиеся на изображение. То есть на основании атрибута alt у тэга <img /> и изредка anchor-текста обычных ссылок, поисковая система должна составить представление о том, что же на самом деле изображено в графическом файле. Варианты ручного построения таких соответствий тоже существуют, но либо нужно платить огромнейшему количеству человек за рутинную работу (что-то на грани фантастики - количество изображений в Сети измеряется числом с слишком большим количеством нулей) или подталкивать людей заниматься этим бесплатно, оформив это, например, в виде online-игры. Обычно в таких играх двум участникам одновременно предоставляется один и тот же набор изображений, а их задачей является последовательно вводить свои ассоциации связанные с текущим изображением. Если они оба ввели одно и то же слово - оно ассоциируется с изображением, а пользователям начисляются виртуальные очки. В общем поиск изображений по ключевым словам - задача, связанная с массой проблем и неточностей.

It's a pic является как раз поисковой системой, призванной избавить людей, ищущих изображения от всех этих проблем с неточностью и некорректностью результатов. Чтобы не придумывать каких-то временных решений проблемы было решено искоренить основательно: основная идея заключается в использовании в качестве критерия поиска не набор ключевых слов, а просто изображение. Сказать, что два изображения похожи, компьютеру намного проще, чем сказать что на картинке нарисован, например, жираф - именно на это и делает ставку этот проект.

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

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

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

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

Иван Блинков — Thu, 22 May 2008 16:39:00 +0400

Google Talk представляет собой сервис мгновенного обмена сообщениями от Google. В основе этого сервиса лежит XMPP протокол, более известный как Jabber. В России среди IM-сервисов несомненно наиболее широко распространен ICQ, но количество русских пользователей Jabber тоже неуклонно растет.

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

Введение

Сервисы мгновенного обмена на самом деле подвергаются существенно большей нагрузке, чем это может показаться на первый взгляд. Давайте взглянем на расшифровку аббревиатуры XMPP: eXtensible Messaging and Presence Protocol. Обмен сообщениями - лишь одна из его функций, наиболее важная же его часть остается "за сценой" - отображение присутствия пользователей online.

Давайте посмотрим на наш абстрактный пример с точки зрения присутствия: пускай им пользуется все тот же миллион пользователей, когда один из них включил компьютер и появился online - он должен уведомить весь свой список контактов об этом событии, а также узнать кто из них находится online. Если этот список велик, то такое элементарное событие может обернуться для сервиса далеко не одной сотней обработанных и доставленных сообщений. Помимо простого изменения статуса online/offline подобную цепочку сообщений может генерировать и любое другое изменение статуса: связанное с отсутствием пользователя около компьютера или с изменением небольшого текстового сообщения, которое обычно отображается в контакт листе рядом с ником пользователя и призвано отображать текущее его состояние, занятие или чего там только не пишут (эта функция не всегда предоставляется IM-сервисами, но наверняка многим знакома по ICQ, если не по Jabber). Все эти сообщения как раз и стоят за "presence" в аббревиатуре XMPP, суммарный траффик, ими генерируемый, может в несколько раз превышать траффик от собственно самих текстовых сообщений.

Если учесть факты, описанные в предыдущем абзаце, не трудно догадаться, что зависимость суммарного количества presence-сообщений от количества пользователей IM-сервиса далеко не линейна. Их количество за какой-то период времени можно очень приблизительно посчитать как произведение трех параметров: количества пользователей online, средней длины списка контактов среди них и количества изменений статуса каждым пользователем. А каждый дополнительный пользователь в системе так или иначе увеличивает как минимум два из этих трех параметров.

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

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

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

Архитектура

Со стороны Google (о котором я, кстати говоря, уже писал) было бы глупо строить сервис мгновенного обмена сообщениями в стороне от остальных коммуникационных сервисов, предоставляемых этой компанией. Еще до своего публичного старта Google Talk был интегрирован в почтовый сервис GMail и социальную сеть Orkut: эти сервисы просто запрашивали у Google Talk присутствие online пользователей из своего списка контактов при возникновении соответствующих событий, но при этом не отображали результаты в своих страницах. Таким образом разработчики получили возможность оценить предстоящие нагрузки и готовность сервиса к публичному запуску намного более точно, чем они могли бы это сделать средствами синтетических тестов.

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

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

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

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

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

Заключение

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

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

DMOZ.org

Иван Блинков — Mon, 19 May 2008 17:14:00 +0400

Возможно Вы уже обратили внимание, что в начале мая данный блог был добавлен в один из крупнейших (если не самый крупнейший) каталог интернет-ресурсов - DMOZ.org, также известный как Open Directory Project. Само по себе это событие достаточно значимо для любого сайта, но я почему-то не счел нужным писать по этому поводу отдельный пост, видимо просто так как других слов кроме как "Ура! Мой блог попал в DMOZ!!!" у меня тогда не нашлось.

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

Масштабируемые веб-архитектуры

Иван Блинков — Mon, 12 May 2008 09:00:00 +0400

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

Приступим?

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

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

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

Масштабируемость принято разделять на два направления:

Вертикальная масштабируемость: Увеличение производительности каждого компонента системы c целью повышения общей производительности.
Горизонтальная масштабируемость: Разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам) и/или увеличение количества серверов параллельно выполняющих одну и ту же функцию.

Так или иначе, при разработке стратегии роста системы приходится искать компромис между ценой, временем разработки, итоговой производительность, стабильностью и еще массой других критериев. С финансовой точки зрения вертикальная масштабируемость является далеко не самым привлекательным решением, ведь цены на сервера с большим количеством процессоров всегда растут практически экспоненциально относительно количества процессоров. Именно по-этому наиболее интересен горизонтальный подход, так как именно он используется в большинстве случаев. Но и вертикальная масштабируемость порой имеет право на существование, особенно в ситуациях, когда основную роль играет время и скорость решения задачи, а не финансовый вопрос: ведь купить БОЛЬШОЙ сервер существенно быстрее, чем практически заново разрабатывать приложения, адаптируя его к работе на большом количестве параллельно работающих серверов.

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

Серверы приложений

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

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

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

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

Оборудование: Сетевое оборудование, позволяющее распределять нагрузку между несколькими серверами, обычно стоит достаточно внушительные суммы, но среди прочих вариантов обычно именно этот подход предлагает наивысшую производительность и стабильность (в основном благодаря качеству, плюс такое оборудование иногда поставляется парами, работающими по принципу HeartBeat). В этой индустрии достаточно много серьезных брендов, предлагающих свои решения - есть из чего выбрать: Cisco, Foundry, NetScalar и многие другие.
Программное обеспечение: В этой области еще большее разнообразие возможных вариантов. Получить программно производительность сопоставимую с аппаратными решениями не так-то просто, да и HeartBeat придется обеспечивать программно, но зато оборудование для функционирования такого решения представляет собой обычный сервер (возможно не один). Таких программных продуктов достаточно много, обычно они представляют собой просто HTTP-серверы, перенаправляющие запросы своим коллегам на других серверах вместо отправки напрямую на обработку интерпретатору языка программирования. Для примера можно упомянуть, скажем, nginx с mod_proxy. Помимо этого имеют место более экзотические варианты, основанные на DNS, то есть в процессе определения клиентом IP-адреса сервера с необходимым ему интернет-ресурсов адрес выдается с учетом нагрузки на доступные сервера, а также некоторых географических соображений.

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

Ресурсоемкие вычисления

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

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

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

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

Сессии

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

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

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

Централизованное хранение сессий: Идея проста: создать для всех серверов общую "копилку", куда они смогут складывать выданные ими сессии и узнавать о сессиях посетителей других серверов. В роли такой "копилки" теоретически может выступать и просто примонтированная по сети файловая система, но по некоторым причинам более перспективным выглядит использование какой-либо СУБД, так как это избавляет от массы проблем, связанных с хранением сессионных данных в файлах. Но в варианте с общей базой данных не стоит забывать, что нагрузка на него будет неуклонно расти с ростом количества посетителей, а также стоит заранее предусмотреть варианты выхода из проблематичных ситуаций, связанных с потенциальными сбоями в работе сервера с этой СУБД.
Децентрализованное хранение сессий: Наглядный пример - хранение сессий в memcached, изначально расчитанная на распределенное хранение данных в оперативной памяти система позволит получать всем серверам быстрый доступ к любым сессионным данным, но при этом (в отличии от предыдущего способа) какой-либо единый центр их хранения будет отсутствовать. Это позволит избежать узких мест с точек зрения производительности и стабильности в периоды повышенных нагрузок.

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

Статический контент

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

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

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

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

Кэширование

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

СУБД: Практически все современные СУБД предоставляют встроенные механизмы для кэширования результатов определенных запросов. Этот метод достаточно эффективен, если Ваша система регулярно делает одни и те же выборки данных, но также имеет ряд недостатков, основными из которых является инвалидация кэша всей таблицы при малейшем ее изменении, а также локальное расположение кэша, что неэффективно при наличии нескольких серверов в системе хранения данных.
Приложение: На уровне приложений обычно производится кэширование объектов любого языка программирования. Этот метод позволяет вовсе избежать существенной части запросов к СУБД, сильно снижая нагрузку на нее. Как и сами приложения такой кэш должен быть независим от конкретного запроса и сервера, на котором он выполняется, то есть быть доступным всем серверам приложений одновременно, а еще лучше - быть распределенным по нескольким машинам для более эффективной утилизации оперативной памяти. Лидером в этом аспекте кэширования по праву можно назвать memcached, о котором я в свое время уже успел подробно рассказать.
HTTP-сервер: Многие веб-серверы имеют модули для кэширования как статического контента, так и результатов работы скриптов. Если страница редко обновляется, то использование этого метода позволяет без каких-либо видимых для пользователя изменений избегать генерации страницы в ответ на достаточно большую часть запросов.
Reverse proxy: Поставив между пользователем и веб-сервером прозрачный прокси-сервер, можно выдавать пользователю данные из кэша прокси (который может быть как в оперативной памяти, так и дисковым), не доводя запросы даже до HTTP-серверов. В большинстве случаев этот подход актуален только для статического контента, в основном разных форм медиа-данных: изображений, видео и тому подобного. Это позволяет веб-серверам сосредоточиться только на работе с самими страницами.

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

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

Базы данных

На закуску я оставил самое интересное, ведь этот неотъемлемый компонент любого веб-приложения вызывает больше проблем при росте нагрузок, чем все остальные вместе взятые. Порой даже может показаться, что стоит вообще отказаться от горизонтального масштабирования системы хранения данных в пользу вертикального - просто купить тот самый БОЛЬШОЙ сервер за шести- или семизначную сумму не-рублей и не забивать себе голову лишними проблемами.

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

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

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

Временным решением этой проблемы, возможно, может стать замена master-сервера на более производительный, но так или иначе не выйдет бесконечно откладывать переход на следующий "уровень" развития системы хранения данных: "sharding", которому я совсем недавно посвятил отдельный пост "Сегментирование баз данных". Так что позволю себе остановиться на нем лишь вкратце: идея заключается в том, чтобы разделить все данные на части по какому-либо признаку и хранить каждую часть на отдельном сервере или кластере, такую часть данных в совокупности с системой хранения данных, в которой она находится, и называют сегментом или shard’ом. Такой подход позволяет избежать издержек, связанных с реплицированием данных (или сократить их во много раз), а значит и существенно увеличить общую производительность системы хранения данных. Но, к сожалению, переход к этой схеме организации данных требует массу издержек другого рода. Так как готового решения для ее реализации не существует, приходится модифицировать логику приложения или добавлять дополнительную "прослойку" между приложением и СУБД, причем все это чаще всего реализуется силами разработчиков проекта. Готовые продукты способны лишь облегчить их работу, предоставив некий каркас для построения основной архитектуры системы хранения данных и ее взаимодействия с остальными компонентами приложения.

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

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

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

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

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

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

Примером готового каркаса для реализации работы с данными по такому принципу служит opensource проект Apache Foundation под названием Hadoop, о котором я уже неоднократно рассказывал ранее, да и статейку в Википедию написал в свое время.

Вместо заключения

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

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

hCard

Иван Блинков — Sun, 13 Apr 2008 22:51:00 +0400

hCard представляет собой реализацию спецификации RFC 2426 (более известной как vCard) в виде микроформата. Основной его целью является предоставление стандарта оформления персональных данных на просторах Сети, но помимо этого имеется возможность указания информации об компаниях, организациях или местах. Как и любой другой микроформат, hCard реализуется без нарушения стандартов XHTML с помощью атрибутов тэга class, причем какие именно тэги используются - не важно. Для оформления данных используя этот микроформат достаточно лишь объявить какой-либо тэг hCard объектом с помощью class="vcard" и разместить внутри него все тэги, обозначающие какое-либо свойство объекта. Большая часть информации, предоставляемой в соответствии с этим микроформатом является опциональной, единственным обязательным свойством является имя объекта - class="fn". Помимо этого в атрибуте profile тэга <head> принято указывать адрес http://www.w3.org/2006/03/hcard.

В целом все свойства объектов hCard можно поделить на семь групп:

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

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

при использовании свойства photo в тэге <a>, значением является адрес из атрибута href;
в тэге <img>, значением является само изображение, то есть значение атрибута src
в <object>, значением является атрибут `data, то есть его источник данных.

Раз уж зашла речь об размещении значений свойств, то сразу хочется сказать об небольшом исключении в виде тэга <abbr>, где оно задается в атрибуте title, а внутри самого тэга - некое более удобное для чтения людьми его представление.

Если тэг, обозначенный любым свойством, содержит какую-либо информацию помимо самого значения свойства, то для отделения релевантного контента от лишней информации можно разместить внутри тэга свойства дочерние объекты, обозначив их атрибутом class="value". Это даст понять парсеру микроформата, что собрав воедино (методом конкатенации) все значения помеченных таким образом объектов он сможет получить значение исходного свойства. Описание получилось несколько запутанным, так что лучше продемонстрировать этот принцип на примере, в котором значению свойства fn будет присвоено значение "Иван Блинков":

<div class="vcard">
  <div class="fn">
    <span class="value">Иван </span>подпрыгнул три раза на месте,
    обернулся и увидел написанную на стене
    свою фамилию: <span class="value">Блинков</span>.
  </div>
</div>

Как не трудно заметить, значение свойства разбавлено массой ненужной информации, но с помощью тэгов с атрибутом class="value" мне удалось выделить лишь важную информацию, не поменяв при этом внешний вид документа. Парсер микроформатов, читая этот документ, соединит обе части и получит в итоге как раз "Иван Блинков", что и будет соответствовать желаемому имени объекта.

Вы заметили в предыдущем примере пробел после моего имени? Он был поставлен для того, чтобы при конкатенации составные части значения не слились в одно слово "ИванБлинков", не самый удобный подход к решению проблемы, но у него есть альтернатива в виде тэга <abbr> (не забываем про упомянутое чуть выше исключение):

<div class="vcard">
  <abbr class="fn" title="Иван Блинков">
    Иван
  </abbr>
  подпрыгнул три раза на месте,
  обернулся и увидел написанную на стене
  свою фамилию: Блинков.
</div>

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

Идентификационные свойства

Свойство	Описание
fn	полное имя объекта (formatted name)
n	имя, используется для идентификации составных частей fn (name)
nickname	прозвище
bday	день рождения в формате YYYY-MM-DD (birthday)
photo	фотография

Свойство fn уже успели слегка обсудить, так что перейдем сразу к n. Как уже было сказано, используется он для детализации составных частей полного имени объекта, для чего оно имеет ряд подсвойств, используемых в дочерних элементах:

given-name: – имя.
additional-name: – отчество.
family-name: – фамилия.
honorific-preffix: – какой-либо префикс к имени, отображающий социальный статус человек.
honorific-suffix: – суффикс с тем же смыслом.

Выглядит это все примерно так, ничего сложного:

<div class="vcard">
  <div class="n">
    <span class="given-name">Иван</span>
    <span class="additional-name">Иванович</span>
    <span class="family-name">Блинков</span>
  </div>
</div>

Адресные свойства

Адрес может быть указан в двух формах:

adr - структурированной (с указанием составных частей);
label - не структурированной.

Для структурированного адреса используются подсвойства по аналогии с n:

Свойство	Описание
post-office-box	почтовый адрес
extended-address	полный адрес (с номером подъезда, квартиры и т.д.)
street-address	улица
locality	город
region	регион, штат или провинция
postal-code	индекс
type	тип адреса, то есть то, как он связан с исходным идивидом, должен принимать одно из значений: dom, parcel, home, work, pref

label же используется просто для написания адреса по тому же принципу, как если бы Вы писали его, например, на конверте традиционного письма. Возможно использование подсвойства type как и в adr.

С телекоммуникационными свойствами все проще:

телефон - tel;
адрес электронной почты - email;
почтовый клиент - mailer (не понятно - и зачем он тут сдался?).

Телефонный номер может иметь тип (type):

home - домашний
msg - имеется автоответчик
work - рабочий
pref - предпочтительный
voice - голосовой
fax - факс
cell - мобильный aka сотовый
video - для видеоконференций
pager - пэйджер
bbs - bulletin board system
modem - возможно использование модема
isdn - integrated services digital network
pcs - personal communication service

Географические свойства также не отличаются особой сложностью:

tz - временная зона
long - широта
lat - долгота

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

Свойства, описывающие индивида с точки зрения работы, немногочисленны:

title - должность
role - роль
logo - ссылка на логотип компании
agent - указание представителя индивида, например секретаря, например в виде ссылки на его hCard
org - название компании

Дополнительные свойства:

category - категория, то есть чем по сути является данный hCard, например - визитка
note - какие-либо замечания к остальным свойствам
rev - время последнего редактирования hCard, то есть время на которое данная информация является актуальной
sort-string - отмечает какая часть hCard (обычно часть имени), которая будет использована при сортировке списка из нескольких hCard
sound - адрес, указывающий на звуковой файл с правильным произношением имени индивида
url - адрес персонального или корпоративного сайта
uid - уникальный идентификационный номер в каком-либо специфицированном IANA формате (подсвойство type указывает в каком именно)

Для обеспечения ограничения доступа к данным из hCard используется два свойства - class и key. class определяет уровень доступа по примерно тому же принципу, что и в ООП: public или confidentional. А свойство key предоставляет публичный ключ, для расшифровки данных с закрытым доступом.

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

В заключение хочу сказать, что в качестве источников информации для данной статьи были использованы официальная вики и презентация от Robert Costello, а подписаться на RSS можно вот ТУТ.

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

Иван Блинков — Tue, 01 Apr 2008 20:49:00 +0400

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

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

Этот текст - перевод статьи, автор - Todd Hoff.

Платформа

Статистика

Проект стартовал в конце 2004 года на одном сервере под управлением Linux с использованием Apache 1.3, PHP 4 и MySQL 4.0 (со стандартной системой хранения данных - MyISAM).
Более 1.2 миллиона пользователей.
Более 200 миллионов просмотров страниц в месяц.
100 серверов расположены в нескольких датацентрах, из них: – 20 серверов баз данных; – 30 веб-серверов; – несколько поисковых серверов, использующих Lucene; – остальные используются для обеспечения избыточности.
30 GB данных.
Ни одна из проблем, с которыми пришлось столкнуться проекту не была связана с PHP, в основном они касались базы данных.
Легковесная природа PHP позволила переместить вычислительные работы из базы данных в приложение для улучшения производительности.

Что внутри?

Балансировщик нагрузки равномерно распределяет запросы между PHP серверами.
MySQL используется по принципу master-slave: - Сервера, обрабатывающие большое количество транзакций, используют движок InnoDB. - Сервера, выполняющие аналитическую обработку данных в реальном времени, используют MyISAM. - Снижения производительности при переходе с MySQL 4.1 на версию 5 замечено не было.
Для кэширования используется Memcached.
Используется сегментирование баз данных.
Особенности использования Digg существенно облегчают процесс масштабирования. Большинство посетителей просто просматривают главную страницу и уходят. Это приводит к тому, что 98% запросов к базе данных являются операциями чтения. Такое соотношение операций чтения и записи позволяет не беспокоиться о комплексной работе по проектированию операций записи, что позволяет намного проще масштабировать проект.
Возникали проблемы, связанные с системой хранения данных, которые сообщали, что данные уже записаны на диск, когда на самом деле это было не так. Контроллеры делали это для создания впечатления более высокой производительности. Но на практике это приводило лишь к проблемам с целостностью данных. Это достаточно распространенная проблема, которую порой не так уж просто решить, правда все зависит от используемого оборудования.
Для облегчения нагрузки на базы данных используется кэширование и APC PHP Accelerator.
С использованием рабочих потоков Apache2, FastCGI и PHP акселератора возможно избежать необходимости каждый раз заново интерпретировать и компилировать PHP скрипты: скрипт компилируется только при первом обращении, что существенно ускоряет скорость его выполнения при последующих обращениях.

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

Используйте возможность выбора движка для MySQL. Если Вам нужны транзакции - используйте InnoDB, если нет - MyISAM. Например, если на master сервере расположены транзакционные таблицы, то для slave серверов можно использовать и MyISAM.
В определенный момент рост стал невозможен путем добавления дополнительной оперативной памяти, пришлось продолжать рост путем изменения архитектуры.
Люди часто жалуются, что Digg медлителен. Скорее это вызвано их огромными JavaScript библиотеками, чем работой их серверной системы.
Стоит тщательно выбирать какие именно приложения развертывать. Они приложили все усилия, чтобы не использовать приложения, требующие больших вычислительных мощностей. Очевидно, что Digg работает на совершенно стандартной LAMP архитектуре, но тем не менее реализована она достаточно интересно. У инженеров часто возникает желание реализовать какой-либо дополнительный функционал, но всегда стоит иметь ввиду, что они могут разрушить инфраструктуру, если она не сможет расти теми же темпами. Так что с этим стоит повременить до тех пор пока система сможет выдерживать все необходимые нагрузки. Это приводит к планированию ресурсов, особенно большое внимание этому аспекту уделяет Flickr.
Вам остается лишь догадываться, сможет ли Digg удержать свои позиции, если и дальше будет ограничивать добавление новых возможностей, или уступит более активно развивающимся сервисам социальных закладок? Возможно если бы была возможность увеличивать масштабы более простыми методами, более быстрое добавление новых функций и возможностей позволило бы более эффективно конкурировать на этом рынке? С другой стороны, просто добавление новых возможностей может и не поменять ситуацию кардинальным образом.
Основные проблемы с масштабируемостью и производительностью связаны с обработкой данных и в большинстве случаев они не зависят от используемого языка программирования. Вы столкнетесь с ними при работе с Java, PHP, Ruby, или подставьте сюда Ваш любимый язык программирования.

Архитектура Friends for Sale

Иван Блинков — Mon, 17 Mar 2008 21:44:00 +0300

За три коротких месяца Friend for Sale (рейтинговая система в условиях рыночной экономики) попала в десятку лучших приложений Facebook, непринужденно обрабатывая 200 запросов в секунду и демонстрируя шокирующее количество просмотров страниц, за месяц достигающее 300 миллионов просмотров. Все это дело рук двух разработчиков, работающих не полный рабочий день, которые смогли создать успешное веб-приложение, имея в своем распоряжении лишь кластер из дюжины серверов и Ruby on Rails.

Как Friends for Sale масштабируется для того, чтобы обеспечить торговлю всеми этими красивыми людьми? Как Вы думаете, сколько стоят Ваши друзья на открытом рынке?

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

Традиционная пара фраз, чтобы отдать должное оригиналу и его автору. Продолжаем:

Ответы на стандартный набор вопросов от Siqi Chen и Alexander Le, создателей Friends for Sale;
Virality on Facebook.

Платформа

Ruby on Rails
CentOS (64 bit)
Capistrano - для обновлений и перезапусков серверов
Memcached
MySQL
nginx
Starling - распределенный сервер очередей
Softlayer - хостинг
Pingdom - мониторинг
LVM - Magic Multi-Connections Gem - разделение операций чтения и записи между серверами

Статистика

Это Facebook приложение находится в десятке наиболее популярных;
Около 600 тысяч активных пользователей;
Полмиллиона уникальных посетителей ежедневно, и эта цифра неуклонно растет;
Темпы роста проекта достигают 300% в месяц;
200 запросов в секунду;
5 TB трафика в месяц;
Над проектом работают 2 разработчика и 1 админимтратор баз данных.
4 сервера баз данных, 6 серверов приложений, 1 тестовый сервер и 1 сервер для балансировки нагрузки:
- Каждый из серверов приложений содержит 4 ядра и 8 GB оперативной памяти.
- На каждом из них работает 16 сервисов mongrel (в сумме - 96).
- 4 GB оперативной памяти на каждом из них отведено под memcached.
- Сервера баз данных имеют более серьезное оборудование: при тех же 4-х ядрах, они имеют 32 GB оперативной памяти и RAID 10 массив из четырех 15000rpm SCSI дисков, работающих в режиме "master/slave".

Давайте знакомиться

Для чего нужна ваша система?

Наша система разработана в качестве платформы для нашего Facebook приложения, Friends for Sale. В целом оно представляет собой аналог рейтинговой системы Hot-or-Not с некоторым добавлением рыночной экономики. В момент проведения интервью это приложение было на 10-м месте по популярности среди приложений Facebook.

Описание этого приложения на самом Facebook гласит:

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

Почему вы решили построить эту систему?

Мы разработали ее скорее как эксперимент для того, чтобы проверить удалось ли нам понять концепции и измерения вирусного эффекта в рамках Facebook. Мне кажется нам это удалось. :)

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

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

Каковы были ваши

действия, направленные для решения этих задач?

С самого начала мы активно использовали memcached - для перезагрузки страницы совсем не требуется выполнение SQL запросов. В основном мы использовали кэширование фрагментов Rails с индивидуальной логикой актуальности.

Как вы оцениваете размеры вашей системы?

Вчера статистика показала более полумиллиона уникальных посетителей, и эта цифра неуклонно растет. За этот месяц было зарегистрировано более 300 миллионов просмотров страниц.

Каковы показатели использования пропускной способности интернет-канала?

В прошлом месяце было потрачено 3 терабайта трафика, но в этом месяце ожидается цифра не меньше 5 терабайт. Эти цифры состоят по большей части из XHTML / CSS и нескольких небольших иконок.

Как много документов используется в системе? Сколько изображений? Какой объем данных?

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

Как вы оцениваете темпы роста вашей системы?

Месяц назад за сутки просматривалось около трех миллионов страниц, на данный момент эта цифра достигла 10 миллионов в сутки. Из чего можно сделать вывод, что ориентировочные темпы роста проекта составляют 300% в месяц. Если говорить о ежесекундной нагрузке, то на данный момент она составляет около 200 запросов в секунду.

Какая часть посетителей платит вам за участие в вашем проекте?

Он абсолютно бесплатен для пользователей.

Каковы показатели "текучести" пользователей?

В среднем около 1% в сутки, с ежедневным ростом в 3% от этой цифры, если говорить в терминах новых установок .

Как много учетных записей активно принимали участие в проекте за последний месяц?

По данным Google за последний месяц проект посетил 2.1 миллион уникальных пользоывтелей.

Какова архитектура вашей системы?

Она представляет собой относительно стандартный Rails кластер. В качестве интерфейса между запросами пользователей и серверами приложений используется proxy балансировщик нагрузки, который перенаправляет запросы напрямую шести четырехядерным серверам приложений. На каждом сервере приложений запущено 16 mongrel'ов, что в сумме дает 96. Балансировщик нагрузки перенаправляет запросы напрямую на порты серверов mongrel. В дополнение к этому на каждом сервере приложений выделено 4 GB оперативной памяти под memcached, а также работает локальный сервер распределенного менеджера очередей Starling и несколько менее важных фоновых процессов.

СУБД работает на двух серверах (четыре ядра, 32 GB оперативной памяти, четыре 15000rpm SCSI диска в RAID 10) в режиме "master/slave". Для организации распределения операций чтения и записи между серверами используется Magic Multi-Connections Gem от Dr Nic.

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

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

Каким образом планируется масштабировать архитектуру вашего проекта?

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

Назовите самые интересные уникальные факты о вашем проекте?

Я могу назвать:

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

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

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

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

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

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

Кто входит в состав вашей команды?

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

Сколько всего людей участвует в проекте?

В технической части - два разработчика и один администратор баз данных, работающий на контрактной основе.

Где они расположены с географической точки зрения?

Все участники проекта живут в районе SOMA, San Francisco.

Каковы обязанности каждого из участников проекта?

Оба разработчика проекта по совместительству являются и его создателями. Поначалу я (Siqi) был ответственным за дизайн и разработку пользовательского интерфейса, но так как у меня был некоторый опыт с развертыванием систем я взял на себя и разработку управления сетевыми операциями и развертывания. Мой коллега Alex был ответственным за большую часть Rails кода, вся логика приложения - его рук дело.

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

У вас есть какая-то определенная философия менеджмента?

Да - найти самых умелых и сообразительных людей, сделать им наилучшее возможное предложение и убраться с их пути. Самые лучшие менеджеры должны уметь НЕ МЕШАТЬ работникам, так что я стараюсь максимально этому следовать при работе с другими участниками проекта. Но, к сожалению, мне удается это далеко не всегда.

Если ваша команда работает раздельно, как вам удается координировать свою работу?

Нам стоило бы задуматься об использования каких-либо эффективных средств общения. Мне кажется, что использование удаленной работа / outsourcing'а является по-настоящему сложной задачей - я предпочитаю обходиться без этого в разработке основы системы. Для системного администрирования или разработки архитектуры БД это было бы более оправданно.

Что вы используете для разработки?

Мы используем Rails с несколькими plug-in'ами, самыми важными являются cache-fu от Cris Wanstrath и magic multi connections от Dr Nic. В качестве текстового редактора я предпочитаю vim с плагином rails.vim.

Какие языки программирования используются?

Ruby on Rails

Сколько используется серверов?

На данный момент используется кластер из 12 серверов.

Как они используются?

4 сервера баз данных, 6 серверов приложений, 1 тестовый сервер и 1 сервер для балансировки нагрузки.

Кто их предоставляет?

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

Какая операционная система используется?

CentOS 5 (64 бит)

Какой http сервер используется?

nginx

Какая СУБД используется?

MySQL 5.1

Вы используете обратную proxy?

Мы просто используем встроенный в nginx proxy балансировщик нагрузки.

Как вы развертываете вышу систему в датацентре?

Мы используем хостинг выделенных серверов, Softlayer.

Какова ваша стратегия хранения данных?

Мы используем резервное копирование NAS помимо внутренних SCSI RAID массивов.

Какой объем дискового пространства вам доступен?

На всех серверах в сумме около 5 TB.

Как вы наращиваете объем дискового пространства?

Спонтанно. Мы еще не выполнили каких-либо исследований в планировании дискового пространство, но это было явно зря не сделано.

Вы используйте какой-либо сервис хранения информации?

Нет.

Вы используете виртуализацию хранимых данных?

Нет.

Как организована работа с сессиями?

На данный момент она поручена СУБД, но передача их обслуживания напрямую memcached - достаточно несложная задача.

Как организована архитектура вашей БД?

На данный момент - "master/slave". Мы осуществляем переход к нескольким "slave" с proxy балансировщиком нагрузки для режима "только для чтения".

Как организована балансировка нагрузки?

На программном уровне средствами nginx.

Какой framework / AJAX библиотеку вы используете?

Rails.

Какие средства распределенного управления задачами вы используете?

Starling

Как вы управляете рекламой в проекте?

Мы участвуем в нескольких рекламных сетях. Мы оцениваем эффективность каждой рекламной сети с помощью eCPM на уровне приложения.

Имеете ли вы стандартную API на вашем сайте?

Нет.

Сколько человек в вашей команде?

2 разработчика.

Какими наборами способностей обладают участники вашей команды?

Я: дизайн пользовательского интерфейса, разработка, ограниченные знания в Rails, оптимизация MySQL, развертывание Rails.

Alex: разработка логики приложения, дизайн пользовательского интерфейса, программная инженерия в целом.

Какие средства разработки вы используете?

Alex работает в OS X, а я предпочитаю Ubuntu. Для контроля за версиями используется SVN. В качестве текстового редактора я использую VIM, а Alex - TextMate.

Как проходит процесс разработки?

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

Какова ваша стратегия кэширования объектов и контента?

Мы используем memcached без TTL и просто вручную очищаем кэш при необходимости.

Как происходит кэширование на клиентской стороне?

Никак.

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

Мы используем Pingdom для внешнего мониторинга за сайтом - они отлично справляются.

Как вы проверяете работоспособность ваших серверов и сетей?

На данный момент мы полагаемся на внешний мониторинг и ping мониторинг от Softlayer. В перспективе мы рассматриваем FiveRuns как возможное решение для мониторинга серверов.

Как вы строите на графиках или диаграммах сетевую и серверную статистику, а также тенденции?

Мы не занимаемся этим.

Как вы тестируете систему?

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

Как вы анализируете производительность?

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

Как вы обеспечиваете безопасность?

Тщательно.

Как вы решаете какие возможности добавить или оставить?

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

Как вы реализуете веб-аналитику?

Мы используем собственную систему оценок для оптимизации вирусного эффекта, но помимо этого пользуемся и услугами Google Analytics.

Используете ли вы A/B тестирование?

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

Как вы выполняете резервное копирование и восстановление?

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

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

На данный момент мы делаем это вручную, за исключением развертывания Rails приложения. Для обновления и перезапуска серверов приложений мы используем Capistrano.

Как вы выполняете глобальные изменения в структуре базы данных при обновлениях?

Обычно мы начинаем переход с второстепенных серверах баз данных, а затем просто переключаем основные.

Каковы ваши планы насчет защиты от сбоев и развития бизнеса?

Не самым лучшим образом...

Есть ли у вас отдельная операционная команда, работающая над сайтом?

Было бы неплохо, но нет :)

Используете ли вы CDN? Если да, то какую и для каких целей?

Нет.

Как выглядит модель ваших доходов?

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

Как вы продвигаете ваш продукт?

Это же социальная сеть. Мы просто используем вирусный эффект для поддержания роста проекта.

Используете ли вы какие-либо особенно интересные технологии или алгоритмы?

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

Храните ли вы изображения в базе данных?

Нет, это бы была не самая лучшая идея.

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

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

Приходилось ли вам сталкиваться с какими-либо сюрпризами, положительными или отрицательными?

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

С другой стороны, было удивительно насколько далеко смогла наз завести архитектура с одним "master" и несколькими "slave" на самом обыкновенном оборудовании. Я думаю, что даже миллиард просмотров страниц в месяц достижим при таком подходе к базе данных.

Как ваша система эволюционирует для соответствия новым требованиям к масштабируемости?

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

Кем вы восхищаетесь?

Brad Fitzpatrick за изобретение memcache, а также каждым, кому успешно удалось горизонтально масштабировать свой проект.

Каковы ваши планы по изменению архитектуры в будущем?

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

Их мысли о вирусном эффекте Facebook

Facebook моделирует социальную сеть в цифровой форме максимально точно и полно, по крайней мере насколько это возможно.
Построение социальной сети более важно, чем возможности, предоставляемые пользователям.
Facebook позволяет быстро распространять новые приложения через социальную сеть.
Идея вашего приложения должна быть социальной, затягивающей и универсальной.
Социальный аспект является основой вирусного эффекта.
"Затягивание" пользователей позволяет зарабатывать на нем.
Универсальность дает необходимый потенциал.
Friends for Sale - социальный проект, так как предоставляет возможность торговать своей частью социального графа.
Он затягивает, так как в основе лежит в какой-то степени сумасшедшая идея, ненавязчивая, слегка флиртующая, и немного циничная.
Он универсальный, так как все люди в какой-то степени самовлюбленны, знают себе цену, и хотят флиртовать с "горячими" людьми.
Каждая часть приложения является потенциальной для вовлечения новых пользователей.
Каждый пользователь в среднем приводит 1.4 новых, что является залогом экспонентациального роста.
Для каждого нового пользователя отслеживается количество приглашений, нотификаций, записей на "стене", кликов в профиле и других факторов.
Для каждого канала поступления новых пользователей вычисляются проценты нажавших, успешно вовлеченных и выходов из проекта.

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

На Facebook требуется масштабирование с самого начала. Дорога до миллиона просмотров страниц в сутки заняла 4 недели.
Ruby on Rails может масштабироваться.
При правильном подходе к архитектуре может масштабироваться практически все что угодно, сосредоточтесь на этом.
Вам определенно нужна продуманная архитектура базы данных, качественный хостинг, а также правильно настроенное оборудование.
С использованием кэширования и современных серверов, может пройти достаточно длительный период времени до тех пор, пока понадобится использование баз данных с более сложной структурой, такой как сегментирование.
Социальная сеть - это реальность. Количество новых пользователей в хорошо реализованном Facebook приложении на самом деле ошеломляет.
Большая часть проблем с производительностью в итоге сводится к базе данных. Лишний раз обратите внимание на конфигурацию СУБД, запросы и использование индексов.
Люди до сих пор пользуются Vi!

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

Иван Блинков — Sun, 17 Feb 2008 21:47:00 +0300

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

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

Как и многие статьи об архитектурах высоконагруженных систем на этом блоге, эта запись представляет собой перевод статьи, автором которой является Todd Hoff. Источниками информации для оригинала послужили:

Ранний Amazon от Greg Linden
Как Linux позволил Amazon сэкономить миллионы
Интервью с Werner Vogels'ом - техническим директором Amazon
Асинхронные архитектуры - краткий пересказ речи Werner Vogels'а от Cris Loosley
Познание технологической платформы Amazon - диалог с Werner Vogels
Блог Werner Vogels'а - построение масштабируемых распределенных систем

Платформа

Статистика

Более чем 55 миллионов учетных записей активных покупателей.
Более миллиона активных розничных партнеров по всему Миру.
Для построения страницы осуществляется доступ к 100-150 сервисам.

Архитектура

Что мы на самом деле подразумеваем под словом "масштабируемость"? Обычно говорят, что сервис является масштабируемым, если в случае расширения ресурсов системы производительность растет пропорционально. Рост производительности обычно означает увеличение количества выполняемых в единицу времени работ, но с другой стороны он может означать и рост объемов выполняемых работ, например размер обрабатываемых наборов данных.
Amazon пришлось претерпеть большое архитектурное преобразование в процессе перехода от двух-уровневой монолитной системы к полностью распределенной децентрализованной платформе для сервисов и приложений.
Все началось с одного приложения, обменивающегося данными с внутренним интерфейсом, написанного на C++.
Оно росло. За годы усилий, направленных на масштабирование, Amazon сфокусировался на масштабировании баз данных для хранения постоянно растущего объема информации о предметах, покупателях, заказах, для поддержки нескольких интернациональных сайтов. В 2001 году стало ясно, что исходное веб-приложение больше не в состоянии масштабироваться такими темпами. Базы данных были разбиты на маленькие части и для каждой их них был построен отдельный интерфейс, выполненный в виде сервиса, который являлся единственным способом получить доступ к данным.
Базы данных стали общим ресурсом, что затрудняло рост бизнеса в целом. Интерфейсы, связанные с пользователями и базами данных, были сильно ограничены в своей эволюции, так как они одновременно использовались множеством разных команд разработчиков и процессов.
Их архитектура тесно связана и построена вокруг сервисов. Ориентированная на сервисы архитектура дала им необходимый уровень изоляции для построения множества программных компонентов быстро и независимо.
Система выросла до сотен сервисов и не меньшего количества серверов приложений, агрегирующих информацию, полученную от сервисов. Приложение, генерирующее страницы для Amazon.com, является одним из таких серверов. То же самое можно сказать и про приложения, служащие в роли интерфейса для Веб-сервисов, сервиса, обслуживающего покупателя, интерфейса для продавцов.
Многие другие технологии очень трудно масштабировать до размеров Amazon, особенно технологии коммуникационной инфраструктуры. Они отлично работают до какого-то предела в размерах системы, а после перестают справляться с выполнения своих обязанностей. Именно это подтолкнуло Amazon на создание своих технологий в этой области.
Не ограничиваясь одним конкретным подходом, некоторые части системы используют Java/Jboss, но они являются всего лишь сервлетами.
C++ используется для обработки запросов, в то время как Perl и Mason - для составления контента.
Amazon предпочитает не пользоваться промежуточным программным обеспечением, так как оно в большинстве случаев является каркасом, а не средством разработки. Если используется промежуточное программное обеспечение, то разработчик становится заперт в использование тех принципов разработки, которые выбрал разработчик промежуточного ПО. Если появится необходимость использовать какие-либо другие решения, ничего не выйдет - вы заперты. Один и тот же цикл используется для обработки всех типов событий: сообщений, задержек в передаче данных, AJAX, и так далее. Слишком громоздко. Если бы промежуточное программное обеспечение было бы доступно в виде более мелких компонентов, скорее на правах средства разработки, чем каркаса для системы, тогда Amazon был бы более заинтересован в нем.
Кажется, что SOAP веб стек собирается заново решать все те же проблемы распределенных систем.
Если предложить разработчиком на выбор работу над SOAP и REST веб-сервисами, то только 30% выберут SOAP, это скорее всего будут разработчики на .NET и Java, привыкшие использовать WSDL файлы для генерации интерфейсов удаленных объектов. Оставшиеся 70% выберут REST - это будут пользователи PHP и Perl.
Обе категории разработчиков имеют возможность получить интерфейс к объектам Amazon. Разработчики заинтересованы просто выполнить свою работу, не заботясь о том, что происходит на другом конце провода.
Идея Amazon заключалась в построении открытого сообщества вокруг своих сервисов. Веб-сервисы были выбраны благодаря своей простоте. Но так это выглядит только снаружи. Внутри же находится архитектура, ориентированная на сервисы. Доступ к данным может быть получен только через соответстыующий интерфейс. Этот процесс описан в WSDL, но они используют свои собственные механизмы транспортировки и инкапсуляции данных.
Команды разработчиков очень небольшие и организуются вокруг сервисов
- Сервисы являются независимыми единицами предоставления функционала в рамках Amazon
- Если у разработчика возникает новая бизнес-идея или проблема, которую ему хотелось бы решить, он собирает команду для ее решения или реализации. Количество участников ограничено 8-10 людьми. Команды из такого количества человек обычно называют пиццерийными, так как для того, чтобы ее накормить достаточно двух пицц.
- Команды очень небольшие, но они уполномочены решать поставленную задачу любыми доступными способами, именно так, как они считают нужным. – В качестве примера задачи, поставленной перед такой командой, может служить поиск фраз в рамках книги, уникальных для конкретного текста. – Экстенсивное A/B тестирование используется для интеграции новых сервисов. Они смотрят на произведенное влияние на систему и выполняют экстенсивные измерения.
Развертывание
- Они создают специальную инфраструктуру для управления зависимостями и развертывания.
- Цель состоит в том, чтобы иметь все необходимые сервисы развернутыми на новом оборудовании, в том числе код приложений, системы мониторинга и лицензирования и так далее.
- Результатом развертывания является виртуальная машина, которая запускается с помощью EC2.
Работа с покупателями для того, чтобы убедиться, что внедрение нового сервиса того стоит
- Фокусировка на конкретно на тех возможностях, которые планируется предоставить покупателям
- Разработчики принуждаются работать в первую очередь с упором на предоставление пользователям новых возможностей, а не на внедрение новых технологий и уже после этого осознавание того, зачем это делалось
- Все начинается с пресс-релиза о новых возможностях, предоставляемых пользователям, а после чего ведется работа по определению того факта, планировалось ли все же что-то значимое для пользователей или нет?
- Дизайн должен быть минимален. Простота - залог успеха, когда речь идет о больших распределенных системах
Управление состояниями, как основная проблема крупномасштабных систем
- Изнутри они теоретически могут предоставить практически бесконечный объем дискового пространства.
- Не все, но многие операции имеют состояния. Например, оформление покупки продукта.
- Сервис отслеживания последних открытых страниц использует рекомендации, базирующиеся на идентификационных номерах сессий.
- Они следят за всем, так что в любом случае цель вовсе не в поддержании состояний. Достаточно небольшой набор состояний требует поддержания с помощью сессий. Сервисы уже хранят всю необходимую информацию, остается лишь ими воспользоваться.
Три свойства системы или теорема Eric Brewer'а:
- Три свойства системы: стабильность, доступность, переносимость возможных распадений сети
- В большинстве случаев для любой системы с общими данными выполняются два свойства из трех
- Возможность разделения: распределение узлов по небольшим группам, которые могут иметь доступ к другим группам, но не могут получить доступ к конкретному произвольному узлу системы
- Стабильность: запишите какие-либо данные, а затем прочитайте их же - получите те же самые данные обратно. Для распределенных систем это далеко не всегда так.
- Доступность: не всегда имеется возможность произвести чтение или запись каких-либо данных. Система иногда сообщает, что она не может произвести запись, так как она хочет остаться целостной.
  - Для масштабирования системы необходимо разбиение ее на части, что приводит к выбору между стабильностью и доступностью. Необходимо найти некий баланс между ними.
  - Выберите определенный подход в соответствии с нуждами сервиса.
  - В процессе выбора продуктов приоритет предоставляется доступности: все запросы на добавление товаров в корзину учитываются, так как именно они приносят прибыль. Даже если возникают какие-либо ошибки, они скрываются от покупателя, и разработчики разбираются с ним позже.
  - В процессе подтверждения заказа покупателем важна надежность, так как сразу несколько сервисов одновременно используют одни и те же данные: работа с кредитными картами, доставка, составление отчетов.

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

Для того, чтобы строить реально масштабируемые системы, Вам необходимо изменить свой склад ума. Вероятностный подход к хаосу может принести неплохие результаты. В традиционных системах мы представляем себе идеальный мир, где не происходит никаких чрезвычайных ситуаций, а затем мы в этом же мире пытаемся построить реализацию по-настоящему сложных алгоритмов. При первом же удобном случае вся система гарантированно рушится, это реальность, пора бы уже к этому привыкнуть. Например, неплохим решением мог бы стать подход, использующий быструю перезагрузку и тем самым быстрое восстановление работоспособности. При достаточной избыточности данных и сервисов этот подход может дать практически 100% отказоустойчивость. Необходимо создание самовосстанавливающихся и самоорганизующихся операций.
Создание инфраструктуры, в которой компоненты ничего друг с другом не разделяют. Сама инфраструктура может стать общим ресурсом для разработки и развертывания с теми же недостатками, что и совместные ресурсы в логике и на уровне данных. Это может вызвать запирание и блокировку данных. Архитектура, ориентированная на сервисы, позволяет создание параллельных изолированных процессов разработки, позволяющих масштабировать будущие разработки для соответствия темпам роста.
Откройте систему с помощью собственной API для создания экосистемы вокруг Ваших приложений.
Единственный способ управлять большой распределенной системой - разрабатывать ее как можно более простой. Это достигается благодаря отсутствию скрытых требований и зависимостей в ее структуре. Минимизируйте использование технологий до того уровня, который Вам необходим для решения конкретно Ваших проблем и задач. Создание дополнительных искуственных и ненужных уровней в системе никогда не пойдет ей на пользу.
Организация вокруг сервисов дает гибкость. Параллельная работа возможна, так как на выходе получается сервис. Этот факт резко сокращает время, необходимое для выхода на рынок. Построение инфраструктуры позволяет сервисам реализовываться очень быстро.
Определенно будут возникать проблемы со всем, что пускает пыль в глаза еще до реальной реализации.
Для внутреннего управления сервисами стоит использовать SLA.
Кто угодно может быстро добавлять веб-сервисы к их продукту. Достаточно лишь реализовать часть продукта в виде сервиса и начать его использовать.
Построение инфраструктуры производится для обеспечения производительности, надежности и контролирования издержек. После ее построения Вы никогда не сможете сказать после очередной неудачи, что в этом виновата компания Х. Ваше программное обеспечение не всегда является более надежным, чем любой другой, но зато у Вас появляется возможность быстро устранять неполадки и развертывать ее, в отличии от продуктов других компаний.
Используйте систему оценивания и целенаправленные обсуждения для отделения "хорошего" от "плохого". Бывшие сотрудники Amazon в своих презентациях неоднократно демонстрировали свою глубоко засевшую привычку ставить покупателей перед выбором и смотреть какой из вариантов сработает лучшим образом, и уже на результатах такого рода тестов строить свои решения.
Avinash Kaushik называет это избавлением от "гиппопотамов", наиболее высоко оплачиваемых людей. Осуществляется оно с помощью A/B тестирований и веб-аналитиков. Если у вас есть выбор пути развития, реализуйте оба, позвольте людям ими пользоваться, и посмотрите какой из альтернативных результатов приведет в лучшим результатам.
Создайте экономичную культуру. Amazon использовал двери в роли столов, например.
Знайте, что Вам необходимо. Amazon имеет печальный опыт с ранней системой рекомендаций, которая не сработала: "Это было не то, что требовалось Amazon. Рекомендации книг в Amazon требовали работы с разбросанными данными, всего лишь несколько рейтингов или покупок. Она должна работать быстро. Система должна иметь необходимый масштаб для работы с массивным количеством клиентов и огромным каталогом. Все, что было необходимо: лишь усовершенствовать обнаружение книг из глубин каталога, откуда читатели не могли достать из самостоятельно."
Работа в сторонних проектах, просто так как Вы в них заинтересованы, часто является намного более продуктивной и инновационной, чем просто работа за деньги. Никогда не недооценивайте мощь блуждания в той сфере, которая Вам интересна.
Вовлеките всех в производство еды для собак. Пойдите на склад и упаковывайте книги во время рождественской суеты. Это называется командной работой.
Создайте специальный сайт для тестирования нововведений перед выпуском их в вольное плавание.
Непоколебимая, кластеризованная, реплицирующая, распределенная файловая система является идеальным решением для хранения данных, доступных только для чтения, используемых веб-серверами.
Предусмотрите способы отменить изменения, если обновление не удалось. Если нужно, напишите соответствующие программные средства.
Переключитесь на глубоко сервис-ориентированную архитектуру.
Во время интервью обращайте внимание на три критерия: энтузиазм, креативность, компетентность. Самым крупным залогом успеха Amazon.com был энтузиазм.
Наймите Боба, кого-то кто знает свое дело, обладает невероятными способностями и знанием системы, и что самое важное, умеет решать даже самые невообразимые проблемы просто нырнув в них с головой.
Инновация может прийти только снизу. Те, кто находится ближе всего к проблеме, являются наиболее вероятными людьми, кто смог бы ее решить. Любая организация, зависящая от инноваций, должна уметь пользоваться хаосом. Лояльность и подчинение - не наш метод.
Креативность должна лезть из всех щелей.
У всех должна быть возможность эксперементировать и учиться. Позиции, подчинение и традиции не должны играть какой-либо роли. Для процветания инновации балом должен править точный расчет.
Выберите путь инноваций. Перед лицом всей компании, Jeff Bezos может дать старый кроссовок Nike в роли награды "Просто сделай это" тому, кто привнес инновацию.
Не платите за производительность. Предоставьте хороший повод задрать нос и высокую оплату труда, но оставляйте это простым. Распознать выдающуюся работу можно и другими методами. Оплата по заслугам звучит неплохо, но в условиях большой организации это практически невозможно. Используйте не-денежные награды, такие как тот старый кроссовок. Если преподнести это как способ сказать спасибо, кто-то оценит.
Вырастайте быстро. Большие парни вроде Barnes и Nobel у Вас на хвосте. Amazon не был ни первым, ни вторым, ни даже третим книжным магазинам в Сети, но их взгляд на работу и драйв в итоге позволили им вырваться вперед.
В дата-центрах персонал проводит только 30% времени в работе над вопросами создания инфраструктуры, остальные 70% они проводят за размещения поставок тяжелого оборудования, управлением программным обеспечением, балансировкой нагрузок, техническими работами, изменениями в масштабе и так далее.
Запретите клиентам прямой доступ к базе данных. Это значит появление возможность масштабировать сервис и делать его более надежным не вовлекая при этом клиентов. Это очень похоже на возможность Google независимо вносить улучшения в части системы, что приводит к улучшениям в работе всех остальных ее компонентов.
Создайте единый универсальный механизм получения доступа к сервисам. Это позволяет более легко агрегировать информацию, полученную от сервисов, децентрализованно прокладывать маршруты передачи запросов, распределенно следить за ними, а также получать доступ к другим инфраструктурным механизмам.
Предоставление свободного доступа ко всем сервисам Amazon.com разработчикам со всех уголков Мира также было достаточно значимым компонентом успеха, так как это привлекло на порядок больше инноваций, чем они могли надеяться построить самостоятельно.
Разработчики сами знают какими инструментами они владеют лучше всего, какие из них делают их наиболее продуктивными.
Не накладывайте слишком много ограничений на инженеров. Предоставляйте стимулы для использования некоторых вещей, например интеграцию с системами мониторинга и другими инструментами инфраструктуры. Для всего остального старайтесь предоставлять возможность командам функционировать максимально независимо.
Разработчики, они как художники; они делают свою работу лучше всего только тогда, когда им предоставляют свободу это делать, но в любом случае им требуются качественные инструменты. Имейте много вспомогательных инструментов, имеющих само-помогающую природу. Поддерживайте окружение вокруг разработки сервисов, которое никогда не будет вмешиваться в сам процесс разработки.
Вы построили это, вы и поддерживаете. Это позволяет разработчикам почувствовать повседневную работу их приложения, а также предоставляет им постоянный контакт с покупателями.
Раз в пару лет разработчики должны проводить некоторое время в отделе по работе с клиентами. Это позволит им выслушать покупателей, ответить на электронные письма, и реально осознать влияние тех вещей, которые они реализовали с помощью как технологи.
Пользуйтесь "голосом покупателя", который являлся бы реалистичной историей от покупателя о какой-то конкретной части сайта. Это поможет менеджерам и инженерам осознать тот факт, что все эти технологии построены для реальных людей. Статистика отдела по работе с клиентами является ранним индикатором того, что вы делаете что-то не так, а также указывает на то, что реально является болевыми точками для ваших покупателей.
Инфраструктура Amazon, подобно Google, является огромным конкурентным преимуществом. Они могут строить комплексные приложения на основе примитивных сервисов, которые сами по себе просты до безобразия. Они могут независимо масштабировать свою работу, поддерживать доступность не распараллеленной системы, быстро реализовывать новые сервисы без необходимости массивных изменений в конфигурации.

Отношения online

Иван Блинков — Sat, 16 Feb 2008 13:07:00 +0300

Допустим, у Вас появилось желание оставить на своем интернет-ресурсе ссылку на сайт своего старого друга. Объяснить этот факт простому читателю достаточно просто: <a href="www.site.ru">Сайт моего друга</a>, но поймет ли такую надпись очередной раз инспектирующий Ваш сайт crawler какой-нибудь поисковой системы? Может быть Вы просто злостно торгуете ссылками со своего сайта? Как Вы могли уже догадаться, для решения этой достаточно узкоспециализированной задачи - выражение отношений с владельцем сайта, на который указывает ссылка - существует специальный микроформат под названием XFN, что расшифровывается как XHTML Friends Network. С его помощью любой человек, у которого есть сайт может продемонстрировать всем желающим в каких отношениях он находится с владельцем сайта, на который он ссылается.

Реализуется этот микроформат с помощью атрибута rel тэга <a>, возможные варианты значения (имеется возможность их комбинировать):

Категории значений	Значения XFN
дружба:	`friend`(кто-либо, кого Вы считаете другом), `acquaintance` (знакомый, просто пару раз здоровались или недолго общались), `contact` (кто-либо, с кем Вы знаете как связаться в случае необходимости)
физические:	`met` (кто-либо, с кем вы когда-то лично встречались)
профессиональные:	`co-worker` (коллега по работе),`colleague` (коллега по учебе или иной форме активности)
географические:	`co-resident` (живете на одной улице),`neighbor` (сосед)
семейные:	`child` (ребенок, в том числе и приемный),`parent` (родители, в том числе и приемные),`sibling` (все братья и сетры),`spouse` (муж/жена), `kin` (дальний родственник)
романтические:	`muse` (муза, источник вдохновения), `crush` (кто-либо, к кому у Вас страстное увлечение), `date` (кто-либо, с кем Вы встречаетесь), `sweetheart` (кто-либо, в кого Вы влюбились"}
личность:	`me` (ссылка на самого себя на другом сайте. Обязательно должна быть симметрична; отношение 'me' неявно подразумевается между поддиректорией и всем ее содержимым)

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

<a href="www.site.ru" rel="friend met">
    Сайт моего друга
</a>

Помимо этого есть еще один маленький нюанс, необходимый для того, чтобы browser'ы и поисковые системы знали, что данная страница оффциально поддерживает этот микроформат, для этого необходимо указать следующий атрибут тэгу <head>:

<head profile="http://gmpg.org/xfn/11">

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

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

Иван Блинков — Fri, 08 Feb 2008 22:41:00 +0300

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

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

Как и предыдущий пост "Архитектура Google", этот тоже является переводом статьи от Todd'а Hoff'а. Возможно читателям Google был более интересен, но подход Flickr к масштабируемости тоже более чем заслуживает внимания. Далее привожу источники информации из оригинальной статьи:

Flickr и PHP (ранний документ)
Планирование нагрузок на LAMP
Федерация Flickr: Тур по архитектуре Flickr
Построение масштабируемых веб-сайтов от Call Handerson'а из Flickr
История войн баз данных #3: Tim O'Reilly о Flickr
Cal Henderson's Talks - много полезных презентаций

Платформа

PHP
MySQL
Сегментирование (прим.: разбиение системы на части, обслуживающие каждая свою группу пользователей; называть можно было по-разному, но давайте остановимся на этом варианте перевода слова "Shards")
Memcached для кэширования
Squid в качестве обратной-прокси для html и изображений
Linux (RedHat)
Smarty в роли шаблонизатора
Perl
PEAR для парсинга e-mail и XML
ImageMagick для обработки изображений
Java для узлового сервиса
Apache
SystemImager для развертывания систем
Ganglia для мониторинга распределенных систем
Subcon хранит важные системные конфигурационные файлы в SVN-репозитории для легкого развертывания на машины в кластере.
Cvsup для распространения и обновления коллекций файлов по сети

Статистика

Более четырех миллиардов запросов в день
Примерно 35 миллионов фотографий в кэше Squid
Около двух миллионов фотографий в оперативной памяти Squid
Всего приблизительно 470 миллионов изображений, каждое представлено в 4 или 5 размерах
38 тысяч запросов к memcached (12 миллионов объектов)
2 петабайта дискового пространства
Более 400000 фотографий добавляются ежедневно

Архитектура

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

Два ServerIron
Squid кэши
Системы хранения NetApp
Серверы PHP приложений
Менеджер хранения данных
Master-master сегменты
Центральная база данных, структурированная по принципу Dual Tree
Memcached кластер
Поисковая система

Хранение данных

Структура Dual Tree является индивидуальным набором модификаций для MySQL, позволяющим масштабировать систему путем добавления новых мастер-серверов без использования кольцевой архитектуры. Эта система позволяет экономить на масштабировании, так как варианты мастер-мастер требовали бы удвоенных вложений в оборудование.
Центральная база данных включает в себя таблицу пользователей, состоящую из основных ключей пользователей (несколько уникальных идентификационных номеров) и указатель на сегмент, на котором может быть найдена остальная информация о конкретном пользователе.
Использование выделенных серверов для статического контента
Все, за исключением фотографий, хранится в базе данных
Отсутствие состояний заключается в том, что в случае необходимости они имеют возможность передать пользователей от сервера к серверу, что стало намного проще для них после создания своего API
В основе масштабируемости лежит репликация, но этот факт помогает лишь при обработке операций чтения
Для поиска по определенной части базы данных создается отдельная копия этого фрагмента
Использования горизонтального масштабирования для того чтобы можно было проще добавлять новые машины в систему
Обработка изображений, полученных от пользователей по электронной почте, происходит с помощью PHP
Раньше система страдала от задержек связанных с организацией по принципу мастер-слуга. При слишком большой нагрузке они имели одну точку, которая теоретически могла дать сбой.
Им было необходимо иметь возможность проводить технические работы во время непрерывной работы сайта, не прекращая его функционирование.
Были проведены отличные работы по планированию распределения дискового пространства, более подробную информацию можно найти по ссылкам в разделе "Источники информации".
Для обеспечения возможности масштабирования в будущем, они пошли по федеративному пути развития:
- Сегменты системы: Мои данные хранятся на моем сегменте, но запись о Вашем комментарии хранится на Вашем сегменте.
- Глобальное кольцо: Принцип работы схож с DNS, Вам необходимо знать куда Вы хотите пойти и кто контролирует то место, куда Вы собираетесь пойти.
- Логика на PHP устанавливает соединение с сегментом и поддерживает целостность данных (10 строк кода с комментариями!)
Сегменты:
- Срез основной базы данных
- Активная репликация по принципу мастер-мастер: имеет несколько недостатков в MySQL 4.1. Автоматическое инкрементирование идентификационных номеров используется для поддержания системы в режиме одновременной активности обоих серверов в паре
- Привязывание новых учетных записей к сегментам системы происходит случайным образом
- Миграция пользователей проводится время от времени для того, чтобы избавиться от проблем, связанных с излишне активными пользователями. Необходима сбалансированность в этом процессе, особенно в случаях с большим количеством фотографий… 192 тысячи фотографий, 700 тысяч тэгов, может занять несколько минут. Миграция выполняется вручную.
Нажатие на Favorite:
- Получается информация об учетной записи владельца из кэша для того, чтобы узнать к какому сегменту он привязан (допустим на shard-5)
- Получается информация о моей учетной записи из кэша, более конкретно - мой сегмент (например shard-13)
- Начинается "распределенная транзакция" для определения ответов на вопросы: Кто добавил эту фотографию в избранное? Как изменился список избранных фотографий?
Подобные вопросы могут задаваться любому сегменту, информация на них абсолютно избыточна.
Для избавления от задержек, связанных с репликацией...
- при каждой загрузке страницы, пользователю предоставляется список серверов
- если сервер не в состоянии ответить на запрос, запрос переходит к следующему серверу в списке; если список кончился - выводится сообщение об ошибке. При этом не используются постоянные соединения, каждый раз создаются и разрываются новые соединения.
Запросы на чтение и запись от каждого пользователя ограничиваются рамками одного сегмента. Задержки репликации исчезают из поля зрения пользователей.
Каждый сервер в рамках одного сегмента в обычном состоянии нагружен ровно на половину. Выключите половину серверов в каждом сегменте и система продолжит функционировать без изменений. Это значит, что один сервер внутри сегмента может взять на себя всю нагрузку второго, в то время как второй сервер может по каким либо причинам быть отключен от системы, например для проведения технических работ. Обновление оборудования производится очень просто: отключается половина сегмента, она же обновляется, подключается обратно, процесс повторяется для оставшейся половины.
Периоды пиковой нагрузки также нарушают правило 50% нагрузки. В такие моменты система получает 6-7 тысяч запросов в секунду, в то время как на данный момент система может работать на пятидесятипроцентном уровне нагрузки только при четырех тысячах запросов в секунду.
В среднем при загрузке одной страницы выполняется 27-35 SQL-запросов. Списки избранных фотографий обрабатываются в реальном времени, ровно как и доступ через API к базе данных. Все требования к нагрузке в реальном времени выполняются без каких-либо недостатков.
Более 36 тысяч запросов в секунду может выполняться не выходя за рамки возможностей системы, даже при резком росте трафика.
Каждый сегмент содержит данные о более чем 400 тысячах пользователей.
Многие данные хранятся в двух местах одновременно. Например, комментарий является частью между комментатором и автором комментируемого контента. Где его хранить? Как насчет обоих мест? Транзакции используются для предотвращения рассинхронизации данных: открывается первая транзакция, выполняется запись, открывается вторая транзакция, выполняется запись, подтверждается первая транзакция если все нормально, после чего вторая подтверждается только в случае если первая прошла успешно.

Поиск

Используется два варианта поиска: поиск в рамках сегмента, поддерживающий до 35 тысяч запросов в секунду, а также проприетарный веб-поиск от Yahoo!
В 90% случаев используется система от Yahoo!, за исключением поиска по тэгу фотографий одного пользователя и массовых изменений тэгов.
Эту систему стоит рассматривать как аналог Lucene.

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

EMT64 под управлением RHEL 4 с 16 Gb оперативной памяти.
6 жестких дисков с 15000rpm, объединены в RAID-10.
Размер для пользовательских метаданных достигает 12 терабайт (это не включает фотографии, для них цифры существенно больше).
Используются 2U корпуса.

Резервное копирование данных

ibbackup выполняется регулярно посредством cron daemon'а, на каждом сегменте настроен на разное время.
Каждую ночь делается снимок со всего кластера баз данных.
Запись или удаление нескольких больших файлов с резервными копиями одновременно на реплицирующую систему хранения может сильно сократить производительность системы вцелом на последующие несколько часов из-за процесса репликации. Выполнение этого на активно работающей системе хранения фотографий было бы не самой лучшей идеей.
Содержание нескольких резервных копий всех Ваших данных требует существенных материальных затрат, но оно того стоит. Особенно это актуально для тех ситуаций, когда Вы понимаете, что что-то пошло не так только спустя несколько дней после того как это случилось, в таких случаях неплохо иметь, например, резервные копии 1, 3, 10 и 30-дневной давности.
Фотографии хранятся в системе хранения данных. После загрузки изображения система выдает различные его размеры, на чем ее работа заканчивается. Метаданные и ссылки на файловые системы, где расположены фотографии, хранятся в базе данных.
Агрегация данных проходит очень быстро, так как она ограничена пределами сегмента.
max_connections = 400 соединений на каждый сегмент, неплохой запас. Значение для кэша потоков установлено равным 45, так как не бывает ситуаций когда более 45 пользователей одновременно выполняют какие-либо действия с одним конкретным сегментом.

Тэги

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

Направления для развития

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

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

Старайтесь думать о своем приложении как о чем-то большем, чем просто веб-приложении, тогда у Вас возможно появятся поддержка различных API, RSS и Atom ленты и многие другие возможности.
Отсутствие состояний системы позволяет более легко выполнять модернизации не моргнув и глазом.
Реструктуризация базы данных - не самое лучшее занятие.
Планирование нагрузок должно проводиться уже на ранних этапах развития проекта
Начинайте медленно. Не покупайте сразу много оборудования просто из-за того, что Вы рады/боитесь, что ваш сайт взорвется.
Измеряйте реально, планирование нагрузок должно базироваться на реальных вещах, а не абстрактных.
Внедряйте ведение логов и индивидуальные измерения для оценки реальных показателей на основе серверной статистики, статистика использования не менее важна чем серверная.
Кэширование и оперативная память может стать ответом на все вопросы.
Создавайте четкие уровни абстракции между работой базы данных, бизнес-логикой, логикой страниц, разметкой страниц и презентационным уровнем. Это позволяет ускорить циклы итеративной разработки.
Разделение приложения на уровни позволяет каждому заниматься своим делом: разработчики могут строить логику страниц, в то время как дизайнеры работают с удобством работы для пользователей.
Делайте релизы как можно чаще, пускай даже это будет происходить каждые полчаса.
Забудьте о всех небольших эффективных вещах, предварительная оптимизация является корнем всего зла в примерно 97% всех случаев.
Тестируйте в работе. Постройте архитектурные механизмы (флаги конфигурации, балансировку нагрузки, и так далее), которые позволят Вам разворачивать новое оборудование в (и из) работу.
Забудьте об искусственных тестах, они годятся только для получения общего представления о нагрузках, но не для планирования. Искуственные тесты дают искусственные результаты, для настоящих тестов все же стоит пользоваться реальным временем выполнения задач.
Найдите максимальное значения для всех показателей:
- Какой максимум чего-то, что может выполнять каждый сервер?
- Как близко параметр находится к максимуму и каковы тенденции?
- MySQL (дисковый ввод/вывод?)
- Squid (дисковый ввод/вывод? или процессорное время?)
- Memcached (процессорное время? или пропускная способность?)
Старайтесь учесть особенности использования Вашего приложения.
- Возможен ли резкий рост нагрузки, связанный с каким-либо событием? Например: какое-либо бедствие, или может быть новость?
- Flickr получает на 20-40% больше новых фотографий в первый рабочий день нового года, чем в любой пик в предыдущем году.
- По воскресеньям нагрузка в среднем на 40-50% выше, чем в любой другой день недели.
Учтите возможность экспоненциального роста. Больше пользователей означает больше контента, больше контента означает больше соединений, больше соединений означает более активное использование.
Планируйте возможные варианты управления работой системы в периоды пиковых нагрузок.

На пути к идеалу

Иван Блинков — Thu, 07 Feb 2008 15:39:00 +0300

...или 15 привычек, которые помогут ускорить PHP-приложение

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

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

Повышения значения индекса с помощью ++\$i;

Этот факт был наверное одним из самых удивительных для меня, когда я впервые о нем услышал, но действительно операция ++\$i; выполняется несколько быстрее, чем \$i++;. или другие вариации на ту же тему вроде \$i+=1;. Привычка использовать в качестве индекса цикла переменную под названием i, казалось бы стара как Мир, мне она досталась в наследство от C, а в месте с ней "в комплекте" шла привычка писать выражение i++ в заголовках циклов. Разница в скорости обработки этих выражений, насколько мне известно, обусловлена разным количеством элементарных машинных операций, которые необходимо выполнить процессору (в точных цифрах не уверен, пишу по памяти, но ++\$i; требует трех элементарных операций, а \$i++; – четырех). В справедливости этого факта не трудно убедиться, достаточно написать простенький скрипт, состоящий из цикла с достаточно большим количеством итераций, и замерить любым способом точное время его выполнения при использовании разных способов инкрементации индекса цикла.

Вывод статического контента без помощи PHP

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

Вывод статического контента из отдельного файла

Частенько при желании выполнить указанное в заголовке действие по привычке используют include, require или их _once версии, что является далеко не самой лучшей идеей с точки зрения производительности. Самым быстрыми быстрыми и экономичными поотношению к оперативной памяти являются функции readfile и fpassthru. В качестве доказательства этого факта приведу таблицу, демонстрирующую статистику выполнения этой операции различными методами и позаимствованную с одного англоязычного сайта:

Функция	Время (сек.)		Оперативная память (байт)
Функция	32Kb файл	1Mb файл	32Kb файл	1Mb файл
file\_get\_contents	0.00152	0.00564	52480	1067856
fpassthru	0.00117	0.00184	20016	20032
fgets	0.00195	0.07190	30760	30768
file	0.00157	0.06464	87344	2185624
require\_once	0.00225	0.08065	67992	2067696
readfile	0.00117	0.00191	19192	19208

Вывод переменных

Наверняка вам известно, что переменные можно выводить с помощью конструкции вроде echo "\$var text";, что является одним из самых удобных вариантов решения этой задачи благодаря минимальному количеству символов, которые необходимо набрать, но с точки зрения быстродействия этот вариант далек от идеала, так как влечет за собой достаточно серьезные преобразования в памяти сервера, эффект которых порой бывает заметен невооруженным глазом. Частично ущерб производительности можно сгладить заменой этой конструкции на echo \$var." text";, что приводит к несколькому усложнению внешнего вида кода и несколько поправляет ситуацию со скоростью выполнения. Но как известно знак . обозначает конкатенацию двух строк, что тоже требует некоторых вычислений и затрат памяти, но и от нее можно избавиться, заменив на запятую. Выражение echo \$var," text"; ничем по своему эффекту не отличается от предложенных ранее вариантов, за исключением максимального быстрого выполнения, обусловленного отсутствием дополнительных преобразований в процессе передачи просто последовательности из константы и переменной.

Избегайте выполнения лишних действий

Достаточно абстрактное утверждение, но тем не мение постоянное напоминание себе о нем может избавить Вас от совершения массы ошибок. Самой широкораспространенной является наверное вызов какой-либо функции (чаще всего count(); или strlen();) в проверке условия выхода из цикла. Когда-нибудь доводилось писать видеть в собственном или чужом коде выражение вида for(\$i = 0; \$i \< count(\$array); ++\$i) { ... }? А задумываться о последовательности выполнения действий при его обработке? Стоит только немного начать размышлять и ошибка становится очевидной: count(); выполняется при каждой итерации цикла, что приводит к подсчету количества элементов массива при каждой проверки условия выхода из цикла - почему бы не посчитать это значение заранее и сравнивать значения индекса с переменной, а не с результатом выполнения функции?

@

Использование этого оператора стоит избегать при каждой возможности. Казалось бы такое простое действие, как сокрытие вывода возможного сообщения об ошибке, влечет за собой достаточно трудоемкую последовательность действий: устанавливает значение параметра PHP-интерпретатора error_reporting = 0, выполняет указанное за этим оператором действие, возвращает значение error_reporting в исходное состояние.

Маленькие мелочи

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

Вместо условия if(\$variableOne == \$variableTwo) { ... } можно написать if(\$variableOne === \$variableTwo) { ... }, что избавит от проверки на соответствие типов данных и приведения их друг к другу, в некоторых случаях эти действия эти случаях эти действия конечно же и бывают необходимы, но бывает это далеко не часто.
Глядя на выражения вроде if(\$boolean == true) { ... }, я чаще всего вспоминаю цитату из одного малоизвестного интернет-ресурса: if (b.ToString().length \< 5) { ... }. Хоть и не имет никакого отношения к PHP, но суть проблемы отражает очень ярко.
Самым очевидным способом проверить попадает ли длина строки в какой-либо диапазон является использование функции strlen(); и сравнение полученного результата с фиксированными значениями, но зачем выполнять лишний вызов функции, если можно воспользоваться услугами конструкцией языка PHP isset(); для определения наличия в строке определенных символов. if(isset(\$str{5})) { ... } приведет к абсолютно тем же результатам, что и if(strlen(\$str)>4){ ... }
Битовые операции выполняются намного быстрее относительно обычных арифметических действий. Об этом факте редко вспоминают, да и работать с ними умеет далеко не каждый, но порой они бывают очень актуальны, особенно при частой работе с числами кратными двойке.
Угадайте, что делает интерпретатор при виде надписи 1/2? Правильно: делит 1 на 2. Зачем лишний раз утруждать его, когда можно написать просто половину - 0.5.
При возвращении значения переменной из функции при помощи global выполняется на порядок больше действий, чем при классическом return.
Конечно же фраза \$array[text]; интерпритируется практически точно так же, как и \$array['text'];, но зачем выполнять лишнее преобразование из необъявленной константы в строку, проверять, что такой константы все же не существует, выводить сообщение типа E_NOTICE, если можно всего этого не делать?
По возможности не используйте require_once(); или include_once(); неоднократно по отношению к одному и тому же файлу. При отсутствии какого-либо эффекта, попусту тратится время на обработку повторного запроса.
Даже "безобидных" ошибок стоит избегать, лишняя проаерка потратит не так много процессорного времени, как генерирование достаточно длинного сообщения об ошибке и вывод его в stdout, stderr или лог-файл, а также не стоит забывать, что даже "безобидные" ошибки могут стать потенциальной угрозой безопасности приложения вцелом.

В заключении...

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

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

Иван Блинков — Thu, 31 Jan 2008 18:05:00 +0300

Эта статья датируется 2008 годом, новая версия: Архитектура Google 2011

Google - Король масштабируемости.

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

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

Сразу хочу сказать, что эта запись является переводом с английского, автор оригинальной версии - Todd Hoff. Оригинал написан приблизительно в середине 2007 года, но по-моему до сих пор очень даже актуально.

Далее следует перечисление источников информации из оригинала:

Платформа

Linux
Большое разнообразие языков программирования: Python, Java, C++

Что внутри?

Статистика

На 2006 год система включала в себя 450000 недорогих серверов
За 2005 год было проиндексировано 8 миллиардов страниц. На данный момент… кто знает?
На момент написания оригинала Google включает в себя более 200 GFS кластеров. Один кластер может состоять из 1000 или даже 5000 компьютеров
Десятки и сотни тысяч компьютеров получают данные из GFS кластеров, которые насчитывают более 5 петабайт дискового пространства. Суммарные пропускная способность операций записи и чтения между дата центрами может достигать 40 гигабайт в секунду
BigTable позволяет хранить миллиарды ссылок (URL), сотни терабайт снимков со спутников, а также настройки миллионов пользователей

// Цифры не первой свежести конечно, но тоже неплохо.

Стек

Google визуализирует свою инфраструктуру в виде трехслойного стека:

Продукты: поиск, реклама, электронная почта, карты, видео, чат, блоги
Распределенная инфраструктура системы: GFS, MapReduce и BigTable
Вычислительные платформы: множество компьютеров во множестве датацентров
Легкое развертывание для компании при низком уровне издержек
Больше денег вкладывается в оборудование для исключения возможности потерь данных

Надежное хранение данных с помощью GFS

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

Она предоставляет:
- высокую надежность дата центров
- масштабируемость до тысяч сетевых узлов – высокую пропускную способность операций чтения и записи
- поддержку больших блоков данных, размер которых может измеряться в гигабайтах
- эффективное распределение операций между датацентрами для избежания возникновения "узких мест" в системе
В системе существуют мастер-сервера и сервера, собственно хранящие информацию:
- Мастер-сервера хранят метаданные для всех файлов. Сами данные хранятся блоками по 64 мегабайта на остальных серверах. Клиенты могут выполнять операции с метаданными на мастер-серверах, чтобы узнать на каком именно сервере расположены необходимые данные.
- Для обеспечения надежности один и тот же блок данных хранится в трех экземплярах на разных серверах, что обеспечивает избыточность на случай сбоев в работе какого-либо сервера.
- Новые приложения могут пользоваться как существующими кластерами, так и новыми, созданными специально для них.
- Ключ успеха заключается в том, чтобы быть уверенными в том, что у людей есть достаточно вариантов выбора для реализации их приложений. GFS может быть настроена для удовлетворения нужд любого конкретного приложения.

Работаем с данными при помощи MapReduce

Теперь, когда у нас есть отличная система хранения, что же делать с такими объемами данных? Допустим, у нас есть много терабайт данных, равномерно распределенных между 1000 компьютерами. Коммерческие базы данных не могут эффективно масштабироваться до такого уровня, именно в такой ситуации в дело вступает технология MapReduce.
MapReduce является программной моделью и соответствующей реализацией обработки и генерации больших наборов данных. Пользователи могут задавать функцию, обрабатывающую пары ключ/значение для генерации промежуточных аналогичных пар, и сокращающую функцию, которая объединяет все промежуточные значения, соответствующие одному и тому же ключу. Многие реальные задачи могут быть выражены с помощью этой модели. Программы, написанные в таком функциональном стиле автоматически распараллеливаются и адаптируются для выполнения на обширных кластерах. Система берет на себя детали разбиения входных данных на части, составления расписания выполнения программ на различных компьютерах, управления ошибками, и организации необходимой коммуникации между компьютерами. Это позволяет программистам, не обладающим опытом работы с параллельными и распределенными системами, легко использовать все ресурсы больших распределенных систем.
Зачем использовать MapReduce? – Отличный способ распределения задач между множеством компьютеров – Обработка сбоев в работе – Работа с различными типами смежных приложений, таких как поиск или реклама. Возможно предварительное вычисление и обработка данных, подсчет количества слов, сортировка терабайт данных и так далее – Вычисления автоматически приближаются к источнику ввода-вывода
MapReduce использует три типа серверов:
- Master: назначают задания остальным типам серверов, а также следят за процессом их выполнения
- Map: принимают входные данные от пользователей и обрабатывают их, результаты записываются в промежуточные файлы
- Reduce: принимают промежуточные файлы от Map-серверов и сокращают их указанным выше способом
Например, мы хотим посчитать количество слов на всех страницах. Для этого нам необходимо передать все страницы, хранимые в GFS, на обработку в MapReduce. Этот процесс будет происходить на тысячах машин одновременно с полной координацией действий, в соответствии с автоматически составленным расписанием выполняемых работ, обработкой потенциальных ошибок, и передачей данных выполняемыми автоматически.
- Последовательность выполняемых действий выглядела бы следующим образом: GFS → Map → перемешивание → Reduce → запись результатов обратно в GFS
- Технология MapReduce состоит из двух компонентов: соответственно map и reduce. Map отображает один набор данных в другой, создавая тем самым пары ключ/значение, которпыми в нашем случае являются слова и их количества.
- В процессе перемешивания происходит агрегирование типов ключей.
- Reduction в нашем случае просто суммирует все результаты и возвращает финальный результат.
В процессе индексирования Google подвергает поток данных обработке около 20 разных механизмов сокращения. Сначала идет работа над всеми записями и агрегированными ключами, после чего результат передается следующему механизму и второй механизм уже работает с результатами работы первого, и так далее.
Программы могут быть очень маленькими, всего лишь от 20 до 50 строк кода.
Единственной проблемой могут быть "отстающие компьютеры". Если один компьютер работает существенно медленнее, чем все остальные, это будет задерживать работу всей системы в целом.
Транспортировка данных между серверами происходит в сжатом виде. Идея заключается в том, что ограничивающим фактором является пропускная способность канала и ввода-вывода, что делает резонным потратить часть процессорного времени на компрессию и декомпрессию данных.

Хранение структурированных данных в BigTable

BigTable является крупномасштабной, устойчивой к потенциальным ошибкам, самоуправляемой системой, которая может включать в себя терабайты памяти и петабайты данных, а также управлять миллионами операций чтения и записи в секунду.
BigTable представляет собой распределенный механизм хэширования, построенный поверх GFS, а вовсе не реляционную базу данных и, как следствие, не поддерживает SQL-запросы и операции типа Join.
Она предоставляет механизм просмотра данных для получения доступа к структурированным данным по имеющемуся ключу. GFS хранит данные не поддающиеся пониманию, хотя многим приложениям необходимы структурированные данные.
Коммерческие базы данных попросту не могут масштабироваться до такого уровня и, соответственно, не могут работать с тысячами машин одновременно.
С помощью контролирования своих низкоуровневых систем хранения данных, Google получает больше возможностей по управлению и модификации их системой. Например, если им понадобится функция, упрощающая координацию работы между датацентрами, они просто могут написать ее и внедрить в систему.
Подключение и отключение компьютеров к функционирующей системе никак не мешает ей просто работать.
Каждый блок данных хранится в ячейке, доступ к которой может быть предоставлен как по ключу строки или столбца, так и по временной метке.
Каждая строка может храниться в одной или нескольких таблицах. Таблицы реализуются в виде последовательности блоков по 64 килобайта, организованных в формате данных под названием SSTable.
В BigTable тоже используется три типа серверов:
- Master: распределяют таблицы по Tablet-серверам, а также следят за расположением таблиц и перераспределяют задания в случае необходимости.
- Tablet: обрабатывают запросы чтения/записи для таблиц. Они разделяют таблицы, когда те превышают лимит размера (обычно 100-200 мегабайт). Когда такой сервер прекращает функционирование по каким-либо причинам, 100 других серверов берут на себя по одной таблице и система продолжает работать как-будто ничего не произошло.
- Lock: формируют распределенный сервис ограничения одновременного доступа. Операции открытия таблицы для записи, анализа Master-сервером или проверки доступа должны быть взаимоисключающими.
Локальная группировка может быть использована для физического хранения связанных данных вместе, чтобы обеспечить лучшую локализацию ссылок на данные.
Таблицы по возможности кэшируются в оперативной памяти серверов.

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

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

Разное

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

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

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

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

Инфраструктура может быть конкурентным преимуществом. Это определенно так для Google. Они могут выпускать новые интернет сервисы быстрее, с меньшими издержками, на таком уровне, что мало кто сможет составить им конкуренцию. Подход многих компаний сильно отличается от подхода Google, эти компании рассматривают инфраструктуру как статью расходов, они обычно используют совсем другие технологии и совсем не задумываются о планировании и организации своей системы. Google позиционирует себя как компанию по построению систем, что является очень современным подходом к разработке программного обеспечения.
Охватывание нескольких дата центров до сих пор является нерешенной проблемой. Большинство сайтов базируется в одном или двух дата центрах. Полное распределение сайта между несколькими датацентрами является хитрой задачей.
Взгляните на Hadoop, если у Вас нет времени на собственноручное построение всей архитектуры с нуля. Hadoop является opensource воплощением в жизнь многих идей здесь представленных.
Часто недооцениваемым преимуществом платформенного подхода является тот факт, что даже неопытные разработчики могут быстро и качественно реализовывать трудоемкие приложения на базе платформы. Но если бы каждый проект требовал одинаково распределенной архитектуры, то это создало бы много проблем, так как люди, которые понимают как это делается, являются достаточно большой редкостью.
Совместная деятельность не всегда является таким уж плохим занятием. Если все части системы работают взаимосвязанно, то улучшение в одной из них сразу и абсолютно прозрачно отразится положительным образом и на остальных компонентах системы. В противном случае такой эффект наблюдаться не будет.
Построение самоуправляемых систем позволяет более легко перераспределять ресурсы между серверами, расширять систему, отключать некоторые компьютеры и элегантно проводить обновления.
Производить длительные операции стоит параллельно.
Всему, что было сделано Google, предшествовало искусство, а не только крупномасштабное развертывание системы.
Учитывайте возможность компрессии данных, она является очень неплохим решением, если остается лишнее процессорное время, но присутствует нехватка пропускной способности.

Защита интернет-ресурсов в картинках

Иван Блинков — Sun, 13 Jan 2008 22:30:00 +0300

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

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

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

Подготовка

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

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

Описание класса, генерирующего изображение
Файл, который будет вызываться browser'ом. В нем будет подключено описание нашего класса, выбор настроек данного конкретного изображения и выполнено создание объекта класса, в соответствии с выбранными настройками.

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

Итак, создание объекта будем производить максимально простым способом, параметрами укажем белый и черный цвета. Заготовка для самого класса будет выглядеть примерно следующим образом (предположим, что он хранится в файле captcha.class.php):

<?php
class Captcha
{
   private $string; // генерируемый текст
   private $bgcol;  // основной цвет фона
   private $fgcol;  // основной цвет текста
   private $height; // высота изображения
   private $width;  // ширина изображения
   function __construct($bgcol,$fgcol)  // конструктор, вызывается при создании экземпляра класса
   {
   }
}
?>

Задаем параметры

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

<?php
private function generateImage()  // генерация изображения
{
  $this->width=250;
  $this->height=80;
  $this->fgcol=$fgcol;
  $this->bgcol=$bgcol;
  $this->generateSymbols();
 }
 private function generateSymbols()   // генерация четырех цифр
 {
    $this->string=$this->leadingZero(rand()%10000,4);
 }
 private function leadingZero($num,$length) // дополнения числа num лидирующими нулями
 {                        // до длины length
  $str=strrev($num);
  for($i=strlen($str);$i<$length;++$i)$str.="0";
  return strrev($str);
 }
}
?>

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

Генерируем изображение

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

<?php
private function generateImage()  // генерация изображения
{
   $im=@imagecreatetruecolor($this->width,$this->height);
   $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
   $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
   imagefill($im,0,0,$bcol);
   imagettftext($im,40,10,20,25,$fcol,"./font/font_name.ttf",$this->string));
   header('Content-Type: image/png');
   imagepng($im);
   imagedestroy($im);
}
?>

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

Реально же ей пользоваться не стоит - такое изображение с легкостью поддается OCR. Полученный текст необходимо тем или иным образом исказить. Для вывода изображения используется формат PNG, но никто не мешает воспользоваться JPEG или GIF, для этого достаточно заменить везде png на название соответствующего формата.

Искажаем текст

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

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

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

<?php
private function generateImage() // генерация изображения
{
   $im=@imagecreatetruecolor($this->width,$this->height);  // создаем пустое изображение
   $mcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%55); // выбираем случайным образом
   $kcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%20); // несколько цветов
   $lcol=imagecolorallocate($im,$this->bgcol[0]-rand()%20,$this->bgcol[1]-rand()%20,$this->bgcol[2]-rand()%20);
   $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
   $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
   imagefill($im,0,0,$bcol);  // заполняем изображение фоном
   $array=array(6,7,6,6,20,20,25,26,31,32,37,39,41); // список названий подходящих шрифтов
   $n=$array[rand()%count($array)];  // наугад выбираем из них один
   $m=rand()%50+1;
   $k=rand()%50+1;
   for($i=0;$i<$m;++$i)
   imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$lcol); // создаем на фоне несколько линий
   for($i=0;$i<$k;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$lcol); // и еще несколько
   /*
   Генерируем текст: две строки на фон, а также интересующие нас символы по одному.
   */
   imagettftext($im,rand()%20+40,rand()%100-50,rand()%$this->height*0.8,rand()%50+25,$kcol,"./font/".$k.".ttf",$this->randomString(rand()%15));
   imagettftext($im,rand()%40+35,rand()%70-35,rand()%$this->height*0.8,rand()%25+25,$mcol,"./font/".$m.".ttf",$this->randomString(5+rand()%4));
   for($i=0;$istring);++$i)
   imagettftext($im,rand()%10+33,rand()%70-35,15+$i*$this->width/5*1.1+rand()%5,rand()%7+$this->height*0.73,$fcol,"./font/".$n.".ttf",$this->string[$i]);
   for($i=0;$i<$m/10;++$i)
   imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$mcol); // еще линии
   for($i=0;$i<$k/4;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$mcol);  // и еще немного
   for($i=0;$i<$k/6;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$fcol);  // и еще чуть-чуть
   header('Content-Type: image/png');
   imagepng($im);
   imagedestroy($im);
}
private function randomString($length)  // генерируем случайный набор символов заданной длины
{
  $list="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXYZ!@#$%^&**()-=_+.,<>/\|;:";
  for($i=0,$str="";$i<$length;++$i)$str.=substr($list,mt_rand(0,strlen($list)-1),1);
  return $str;
}
?>

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

Сборка

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

Собрав все написанное выше, и учтя передачу текста, можно получить следующий класс:

<?php
class Captcha
{
   private $string; // генерируемый текст
   private $bgcol;  // основной цвет фона
   private $fgcol;  // основной цвет текста
   private $height; // высота изображения
   private $width;  // ширина изображения
   function __construct($bgcol,$fgcol)  // конструктор, вызывается при создании экземпляра класса
   {
      $this->width=250;
      $this->height=80;
      $this->fgcol=$fgcol;
      $this->bgcol=$bgcol;
      $this->generateSymbols();
      $this->generateImage();
   }
   private function generateImage() // генерация изображения
   {
      $im=@imagecreatetruecolor($this->width,$this->height);  // создаем пустое изображение
      $mcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%55); // выбираем случайным образом
      $kcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%20); // несколько цветов
      $lcol=imagecolorallocate($im,$this->bgcol[0]-rand()%20,$this->bgcol[1]-rand()%20,$this->bgcol[2]-rand()%20);
      $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
      $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
      imagefill($im,0,0,$bcol);  // заполняем изображение фоном
      $array=array(6,7,6,6,20,20,25,26,31,32,37,39,41); // список названий подходящих шрифтов
      $n=$array[rand()%count($array)];  // наугад выбираем из них один
      $m=rand()%50+1;
      $k=rand()%50+1;
      for($i=0;$i<$m;++$i)
      imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$lcol); // создаем на фоне несколько линий
      for($i=0;$i<$k;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$lcol); // и еще несколько
      /*
      Генерируем текст: две строки на фон, а также интересующие нас символы по одному.
      */
      imagettftext($im,rand()%20+40,rand()%100-50,rand()%$this->height*0.8,rand()%50+25,$kcol,"./font/".$k.".ttf",$this->randomString(rand()%15));
      imagettftext($im,rand()%40+35,rand()%70-35,rand()%$this->height*0.8,rand()%25+25,$mcol,"./font/".$m.".ttf",$this->randomString(5+rand()%4));
      for($i=0;$istring);++$i)
      imagettftext($im,rand()%10+33,rand()%70-35,15+$i*$this->width/5*1.1+rand()%5,rand()%7+$this->height*0.73,$fcol,"./font/".$n.".ttf",$this->string[$i]);
      for($i=0;$i<$m/10;++$i)
      imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$mcol); // еще линии
      for($i=0;$i<$k/4;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$mcol);  // и еще немного
      for($i=0;$i<$k/6;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$fcol);  // и еще чуть-чуть
      header('Content-Type: image/png');
      imagepng($im);
      imagedestroy($im);
   }
   private function generateSymbols()   // генерация четырех цифр
   {
      $this->string=$this->leadingZero(rand()%10000,4);
   }
   private function leadingZero($num,$length) // дополнения числа num лидирующими нулями
   {                        // до длины length
      $str=strrev($num);
      for($i=strlen($str);$i<$length;++$i)$str.="0";
      return strrev($str);
   }
   private function randomString($length)  // генерируем случайный набор символов заданной длины
   {
      $list="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXYZ!@#$%^&**()-=_+.,<>/\|;:";
      for($i=0,$str="";$i<$length;++$i)$str.=substr($list,mt_rand(0,strlen($list)-1),1);
      return $str;
   }
}
?>

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

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

7 способов защитить свой интернет-ресурс от нежелательной информации

Иван Блинков — Thu, 03 Jan 2008 20:41:00 +0300

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

1. Классический вариант - графическая реализация

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

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

Казалось бы это существование таких алгоритмов делает бессмысленным использованием такого рода "защиты", но на практике это далеко не так: большинство из них пригодны только для распознавания только узкого набора реализаций графических captch, особенно это актуально для популярных готовых решений реализации этого типа защиты находящимся в свободном доступе в сети Интернет, а также сервисов, предоставляющих услуги по генерации такого рода изображений. Что делает довольно актуальным написание собственной реализации графической captch'и для появления уверенности в отсутствии готовой модификации OCR алгоритма, для преодоления используемой преграды. Об этом и пойдет речь в записи про собственноручную реализацию технологии CAPTCHA.

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

2. Сommon sense

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

3. Математический тест

Помимо просто перенабирания некоторого набора цифр с изображения, авторы captch'и могут попросить своего посетителя выполнить какую-либо несложную операцию (например: 2 x 2 = ???). Но такого рода тесты также далеки от идеала, так как в подавляющем большинстве алгоритм их решения прост для безобразия - вполне достаточно бывает базового OCR и реализации калькулятора внутри crawler'a, чтобы он смог преодолеть такого рода барьер.

4. Выбор изображения

Хочется также упомянуть один из достаточно оригинальных вариантов реализации, являющийся по сути вариацией на тему common sense captch'и, который меня как минимум удивил, когда я его впервые увидел на сайте одного из мобильных операторов рядом с формой для online отправки SMS. Суть его заключалось в том, что предлагался набор небольших фотографий, из которых предлагалось выбрать 2-4 изображения обладающих каким-либо свойством, например являющимися живыми объектами. Помимо позитивненького оформления и симпатичных фотографий, чисто технически такой подход является достаточно эффективным и легко реализуемым, единственное предъявляемое к такой реализации требование - достаточно обширная база данных изображений.

5. Выход за рамки стандартов

Большинство вещей, предназначенных для массового использования, принято делать по принципу "чем проще тем лучше". Обусловлено это тем, что количество пользователей обратно пропорционально уровню требований, к ним предъявляемых. Формы на интернет-страницах, как ни странно, исключением из этого принципа не являются, что является причиной их построения с использованием только базовых языков разметки - HTML, XHTML или в крайнем случае XML. Именно такую форму и ожидает увидеть spider, попадая на страницу. Но если поступиться этим принципом - легко поставить программу в тупиковое положение, задействовав какую-либо непривычную для нее технологию. В качестве примера в голову приходит Flash-ролик вместо изображения в графическом варианте реализации.

Этот способ является очень эффективным, но обладает существенными недостатками, такими как, например, необходимость использования современных браузеров с определенными plug-in'ами.

6. Скрытие разметки

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

7. Звуковое воплощение

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

Вместо заключения хотелось бы предложить Вам подписаться на RSS этого блога.

Откуда возникает спам и как с ним бороться

Иван Блинков — Thu, 03 Jan 2008 20:25:00 +0300

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

Good vs Evil

Большая часть "хороших" spider'ов используется лишь для сбора информации о сайте и следуют пожеланиям владельцев сайтов, оставленных ими в специальном файле под названием robots.txt, либо внутри HTML-разметки с помощью специально предназначенных для этого тэгов (этот механизм выходит за рамки данного повествования, так что позволю себе его пропустить, оставив как тему для отдельного разговора).

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

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

Защита форм от автоматического заполнения

Наверняка многие из вас раньше слышали термин CAPTCHA, но боялись спросить: что же он значит? Как не трудно догадаться этот термин является аббревиатурой :). Расшифровывается она как "Completely Automated Public Turing test to tell Computers and Humans Apart". Для меня до сих пор остается загадкой по какому принципу выбирались слова для составления этой аббревиатуры, наверное тупо случайным образом :). Смысл этой фразы в переводе на русский можно передать как "полностью автоматический способ отличить человека от компьютера". Конечно же имеется ввиду не внешние различия, а особенности их поведения на просторах сети Интернет. В роли "компьютера" в данном случае как раз выступают программы, о которых шла речь в самом начале. Эта технология позволяет владельцам сайтов, желающих исключить (по крайней мере чисто теоретически, на практике же - минимизировать) посещение своего ресурса "плохими" "компьютерами", крайне затруднить их использование.

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

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

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

Привет, мир!

Иван Блинков — Thu, 03 Jan 2008 19:36:00 +0300

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

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