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

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

Способы сохранения состояний приложения

Приложения работают с состоянием по-разному. Есть два способа — stateful и stateless.
Разберёмся, как масштабировать эти варианты и при этом сохранить работоспособность приложения.

Stateful

Stateful (с сохранением состояния) — подход, при котором система сохраняет информацию о предыдущих состояниях или взаимодействиях с клиентами. Применяется в ситуациях, когда экземпляров (их ещё называют инстансами) приложения несколько, но пользователю нужно всегда попадать на сервер, который владеет конкретным закреплённым за ним состоянием.
Например, у магазина в каждом экземпляре сервиса есть свой локальный кэш или отдельный экземпляр кэша, где сохраняется текущее состояние корзины. В фоне это состояние сохраняется в общую базу данных. Если пользователь попадёт на другой экземпляр, то корзины в кэше не будет, — придётся считать состояние, и потенциально данные могут отличаться от данных предыдущего экземпляра, если первый экземпляр не успел записать данные в базу.
Другой пример. Есть сервис обработки событий по заказу, «синхронизатор» задач между двумя системами. В нём обработка зависит от уже пришедших сообщений. Если масштабировать такой сервис горизонтально, то разные экземпляры могут соревноваться и «портить» состояние друг друга.
Всё это неудобно для пользователей и грозит потенциальными ошибками. Поэтому приложения с состояниями обычно масштабируют не напрямую, а через масштабирование базы данных, распределённое кэширование и распил на более независимые микросервисы, каждый из которых работает только над отдельными частями процесса независимо.

Stateless

Stateless (без сохранения состояния) — подход, при котором архитектура приложения не сохраняет информацию о предыдущих состояниях или сеансах где-то отдельно от остальных сервисов. Каждый запрос рассматривается как изолированное взаимодействие.
Хорошим примером stateless может служить, например, сервис поиска товаров в магазине или расчёта скидок по готовой корзине, причём корзина в этом случае просто поступает в качестве данных запроса.
Допустим, «Мегашоп» уже обзавёлся возможностью stateless: считает скидки независимо, предоставляет поиск, выделен отдельный сервис расчёта доставки. Мы не будем подробно останавливаться на том, как именно это реализовано: это слишком специфично для каждого отдельно взятого приложения и обычно требует доработок на уровне кода.
Масштабировать такой stateless-сервис горизонтально нам поможет балансировщик нагрузки.

Балансировщик нагрузки

Для обеспечения доступа пользователей к приложению можно было бы просто сделать много серверов — и на каждый добавить по экземпляру приложения. Готово, задача решена!
Но как тогда пользователь попадёт на каждый из экземпляров? Поддерживать 10–20 приложений не получится, заставлять пользователей ходить по конкретным IP-адресам — плохая идея, да и нагрузка в таком случае будет неравномерной.
Есть более простое решение проблемы — использовать балансировщик нагрузки.
💡 Сервис балансировки нагрузки — это инструмент для распределения запросов между серверами внутри кластера.
Он решает три основные задачи:
  • Обеспечивает непрерывную работу приложения Если один из серверов выйдет из строя, балансировщик автоматически направит трафик на другой сервер, что позволит избежать простоя в работе приложения.
  • Позволяет провести горизонтальное масштабирование Балансировщик позволяет равномерно распределять нагрузку между  несколькими экземплярами приложения. Добавление новых экземпляров приложения способствует увеличению общей производительности системы.
  • Повышает безопасность Некоторые балансировщики обладают функциями, которые помогают обеспечить безопасность системы. Они могут анализировать трафик, фильтровать запросы, а также направлять их через брандмауэры и другие защитные механизмы.

Виды балансировщиков нагрузки

Балансировщики делят на категории по функциям и устройству.

Балансировщики нагрузки по устройству

  • Программные
    Это сервисы, которые обычно работают на отдельном сервере. В зависимости от выбранного алгоритма они отправляют трафик на тот или иной экземпляр приложения. Основные алгоритмы мы рассмотрим чуть дальше в уроке.
    Это самые привычные для разработчиков балансировщики нагрузки. К ним, например, относится Nginx.
  • Виртуальные
