Distribuzione più rapida dei dati grazie ad Azure, API Web e Redis

Da Johnny Webb | Dicembre 2015

Nel reparto di marketing di oggi worldof in tempo reale, il cerchio di rotazione della morte che accompagna troppo spesso in attesa di una pagina di carico o una query di ricerca per popolare piuttosto letteralmente può comportare l'interruzione di una vendita. Come più record di dati vengono creati, archiviati e analizzati, la generazione di RTF, informazioni approfondite sui dati in tempo reale diventa sempre più difficile. La domanda da porsi come scegliere gli strumenti di tecnologie e architetture migliore vagliare milioni di record di dati e fornire risultati istantanei per una migliore esperienza del cliente.

In questo articolo verrà illustrato un caso di utilizzo recente in cui abbiamo illustrato un client di implementare Redis e API Web. Viene spiegato l'approccio di implementazione, nonché i problemi che si sono verificati e come sono state raggiunte in definitiva i requisiti di prestazioni.

Problema aziendale

Alcuni mesi fa, un'organizzazione di servizi finanziari e assicurazioni Fortune 100 diversificata affrontato matasse Harte, una società di marketing globale, un'iniziativa di nuovo. La società desidera fornire un'esperienza migliore e più completa del cliente durante il processo di offerte di assicurazione in linea. A tale scopo, è necessario per abilitare l'accesso rapido e dinamico di dati dei criteri del cliente.

L'obiettivo era di consentire ai clienti di visualizzare e selezionare uno o più polizze assicurative tramite applicazioni self-service o con agente di connessione Internet. In definitiva, questo porterebbe a maggiore valore aziendale, maggiore soddisfazione del cliente, la velocità di offerta per l'associazione e un processo di avviamento agente migliorata. Per semplificare una realtà, durante il processo di offerta dettagli archiviati e i dati dei clienti necessari per l'elaborazione, trovare una corrispondenza e fornito in modo proattivo, in modo quasi istantaneo.

Database del client contiene più di 50 milioni di record, che significava con qualsiasi database tradizionale in genere una richiesta di questa natura richiederebbe più secondi per caricare. Abbiamo stavamo il compito di fornire un servizio Web in grado di eseguire query sull'origine dati di grandi dimensioni e la distribuzione di risultati ai consumer in millisecondi.

Per questa attività, viene valutata l'implementazione di Redis e API Web. Sono stati i fattori di misurazione generale:

Richieste di transazione
Richieste di oggetti
Risposte al secondo
Larghezza di banda totale dei dati
Velocità effettiva totale del sito

Implementazione: Come abbiamo

Creazione di un servizio Web per esporre i dati sono necessari più livelli dei componenti funzionalità specifiche. Man mano che aumenta la richiesta per il servizio Web, l'infrastruttura di supporto di questi livelli deve adattare e scalare rapidamente. E anche se è essenziale scalabilità, disponibilità è altrettanto importante e deve essere considerata sempre per garantire il buon consumer. Inoltre, gli endpoint esposti devono essere monitorati ed eseguito il wrapping con protocolli di autenticazione specifici per i dati protetti e recapitati in modo sicuro con prestazioni massime. Per soddisfare questi requisiti per la soluzione, abbiamo utilizzato Microsoft Azure. All'interno di Azure, è stato distribuito una combinazione di risorse tra le macchine virtuali, applicazioni Web, le reti virtuali, gruppi di risorse e gruppi di disponibilità per creare una soluzione completamente funzionale e di alta qualità.

Il livello dati

Poiché la maggior parte delle nostre soluzioni sono state create mediante lo stack di Microsoft, è consigliabile che la maggior parte dei casi è utilizzare Microsoft SQL Server. Tuttavia, i requisiti del contratto di servizio per questa soluzione specificato un tempo di risposta del servizio di minore di 1 secondo per ogni richiesta, con una frequenza di circa 6.000 richieste all'ora, un set di dati con più di 50 milioni di record. Poiché i database tradizionali come SQL Server archiviano i dati su disco e un collo di bottiglia da IOPS, Microsoft non garantisce che ogni query passa tale requisito. Per complicare ulteriormente la questione, il subset di dati che è necessario esporre già appartiene a un database tradizionale contenente terabyte di dati non correlati. Per questo motivo, abbiamo iniziato la valutazione delle soluzioni che possono supportare grandi set di dati rapidamente. Ovvero quando abbiamo scoperto Redis.

