Compartir a través de

Procedimientos recomendados de arquitectura para Azure API Management

Azure API Management es una plataforma de administración y una puerta de enlace para las API en todos los entornos, incluidos híbridos y multinube. Como solución de plataforma como servicio (PaaS), API Management contribuye a gestionar el ciclo de vida de las API de sus cargas de trabajo.

En este artículo se supone que, como arquitecto, ha revisado el árbol de decisión de servicios de integración y ha elegido API Management como servicio de integración para la carga de trabajo. La guía de este artículo proporciona recomendaciones arquitectónicas que están alineadas con los principios de los pilares del marco Well-Architected.

Importante

Cómo usar esta guía

Cada sección tiene una lista de comprobación de diseño que presenta áreas arquitectónicas de preocupación junto con estrategias de diseño adaptadas al ámbito tecnológico.

También se incluyen recomendaciones para las funcionalidades tecnológicas que pueden ayudar a materializar esas estrategias. Las recomendaciones no representan una lista exhaustiva de todas las configuraciones disponibles para la gestión de API o los servidores de API back-end de su tarea. En su lugar, enumeran las recomendaciones clave asignadas a las perspectivas de diseño. Use las recomendaciones para crear la prueba de concepto o para optimizar los entornos existentes.

Arquitectura básica que muestra las recomendaciones clave: arquitectura de zona de aterrizaje de API Management.

Alcance de la tecnología

Esta revisión se centra en las decisiones relacionadas entre sí para el siguiente recurso de Azure:

  • Azure API Management

El ámbito de esta guía es el servicio API Management, principalmente el componente de puerta de enlace (plano de datos), que actúa como intermediario para las solicitudes de API de las aplicaciones cliente a las APIs de backend alojadas en varias plataformas o ubicaciones cruzadas. La arquitectura de la carga de trabajo debe tener en cuenta el plano de control de API Management y los componentes relacionados, como las aplicaciones cliente que acceden a la puerta de enlace y las API de back-end que procesan las solicitudes enrutadas. También integra servicios de Azure compatibles, como redes, supervisión, administración de identidades y otras funcionalidades.

Esta guía no cubre el Centro de API de Azure. Aborda los temas de nivel de API a medida que se relacionan con API Management en lugar de proporcionar una perspectiva bien diseñada sobre las consideraciones de diseño de API.

Nota:

No todas las recomendaciones se aplican a todos los niveles de servicio de API Management. Muchas recomendaciones de esta guía se centran en los niveles Estándar v2 y Premium clásicos de API Management, que son los niveles de producción recomendados para la mayoría de las cargas de trabajo empresariales.

Importante

El nivel Premium v2 con funcionalidades empresariales está en versión preliminar. Para determinar si el diseño debe depender de características de acceso anticipado o funcionalidades disponibles con carácter general, evalúe las escalas de tiempo de diseño e implementación en relación con la información disponible sobre las rutas de lanzamiento y migración de Premium v2.

Fiabilidad

El propósito del pilar Fiabilidad es proporcionar una funcionalidad continuada mediante la creación de suficiente resiliencia y la capacidad de recuperarse rápidamente de los fallos.

principios de diseño de confiabilidad proporcionar una estrategia de diseño de alto nivel aplicada a componentes individuales, flujos del sistema y al sistema en su conjunto.

Lista de comprobación de diseño

Inicie la estrategia de diseño en función de la lista de comprobación de revisión de diseño para confiabilidad. Determine su relevancia para los requisitos empresariales a la vez que tenga en cuenta los niveles y características de API Management y sus dependencias. Amplíe la estrategia para incluir más enfoques según sea necesario.

  • Evaluar las funcionalidades de la puerta de enlace para lograr confiabilidad y redundancia: Determine el nivel y las características de API Management que son necesarias para cumplir los requisitos de confiabilidad de la carga de trabajo para cada entorno.

    Evalúe las características de redundancia de puerta de enlace, incluidas las zonas de disponibilidad, varias unidades de puerta de enlace, varias regiones y áreas de trabajo. Todas estas características están disponibles en el nivel Premium. El nivel Desarrollador, que no incluye un acuerdo de nivel de servicio (SLA), no es adecuado para cargas de trabajo de producción. Tenga en cuenta los inconvenientes de adoptar características, como el almacenamiento en caché externo, que pueden introducir posibles puntos de error y cuellos de botella en el rendimiento.

  • Revise las funcionalidades de observabilidad: Tenga en cuenta las funcionalidades de observabilidad del servicio, incluidos los registros y métricas de Azure Monitor, Application Insights, el análisis integrado y los diagnósticos integrados. Use estas funcionalidades para supervisar las señales de confiabilidad de la carga de trabajo.

    Por ejemplo, considere la posibilidad de usar alertas de Azure Monitor para notificarle posibles problemas con la puerta de enlace de API Management o sus dependencias.

  • Revisar las estrategias de escalado: defina criterios para escalar horizontalmente la puerta de enlace agregando unidades para mantener la confiabilidad del servicio. Considere si se debe escalar en función de solicitudes, excepciones o ambas. Evalúe el impacto del escalado del componente de puerta de enlace en otros componentes de la carga de trabajo. Por ejemplo, su efecto en el espacio de direcciones de red y las funcionalidades de escalado de los back-end.

  • Aislar cargas de trabajo críticas: Determine si se necesita aislamiento de proceso para cumplir los requisitos de carga de trabajo, como la soberanía de datos o la optimización del rendimiento, en las API. Use puertas de enlace dedicadas para las API críticas y las puertas de enlace compartidas para las API menos críticas.

    Elija un enfoque de aislamiento, como usar una puerta de enlace de área de trabajo dedicada o una instancia independiente de API Management. Para varias instancias, mantenga los entornos sincronizados como parte de los procedimientos de implementación seguros.

  • Alineación del objetivo de nivel de servicio (SLO): tenga en cuenta el ámbito del Acuerdo de Nivel de Servicio de la puerta de enlace al establecer los SLO de la carga de trabajo. El servicio proporciona su propio Acuerdo de Nivel de Servicio, pero también debe tener en cuenta la confiabilidad prevista de otros componentes de carga de trabajo, como los back-end de la API.

  • Solucionar errores de back-end: prepárese para errores esperados e inesperados del back-end. Pruebe las experiencias de cliente en estos escenarios. Evalúe las directivas de puerta de enlace para mejorar la resistencia y la experiencia del cliente. Céntrese en cuotas, límites de velocidad, directivas de reintento, interruptores de back-end, equilibrio de carga y control de excepciones, tal como se documenta en las especificaciones de la API.

  • Definir estrategias de prueba: Use una solución de prueba como Azure Load Testing desde dentro de la red para reflejar las cargas de trabajo de producción reales. No confíe en el rendimiento publicado ni en otras estimaciones que podrían no aplicarse a la carga de trabajo.

  • Planear la recuperación ante desastres (DR): Revise las opciones para realizar copias de seguridad y restaurar la infraestructura y las API de la puerta de enlace. Las funcionalidades integradas de copia de seguridad y restauración pueden ser útiles en algunos escenarios. Pero también se pueden tener en cuenta las opciones administradas por el cliente, como las herramientas de APIOps y la infraestructura como código (IaC). Desarrolle estrategias para mantener otros datos del sistema, incluidas las suscripciones de usuario.