Это решение работает на виртуальной машине (VM) или как экземпляр программного обеспечения в виртуализированной среде. Например, в центрах обработки данных, где используются технологии виртуализации, такие как VMware, Hyper-V или KVM. Там критически важно распределять входящий сетевой трафик между несколькими серверами: это позволяет эффективно использовать ресурсы, увеличить скорость отклика и предотвратить перегрузку сервера.
  • Аппаратные
    Это непосредственно физические устройства, работающие на 4 и 7 уровнях модели OSI. Они способны обрабатывать все виды трафика: HTTP, HTTPS, TCP и UDP. Такие балансировщики дороже, так как требуют отдельного физического устройства, его обслуживания и настройки. Обычно их применяют, когда простои недопустимы — например, нужно быстро перенаправить весь трафик в другой ЦОД, потому что текущий вышел из строя.

Балансировщики нагрузки по функциям

По функциям различают балансировщики на уровне 4 и 7 модели OSI. Расскажем про особенности их работы.
На 4, транспортном уровне, балансировщик быстрее обрабатывает запросы, поскольку не анализирует содержимое пакетов и имеет возможность работать с адресами серверов. Это применяют, например, для балансировки трафика между ЦОДами по нагрузке сети.
На 7, уровне приложений, балансировщик маршрутизирует контент с учётом содержимого и позволяет принимать сложные решения о маршрутизации, используя данные, специфические для конкретного приложения. Однако работает он при этом медленнее. Так работают кластеры (Redis, Mongo, микросервисы) — они применяют алгоритмы, чтобы выбрать экземпляр сервиса, который обработает запрос.
Подробнее про работу на разных уровнях OSI.
На уровне 4 балансировщик:
  • Использует протоколы TCP и UDP.
  • Распределяет трафик, опираясь на IP-адреса и номера портов.
  • Может применять базовое преобразование сетевых адресов (NAT), скрывая таким образом адреса серверов.
На уровне 7 балансировщик:
  • Работает на уровне приложений с протоколами HTTP и HTTPS.
    • Способен закрывать SSL-соединения.
Чтобы эффективно распределять нагрузку, на уровне приложений применяются следующие алгоритмы для прикладного уровня:
АлгоритмМеханизм отправки запросов к серверамКогда использовать
Round RobinВ порядке очередиВ базовом варианте, если нет каких-то специальных требований
IP Hash, или Sticky sessionsНа тот же сервер, откуда пришёл запрос, по хэшу IP-адреса пользователяЧаще всего в stateful-приложениях
Least ConnectionНа наименее загруженный серверМикросервисная архитектура
Least Response TimeНа сервер с наименьшим средним временем обработки ответаМикросервисная архитектура
Least BandwidthНа сервер с наименьшим трафикомМикросервисная архитектура

Round Robin. Эта стратегия последовательно распределяет запросы между доступными экземплярами.

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

Как настроить балансировщик нагрузки

Самый простой и популярный способ настроить балансировку — использовать Nginx.
Пример конфигурации:
BASH
   upstream application{
      least_conn; #алгоритм
      server 195.2.2.11; # ip-адреса серверов
      server 195.2.2.12;
      server 195.2.2.13;
   }

   server {
      listen 80; #порт nginx

      location / {
         # назначение трафика
          proxy_pass http://application;
      }
   }
Вариант отличный, но если серверов очень много? Вручную каждый не пропишешь. А если масштабирование идёт динамически или всё вообще работает через Kubernetes, то таким способом ничего не получится. Не хватает удобной единой точки подключения к API с автообнаружением всех доступных экземпляров приложения. Такую точку, к счастью, можно создать с помощью специальных паттернов: API Gateway и Service Discovery.

Паттерн API Gateway

