Как создать рабочую ИТ-инфраструктуру сайта и не потратить кучу денег зря

Павел Бондарович

технический директор в Creonit

Сегодня предприниматели мыслят масштабно и ставят перед собой высокие цели. На самом деле это здорово — все меньше иллюзий сделать «убийцу Амазона» на WordPress. Мы все чаще видим в брифах требование, чтобы сайт выдерживал огромные потоки трафика, «поэтому сразу нужно поднять целый кластер серверов, способных выдерживать колоссальную нагрузку». Ведь продукт по мнению клиента — просто песня, и пользователи выстроятся за ним в очередь, как за колбасой в 90-е или за «Яндекс.Станциями» в 2019-м. Но, к сожалению, так происходит не всегда и не сразу. Сайт запускается, но трафик растет не так быстро, как хотелось бы, а многочисленные купленные сервера пыляться в облаке, посыпая сверху пеплом головы предпринимателей.

Мы в Creonit советуем заказчикам мыслить завтрашним днем, но при этом не гулять «на все деньги» и вместо огромной дорогостоящей инфраструктуры разворачивать простую ИТ-систему, которую можно легко масштабировать в нужный момент.

Возьмем для примера обычный сайт. Он состоит из разных компонентов, основные из которых:

• код – приложение написанное, например, на PHP;
• база данных, где хранится вся информация;
• файловое хранилище, где хранятся, например, загруженные в админке картинки.

Как обычно происходит? Наступает момент релиза, покупается сервер и туда загружается сайт. На нем же устанавливается база данных, загружаемые файлы хранятся там же. Сайт работает, все отлично.

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

Прежде чем увеличивать ресурс нужно убедиться, что:

• программное обеспечение настроено оптимально (иногда не хватает пары строк в конфигурационном файле);
• на сервере установлены быстрые диски (SSD);
• налажена система кеширования данных на сайте.

Но если после всех этих мероприятий, сайт все равно еле шевелится, пора браться за развитие ИТ-инфраструктуры. И вот вам пошаговый план.

Шаг 1. Наращиваем мощности сервера

Самый простой и дешевый способ справиться с возросшей нагрузкой — установить процессор помощнее и/или докупить оперативную память. Это делается несколькими кликами в панели управления хостера. Код дорабатывать не нужно, а обслуживать сайт по-прежнему просто.

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

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

Цена вопроса: 10 000 – 20 000 рублей/месяц.

Шаг 2. Переносим базу данных на отдельный сервер

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

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

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

Цена вопроса: от 12 000 рублей\месяц.

Шаг 3. Поднимаем несколько копий базы данных

Трафик растет, сайт опять начал подтормаживать, а в системе мониторинга очевидно, что база данных «не вывозит». Тогда можно продолжить горизонтальное масштабирование, и если одна база не справляется с потоком запросов, то несколько баз должны.

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

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

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

Цена вопроса: от 4 000 рублей\месяц за один сервер.

Шаг 4. Балансируем нагрузку между серверами

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

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

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

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

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

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

Цена вопроса: от 12 500 рублей\месяц + оплата часов разработчиков.

Шаг 5. Бесконечное масштабирование

Это последний шаг, но по сути он бесконечный. У сайта помимо базы данных, приложения и хранилища, могут быть и другие компоненты: индексация для поиска, сервисы для кеширования, очередь сообщений. Когда трафик растет, их также можно переносить на другие серверы, чтобы распределять нагрузку и ускорять работу сайта. Само собой с увеличением количества серверов будут расти расходы, как на сами серверы, так и на технических специалистов.

Цена вопроса: бесценно.

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

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

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

Совсем недавно пользователь приложения Яндекс Go описал ситуацию, которая очень точно иллюстрирует ошибку неправильного выбора ресурсной базы. Только на примере реального сектора.

Парень заказал себе еды из ближайшего ресторана — 500 метров по прямой, но самому не дойти, некогда. Прождал минут 40: звонит курьер, спрашивает, есть ли свободные парковочные места во дворе. Наш герой выглянул в окно, и сказал, что есть. Еще через 20 минут пришел грустный мужчина с пакетом остывшей еды и сказал, что парковку он не нашел, что вообще-то у него огромная фура, но Яндекс предложил ему зарегистрироваться и брать заказы в приложении. Но никто не предупредил, что это заказы на 500 грамм продуктов, а топлива он сжег в 5 раз больше, чем заработал.

Мораль такова: лучше по чуть-чуть, но долго, чем много и один раз.