AWS Architekturdesign

Question

In unserem Unternehmen planen wir, unsere webbasierte Plattform über AWS zu starten. Ich habe das Architekturdesign vorbereitet und möchte Sie bitten, Feedback zu geben, wie Sie es verbessern können. Ein paar Hinweise sind ..

DATABASE

• Wir mit MariaDB gehen (Master + Slave auf anderem AZ)
• Master-DB ist nur zugänglich für Admins schreiben/löschen/lesen
• End -Anwender werden alle von der Lese Repliken (4 Replikate accross 2 AZ)
• Master = T2.micro
• lesen Repliken = T2.small
lesen

ADMIN

• Admin Panel App werden getrennt werden, auf separaten Sub-Domain und SSL-fähigen
• Admin-Panel ist der einzige, der Master RDS Anzahl Benutzer wird modifiziert: max 10 : D
• Webserver: Lighttpd/Apache (kommentieren?)
• Maschine: T2.nano
(keine Notwendigkeit für mehr für 10 Benutzer, nicht wahr?)

FRONT (END-USERS)

• Vorderseite wird eine Menge von Endnutzern servieren (bis 10Mio)
• EC2 Maschinen T2.small wird
• Web-Server: lighttpd/Apache (Kommentar?)
• Wir haben viele Anwender aber jeder Benutzer nur 1 PHP-Anforderung (1 php Skript + wählen Sie auf RDS Read Replica)
• Alle anderen Dateien sind statisch und werden von unserem CDN serviert (Origin wird EC2 T2.nano, weil es wirklich wenig Verkehr gibt, nur in um neue Dateien zu CDN zu cachen)
• Natürlich werden EC2-Maschinen für Front Autoscalling sein. 2 verschiedene AZ zu wählen. (Ist das 1 Autoscale-Gruppe in diesem Fall oder 2 Gruppen?)

BACKUP und SAFETY

• Master-DB wird automatisch ein Backup
• Wir tun automatisierte Snapshot-Erstellung von Admin EC2 & CDN Herkunft Webserver
• Keine Notwendigkeit für das Backup von Frontend EC2 automatische Skalierung Instanzen, Der gesamte Code wird automatisch mit CodeDeploy von Github

bereitgestellt

Here's the current arhitecture design diagram.

Bitte helfen Sie und geben Sie einige Rückmeldungen. Was sind die Engpässe? Haben wir etwas Wichtiges vermisst?

Answer 1

Schwer zu wissen, ohne viel über Ihren Anwendungsfall zu wissen, aber ein paar Dinge springen bei mir:

• Sie sagen, Sie ‚viel‘ der Nutzer wird dient, sondern eine Kombination von t2 verwenden .nanos, t2.micros und t2.smalls - das kann zu einem Flaschenhals werden. Ich denke an t2 ist gut für Test/dev und sehr kleine Produktionslasten. Nicht um viele Nutzer zu bedienen - das kann schnell zu einem Flaschenhals werden.
• Erwägen Sie, einen S3-Bucket anstelle von t2.nano für den Ursprung Ihrer statischen Assets zu verwenden, billiger, einfacher und wird bei Bedarf besser skaliert; Das hat keinen Nachteil.