Паттерн API Gateway — это единая точка входа для клиентских приложений. Он регламентирует коммуникации между клиентом и сервисами, убирая прямую привязку сервисов к клиентам, абстрагирует сервисы от клиентов.
Давайте разберём на простом примере. Представьте, что есть маленькая компания из 10 человек, в которой все свободно общаются друг с другом напрямую. Со временем компания растёт, человек в ней уже 300 и общаться всем напрямую долго, неудобно и неэффективно. Чтобы всё упростить, создаются направления, команды, выделяются руководители и прописываются регламенты. Паттерн API Gateway — как раз такой руководитель, который централизованно передаёт задачи и информацию своим сотрудникам и предоставляет результаты работы другим направлениям в компании. При этом каждый отдельный сотрудник его команды напрямую не привязан к «сервису», то есть руководству компании и другим отделам.
Внутрь API Gateway, этой единой точки входа, можно добавить разную функциональность: аутентификацию, походы в кэш, роутинг, логирование и другие нужные функции и инструменты.

Паттерн Service Discovery

Service Discovery — это паттерн, который облегчает коммуникацию между приложениями, даже если меняется количество их инстансов или сетевое расположение.
Основой этого принципа служит Service Registry — реестр, что-то вроде маленькой базы данных, в котором хранится метаинформация о микросервисах, их экземплярах и сетевом расположении.
Здесь на схеме в качестве микросервисов выступают Продукт, Корзина товаров, Цены и Заказы. Клиент через Gateway запрашивает у них IP-адреса, а через Service Registry — получает их.
Давайте разберём, как применить оба рассмотренных паттерна. Для этого будем использовать инструмент APISIX Gateway.

APISIX Gateway

APISIX Gateway, или API-шлюз, — это популярный инструмент с открытым исходным кодом и встроенным Consul. Consul — продукт от компании HashiCorp, который позволяет регистрировать и отменять регистрацию IT-сервисов, работающих в сети организации, а также хранить информацию о них. Кроме того, Consul представляет собой хранилище данных типа «ключ — значение».
Consul особенно полезен организациям, применяющим микросервисную архитектуру в своей инфраструктуре.
Покажем на схеме, как будет выглядеть настройка балансировки нагрузки с APISIX Gateway:
Сайт посылает запросы к API-шлюзу, который выступает в роли балансировщика и агрегатора. API отправляет запросы к конкретным инстансам, а сам список инстансов API-шлюз получает от хранилища Consul через модуль-адаптер сounsul_kv. Модуль-адаптер позволяет разделить сервис и клиентское приложение и реализовать две основные функции реестра обнаружения сервисов.
Реализация функций реестра обнаружения сервисов включает в себя два этапа:
  • Регистрация сервисов: сервисы «отмечаются» в реестре.
  • Обнаружение сервисов: клиентское приложение получает информацию о маршрутах сервисов через реестр.

Практика: настройка APISIX Gateway

Вам снова понадобится docker и docker-compose:
BASH
#Возьмём официальный репозиторий APISIX
git clone https://github.com/apache/apisix-docker.git

#Перейти в папку example, нам не особо интересен дашборд сейчас
cd example
Добавьте сервис в docker-compose.yml:
BASH
  consul:
    image: consul:1.15.1
    container_name: consul
    restart: always
    networks:
      - apisix
    ports:
      - '8500:8500'
    command: 'agent -server -bootstrap-expect=1 -node=agent-one -client 0.0.0.0 -log-level info -data-dir=/consul/data -enable-script-checks'
Полный файл docker-compose.yml:
BASH
version: "3"

