Header Ads Widget

Ticker

6/recent/ticker-posts

Detener la inundación: cómo limitar la tasa de una API

 

Detener-la-inundación-cómo-limitar-una-API-nordic-apis

Si una API se implementa correctamente, la cantidad de usuarios que utilizan un servicio puede ser asombrosa. Millones de usuarios y dispositivos se conectan a Internet todos los días, utilizando API para realizar cálculos, convertir medios e incluso ayudar a curar el cáncer .

Sin embargo, el sueño del desarrollador de API también puede ser una pesadilla. El sueño es ser la API más popular, el mejor servicio posible, enfrentando enormes tasas de adopción. ¿La pesadilla? A medida que aumenta el número de usuarios y llamadas legítimos en un entorno de API, la mayoría de las veces, también lo hace el número de usuarios y llamadas ilegítimos.

¿Cómo puede un desarrollador detener esta avalancha de solicitudes de API? Poner límites de velocidad a las llamadas a la API es algo maravilloso de implementar y, cuando se hace correctamente, soluciona muchos de los problemas inherentes a las grandes bases de usuarios.

¿Qué es la limitación de tasa?

Una forma fácil de contextualizar los fundamentos de la arquitectura de API es comparar las API con la ciudad grande promedio. Una ciudad tiene ciertas funciones, y estas funciones requieren conexiones entre sí. Estas carreteras tienen limitaciones tanto en el contexto físico (es decir, el tamaño de la carretera) como en los contextos de seguridad (cuántos coches es seguro tener en la carretera al mismo tiempo).

De la misma forma, las conexiones API tienen estas mismas limitaciones en sus “carreteras”.

Al desarrollar una API, un desarrollador debe considerar las limitaciones físicas de un sistema, es decir, el ancho de banda, la cantidad de conexiones simultáneas que se pueden enrutar y la cantidad de datos que se pueden transferir entre el sistema y sus usuarios. Hay una cantidad limitada de datos que se pueden enviar a través de un sistema.

En el contexto de la seguridad, un desarrollador debe considerar las limitaciones de un sistema para evitar desbordes. Al igual que una carretera por encima del límite provoca congestión y accidentes, también lo hace una conexión lógica por encima del límite.

Desde un contexto empresarial, los proveedores de API pueden implementar la limitación de tasas como una técnica de negación de beneficios y costes. Al exigir que los usuarios de gran volumen paguen por planes premium , el aumento de los gastos operativos se puede negar y convertir en su lugar en un flujo de ingresos.

El proveedor de API tiene una solución milagrosa para estos problemas: limitación de velocidad . La limitación de velocidad es el proceso por el cual una API rechaza las solicitudes por una variedad de razones, que van desde tener demasiadas conexiones simultáneas hasta que el solicitante forma una solicitud deficiente para grandes cantidades de datos. Al implementar la limitación de velocidad, el desarrollador esencialmente instala un grifo que puede relajarse para permitir un mayor flujo o apretarse para reducir el flujo dentro del sistema.

Además, puede considerar la limitación de velocidad como una característica de seguridad en el ámbito más amplio de "CIA" (es decir, confidencialidad, integridad y disponibilidad ), uno de los conceptos fundamentales de la seguridad de la red. Al garantizar que no se produzcan desbordamientos de solicitudes y que los usuarios no puedan sobrecargar el sistema, la API se mantiene disponible para todos los usuarios, incluso si tiene una tasa de accesibilidad limitada.

Finalmente, uno de los mayores beneficios de la limitación de tasas para las empresas es el hecho de que la limitación requiere una implementación de análisis y métricas, una herramienta útil en el arsenal del proveedor de API .

Más sobre la arquitectura de API: ¿Qué formatos de datos debería admitir mi API?

3 tipos de limitación de la tasa de API

La limitación de la tasa es un arte, no una ciencia. Hay una variedad de formas de controlar las tarifas que no utilizan políticas generales y, en cambio, optan por límites dinámicos , lo que puede contribuir en gran medida a negar esta advertencia. Se utilizan tres tipos principales de límites de tarifas:

Los desarrolladores pueden establecer límites de tasa de usuario . Estos límites están vinculados directamente a la clave API del usuario. Después de una cierta cantidad de solicitudes, se niegan más solicitudes y, después de un período de tiempo establecido, este contador se reinicia, lo que permite nuevas solicitudes.