Recomendaciones

Estas recomendaciones de confiabilidad se pueden aplicar al propio servicio o al tráfico que fluye a través de las API y sus directivas. Los designadores (Servicio) o (API) indican si una recomendación tiene como destino el servicio o las API.

Recomendación Ventajas
(Servicio) Habilite la redundancia de zona en el nivel Premium y tenga un mínimo de tres unidades implementadas.

En esta configuración, en condiciones de funcionamiento normales, todas las unidades de escala de todas las zonas configuradas están activas y gestionan el tráfico del gateway.

En cualquier escenario activo-activo, planee el escalado horizontal en las zonas activas restantes para controlar el tráfico que las unidades procesaron originalmente en la zona con errores.		 La resistencia se garantiza durante una interrupción del centro de datos dentro de una región. Durante una pérdida completa del centro de datos, el tráfico de API seguirá fluyendo a través de las unidades restantes implementadas en otras zonas.
(Servicio) Habilite la escalabilidad horizontal automática en función de las demandas de tráfico.

En las implementaciones de varias regiones, las regiones secundarias no tienen funcionalidades de escalabilidad horizontal ni reducción horizontal automáticas. Debe implementar una función personalizada o una aplicación lógica que se active en respuesta a las alertas de métricas de Azure Monitor para administrar los ajustes de unidad en función de la demanda.		 Se garantiza que los recursos suficientes satisfagan la demanda de los clientes de API, lo que evita errores debido a una capacidad insuficiente.
(Servicio) Utilice una topología multirregional para mejorar la resiliencia ante una falla total en una región.

Este enfoque requiere que se coordine con otros componentes de la carga de trabajo y que comprenda sus características de conmutación por error planeadas. En cualquier escenario activo-activo, planee el escalado horizontal en el resto de regiones activas para controlar el tráfico que la región ahora inactiva procesó originalmente.

Asegúrese de que la topología de varias regiones se alinea con los requisitos de cumplimiento de los datos en tránsito o que residen en la memoria caché.		 Durante una interrupción regional completa, se proporciona resistencia sólida, lo que ayuda a garantizar el tráfico de API ininterrumpido a través de unidades implementadas en otras regiones.
(Servicio) Aísle las API no relacionadas con áreas de trabajo o instancias adicionales de API Management. El impacto de los errores causados por errores de configuración o interrupciones se minimiza al separar las API en diferentes instancias de proceso.
(API) Pruebe exhaustivamente las expresiones de directiva y la lógica y combínelas con técnicas de control de errores resistentes en las directivas de API Management. La experiencia del cliente se mejora al evitar nuevos orígenes de errores en la puerta de enlace y proporcionar una degradación correcta o un control de errores transitorios seguros.
(Servicio y API) Recopilación de métricas de confiabilidad.

Entre las métricas típicas de confiabilidad de la API se incluyen:

- Límites de velocidad y infracciones de cuotas.
- Tasa de errores basada en códigos de estado HTTP.
- Solicitar desviaciones de tasa desde la línea base.
- Comprobaciones de estado, incluido el estado de dependencia.		 Se identifican las desviaciones del comportamiento esperado y las líneas base anteriores. Estos datos se pueden usar para realizar un seguimiento de las causas principales, como el comportamiento cambiado del usuario, la interferencia de las operaciones rutinarias, los impactos inesperados de las nuevas características o los errores no planeados en la carga de trabajo.
(Servicio y API) Utiliza las capacidades de copia de seguridad y restauración incorporadas en API Management como parte de tu plan de estrategias de recuperación ante desastres. Complemente esas características con los artefactos de IaC y los procesos de APIOps para una solución sólida que pueda controlar varios escenarios, incluida la coordinación de recuperación con dependencias y back-end. La continuidad empresarial se garantiza al permitir la recuperación de la puerta de enlace de API y la restauración de las API definidas después de una pérdida completa del sistema.

