Создано на wordle

Эта картинка обычно отражает мысли человека, перед которым стоят два факта:

1. Система растет
2. Производительность падает

Закапываясь в проблемы производительности и масштабирования, мы зачастую забываем и путаем что и зачем мы делаем. В этой статье мы вернемся к первым вопросам, на которые необходимо отвечать постоянно, что-бы не збиваться с курса.

Основы основ

Для того, что-бы принимать решения, необходимо понимать, что тот или иной подход (технология, методика, принцип, практика и т.д.) даст Вашей системе. И так, вернемся к базовым вещам.

Производительность

Производительность - это характеристика системы, которая определяется двумя взаимозависимыми величинами:

• Пропускная способность
• Время отклика

Необходимо помнить, что Вы делаете продукт для клиента, и его не интересуют тонкости. Ему важно только одно: насколько быстро система реагирует на его запросы.

Чем быстрее - тем лучше. Если Вы четыре месяца бъетесь над усовершенствованием алгоритма коллаборативной фильтрации, которая даст человеку ощущение того, что система стала рабоатать на “2…3%” быстрее, Вы делаете не то, что нужно! Вместо этого Вам стоило бы поработать, скажем, над клиентской оптимизацией, которая может ускорить время отклика для клиента в несколько раз.

И так, вопрос производительности - это вопрос того, насколько быстро Ваша система дает результат Вашему клиенту (посетителю, пользователю, покупателю - всем). Кто купит машину, которая умеет готовить кофе но ездит со скоростью 7 км/час? Не забывайте об этом.

Масштабирование

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

1. Вертикальное - увеличение мощностей оборудования (т.е. увеличение его “качества”). К примеру, это переход от 2 ядерных 3 Ггц процессоров к 8 ядерным 4 Ггц и т.п. Этот способ обычно не требует крупных изменений в системе, но является дорогостоящим. К тому же, существует определенный практический научный предел, дальше которого выйти не получится.
2. Горизонтальное - увеличение количества атомарных узлов системы (т.е. количественное увеличение ресурсов). Например, к 75 имеющимся серверам доставляются еще 25 точно таких же. Этот способ сравнительно дешевый, но медленный, т.к. требует достаточно обширных технологических изменений в приложении (причем постоянных).

И так, вопрос масштабирования - вопрос способности Вашей системы расти при увеличении нагрузки на нее.

Производительность это не масштабируемость

Формально, увеличивая производительность системы (например, повышая пропускную способность), мы добиваемся того, что система становится способна выдерживать более крупные нагрузки. А значит она способна расти. Это так, но с масштабированием это не имеет ничего общего. Масштрабирование - это свойство обеспечить большую нагрузоспособность при расширении ресурсов. Т.е. если Вы купили еще один сервер, поставили его, а система все так же “тупит” - она не масштабируема (на этот момент).

Принятие решений

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

Менеджменту необходимо иметь представление о том, в каком направлении двигаться. Как добиться такого понимания? Если вспомнить, что все исходит от денег и времени, становится проще:

• Оптимизация - обычно дело не столько денег сколько времени. Считайте, сколько Вы потратите на техническую команду и сколько клиентов сможете удовлетворить после этого
• Масштабирование - обычно дело денег, но не времени. Сколько Вам необходимо оборудования? Во сколько это обойдется? Опять же, каков будет результат?

После этого остается несложная математика. Что выгоднее - то и стоит делать. Не все так просто, как может показаться, т.к. необходимо учесть еще некоторые моменты:

• Выбор в ту или иную сторону является достаточно динамичным решением. Оно будет меняться в зависимости от компонент, хода времени, состоянии проекта и т.д. В связи с этим, не стройте длительных планов по росту. Находите наиболее критические точки и применяйте решения к ним.
• В определенный момент стоимость аппаратного расширения может перевалить за стоимость оптимизации (т.е. технической команды). Точно также, второе может быть дешевле первого на определенном этапе. Т.о. стоит принимать во внимание и ту ситуацию, с которой Вы можете столкнуться в будущем. Если Вы сейчас экономите 18 тыс. долларов, но это решение приведет Вас к расходам в 400 тыс. через год - видимо его нужно пересмотреть.
• Не думайте о проблемах оптимизации на этапе прототипа. Во первых, до окончания работы над прототипом, приходит понимание того, как стоит правильно разрабатывать производственную версию. Во вторых, если Вы ставите ставку на прототипное решение, как на базовое, то Ваше решение должно обладать только одним свойством - масштабируемостью. Что касается оптимизации, то это может показать только реальный опыт системы, т.к. Вы не сможете предугадать, что станет узким местом (со 100% вероятностью) в производительности.

Помните: время = деньги и деньги = время, но курс обмена отличается в зависимости от решения!

Интересно услышать опыт читателей об организации работ по масштабированию и оптимизации из собственной практики, сколько они отнимают проектного времени, насколько критичны, что из них приоритетнее?

Статьи по теме

• Масштабирование и производительность - еще раз о главном