Campaign Classic: Raccomandazioni per il dimensionamento dell'hardware

Descrizione

Ambiente
Adobe Campaign Classic v7

Problema/Sintomi
Questo documento fornisce raccomandazioni generali per la distribuzione di Adobe Campaign Classic v7 nel centro dati on-premise o nell’ambiente cloud virtualizzato. Questo tipo di distribuzione, denominato ibrido o mid-sourcing, posiziona l’istanza di marketing Campaign e il database di marketing sotto il tuo controllo operativo, mentre utilizzi i servizi Adobe Cloud Messaging per inviare e-mail, messaggi SMS o SMPP e raccogliere i dati di tracciamento dei clic, le e-mail aperte, rimbalzate e i messaggi non recapitati.

Attenzione - Questo articolo è fornito solo come guida di esempio generale. È necessario interagire con il team dell’account di Adobe Campaign Adobe per misurare le dimensioni esatte della distribuzione prima di avviare il progetto Campaign. Non acquisire o distribuire alcuna infrastruttura o hardware fino a quando non viene fatto questo.

L’istanza di marketing è la parte dell’architettura di Adobe Campaign che guida tutte le attività di marketing e memorizza tutti i dati dei destinatari e i dati analitici restituiti dalle campagne. L’istanza di marketing è un set di server on-premise che eseguono i servizi Adobe Campaign e un database relazionale.

Attenzione - Le informazioni contenute in questo documento non si applicano se utilizzi un’istanza Adobe Campaign completamente ospitata (distribuita nei Cloud Services di Adobe).

La compatibilità del software è descritta in Matrice di compatibilità.
Scenari
I diagrammi di distribuzione e le raccomandazioni di dimensionamento dell'hardware sono forniti per tre scenari rappresentativi:

1. Dimensione moderata - 5 milioni di destinatari attivi nel sistema
2. Grandi dimensioni - 20 milioni di destinatari attivi nel sistema
3. Enterprise - 50 milioni di destinatari attivi, con messaggi transazionali

Ipotesi
Questo documento presuppone anche i seguenti tipi di utilizzo per tutti e tre gli scenari:

• Le campagne e-mail di grandi dimensioni vengono inviate due volte alla settimana a circa il 50% dei destinatari attivi.
• Gli invii diretti vengono generati una volta al mese per ogni destinatario nel sistema.
• I messaggi SMS vengono inviati a circa il 10% dei destinatari attivi ogni mese.
• Lo schema del database che definisce ogni destinatario è stato esteso con una tabella aggiuntiva, contenente circa 200 byte di dati per ciascun destinatario.
• Il modulo di interazione Adobe Campaign viene utilizzato per aggiungere offerte alle e-mail in uscita.
• I dati di tracciamento e-mail vengono conservati nel sistema Campaign per 90 giorni.

Risoluzione

Linee guida generali
Campaign è un’applicazione incentrata sul database e le prestazioni del server di database sono fondamentali. L’esecuzione di flussi di lavoro, segmentazione, caricamento di dati di tracciamento, interazioni in entrata, analisi e altre attività genera tutte attività di database. In generale, le dimensioni e la frequenza di queste operazioni determinano le dimensioni dei server di database.

I server applicazioni nella tua istanza di marketing richiedono CPU e memoria sufficienti per eseguire flussi di lavoro e rispondere alle chiamate API SOAP, comprese le richieste degli utenti della console Campaign. I requisiti della CPU possono essere significativi per i flussi di lavoro che utilizzano interazioni in uscita con regole di offerta complesse, flussi di lavoro che eseguono JavaScript personalizzato e applicazioni web con livelli di traffico elevati.

Le applicazioni web di Campaign possono essere distribuite anche sui server app dell’istanza di marketing o su sistemi server web separati. Poiché i carichi di lavoro delle applicazioni web sono in conflitto con i flussi di lavoro critici e gli utenti della console Campaign, le applicazioni web e le interazioni in entrata possono essere distribuite su server separati, per garantire che la funzionalità di base di Campaign sia eseguita in modo affidabile con buone prestazioni.

Per la sicurezza e la disponibilità, l'Adobe consiglia di separare il traffico di Internet dal traffico generato dagli utenti aziendali. Per questo motivo, i diagrammi contengono due gruppi di server: il server web (web-face Web1 e Web2) e i server app (business process App1 e App2).

È un requisito legale per i mittenti e-mail commerciali avere una pagina web di rinuncia funzionale. Adobe consiglia di disporre di un computer ridondante in ciascun server di gruppo per gli scenari di failover. È particolarmente vero se Adobe Campaign ospita le pagine di rinuncia.

 
Proxy inversi
L’architettura di Campaign garantisce un’elevata sicurezza utilizzando SSL su HTTP (HTTPS) per comunicare tra l’istanza di marketing e Adobe Cloud Messaging. Sicurezza, affidabilità e disponibilità vengono applicate utilizzando proxy inverso in una subnet "zona demilitarizzata" (DMZ) per isolare e proteggere i server e il database delle istanze di marketing.

 
Load balancer
Il load balancer per i server app è configurato in una configurazione attiva/passiva, con HTTPS terminato sul proxy. Il load balancer per i server Web è configurato in una configurazione attiva/attiva, con HTTPS terminato sul proxy.