Seguridad

El propósito del pilar de seguridad es proporcionar garantías de confidencialidad, integridad y disponibilidad a la carga de trabajo.

Los principios de diseño de seguridad proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos aplicando enfoques al diseño técnico para proteger la puerta de enlace de API Management.

Nota:

La lista de comprobación y las recomendaciones de esta sección se centran en proteger el recurso de puerta de enlace de API Management. La protección de las propias API solo se aborda brevemente. Para más información, consulte Mitigar los 10 principales riesgos de seguridad de API de OWASP en la gestión de API.

Lista de comprobación de diseño

Inicie la estrategia de diseño basándose en la lista de comprobación de revisión de diseño para la seguridad e identifique vulnerabilidades y controles para mejorar la posición de seguridad. Amplíe la estrategia para incluir más enfoques según sea necesario.

  • Establezca una línea base de seguridad: Revise la línea de base de seguridad de API Management e incorpore medidas aplicables en la línea base.

  • Proteja la canalización de implementación: Identifique las personas y los roles de control de acceso basado en roles necesarios para administrar la plataforma de servicio, las canalizaciones de integración e implementación continua (CI/CD) y las API específicas. Asegúrese de que solo las personas autorizadas tengan acceso para administrar el servicio y sus API.

  • Evaluar la confidencialidad de los datos: Si los datos confidenciales fluyen a través de solicitudes y respuestas de API en la puerta de enlace de API Management, asegúrese de su protección durante todo su ciclo de vida. Tenga en cuenta los distintos requisitos de protección de datos en distintas regiones. Evalúe las características del servicio, como varias regiones , para aislar datos específicos. Además, confirme si la estrategia de almacenamiento en caché se alinea con estos requisitos de aislamiento.

  • Desarrollo de estrategias de segmentación en puertas de enlace compartidas: Si la instancia de API Management hospeda las API para varios equipos de carga de trabajo, use áreas de trabajo para separar roles, redes y, posiblemente, puertas de enlace. Este enfoque garantiza que cada equipo tenga el acceso y el control adecuados sobre las API que administran al restringir el acceso a las API de otros equipos.

  • Tenga en cuenta los controles de red: Identifique los requisitos y opciones para aislar o filtrar el tráfico de puerta de enlace entrante y saliente mediante redes virtuales. Determine si el acceso a la puerta de enlace se puede restringir a través de Azure Private Link o si es necesario el acceso público a la puerta de enlace. Evalúe si la arquitectura debe incluir un firewall de aplicaciones web, como Azure Web Application Firewall en Azure Application Gateway o Azure Front Door, para lograr el aislamiento de red necesario y filtrar el tráfico de red.

  • Tenga en cuenta las funcionalidades de autenticación y autorización de API: Evalúe el uso de proveedores de identidades como El identificador de Entra de Microsoft, que incluye grupos integrados o el identificador externo de Microsoft Entra para pantallar las solicitudes de puerta de enlace y habilitar la autorización de OAuth para las API de back-end.

  • Cifrado del tráfico de red: Identifique las versiones y cifrados del protocolo de seguridad de la capa de transporte (TLS) más seguras que las cargas de trabajo pueden admitir. No requiera versiones de TLS no seguras. Use TLS 1.3 cuando sea compatible con los clientes.

  • Realice el modelado de amenazas en API Management y reduzca su área expuesta: Determine si determinados componentes de API Management, como la API de administración directa o el acceso público al portal para desarrolladores, se pueden deshabilitar, restringir o quitar.

  • Identifique los secretos que requieren las cargas de trabajo: La operación de puerta de enlace puede requerir certificados, claves de API u otros valores secretos. Revise los requisitos y funcionalidades de Azure Key Vault para almacenar secretos y certificados. O bien, revise las funcionalidades integradas de API Management, como los valores con nombre y los certificados administrados.

Recomendaciones

Estas recomendaciones de seguridad se pueden aplicar al propio servicio o al tráfico que fluye a través de las API y sus directivas. Los designadores (Servicio) o (API) indican si una recomendación tiene como destino el servicio o las API.

Recomendación Ventajas
(Servicio) Deshabilite la API de administración directa, que está en desuso. Use Azure Resource Manager como plano de control. El área expuesta del servicio se reduce quitando un punto de acceso del plano de control.
(Servicio) Limite la exposición de la puerta de enlace en función exclusivamente de dónde se conecten los clientes legítimos.

- Use la inyección de red virtual sin una dirección IP pública cuando todos los clientes puedan enrutar el tráfico a través de una red virtual. Use un grupo de seguridad de red (NSG) para restringir aún más el tráfico a solo las direcciones IP de origen de cliente esperadas.

