Produktionsbereitstellung auf EC2 mit minimalen Ausfallzeiten

Ich habe eine einfache Webanwendung, die auf einer großen Instanz mit EC2 bereitgestellt wird. Ich möchte jetzt den neuesten Code auf diesem Server bereitstellen, aber ich möchte dies auf eine Weise tun, die Ausfallzeiten minimiert und für den Endbenutzer so reibungslos wie möglich ist. Hier ist mein Plan:

1. Starten Sie eine weitere große Instanz
2. Installieren Sie alle Softwareschichten auf dieser Instanz
3. Stellen Sie ein EBS-Laufwerk wieder her und hängen Sie es an die Instanz an
4. Stellen Sie unseren neuesten produktionsbereiten Code auf der neuen Instanz bereit
5. Führen Sie alle Tests aus (einschließlich manueller Tests der Anwendung).
6. (Wenn die Tests bestanden wurden) Setzen Sie auf der Live-Site einen Hinweis "Site Under Maintenance".
7. Sichern Sie die EBS-Instanz auf der Live-Site
8. Trennen Sie die EBS-Instanz vom neuen Server und ersetzen Sie sie durch die neueste Sicherung
9. Verwenden Sie die ec2-Associate-Adresse, um die IP-Adresse auf die neue Instanz zu verschieben
10. Lehnen Sie sich zurück und warten Sie, bis der Datenverkehr durch die neue Instanz fließt
11. Beenden Sie die alte Instanz

Scheint dies eine gute Strategie zu sein? Gibt es Tutorials oder Bücher, die dieses Thema behandeln könnten? Ich habe bereits Cloud Application Architectures von George Reese gelesen, ein ausgezeichnetes Buch, das jedoch nicht die Bereitstellung abdeckt. Außerdem weiß ich, dass es Tools wie RightScale oder enStratus gibt, die ich verwenden kann, wenn ich mehr als eine Instanz verwende.

Dies scheint ein guter Gesamtansatz zu sein. Sie können Schritt 2 ausschneiden und so die Startzeit verkürzen, indem Sie ein benutzerdefiniertes AMI erstellen, das alle erforderlichen Softwareschichten enthält. Trotzdem würde ich beim Start immer noch alle Pakete aktualisieren, um sicherzustellen, dass Sie die neuesten Sicherheitsupdates erhalten.

Möglicherweise möchten Sie auch über die Verwendung einer EBS-gestützten Instanz nachdenken. Auf diese Weise können Sie das Startvolume, den Software-Stack und Ihre Anwendung auf EBS verwenden, wodurch einige der oben genannten Schritte entfallen.

OK, das wurde vor einiger Zeit gefragt, aber ich werde mich trotzdem mit meinen 2 Cent einschalten. Ich denke, Sie verpassen die Vorteile von Cloud Computing.

Zunächst sollten Sie Ihren Anwendungscode und Ihre persistenten Daten auf zwei verschiedenen virtuellen Maschinen trennen. Dies kostet Sie ein wenig Kommunikationslatenz zwischen VMs, sollte jedoch Ihre Verwaltung erheblich vereinfachen. Denken Sie daran, dass 2 kleine VMs anstelle von 1 großen VM nicht teurer sind. Wählen Sie daher die Anzahl der Hosts, die Ihren Anforderungen am besten entspricht.

Wenn möglich, möchten Sie, dass Ihre Anwendungsserver in dem Sinne "zustandslos" sind, dass sie keine persistenten Daten enthalten sollten, und Sie sollten in der Lage sein, eine neue Instanz mit einem Minimum an manueller Arbeit zu erzeugen.

Zweitens sollten Sie überlegen, ob einige der von Amazon verwalteten Dienste wie SimpleDB oder Relational Database Service (gehostetes MySQL) gut zu Ihrem dauerhaften Datenspeicher passen.

Der ideale Fluss sieht ungefähr so ​​aus:

1. Ändern Sie zuerst das "hinterste" Backend-System. Wenn für Ihre Änderung beispielsweise das Hinzufügen einer Spalte zu einer Datenbanktabelle erforderlich ist, fügen Sie diese mithilfe normaler MySQL-Tools auf einer laufenden RDS-Instanz hinzu. (Dies setzt voraus, dass Ihre Architektur es Ihrem Datenspeicher ermöglicht, sich unter Beibehaltung der Abwärtskompatibilität zu ändern, oder dass Sie zuerst Ihren App-Server-Code aktualisieren, damit er vorwärtskompatibel ist.)
2. Rufen Sie eine neue Anwendungsserverinstanz mit einem benutzerdefinierten, sofort vorbereiteten, gebrauchsfertigen AMI auf.
3. Installieren Sie Ihren aktualisierten Code auf dem neuen App-Server, dh den neuen Code, der die neue Spalte verwendet und über die neue Funktionalität verfügt.
4. Test .
5. Übertragen Sie einen Teil oder den gesamten Datenverkehr, dh verschieben Sie die IP-Adresse / schalten Sie den elastischen Lastausgleich auf den neuen App-Server um. (In einer idealen Welt würden Sie sich nur über einen kleinen Prozentsatz bewegen, z. B. zunächst 5% Ihres Datenverkehrs, und dann auf Probleme achten. AFAIK Elastic Load Balancing unterstützt noch kein gewichtetes Sticky-Routing, daher sollten Sie dies wahrscheinlich nicht tun. Eine schrittweise Umschaltung kann auch durch zwei Ausführungspfade in Ihrem Code erreicht werden. Dies ist jedoch zeitaufwändig und ärgerlich - der gewichtete Lastausgleich ist einfacher.)
6. Behalten Sie die alte App-Server-Instanz einige Tage bei , falls der neue Code Regressionen aufweist und Sie ein Rollback durchführen müssen.