services:
  #api gateway
  apisix:
    image: apache/apisix:3.9.0-debian
    restart: always
    volumes:
      - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro
    depends_on:
      - etcd
    ##network_mode: host
    ports:
      - "9180:9180/tcp"
      - "9080:9080/tcp"
      - "9091:9091/tcp"
      - "9443:9443/tcp"
      - "9092:9092/tcp"
    networks:
      apisix:

  #база данных типа Key-value для APISIX
  etcd:
    image: bitnami/etcd:3.5.11
    restart: always
    volumes:
      - etcd_data:/bitnami/etcd
    environment:
      ETCD_ENABLE_V2: "true"
      ALLOW_NONE_AUTHENTICATION: "yes"
      ETCD_ADVERTISE_CLIENT_URLS: "http://etcd:2379"
      ETCD_LISTEN_CLIENT_URLS: "http://0.0.0.0:2379"
    ports:
      - "2379:2379/tcp"
    networks:
      apisix:

  #сервис для проверки
  web1:
    image: nginx:1.19.0-alpine
    restart: always
    volumes:
      - ./upstream/web1.conf:/etc/nginx/nginx.conf
    ports:
      - "9081:80/tcp"
    environment:
      - NGINX_PORT=80
    networks:
      apisix:
  
  # сервис для проверки
  web2:
    image: nginx:1.19.0-alpine
    restart: always
    volumes:
      - ./upstream/web2.conf:/etc/nginx/nginx.conf
    ports:
      - "9082:80/tcp"
    environment:
      - NGINX_PORT=80
    networks:
      apisix:

  consul:
    image: consul:1.15.1
    container_name: consul
    restart: always
    networks:
      - apisix
    ports:
      - '8500:8500'
    command: 'agent -server -bootstrap-expect=1 -node=agent-one -client 0.0.0.0 -log-level info -data-dir=/consul/data -enable-script-checks'

networks:
  apisix:
    driver: bridge

volumes:
  etcd_data:
    driver: local
Добавьте в apisix_conf/config.yaml для apisix данные consul:
BASH

apisix:
  node_listen: 9080              # APISIX listening port
  enable_ipv6: false

  enable_control: true
  control:
    ip: "0.0.0.0"
    port: 9092

deployment:
  admin:
    allow_admin:               # https://nginx.org/en/docs/http/ngx_http_access_module.html#allow
      - 0.0.0.0/0              # We need to restrict ip access rules for security. 0.0.0.0/0 is for test.

    admin_key:
      - name: "admin"
        key: edd1c9f034335f136f87ad84b625c8f1
        role: admin                 # admin: manage all configuration data

      - name: "viewer"
        key: 4054f7cf07e344346cd3f287985e76a2
        role: viewer

  etcd:
    host:                           # it's possible to define multiple etcd hosts addresses of the same etcd cluster.
      - "http://etcd:2379"          # multiple etcd address
    prefix: "/apisix"               # apisix configurations prefix
    timeout: 30                     # 30 seconds

plugin_attr:
  prometheus:
    export_addr:
      ip: "0.0.0.0"
      port: 9091

**discovery:
  consul:
    servers:
      - "http://consul:8500"
    dump:
      path: "logs/consul.dump"
      expire: 2592000**
Запустите:
BASH
docker-compose up -d
Определите IP:
BASH
 docker inspect -f='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $( docker ps -aq) | grep web
В результате вы получите свои IP-адреса (например, 10.89.0.2 и 10.89.0.3).
Дальше нужно вызвать Consul для регистрации сервисов. В реальном приложении (например, на Spring Framework) в конфигурации просто указывается адрес Consul и каждый экземпляр регистрируется сам:
BASH
curl "http://127.0.0.1:8500/v1/agent/service/register" -X PUT \
  -H "Content-Type: application/json" \
  -d '{
    "ID": "svc-a1",
    "Name": "svc-a",
    "Tags": ["sample_web_svc", "v1"],
    "Address": "'10.89.0.2'",
    "Port": 80,
    "Weights": {
      "Passing": 10,
      "Warning": 1
    }
  }'

curl "http://127.0.0.1:8500/v1/agent/service/register" -X PUT \
  -H "Content-Type: application/json" \
  -d '{
    "ID": "svc-a2",
    "Name": "svc-a",
    "Tags": ["sample_web_svc", "v1"],
    "Address": "'10.89.0.3'",
    "Port": 80,
    "Weights": {
      "Passing": 10,
      "Warning": 1
    }
  }'