Los límites de velocidad del servidor también son una buena opción. Al establecer tarifas en servidores específicos, los desarrolladores pueden asegurarse de que los servidores de uso común, como los que se usan para iniciar sesión, puedan manejar muchas más solicitudes que los servidores especializados o poco usados, como los dispositivos de conversión de datos.

Finalmente, el desarrollador de API puede implementar límites de datos regionales , que limitan las llamadas por región. Esto es especialmente útil cuando se implementa la limitación basada en el comportamiento; por ejemplo, un desarrollador esperaría que la cantidad de solicitudes durante la medianoche en América del Norte sea menor que la tasa diurna de referencia, y cualquier comportamiento contrario a esto sin una buena razón sugeriría una actividad cuestionable. Limitando la región por un período de tiempo, esto se puede prevenir.

Consideraciones comerciales

Si bien se podría argumentar que la limitación de tarifas tiene un efecto moderador en el comercio entre usuarios y sistemas al reducir la cantidad de llamadas simultáneas, esto es bastante miope; contrariamente a lo que podría esperarse, la limitación de tarifas en realidad puede tener un gran impacto positivo en el comercio. .

En primer lugar, la limitación de velocidad establece la disponibilidad para una gama más amplia de usuarios al garantizar que los usuarios individuales o las regiones no dominen las conexiones simultáneas a un servidor. En efecto, esto asegura que más usuarios con necesidades más diversas puedan conectarse a una colección más amplia de servidores, aumentando la base de usuarios y los ingresos potenciales. A largo plazo, preservar la funcionalidad para una gama más amplia de usuarios tiene un efecto positivo neto, incluso cuando se equilibra con la reducción inmediata de las solicitudes potenciales.

La limitación de tarifas también tiene el potencial de crear un flujo adicional de ingresos al permitir un modelo de suscripción freemium que reduce o elimina estos límites. Un usuario gratuito que utiliza miles de conexiones es caro; sin embargo, si un socio desea realizar tantas conexiones, se le puede ofrecer un modelo de suscripción que ayude a reducir los costos de utilización de su API y proporcione tantas conexiones como desee.

Este enfoque de suscripción también se puede adoptar para los usuarios. Un gran ejemplo de este tipo de monetización es Pusher , que ofrece versiones gratuitas y de pago de su API.

Como solución alternativa a las implementaciones de hardware, algunos diseños de API Gateway también pueden proporcionar una medida de limitación de velocidad . Al vincular un sistema detrás de una puerta de enlace central y limitar la cantidad de conexiones, usuarios registrados simultáneamente y las solicitudes provenientes del servidor que lleva la puerta de enlace, se puede implementar un límite de facto .

Todo esto es un acto de equilibrio: limite demasiado las tarifas con un precio de entrada demasiado alto y los clientes se marcharán. No permita la limitación de la tasa, y la seguridad reducida y las fuentes de ingresos perdidas provocan un rendimiento deficiente con el tiempo. Equilibrar la experiencia de usuario y desarrollador de una API es quizás uno de los elementos más importantes del desarrollo de API. Encontrar el "punto óptimo" para cada API debe ser una parte personal e integral de la implementación de la limitación de velocidad.

Insights-CTA-Blog-Post-APi-Security

Implementación de limitación de velocidad

Hay muchas formas de implementar la limitación de velocidad. Una de las formas más comunes y fáciles de hacerlo es utilizar el almacenamiento en caché interno en el servidor. Tome este ejemplo en la caché PHP alternativa:

array apc_cache_info ([ string $cache_type = "" [, bool $limited = false ]] )

