Вот вы зашли в интернет-магазин: посмотрели рекомендации, выбрали, что нужно, положили в корзину, оплатили. Для вас это как один связный фильм. А для магазина это серия запросов: «показать рекомендации», «добавить товар в корзину», «обработать оплату».
Если вы единственный пользователь магазина, то проблем не будет. Но если вдруг тысяча пользователей решит одновременно что-то купить, то сервер получит в тысячу раз больше запросов — и если на сервере что-то сделано криво, всё это хозяйство мёртво ляжет.
Такова судьба высоконагруженных проектов.
👉 Эта статья написана по мотивам разговора с Александром Трегером, руководителем службы разработки Практикума. Раньше Александр работал в сервисе знакомств Badoo. Можете представить, насколько там всё нагружено.
Высокая нагрузка — это сколько?
Высоконагруженные проекты (хайлоад) — это сайты, сервисы и приложения, которые обрабатывают большое количество запросов. Это интернет-магазины, мессенджеры, социальные сети, интернет-банки: сотни и тысячи пользователей одновременно покупают, общаются, загружают фотографии, переводят деньги. Сервера без остановки обрабатывают их действия.
«Большое количество запросов» — понятие относительное. Чёткой границы, после которой проект можно считать высоконагруженным, нет: это зависит от инфраструктуры. Если у вас небольшой сервер, то даже стабильные 10 запросов в секунду могут стать проблемой. Но если усреднить, то граница высокой нагрузки пролегает около сотни запросов в секунду.
Сотня запросов в секунду — это, скорее всего, тысячи и десятки тысяч пользователей онлайн: если каждый пользователь делает запрос раз в несколько секунд, как раз набегает несколько сотен запросов в секунду.
В чём проблема
Если запросов слишком много, сервер не успевает их обрабатывать и начинает сбоить. Чем это чревато:
- Страницы сайта начинают загружаться медленнее или вовсе не загружаются.
- Появляются случайные ошибки, пользователи не могут выполнять привычные операции.
- Соединение между сервером и пользователем в принципе теряется.
Пользователей это напрягает, а бизнес теряет деньги. В условиях жёсткой конкуренции это вообще может означать потерю людей: например, в 2007 году, когда только начинались соцсети, в студенческой среде было два сайта — «Вконтакте» и «Факультет». О втором вы ничего не слышали, потому что он дико тормозил в пиковое время, и все постепенно переползли во «Вконтакте».
А ещё в хайлоад-проектах меньше простор для эксперимента. В любой момент тысячи людей по всему миру могут использовать сервис, так что он должен быть стабильным. Приходится использовать проверенные технологии и уделять больше внимания тестированию.
Что нужно учитывать при разработке хайлоад-проекта
Много запросов — много данных. Пользователи загружают фотографии, заполняют анкеты, переписываются — это всё нужно хранить и обрабатывать. Значит, нужно много серверов, а если проект международный, то ещё и в разных странах, чтобы у пользователей из Америки всё работало так же быстро, как и у пользователей из Европы.
Объём данных может резко вырасти. Никогда не знаешь, что произойдёт завтра. Может, выстрелит реклама, придёт миллион новых пользователей и нагрузка станет в несколько раз выше. Сегодня у тебя создаётся гигабайт личных сообщений в день, а завтра — 10 гигабайт в день.
Поэтому недостаточно просто иметь много серверов, чтобы просто решать текущие задачи. Нужно спроектировать систему так, чтобы иметь возможность быстро её масштабировать.
Лучше всё дублировать. «1» — плохое число для высоконагруженного проекта. Любой сервер или сервис может неожиданно выйти из строя, поэтому приходится всё дублировать. Запасной сервер, реплика базы данных — без этого никуда.
Использовать кэширование. Ответ на запрос пользователя можно кэшировать — временно сохранять, например, в оперативной памяти. Когда от пользователя повторно придёт запрос, можно не обращаться к серверу, а взять информацию из кэша. Это помогает снижать нагрузку: если в кэше есть информация, которая нужна пользователю, не придётся отправлять идентичный запрос и снова ждать ответ. Страница загрузится быстрее.
Как выкатывать высоконагруженные проекты
Обновить личный блог или сайт компании с парой десятков визитов в день несложно. Даже если во время обновления сайт не будет доступен несколько минут, ничего страшного не произойдёт. С нагруженными проектами всё по-другому — они не могут позволить себе такую задержку. Чтобы пользователь во время использования такого сервиса не наткнулся на ошибку или неправильные данные, существуют разные релизные флоу — способы выпускать новые версии.
👉 Вот что Александр Трегер рассказывает про это:
«Для начала код нужно писать так, чтобы всегда была обратная совместимость. Это значит, что новая версия кода должна уметь работать с данными и в новом формате, и в старом, из предыдущей версии. Сложные миграции баз данных нужно делать по шагам и независимо от обновления кода. А такие действия, как, например, переименование полей, — практически табу.
Когда я работал в Badoo, мы использовали подход, в основе которого лежала штатная система автозагрузки файлов в PHP. Каждый файл в процессе подготовки к выкладке получает свою версию, и в каждом релизе есть карта с актуальными версиями. В продакшен-окружении на каждой машине есть symlink-файл — символическая ссылка — который указывает на нужную карту.
Когда все машины получили новый код, мы меняем одну ссылку на другую. Для всех новых запросов PHP начинает использовать новую карту и, соответственно, новые файлы.
Минус такого подхода в том, что файлы постоянно докладываются, занимая место на диске, и их нужно периодически чистить. А ещё старый код может ещё работать в памяти, порой по несколько дней. Инфраструктура может сильно поменяться, и логи засыпет ошибками.
В Практикуме мы используем внутреннее облако Яндекса для деплоя наших приложений. У нас всё в контейнерах, и каждое приложение запущено в несколько экземпляров. Процесс так настроен, что поднимается несколько новых экземпляров, балансировщик пускает на них трафик вместо части старых и гасит последние. Так постепенно всё обновляется. Это — rolling update.
Есть ещё вариант сначала полностью параллельно поднять нужное количество экземпляров и одномоментно на них переключиться. Такой метод деплоя называется blue-green. Чтобы его использовать, нужно всегда иметь в запасе в два раза больше свободных ресурсов, что не всегда возможно».