В результате консоль выдаст:
JSX
"truetrue%"
Проверьте регистрацию непосредственно в Consul:
BASH
curl "http://127.0.0.1:8500/v1/catalog/service/svc-a" | jq
Результат проверки регистрации.
JSON
[
  {
    "ID": "1f42ff08-f451-5733-a62c-990011b0adf5",
    "Node": "agent-one",
    "Address": "10.89.0.5",
    "Datacenter": "dc1",
    "TaggedAddresses": {
      "lan": "10.89.0.5",
      "lan_ipv4": "10.89.0.5",
      "wan": "10.89.0.5",
      "wan_ipv4": "10.89.0.5"
    },
    "NodeMeta": {
      "consul-network-segment": ""
    },
    "ServiceKind": "",
    "ServiceID": "svc-a1",
    "ServiceName": "svc-a",
    "ServiceTags": [
      "sample_web_svc",
      "v1"
    ],
    "ServiceAddress": "10.89.0.2",
    "ServiceTaggedAddresses": {
      "lan_ipv4": {
        "Address": "10.89.0.2",
        "Port": 80
      },
      "wan_ipv4": {
        "Address": "10.89.0.2",
        "Port": 80
      }
    },
    "ServiceWeights": {
      "Passing": 10,
      "Warning": 1
    },
    "ServiceMeta": {},
    "ServicePort": 80,
    "ServiceSocketPath": "",
    "ServiceEnableTagOverride": false,
    "ServiceProxy": {
      "Mode": "",
      "MeshGateway": {},
      "Expose": {}
    },
    "ServiceConnect": {},
    "CreateIndex": 51,
    "ModifyIndex": 51
  },
  {
    "ID": "1f42ff08-f451-5733-a62c-990011b0adf5",
    "Node": "agent-one",
    "Address": "10.89.0.5",
    "Datacenter": "dc1",
    "TaggedAddresses": {
      "lan": "10.89.0.5",
      "lan_ipv4": "10.89.0.5",
      "wan": "10.89.0.5",
      "wan_ipv4": "10.89.0.5"
    },
    "NodeMeta": {
      "consul-network-segment": ""
    },
    "ServiceKind": "",
    "ServiceID": "svc-a2",
    "ServiceName": "svc-a",
    "ServiceTags": [
      "sample_web_svc",
      "v1"
    ],
    "ServiceAddress": "10.89.0.3",
    "ServiceTaggedAddresses": {
      "lan_ipv4": {
        "Address": "10.89.0.3",
        "Port": 80
      },
      "wan_ipv4": {
        "Address": "10.89.0.3",
        "Port": 80
      }
    },
    "ServiceWeights": {
      "Passing": 10,
      "Warning": 1
    },
    "ServiceMeta": {},
    "ServicePort": 80,
    "ServiceSocketPath": "",
    "ServiceEnableTagOverride": false,
    "ServiceProxy": {
      "Mode": "",
      "MeshGateway": {},
      "Expose": {}
    },
    "ServiceConnect": {},
    "CreateIndex": 52,
    "ModifyIndex": 52
  }
]
Всё — Consul настроен, реестр сервисов работает, пора донастроить API Gateway.
Стандартный ключ для доступа к API APISIX — edd1c9f034335f136f87ad84b625c8f1.
Проверьте наличие consul на apisix:
BASH
curl http://127.0.0.1:9092/v1/discovery/consul/dump | jq
# результат
{
  "services": {
    "svc-a": [
      {
        "weight": 1,
        "port": 80,
        "host": "10.89.0.2"
      },
      {
        "weight": 1,
        "port": 80,
        "host": "10.89.0.3"
      }
    ]
  },
  "config": {
    "keepalive": true,
    "weight": 1,
    "dump": {
      "expire": 2592000,
      "load_on_init": true,
      "path": "logs/consul.dump"
    },
    "token": "",
    "timeout": {
      "connect": 2000,
      "wait": 60,
      "read": 2000
    },
    "fetch_interval": 3,
    "sort_type": "origin",
    "servers": [
      "http://consul:8500"
    ]
  }
}
Зарегистрируйте маршрут через consul:
BASH
curl "http://127.0.0.1:9180/apisix/admin/routes" -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
  "id": "consul-web-route",
  "uri": "/consul/web/*",
  "upstream": {
    "service_name": "svc-a",
    "discovery_type": "consul",
    "type": "roundrobin"
  }
}' | jq