Redis è un archivio di struttura di dati in memoria che supporta più tipi di dati. I requisiti essenziali server includono una distribuzione Linux, quantità di RAM sufficiente per incapsulare i dati e spazio su disco sufficiente per la persistenza dei dati. Redis può essere configurato anche come un cluster, ma questo è più adatto per le soluzioni con terabyte di dati. Poiché il set di dati è minore di 50GB, abbiamo deciso di semplicità e impostare una configurazione singola master/slave. Per ospitare questa configurazione, abbiamo creato due macchine virtuali CentOS 7.1 all'interno di una rete virtuale in Azure. Ogni macchina virtuale contenuti 56GB di memoria, un indirizzo IP statico e un endpoint SSH con la crittografia AES256. Poiché entrambe le macchine virtuali condivise di un set di disponibilità, Azure fornito un contratto di servizio garantisce tempi di attività il 99,95%. Come bonus aggiuntivo, tutte le risorse che sono stati creati sono stati aggiunti a un gruppo di risorse creato appositamente per questa soluzione, che consente di monitorare e gestire la fatturazione su base mensile. Entro pochi minuti, il nostro macchine virtuali sono stati distribuiti e disponibili.

I nostri server Redis in piedi era semplice ed effettuata anche all'interno di un'ora. Dopo aver scaricato e installare la versione stabile più recente nei nostri server appena creato, in primo luogo è modificato il file di configurazione per consentire a ciò che Redis definisce la persistenza di file di solo accodamento (12X12). In breve, ciò significa che ogni comando inviato per l'istanza viene archiviata su disco. Se riavviare il server, tutti i comandi vengono eseguiti nuovamente, il ripristino allo stato originale. Per eliminare un 12X12 troppo grandi, un comando BGREWRITEAOF viene attivato in alcuni casi, riscrivere il file con il più breve sequenza di comandi necessari per ricreare il set di dati corrente in memoria. Inoltre, abbiamo configurato un utilizzo della memoria massima di 50GB, creazione di un buffer e impedendo l'utilizzo di tutta la memoria di sistema se è stati caricati una quantità eccessiva di dati Redis. Con tali presupposti, la nostra soluzione non necessaria più memoria, è facilmente possibile ridimensionare la macchina virtuale tramite il portale di Azure e aggiornare la configurazione in un secondo momento. Successivamente, abbiamo configurato l'istanza slave per riconoscere il server master, la creazione di replica dei dati. Se l'istanza master è diventato disponibile, l'istanza slave sarà pronto per servire i client. Infine, viene riavviato il nostro server Redis per le configurazioni per rendere effettive. Di seguito sono riportate le configurazioni che sono stati usati:

appendonly yes
maxmemory 50000000000
slaveof 10.0.0.x 6379
# cluster-enabled no

Caricamento di dati e benchmark

I dati che è stato necessario Redis vengono caricati dal database tradizionale contenuti circa 4GB di metadati customer. Questi metadati è stato aggiornato ogni giorno, pertanto è necessario creare un processo per trasformarlo in un tipo di dati Redis e il caricamento bulk per mantenere la soluzione corrente. Per eseguire questa applicazione, abbiamo creato un processo automatizzato per estrarre il set di modifiche giornaliere nei file di formato di protocollo Redis e trasferiti al server master utilizzando l'endpoint SSH disponibile. All'interno dell'istanza master, viene creato uno script bash per eseguire il caricamento bulk i file utilizzando la modalità pipe. Per evidenziare, modalità pipe è un elemento chiave della nostra soluzione, siamo in grado di caricare 28 milioni di record entro 5 minuti. Si noti, tuttavia, tale modalità pipe non è ancora compatibile con un'implementazione di cluster. Durante la fase iniziale di creazione di prototipi, abbiamo scoperto che il caricamento di 28 milioni di record in un cluster ci sarebbero volute perché i record sono stati trasferiti singolarmente. Questo è un fattore significativo della nostra decisione di mantenere la progettazione di un'implementazione semplice master/slave. Il comando di modalità di pipe e risposta per una singola istanza è simile al seguente:

