Implementar una instancia de Azure API Management en varias regiones de Azure

Azure API Management admite la implementación en varias regiones, lo que permite a los publicadores de API agregar puertas de enlace de API regionales a una instancia de API Management existente en una o varias regiones de Azure admitidas. La implementación en varias regiones ayuda a reducir la latencia de las solicitudes que perciben los consumidores de API distribuidos geográficamente, y mejora la disponibilidad del servicio en caso de que una región se quede sin conexión.

Al agregar una región, configure:

Importante

La característica para permitir el almacenamiento de datos de clientes en una sola región solo está disponible actualmente en la región de Sudeste Asiático (Singapur) de la geoárea Asia Pacífico. En todas las demás regiones, los datos del cliente se almacenan en la geoárea.

Disponibilidad

Importante

Esta característica solo está disponible en el nivel Premium de API Management.

Acerca de la implementación multirregional

  • Con la implementación en varias regiones, solo el componente de puerta de enlace de la instancia de API Management se replica en varias regiones. El plano de administración y el portal para desarrolladores de la instancia permanecen hospedados solo en la región primaria, donde implementó originalmente el servicio.

  • Las configuraciones de puerta de enlace, como las API y las definiciones de directiva, se sincronizan periódicamente entre las regiones principal y secundaria que agregue. La implementación en varias regiones proporciona disponibilidad de la puerta de enlace de API en más de una región y proporciona disponibilidad del servicio si una región se queda sin conexión.

  • Cuando API Management recibe solicitudes HTTP públicas al punto de conexión de puerta de enlace principal, el tráfico se enruta a una puerta de enlace regional en función de la latencia más baja, lo que puede reducir la latencia experimentada por consumidores de API distribuidos geográficamente.

  • Si una región se queda sin conexión, las solicitudes de la API se enrutan de forma automática para evitar la región con errores hacia la siguiente puerta de enlace más cercana.

  • Si la región primaria se queda sin conexión, el plano de administración de API Management y el portal para desarrolladores deja de estar disponible, pero las regiones secundarias siguen atendiendo solicitudes de API mediante la configuración de puerta de enlace más reciente.

Requisitos previos

Implementación del servicio API Management en una región adicional

  1. En Azure Portal, vaya al servicio API Management y seleccione Ubicaciones en el menú de la izquierda.
  2. Seleccione + Agregar en la barra superior.
  3. Seleccione la ubicación agregada en la lista desplegable.
  4. Seleccione el número de unidades de escalado de la ubicación.
  5. Opcionalmente, seleccione una o más zonas de disponibilidad.
  6. Si la instancia de API Management se ha implementado en una red virtual, configure las siguientes opciones de la red virtual en la ubicación. Seleccione una red virtual, una subred y una dirección IP pública existentes que estén disponibles en la ubicación.
  7. Seleccione Agregar para confirmar.
  8. Repita este proceso hasta que configure todas las ubicaciones.
  9. Seleccione Guardar en la barra superior para iniciar el proceso de implementación.

Eliminación de una región de servicio de API Management

  1. En Azure Portal, vaya al servicio API Management y seleccione Ubicaciones en el menú de la izquierda.
  2. Para la ubicación que desee eliminar, seleccione el menú contextual mediante el botón ... situado a la derecha de la tabla. Seleccione Eliminar.
  3. Confirme la eliminación y seleccione Guardar para aplicar los cambios.

Enrutamiento de las llamadas API a servicios regionales back-end

De forma predeterminada, cada API enruta las solicitudes a una única dirección URL del servicio back-end. Incluso si ha configurado las puertas de enlace de Azure API Management en varias regiones, la puerta de enlace de la API seguirá reenviando las solicitudes al mismo servicio backend, que está implementado en una sola región. En este caso, la ganancia de rendimiento procederá solo de las respuestas en caché a la solicitud en Azure API Management de una región específica, también puede generar una latencia alta al ponerse en contacto con el back-end de todo el mundo.

Para aprovechar la distribución geográfica de su sistema, debe tener servicios de backend implementados en las mismas regiones que las instancias de Azure API Management. A continuación, mediante directivas y la propiedad @(context.Deployment.Region) puede enrutar el tráfico a las instancias locales de su back-end.

