Editar

Share via


Patrón Gateway Offloading

Azure Application Gateway

Descarga una funcionalidad de servicio compartida o especializada en un proxy de puerta de enlace. Este patrón puede simplificar la implementación de la aplicación al mover la funcionalidad del servicio compartido, como el uso de certificados SSL, de otras partes de la aplicación a la puerta de enlace.

Contexto y problema

Algunas de las características que se usan habitualmente en varios servicios requieren configuración, administración y mantenimiento. Un servicio compartido o especializado que se distribuye con cada implementación de aplicación aumenta la sobrecarga administrativa y la probabilidad de errores de implementación. Las actualizaciones de las características compartidas deben implementarse en todos los servicios que la comparten.

La correcta administración de los problemas de seguridad (validación de tokens, cifrado, administración de certificados SSL) y otras tareas complejas puede requerir conocimientos muy especializados de los miembros del equipo. Por ejemplo, un certificado que una aplicación necesita debe configurarse e implementarse en todas las instancias de la aplicación. Con cada nueva implementación, el certificado debe administrarse para garantizar que no va a expirar. Cualquier certificado común a punto de caducar debe actualizarse, probarse y comprobarse en cada implementación de la aplicación.

Otros servicios comunes, como la autenticación, la autorización, el registro, la supervisión, o l limitación pueden resultar difíciles de implementar y administrar en un gran número de implementaciones. Es posible que convenga combinar este tipo de funcionalidad con el fin de reducir la sobrecarga y la posibilidad de errores.

Solución

Descargue algunas características en una puerta de enlace, especialmente cuestiones transversales, como la administración de certificados, la autenticación, la terminación de SSL, la supervisión, la traducción de protocolos o la limitación del ancho de banda.

En el siguiente diagrama se muestra una puerta de enlace que termina las conexiones de SSL entrantes. Solicita datos en nombre del solicitante original desde cualquier servidor HTTP en dirección ascendente en relación con la puerta de enlace.

Diagrama del patrón Gateway Offloading

Estos son algunos ejemplos de las ventajas de este patrón:

  • Simplifica el desarrollo de servicios mediante la eliminación de la necesidad de distribuir y mantener los recursos de compatibilidad, como los certificados de servidor web y la configuración de sitios web seguros. Una configuración más simple facilita la administración y la escalabilidad, y simplifica las actualizaciones del servicio.

  • Permite a los equipos expertos implementar características que requieren conocimientos especializados, como la seguridad. Esto permite que el equipo principal se centre en la funcionalidad de la aplicación, dejando estos aspectos especializadas pero transversales en manos de los expertos correspondientes.

  • Proporciona coherencia en el registro y la supervisión de las solicitudes y las respuestas. Aunque un servicio no se haya instrumentado correctamente, la puerta de enlace se puede configurar para garantizar un registro y una supervisión mínimos.

Problemas y consideraciones

  • Asegúrese de que la puerta de enlace proporcione una alta disponibilidad y sea resistente a errores. Evite los puntos únicos de error mediante la ejecución de varias instancias de la puerta de enlace.
  • Asegúrese de que la puerta de enlace está diseñada para los requisitos de capacidad y escalado de la aplicación y los puntos de conexión. Asegúrese de que la puerta de enlace no se convierte en cuello de botella para la aplicación y de que es lo suficientemente escalable.
  • Descargue solo las características que use toda la aplicación, como la seguridad o la transferencia de datos.
  • La lógica de negocios nunca se debe descargar a la puerta de enlace.
  • Si necesita realizar un seguimiento de las transacciones, considere la posibilidad de generar identificadores de correlación para fines de registro.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

  • Una implementación de una aplicación tenga un problema compartido, como de los certificados SSL o el cifrado.
  • Una característica común a las implementaciones de la aplicación pueda tener requisitos de recursos diferentes, como los recursos de memoria, la capacidad de almacenamiento o las conexiones de red.
  • Quiera que la responsabilidad de problemas como la seguridad de red, la limitación u otros problemas de límite de red recaiga en un equipo más especializado.

Este patrón puede no ser adecuado si introduce acoplamiento entre servicios.

Diseño de cargas de trabajo

El arquitecto debe evaluar cómo se puede usar el patrón de descarga de la puerta de enlace en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Marco de la Well-Architected de Azure. Por ejemplo:

Fundamento Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de la fiabilidad ayudan a que la carga de trabajo sea resistente a los errores y a garantizar que se recupere a un estado de pleno funcionamiento después de que se produzca un error. Descargar esta responsabilidad a una puerta de enlace reduce la complejidad del código de la aplicación en los nodos back-end. En algunos casos, la descarga sustituye completamente la funcionalidad por una característica fiable proporcionada por la plataforma.

- RE:01 Simplicidad y eficiencia
Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo. Añadir una puerta de enlace al flujo de solicitudes le permite centralizar las funciones de seguridad, como los firewall de aplicaciones web y las conexiones TLS con los clientes. Cualquier funcionalidad descargada que proporcione la plataforma ya ofrece una mayor seguridad.

- SE:06 Controles de red
- SE:08 Recursos de protección
La optimización de costos se centra en mantener y mejorar el retorno de la inversión de la carga de trabajo. Este patrón le permite redirigir los costos de los recursos que se gastarían por nodo a la implementación de la puerta de enlace. Los costos del modelo de procesamiento centralizado suelen ser inferiores a los del modelo distribuido.

- CO:14 Consolidación
La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos. En este patrón, la configuración y el mantenimiento de la funcionalidad descargada se realiza desde un único punto en lugar de gestionarla desde varios nodos.

- OE:04 Herramientas y procesos
La eficiencia del rendimiento ayuda a que la carga de trabajo satisfaga eficazmente las demandas mediante optimizaciones en el escalado, los datos y el código. Añadir una puerta de enlace de descarga al proceso de solicitud le permite utilizar menos recursos por nodo porque la funcionalidad está centralizada en la puerta de enlace. Puede optimizar la implementación de la funcionalidad descargada independientemente del código de la aplicación. Es probable que la funcionalidad descargada que proporciona la plataforma ya tenga un alto rendimiento.

- PE:03 Selección de servicios

Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.

Ejemplo

Al usar Nginx como dispositivo para descargar SSL, la siguiente configuración finaliza una conexión entrante de SSL y distribuye la conexión a uno de los tres servidores HTTP ascendentes.

upstream iis {
        server  10.3.0.10    max_fails=3    fail_timeout=15s;
        server  10.3.0.20    max_fails=3    fail_timeout=15s;
        server  10.3.0.30    max_fails=3    fail_timeout=15s;
}

server {
        listen 443;
        ssl on;
        ssl_certificate /etc/nginx/ssl/domain.cer;
        ssl_certificate_key /etc/nginx/ssl/domain.key;

        location / {
                set $targ iis;
                proxy_pass http://$targ;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
        }
}

En Azure, esto se puede lograr con la configuración de una terminación SSL en Application Gateway.