$ cat data.txt | redis-cli –pipe
All data transferred. Waiting for the last reply...
Last reply received from server.
errors: 0, replies: 1000000

Dopo la modalità pipe è stata eseguita, la risposta è indicato il numero di errori e le risposte ricevute. Abbiamo analizzato la risposta all'interno dello script, archiviato il file e inviata una notifica tramite posta elettronica ai team di documentazione tecnica appropriata. Per ciascun errore, i tecnici Impossibile valutare l'estrazione e identificare rapidamente i dati che devono essere ricaricati. Dopo il completamento dello script di elaborazione giornaliera, è registrato la nostra implementazione utilizzando l'utilità di benchmark di Redis. Figura 1 Mostra i risultati delle prestazioni della soluzione di reassuring noi da poter soddisfare i requisiti del contratto di servizio.

Figura 1 il Benchmark Redis

Livello servizio

È fondamentale che il client sia l'unico consumer della nostra soluzione. Per fortuna, Azure semplifica questa attività con il servizio di controllo di accesso, che consente di creare un provider OAuth in modo specifico per la soluzione. Una volta implementata, i servizi necessari un token specifico per ogni richiesta, con un nuovo token rigenerate dopo 5 minuti. Si ricordi, il token deve essere mantenuto sempre prima della scadenza. Richiedere un nuovo token per ogni chiamata al servizio sarebbe essenzialmente creare colli di bottiglia della soluzione o, ancora peggio, renderlo inaccessibile se si supera il limite di richiesta specificato da Azure. È consigliabile che chiunque sfruttando questa funzionalità, leggere la documentazione di Azure prima di implementarli in un ambiente di produzione.

Sono disponibili più client c# Redis, ma sono stati usati Stackexchange perché abbiamo ritenuto che fosse più diffusi e matura. Perché tutti i dati archiviati nel set, abbiamo utilizzato il comando comandi LRANGE per eseguire query sui dati. Per impedire la riconnessione per ogni query, la connessione utilizzata per lo Stackexchange è stata gestita in un criterio singleton. Nell'esempio riportato in Figura 2 illustra come è recuperare dati.

Figura 2 la connessione a Redis e il recupero dei dati

private static Lazy<ConnectionMultiplexer> lazyConnection =
  new Lazy<ConnectionMultiplexer>(() => {
  return ConnectionMultiplexer.Connect(
    ConfigurationManager.AppSettings[Constants.AppSettings.RedisConnection]);
});
public static ConnectionMultiplexer Connection
{
  get
  {
    return lazyConnection.Value;
  }
}
public async static Task<MemberResponse> MemberLookup(MemberRequest request)
{
  MemberResponse response = new MemberResponse();
  try
  {
    if (request != null && request.customer != null && request.customer.Count() > 0)
    {
      foreach (var customer in request.customer)
      {
        Customer c = customer;
        RedisKey key = GetLookupKey(c);
        IDatabase db = Connection.GetDatabase();
        c.policies = await db.ListRangeAsync(key, 0, -1, CommandFlags.None);
        response.customer.Add(c);
      }
      response.success = true;
    }
    else
    {
      response.exceptions = new List<ServiceException>();
      response.exceptions.Add(Classes.ErrorCodes.Code_101_CustomerRequired);
      response.success = false;
        }
  }
  catch (Exception ex)
  {
    response.exceptions = new List<ServiceException>();
    response.exceptions.Add(Classes.ErrorCodes.Code_100_InternalError);
    response.success = false;
    Logging.LogException(ex);
  }
  response.executedOn =
    Utils.FormatEST(DateTime.UtcNow).ToString(Constants.DateTimeFormat);
  return response;
}

Per ospitare la soluzione in Azure, viene creato un sito Web. Per ottenere prestazioni ottimali, è stato critico che è stato distribuito l'applicazione Web stessa area le istanze di Redis. Dopo l'applicazione è stata distribuita, abbiamo creato una connessione di rete virtuale per la rete virtuale di Redis, consentendo al servizio ottenere l'accesso diretto ai dati. Viene illustrata questa connessione Figura 3.

Connessione di integrazione di reti VIRTUALI nella figura 3

Questa applicazione Web è stata configurata per la scalabilità a 10 istanze in base all'utilizzo della CPU. Poiché il traffico per la nostra soluzione diverse, l'applicazione Web di scalabilità in base alle esigenze. Un ulteriore livello di sicurezza, un certificato SSL è stato applicato all'app, insieme a filtro in modo specifico per il client IP. Sebbene l'app è stato configurato per applicare la scalabilità automatica, non il failover automatico. Per ottimizzare la disponibilità della soluzione per il client, viene creato un clone dell'app Web principale, tuttavia l'inserimento in un'area diversa. Entrambe le app sono state aggiunte a una gestione traffico di Azure, che abbiamo utilizzato per il failover automatico.

Infine, abbiamo acquistato un dominio personalizzato e creato un record CNAME che punta al nostro URL di gestione traffico, completare la nostra implementazione. Per monitorare le prestazioni della nostra soluzione giornaliera, abbiamo acquistato un'istanza di New Relic direttamente da Azure marketplace. Dall'utilizzo di New Relic, è possibile identificare rapidamente le aree necessarie analisi utilizzo software, nonché la disponibilità del server.

Avvolgendo

Per distribuire questa soluzione in Azure, si è appreso a rendere gli stack di tecnologia diversi interagiscono rapidamente per fornire una soluzione potente e ha esito positivo. Sebbene la distribuzione di una soluzione in Azure non elimini manutenzione del server, se si seguono i modelli sul posto, si avrà esito positivo. A seconda della durata media delle soluzioni, è possibile salvare sui costi hardware spostando tutte le soluzioni nel cloud.

Al termine dell'implementazione, il tempo di risposta medio: 25 millisecondi per 50 utenti simultanei. In base a questi risultati, il tempo di risposta viene estesa all'incirca 10 millisecondi per 15 utenti simultanei aggiunti.

Sean Iannuzzi è di tecnologia per matasse Harte e lavora nel settore tecnologico per oltre 20 anni, la riproduzione di un ruolo fondamentale per colmare il divario tra visioni tecnologiche e aziendali per una vasta gamma di social networking, Big Data, le soluzioni di database, il cloud computing, e-commerce e applicazioni finanziarie di oggi. Iannuzzi ha esperienza con più di 50 piattaforme straordinaria tecnologia, ha raggiunto i riconoscimenti/certificazioni tecniche oltre una dozzina e specializzata in piedi indicazioni tecnologiche e soluzioni per raggiungere gli obiettivi aziendali.

Johnny Webb è un progettista software per Harte matasse e ha implementato soluzioni di alta qualità utilizzando tecnologie all'avanguardia per i client noti per negli ultimi 10 anni. Il suo esperienza include il ciclo di vita di sviluppo software completa, come Microsoft .NET Framework, l'architettura software, il cloud computing, lo sviluppo Web, sviluppo per dispositivi mobili, API database di sviluppo, database SQL e NoSQL.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Eric grigie (Liquidhub)
Eric Riddle è un responsabile tecnico per liquidi Hub in Philadelphia. Egli è stato lo sviluppo e progettazione di soluzioni con .NET Framework fin dal principio. Il suo esperienza include lo sviluppo web front-end, l'API REST, WCF, servizi di Windows e SQL Server. Ha accumulato esperienza approfondita di servizi finanziari e settore marketing diretto.