How to write scalable web applications

Как писать веб-приложения, которые не падают под нагрузкой — введение (1/5)

Введение

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

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

• как правильно масштабировать серверы
• как тестировать приложение под нагрузкой
• основы security operations
• как отслеживать атаки
• как реагировать на инциденты безопасности

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

В этой первой статье разберём базовые вещи: что такое масштабирование и какие у него виды.

1. Вертикальное и горизонтальное масштабирование

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

В какой-то момент сервер начинает:

• медленно отвечать
• падать под нагрузкой
• или просто перестаёт справляться

Тогда появляется вопрос: как увеличить мощность системы?

Существует два основных способа.

Вертикальное масштабирование

Вертикальное масштабирование — это увеличение мощности одного сервера.

Проще говоря: если сервер не справляется, мы делаем его сильнее.

Пример:

Было:
2 CPU
4 GB RAM

Стало:
8 CPU
32 GB RAM

Code

Было:

2 CPU

4 GB RAM



Стало:

8 CPU

32 GB RAM

или просто переносим приложение на более мощный сервер.

Простой пример

Представьте маленький интернет-магазин.

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

Через несколько месяцев приходит 5000 пользователей.

Сайт начинает тормозить.

Самое простое решение — добавить серверу больше RAM и CPU.

Это и есть вертикальное масштабирование.

Плюсы

• очень просто реализовать
• не требует сложной архитектуры
• быстрое решение проблемы

Минусы

• есть предел мощности
• мощные серверы стоят дорого
• Single Point of Failure — если сервер упадёт, упадёт всё приложение

Горизонтальное масштабирование

Горизонтальное масштабирование — это когда мы добавляем больше серверов, а не делаем один сервер мощнее.

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

Нагрузка распределяется между ними.

Простой пример

Представьте кафе.

Есть один бариста.

Если приходит 10 клиентов — он справляется.

Но если приходит 100 клиентов — очередь становится огромной.

Есть два варианта:

Вариант 1 — вертикальное масштабирование

Нанять одного супер-бариста, который работает быстрее.

Вариант 2 — горизонтальное масштабирование

Нанять 5 обычных бариста, и каждый обслуживает часть клиентов.

Очередь исчезает.

Как это выглядит в веб-приложении

Пример архитектуры:

Пользователи
│
│
Load Balancer
(балансировщик)
/ | \
/ | \
Server1 Server2 Server3

Code

        Пользователи

             │

             │

        Load Balancer

      (балансировщик)

        /    |    \

       /     |     \

   Server1 Server2 Server3

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

Пример:

User 1 → Server 1
User 2 → Server 2
User 3 → Server 3
User 4 → Server 1

Code

User 1 → Server 1

User 2 → Server 2

User 3 → Server 3

User 4 → Server 1

Если один сервер перегружен — балансировщик отправляет запросы на другой.

Плюсы и минусы горизонтального масштабирования

Плюсы

• высокая отказоустойчивость
• можно масштабировать почти бесконечно
• система переживает падение одного сервера

Пример:

Server2 crashed

Code

Server2 crashed

Система продолжит работать:

Server1
Server3

Code

Server1

Server3

Минусы

Главная проблема — синхронизация данных между серверами.

Если несколько серверов работают одновременно, нужно следить, чтобы у всех была одинаковая информация.

2. Основные методы горизонтального масштабирования

Самые распространённые:

• репликация
• шардирование
• партиционирование

В этой статье разберём репликацию.

3. Репликация серверов

Репликация — это когда у нас есть несколько серверов с одинаковыми данными.

Проще говоря — мы создаём копии сервера.

Пример:

Server1
Server2
Server3

Code

Server1

Server2

Server3

Все они содержат одинаковое приложение и одинаковые данные.

Балансировщик распределяет запросы между ними.

Пример из реальной жизни

Представьте популярный новостной сайт.

В день его читают миллионы пользователей.

Если использовать один сервер — он просто не выдержит.

Поэтому запускают несколько одинаковых серверов:

news-server-1
news-server-2
news-server-3
news-server-4

Code

news-server-1

news-server-2

news-server-3

news-server-4

Когда пользователь открывает сайт, балансировщик отправляет его на один из серверов.

Для пользователя всё выглядит как один сайт, хотя на самом деле работает несколько серверов одновременно.

Плюсы репликации

1. Снижение нагрузки
Запросы распределяются между серверами.

2. Отказоустойчивость
Если один сервер упадёт, остальные продолжат работать.

3. Простое масштабирование

Server5
Server6

Code

Server5

Server6

4. Географическое распределение

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

Это уменьшает latency.

Минусы репликации

1. Задержка синхронизации

Иногда данные между серверами обновляются не мгновенно.

Пример:

Пользователь изменил пароль →
другой сервер узнает об этом через несколько секунд

Code

Пользователь изменил пароль →

другой сервер узнает об этом через несколько секунд

2. Сложность архитектуры

Появляются дополнительные компоненты:

• балансировщик нагрузки
• системы мониторинга
• механизмы failover

3. Выбор нового главного сервера

Если основной сервер падает, система должна автоматически выбрать новый главный сервер.

Заключение

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

Есть два основных подхода.

Вертикальное масштабирование

• увеличиваем мощность одного сервера
• просто, но имеет предел

Горизонтальное масштабирование

• добавляем новые серверы
• сложнее, но позволяет строить большие и устойчивые системы

В следующей статье:

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