Что такое масштабирование

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

Зачастую эти два понятия тесно связаны, но представляют собой два абсолютно разных свойства системы:

  • Производительность — способность системы выполнять операцию за определенное допустимое время (другими словами, достаточно быстро)
  • Масштабируемость — способность системы справляться с увеличивающимися нагрузками (обычно — путем наращивания аппаратных ресурсов)

Почему эти важно?

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

Оба свойства тесно связаны друг с другом и оказывают влияние друг на друга. Как ни странно, именно это позволяет добиваться наиболее эффективных решений в терминах затрат при удачной комбинации внедряемых улучшений. Если Вашей системе нужно справиться с 10%-ым ростом нагрузки, наверняка имеет смысл подумать об оптимизации. Оптимизация во многих случаях может дать выигрыш в производительности в несколько раз, освобождая таким образом ресурсы для большей нагрузки (при сохранении аппаратной части без изменений).

Какой язык выбрать?

Это неважно! В большинстве своем проблемы производительности лежат вне кода системы. Проблемы таятся в архитектурных решениях, но очень редко в их реализации. Даже столкнувшись с неудачной реализацией, затраты на ее исправление не сравняться с затратами на изменение архитектурных решений.

По этой причине выбор языка (или платформы) разработки стоит рассматривать только со стороны ее потенциальной стоимости, сложности и скорости разработки. Как хорошо Вы знакомы с технологией, насколько быстро Вы сможете ее освоить, сколько Вам придется прочитать, какова рыночная стоимость разработки — это вопросы стоит задавать при выборе языка разработки.

Когда начать?

Начинать решать вопросы производительности и масштабирования нужно только (и только!) тогда, когда они возникают. Никогда не стоит заниматься решением несуществующих проблем во время разработки системы. Опыт говорит о том, что абсолютно все системы испытывающие потребность в росте в большинстве случаев сталкиваются с проблемами, о которых на стадии разработки и предположить не могли.

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

Когда остановиться?

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

Существуют очень много информации и подходов к оптимизации, и если придется с ними столкнуться то придется иметь дело с большинством из них. Некоторые из них малозатратны, некоторые — наоборот — трудоемкие для реализации и внедрения. Единственное, что нужно обеспечить — это готовность к таким изменением и понимание того, когда они понадобятся (если понадобятся вообще).

Общие правила эффективности

Опыт многих и многих можно свести к нескольким очень важным рекомендациям:

  • Профилируйте всегда и с самого начала
  • Тестируйте изменения на реальных данных (Вы не представляете, какие затычки можно будет обнаружить)
  • Собирайте статистику и следите за динамикой всех аппаратных и программных узлов
  • Не делайте предположений, и не решайте несуществующих проблем — это может стать самой большой ошибкой
  • Планируйте изменения, но не делайте их без надобности

Вопросы масштабирования

  1. Изолируйте компоненты системы (как программно, так и аппаратно)
  2. Кешируйте
  3. Распределяйте СУБД по разным физических серверам (федерация)
  4. Используйте репликацию
  5. Анализируйте все технологические решения на предмет масштабирования и избегайте тех, с которыми могут возникнуть проблемы

Вопросы оптимизации

  1. Разрабатывайте системы с учетом возможности внедрения кеширования данных (всех данных!)
  2. Используйте внешние ресурсы максимально редко (если есть возможность не инициировать соединение с СУБД на каждой странице, обязательно используйте ее)
  3. Не изобретайте велосипед — используйте средства платформы максимально обширно (а современные платформы имеют огромные арсеналы всевозможных инструментов)
  4. Используйте прекомпиляцию и кеширование кода (естественно в случаях, когда этого не предусматривает стандартная поставка платформы)
  5. Избегайте огромных циклов или высокой вложенности рекурсий

Подпишитесь на Хайлоад с помощью Google аккаунта
или закройте эту хрень