Лайфхак: Как сделать сайты, которые никогда не будут падать. Простым языком

Преамбула: Написать эту статью меня сподвигнул пост в фейсбуке, как внезапно упал сайт, как ни до кого нельзя было дозвониться и злые конкуренты сделал submit url и сайт выпал из ТОПа. Как вывод - надо еще больше мониторить и быстрее поднимать сайты. Предлагаю вашему вниманию иную точку зрения на проблему.

Ни для кого не секрет, что любые сайты периодически ломаются. Даже самые крупные и известные не могут похвастаться 100% uptime. Что уже говорить про обычные мелкие сайты, где технические неполадки бывают по несколько раз в год и портят жизнь вебмастерам.

Я постоянно вижу, как владельцы сайтов, seo агентств пытаются подключить очередной мониторинг, в надежде, что он поможет быстрее увидеть проблемы и улучшить ситуацию. Но что делать, если админ уехал на Канарские острова (ну или в деревню), а программист не отвечает на телефон в три часа ночи? Знакомая ситуация?

Что если я скажу вам, что можно пойти от обратного - ваши сайты будут работать 99.99% в год как у лидеров рынка? Не верите? Я попробую рассказать как это сделатьочень простым языком.

Основные понятия

Сперва очень небольшой упрощенный экскурс про то, как работают сайты. Среднестатистический сайт, например на wordpress, интернет магазин на opencart и т.д. состоит из двух-трех частей:

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

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

Причина, из-за которых сайты падают (не берем случаи, когда программист что-то вылил на “живой”(production) сервер и все упало):

  • Падает или отключается от сети какой-то сервер. Например, уборщица задела шнур, вылетел жесткий диск, трактор повредил кабель около ДЦ
  • Заканчиваются ресурсы (место на диске, оперативная память).
  • Ошибки в самом приложении. Бывает, что сайт начинает падать при небольшом увеличении нагрузки (например, вы сделали новый sitemap.xml, отправили его гуглу и на сайт ночью набежали боты), программист неправильно выбрал тип поля в базе, и ваш 32768 заказ уже не добавится в систему... и т. д..
  • Список подобных причин будет практически бесконечным. Любой более-менее опытный программист сможет часами вам рассказывать о таких косяках.

Ключ к надежности

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

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

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

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

На заре интернета это часто выглядело как www1.site.com, www2.site.com и вы попадали то на одну, то на другую версию.

Сейчас это уже делается проще - есть только www.site.com, который может внутри обращаться то к одному то к другому серверу.

Что такое load balancer сервер?

Это отдельный сервер, на котором запущено приложение, например nginx, которое распределяет трафик по определенному алгоритму. Например 50% на первый сервер и 50% трафика на второй сервер. Если первый сервер не отвечает (упал), то весь трафик переключается на второй сервер и наоборот.

Таким образом единой точкой отказа становится только load balancer сервер. Из практики load balancer - очень надежная система, которая сама по себе вряд ли упадет. Но и его мы можем продублировать, если введём два и более таких узлов.

База Данных

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

В чем ее суть: есть главная БД, например на сервере A, есть подчиненная БД - на сервере B. Когда что-то добавляется на сервере A (статья, товар, заказ и т.п.), сервер B практически в ту же секунду получает копию новых данных. Таким образом на двух серверах БД данные одинаковы и консистентны.

У нас очень старая сложная система

Часто бывает, что старые сайты очень сложные с множеством «костылей», их не так легко перенести или сделать копию.

Для такого случая можно предложить немного другое решение, которое называется failover.

  • делается копия сайта, вырезается все лишнее. Остается минимально рабочая версия с только необходимым функционалом, например, без возможности оставлять комментарии. БД не синхронизируется автоматически, а вручную раз в неделю, месяц.
  • если первый вариант невозможен, делаете HTML-копию сайта.

Load balancer настраивается таким образом, что если основной сервер не отвечает в течение минуты, то весь трафик перекидывается на failover сервер. Это дает время для технической команды решить проблемы на основном сервере.

Технари сказали, что не могут сделать такую систему

За время моей практики приходилось сталкиваться с весьма «велосипедными» решениями, но и там удавалось применить хотя бы решение failover.

Остается только порекомендовать обратиться к грамотным специалистам.

Сколько это все стоит?

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