- Use la integración de red virtual con Application Gateway o Azure Front Door si algún tráfico debe proceder de Internet. Configure el grupo de seguridad de red para que solo acepte el tráfico que procede del único punto de entrada.		 La confidencialidad del tráfico de red está protegida al restringir la exposición a los intervalos de direcciones IP de origen que se espera que contengan clientes legítimos. Estas restricciones bloquean el acceso desde orígenes que no deben iniciar la comunicación legítima del cliente. Limitar la exposición a orígenes de tráfico legítimos mejora la confidencialidad, la integridad y la disponibilidad del servicio.
(Servicio) Deshabilite el portal para desarrolladores si no está en uso. Si el portal está en uso, deshabilite la experiencia de registro, deshabilite el acceso anónimo y restrinja el acceso solo a ubicaciones de red de confianza. El área expuesta del servicio y la posibilidad de errores configuración o negligencia se reducen.
(Servicio) Establezca explícitamente las versiones, protocolos y cifrados de TLS más estrechos admitidos para sus clientes y sus sistemas de back end. Las versiones y los cifrados admitidos se reducen solo a las opciones que admiten los clientes y los servidores back-end. Este enfoque ayuda a garantizar que las conexiones priorizan las conexiones de mayor grado posibles para la confidencialidad.
(Servicio) Almacene certificados personalizados en Key Vault. La funcionalidad de administración de certificados se proporciona mediante Key Vault, que admite la rotación rutinaria y audita el acceso a los certificados.
(Servicio) Los back-ends solo deben aceptar el tráfico de las puertas de enlace de API y deben bloquear el resto del tráfico. Se evita que el tráfico malintencionado eluda la seguridad y otras preocupaciones transversales delegadas a la puerta de enlace.
(Servicio) En el caso de las instancias de API Management que hospedan las API para varios equipos o cargas de trabajo segmentadas, debe diseñar una estrategia sólida de aislamiento de control de acceso. Use áreas de trabajo o implemente un proceso riguroso de APIOps para lograr esta estrategia.

Los equipos solo deben tener acceso a las API de las que son propietarios. No deben tener acceso a otras API que se puedan hospedar en la misma instancia.		 Se reduce el movimiento lateral por parte de los atacantes de un conjunto de API comprometido hacia otras API no relacionadas.
(API) Almacene los secretos en Key Vault y expóngalos a directivas mediante valores con nombre. No use Key Vault para almacenar valores no secretos. Usa directamente las propiedades de valor nombrado para esos valores. Se recomienda la rotación de secretos a través de un único plano de administración en Key Vault, similar al enfoque que se usa para los certificados. Este proceso garantiza que API Management se actualice según corresponda. Los valores con nombre también garantizan una experiencia coherente para la configuración de directivas tanto para secretos como para no secretos. Todo el acceso secreto también se audita en Key Vault para proporcionar un historial de acceso. Almacenar solo secretos en Key Vault minimiza la dependencia de este y no convierte a Key Vault en un servicio de configuración de aplicaciones.
(API) Use diferentes identidades administradas asignadas por el usuario para distintas API mediante la directiva authentication-managed-identity. Cada API está habilitada para tener una identidad independiente, que admite objetivos de segmentación a través del acceso con privilegios mínimos para cada API. También proporciona una mejor auditabilidad en los sistemas back-end.
(API) Cuando sea posible, requiera que los clientes se autentiquen con flujos de OAuth 2.0 en lugar de usar solo claves previamente compartidas, incluidas las claves de suscripción o los certificados de cliente. Se ha mejorado la identificación de cliente con fines de auditoría, se elimina la rotación de claves y se reduce la carga de los clientes para proteger los secretos en comparación con el uso de claves previamente compartidas.
(API) Suprima los encabezados HTTP de las respuestas de API mediante la directiva set-header que podría exponer los detalles de implementación. El costo de los atacantes aumenta al retener la información de implementación.
(API) No use el seguimiento de API en producción. Se impide que los datos confidenciales se expongan en seguimientos de solicitudes.
(API) Use Defender para API. Se proporcionan información de seguridad de API, recomendaciones y detección de amenazas.
(API) Proteja los recursos back-end delegando comprobaciones clave de seguridad en la política de API, como validate-jwt, ip-filter, validate-headers, validate-content. La cantidad de tráfico nolegitio que llega a los servicios back-end se reduce mediante la realización de comprobaciones de seguridad en la puerta de enlace. Este enfoque de descarga ayuda a proteger la integridad y la disponibilidad de esos recursos.
(API) Aplique las prácticas del ciclo de vida de desarrollo de seguridad (SDL) a los cambios en las políticas de API de la misma manera que aplica los cambios propuestos en el código de aplicación en su carga de trabajo. Las directivas se ejecutan con una vista con privilegios elevados del tráfico de API. Se evita que una puerta de enlace de API comprometida eluda las protecciones de confidencialidad, integridad y disponibilidad del back-end.
(Servicio y API) Utilice identidades administradas para las dependencias de servicio y API. Las conexiones a Key Vault, Azure Event Hubs y otras dependencias, como certificados y valores con nombre, se establecen sin depender de secretos compartidos previamente.
(Servicio y API) Conéctese a dependencias como Key Vault, Event Hubs y back-end a través de conexiones de red privada siempre que sea posible. La confidencialidad del tráfico está protegida sin exponer el tráfico más allá de la red privada.
(Servicio y API) El tráfico de cliente destinado a las API expuestas a Internet debe pasar primero a través de un firewall de aplicaciones web, como el firewall de aplicaciones web, antes de que llegue a API Management. Además, proteja los puntos de conexión públicos mediante Azure DDoS Protection. La cantidad de tráfico nolegitio que llega a la puerta de enlace y los servicios back-end se reduce mediante la realización de comprobaciones de seguridad con un firewall de aplicaciones web. Reducir este tráfico ayuda a proteger la integridad y la disponibilidad de esos recursos.
(Servicio y API) Evalúe y habilite todos los controles de cumplimiento normativo de Azure Policy que sean relevantes para la carga de trabajo. La instancia de API Management se alinea con la posición deseada y permanece alineada a medida que la carga de trabajo evoluciona teniendo directivas de seguridad vigentes.

Optimización de costos

La optimización de costes se centra en detectar patrones de gasto, priorizar inversiones en áreas críticas y optimizar en otras para ajustarse al presupuesto de la organización al tiempo que se cumplen los requisitos empresariales.

