Вопросы проектирования, касающиеся быстродействия и масштабируемости

Наиболее важное соображение, которое надо иметь в виду при разработке проекта веб-приложения, состоит в том, что веб-приложение, по большей части, является серверным приложением. Исторически сложилось, что серверное программное обеспечение уступает по сложности и трудностям программирования только программному обеспечению операционных систем. IIS and Windows^® предлагают множество передовых инструментов, которые делают разработку веб-приложений более быстрой и легкой, но вопросы и проблемы программирования сервера по-прежнему остаются.

Важные вопросы обеспечения масштабируемости приложения включают:

• Выбор технологии: Как и большинство платформ разработки, Windows предлагает множество возможностей для выполнения поставленной задачи. Правильный выбор технологии является первым, и часто наиболее важным, шагом в разработке масштабируемого веб-приложения. Например, если технология, используемая на стороне клиента, обеспечивает функциональность одинаковую или близкую той, которая обеспечивается сервером, целесообразно максимальное использование программного обеспечения клиента. Это сделает приложение более масштабируемым, поскольку в этом случае клиент реализует значительную часть обработки. Правильный выбор технологии также ведет к уменьшению двойного обмена между клиентом и сервером, что также улучшает быстродействие. Для получения дополнительных сведений см. Веб-приложения: Обзор и пакет Internet Client SDK.

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

  • Windows Script Components

  • Visual Basic

  • Java

  • C++

• Разработка алгоритмов и блок-схем: Даже правильная технология, примененная неправильно, даст плохие результаты.

• Многопотоковость: IIS и Windows обеспечивают многопотоковую среду. Для создания масштабируемых приложений необходимо выбрать подходящую модель потоков для компонентов.

• Конфликт ресурсов и временные задержки: Конфликт ресурсов и их «утечка» часто являются главными виновниками недостаточной масштабируемости приложений.

• Проверка в реальных условиях: Следует тщательно проверить веб-приложение в среде максимально близкой к той, в которой приложение будет развернуто.

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

Этот раздел содержит следующие сведения:

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

ТекстПрезентацияКомментарииПоделиться

Предисловие

Данный материал подготовлен по мотивам презентации, автором которой является John Engates, CTO Rackspace. Адаптацию текста и перевод выполнил Иван Блинков

Желательные свойства веб-приложений

Так или иначе практически все интернет-приложения стремятся к

• высокой доступности

• масштабируемости

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

• управляемости

• низкой стоимости эксплуатации

• богатству функциональных возможностей

• генерации прибыли.

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

Высокая доступность

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

Сайт работает, пользователи довольны, бизнес не теряет доходы в связи с недоступностью. (И система не обходится владельцам дороже, чем она приносит денег) Все довольны и счастливы.

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

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

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

Масштабиремость это не про:

• общую производительность

• используемую операционную систему

• используемые технологии

• аппаратную платформу

• оптимизированный код

• системы хранения данных.

Производительность и Масштабируемость — это СОВЕРШЕННО разные вещи!

Правило номер 1:

То, что не было спроектировано для масштабирования, масштабироваться не будет.

Правило номер 2:

Даже если система проектировалась с учётом масштабирования, проблемы всё равно будут

Типичный сценарий роста

Этап первый: Начало

Классическая двухуровневая архитектура

• один пакетный фильтр и балансировщик нагрузки;

• пара стоящих за ним веб-серверов;

• сервер баз данных;

• внутреннее хранилище данных.

Основное ее преимущество — простота, она позволяет вести разработку быстро. Отсутствие избыточности и низкие издержки — идеально для стартапов.

Этап второй: То же самое, только в большем количестве

Казалось бы бизнес идет вполне успешно, самое время предпринять меры для минимизации рисков

• добавить ещё балансировщиков и брендмауэров;

• добавление веб-серверов для увеличения производительности;

• увеличить размеры и оптимизировать БД;

• обеспечить избыточность данных;

• переместить БД переезжает на SAN или DAS;

• на уровне приложений оставить всё относительно простым.

Этап третий: Появляются проблемы

Веб-приложение наконец-то становится известным широкой публике (обычно не без помощиDigg и Slashdot).

Что делать?

Ставить обратный прокси, такой как Squid или Varnish, либо высококлассные балансировщики нагрузки. И ещё больше веб-серверов — управление контентом становится всё более проблемным. Более тонкая настройка компонентов системы может лишь немного сгладить последствия экспоненциального роста трафика, добавление дополнительных веб-серверов тоже позволяет лишь ненадолго отсрочить, казалось бы, неминуемое падение производительности системы.

Объяснение такой ситуации же, на практике, достаточно очевидно: единственная база данных перестает справляться. Обычно решением этой проблемы становится асинхронная репликация

• разделение запросов на чтение и запись данных — вся запись происходит лишь на одном сервере баз данных

• запросы на чтение равномерно распределяются между несколькими серверами

• репликация синхронизирует данные на всех серверах.

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

Этап четвертый: Проблемы нарастают

Что происходит и что делать?

Кэшировать с помощью memcached.

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

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

Этап пятый: Проблемы становятся критическими

Возникает паника — «Разве мы не сделали это раньше?». Нужно пересматривать бизнес-модель и переделывать практически все приложение. Неизменно возникает вопрос: «Почему же мы сразу не проектировали наше приложение с учетом масштабируемости?»

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

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

Этап шестой: Напряжение немного спадает

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

Этап седьмой: Познание неизвестного

Ситуация определенно наладилась, но предугадать, что ждет проект впереди становится все труднее. Где же могут возникнуть очередные узкие места системы?

• питание и безопасность системы;

• пропускная способность каналов, сети раздачи контента, мощность провайдера;

• брэндмауэеры, проблемы балансировщиков;

• хранение данных;

• люди и процесс;

• технологические ограничения БД — масштабируемое хранилище по принципу «ключ-значение».

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