Insight IT

YAPC::Russia 2008 May Perl

Иван Блинков — Sat, 17 May 2008 16:58:00 +0400

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

Началось все с того, что мне в голову взбрела достаточно глупая мысль съездить к 9 утра субботы на лекции в университет, ни о какой конференции я не знал естественно. Не знаю как я умудрился вовремя проснуться, но так или иначе я выбрался из дома и отправился в свой ВУЗ, правда несколько изменив своей традиции делать это на метро - ранним утром на машине добраться до туда мне можно существенно быстрее, да и комфортнее. Лекции были по какому-то скучному предмету, так что я решил прогуляться и наткнулся случайно в коридоре на своего знакомого по имени Петр Федин, который, как оказалось, участвовал в организации этого мероприятия. Именно он и поведал мне о проведении в нашем ВУЗе (то есть ГУ-ВШЭ) конференции "May Perl", а также порекомендовал ее посетить. Собственно говоря в тот момент она только начиналась, и я не нашел ничего лучше кроме как согласиться, так как возвращаться на лекцию продолжать читать книжку на телефоне мне явно не хотелось.

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

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

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

Следующим пунктом программы был очень поверхностный рассказ о POE. К этому моменту я уже вполне привык к Perl'у и трудностей с пониманием кода больше не испытывал, так что понимать было существенно проще. Суть доклада заключалась в обзоре возможностей, предоставляемым эти окружением. Оно предоставляет возможность работы приложения как на очень низком уровне, так и с помощью предоставляемых высокоуровневых абстракций и framework'ов. Система имеет модульную структуру, основу которой составляют модули POE::Kernel и POE::Session, а остальные строятся на их базе и позволяют программисту пользоваться широким предоставляемым набором инструментов для решения задач различной сложности путем построения логики приложения в виде совокупности обработчиков событий, вызываемых как вручную так и при взаимодействии с внешними объектами.

После этого выступления конференция fork'анулась на две аудитории: в одной проходил мастер-класс по все тому же POE с Иваном Сережкиным из Яндекс, куда я собственно и пошел, а в другой (как я понял) - обзор framework'а Jifty. Мастер-класс был достаточно впечатляющим, даже при том что я ежедневно пользуюсь Linux, я был несколько удивлен увиденной мной на экране проектора операционной системой: очень минималистичный оконный менеджер с массой рабочих столов, на которых располагалось куча приложений, по большей части консольных. Дополнительное впечатление произвел владелец этой системы, который пользовался ей на удивление быстро и слаженно. Сам мастер-класс заключался в реализации средствами POE на ходу придумываемой задачи, которую на ходу же и меняли по определенным причинам (по большей части благодаря своеобразности организации доступа в интернет в здании). Как и любой нормальный программист, ведущий мастер-класс человек (не знаю как это правильно называется одним словом), в процессе очень активно и эффективно пользовался мануалами, а также советами и предложениями коллег. Процесс написания кода сопровождался подробнейшими комментариями, так что даже я прекрасно понимал что и зачем пишется в данный момент и вообще о чем идет речь.

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

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

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

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

Иван Блинков — Thu, 10 Apr 2008 00:24:00 +0400

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

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

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

Основным источником информации послужила презентация Brad Fitzpatrick в Токио.

Платформа

Linux (Debian Sarge)
Perl
Apache
MySQL 4.0/4.1 в основном с InnoDB
Perlbal, веб-сервер и балансировщик нагрузки
memcached для распределенного кэширования
MogileFS, распределенная файловая система
Gearman
TheShwartz
djabberd

Статистика

на данный момент 15320315 учетных записей; (10.04.08)
из них активно используется 551589;
наиболее активно сервис используется в США и Российской федерации, а 2/3 пользователей - девушки и женщины;
более 15 миллионов новых записей в блогах за месяц;
более 50 миллионов просмотров страниц в день, при пиковой нагрузке - несколько тысяч в секунду (сильно устаревшие цифры, 2004 год);
связь с внешним миром осуществляется через два BIG-IP (активный + в режиме ожидания) с автоматическим восстановлением работоспособности в случае сбоя в работе одного из них, защитой от DDoS, L7 набором правил, включая TCL;
более сотни серверов, насчет конфигурации известен только тот факт, что практически на каждом сервере установлены огромные объемы оперативной памяти (более 12 GB) для эффективного кэширования.

