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

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

Статистика

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

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

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

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

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

О компании Baidu

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

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

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

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

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

Aladdin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[poll id="11"]

[poll id="12"]

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

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

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

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

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

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

Платформа

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

Что внутри?

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

Работа сайта

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

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

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

Зато через какое-то время наткнувшись на очередную заметку про все ту же довольно избитую тему, я заметил ма-а-аленькую неприметную ссылку на «инструкцию по компиляции Google 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/m11/Local Settings/Application Data/Google/Chrome/Application/chrome.exe--new-http --in-process-plugins

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

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

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

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

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

Пару дней назад произошел corruption данных в MySQL (судя по логам), нужно было восстанавливать ее из дампа, но руки никак не доходили из-за работы. Слушать музыку в техподдержке хостинга желания тоже особо не было, так что не нашел ничего лучшего, чем закрыть временно блог под пароль до тех пор пока не разберусь. Когда я добрался-таки до блога выяснилось, что хостинг провайдер меня в phpmyadmin пускать отказывается с формулировкой «Access denied». Разбираться в чем причина опять же было не охота, так что не обломавшись залез на хостинг по ssh и загрузил дамп в базу через консольный mysql-клиент. Ничем хорошим тоже не закончилось — он умудрился каким-то образом напутать что-то с кодировкой, хотя и сам файл и в create table явно был указан UTF-8.

Забросив это дело, на следующий день я обнаружил, что хостинг-провайдер передумал и решил пустить-таки меня в phpmyadmin. Пободавшись с которым насчет излишне большого размера дампа (не знаю с каких пор 700кб стало считаться большим дампом), мне удалось-таки вернуть все в исходное состояние, так что WELCOME!

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

Если Вы хотите помочь развитию блога — мое предложение все еще в силе, да и подписаться на RSS еще не поздно

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

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

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

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

Платформа

• Linux
• Tomcat
• Java

Статистика

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

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

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

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

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

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

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

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

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

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

Приступим?

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

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

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

идентификационные

– различные варианты имен объекта.

адресные

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

телекоммуникационные

– любые формы контактной информации: номера телефонов, факс, адреса электронной почты и так далее.

географические

– месторасположение объекта.

организационные

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

уточняющие

– любая дополнительная информация об объекте.

безопасность

– ограничение доступа к информации в hCard.

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

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

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

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

Иван подпрыгнул три раза на месте,
  обернулся и увидел написанную на стене
  свою фамилию: Блинков.

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

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

Иван
  подпрыгнул три раза на месте,
  обернулся и увидел написанную на стене
  свою фамилию: Блинков.

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

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

given-name

– имя.

additional-name

– отчество.

family-name

– фамилия.

honorific-preffix

– какой-либо префикс к имени, отображающий социальный статус человек.

honorific-suffix

– суффикс с тем же смыслом.

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

    Иван
    Иванович
    Блинков
  

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

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

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

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

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 можно вот ТУТ.

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

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

• Как Digg.com использует LAMP для масштабирования
• Масштабируемость и производительность PHP в Digg

Платформа

• MySQL
• Linux
• PHP
• Lucene
• APC PHP Accelerator
• Memcached

Статистика

• Проект стартовал в конце 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 масштабируется для того, чтобы обеспечить торговлю всеми этими красивыми людьми? Как Вы думаете, сколько стоят Ваши друзья на открытом рынке?

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

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

• Ответы на стандартный набор вопросов от 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», но мы стараемся отложить неизбежный переход к сегментированной базе данных на как можно более длительный срок. На данный момент базы данных масштабируются вертикально, но со временем, надеюсь, мы сможем от этого избавиться.

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

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

1. Ни один из двух разработчиков ранее не имел опыта в крупномасштабных разработках на основе Rails.
2. Наша траектория роста проекта достаточно редка в истории разработок с использованием Rails.
3. У нас практически не было возможностей для кэширования статических страниц — каждый запрос страницы приходилось обрабатывать 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!

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

С уважением,
Блинков Иван

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

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

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

Платформа

• Linux
• Oracle
• C++
• Perl
• Mason
• Java
• Jboss
• Сервлеты

Статистика

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

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

Как не трудно заметить, практически все возможные варианты отношений могут быть описаны одним из значений или их комбинацией. Наш пример из начала этого поста с использованием XFN выглядел бы: <a href="www.site.ru" rel="friend met">Сайт моего друга</a>

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

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

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

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

Как и предыдущий пост «Архитектура 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% выше, чем в любой другой день недели.

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