1. Despliegue un microservicio en Kubernetes para procesar mensajes de la cola de OCI
  2. Acerca de la ampliación de consumidores de colas de OCI en Kubernetes

Acerca de la ampliación de consumidores de colas de OCI en Kubernetes

En este manual se muestra cómo utilizar las funciones de la cola de Oracle Cloud Infrastructure (OCI) y se proporciona una receta que se adapta a la mayoría de los casos de uso que requieren una ampliación dinámica, en función de la cantidad de demanda del cliente, sin que se produzcan problemas de contrapresión o de cuello de botella de rendimiento.

Puede desplegar un microservicio en Oracle Kubernetes Engine (OKE), que procesa mensajes de una cola de OCI y, a continuación, aprovechar la profundidad de cola para escalar horizontalmente las instancias de microservicio que se ejecutan en un cluster de OKE. El ejemplo incluye un generador de mensajes que puede ejecutar desde cualquier lugar; por ejemplo, desde la máquina local o como parte de otro contenedor o máquina virtual.

En este manual también se proporcionan instrucciones de configuración detalladas y de código, que se pueden encontrar en el repositorio Oracle-DevRel GitHub, oci-arch-queue-oke-demo (al que puede acceder desde la sección Explorar más de este manual). Esta solución proporciona todos los archivos de configuración, scripts y código Java, junto con pasos detallados sobre la creación, el despliegue y la ejecución de los bloques de creación. En este documento se proporcionará una vista arquitectónica y se examinarán los elementos clave de la implantación, incluida la identificación de las partes del código que necesitará modificar para adaptar la solución a sus propias necesidades.

Más información sobre las API de colas de OCI

Las soluciones raramente abordan procesos únicos; la comunicación entre aplicaciones a menudo debe ser asíncrona para evitar limitar la solución por la parte más limitante de una solución (por ejemplo, que requiere CPU, latencia, etc.) . Puede superar estos problemas estableciendo una comunicación en la que los productores y consumidores no dependen unos de otros. Esto es lo que soporta la cola de OCI con un rendimiento muy alto.

Aunque Queue puede amortiguar las aplicaciones de las fluctuaciones de demanda, cuando los usuarios están involucrados, no desea que transcurra mucho tiempo entre la creación de mensajes y el procesamiento de mensajes. Por lo tanto, el backend debe poder escalar dinámicamente, según la demanda. Esa demanda está determinada por elnúmero de mensajes que se encuentran en la cola; más mensajessignifica más demanda y, por lo tanto, más esfuerzo informáticonecesario. Por el contrario, una cola vacía no representa ninguna demanda y, por lo tanto, necesita recursos de backend mínimos. La escala dinámica aborda estas variaciones constantes.

Arquitectura

Esta arquitectura necesita una cola para los mensajes que residen fuera de nuestros dominios de errores visibles, ya que se trata de un servicio totalmente gestionado.

En OCI, puede ejecutar Kubernetes con nodos gestionados por el cliente o con nodos gestionados por Oracle. Este escenario utiliza el enfoque anterior de los nodos de cliente, por lo que necesita nodos de Compute asociados al cluster. Estos nodos se distribuyen mejor entre los dominios de errores dentro de una zona de disponibilidad.

Nota:

En este manual, la generación de demanda proviene de su máquina local y, por lo tanto, fuera del entorno de OCI.

Los dos últimos elementos clave controlan la escala. En primer lugar, se llama periódicamente a una función de OCI y recupera los detalles de la profundidad de cola. Para abstraer la forma en que se determina la profundidad de la cola, se utiliza un gateway de API, que facilita la llamada a funciones de OCI.

Por último, necesitamos servicios auxiliares, como Vault, para almacenar credenciales para acceder a la cola, supervisar la observación general del estado, etc.


A continuación se muestra la descripción de Queue-scaling-oke-arch.png
Descripción de la ilustración Queue-scaling-oke-arch.png

escala de cola-oke-arch-oracle.zip