История

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

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

Применительно к LiveJournal эту схему лучше всего демонстрирует один из слайдов презентации, указанной в источниках информации:

При работе такой системы не используется auto_increment в MySQL, а также используется составной primary key из номера пользователя и номера записи. Таким образом пространство имен объектов разбито на группы, соответствующие конкретному пользователю.

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

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

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

memcached

Залогом быстрой загрузки любой страницы крупного интернет-проекта является кэширование. Но как всегда возникает вопрос: а на каком уровне обработки данных его стоит выполнять? Для динамических страниц недопустимо кэширование на уровне готовых страниц. Можно кэшировать на уровне mod_perl, но по сути это пустая трата оперативной памяти, так как создастся отдельный кэш для каждого потока Apache, и количество промахов мимо кэша будет огромно. Кэширование запросов MySQL или HEAP таблицы также не дали бы требуемого результата ввиду чрезвычайной распределенности базы данных.

Выходом из сложившейся ситуации стало написание собственной распределенной системы кэширования объектов, получившей название memcached. Она позволяет:

использовать для кэширования свободную оперативную память практически любого компьютера, задействованного в системе;
кэшировать объекты практически любого языка программирования в сериализованном виде: Perl, PHP, Java, C++ и так далее;
использовать для передачи кэшируемых данных простой протокол, не требующий избыточности данных;
избегать даже теоретической возможности полного сбоя работы кэшируещей системы в связи с полной равнозначностью серверов;
достигать превосходной производительности при формировании HTML-кода страниц;
в разы снизить нагрузку на базы данных в проекте любого масштаба.

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

Perlbal

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

быстрый;
небольшой размер;
"сообразительный";
обработка "мертвых" узлов;
может выступать как в роли reverse proxy, так и балансировщика нагрузки;
базовый функционал классического веб-сервера;
реализация внутреннего перенаправления данных;
поддержка некоторых менее существенных трюков, реализованных обычно в виде plug-in'ов.

Perlbal не так активно используется вне LiveJournal, по сравнению с memcached, но для решения конкретной задачи он подошел как нельзя лучше.

MogileFS

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

Как и все файловые системы этого класса, MogileFS работает на уровне пользовательских приложений и использует достаточно тривиальные протокол передачи данных и общую архитектуру: клиенты, управляющие серверы, абстрактные базы данных, сервера для хранения самих данных - в этом плане ничего нового придумано не было. Доступ к файлам осуществляется с помощью HTTP-запросов PUT/GET либо через виртуальный NFS-раздел. Единственной особенностью можно назвать уклон в построение собой абстрактной прослойки между приложением и собственно кластером базы данных (в случае LiveJournal - сегмента), используемой в роли альтернативы более тривиальной master/slave схемы.

Gearman

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

В рамках LiveJournal Gearman применяется в основном для:

обработка изображений средствами Image::Magick вне perl-приложений;
создание pool'а DBI соединений (DBD::Gofer + Gearman);
уменьшением нагрузки, создаваемой отдельными компонентами системы;
улучшения субъективного впечатления пользователей о быстродействии сервиса, благодаря выполнению части работ параллельно в фоновом режиме;
выполнение блокирующего ресурсы кода отдельно от обработчиков различных событий.

TheShwartz

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

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

Основными сферами применения TheShwartz в LJ являются:

отправка электронной почты (SMTP клиент);
LJ Notifications: каждое событие может вызывать за собой цепочку из тысяч уведомлений по электронной почте, SMS, XMPP и так далее;
отправка RPC сообщений внешним сервисам;
внедрение Atom потоков;

djabberd

Как всегда следуя принципу "чем проще - тем лучше", разработки LJ написали этот крошечный daemon, лежащий в основе их Jabber/LJTalk. Он способен спокойно работать с более чем 300 тысячами соединений, используя очень скромное количество оперативной памяти для поддержания каждого соединения.

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

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

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

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

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

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

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

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

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

Платформа

Статистика

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

Архитектура

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

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

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

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

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

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

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

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

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

Платформа

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

Статистика

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

Архитектура

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

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

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

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

Поиск

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

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

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

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

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

Тэги

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

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

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

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

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