#Получаем результат

{
  "key": "/apisix/routes/consul-web-route",
  "value": {
    "status": 1,
    "uri": "/consul/web/*",
    "update_time": 1719606436,
    "id": "consul-web-route",
    "priority": 0,
    "upstream": {
      "scheme": "http",
      "type": "roundrobin",
      "pass_host": "pass",
      "service_name": "svc-a",
      "hash_on": "vars",
      "discovery_type": "consul"
    },
    "create_time": 1719606436
  }
}
Можно ещё получить список маршрутов для того, чтобы удостовериться, что всё работает:
BASH
curl http://127.0.0.1:9180/apisix/admin/routes -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' | jq
Вывод будет примерно таким (хотя id могут отличаться):
BASH
{
  "list": [
    {
      "key": "/apisix/routes/consul-web-route",
      "value": {
        "upstream": {
          "scheme": "http",
          "discovery_type": "consul",
          "pass_host": "pass",
          "service_name": "svc-a",
          "hash_on": "vars",
          "type": "roundrobin"
        },
        "create_time": 1719606436,
        "update_time": 1719606436,
        "status": 1,
        "priority": 0,
        "uri": "/consul/web/*",
        "id": "consul-web-route"
      },
      "modifiedIndex": 16,
      "createdIndex": 16
    }
  ],
  "total": 1
}
Финальная проверка балансировки средствами APISIX и service discovery средствами Consul:
JSON
curl "http://127.0.0.1:9080/consul/web/"
В результате вы увидите либо:
JSX
hello web2
Либо спустя ещё пару вызовов:
JSX
hello web1
Теперь давайте закрепим теорию и практику тестами.

Задание 1

Какое из перечисленных утверждений верно относительно использования stateless-сервисов?

Задание 2

Какие задачи позволяет решать использование балансировщика нагрузки?

Задание 3

На рынок выпустили новое приложение по обработке коротких видео — до одной минуты. Для распределения нагрузки инженеры использовали алгоритм обработки запросов Round Robin. Приложение stateless, поэтому неважно, на какой сервер пришёл запрос пользователя.
Сервис стал популярен, и от пользователей участились жалобы на медленную работу приложения. Инженеры указали на высокую нагрузку на пару серверов из десятка и предложили заменить алгоритм распределения нагрузки. Какие могут подойти?

Задание 4

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

Итоги

  • У приложений есть два способа хранения состояний: stateful и stateless. Stateful требует хранить информацию о предыдущих состояниях или взаимодействиях с клиентами. При stateless-подходе архитектура приложения не сохраняет информацию о предыдущих состояниях или сеансах где-то отдельно от остальных сервисов. Каждый запрос рассматривается как изолированное взаимодействие.
  • Stateful обычно масштабируют не напрямую, а через масштабирование базы данных, распределённое кэширование и распил на более независимые микросервисы, каждый из которых работает только над отдельными частями процесса независимо.
  • Stateless можно масштабировать напрямую, так как там не требуется хранить информацию о предыдущих состояниях и можно направлять клиента на любой экземпляр приложения.
  • Масштабировать stateless-сервис горизонтально поможет балансировщик нагрузки — инструмент для распределения запросов между серверами внутри кластера.
  • Балансировщики нагрузки бывают разными. Они могут отличаться по устройству, на базе которого работают, и по функциям, которые выполняют.
  • В настройке балансировщика вам потребуется единая точка подключения к API с автообнаружением всех доступных экземпляров приложения. Такую точку можно создать с помощью специальных паттернов: API Gateway и Service Discovery. Вы освоили, как это делать, на практике.
Тема с основами репликации и шардирования подошла к концу. В следующей теме вас ждёт работа с геораспределёнными решениями.

Что почитать по теме

Подробная статья про балансировку и проксирование на Хабре
Статья про балансировщики в Yandex Cloud и их выбор в случае использования Облака
Статья на английском про подходы stateful и stateless и их реализацию