Мысли о масштабируемости

14.01.2012

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

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

Build it to Break (Стройте так, чтобы сломать)

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

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

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

Everything is a Feature (Все – это фича, отличительная особенность)

Как однажды лихо сказал Джефф Этвуд (Jeff Atwood), производительность – это фича. Основная мысль Джеффа в том, что дать приложению максимальную производительность – это решение, которые Вы принимаете в процессе разработки. Поэтому, размышляя в том же ключе, сделать приложение отказоустойчивым – это тоже должно быть сознательным решением.

Посему, любое решение – это компромисс. Обзор всего приложения как ряд компромиссов ведет к лучшему пониманию того, как приложение будет работать в реальном мире. И разница в том, можно ли расширять приложение вверх и вширь закладывается именно в нескольких ключевых решениях, которые были сделаны на ранних стадиях разработки.

Scale Out, Not Up (Масштабируйте вширь, но не вверх)

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

Самый простой способ масштабирования, как правило, находится на уровне приложений, требуется просто добавить еще серверов. Что происходит, когда возникает необходимость масштабировать базу данных? Нынешняя тенденция состоит в покупке более быстрого сервера с более быстрыми дисками и большим объемом памяти. И этот процесс постоянно повторяется. Надеюсь, что Ваша необходимость в новых серверах будет продолжаться в темпе, которые меньше, либо равен темпу инноваций. Есть и другие проблемы с масштабированием. В процессе повышения производительности, железо становится все более и более дорогим, однако удельный прирост производительности становится все меньше и меньше. Разница в цене между самым быстрым CPU и вторым самым быстрым CPU как правило куда больше, чем получаемый выигрыш в производительности – масштабирование вверх как правило имеет огромную стоимость.

Кроме масштабирования вверх существует масштабирование вширь. Когда мы говорим о масштабирование вширь, то для обработки дополнительной нагрузки просто добавляются дополнительные сервера. Один из простейших способов масштабировать вширь базу данных – это добавить реплики только для чтения. Запросы на запись обрабатываются на главном сервере, потому что масштабирование вширь записи может быть очень и очень сложным. Но что делать, если нам все-таки необходимо масштабировать вширь запись? К счастью, есть много методов для горизонтального масштабирования слоя базы данных. Фичи могут использовать разные хранилища данных, метаданные реплицируются между всеми серверами, в том время как бизнес данные разбиваются на шарды (shards). Кроме того, можно использовать автоматизированные техники, как например SQL Azure Federation.

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

Buy more storage (Покупайте больше жестких дисков)

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

Хитрость в том, что современные системы управления базами данных могут умело распределять нагрузку между несколькими файлами или даже дисками. Если в процесс считывания данных вовлечено несколько файлов/дисков/шпинделей/логических томов, то данные будут считаны быстрее, чем если бы был вовлечен только один большой диск. Принцип горизонтального масштабирования лучше вертикального масштабирования даже на уровне системы хранения – несколько дисков, как правило, быстрее чем один большой.

You’re Going to Do It Wrong (Вы все равно сделаете это неправильно)

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

Поэтому, будьте готовы переписать ядро приложения при масштабировании. Твиттер был изначально построен на Ruby On Rails. С течением времени, они реализовали различные части приложения с помощью разных инструментов. Готовность Twitter переписать основные компоненты свой инфраструктуры, стала важной частью успеха.

Не бойтесь изменений – делайте их. (Don’t be afraid to change everything)