В качестве load balancer подойдет практически любая VPS с объемом памяти от 1-2гб.
Так, например, на одном из наших проектов, на котором нагрузка 15-20 запросов в секунду, в качестве load balancer работает VPS из DigitalOcean 2гб за 10 долл в месяц.

Стоимость сервера, где работает сайт, зависит от требований вашего сайта. Тут уже действует простая математика. Что дороже: взять еще один сервер или простой сайта?

Выводы

Повысить надежность практически любого сайта можно, и это не так сложно, как кажется на первый взгляд. В Интернете много материалов по настройке load balancer серверов. Для системного администратора средней квалификации - это обычная несложная задача.

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

0
14 комментариев
Написать комментарий...
DxdV
Предлагаю вашему вниманию иную точку зрения на проблему.

И предлагаете совершенно типичное решение, которое используется везде.

Ответить
Развернуть ветку
Serge Bezborodov
Автор

"Как вывод - надо еще больше мониторить и быстрее поднимать сайты. " -> "Предлагаю вашему вниманию иную точку зрения на проблему."

Ответить
Развернуть ветку
DxdV
Написать эту статью меня сподвигнул пост в фейсбуке, как внезапно упал сайт, как ни до кого нельзя было дозвониться и злые конкуренты сделал submit url и сайт выпал из ТОПа.

Короче, статья слишком ни о чём. Чтобы увеличить аптайм - балансировать нагрузку, вот новости-то. Причём практически без нюансов балансировки, ну да nginx умеет балансировать, збс. И так далее.

Статья на уровне инструкции для бабушек что такое телефон.

Ответить
Развернуть ветку
DxdV
Load balancer настраивается таким образом, что если основной сервер не отвечает в течение минуты, то весь трафик перекидывается на failover сервер. Это дает время для технической команды решить проблемы на основном сервере.

Ну например. Вот так делают только не очень умные люди, потому что это не балансировка нагрузки, т.к. все запросы валятся на один и тот же сервер. Балансировка делается по принципу Roundrobin, когда, скажем, 10 запросов кидаются на 1 сервер, 10 на другой или устанавливается лимит одновременно обслуживаемых запросов и при превышении они отдаются другому серверу. Если один падает, то люди даже простоя в минуту не получат, т.к. сервер просто выпадет из ротации. Старость и сложность системы здесь роли не играют, потому что её просто поднимают на куче серверов и ставят балансировщик спереди.

Ответить
Развернуть ветку
Serge Bezborodov
Автор

для любого более менее опытного сисадмина, прогера, статья ни о чем - я согласен с Вами.

Цель статьи - объяснить на пальцах, для владельцев бизнеса, интернет маркетологов, без заумных терминов, как можно сделать сайты надежнее и все.

Ответить
Развернуть ветку
DxdV

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

Ответить
Развернуть ветку
Igor Rudnyk

Мне как не технарю - статья очень полезная. Потому что я банально могу дать ссылку своим девелоперам и спросить "А у нас так?"

Ответить
Развернуть ветку
DxdV

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

Я же говорю, статья очень своеобразная. Вроде о том, да неправильно.

Ответить
Развернуть ветку
Serge Bezborodov
Автор

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

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

в реальном мире есть очень большая прослойка сайтов, о боже на вордпрессе, которые трафа имеют 1к-5к визитов в день, и их дамп их базы в tar.gz вместится на дискете трехдюймовой - скажите, какие там в кластера делать с нодами?

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

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

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

Ответить
Развернуть ветку
DxdV
кластера, ноды, синхронизация - да да, все ок, верно говорите, но только это имеет смысл для крупных проектов, с миллионами юзеров в день, хотя бы в неделю.

По такой логике для сайтов с 1-5к юзеров подход с балансировщиком это уже слишком много. Тут надо определиться - если мы говорим о том как НАДО делать, то всё-таки надо быть точным в деталях. Если речь про реальность, то вашей статьёй даже никто не воспользуется, потому что не осилит или не посчитает нужным.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Serge Bezborodov
Автор

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

Ответить
Развернуть ветку
Олег Рябчиков

Amazon route 53

Ответить
Развернуть ветку
Ann Yaroshenko

Познавательная статья с понятными примерами и доступным объяснением, спасибо

Ответить
Развернуть ветку
11 комментариев
Раскрывать всегда