Как сделать сайт, который будет расти и не будет падать

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

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

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

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

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

Если нагрузка в системе распределяется на несколько серверов, необходимо учесть вероятность отказа одного и резкого роста нагрузки на другие серверы. Один из наших клиентов предоставляет услуги по доступу к WiFi для кафе и ресторанов. У них была система из двух облаков, между которыми распределялась нагрузка. В какой-то момент они подключили крупную сеть ресторанов, и один из серверов «упал». Нагрузка автоматически переключилась на второй сервер, но он не был на нее рассчитан и тоже рухнул. В итоге сервис не работал несколько часов. Чтобы предупредить такую ситуацию, надо тестировать разные сценарии. К тому же желательно, чтобы серверы были в разных дата-центрах.

Вторая большая проблема, с которой сталкивается растущий интернет-бизнес, это безопасность — в первую очередь DDoS-атаки конкурентов и хакеры. Как только ваш сайт станет более-менее заметен на своем рынке, ваши конкуренты начнут заказывать на вас DDoS, то есть специально загонять на ваш сайт много пустого трафика, чтобы положить серверы. Как правило, это небольшие атаки, которые обходятся заказчику в зависимости от рынка $ 300−1000. От них можно легко защититься рядом технических мероприятий. Наверное, 100-процентную защиту это вам не обеспечит, и с более серьезными атаками, которые заказывают за десятки тысяч долларов, справиться будет сложнее, но обеспечить себе 80-процентный уровень защиты вполне реально.

Мы работаем с сервисом ускорения и защиты сайтов Айри.рф. Они предоставляют услугу ускорения сайтов за счет географического распределения своих серверов по стране и алгоритма сжатия статического контента. Этой услугой пользуются владельцы коммерческих сайтов, которые регулярно сталкиваются с DDoS-атаками, и все эти атаки в итоге «прилетают» в нас, а мы уже с ними разбираемся.

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

Еще один показатель, которому стоит уделить внимание, это отказоустойчивость. Суть этого показателя в том, чтобы в случае отказа система не «лежала» дольше определенного количества времени. Например, если отказоустойчивость 99,977%, система не «лежит» больше десяти минут в месяц. Отказ может произойти по любой причине, это необязательно должно лежать в зоне вашей ответственности. Возможен отказ сети, отказ плохого «железа», отказ провайдера, если в дата-центре, например, вылетит сеть. От этого никто не застрахован. Вопрос в том, сколько времени займет переключение вашей системы на запасной сервер. Задача в том, чтобы это переключение проходило как можно быстрее.

Например, мы работали с онлайн-сервисом по доставке еды из ресторанов в Санкт-Петербурге. Мы ориентировались на ожидаемый трафик около 50 тыс. пользователей в день. Они хотели переключение в течение 15 минут, то есть в течение этого времени вместо упавшего сервера в облаке должен был запуститься новый. Сейчас мы реализуем решение по отказоустойчивости для проекта одного известного банка. Мы распределяем нагрузку для конфигурации master-slave на три облака: в двух из них — резервные серверы, а третье облако арбитражное, чтобы принимать решение в случае «падения» мастера.

Для стартапов и молодых компаний не менее важный момент — это масштабируемость сайта, то есть устойчивость инфраструктурного решения к плавному росту нагрузки. Раньше в процессе роста компания была вынуждена на каждом этапе расширять серверную базу и каждый раз настраивать взаимодействие с остальным «железом», чтобы все работало слаженно. С появлением мультисервисной архитектуры все стало заметно проще. Каждый сервис в рамках работы сайта можно при необходимости масштабировать отдельно: для этого надо просто дать той или иной подсистеме больше мощности. Конечно, это удобно делать с помощью облачных решений, а на своем «железе» полной масштабируемости добиться нереально.

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

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

Если у сервиса уже выросла большая база данных — 20−50 Гб, — код должен проходить через все стадии с этой реальной базой, а ее так просто не скопируешь. Для этих ситуаций есть решение по клонированию базы данных без копирования. Клон потом можно ронять и портить в тестовых средах, а на продуктивной среде это не отразится.

Настройка системных окружений, скриптов, клонирование баз данных и другие необходимые процедуры в рамках сопровождения разработки — это отдельный вид работ, объединенных понятием непрерывная интеграция (continuous integration).

Источник