Масштабирование клиента API путем распределения нагрузки

Стандартный клиент API WhatsApp Business работает в одном контейнере Docker. Если вы хотите разделить нагрузку так, чтобы сообщениями с WhatsApp обменивались несколько серверов, используйте конфигурацию с распределением нагрузки.

Обзор

В кластерах повышенной доступности за обмен сообщениями с серверами WhatsApp отвечает только один контейнер Docker. Если трафик сообщений превышает его пропускную способность, они дольше ждут в очереди и задержка их доставки увеличивается. Чтобы обеспечить масштабируемость клиента API WhatsApp Business, кластер разделяется на сегменты для распределения нагрузки по нескольким контейнерам Docker. На данный момент поддерживается только статическое сегментирование (с 1, 2, 4, 8, 16 или 32 сегментами). Кластер повышенной доступности представляет собой частный случай распределения нагрузки, когда число сегментов равно 1.

Кластер с распределением нагрузки, состоящий из 2 сегментов

В этом кластере за обмен сообщениями с сервером WhatsApp одновременно отвечают два узла Coreapp: CoreApp 1 и CoreApp 3. За каждое сообщение отвечает только один сегмент, с которым оно связано по ID получателя.

Сегментирование

Клиент API WhatsApp Business распределяет нагрузку с помощью сегментирования кластера. С учетом количества сегментов, которые вы настроили, в базе данных создается таблица сегментирования, на основе которой сообщения распределяются по сегментам по ID получателя или его имени пользователя в WhatsApp. Для этого используется следующая функция:

shard_id = hash(recipient-id) % shard-number

Каждому сегменту соответствует активный контейнер Docker (Coreapp). Узел Webapp перенаправляет запросы сообщений в нужные контейнеры Docker в зависимости от результата функции. Чтобы исключить отказ при сбое X компьютеров, их количество должно превышать число сегментов на величину X.

Как показывает приведенная выше схема кластера с распределением нагрузки, состоящего из 2 сегментов, сообщения направляются на узел CoreApp 1 или CoreApp 3 в зависимости от того, с каким сегментом они связаны. Узел CoreApp 2 является второстепенным: он работает, но без активного подключения к серверам WhatsApp. Предположим, что узел CoreApp 1 принимает сообщения, связанные с сегментом shard=0, а CoreApp 3 — с сегментом shard=1. Если узел CoreApp 1 откажет, это затронет только сообщения, связанные с сегментом shard=0. Узел CoreApp 3 по-прежнему будет исправно отправлять и принимать сообщения, относящиеся к сегменту shard=1. Как и в кластере повышенной доступности, основной узел Master 1 выявляет отказ CoreApp 1 и переключает трафик сегмента shard=0 на узел CoreApp 2. Время переключения составляет приблизительно 35 секунд.

Настройка распределения нагрузки

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

Запрос

POST /v1/account/shards
{
    "cc": "country-code",
    "phone_number": "phone-number",
    "shards": 1 | 2 | 4 | 8 | 16 | 32,
    "pin": "pin",
    "cert": "verified-name-cert-in-base64"
}

Параметры

Ответ

201 Created   : You successfully changed shard number 
403 Forbidden : You could hit this if server is temporarily unavailable, retry the request should fix it

Получение информации о сегментах

Запрос

GET /v1/account/shards

Ответ

{
  "account": {
      "shards": number-of-shards 
  }
}

Частота отправки сообщений

См. справку по сообщениям и производительности.

Сведения о развертывании в AWS

URL шаблонов:

• Enterprise: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent.yml?versionId=Tvb.Sa6uTwmvj1rSbbpKCmEKz2pyxcLG
• DB: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_db.yml?versionId=3.vthzENa7qUOuZrozcX9hDk9n8.kdTg
• Lambda: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_lambda.yml?versionId=gqIhZaXkX_NylKaPJMDBlQNk9.Pl_34b
• Network: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

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

Если включена повышенная доступность, по умолчанию шаблон создает следующее количество экземпляров для распределения нагрузки:

• рабочая среда — экземпляры EC2: 3, контейнер Webapp: 3, контейнер Coreapp: 3, контейнер Master: 3;
• промежуточная среда — экземпляры EC2: 2, контейнер Webapp: 2, контейнер Coreapp: 2, контейнер Master: 2.

Шаблон предусматривает автоматическое масштабирование экземпляров EC2 в соответствии с использованием памяти. Использование памяти увеличивается (или уменьшается) одновременно с количеством активных экземпляров контейнеров Coreapp. Т. е. чем больше создается экземпляров Coreapp, тем больше будет экземпляров EC2. Однако максимальное количество экземпляров EC2 ограничено:

Размер экземпляра RDS

Частота запросов API и количество активных экземпляров Coreapp определяют количество подключений к базе данных. Для 8 активных экземпляров Coreapp при частоте 100 сообщений в секунду требуется примерно 700 подключений к БД, если протокол SSL отключен, и 1200, если он включен. Для 32 активных экземпляров Coreapp при частоте 250 сообщений в секунду требуется порядка 1700 подключений к БД.

В текущей версии для 8 активных экземпляров Coreapp (шифрование подключений к базе данных отключено) используется db.m4.2xlarge, а для 32 активных экземпляров Coreapp (шифрование подключений к базе данных включено) — db.m4.4x.large. В таблице ниже указано поддерживаемое максимальное количество подключений для различных классов экземпляров RDS.

Конфигурация

• Количество активных экземпляров Coreapp, заданное в шаблоне, определяет только количество создаваемых экземпляров Coreapp. Чтобы активировать эти экземпляры, необходимо задать сегменты (как описано в разделе Настройка распределения нагрузки). Количество сегментов по умолчанию — 1.
• Количество экземпляров Coreapp должно быть не меньше количества сегментов, заданного в API.
• Чтобы увеличить количество сегментов:

  • Создайте стек с нужным количеством активных экземпляров Coreapp или измените существующий стек.
  • Активируйте экземпляры Coreapp и сегменты, задав сегменты.
  • Примечание. При задании сегментов все экземпляры контейнеров Coreapp автоматически останавливаются и перезапускаются. На это требуется от 45 секунд до 1 минуты.
• Чтобы уменьшить количество сегментов:

  • Уменьшите количество активных экземпляров Coreapp и сегментов, задав сегменты.
  • Когда все экземпляры Coreapp успешно перезапустятся, обновите стек так, чтобы в нем осталось такое же количество активных экземпляров Coreapp.
  • Примечание. При обновлении стека может завершиться работа активных экземпляров Coreapp, обслуживающих сегмент. Однако через короткое время будут назначены другие активные экземпляры Coreapp. Иными словами, может возникнуть дополнительная задержка (примерно на 35 секунд).