Sugerencia

Opcionalmente, establezca la propiedad disableGateway en una puerta de enlace regional para deshabilitar el enrutamiento del tráfico de API allí. Por ejemplo, deshabilite temporalmente una puerta de enlace regional al probar o actualizar un servicio back-end regional.

  1. Vaya a la instancia de Azure API Management y seleccione API en el menú izquierdo.

  2. Seleccione la API que desee.

  3. Seleecione el Editor de código de la flecha desplegable de Procesamiento de entrada.

    Editor de código de API

  4. Use set-backend en combinación con directivas choose condicionales para construir una directiva de enrutamiento adecuada en la sección <inbound> </inbound> del archivo.

    Por ejemplo, el siguiente archivo XML funcionaría para las regiones de Oeste de EE. UU. y Asia Pacífico:

    <policies>
        <inbound>
            <base />
            <choose>
                <when condition="@("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                    <set-backend-service base-url="http://contoso-backend-us.com/" />
                </when>
                <when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                    <set-backend-service base-url="http://contoso-backend-asia.com/" />
                </when>
                <otherwise>
                    <set-backend-service base-url="http://contoso-backend-other.com/" />
                </otherwise>
            </choose>
        </inbound>
        <backend>
            <base />
        </backend>
        <outbound>
            <base />
        </outbound>
        <on-error>
            <base />
        </on-error>
    </policies>
    

Sugerencia

También puede adelantar sus servicios de back-end con Azure Traffic Manager, dirigir las llamadas de las API a Traffic Manager y dejar que resuelva el enrutamiento automáticamente.

Uso del enrutamiento personalizado a puertas de enlace regionales de API Management

API Management enruta las solicitudes a una puerta de enlace regional en función de la latencia más baja. Aunque no es posible invalidar esta configuración en API Management, puede usar su propia instancia de Traffic Manager con reglas de enrutamiento personalizadas.

  1. Cree su propio perfil de Azure Traffic Manager.
  2. Si usa un dominio personalizado, úselo con Traffic Manager y no con el servicio API Management.
  3. Configuración de los puntos de conexión regionales de API Management en Traffic Manager. Los puntos de conexión regionales siguen el patrón de dirección URL de https://<service-name>-<region>-01.regional.azure-api.net, por ejemplo https://contoso-westus2-01.regional.azure-api.net.
  4. Configure los puntos de conexión de estado regional de API Management en Traffic Manager. Los puntos de conexión de estado regional siguen el patrón de dirección URL de https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, por ejemplo https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
  5. Especifique el método de enrutamiento de Traffic Manager.

Redes virtuales

En esta sección se proporcionan consideraciones para las implementaciones de varias regiones cuando la instancia de API Management se inserta en una red virtual.

  • Configure cada red regional de forma independiente. Los requisitos de conectividad, como las reglas de grupo de seguridad de red necesarias para una red virtual de una región agregada, son los mismos que para una red de la región primaria.
  • No es necesario emparejar redes virtuales en las distintas regiones.

Direcciones IP

  • Se crea una dirección IP virtual pública en cada región agregada con una red virtual. En el caso de las redes virtuales en modo externo o en modo interno, esta dirección IP pública es necesaria para la administración del tráfico en el puerto 3443.

    • Modo de red virtual externa : las direcciones IP públicas también son necesarias para enrutar el tráfico HTTP público a las puertas de enlace de API.

    • Modo de red virtual interna: también se crea una dirección IP privada en cada región agregada con una red virtual. Use estas direcciones para conectarse dentro de la red a los puntos de conexión de API Management en las regiones primarias y secundarias.

Enrutamiento

  • Modo de red virtual externa: el enrutamiento del tráfico HTTP público a las puertas de enlace regionales se controla automáticamente, de la misma manera que para una instancia de API Management no conectada a la red.

  • Modo de red virtual interna: el tráfico HTTP privado no se enruta ni se equilibra la carga a las puertas de enlace regionales de forma predeterminada. Los usuarios son propietarios del enrutamiento y son responsables de traer su propia solución para administrar el enrutamiento y el equilibrio de carga privado en varias regiones. Entre las soluciones de ejemplo se incluyen Azure Application Gateway y Azure Traffic Manager.

Pasos siguientes