Insight IT

Веб-сервер за два вечера

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

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

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

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

Предистория

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

Ассортимент оборудования, спрятанного внутри 1U корпуса, был вполне стандартным, ничего особенного: процессор Intel Xeon 5335, оперативная память Kingston 2х2 GB ECC Full-buffered, жесткий диск изначально только один - WD 150 GB 10000rpm SATA, а вот модель материнской платы, к сожалению, на память назвать не могу, вроде что-то от SuperMicro, с простенькой встроенной видеокартой, сетевой картой с двумя гигабитными Ethernet портами и встроенным же видимо software RAID-контроллером. Опытный глаз наверняка заметил бы в этом списке сильную недоукомплектацию, особенно проявляющуюся при упоминании процессора в единственном числе, отсутствии RAID, и скромным объемам оперативной памяти. Объясняется это достаточно просто - проект еще предстоит тестировать перед запуском, а этой платформы для этого будет более чем достаточно.

Перед запуском проекта в открытое плавание естественно предстоит upgrade оборудования.

День первый

Подготовка

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

Почему выбор пал именно на эту ОС объяснить не так уж и просто, но я все же попробую. Выбор был достаточно классический: Unix vs Linux, возникали еще некоторые сомнения насчет решений от Sun в виде Solaris и OpenSolaris, но от них я отказался достаточно быстро в основном из-за более чем скромной документации и проприетарного происхождения, попутно закрыв глаза на все положительные отзывы, которые я видел в Сети.

Так как мне хотелось иметь иметь перед собой конструктор для сбора системы именно таким образом, как было бы удобно мне, а не разработчикам дистрибутива, то список вариантов, выступавших на стороне Linux быстро начал сокращаться, начиная с CentOS. Предпоследним вычеркнутым из списка дистрибутивов Linux был Debian, что оставило в нем лишь Gentoo Linux. Финальный выбор между FreeBSD и Gentoo был сделан уже легче: во-первых, по своему опыту с ноутбуком я уже понял, что с Gentoo предстояло бы немало хлопот, а, во-вторых, в новый конструктор, как ни крути, "играть" намного интереснее, чем в старый, так что долго думать не пришлось :)

Установка

Найдя наконец диск с FreeBSD, я попытался решить следующий возникший вопрос: а как же установить операционную систему с компакт-диска на компьютер, не имеющий соответствующего привода? Так как сервер был запломбирован и находился на гарантии, вариант частично разобрать и подключить обычный привод отпал сразу же, ровно как и вариант с подключением внешнего привода по причине его отсутствия. Подходящее решение было найдено практически сразу же, благо жесткие диски подключались по принципу hotswap: вытащив жесткий диск без развинчивания корпуса, я подключил его к подвернувшемуся под руку настольному компьютеру, обладающему DVD-приводом. Загрузка прошла успешно и я приступил к установке, руководствуясь FreeBSD Handbook, пересказывать его особого желания у меня нет, остановлюсь лишь на некоторых особенностях этого процесса.

Первым этапом установки, где пришлось задуматься, был fdisk (разбиение диска на так называемые slice). Для избежания путаницы для самого себя, я решил, что размещу рабочие директории http-сервера и базы данных в /var, которую и выделил в отдельный slice, занимающий большую часть доступного дискового пространства. В ассортимент доступного при установке программного обеспечения я особо вникать не стал, так как знал, что у меня всегда будет возможность заняться им позже, и как следствие этого выбрал что-то очень близкое к стандартному набору ПО. Подтвердив установку и подождав достаточно непродолжительный период времени, я перезагрузил систему, вытащив установочный диск в процессе. Установка оказалась на удивление элементарной, что привело к полученной с первой попытки работоспособной системе. Увидев долгожданное приглашение к вводу логина и пароля я убедился, что могу беспрепятственно получить доступ к консоли и сразу же выключил систему, чтобы перенести жесткий диск обратно на сервер.

