Что делать? Ставить обратный прокси, такой как Squid или Varnish, либо высококлассные балансировщики нагрузки

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

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

• разделение запросов на чтение и запись данных — вся запись происходит лишь на одном сервере баз данных
• запросы на чтение равномерно распределяются между несколькими серверами
• репликация синхронизирует данные на всех серверах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• питание и безопасность системы;
• пропускная способность каналов, сети раздачи контента, мощность провайдера;
• брэндмауэеры, проблемы балансировщиков;
• хранение данных;
• люди и процесс;
• технологические ограничения БД — масштабируемое хранилище по принципу «ключ-значение».

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

Поиск по сайту: