1. Distribuire un microservizio in Kubernetes per elaborare i messaggi dalla coda OCI
  2. Informazioni sulla scala dei consumer di code OCI in Kubernetes

Informazioni sulla scala dei consumer di code OCI in Kubernetes

Questa guida illustra come utilizzare le funzioni della coda Oracle Cloud Infrastructure (OCI) e fornisce una ricetta che si adatta alla maggior parte dei casi d'uso che richiedono un ridimensionamento dinamico, in base alla quantità di richieste del cliente, senza dover affrontare problemi di retropressione o strozzatura delle prestazioni.

È possibile distribuire un microservizio in Oracle Kubernetes Engine (OKE), che elabora i messaggi da una coda OCI, quindi approfitta della profondità della coda per ridimensionare orizzontalmente le istanze di microservizi in esecuzione su un cluster OKE. L'esempio include un generatore di messaggi che è possibile eseguire da qualsiasi posizione, ad esempio dal computer locale o come parte di un altro contenitore o VM.

Questa guida fornisce inoltre istruzioni di impostazione dettagliate e di codice, disponibili nel repository Oracle-DevRel GitHub, oci-arch-queue-oke-demo (a cui è possibile accedere dalla sezione Esplora altro di questa guida). Questa soluzione fornisce tutto il codice Java, gli script e i file di configurazione, insieme a procedure dettagliate per la creazione, la distribuzione e l'esecuzione dei componenti di base. Questo documento fornisce una vista architettonica ed esamina gli elementi chiave dell'implementazione, tra cui l'identificazione delle parti del codice che dovrai modificare per adattare la soluzione alle tue esigenze.

Informazioni sulle interfacce API di coda OCI

Soluzioni molto raramente affrontano singoli processi; la comunicazione tra applicazioni spesso deve essere asincrona per evitare di limitare la soluzione con la parte più limitante di una soluzione (ad esempio, che richiede CPU, latenza e così via). È possibile superare questi problemi stabilendo una comunicazione in cui i produttori e i consumatori non dipendono l'uno dall'altro. Questo è ciò che la coda OCI supporta a prestazioni molto elevate.

Mentre la coda può ammortizzare le applicazioni dalle fluttuazioni della domanda, quando gli utenti sono coinvolti, non si desidera passare molto tempo tra la creazione dei messaggi e l'elaborazione dei messaggi. Pertanto, il back-end deve essere in grado di scalare dinamicamente, in base alla richiesta. Tale domanda è determinata dal numero di messaggi che si trovano nella coda; più messaggi significa più domanda e quindi più sforzo di calcolo necessario. Al contrario, una coda vuota non rappresenta alcuna richiesta e richiede pertanto un numero minimo di risorse backend. Il ridimensionamento dinamico si riferisce a queste variazioni costanti.

Architettura

Questa architettura richiede una coda per i messaggi che risiedono al di fuori dei nostri domini di errore visibili in quanto si tratta di un servizio completamente gestito.

All'interno di OCI, puoi eseguire Kubernetes con nodi gestiti dal client o con nodi gestiti da Oracle. Questo scenario utilizza l'approccio meno recente dei nodi client, pertanto sono necessari nodi di calcolo collegati al cluster. Questi nodi sono distribuiti meglio nei domini di errore, all'interno di una zona di disponibilità.

Nota:

In questo playbook, la generazione della domanda proviene dal tuo computer locale e, quindi, al di fuori dell'ambiente OCI.

Gli ultimi due elementi chiave controllano la scalabilità. In primo luogo, una funzione OCI viene richiamata periodicamente e recupera i dettagli della profondità della coda. Per astrarre la profondità di coda, viene utilizzato un gateway API che agevola la chiamata delle funzioni OCI.

Infine, abbiamo bisogno di servizi ausiliari, come Vault, per memorizzare le credenziali per accedere alla coda, il monitoraggio per l'osservazione sanitaria generale e così via.


Segue la descrizione di Queue-scaling-oke-arch.png
Descrizione dell'illustrazione Queue-scaling-oke-arch.png

code-scaling-oke-arch-oracle.zip

I numeri nel diagramma precedente rappresentano questa sequenza di eventi:
  1. Il producer ospitato localmente inserisce i messaggi nella coda OCI.
  2. Le istanze di consumer OCI recuperano i messaggi dalla coda. All'interno del codice, il tasso di consumo è vincolato utilizzando un ritardo. Ciò garantisce che il provider generi più messaggi che un singolo consumer può rimuovere dalla coda. Di conseguenza, i meccanismi di ridimensionamento funzioneranno.
  3. Periodicamente, un job pianificato Kubernetes supporterà KEDA per richiamare l'API pubblicata per ottenere il numero di messaggi nella coda.
  4. Il gateway API indirizza la richiesta a un'istanza della funzione OCI.
  5. La funzione OCI interroga la coda OCI.
  6. Viene restituita la risposta, che comporterà l'attivazione di un aumento o una riduzione delle istanze del microservizio.
Inoltre, (a) questa implementazione consente all'utente di interrogare in qualsiasi momento lo stato della profondità della coda.
Questa architettura contiene i componenti elencati di seguito.
  • Area

    Un'area OCI è un'area geografica localizzata che contiene uno o più data center, definiti domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (in tutti i paesi o anche in continenti).

  • Domini di disponibilità

    I domini di disponibilità sono data center standalone indipendenti all'interno di un'area geografica. Le risorse fisiche in ciascun dominio di disponibilità sono isolate dalle risorse presenti negli altri domini di disponibilità, che offrono tolleranza agli errori. I domini di disponibilità non condividono servizi dell'infrastruttura quali alimentazione, raffreddamento o rete interna del dominio di disponibilità. È pertanto improbabile che l'eventuale guasto di un dominio di disponibilità influenzi gli altri domini di disponibilità nell'area.

  • domini di errore

    Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità dispone di tre domini di errore con alimentazione e hardware indipendenti. Quando distribuisci risorse su più domini di errore, le tue applicazioni possono tollerare errori fisici del server, manutenzione del sistema e errori di alimentazione all'interno di un dominio di errore.

  • Compartimento

    I compartimenti sono partizioni logiche tra più aree all'interno di una tenancy OCI. Utilizza i compartimenti per organizzare le risorse in Oracle Cloud, controllare l'accesso alle risorse e impostare le quote di utilizzo. Per controllare l'accesso alle risorse in ogni compartimento, definisci i criteri che specificano chi può accedere alle risorse e quali azioni può eseguire.

  • Rete cloud virtuale (VCN) e subnet

    Una VCN è una rete personalizzabile definita dal software impostata in un'area OCI. Analogamente alle reti di data center tradizionali, i VCN offrono il controllo completo sull'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che puoi modificare dopo aver creato la VCN. Puoi segmentare una VCN nelle subnet che possono essere definite nell'area o in un dominio di disponibilità. Ogni subnet è composta da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. Puoi modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.

  • Istanze di computazione

    OCI Compute ti consente di eseguire il provisioning e gestire gli host di computazione. Puoi avviare le istanze di computazione con forme che soddisfano i requisiti delle risorse (CPU, memoria, larghezza di banda della rete e storage). Dopo aver creato un'istanza di computazione, puoi accedere a tale istanza in modo sicuro, riavviarla, collegare e scollegare volumi e terminarla quando non ne hai bisogno.

  • Funzioni

    Oracle Functions è una piattaforma completamente gestita, multi-tenant, altamente scalabile, su richiesta e Functions-as-a-Service (FaaS). Si basa sul motore open source di Fn Project. Le funzioni consentono di distribuire il codice e di chiamarlo direttamente o attivarlo in risposta agli eventi. Oracle Functions utilizza i container Docker ospitati nel registro OCI.

  • Registro contenitore

    Il registro OCI è un registro gestito da Oracle che consente di semplificare il flusso di lavoro dallo sviluppo alla produzione. Il registro semplifica la memorizzazione, la condivisione e la gestione degli artifact di sviluppo, ad esempio le immagini Docker. L'architettura altamente disponibile e scalabile di OCI garantisce la possibilità di distribuire e gestire le applicazioni in modo affidabile.

  • Container Engine per Kubernetes

    OCI Container Engine for Kubernetes è un servizio completamente gestito, scalabile e ad alta disponibilità che puoi utilizzare per distribuire le tue applicazioni gestite in container nel cloud. Puoi specificare le risorse di computazione richieste dalle tue applicazioni, mentre Container Engine for Kubernetes le esegue sul servizio OCI in una tenancy esistente. Container Engine for Kubernetes utilizza Kubernetes per automatizzare la distribuzione, il ridimensionamento e la gestione delle applicazioni in container su cluster di host.

  • Gateway API

    Oracle API Gateway consente di pubblicare le API con gli endpoint per gestire la visibilità di funzionalità quali Funzioni, Microservizi e altre interfacce applicative. Gli endpoint forniscono controlli di sicurezza dettagliati per le soluzioni backend e spiegano in che modo un'API potrebbe essere implementata.

  • Coda

    Queue è un meccanismo di comunicazione asincrona altamente scalabile serverless. È ideale per abilitare il disaccoppiamento dei servizi e la consegna dei messaggi.

Considerazioni