Los números del diagrama anterior representan esta secuencia de eventos:
  1. El productor alojado localmente coloca los mensajes en la cola de OCI.
  2. Nuestras instancias de consumidor de OCI recuperan mensajes de la cola. Dentro del código, la tasa de consumo se restringe mediante un retraso. Esto garantiza que el proveedor está generando más mensajes de los que un único consumidor puede eliminar de la cola. Como resultado, los mecanismos de ampliación funcionarán.
  3. De forma periódica, un trabajo programado de Kubernetes soportará KEDA para llamar a la API publicada y obtener el número de mensajes en la cola.
  4. El gateway de API dirige la solicitud a una instancia de la función de OCI.
  5. La función de OCI interroga la cola de OCI.
  6. La respuesta se devuelve, lo que provocará que KEDA dispare un aumento o una disminución de las instancias del microservicio.
Además, (a) esta implementación también permite al usuario, en cualquier momento, interrogar el estado de la profundidad de la cola.
Esta arquitectura contiene estos componentes:
  • Región

    Una región de OCI es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y las grandes distancias pueden separarlas (entre países e incluso continentes).

  • dominios de disponibilidad

    Los dominios de disponibilidad son centros de datos independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten servicios de infraestructura, como la alimentación, la refrigeración o la red interna del dominio de disponibilidad. Por lo tanto, es improbable que un fallo en un dominio de disponibilidad afecte a los otros dominios de la región.

  • Dominios de errores

    Un dominio de errores es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad tiene tres dominios de errores con energía y hardware independientes. Al distribuir recursos entre varios dominios de errores, sus aplicaciones pueden tolerar fallos en el servidor físico, el mantenimiento del sistema y los fallos de energía dentro de un dominio de errores.

  • Compartimento

    Los compartimentos son particiones lógicas entre regiones dentro de un arrendamiento de OCI. Utilice compartimentos para organizar los recursos en Oracle Cloud, controlar el acceso a los recursos y definir cuotas de uso. Para controlar el acceso a los recursos de cada compartimento, defina políticas que especifiquen quién puede acceder a los recursos y qué acciones pueden realizar.

  • Red virtual en la nube (VCN) y subredes

    Una VCN es una red personalizable y definida por software que se configura en una región de OCI. Al igual que las redes de centros de datos tradicionales, las redes virtuales le proporcionan un control completo de su entorno de red. Una VCN puede tener varios bloques CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, que se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está compuesta por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.

  • Recursos informáticos

    OCI Compute permite aprovisionar y gestionar hosts informáticos. Puede iniciar instancias informáticas con unidades que cumplan los requisitos de recursos (CPU, memoria, ancho de banda de red y almacenamiento). Después de crear una instancia informática, puede acceder a ella de forma segura, reiniciarla, asociar y desconectar volúmenes y terminarla cuando no lo necesite.

  • Funciones

    Oracle Functions es una plataforma de funciones como servicio (FaaS) totalmente gestionada, multitenant, altamente escalable y bajo demanda. Se basa en el motor de código abierto de Fn Project. Las funciones permiten desplegar el código y llamarlo directamente o dispararlo en respuesta a eventos. Oracle Functions utiliza contenedores de Docker alojados en OCI Registry.

  • Registro de contenedor

    OCI Registry es un registro gestionado por Oracle que permite simplificar el flujo de trabajo de desarrollo a producción. El registro facilita el almacenamiento, el uso compartido y la gestión de artefactos de desarrollo, como imágenes de Docker. La arquitectura altamente disponible y ampliable de OCI garantiza que pueda desplegar y gestionar sus aplicaciones de forma fiable.

  • Container Engine para Kubernetes

    OCI Container Engine for Kubernetes es un servicio totalmente gestionado, escalable y disponible que puede utilizar para desplegar las aplicaciones en contenedores en la nube. Especifique los recursos informáticos que necesitan sus aplicaciones y Container Engine for Kubernetes los proporciona en OCI en un arrendamiento existente. Container Engine for Kubernetes utiliza Kubernetes para automatizar el despliegue, el ajuste y la gestión de aplicaciones en contenedores en clusters de hosts.

  • Gateway de API

    Oracle API Gateway permite publicar API con puntos finales para gestionar la visibilidad de la funcionalidad, como funciones, microservicios y otras interfaces de aplicaciones. Los puntos finales proporcionan controles de seguridad detallados para las soluciones backend, así como una abstracción de cómo se puede implantar una API.

  • Cola

    La cola es un mecanismo de comunicación asíncrona altamente escalable sin servidor. Es ideal para permitir la disociación de servicios y entrega de mensajes.

Consideraciones

