По ссылке с 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
14 коммент.:
> Твой софт, возможно, не лучше чужого, но ты можешь его поправить, отладить и развить быстрее, чем чей-то чужой софт.
К этому я обычно добавляю: только если у вас крутые разработчики. А то чаще бывает, что люди, которые только вчера чему-то научились, сразу начинают делать все с нуля, обосновывая это тем, что Google или Amazon тоже так делают.
Большое спасибо за обзор и перевод!
Очень интересная ссылка. ИМХО, в таких проектах идет борьба желания сделать просто и необходимости потом все это поддерживать и развивать. Все-таки зоопарк это ужасно. Если нет договоренностей о некотором стандарте внешних протоколов, то все превращается в кашу...
Вот описание системы хранения Amazon:
Dynamo. Там очень интересный аппарат используется
Алена выбрала их потому что в обороте С, в Амазоне, видимо, от старого сишного кода немогут избавиться до сих пор...
спасибо за обзор
Большое спасибо за статью
2Андрей:
Алена выбрала их потому что в обороте С, в Амазоне, видимо, от старого сишного кода немогут избавиться до сих пор...
Я не очень поняла смысл этой фразы, но ощущаю какой-то наезд.
Спасибо большое, очень интересно.
Алёна! Почему так долго нет постов? Заждались :)
Алёна - у Вас очень интересные посты - есть что почитать - особенно понравились об архитектуре и идеях.
Чужой код использовать терпеть не могу - а вот чужие идеи можно дополнить и что-то поюзать.
2Exo:
Алёна! Почему так долго нет постов? Заждались :)
Спокойствие только спокойствие. Всё будет :-)
2SVGreg:
Алёна - у Вас очень интересные посты - есть что почитать
Хех, приятно :-)
Пожалуйста :-)
Спасибо, интересная и познавательная статья!
Интересно было бы увидеть новый актуальный обзор на этих гигантов.
Отправить комментарий