Los Principios de Diseño de Optimización de Costos proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos y hacer compromisos según sea necesario en el diseño técnico relacionado con API Management y su entorno.

Lista de comprobación de diseño

  • Considere el modelo de costos de API Management: use la calculadora de precios de Azure con las ventajas y los criterios de la cuenta de su organización con respecto al Acuerdo de Nivel de Servicio y la escalabilidad para desarrollar estimaciones de costos precisas del uso de un nivel de servicio de API Management. Determine si es necesario un modelo de recargó y determine cómo calcularlo en función de métricas, etiquetas y tokens.

    El modelo de costo de servicio se ve principalmente influenciado por el nivel de servicio, el número de unidades y el número de puertas de enlace. Evalúe los costos adicionales asociados con el mantenimiento de una unidad de reserva o la implementación de una configuración de recuperación ante desastres activa-pasiva.

    Si implementa áreas de trabajo, evalúe los costos de usar puertas de enlace de áreas de trabajo independientes frente a compartidas para satisfacer los distintos requisitos de flujo de API de varios equipos de API o partes interesadas.

  • Estimación de los costos de escalado: Desarrolle criterios de escalado para mantener un uso elevado de los recursos de la puerta de enlace. Evalúe los costos de línea base en un entorno de preproducción y realice pruebas para calcular los costos de escalado horizontal en función del tráfico previsto de las cargas de trabajo.

    Diseñe una estrategia de mitigación para evitar el uso incorrecto de las puertas de enlace, lo que podría provocar un escalado costoso más allá del uso predeciado.

  • Evaluar las configuraciones y directivas del servicio: Las funcionalidades como el límite de velocidad y la simultaneidad de límite se pueden usar como técnicas de optimización de costos para administrar las cargas de solicitudes.

  • Optimización de la ubicación lógica: Evalúe si los servidores back-end son más rentables para la lógica de procesamiento o si la puerta de enlace debe controlar el uso de recursos. La puerta de enlace es un componente seguro para implementar problemas transversales, pero podría realizar funciones excesivas en determinados escenarios. Identifique las tareas de procesamiento de solicitudes intensivas de recursos que realiza la puerta de enlace y determine si mover esa lógica a servidores back-end puede reducir los costos.

Recomendaciones

Estas recomendaciones de optimización de costos se pueden aplicar al propio servicio o al tráfico que fluye a través de las API y sus directivas. Los designadores (Servicio) o (API) indican si una recomendación tiene como destino el servicio o las API.

Recomendación Ventajas
(Servicio) Use el nivel menos costoso que admita los requisitos de la carga de trabajo. Por ejemplo, elija un nivel Estándar en lugar de un nivel Premium si la carga de trabajo no se beneficiará de la funcionalidad agregada de una manera que justifica la rentabilidad de la inversión (ROI). Se evita la compra de funcionalidades no utilizadas o infrautilizadas.
(Servicio) Use niveles de no producción o infraestructura transitoria en entornos inferiores, como entornos de desarrollo, implementaciones de prueba de concepto y actividades de modelado de costos iniciales. Los costos de recursos se ahorran para entornos que pueden permanecer útiles sin reflejar completamente los requisitos exactos de configuración o tiempo de actividad de la producción.
(Servicio) Reduzca verticalmente cuando disminuya la demanda. Configure reglas de escalabilidad automática u otros procesos automatizados para reducir las unidades cuando la capacidad de puerta de enlace cae por debajo de los umbrales definidos. Los costos innecesarios se reducen ajustando la capacidad a la demanda.
(Servicio) Calcule cualquier ventaja de costo de un modelo federado para la gestión de API mediante el uso de espacios de trabajo para servir las API, proporcionando al mismo tiempo aislamiento para el equipo. Se reduce la superficie de implementación y administración. Este enfoque tiene como objetivo lograr economías de escala a partir del tiempo y las compras de recursos.
(Servicio) Desmantelar las áreas de trabajo cuando ya no están en uso. Se evita el gasto en recursos no utilizados.
(Servicio) Use la caché integrada si los datos almacenados en caché de la carga de trabajo se ajustan a las restricciones de la memoria caché integrada en el nivel. Se evitan los costos implicados en la compra y el mantenimiento de una caché externa compatible con Redis.
(Servicio) Bloquee el tráfico malintencionado antes de llegar a la puerta de enlace mediante controles de red, protección contra DDoS y firewalls de aplicaciones web. Los niveles específicos de API Management incurren en cargos en función del número de operaciones de solicitud HTTP que procesa la puerta de enlace. Como resultado, el tráfico no deseado, como las solicitudes generadas por bots, puede aumentar los costos.

Evalúe el costo del mecanismo de bloqueo frente al costo estimado de reducción de la operación HTTP para evaluar si este enfoque tiene un ROI.		 Se reducen los cargos que se producen debido a operaciones HTTP excesivas malintencionadas o molestas en la puerta de enlace.
(API) Optimice las expresiones de directiva y el procesamiento y el código para evitar un uso excesivo de recursos de proceso, como el procesador, las redes o la memoria. Se evita la implementación innecesaria de más unidades para proporcionar capacidad para implementaciones de directivas y código no optimizados.
(API) Evalúe el costo de la ubicación lógica entre la puerta de enlace, el back-end o el punto de entrada público, como Azure Front Door. El mismo procesamiento se puede producir a menudo en cualquiera de estas capas, cada uno con sus propias ventajas. Sin embargo, algunas capas podrían proporcionar ahorros de costos debido a la capacidad sin usar disponible en ese nivel. Por ejemplo, la lógica de almacenamiento en caché implementada originalmente en el back-end podría implementarse de forma más rentable en el nivel de puerta de enlace mediante la memoria caché integrada. Este enfoque reduce la sobrecarga adicional de red y proceso en los servicios back-end. La carga en recursos de alto costo se minimiza colocando funcionalidades en la capa más rentable. Este enfoque desplaza las cargas de trabajo a las capas que tienen capacidad de reserva o opciones de proceso de menor costo.