Al desplegar un microservicio en Kubernetes para procesar mensajes de la cola de OCI, debe tener en cuenta lo siguiente:

  • Consideraciones sobre las políticas para colas

    Las políticas para controlar y configurar las colas de OCI y las políticas para crear y consumir mensajes están separadas. Esto le proporciona un control detallado de las operaciones disponibles a través de las API. Esto significa que debe tener en cuenta los requisitos y las necesidades de seguridad de la aplicación. Para la producción, se recomiendan controles estrictos; esta implantación utiliza valores de configuración relajados, lo que minimiza la posibilidad de que se produzca un error de configuración que impida que la demostración funcione.

  • Consideraciones sobre los límites de ampliación de Kubernetes

    Debe tener en cuenta la velocidad y los límites de la ampliación de backend. Debe abordar factores, como la profundidad de la cola antes de iniciar instancias adicionales del microservicio. El número máximo de instancias adicionales de un microservicio debe estar en ejecución. Si bien sería tentador no vincular esto, en el mundo real, términos prácticos, si alguien (de forma deliberada o accidental) comienza a inundar su cola con mensajes erróneos, no desea absorber los costos de la potencia de cálculo adicional necesaria para quedarse atrás. También debe tener en cuenta la rapidez con la que se desactivan las instancias adicionales de su microservicio. Póngase demasiado rápido y encontrará su entorno constantemente iniciando y parando servicios. Independientemente de la eficiencia del microservicio, siempre habrá un costo general de iniciar y detener instancias de servicio que, en última instancia, cuestan.

  • Consideraciones para el control de escala

    El último aspecto del control de la ampliación es si desea aplicar la ampliación y cómo controlarla. Este escenario utiliza un proyecto CNCF denominado KEDA (escala automática basada en eventos de Kubernetes). Además de cómo se ejecuta la ampliación de backend, debe tener en cuenta cómo se llama a la API. En este caso, puede configurar un trabajo programado de Kubernetes (ya que el trabajo lo realiza un nodo de trabajador, el diagrama refleja este flujo) para llamar a la API.

Requisitos previos

Antes de empezar, debe preparar el entorno cumpliendo los requisitos que se describen aquí.

  • Para la generación de mensajes, necesita Java 8 o posterior (Java 8 instalado junto con Apache Maven).
  • La interacción con la cola de OCI necesitará usuarios y credenciales asociadas para permitir el acceso. Defina estas políticas:
    • Defina esta política para identificar el compartimento que utilizará (compartment-name): 
      allow any-user to manage queues in compartment compartment-name
    • Para limitar a los usuarios a leer o escribir en la cola de OCI, cree grupos de OCI denominados MessageConsumers y MessageProducers y asigne los usuarios adecuados a estos grupos. Utilice las siguientes políticas: 
      allow group MessageConsumers to use queues in compartment compartment-name 
allow group MessageProducers to use queues in compartment compartment-name
    • Proporcione al cliente productor los atributos de configuración estándar de OCI para que pueda autenticarse con OCI y utilizar la API.
    • Debe definir políticas para soportar el comportamiento dinámico porque los nuevos recursos van y van a necesitar acceso a la cola. Defina estas políticas creando un grupo dinámico con los recursos que necesitará controlar de forma flexible. Como este control se produce en OCI, utilice un principal de instancia. Llame a este grupo queue_dg. Utilice las siguientes sentencias de política: 
      ALL {instance.compartment.id='instance Compartment id (OCID)'} 
allow dynamic-group queue_dg to use queues in compartment queue_parent_compartment
      Donde instance Compartment id (OCID) es el compartimento que contiene los nodos de trabajador.

Información sobre Java SDK

Las tres partes de código (productor, consumidor y función) utilizan todas las API de OCI. La forma más sencilla de interactuar con las API es mediante el SDK de Java. Los SDK proporcionados por OCI proporcionan una serie de funciones de convencimiento que recuperan la información necesaria para que pueda autenticar y autorizar las llamadas de servicios de OCI. Los SDK adoptan la variante de Joshua Bloch del patrón de Builder. Puede encontrar más información sobre el SDK en Java SDK. El repositorio DevRel GitHub de Oracle tiene más ejemplos de los SDK que se utilizan aquí, por ejemplo, en https://github.com/oracle-devrel/oci-arch-queue-demo.