Так как сетевое подключение еще только предстояло настроить, то на сервер переносить пришлось не только жесткий диск, но и монитор с клавиатурой. На новом оборудовании все так же прекрасно запустилось, и я принялся за настройку подключения. Особых проблем не возникло - в Handbook'е все более чем качественно задокументировано, самым сложным был процесс выбора драйвера, вернее осознавание того, что он изначально правильно сам установился. Следующей маленькой проблемой было угадывание какой же из Ethernet-портов был только что настроен, и, соответственно, подключение кабеля именно в него, а не в его соседа. После завершения всех манипуляций я с радостью обнаружил, что ping от сервера до gateway'а успешно проходит, что по сути и означало окончание настройки сетевого подключения. Следущей целью было избавить себя от необходимости пользоваться позаимствованными у другого компьютера клавиатурой и монитором. Дело тоже оказалось достаточно нехитрым, sshd установился и настроился вполне самостоятельно где-то в процессе установки, от меня потребовалось лишь создать дополнительного пользователя, написать нехитрую строчку в rc.conf: sshd_enable="YES" и собственно запустить daemon'а. Этого было вполне достаточно, чтобы набрав на своем ноутбуке ssh в консоли, с указанием необходимых параметров, получить удаленный доступ к серверу по протоколу SSH.

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

День второй

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

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

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

Так как одной из основных составных частей практически любого веб-сервера является http-daemon, именно с его выбора я и решил начать. Причем начал еще задолго до описываемых событий, вся многофункциональность Apache мне была не нужна, а аналоги mod_auth и mod_rewrite есть и в более легких http-серверах. Cамо веб-приложение, которое там предполагалось располагать, работает по большей части на PHP, так что ничего особенного от httpd совсем не требовалось. В итоге финальный выбор был между быстрыми и легкими вариантами: nginx и lighttpd, какой-либо весомой причины по которой я выбрал lighttpd с mod\_fastcgi привести не могу, основным фактором был мой некоторый опыт работы с ним в прошлом, и отсутствие такового в отношении nginx. Установка прошла легко и непринужденно с помощью в сжатые сроки найденного в Google мануала.
Другим немаловажным компонентом сервера является ftpd, как известно используемый для передачи файлов. Собственно говоря, если активное его использование не планируется, то особого значения какой именно сервер будет использоваться значения не имеет: любой из доступных устанавливается настраивается в пару простых шагов без каких-либо проблем (если это имеет значение - я выбрал vsftpd, так как мне уже далеко не один раз доводилось его настраивать на домашних компьютерах, и, как следствие, даже инструкция не понадобилась). Но при потенциальной возможности работы через Интернет, этот протокол является достаточно уязвимым, так как не использует никакого шифрования. Эта проблема решается с помощью механизма FTP over SSH, который представляет собой использование SSH в роли туннеля для передачи файлов по FTP. О том, как воспользоваться этим механизмом вам подскажет man ssh, какой-либо дополнительной конфигурации он не требует, разве что настройки соответствующим образом firewall'а, но об этом я расскажу позже.
Сам PHP установлен последней доступной в ports версии и , как уже упоминалось, был подключен к lighttpd с помощью mod_fastcgi, какой-либо дополнительной конфигурации с моей стороны не потребовалось, я разве что выбрал список модулей (в общем-то тоже занятие не сложное, достаточно лишь осознавать какие именно используются, плюс я еще решил Suhosin установить) и просто просмотрел по диагонали все конфиги (в основном сам php.ini и lighttpd.conf) на предмет их соответствия потребностям моего приложения. Отдельная история возникла с лишь одним модулем - Blitz, который на данный момент все еще отсутствует в репозиториях как FreeBSD, так и подавляющего большинства (если не всех) дистрибутивов Linux. Его пришлось устанавливать вручную из исходников по соответствующему мануалу, что правда тоже дело не хитрое и заняло всего несколько минут.
СУБД особо выбирать не пришлось - приложение написано было с расчетом на PostrgeSQL, ее соответственно и прикручивал к PHP. Этот этап был пожалуй одним из самых проблематичных, так как сразу после классического make install clean соответствующий daemon запускаться отказался. Какого-либо осознанного сообщения об ошибке /usr/local/etc/rc.d/postgresqld start не выводило как в консоль, так и в логи, но тем не менее консольный клиент psql и само веб-приложение жаловались на отсутствие запущенной СУБД. Этот факт сильно затруднял поиск возможных вариантов решения на просторах Сети, так что не найдя ничего полезного я решил заняться диагностикой проблемы и поиском решения для нее самостоятельно. Методом проб и ошибок, перебрав множество возможных вариантов запуска daemon'а, я пришел к выводу, что у пользователя от имени которого он должен был запускаться явно проблемы с доступом к файловой системе. Видимо так получилось из-за нестандартного расположения самой базы данных - в директории /var. Не смотря на тот факт, что chown и chmod были использованы по прямому назначению в отношении соответствующих директорий для установления прав доступа. В итоге оказалось, что директория указанная для этого пользователя как домашняя (по памяти пишу, могу ошибиться, но вроде /usr/local/pgsql) по каким-то причинам не создалась и соответственно именно этот факт и мешал запуску daemon'а. Восстановив справедливость в отношении этого пользователя, я обнаружил, что PostrgeSQL успешно запустился-таки, а мое приложение тоже стало функционировать именно так, как ему было положено. Проверив содержимое соответствующего конфига, я решил его больше не трогать, а то как говорится "premature optimization is the root of all evil"&copyright;. За компанию решил установить веб-интерфейс к PostrgeSQL - phppgadmin. Собравшись из портов, он повел себя как-то не очень адекватно, совсем не так каким я привык его видеть у себя на ноутбуке, разбираться в причинах было не охота - простое копирование и замена соответствующей директории по ftp буквально за минуту решило проблему.
Вариантов фильтров сетевого трафика в FreeBSD имеется предостаточно: pf, ipf, ipfw. Опыта работы ни с одним из них у меня не было, так что выбор происходил из достаточно субъективных критериев - очевидности принципов работы правил и достаточности документации. Так как я был уверен, что каждый из них сможет обеспечить достаточный уровень безопасности, основываясь на указанных выше критериях в итоге я выбрал ipf. Документация позволила легко и непринужденно все установить и настроить, правда за компанию пришлось разбираться и с пересборкой ядра. В качестве базы для построения собственного списка правил я использовал приведенный все там же, в документации, пример. Само собой пришлось доработать его под конкретную систему, но методом проб и ошибок эта задача выполняется достаточно быстро (будте осторожны с 22 портом, используемым для SSH - очень легко на этом этапе случайно заблокировать самому себе доступ к серверу). Получившийся в итоге список правил приводить не буду, так как его еще предстоит довести до ума на активно работающей системе.