Esta función simplemente verifica si una IP está almacenada en caché en la cadena de memoria actual y, si lo está, verifica el límite bool contra conexiones concurrentes. Esto también se puede hacer usando nginx :

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

    ...

    server {

        ...

        location /search/ {
            limit_req zone=one burst=5;
        }

Este caso es mucho más variable que la solución de caché PHP alternativa anterior. Al establecer tanto el límite estático (1 solicitud por segundo) como el límite de ráfaga (5 en una ráfaga), las conexiones se pueden limitar dinámicamente para permitir un uso regular y un uso de alto volumen.

Como otra implementación, Redis utiliza patrones de límite de velocidad:

FUNCTION LIMIT_API_CALL(ip)
ts = CURRENT_UNIX_TIME()
keyname = ip+":"+ts
current = GET(keyname)
IF current != NULL AND current > 10 THEN
    ERROR "too many requests per second"
ELSE
    MULTI
        INCR(keyname,1)
        EXPIRE(keyname,10)
    EXEC
    PERFORM_API_CALL()
END

Simplemente, esto limita las interacciones con el servidor como en los otros ejemplos, pero también crea un contador dinámico para cada IP conectada, que expira cada 10 segundos y rastrea las tarifas de servicios públicos de las IP conectadas. Esta solución también genera un error cuando se alcanza el límite de velocidad.

Límites de tasa de ejemplo

Para ver cómo se ven realmente estos límites, echemos un vistazo a las tarifas publicadas de Twitter. A continuación se muestra una sección de su gráfico público oficial de límites de tarifas . Estas tarifas se separan entre el usuario autenticado y la aplicación autenticada, ya que los límites por usuario y por aplicación son ligeramente diferentes en diferentes circunstancias.

Toma una sola llamada - GET friendships/showEsta llamada devuelve información sobre dos usuarios arbitrarios . Esta es una llamada de uso común, ya que constituye la base de gran parte de Twitter. En consecuencia, los usuarios pueden realizar 180 solicitudes por cada 15 minutos y la aplicación está limitada a 15 solicitudes por cada 15 minutos.

Compare esto con una llamada como GET followers/listEsta llamada devuelve una colección con cursores de usuarios ordenados y está limitada a 15 tanto para el usuario como para la aplicación.

Con estas dos llamadas, podemos ver exactamente por qué la limitación de velocidad es tan poderosa. Considere la potencia informática detrás de la primera llamada. Dos usuarios arbitrarios tienen varias propiedades entre ellos, y estas propiedades se definen simplemente. Esta es una llamada simple con una devolución simple y se puede manejar fácilmente incluso en volumen.

La segunda llamada es mucho más complicada. La lista de usuarios para un usuario arbitrario no solo varía en tamaño, de minúscula a gigantesca, estos resultados deben ordenarse, formatearse, presentarse y mantenerse en la memoria para permitir la navegación.

Podemos ver por qué la limitación de tasa variable por uso es tan útil. La segunda llamada es claramente mucho más intensiva en recursos y, en consecuencia, está limitada para evitar que las llamadas de alto volumen de datos eclipsen las llamadas para relaciones simples.

A veces, la limitación no es de uso, sino de propósito. Mirar la limitación de velocidad de Twilio revela un límite bastante interesante:

Llamadas salientes
De forma predeterminada, cada cuenta de Twilio puede realizar 1 llamada saliente por segundo. Si su cuenta necesita más, comuníquese con nuestro equipo de ventas para conocer las opciones para límites más altos.

Llamadas entrantes y SMS
Twilio no limita la velocidad a la que un número puede recibir llamadas entrantes o mensajes SMS. Twilio realizará una solicitud HTTP a la URL de solicitud para cada llamada y mensaje recibido en su número de Twilio. Por lo tanto, asegúrese de que su servidor sea capaz de manejar la carga si espera una gran cantidad de tráfico entrante simultáneo.

Estos límites tienen sentido cuando se considera lo que hace Twilio: como controlador de voz y SMS, tener más de una llamada saliente no tiene sentido, ya que el usuario promedio solo utilizará esta comunicación de una manera. Sin embargo, con los contestadores automáticos integrados y los servicios de espera, este límite en las llamadas entrantes no tiene sentido, ya que el backend las manejará automáticamente.

Los desarrolladores de API deben considerar cuidadosamente los cálculos específicos que deben ser limitados. Como en el caso anterior, los datos pueden estar limitados por función, pero esto es solo una parte de la imagen. Limitar por nivel de acceso (es decir, usuario o aplicación), limitar por región e incluso limitar por el tipo de solicitud es posible bajo la limitación de velocidad variable.

Lea también: Puertas de enlace API a la arquitectura de microservicios directos

Conclusión

La limitación de tasas es una herramienta increíblemente poderosa para implementar, pero debe implementarse con una comprensión inteligente de su base de usuarios y sus requisitos.

La utilización de un sistema de limitación de tasa eficaz establece seguridad y disponibilidad para su API y, si se equilibra con las advertencias inherentes, puede generar una mayor seguridad, control dinámico e incluso nuevas fuentes de ingresos. Piense en ello como la autopista central hacia su ciudad API: ¿desea una autopista moderna de cinco carriles o un camino de tierra polvoriento? Uno conduce a un gran éxito y un crecimiento acelerado , y el otro a la mediocridad.

Publicar un comentario

0 Comentarios