Adobe fornisce l’elenco esclusivo dei percorsi URL che possono essere inoltrati al server Adobe Campaign nell’ambiente di distribuzione.

 
Architettura
L'architettura generale è quasi identica, indipendentemente dai volumi. I requisiti di sicurezza e di elevata disponibilità impongono un minimo di quattro server; due server se non vengono utilizzate webApps. La differenza nella configurazione varia principalmente nella configurazione dell'hardware come il core della CPU e la memoria.

Scenario 1: Distribuzione a dimensione moderata

Volume stimato

Per questi volumi, una coppia di sistemi server applicativi Adobe Campaign fornisce tutte le funzionalità per gli utenti client Adobe Campaign e l'esecuzione di un flusso di lavoro. Per 5 milioni di destinatari attivi e questo volume di e-mail, i carichi di lavoro del server applicazioni non richiedono un uso intensivo della CPU o dell’I/O; la maggior parte dello stress è nel database.

I server web Adobe Campaign vengono visualizzati nell’area protetta.

 
Server web e applicazioni
Questo scenario consiglia di installare Adobe Campaign su quattro computer, con le seguenti specifiche:

CPU quad-core da 3 Ghz+, 8 GB di RAM, RAID 1 o 10, 2 x 80 GB SSD

Questi sistemi creano l’istanza di marketing Application Server, che supporta direttamente gli utenti della console Campaign ed esegue i flussi di lavoro delle campagne.

Invertire i proxy in un traffico di bilanciamento del carico DMZ nei server Web Adobe Campaign. Non è necessario installare lo stack software Adobe Campaign su macchine proxy; è possibile utilizzare qualsiasi software reverse proxy o apparecchiatura di rete.

Le funzioni di opt-in/opt-out dell’abbonamento e del centro preferenze possono essere fornite da Campaign o dal tuo sito web. Se scegli di implementare questa funzionalità sul tuo sito web, assicurati che le informazioni sulle preferenze e sugli abbonamenti vengano propagate al database di marketing di Campaign. Normalmente viene eseguito creando file di estrazione che vengono caricati automaticamente dai flussi di lavoro Campaign.

Il consumo di spazio su disco su Application Server dipende dal periodo di conservazione dei file scambiati con fornitori di servizi di terze parti (ad esempio, fornitori di stampa per Direct Mail) e dalle dimensioni e dalla conservazione dei file flat importati, come gli aggiornamenti di abbonamento o preferenza dal tuo sito Web, o estratti dai tuoi sistemi CRM o di marketing.

 
Database
Le raccomandazioni hardware per il server di database sono le seguenti:

CPU a 4 core da 3 Ghz+, RAM da 16 GB, RAID 1 o 10, SSD da 128 GB minima

La stima della memoria presuppone il caching completo di circa 500.000 destinatari per un avvio di una campagna di grandi dimensioni, oltre allo spazio buffer RDBMS per l’esecuzione di flussi di lavoro, l’importazione di dati di tracciamento e altre attività simultanee.

Si stima che lo spazio su disco necessario nel database per memorizzare tutti i dati tecnici Adobe Campaign (campagne, tracciamento, tabelle di lavoro e così via) sia di circa 35 GB in base a un periodo di conservazione di tre mesi. Se scegli di conservare i dati di tracciamento per 6 mesi, le dimensioni del database aumentano a circa 40 GB e la conservazione a 12 mesi aumenta le dimensioni del database a circa 45 GB. I dati dei destinatari consumano circa 5 GB per questo ambiente.

Attenzione - Questa stima non include dati cliente aggiuntivi. Se si prevede di replicare ulteriori colonne o tabelle di dati dei clienti nel database Adobe Campaign, è necessario stimare il fabbisogno aggiuntivo di spazio su disco per tale database. I segmenti o gli elenchi caricati richiedono anche più spazio di archiviazione, a seconda delle dimensioni, della frequenza e del periodo di conservazione.

Server web e applicazioni
In questo scenario, Adobe consiglia di installare Adobe Campaign su quattro computer, due server applicazioni e due server web, con le seguenti specifiche:

Fai riferimento a Scenario 1: Distribuzione a dimensione moderata per ulteriori commenti su proxy, centri preferenza/gestione abbonamento e utilizzo dello spazio su disco.

 
Database
Le raccomandazioni hardware per il server di database sono le seguenti:

Questa distribuzione include anche le chiamate al Centro messaggi, gestite dai siti web e dalle applicazioni personali.

 
Server web e applicazioni
In questo scenario, Adobe consiglia di installare Adobe Campaign su quattro computer, come segue:

Fai riferimento a Scenario 1: Distribuzione a dimensione moderata per ulteriori commenti su proxy, centri preferenza/gestione abbonamento e utilizzo dello spazio su disco.

 
Database
Le raccomandazioni hardware per il server di database sono le seguenti:

