Solución API7: Alta Disponibilidad para Servicios B2B

En el curso de la comunicación con los clientes, una pregunta clave surge con frecuencia: "¿Ofrecen alta disponibilidad? y ¿cómo?"

API7 Enterprise proporciona componentes para implementaciones de alta disponibilidad administradas por el cliente. La disponibilidad depende de la arquitectura de implementación, las dependencias de infraestructura y las operaciones del cliente; API7 Enterprise autogestionado no incluye un porcentaje de disponibilidad a nivel de producto.

En el entorno empresarial, la alta disponibilidad de los servicios API es particularmente crítica, ya que impacta directamente en la continuidad y confiabilidad del cliente. ¿Por qué es tan crucial la alta disponibilidad para los negocios B2B? Porque, como una métrica clave, cualquier interrupción o falla de los servicios API en momentos críticos puede afectar gravemente el negocio del cliente, resultando no solo en pérdidas financieras, sino también potencialmente dañando la reputación y credibilidad del cliente.

¿Cómo admite API7 implementaciones de alta disponibilidad?

La alta disponibilidad es un objetivo de arquitectura y operaciones, no una propiedad que un producto pueda garantizar por sí solo. Las secciones siguientes describen los componentes que API7 Enterprise proporciona para ayudar a los clientes a crear implementaciones de alta disponibilidad. El resultado real depende del número de instancias, el diseño de conmutación por error, las dependencias de infraestructura y las operaciones del cliente.

Plano de Control sin Estado

El plano de control de API7 Enterprise utiliza un diseño sin estado para administrar las configuraciones de API. Esto permite que el cliente o una plataforma de orquestación ejecute varias instancias y sustituya las que no estén en buen estado sin transferir estado de aplicación entre ellas. El diseño puede reducir el impacto de la pérdida de una instancia, siempre que el cliente configure la redundancia, las comprobaciones de estado, la distribución del tráfico y la capacidad de sustitución adecuadas.

PostgreSQL como Centro de Configuración Predeterminado

API7 Enterprise utiliza PostgreSQL para almacenar los datos de configuración. PostgreSQL puede desplegarse con los patrones de replicación y conmutación por error seleccionados por el cliente, de modo que una instancia en espera pueda asumir el servicio si falla la instancia principal. El cliente o el proveedor de infraestructura configura, supervisa y prueba la conmutación por error de la base de datos; por tanto, la disponibilidad de los datos de configuración depende de la arquitectura de PostgreSQL, almacenamiento, red y operaciones utilizada.

Plano de Datos sin Estado

El plano de datos se basa en APISIX, y las instancias del gateway no mantienen estado para procesar el tráfico. Esto permite ejecutar, escalar y sustituir varias instancias mediante un balanceador de carga o una plataforma de orquestación. El diseño puede reducir el impacto de perder una instancia, pero no garantiza la continuidad del servicio si fallan la capacidad, la red, los servicios dependientes o la distribución del tráfico.

Plano de Datos y Plano de Control Independientes

API7 Enterprise separa el procesamiento del tráfico en el plano de datos de la administración de configuraciones en el plano de control. El plano de datos utiliza la configuración sincronizada y no necesita consultar el plano de control para cada solicitud. Si el plano de control no está disponible en determinados escenarios, una instancia del plano de datos puede procesar solicitudes con la última configuración conocida, pero no recibirá nuevas actualizaciones hasta que se restablezca la conexión. El resultado sigue dependiendo del estado de las instancias del gateway, sus dependencias y la arquitectura del cliente.

Escenarios de Uso y Beneficios de la Arquitectura de Alta Disponibilidad

En implementaciones con Docker o en una máquina virtual, los clientes pueden ejecutar varias instancias de API7 Gateway detrás de un balanceador de carga con comprobaciones de estado y usar las herramientas operativas que elijan para retirar y sustituir instancias no saludables. En Kubernetes, las réplicas, las comprobaciones de preparación y actividad y los controladores pueden sustituir pods no saludables. Estos mecanismos solo son eficaces si el cliente configura adecuadamente el número de réplicas, la capacidad, la programación, el almacenamiento, la red y las pruebas de conmutación por error.

Cuando estos mecanismos se diseñan, operan y prueban adecuadamente, pueden reducir el impacto de determinados fallos, acelerar la recuperación y ayudar a continuar procesando parte del tráfico. Sin embargo, no evitan todas las interrupciones del negocio ni garantizan menores costos de mantenimiento. Los resultados dependen de los objetivos de recuperación, la redundancia, las dependencias externas, la supervisión y los procedimientos operativos del cliente.

Conclusión

API7 Enterprise proporciona mecanismos de alta disponibilidad para implementaciones administradas por el cliente. Estos mecanismos pueden reducir el impacto de los fallos, pero la disponibilidad del servicio alcanzada depende de la arquitectura de implementación, las dependencias de infraestructura y las operaciones del cliente.