Implantar uma Solução GraphQL Altamente Escalável
Esta Arquitetura de Referência demonstra como você pode implantar uma solução baseada em GraphQL que pode ser facilmente dimensionada para atender à demanda da carga de trabalho.
GraphQL, uma linguagem de manipulação e consulta de dados de código-fonte aberto para APIs e um runtime para atender consultas com dados existentes, é um componente ideal para implementações como aplicativos móveis que definem explicitamente os atributos necessários. Ele fornece APIs nas quais um cliente pode solicitar dados entre entidades relacionadas para otimizar o fluxo de solicitações e respostas, por exemplo, minimizando o tráfego de rede móvel para aplicativos móveis. O GraphQL também oferece um meio eficaz de ajudar os consumidores de API a abstrair como as soluções de back-end podem ser implementadas fornecendo um único esquema que pode abranger muitos serviços de back-end diferentes.
Arquitetura
Essa arquitetura define rotas diferentes para conteúdo de API estático e dinâmico. Essa abordagem facilita a otimização do acesso ao conteúdo estático configurando opções de armazenamento em cache em várias camadas, inclusive usando uma Rede de Entrega de Conteúdo (CDN), no balanceador de carga e nos serviços de back-end que carregam e atendem ao conteúdo.
Os serviços de back-end são implementados com microsserviços nesta arquitetura. Esses serviços também podem implantar uma solução CMS, como o Oracle Content and Experience, por meio de opções de CMS de código-fonte aberto. Como o conteúdo é estático, os riscos de segurança são consideravelmente menores.
O conteúdo da API é roteado por meio de um gateway de API para que as solicitações de API possam ser validadas e controladas (por exemplo, taxa limitada). O tráfego é, em seguida, enviado para o balanceador de carga do Oracle Kubernetes Engine, o ponto de entrada no cluster, que o direciona para um servidor GraphQL. Idealmente, se microsserviços forem usados para atender ao conteúdo estático, os serviços que suportam GraphQL e o conteúdo estático serão mantidos em namespaces separados para maior isolamento e controle.
Esta implementação adota o servidor Apollo GraphQL de código aberto para receber as invocações e decompor o trabalho para separar microsserviços que hospedam a lógica do resolvedor e do mutador. Você pode escalar a implementação de maneira mais eficiente implementando os diferentes subdomínios dentro do modelo de dados usando serviços separados. Portanto, é mais fácil ajustar a solução com qualquer cache in-memory.
O diagrama a seguir ilustra essa arquitetura de referência.
Descrição da ilustração implant-hs-graphql.png
O código e a documentação para implementar a arquitetura, incluindo serviços de exemplo, podem ser encontrados no repositório relevante do GitHub (consulte o tópico Implantar, abaixo). A rota API usa um Apollo GraphQL Server e serviços Python para cada subdomínio. Mais detalhes estão incluídos na documentação do GitHub fornecida.
- Locação
Uma Tenancy abrange todas as regiões que estão sendo usadas. Para obter desempenho e resiliência maximizadas, você deseja replicar a implantação em várias regiões diferentes do mundo e combinar o roteamento DNS público para que os clientes vão para a região mais próxima a fim de minimizar a latência. Isso exigiria a replicação dos dados de backend entre as regiões.
- Região
Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominados domínios de disponibilidade. As regiões são independentes das outras regiões, e grandes distâncias podem se separar (em países ou até mesmo continentes).
- Compartimento
Os compartimentos são partições lógicas entre regiões em uma tenancy do Oracle Cloud Infrastructure. Use compartimentos para organizar seus recursos no Oracle Cloud, controlar o acesso aos recursos e definir cotas de uso. Para controlar o acesso aos recursos em um determinado compartimento, você define políticas que especificam quem pode acessar os recursos e quais ações eles podem executar. Os controles de compartimento para essa arquitetura podem ser adicionados para separar a camada de acesso público e o back-end para minimizar o risco de criar acidentalmente caminhos diretos para a camada de segurança.
- Domínios de disponibilidade
Os domínios de disponibilidade são data centers independentes e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, que oferecem tolerância a falhas. Os domínios de disponibilidade não compartilham infraestruturas, como energia ou refrigeração, ou a rede de domínio de disponibilidade interna. Portanto, é pouco provável que uma falha em um domínio de disponibilidade afete os outros domínios Nesta arquitetura de referência, os nós de trabalho do Kubernetes são distribuídos entre domínios de falha e domínios de disponibilidade para garantir máxima resiliência.
- Domínios de falha
Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre diversos domínios de falha, seus aplicativos podem tolerar falha física do servidor, manutenção do sistema e falhas de alimentação dentro de um domínio de falha.
- Rede virtual na nuvem (VCN) e sub-redes
Uma VCN é uma rede personalizada e definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes de data center tradicionais, as VCNs dão a você total controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, que podem ter escopo em uma região ou em um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contínuo de endereços que não se sobrepõem às outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.
- Balanceador de carga
O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores no back-end. Nesta arquitetura de referência, o balanceador de carga incluirá políticas de roteamento para separar o tráfego direcionado ao gateway de API para dados dinâmicos e o conteúdo estático (por exemplo, imagens, páginas Web etc.). Isso pode explorar os recursos WAA (Web Application Acceleration) do Balanceador de Carga.
- Lista de segurança
Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.
- gateway NAT
O gateway NAT permite que recursos privados em uma VCN acessem hosts na internet, sem expor esses recursos a conexões de internet recebidas.
- Gateway de serviço
O gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle percorre a malha da rede Oracle e nunca atravessa a internet.
- Cloud Guard
Você pode usar o Oracle Cloud Guard para monitorar e manter a segurança dos seus recursos no Oracle Cloud Infrastructure. O Cloud Guard usa receitas do detector que você pode definir para examinar seus recursos em busca de falhas de segurança e monitorar operadores e usuários em busca de atividades de risco. Quando qualquer configuração incorreta ou atividade não segura é detectada, o Cloud Guard recomenda ações corretivas e ajuda a executar essas ações, com base nas receitas do respondedor que você pode definir.
- Zona de segurança
As zonas de segurança garantem as melhores práticas de segurança da Oracle desde o início, impondo políticas como a criptografia de dados e a prevenção do acesso público a redes para um compartimento inteiro. Uma zona de segurança está associada a um compartimento com o mesmo nome e inclui políticas de zona de segurança ou uma "receita" que se aplica ao compartimento e seus subcompartimentos. Não é possível adicionar ou mover um compartimento padrão para um compartimento de zona de segurança.
- Autonomous Database
Os bancos de dados autônomos do Oracle Cloud Infrastructure são ambientes de banco de dados totalmente gerenciados e pré-configurados que você pode usar para cargas de trabalho de processamento de transações e data warehousing. Não é necessário configurar ou gerenciar qualquer hardware ou instalar qualquer software. O Oracle Cloud Infrastructure trata da criação do banco de dados, bem como do backup, da aplicação de patches, do upgrade e do ajuste do banco de dados.
- Container Engine for Kubernetes
O Oracle Cloud Infrastructure Container Engine for Kubernetes é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos de contêineres na nuvem. Você especifica os recursos de computação necessários para os seus aplicativos, e o Serviço Container Engine for Kubernetes as provisiona no Oracle Cloud Infrastructure em uma tenancy existente. O Serviço Container Engine for Kubernetes usa o Kubernetes para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos de contêineres em clusters de hosts. O cluster do Kubernetes terá nós alocados para diferentes zonas de vault e zonas de disponibilidade para maximizar a resiliência e a disponibilidade. O cluster do Kubernetes idealmente terá o Istio ou outro recurso do Service Mesh para gerenciar e monitorar os microsserviços. O serviço GraphQL existirá em seu próprio pod, com os vários resolvedores e mutadores implantados no cluster do Kubernetes como seus próprios microsserviços.
- Registro
O Oracle Cloud Infrastructure Registry é um registro gerenciado pela Oracle que permite simplificar seu workflow de desenvolvimento até a produção. O registro facilita o armazenamento, o compartilhamento e o gerenciamento de artefatos de desenvolvimento, como imagens do Docker. A arquitetura altamente disponível e escalável do Oracle Cloud Infrastructure garante que você possa implantar e gerenciar seus aplicativos de forma confiável.
Recomendações
- VCN
Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar às sub-redes na VCN. Use blocos CIDR que estão dentro do espaço de endereço IP privado padrão.
Selecione os blocos CIDR que não se sobrepõem a nenhuma outra rede (no Oracle Cloud Infrastructure, em seu data center local ou em outro provedor de nuvem) para a qual você pretende configurar conexões privadas.
Depois de criar uma VCN, você poderá alterar, adicionar e remover seus blocos CIDR.
Ao projetar as sub-redes, considere seu fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos dentro de uma camada ou atribuição específica à mesma sub-rede, que pode servir como limite de segurança.
- Segurança
Use o Oracle Cloud Guard para monitorar e manter a segurança dos seus recursos no Oracle Cloud Infrastructure de forma proativa. O Cloud Guard usa receitas do detector que você pode definir para examinar seus recursos em busca de falhas de segurança e monitorar operadores e usuários em busca de atividades de risco. Quando qualquer configuração incorreta ou atividade não segura é detectada, o Cloud Guard recomenda ações corretivas e ajuda a executar essas ações, com base nas receitas do respondedor que você pode definir. Para recursos que exigem segurança máxima, a Oracle recomenda que você use zonas de segurança. Uma zona de segurança é um compartimento associado a uma receita definida pela Oracle de políticas de segurança que se baseiam nas melhores práticas. Por exemplo, os recursos de uma zona de segurança não podem ser acessados pela internet pública e devem ser criptografados usando chaves gerenciadas pelo cliente. Quando você criar e atualizar recursos em uma zona de segurança, o Oracle Cloud Infrastructure validará as operações contra as políticas na receita de zona de segurança e negará operações que violem qualquer uma das políticas.
- Cloud Guard
Clone e personalize as receitas padrão fornecidas pela Oracle para criar receitas personalizadas do detector e do respondedor. Essas receitas permitem especificar que tipo de violações de segurança geram um aviso e quais ações podem ser executadas nelas. Por exemplo, talvez você queira detectar buckets do Object Storage que tenham visibilidade definida como pública. Aplique o Cloud Guard no nível da tenancy para abranger o escopo mais amplo e reduzir a carga administrativa de manter várias configurações. Você também pode usar o recurso Lista Gerenciada para aplicar determinadas configurações aos detectores.
- Grupos de Segurança de Rede (NSGs)
Você pode usar NSGs para definir um conjunto de regras de entrada e saída que se aplicam a VNICs específicas. Recomendamos o uso de NSGs em vez de listas de segurança porque os NSGs permitem que você separe a arquitetura da sub-rede da VCN dos requisitos de segurança do seu aplicativo.
Você pode usar NSGs para definir um conjunto de regras de entrada e saída que se aplicam a VNICs específicas. Recomendamos o uso de NSGs em vez de listas de segurança porque os NSGs permitem que você separe a arquitetura da sub-rede da VCN dos requisitos de segurança do seu aplicativo.
- Largura de banda do balanceador de carga
Ao criar o balanceador de carga, você pode selecionar uma forma predefinida que forneça uma largura de banda fixa ou especificar uma forma personalizada (flexível) na qual você define uma faixa de largura de banda e permite que o serviço dimensione a largura de banda automaticamente, com base nos padrões de tráfego. Com qualquer uma das abordagens, você pode alterar a configuração a qualquer momento após criar o balanceador de carga.
- API Gateway
O API Gateway pode ser usado para fornecer um nível inicial de rastreamento e controles de uso, como:
- Autenticação e Autorização de Serviço
- Controles de serviço, como limitação de taxa
- Captura de análise de uso de serviço
Considerações
Considere os seguintes pontos ao implantar essa arquitetura de referência.
- Desempenho
Essa arquitetura fornecerá um meio de desenvolver a capacidade de desempenho vertical e horizontal. Mesmo com os microsserviços mais otimizados, há um tempo de espera em novos nós, portanto, isso precisa ser permitido ao lidar com o dimensionamento manual ou dinamicamente. Isso será particularmente verdadeiro para a camada de persistência de qualquer solução.
- Segurança
Você deve tratar a segurança no nível do aplicativo no Gateway de API. No entanto, você pode tratar a segurança específica GraphQL refinada (por exemplo, acesso no nível do atributo) utilizando diretivas GraphQL, como
@auth. - Disponibilidade
- Kubernetes
Os domínios de falha fornecem resiliência dentro de um domínio de disponibilidade. Você pode configurar nós de trabalho do Kubernetes para implantação em diferentes zonas de disponibilidade.
- API Gateway, balanceadores de carga etc.
Os serviços gerenciados, como o Gateway de API, têm sua disponibilidade tratada dentro de uma região. Você pode configurar balanceadores de carga para garantir a coordenação entre zonas de disponibilidade.
- Kubernetes
- Custo
Quanto maior a disponibilidade e a resiliência necessárias, maior o custo operacional. Isso acontece porque o volume necessário de recursos de computação redundantes aumenta. Considere qual implementação do GraphQL você usará e quais, se houver, restrições de licenciamento serão impostas e se a implementação será suportada pelo provedor.