Excelencia operativa

La excelencia operativa se centra principalmente en los procedimientos para las prácticas de desarrollo , la observabilidad y la administración de versiones.

Los principios de diseño de Excelencia Operativa proporcionan una estrategia de diseño de alto nivel para alcanzar los objetivos relacionados con los requisitos operativos del flujo de trabajo.

Inicie la estrategia de diseño basada en la lista de comprobación de revisión de diseño para la excelencia operativa para definir procesos de observabilidad, pruebas e implementación relacionados con la Gestión de API.

Lista de comprobación de diseño

  • Revise los conocimientos y aptitudes clave necesarios para operar el servicio: Entre las áreas se incluyen el ciclo de vida de la API, los procesos de DevOps, las redes y la conectividad, la supervisión y la observabilidad, y el desarrollo de software. Este enfoque abarca la configuración de directivas, las pruebas unitarias y la creación de canalizaciones de CI/CD.

  • Considere las necesidades de documentación: Las organizaciones deben comprometerse a documentar los procesos para la configuración de nivel de servicio y nivel de API, las operaciones del ciclo de vida y los diferentes patrones de acceso para los equipos de API.

  • Evalúe las herramientas estándar para apoyar operaciones de servicio. Por ejemplo, adopte métodos de APIOps , como GitOps y CI/CD, para publicar API y administrar configuraciones de API. Use herramientas de IaC para los cambios de configuración de nivel de servicio. Diseñe artefactos reutilizables que puedan pasar sin problemas de entornos de desarrollo a producción. Considere la posibilidad de integrar un linter como Spectral, ya sea autoadministrado o como integrado en un servicio de Azure, como Azure API Center, en canalizaciones de aprobación de API.

  • Determinación de las métricas y registros operativos clave: Revise las métricas de producción. Estas métricas incluyen capacidad de puerta de enlace, uso de CPU, uso de memoria y el número de solicitudes. Revise los registros y las herramientas de observabilidad, como Azure Monitor y Application Insights. Determine las estrategias y herramientas necesarias para administrar eficazmente grandes volúmenes de datos de observación en entornos de producción. Determine las consultas que proporcionan información procesable tanto para el operador de puerta de enlace como para las partes interesadas que supervisan api hospedadas específicas.

  • Planee pruebas periódicas de cargas de trabajo de producción mediante pruebas de carga.

  • Identifique las tareas operativas más allá de los procesos de CI/CD o IaC que requieren automatización. Planee la automatización en áreas como administración de orígenes de directivas de API Management, directivas de Azure y configuraciones específicas del portal para desarrolladores.

Recomendaciones

Estas recomendaciones de excelencia operativa se pueden aplicar al propio servicio o al tráfico que fluye a través de las API y sus directivas. Los designadores (Servicio) o (API) indican si una recomendación tiene como destino el servicio o las API.

Recomendación Ventajas
(Servicio) Configure los registros de recursos de diagnóstico de Azure para API Management. Los registros generados por la plataforma están disponibles para consultar operaciones rutinarias, necesidades a petición o escenarios urgentes, como auditorías de seguridad.
(Servicio) Use Azure Event Grid para la automatización en función de los eventos significativos que genere la instancia de API Management, como APICreated. Las tareas de automatización o notificación se pueden crear en torno a los eventos clave del ciclo de vida que se producen en la instancia de API Management.
(Servicio) Evite usar una puerta de enlace autohospedada si una unidad de puerta de enlace hospedada por Microsoft funciona en su escenario. Las tareas de automatización o notificación se pueden crear en torno a los eventos clave del ciclo de vida que se producen en la instancia de API Management.
(Servicio) Aplique todas las directivas integradas de Azure Policy que le ayuden a controlar la instancia y restringirla para alinearse con los requisitos de carga de trabajo, incluidos los requisitos de seguridad. Por ejemplo, use directivas de denegación para evitar que las API se expongan a través de HTTP o para evitar la habilitación de la API REST de administración directa. Use directivas de auditoría si las directivas de denegación no están disponibles, o cree directivas de denegación personalizadas si es importante para tu carga de trabajo. La instancia de API Management se alinea con el diseño y permanece alineada a medida que evoluciona la carga de trabajo.
(Servicio) Familiarícese con la funcionalidad Diagnosticar y resolver problemas en Azure Portal.

