Как определить необходимые ресурсы для вашего API Gateway?

Предыстория

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

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

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

• Выбор шлюза: Однопоточный QPS
• Типы бизнеса: Финансовые или нефинансовые услуги
• Требования к высокой доступности

Выбор шлюза

Узким местом для базовых компонентов API-шлюза обычно является процессор, а не сеть, диск или память. Однопоточная обработка процессора API-шлюза значительно указывает на его качество. Когда потребление ресурсов ниже для того же трафика API-запросов, это подразумевает меньшее количество машин, упрощение управления операциями и повышение доступности услуг.

Apache APISIX, открытый API-шлюз, консервативно оценивает, что однопоточный процессор может поддерживать как минимум 10 000 QPS при включении общих корпоративных плагинов для мониторинга, ограничения скорости и т.д. Предприятия могут проводить конкретные тесты для сбора результатов с учетом различий в включенных плагинах, аппаратной среде, сетевых условиях и характеристиках API-запросов.

Типы бизнеса

Большинство нефинансовых предприятий могут контролировать использование ресурсов процессора в API-шлюзе в диапазоне 20-30% в производственной среде, что является идеальным сценарием. Даже при увеличении вызовов услуг в 3-5 раз они могут эффективно справляться с этим. Отрасли, такие как новости, развлечения и интернет, могут использовать такую нагрузку.

Однако для отраслей, таких как банковское дело, финансы и ценные бумаги, где ценность API высока, поддержание ежедневной нагрузки процессора на уровне 5-10% является идеальным. Это позволяет API-шлюзу справляться с внезапными скачками трафика в 10-20 раз выше обычного.

Требования к высокой доступности

Для более высоких требований к доступности экземпляры прокси API-шлюза должны иметь как минимум 2 узла.

Практические примеры

Пользователь из финансового сектора

Пример предприятия:

• QPS для ежедневных вызовов API составляет 100 000
• Ежедневная нагрузка API-шлюза составляет 10%
• Выбор шлюза: Apache APISIX (Однопоточный QPS: 10 000)

На основе вышеуказанной информации необходимое количество процессоров составляет 100 000 / 10 000 / 10% = 100. Если используются машины с 4 ядрами процессора, необходимо 25 машин; с 8 ядрами процессора — 13 машин.

Пользователь из нефинансового сектора

Пример предприятия:

• QPS для ежедневных вызовов API составляет 100 000
• Ежедневная нагрузка API-шлюза составляет 25%
• Выбор шлюза: Apache APISIX (Однопоточный QPS: 10 000)

На основе вышеуказанной информации необходимое количество процессоров составляет 100 000 / 10 000 / 25% = 40. Если используются машины с 4 ядрами процессора, необходимо 10 машин; с 8 ядрами процессора — 5 машин.

Заключение

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