По ссылке с lktalks нашла интересный сайт, посвященный архитектуре больших систем - High Scalability. Там много чего есть, но наибольший интерес, конечно, вызвают архитектуры известных проектов. Я почитала про те, что посоветованы на lktalks и сделала небольшой обзор. На High Scalability все описано подробнее.
Amazon.com
Amazon - самый известный Интернет-магазин.
Используют: Linux, Oracle, C++, Perl, Mason, Java, Jboss, Servlets
У них более 55 миллионов активных аккаунтов. Начали они с одного приложения, которое общалось с бэкэндом. Написано это все было на C++.
Сегодняшняя архитектура Амазона слабосвязная. Построена вокруг сервисов. Это дало им изоляцию, которая позволят строить многочисленные софтверные компоненты быстро и независимо.
Все разрослось на сотни сервисов и несколько серверов приложений, которые агрегируют информацию с сервисов. Например, приложение, которое рендерит странички amazon.com, это один из таких серверов приложений.
Технологии третьих сторон для амазоновского сайта масштабировать тяжело. До определеного момента все работает, а потом уже не работает. Амазоновцам пришлось все свое строить.
Они не придерживаются какого-то одного подхода. Где-то используют
jboss/java, но используют они только сервлеты, больше ничего из J2EE не используют.
C++ для обработки запросов. Perl/Mason для построения контента.
Не используют middleware. Потому что если используешь, то тебе приходится мириться с архитектурными решениями, которые выбрали за тебя.
Используют как SOAP, так и REST. ~30 процентов SOAP'а.
Команды у них небольшие и организованы вокруг сервисов. Команда - это 8-10 человек, иначе уже начинаются коммуникационные проблемы. Эти команды называются "команда двух пицц". Это количество людей, которых можно накормить двумя пиццами.
Работают для пользователя. Надо сосредотачиваться на том, что ты хочешь дать пользователю. Заставить разработчиков фокусироваться на том, что дается пльзователю, а не строить сначала какую-то технологию, а потом пытаться понять как это можно использовать.
Дизайн должен быть настолько минимальным, насколько это вообще возможно. Простота - ключ к построению больших распределенных систем.
Какие сделали выводы в процессе
Приходится менять свои взгляды, чтобы построить действительно масштабируемую систему. В традиционных сстемах мы представляем себе идеальный мир, в котором ничего не может сломаться, а потом разрабатываем сложне алгоритмы для этого идеального мира. Вместо этого надо принять тот факт, что вещи ломаются.
Открой свою систему, предоставь API и ты создашь экосистему вокруг своих приложений.
Единственный путь управиться с такой огромной распределенной системой - это сохранять вещи настолько простыми, насколько это возможно. Не должно быть никаких скрытых требований или скрытых зависимостей в дизайне.
Нужна своя собственная инфраструктура чтобы получить производительность, отказоустойчивость и контроль за расходами. Если ты все это разрабатываешь сам, никогда у тебя не будет причин сказать, что что-то сломалось по вине компании Х. Твой софт, возможно, не лучше чужого, но ты можешь его поправить, отладить и развить быстрее, чем чей-то чужой софт.
Нужны возможности откатить апдейт если что-то не работает.
Разработчикам лучше знать какие именно тулзы делают их более продуктивными и какие именно тулзы подходят для конкретной работы.
YouTube
Используют: Apache, Python, Linux (SuSe), MySQL, psyco (динамический компилятор python->C), lighttpd вместо Apache
Для балансировки загрузки и кэширования статического контента используют NetScalar.
YouTube - это 100 миллионов просмотров в день.
2 сисадмина, 2 архитектора софта по масштабированию
2 девелопера, 2 сетевых инженера, 1 специалист по БД.
Их рецепт как управиться с быстрым ростом системы :
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}
Питон способствует быстрой разработке. Питоновский код обычно не является узким местом, проблемы вызывают RPC.
Каждое видео хостится на мини - кластере. Каждое видео обслуживается более чем одной машиной.
Советуют использовать простое и дешевое оборудование. Держать как можно меньше оборудования между пользователем и контентом. Использовать серийное оборудование. Более дорогое оборудование означает более дорогую поддержку, причем при этом вряд ли найдешь какую-нибудь помощь в Интернете если что.
Неожиданной проблемой оказалась работа с тамбнейлами. Это очень много очень маленьких картинок. По 4 на каждое видео. Проблемы с обслуживанием большого количества маленьких объектов - много приходится рыскать по диску, много запросов в секунду происходит, потому что на одной странице может быть до 60 тамбнейлов. Апач с такой нагрузкой справляется плохо. Пробовали использовать squid вместе с Апачем, пробовали lighttpd. В итоге они стали использовать Гугловский BigTable и это решило все их проблемы. (От себя добавлю, что с использованием BigTable у них наступило настолько полное счастье, что оно выглядит подозрительно. Ну не может быть чтобы вообще никаких проблем не было)
Для хранения метаданных (пользователи, описания) используют MySQL.
Наиболее интересные выводы
Надо уметь расставлять приоритеты. Надо знать, что в твоем сервисе является наиболее важным и концентрировать ресурсы именно там.
Ну и - Keep it simple!
Еще там есть описание архитектур Google и Flickr.
Ссылки по теме:
Про Google я как-то писала довольно подробно
Также на High Scalability упоминалась ссылка на Introduction to Distributed System Design
Atom feed