Usa el panel de estado de la red en el portal para resolver problemas de conectividad de red.		 Los usuarios de ingeniería de confiabilidad de sitios pueden identificar y solucionar problemas de rendimiento de puerta de enlace, disponibilidad del servicio y conectividad de red en todos los entornos.
(API) Use Event Hubs para manejar los flujos de registros o eventos de las invocaciones de API que requieren reacciones casi en tiempo real u operaciones en ventanas de tiempo reducido. Se proporciona disponibilidad casi en tiempo real de entradas de registro. Se evita el retraso en la ingesta de datos de registro que ocurre al registrar en Azure Monitor dentro de las API.
(API) Apoye el uso del seguimiento de API en el desarrollo para ayudar a los desarrolladores a comprender su implementación de políticas. La productividad del desarrollador está optimizada al proporcionar información sobre la implementación de directivas dentro de una API. Sin esta funcionalidad, los desarrolladores deben introducir hackeos en la implementación de directivas para obtener información.
(API) Defina siempre los backends mediante la funcionalidad backends de API Management. Haga referencia a estos servidores back-end por su identificador en la directiva mediante set-backend-service. Los servidores back-end con equilibrio de carga deben definirse como un grupo de back-end. Los cambios de conexión de back-end se aplican a todas las API que usan el back-end sin necesidad de actualizaciones en el código de directiva individual. Se reduce el riesgo de configuraciones incorrectas o de pasar por alto los cambios en las políticas de APIs, y los escenarios en los que varias APIs comparten el mismo back-end se gestionan adecuadamente a través de esta capa de abstracción de configuración.
(API) Diseñe el enfoque de control de versiones de las API para alinearse con las funcionalidades de control de versiones y revisión de API Management. Tenga en cuenta este enfoque en las operaciones de implementación de API. Una estrategia de control de versiones de API admitida de forma predeterminada por API Management se usa para aprovechar las funcionalidades integradas en lugar de crear soluciones personalizadas.
(Servicio y API) Defina un proceso operativo coherente y sostenible para agregar, modificar y eliminar API. Determine si administrar esta experiencia manualmente a través del portal o implementarla a través de un proceso de APIOps. Prefiere usar un enfoque basado en IaC en lugar de un enfoque basado en el portal.

La representación de API Management en la API de Resource Manager consta de muchos recursos secundarios, por lo que es importante adoptar un enfoque en capas para la administración basada en IaC de esta colección de recursos.		 Las especificaciones de API y sus implementaciones de puerta de enlace se integran en los procesos de control de cambios de la carga de trabajo. Este enfoque impide controlar los cambios en las API de back-end de forma diferente de cómo se exponen a los clientes de API a través de la puerta de enlace.

Eficiencia del rendimiento

La eficiencia del rendimiento consiste en mantener la experiencia del usuario incluso cuando hay un aumento de la carga mediante la administración de la capacidad. La estrategia incluye el escalado de recursos, la identificación y la optimización de posibles cuellos de botella y la optimización del rendimiento máximo.

Los principios de diseño eficiencia del rendimiento proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos de capacidad con respecto al uso esperado.

Comience su estrategia de diseño basándose en la lista de comprobación de revisión de diseño para el rendimiento eficiente para definir una línea de base que se fundamenta en indicadores clave de rendimiento para la gestión de APIs.

Lista de comprobación de diseño

  • Defina los objetivos de rendimiento: Las métricas clave para evaluar el rendimiento de la puerta de enlace de API Management incluyen métricas de capacidad, como porcentajes de uso de CPU y memoria para la infraestructura de puerta de enlace, la duración de la solicitud y el rendimiento de las solicitudes. En las implementaciones de varias regiones, defina los objetivos de rendimiento para cada región. El cliente debe definir los umbrales de escalado adecuados en función de los patrones de tráfico, las cargas de trabajo de API y los tiempos de escalado.

  • Recopilación de datos de rendimiento: Revise las funcionalidades de análisis integrados, métricas de Azure Monitor, registros de Azure Monitor, Application Insights y Event Hubs para recopilar y analizar el rendimiento en distintos niveles de granularidad.

  • Revise cómo identificar problemas de rendimiento en vivo: Los indicadores de problemas de rendimiento activo incluyen la disponibilidad del servicio de Azure, los errores de respuesta HTTP y los errores generados en la sección Diagnosticar y resolver problemas en el portal. Solucionar problemas de rendimiento y disponibilidad mediante el uso de Application Insights, consultas de Kusto y recomendaciones de Diagnósticos de API Management en el portal de Azure.

  • Rendimiento de la prueba: Pruebe el rendimiento en condiciones de producción mediante pruebas de carga.

  • Evalúe los servicios adyacentes que podrían mejorar el rendimiento: Las directivas de almacenamiento en caché o una caché externa pueden mejorar el rendimiento de operaciones de API específicas. Azure Front Door y Application Gateway son opciones comunes para la descarga de TLS.

  • Revise los límites y restricciones documentados:API Management tiene límites y restricciones. Revise las restricciones documentadas y compárelas con los requisitos de la carga de trabajo para ver si necesita diseñar una solución que evite estas restricciones.

Recomendaciones

Estas recomendaciones de eficiencia del rendimiento se pueden aplicar al propio servicio o al tráfico que fluye a través de las API y sus directivas. Los designadores (Servicio) o (API) indican si una recomendación tiene como destino el servicio o las API.

Recomendación Ventajas
(Servicio) Escale dinámicamente para que coincida con la demanda. Configure reglas de escalabilidad automática u otros procesos automatizados para ajustar las unidades de puerta de enlace para que coincidan con una capacidad de uso objetivo. La elasticidad se logra en función del uso simultáneo, lo que evita el agotamiento de los recursos de las unidades implementadas actualmente o la asignación excesiva de capacidad.
(API) Minimice las tareas de procesamiento costosas, como generar grandes tamaños de carga almacenados en búfer, mediante la directiva de validación de contenido en cuerpos de solicitud grandes o manteniendo un gran número de webSockets activos. La carga en las unidades de escalado se reduce, lo que les permite procesar más solicitudes de manera simultánea antes de tener que escalar horizontalmente.
(Servicio y API) Recopilar métricas de rendimiento.

Entre las métricas comunes de rendimiento de la API se incluyen las siguientes:

