-
L'API deve essere protetta, quindi non provare a fare dei compromessi qui. Non sarà buono ;-) Tuttavia, non scambiare su prestazioni, deve essere molto veloce, quindi sarà stabile. Usa i cookie che sono molto buoni (ci sono un sacco di informazioni qui intorno).
-
Oltre alle solite precauzioni di sicurezza (cookie, ecc.), ho trovato il seguente:
-
Buoni limiti al numero di richieste simultanee a Tomcat (o qualsiasi altra cosa tu usi, è normalmente nella direttiva del connettore web) - puoi testarlo in modo che il server non stia sovraccaricando a pieno carico, in modo da non rendere i server crash a pieno carico ma anche loro sono stati utilizzati bene, ad esempio con
ab -c <number of connections> . E poi, davanti a questi Tomcats mette il bilanciamento del carico per distribuire il traffico e proteggersi da altri attacchi come le inondazioni di pacchetti. Load Balancer dovrebbe avere lo stack TCP / IP ottimizzato per tali scenari (vedi sotto).
- Server distribuiti geograficamente in Cloud, quindi con bilanciamento del carico GSLB e scalabilità automatica
- Cerca di utilizzare la cache in-RAM il più possibile
- Utilizza database scalabili, come DynamoDB in AWS, ma farà anche una buona istanza MySQL, in modo che possano scalare con il tuo carico
- Assicurati che ogni singola funzione API non sia lenta, questo può essere fatto in unit test (quindi con ogni prova puoi vedere qualsiasi potenziale bersaglio per DDoS), rendendo tutte le chiamate API molto veloci, fondamentalmente fai problemi DDoS molto piccolo e il tuo sito web molto bello.
Le cose sopra evidenziate in grassetto sono ciò che di solito faccio dopo che gli sviluppatori fanno il loro lavoro per renderlo più veloce e più resistente e questo è il mio 4 punti d'oro :-)
Dalla mia esperienza ci vogliono 20GBps di rete e 4-6 32 core server per mitigare comunque qualsiasi picco simile a quello di Tomcats. Semplicemente non accade più di questo e le risorse oggi sono economiche per affrontarle e persino su richiesta. Il problema è quando qualcosa è lento o non scalabile come i database, quindi le risorse diventano troppo alte e questo è il problema.
Per gli sviluppatori che fanno l'API il punto principale è usare la cache in-RAM. Il resto è infrastruttura / server con Tomcat build. Ho visto alcuni sviluppatori fare cose del genere e questo è un approccio semplice e buono. Quindi, invece di controllare ogni volta Cookie con database, tenerlo nella RAM, usare sessioni adesive ecc. Lo stesso per altre cose. Come un polling al database che carica i dati nella RAM ogni minuto e altri thread lo stanno utilizzando senza mai toccare DB. Ho visto anche questo approccio.
Per quanto riguarda l'infrastruttura, è utile avere Load Balancer di fronte a Tomcats e, se non è Cloud One, è possibile farlo in seguito.
-
Imposta il normale bilanciamento del carico come HAProxy e imposta i limiti per ciascun server, quindi in caso di un numero elevato di richieste HTTP reali puoi elaborarle e inoltrarle a Tomcats, altri software potrebbero essere in grado di eliminare o filtrare le richieste non valide su regole configurate - potresti provare Varnish Cache che è Cache, ma per Load Balancer con filtro è anche eccellente e puoi programmare la tua logica.
-
Ottimizza lo stack TCP / IP del servizio di bilanciamento del carico in modo che sia resiliente a un numero elevato di richieste o pacchetti SYN. Quindi la seguente sintonizzazione è efficace:
- Nessun IPTABLES su di esso (basta filtrare le cose sull'interruttore)
- Disattiva SynCookies
net.ipv4.tcp_syncookies = 0
- Prova
net.ipv4.tcp_tw_recycle = 0
- E
net.ipv4.tcp_tw_reuse = 0
Gli ultimi due possono aiutare a raggiungere un sacco di nuove connessioni in entrata al secondo.