Linee guida per la modifica delle ipotesi
Le ipotesi formulate per questi scenari hanno un impatto significativo sulle raccomandazioni hardware e sull'architettura di distribuzione. Questa sezione illustra le linee guida relative a diverse ipotesi. Contatta il team di consulenza Adobe Campaign per suggerimenti specifici in base alle tue esigenze.

• Numero di destinatari

  I destinatari attivi richiedono spazio di archiviazione e spazio buffer del database, pertanto un numero maggiore di destinatari in genere richiede una maggiore capacità di memoria e CPU sul server di database. Gli incrementi di archiviazione sono relativamente piccoli per i destinatari stessi, ma possono essere significativi per i dati di tracciamento degli eventi conservati per le campagne e-mail.

• Dimensione campagna e-mail

  La frequenza dei lanci delle campagne ha un impatto sui requisiti della CPU del server di database. Insieme alla direct mailing, alle interazioni in entrata e ad altri flussi di lavoro, le operazioni di segmentazione per le campagne e-mail caricano notevolmente il server di database.

• Frequenza direct mailing

  La frequenza delle direct mailing può influire sui requisiti della CPU del server di database. Insieme ai lanci di campagne e ad altri flussi di lavoro, le operazioni di segmentazione per gli invii diretti caricano notevolmente il server di database.

• Volume messaggio SMS

  Come le dimensioni della campagna e-mail, il volume del messaggio SMS non inserisce carichi di grandi dimensioni sui server Campaign situati on-premise; il caricamento è eseguito principalmente sui server Adobe Cloud Messaging sul cloud. La segmentazione per le campagne SMS, come e-mail e direct mailing, può caricare notevolmente il database di marketing. Pertanto la frequenza degli avvii delle campagne SMS e la complessità della segmentazione sono più rilevanti del volume dei messaggi SMS.

• Complessità dello schema di database

  La quantità di dati per ogni destinatario attivo richiede sia spazio di archiviazione che spazio di buffer del database, pertanto più destinatari generalmente richiedono più memoria e CPU sul server di database. Gli schemi complessi richiedono anche l’unione di più tabelle per la segmentazione, pertanto le operazioni di segmentazione possono essere eseguite molto più lentamente e richiedono più CPU e memoria del database quando i dati vengono distribuiti su più tabelle.
  La memoria del server di database viene stimata garantendo che il pool di buffer del database possa essere sufficientemente grande da contenere tutti i dati dei destinatari, oltre alle tabelle temporanee per l'esecuzione dei flussi di lavoro, oltre a un margine per altre operazioni del database.

• Utilizzo dell’interazione in uscita

  Le regole per l'interazione in modalità batch vengono valutate nei flussi di lavoro che trasferiscono al database tutta la complessità del calcolo. Il principale fattore di sforzo sul database è il numero totale di offerte ammissibili calcolate durante una chiamata al motore (dimensione obiettivo X numero medio di offerte per destinatario prima di mantenere le N migliori offerte). La velocità della CPU del server di database è il primo fattore di prestazioni.

• Interazioni in entrata o utilizzo dell’API SOAP

  Le regole e le offerte di interazione in entrata vengono valutate nel database di marketing, richiedendo risorse significative del server di database, in particolare la CPU. L’utilizzo intensivo di Interazioni in entrata o API SOAP richiede server web separati per separare il carico di lavoro dall’esecuzione dei flussi di lavoro di Campaign.

• Periodo di conservazione dei dati di tracciamento

  L'aumento della conservazione dei dati di tracciamento oltre i 90 giorni richiede più spazio di archiviazione nel database e può rallentare il sistema perché l'inserimento di nuovi dati di tracciamento va in tabelle di grandi dimensioni. I dati di tracciamento non sono utili per la segmentazione delle campagne dopo 90 giorni, pertanto si consiglia di ridurre il periodo di conservazione.
  I dati di tracciamento devono essere spostati in Adobe Analytics o in un altro sistema di analisi se hai bisogno di un’analisi a lungo termine dell’esperienza di marketing dei destinatari.

Virtualizzazione
Tutti i server Campaign sono candidati ideali per la virtualizzazione. Vari problemi devono essere affrontati per garantire la disponibilità e le prestazioni adeguate.

• Configurazione non riuscita

  I server cluster, ad esempio, i server applicazioni ridondanti sotto un proxy con carico bilanciato, devono essere distribuiti su hardware separato per garantire che entrambe le VM non si spegnano in caso di errore hardware.

• Configurazione I/O

  È necessario mantenere qualsiasi configurazione RAID consigliata per la sicurezza del database, in modo che la perdita di un dispositivo di storage non causi la perdita di dati.

• Prestazioni I/O

  È necessario rispettare la classificazione IOPS raccomandata per lo storage del database. I servizi cloud come Amazon EC2 potrebbero non fornire le prestazioni richieste e devono essere valutati attentamente. Ad esempio, i volumi SSD con provisioning Amazon EC2 sono attualmente valutati a 20.000 IOPS ciascuno. Ulteriori informazioni in Documentazione di AmazonPertanto, una configurazione RAID a 4 volumi verrebbe classificata a 80.000 IOPS, il che potrebbe non essere sufficiente.