- Solicitar tiempo de procesamiento para la propia puerta de enlace y para la operación completa.
- Métricas de uso de recursos en unidades de puerta de enlace.
- Medidas de rendimiento como solicitudes por segundo o megabits por segundo.
- Frecuencia de aciertos de caché		 El rendimiento real se mide con respecto a los objetivos de la carga de trabajo.
(Servicio y API) Defina un porcentaje de muestreo para Application Insights que proporcione visibilidad suficiente sin afectar al rendimiento. Las necesidades de datos de observabilidad se satisfacen sin afectar al rendimiento general.
(Servicio y API) Evalúe el impacto en el rendimiento de la ubicación lógica entre la puerta de enlace, el back-end o el punto de entrada público, como Azure Front Door. Las mismas tareas de procesamiento a menudo pueden producirse en cualquiera de estas capas, con ventajas de rendimiento y limitaciones en las oportunidades de optimización para cada una. Si una tarea, como una directiva de API Management API, presenta demasiada latencia, considere si esa tarea puede ejecutarse en otro lugar de una manera más optimizada. Las tareas que agregan latencia a las API se ejecutan en el proceso optimizado para cumplir los requisitos de carga de trabajo.

Directivas de Azure

Azure proporciona un amplio conjunto de directivas integradas relacionadas con API Management y sus dependencias. Algunas de las recomendaciones anteriores se pueden auditar mediante Azure Policy. Por ejemplo, puede comprobar si:

  • La puerta de enlace está configurada para la redundancia de zona.
  • Se dispone de los controles de red adecuados para la puerta de enlace de API Management, como la implementación en una red virtual.
  • Los puntos de conexión para la configuración del servicio no son accesibles públicamente.
  • La API rest de administración directa está deshabilitada.

Para una gobernanza completa, revise las definiciones integradas de Azure Policy y otras directivas que podrían afectar a la seguridad de la puerta de enlace de API Management.

Recomendaciones de Azure Advisor

Azure Advisor es un consultor en la nube personalizado que le ayuda a seguir los procedimientos recomendados para optimizar las implementaciones de Azure.

Para más información, consulte Azure Advisor.

Advisor también podría exponer otras recomendaciones en el sistema de producción, como:

  • Error al requerir tamaños de clave JWT largos en la directiva validate-jwt.
  • Ha usado una versión heredada de la API de Resource Manager para implementar el recurso.
  • Los tokens de clave de API están cerca de su fecha de expiración.
  • Error en una operación de rotación de certificados.

Concesiones

Es posible que tenga que hacer concesiones en el diseño si usa los enfoques de las listas de comprobación de elementos fundamentales. Estos son algunos ejemplos de ventajas e inconvenientes.

Alta disponibilidad a través de redundancia y aislamiento

  • Alta disponibilidad. Agregar redundancia a una arquitectura afecta a los costos. Por ejemplo, el aprovisionamiento de al menos tres unidades para evitar interrupciones zonales podría no ser viable financieramente para la carga de trabajo. Los costos aumentan aún más con una arquitectura de varias regiones, que requiere al menos seis unidades o tres unidades por región. Una configuración multirregional también agrega costos operativos relacionados con la coordinación de implementaciones seguras, el escalado confiable y la coordinación de conmutación por error con los servidores back-end.

  • Aislamiento. Aislar las cargas de trabajo entre áreas de trabajo o instancias de API Management agrega complejidad operativa, ya que incluye la administración de un sistema multiinquilino que tiene aislamiento de proceso.

Escalado para satisfacer la demanda

  • Al escalar horizontalmente de manera automática para satisfacer la demanda de clientes con buen comportamiento, esos costos ya se tienen en cuenta en los modelos de costos. Sin embargo, esta funcionalidad de escalado también permite al servicio escalar para gestionar el tráfico no deseado y el tráfico malintencionado.

  • La mitigación del tráfico no deseado conlleva costos. La adición de servicios como un firewall de aplicaciones web y la protección contra DDoS aumenta los gastos. Escalar su servicio para gestionar aumentos de tráfico aumenta los costos debido a las unidades adicionales. Establecer límites de escalado superior puede limitar el gasto, pero podría dar lugar a problemas de confiabilidad para los usuarios legítimos si el tráfico malintencionado o dañino sobrecarga la API.

Enfoque federado frente a distribuido

Una decisión fundamental en API Management es si se deben colocar cargas de trabajo dispares dentro de una sola instancia de API Management o aislar las cargas de trabajo entre varias instancias de una topología totalmente autónoma.

Las áreas de trabajo de API Management permiten un funcionamiento eficaz como una plataforma de coubicación de varios inquilinos para varios equipos de API. Los modelos de precios por niveles están diseñados para permitir que los costos de servicio se compartan entre todos los arrendatarios que usan las pasarelas. Sin embargo, como cualquier plataforma de colocación, interrupciones o configuraciones incorrectas puede dar lugar a efectos generalizados en cargas de trabajo no relacionadas que comparten la misma infraestructura.

Un modelo totalmente distribuido, donde cada equipo de carga de trabajo administra sus propias instancias, introduce costos duplicados y redundancia en operaciones rutinarias. Sin embargo, proporciona mitigación inherente del radio de explosión para incidentes relacionados con la confiabilidad, la seguridad y el rendimiento.

Pasos siguientes

API Management suele combinarse con los siguientes servicios. Asegúrese de revisar sus guías de servicio o documentación del producto si la carga de trabajo incluye los siguientes servicios.

En los artículos siguientes se muestran algunas de las recomendaciones que se describen en este artículo.