Заключение

Не прошло и двух дней, как из простого набора оборудования получился вполне готовый к работе веб-сервер, конечно же доводить до ума его придется еще достаточно долго, но просто стабильно работать он был в состоянии уже тогда. Дальше его отвезли в место постоянного его прибывания, подключили к более-менее приличному интернет-каналу, с моей стороны при этом потребовалось лишь слегка поменять настройки сетевого подключения, и вот - он уже доступен из Сети. Практически сразу же обнаружился один мой недочет в плане выбора ПО - буквально в первую же ночь после открытия публичного доступа к серверу нашлась масса желающих попытаться подобрать по словарю логин и пароль для доступа к серверу по SSH, но он был открыт лишь для одной учетной записи, у которой было мягко говоря нестандартное имя пользователя, даже его никто за ночь не смог угадать, а до более чем 20-символьного пароля дело так и не дошло. На следующее утро я, не долго думая, установил программу под названием sshguard, которая сразу же предотвратила все последующие попытки подобным образом издеваться над сервером. Дальше надо было настроить запись на DNS-сервере для ассоциации домена с IP нашего сервера, настроить почту, закончить работу над самим веб-приложением и много чего еще, но это уже совсем другая история.

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

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

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

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

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

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

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

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

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

Платформа

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

Что внутри?

Статистика

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

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

Стек

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

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

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

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

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

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

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

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

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

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

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

Разное

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

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

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

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

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