Quando si distribuisce un microservizio in Kubernetes per elaborare i messaggi dalla coda OCI, è necessario considerare quanto riportato di seguito.

  • Considerazioni sui criteri per le code

    I criteri per il controllo e la configurazione delle code e dei criteri OCI per la creazione e l'utilizzo dei messaggi sono separati. In questo modo, avrai il controllo dettagliato sulle operazioni disponibili tramite le API. Ciò significa che devi tenere in considerazione i requisiti e le esigenze di sicurezza della tua applicazione. Per la produzione, si consigliano controlli rigorosi; questa implementazione utilizza impostazioni di configurazione rilassate, che riducono al minimo la possibilità di un errore di configurazione che impedisce il funzionamento della demo.

  • Considerazioni per i limiti di scala di Kubernetes

    La frequenza e i limiti alla scalabilità del backend devono essere considerati. È necessario risolvere i fattori, ad esempio l'approfondimento della coda prima che vengano avviate istanze aggiuntive del microservizio. Il numero massimo di istanze aggiuntive di un microservizio dovrebbe essere in esecuzione. Anche se si sarebbe tentati di non legare questo, nel mondo reale, termini pratici, se qualcuno (liberatamente o accidentalmente) inizia a inondare la tua coda con messaggi errati, non si desidera assorbire i costi della potenza di calcolo aggiuntiva necessaria per scappare. Inoltre, devi valutare la velocità con cui attivi le istanze aggiuntive del microservizio. Scorri troppo rapidamente e troverai il tuo ambiente in costante avvio e arresto dei servizi. Indipendentemente dall'efficienza del microservizio, ci sarà sempre un costo indiretto per l'avvio e l'arresto delle istanze di servizio che alla fine costa.

  • Considerazioni per il controllo di scala

    L'ultimo aspetto del controllo della scala è se si desidera applicare la scala e come controllarla. Questo scenario utilizza un progetto CNCF denominato KEDA (Kubernetes Event Driven Autoscaler). Oltre alla modalità di esecuzione del ridimensionamento del backend, devi prendere in considerazione la modalità di richiamo dell'API. In questo caso, è possibile configurare un job pianificato Kubernetes (in quanto il job viene eseguito da un nodo di lavoro che il diagramma riflette questo flusso) per richiamare l'API.

Prerequisiti

Prima di iniziare, è necessario preparare l'ambiente rispondendo ai prerequisiti descritti in questa sezione.

  • Per la generazione dei messaggi, è necessario disporre di Java 8 o versione successiva (Java 8 installato insieme ad Apache Maven).
  • L'interazione con la coda OCI richiederà utenti e credenziali associate per consentire l'accesso. Impostare i seguenti criteri:
    • Impostare questo criterio per identificare il compartimento che verrà utilizzato (compartment-name): 
      allow any-user to manage queues in compartment compartment-name
    • Per limitare gli utenti alla sola lettura o scrittura nella coda OCI, creare gruppi OCI denominati MessageConsumers e MessageProducers e allocare gli utenti appropriati a questi gruppi. Utilizzare i criteri seguenti: 
      allow group MessageConsumers to use queues in compartment compartment-name 
allow group MessageProducers to use queues in compartment compartment-name
    • Fornire al client producer gli attributi di configurazione OCI standard in modo che possa eseguire l'autenticazione con OCI e utilizzare l'API.
    • È necessario impostare criteri per supportare il comportamento dinamico perché nuove risorse verranno e andranno e avranno bisogno dell'accesso alla coda. Imposta questi criteri creando un gruppo dinamico con le risorse che dovrai controllare in modo elastico. Poiché questo controllo si verifica all'interno di OCI, utilizzare un principal istanza. Chiama questo gruppo queue_dg. Utilizzare le seguenti istruzioni criterio: 
      ALL {instance.compartment.id='instance Compartment id (OCID)'} 
allow dynamic-group queue_dg to use queues in compartment queue_parent_compartment
      Dove instance Compartment id (OCID) è il compartimento contenente i nodi di lavoro.

Informazioni sull'SDK Java

I tre codici (produttore, consumatore e funzione) utilizzano tutte le API OCI. Il modo più semplice per interagire con le API è tramite l'SDK Java. Gli SDK forniti da OCI forniscono una serie di funzioni convincenti che recuperano le informazioni necessarie per autenticare e autorizzare i richiami dei servizi OCI. Gli SDK adottano la variante del pattern del Builder di Joshua Bloch. Puoi trovare ulteriori informazioni sull'SDK in Java SDK. Il repository Oracle DevRel GitHub contiene altri esempi degli SDK utilizzati qui, ad esempio, all'indirizzo https://github.com/oracle-devrel/oci-arch-queue-demo.