Despliegue una solución GraphQL altamente ampliable
Esta arquitectura de referencia muestra cómo desplegar una solución basada en GraphQL que se puede ampliar fácilmente para satisfacer la demanda de carga de trabajo.
GraphQL, una consulta de datos de código abierto y un lenguaje de manipulación para API, y un tiempo de ejecución para realizar consultas con datos existentes, es un componente ideal para implantaciones como aplicaciones móviles que definen explícitamente los atributos necesarios. Proporciona API en las que un cliente puede querer solicitar datos entre entidades relacionadas para optimizar el flujo de solicitud y respuesta, por ejemplo, minimizar el tráfico de red móvil para aplicaciones móviles. GraphQL también ofrece un medio eficaz para ayudar a abstenerse de los consumidores de API de cómo se pueden implantar soluciones de backend proporcionando un único esquema que puede abarcar muchos servicios de backend diferentes.
Arquitectura
Esta arquitectura define diferentes rutas para el contenido de API estático y dinámico. Este enfoque facilita la optimización del acceso al contenido estático mediante la configuración de las opciones de almacenamiento en caché en varias capas, incluido el uso de una red de entrega de contenido (CDN), en el equilibrador de carga y en los servicios de backend que cargan y sirven el contenido.
Los servicios de backend se implementan con microservicios en esta arquitectura. Estos servicios también podrían desplegar una solución de CMS, como Oracle Content and Experience, a través de opciones de CMS de código abierto. Como el contenido es estático, los riesgos de seguridad son considerablemente menores.
El contenido de API se enruta a través de un gateway de API para que las solicitudes de API se puedan validar y controlar (por ejemplo, limitado a tarifas). A continuación, el tráfico se envía al equilibrador de carga del motor de Kubernetes de Oracle, el punto de entrada en el cluster, que lo dirige a un servidor GraphQL. Idealmente, si se utilizan microservicios para servir el contenido estático, los servicios que admiten GraphQL y el contenido estático se mantienen en espacios de nombres separados para un mayor aislamiento y control.
Esta implementación adopta el servidor Apollo GraphQL de código abierto para recibir las llamadas y descomponer el trabajo para separar microservicios que alojan la lógica del solucionador y del mutador. Puede escalar la implantación de forma más eficaz mediante la implantación de los diferentes subdominios dentro del modelo de datos mediante servicios independientes. Por lo tanto, es más fácil ajustar la solución con cualquier almacenamiento en caché en memoria.
El siguiente diagrama ilustra esta arquitectura de referencia.
Descripción de la ilustración deployment-hs-graphql.png
El código y la documentación para implantar la arquitectura, incluidos los servicios de ejemplo, se pueden encontrar en el repositorio de GitHub relevante (consulte el tema Desplegar, a continuación). La ruta de API utiliza un servidor Apollo GraphQL y servicios Python para cada subdominio. Se incluye más información en la documentación de GitHub proporcionada.
- arrendamiento
Un arrendamiento abarca todas las regiones que se utilizan. Para maximizar el rendimiento y la resiliencia, desea replicar el despliegue en varias regiones del mundo y combinar el enrutamiento DNS público para que los clientes vayan a la región más cercana a fin de minimizar la latencia. Esto requeriría que los datos de backend se replicaran entre regiones.
- Región
Una región de Oracle Cloud Infrastructure 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 separarse (entre países e incluso continentes).
- Compartimento
Los compartimentos son particiones lógicas entre regiones de un arrendamiento de Oracle Cloud Infrastructure. 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 un compartimento determinado, debe definir políticas que especifiquen quién puede acceder a los recursos y qué acciones pueden realizar. Los controles de compartimento para esta arquitectura se pueden agregar para separar la capa de acceso público y el backend, con el fin de minimizar el riesgo de crear accidentalmente rutas directas a la capa de seguridad.
- 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 infraestructuras, como alimentación o refrigeración, ni la red del dominio de disponibilidad interno. Por tanto, es poco probable que un fallo en un dominio de disponibilidad afecte a los otros dominios de disponibilidad de la región. En esta arquitectura de referencia, los nodos de trabajador de Kubernetes se distribuyen entre los dominios de errores y los dominios de disponibilidad para garantizar una resiliencia máxima.
- 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 hardware y potencia independientes. Cuando distribuye recursos entre varios dominios de errores, sus aplicaciones pueden tolerar fallos en el servidor físico, el mantenimiento del sistema y los fallos de alimentación dentro de un dominio de errores.
- Red virtual en la nube (VCN) y subredes
Una VCN es una red personalizable definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes de centros de datos tradicionales, las VCN le proporcionan un control total 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á formada por un rango contiguo de direcciones que no se solapan con las demás subredes de VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- equilibrador de carga
Oracle Cloud Infrastructure Load Balancing ofrece una distribución automatizada de tráfico desde un único punto de entrada a varios servidores en el backend. En esta arquitectura de referencia, el equilibrador de carga incluirá políticas de enrutamiento para separar el tráfico que se dirige al gateway de API para datos dinámicos y el contenido estático (por ejemplo, imágenes, páginas web, etc.). A continuación, podrá aprovechar las capacidades de aceleración de aplicaciones web (WAA) del equilibrador de carga.
- Lista de seguridad
Para cada subred, puede crear reglas de seguridad que especifiquen el origen, el destino y el tipo de tráfico que se debe permitir dentro y fuera de la subred.
- Gateway de NAT
El gateway de NAT permite que los recursos privados de una VCN accedan a los hosts en Internet, sin exponer dichos recursos a las conexiones de Internet entrantes.
- Gateway de servicio
El gateway de servicios proporciona acceso desde una VCN a otros servicios, como Oracle Cloud Infrastructure Object Storage. El tráfico desde la VCN al servicio Oracle recorre el tejido de red de Oracle y no internet.
- Cloud Guard
Puede utilizar Oracle Cloud Guard para controlar y mantener la seguridad de los recursos en Oracle Cloud Infrastructure. Cloud Guard utiliza recetas de detector que puede definir para examinar los recursos en busca de debilidades de seguridad y supervisar a los operadores y usuarios en busca de actividades de riesgo. Cuando se detecta una configuración incorrecta o una actividad insegura, Cloud Guard recomienda acciones correctivas y ayuda a realizar esas acciones en función de las recetas de responsable de respuesta que pueda definir.
- Zona de seguridad
Las zonas de seguridad garantizan desde el principio las mejores prácticas de seguridad de Oracle mediante la aplicación de políticas como el cifrado de datos y la prevención del acceso público a las redes para un compartimento completo. Una zona de seguridad está asociada a un compartimento con el mismo nombre e incluye políticas de zona de seguridad o una "recepción" que se aplica al compartimento y sus subcompartimentos. No puede agregar ni mover un compartimento estándar a un compartimento de zona de seguridad.
- Base de datos autónoma
Las bases de datos autónomas de Oracle Cloud Infrastructure son entornos de base de datos completamente gestionados y preconfigurados que puede utilizar para el procesamiento de transacciones y las cargas de trabajo de almacenamiento de datos. No necesita configurar ni gestionar ningún hardware ni instalar ningún software. Oracle Cloud Infrastructure gestiona la creación de la base de datos, así como la copia de seguridad, la aplicación de parches, la actualización y el ajuste de la base de datos.
- Container Engine para Kubernetes
Oracle Cloud Infrastructure 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 aprovisionará en Oracle Cloud Infrastructure 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. El cluster de Kubernetes tendrá nodos asignados a diferentes zonas de almacén y zonas de disponibilidad para maximizar la resiliencia y la disponibilidad. El cluster de Kubernetes idealmente tendrá Istio u otra capacidad de malla de servicios para gestionar y supervisar los microservicios. El servicio GraphQL existirá en su propio pod, con los distintos solucionadores y mutadores desplegados en el cluster de Kubernetes como sus propios microservicios.
- Registro
Oracle Cloud Infrastructure 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 escalable de Oracle Cloud Infrastructure garantiza que puede desplegar y gestionar sus aplicaciones de forma fiable.
Recomendaciones
- VCN
Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque según el número de recursos que planea asociar a subredes en la VCN. Utilice bloques CIDR que estén dentro del espacio de dirección IP privada estándar.
Seleccione bloques CIDR que no se solapen con ninguna otra red (en Oracle Cloud Infrastructure, su centro de datos local u otro proveedor en la nube) en la que desea configurar conexiones privadas.
Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Al diseñar las subredes, tenga en cuenta los requisitos de seguridad y flujo de tráfico. Conecte todos los recursos de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
- Seguridad
Utilice Oracle Cloud Guard para supervisar y mantener la seguridad de los recursos en Oracle Cloud Infrastructure de forma proactiva. Cloud Guard utiliza recetas de detector que puede definir para examinar los recursos en busca de debilidades de seguridad y supervisar a los operadores y usuarios en busca de actividades de riesgo. Cuando se detecta una configuración incorrecta o una actividad insegura, Cloud Guard recomienda acciones correctivas y ayuda a realizar esas acciones en función de las recetas de responsable de respuesta que pueda definir. Para los recursos que requieren máxima seguridad, Oracle recomienda utilizar zonas de seguridad. Una zona de seguridad es un compartimento asociado a una receta definida por Oracle de políticas de seguridad que se basan en las mejores prácticas. Por ejemplo, no se puede acceder a los recursos de una zona de seguridad desde la Internet pública y se deben cifrar con claves gestionadas por el cliente. Al crear y actualizar recursos en una zona de seguridad, Oracle Cloud Infrastructure valida las operaciones con respecto a las políticas de la receta de zona de seguridad y deniega operaciones que violan cualquiera de las políticas.
- Cloud Guard
Clone y personalice las recetas por defecto proporcionadas por Oracle para crear recetas de detector y responsable de respuesta personalizadas. Estas recetas permiten especificar qué tipo de violaciones de seguridad generan una advertencia y qué acciones se pueden realizar en ellas. Por ejemplo, puede que desee detectar bloques de Object Storage que tengan una visibilidad definida como pública. Aplique Cloud Guard en el nivel del arrendamiento para abarcar el ámbito más amplio y reducir la carga administrativa que supone el mantenimiento de varias configuraciones. También puede utilizar la función de lista gestionada para aplicar determinadas configuraciones a los detectores.
- Grupos de seguridad de red (NSG)
Puede usar los NSG para definir un juego de reglas de entrada y salida que se aplican a VNIC específicas. Recomendamos utilizar NSG en lugar de listas de seguridad, ya que los NSG permiten separar la arquitectura de subred de la VCN de los requisitos de seguridad de la aplicación.
Puede usar los NSG para definir un juego de reglas de entrada y salida que se aplican a VNIC específicas. Recomendamos utilizar NSG en lugar de listas de seguridad, ya que los NSG permiten separar la arquitectura de subred de la VCN de los requisitos de seguridad de la aplicación.
- Ancho de banda de equilibrio de carga
Al crear el equilibrador de carga, puede seleccionar una unidad predefinida que proporcione un ancho de banda fijo o especificar una unidad personalizada (flexible) en la que defina un rango de ancho de banda y que el servicio amplíe el ancho de banda automáticamente en función de los patrones de tráfico. Con cualquier enfoque, puede cambiar la unidad en cualquier momento después de crear el equilibrador de carga.
- Gateway de API
API Gateway se puede utilizar para proporcionar un nivel inicial de controles de uso y de filtrado, como:
- Autenticación y autorización de servicio
- Controles de servicio como la limitación de tarifas
- Captura de análisis de uso de servicios
Consideraciones
Tenga en cuenta los siguientes puntos al desplegar esta arquitectura de referencia.
- Rendimiento
Esta arquitectura proporcionará un medio para desarrollar la capacidad de rendimiento tanto vertical como horizontalmente. Incluso con los microservicios más optimizados, hay un retraso en la introducción de nuevos nodos, por lo que se debe permitir esto al gestionar la ampliación de forma manual o dinámica. Esto será particularmente cierto para la capa de persistencia de cualquier solución.
- Seguridad
Debe abordar la seguridad a nivel de aplicación en el gateway de API. Sin embargo, puede abordar la seguridad específica de GraphQL detallada (por ejemplo, acceso de nivel de atributo) mediante directivas GraphQL como
@auth. - Disponibilidad
- Kubernetes
Los dominios de errores proporcionan resiliencia en un dominio de disponibilidad. Puede configurar los nodos de trabajador de Kubernetes para que se desplieguen en distintas zonas de disponibilidad.
- Gateway de API, equilibradores de carga, etc.
Los servicios gestionados, como API Gateway, tienen su disponibilidad gestionada dentro de una región. Puede configurar equilibradores de carga para garantizar la coordinación entre las zonas de disponibilidad.
- Kubernetes
- Costo
Cuanto mayor sea la disponibilidad y la resiliencia necesarias, mayor será el costo operativo. Esto se debe a que aumenta el volumen necesario de recursos informáticos redundantes. Tenga en cuenta qué implantación de GraphQL utilizará y qué restricciones de licencia, si las hay, y si la implantación está soportada por el proveedor.