{"id":87393,"date":"2020-07-08T01:42:02","date_gmt":"2020-07-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws"},"modified":"2020-07-08T01:42:02","modified_gmt":"2020-07-07T23:42:02","slug":"sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Erstellung einer skalierbaren API auf Spot-Instanzen von AWS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo zusammen! Mein Name ist Kirill und ich bin CTO bei Adapty. Der Gro\u00dfteil unserer Architektur basiert auf AWS, und heute werde ich euch erz\u00e4hlen, wie wir unsere Serverkosten um das Dreifache gesenkt haben, indem wir Spot-Instances in unserer Produktionsumgebung eingesetzt haben, sowie, wie man deren automatisches Scaling einrichtet. Zuerst gibt es einen \u00dcberblick \u00fcber die Funktionsweise, gefolgt von einer detaillierten Anleitung zur Implementierung.<\/p>\n

<\/p>\n

Was sind Spot-Instances?<\/h2>\n

<\/p>\n

Spot-<\/a><\/noindex> Instances sind Server anderer AWS-Nutzer, die derzeit ungenutzt sind und zu stark reduzierten Preisen verkauft werden (Amazon spricht von bis zu 90 % Rabatt, laut unserer Erfahrung liegt der Durchschnitt bei etwa 3x, variierend je nach Region, AZ und Instanztyp). Der Hauptunterschied zu den regul\u00e4ren Instanzen besteht darin, dass sie jederzeit abgeschaltet werden k\u00f6nnen. Daher haben wir lange Zeit geglaubt, dass sie f\u00fcr Entwicklungsumgebungen oder f\u00fcr Berechnungen, bei denen Zwischenergebnisse in S3 oder in einer Datenbank gespeichert werden, geeignet sind, jedoch nicht f\u00fcr die Produktion. Es gibt Drittanbieter-L\u00f6sungen, die die Nutzung von Spot-Instanzen in der Produktion erm\u00f6glichen, aber f\u00fcr unseren Fall sind viele Workarounds erforderlich, weshalb wir sie nicht implementiert haben. Der in diesem Artikel beschriebene Ansatz funktioniert vollst\u00e4ndig innerhalb der Standardfunktionalit\u00e4t von AWS, ohne zus\u00e4tzliche Skripte, Cronjobs usw.<\/p>\n

<\/a><\/noindex><\/p>\n

Im Folgenden zeige ich einige Screenshots, die die Preishistorie der Spot-Instanzen darstellen.<\/p>\n

<\/p>\n

m5.large in der Region eu-west-1 (Irland). Der Preis ist in den letzten 3 Monaten \u00fcberwiegend stabil gewesen, derzeit betr\u00e4gt die Einsparung 2,9x.<\/p>\n

<\/p>\n

\"Erstellung<\/p>\n

<\/p>\n

m5.large in der Region us-east-1 (N. Virginia). Der Preis ver\u00e4ndert sich st\u00e4ndig \u00fcber einen Zeitraum von 3 Monaten, aktuell betr\u00e4gt die Einsparung zwischen 2,3x und 2,8x, abh\u00e4ngig von der Verf\u00fcgbarkeitszone.<\/p>\n

<\/p>\n

\"Erstellung<\/p>\n

<\/p>\n

t3.small in der Region us-east-1 (N. Virginia). Der Preis ist stabil \u00fcber einen Zeitraum von 3 Monaten, aktuell betr\u00e4gt die Einsparung 3,4x.<\/p>\n

<\/p>\n

\"Erstellung<\/p>\n

<\/p>\n

Architektur des Dienstes<\/h2>\n

<\/p>\n

Die grundlegende Architektur des Dienstes, \u00fcber den wir in diesem Artikel sprechen werden, ist in der folgenden Abbildung dargestellt.<\/p>\n

<\/p>\n

\"Erstellung<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 Target Group \u2192 Elastic Container Service<\/h3>\n

<\/p>\n

Als Lastenausgleich wird der Application Load Balancer (ALB) verwendet, der Anfragen an die EC2 Target Group (TG) sendet. Die TG sorgt daf\u00fcr, dass die Ports auf den Instanzen f\u00fcr den ALB ge\u00f6ffnet werden und mit den Ports der Container im Elastic Container Service (ECS) verbunden sind. ECS ist das Pendant zu Kubernetes bei AWS und verwaltet Docker-Container.<\/p>\n

<\/p>\n

Auf einer Instanz k\u00f6nnen mehrere Container mit identischen Ports gleichzeitig betrieben werden, weshalb wir diese nicht festlegen k\u00f6nnen. ECS informiert den TG, dass es einen neuen Task startet (dies wird in der Kubernetes-Terminologie als Pod bezeichnet). Anschlie\u00dfend wird eine \u00dcberpr\u00fcfung der verf\u00fcgbaren Ports auf der Instanz durchgef\u00fchrt, und einer dieser Ports wird dem gestarteten Task zugewiesen. Zudem \u00fcberpr\u00fcft der TG regelm\u00e4\u00dfig, ob die Instanz und die API darauf durch einen Health Check funktionieren, und wenn Probleme festgestellt werden, werden keine Anfragen mehr dorthin geleitet.<\/p>\n

<\/p>\n

EC2 Auto Scaling Groups + ECS Capacity Providers<\/h3>\n

<\/p>\n

Im obigen Diagramm ist der Dienst EC2 Auto Scaling Groups (ASG) nicht dargestellt. Aus dem Namen geht hervor, dass er f\u00fcr die Skalierung der Instanzen verantwortlich ist. Bis vor kurzem gab es in AWS keine integrierte M\u00f6glichkeit, die Anzahl der laufenden Maschinen direkt \u00fcber ECS zu steuern. ECS erlaubte eine Skalierung der Anzahl der Tasks, zum Beispiel basierend auf der CPU-Nutzung, dem RAM oder der Anzahl der Anfragen. Doch wenn alle freien Instanzen von den Tasks belegt waren, wurden keine neuen Maschinen automatisch gestartet.<\/p>\n

<\/p>\n

Mit dem Auftreten der ECS Capacity Providers (ECS CP) hat sich dies ge\u00e4ndert. Jetzt kann jeder Service in ECS mit einer Auto Scaling-Gruppe (ASG) verkn\u00fcpft werden. Wenn die Tasks nicht auf den laufenden Instanzen Platz finden, werden neue Instanzen gestartet (nat\u00fcrlich innerhalb der festgelegten ASG-Limits). Umgekehrt, wenn ECS CP ungenutzte Instanzen ohne Tasks erkennt, gibt es der ASG den Befehl, diese abzuschalten. ECS CP erm\u00f6glicht es auch, einen Zielauslastungsprozentsatz f\u00fcr die Instanzen anzugeben, sodass jederzeit eine bestimmte Anzahl an Maschinen verf\u00fcgbar ist, um Tasks schnell zu skalieren. Dar\u00fcber werde ich sp\u00e4ter noch mehr erz\u00e4hlen.<\/p>\n

<\/p>\n

EC2 Launch-Vorlagen<\/h3>\n

<\/p>\n

Der letzte Service, \u00fcber den ich sprechen m\u00f6chte, bevor ich zur detaillierten Beschreibung der Erstellung dieser Infrastruktur \u00fcbergehe, sind die EC2 Launch-Vorlagen. Sie erm\u00f6glichen es, eine Vorlage zu erstellen, nach der alle Maschinen gestartet werden, um dies nicht jedes Mal von Grund auf neu machen zu m\u00fcssen. Hier kann man den Typ der zu startenden Maschine, die Sicherheitsgruppe, das Disk-Image und viele weitere Parameter ausw\u00e4hlen. Au\u00dferdem kann man benutzerdefinierte Daten angeben, die auf alle gestarteten Instanzen angewendet werden. In den benutzerdefinierten Daten k\u00f6nnen Skripte ausgef\u00fchrt werden, beispielsweise kann der Inhalt einer Datei bearbeitet werden. ECS-Agent-Konfiguration<\/a><\/noindex>.<\/p>\n

<\/p>\n

Einer der wichtigsten Konfigurationsparameter in diesem Artikel ist ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Wenn dieser Parameter aktiviert ist, wechselt ECS alle Tasks, die auf einer Spothinstanz laufen, in den Status Draining, sobald ein Signal empfangen wird, dass die Spothinstanz abgezogen wird. Es werden keine neuen Tasks mehr auf diese Instanz zugewiesen; wenn es Tasks gibt, die gerade auf diese Instanz ausgerollt werden sollen, werden sie abgebrochen. Anfragen vom Load Balancer h\u00f6ren ebenfalls auf, zu kommen. Die Benachrichtigung \u00fcber die Entfernung der Instanz erfolgt 2 Minuten vor dem tats\u00e4chlichen Ereignis. Daher k\u00f6nnen Sie Spothinstanzen ohne Datenverlust verwenden, wenn Ihr Dienst keine Aufgaben l\u00e4nger als 2 Minuten ausf\u00fchrt und nichts auf der Festplatte speichert.<\/p>\n

<\/p>\n

Was die Festplatte betrifft \u2013 AWS hat k\u00fcrzlich eine \u00c4nderung vorgenommen<\/a><\/noindex> Die Nutzung des Elastic File System (EFS) zusammen mit ECS ist m\u00f6glich; dabei stellt selbst die Festplatte kein Hindernis dar. Allerdings haben wir dies nicht getestet, da wir grunds\u00e4tzlich keine Festplatte zur Speicherung des Zustands ben\u00f6tigen. Standardm\u00e4\u00dfig werden nach Erhalt eines SIGINT (dies wird zum Zeitpunkt des Wechsels des Tasks in den Status Draining gesendet) alle aktiven Tasks nach 30 Sekunden gestoppt, auch wenn sie nicht rechtzeitig abgeschlossen werden. Diese Zeit kann mit einem Parameter ge\u00e4ndert werden. ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. Wichtig ist, diesen Wert nicht auf mehr als 2 Minuten f\u00fcr Spot-Instances zu setzen.<\/p>\n

<\/p>\n

Erstellung eines Dienstes<\/h2>\n

<\/p>\n

Kommen wir nun direkt zur Erstellung des beschriebenen Dienstes. Im Verlauf werde ich einige n\u00fctzliche Punkte erw\u00e4hnen, die zuvor nicht angesprochen wurden. Im Grunde handelt es sich um eine Schritt-f\u00fcr-Schritt-Anleitung, jedoch werde ich einige sehr grundlegende oder sehr spezifische F\u00e4lle nicht behandeln. Alle Schritte werden in der visuellen AWS-Konsole ausgef\u00fchrt, k\u00f6nnen jedoch auch programmatisch mit CloudFormation oder Terraform umgesetzt werden. Bei Adapty verwenden wir Terraform.<\/p>\n

<\/p>\n

EC2 Launch-Vorlage<\/strong><\/h3>\n

<\/p>\n

In diesem Dienst wird eine Konfiguration der Maschinen erstellt, die verwendet werden sollen. Die Verwaltung der Vorlagen erfolgt im Bereich EC2 -> Instances -> Launch templates.<\/p>\n

<\/p>\n

Amazon Machine Image (AMI)<\/strong> \u2014 geben Sie das Abbild an, mit dem alle Instanzen gestartet werden. F\u00fcr ECS sollten Sie in den meisten F\u00e4llen das optimierte Abbild von Amazon verwenden. Es wird regelm\u00e4\u00dfig aktualisiert und enth\u00e4lt alles Notwendige f\u00fcr den Betrieb von ECS. Um die aktuelle ID des Abbilds zu erfahren, gehen Sie zur Seite Amazon ECS-optimierte AMIs<\/a><\/noindex>, w\u00e4hlen Sie die verwendete Region aus und kopieren Sie die AMI-ID daf\u00fcr. Zum Beispiel ist f\u00fcr die Region us-east-1 die zum Zeitpunkt des Schreibens des Artikels aktuelle ID \u2014 ami-00c7c1cf5bdc913ed<\/em>. Diese ID muss in das Feld \"Specify a custom value\" eingef\u00fcgt werden.<\/p>\n

<\/p>\n

Instanztyp<\/strong> \u2014 geben Sie den Typ der Instanz an. W\u00e4hlen Sie denjenigen, der am besten f\u00fcr Ihre Aufgabe geeignet ist.<\/p>\n

<\/p>\n

Schl\u00fcsselpaar (Login)<\/strong> \u2014 geben Sie das Zertifikat an, mit dem Sie sich bei Bedarf \u00fcber SSH mit der Instanz verbinden k\u00f6nnen.<\/p>\n

<\/p>\n

Netzwerkeinstellungen<\/strong> \u2014 geben Sie die Netzparameter an. Netzwerkplattform<\/strong> sollte in den meisten F\u00e4llen Virtual Private Cloud (VPC) sein. Sicherheitsgruppen<\/strong> \u2014 Sicherheitsgruppen f\u00fcr Ihre Instanzen. Da wir einen Load Balancer vor den Instanzen einsetzen, empfehle ich, hier eine Gruppe anzugeben, die eingehende Verbindungen nur vom Load Balancer zul\u00e4sst. Das bedeutet, Sie haben zwei Sicherheitsgruppen: eine f\u00fcr den Load Balancer, die eingehende Verbindungen aus allen Quellen auf den Ports 80 (HTTP) und 443 (HTTPS) erlaubt, und eine zweite f\u00fcr die Maschinen, die eingehende Verbindungen von der Load Balancer-Gruppe auf beliebigen Ports zul\u00e4sst. Die ausgehenden Verbindungen in beiden Gruppen sollten \u00fcber das TCP-Protokoll f\u00fcr alle Ports zu allen Adressen ge\u00f6ffnet sein. Ports und Adressen f\u00fcr ausgehende Verbindungen k\u00f6nnen eingeschr\u00e4nkt werden, allerdings m\u00fcssen Sie dann st\u00e4ndig \u00fcberwachen, dass Sie nicht versuchen, auf einen geschlossenen Port zuzugreifen.<\/p>\n

<\/p>\n

Speicher (Volumes)<\/strong> \u2014 wir geben die Festplattenspezifikationen f\u00fcr die Maschinen an. Das Festplattenvolumen darf nicht kleiner sein als das, was im AMI festgelegt ist, f\u00fcr ECS Optimized \u2014 30 GiB.<\/p>\n

<\/p>\n

Erweiterte Details<\/strong> \u2014 wir geben zus\u00e4tzliche Parameter an.<\/p>\n

<\/p>\n

Kaufsoption<\/strong> \u2014 m\u00f6chten wir Spot-Instanzen kaufen. Wir m\u00f6chten, werden diese Option hier aber nicht aktivieren, sondern in der Auto Scaling-Gruppe einstellen, wo es mehr Optionen gibt.<\/p>\n

<\/p>\n

IAM-Instanzprofil<\/strong> \u2014 geben Sie die Rolle an, mit der die Instanzen gestartet werden. Damit die Instanzen in ECS funktionieren, ben\u00f6tigen sie Berechtigungen, die normalerweise in der Rolle liegen. ecsInstanceRole<\/em>. In einigen F\u00e4llen kann sie erstellt werden, falls nicht, hier ist finden Sie die Anleitung<\/a><\/noindex> eine Anleitung dazu. Nach der Erstellung geben wir sie im Template an.
\nEs folgen viele Parameter, in den meisten F\u00e4llen k\u00f6nnen die Standardwerte beibehalten werden, aber jeder von ihnen hat eine verst\u00e4ndliche Beschreibung. Ich aktiviere immer die Parameter EBS-optimized instance und T2\/T3 Unlimited, wenn verwendet wird, burstable<\/a><\/noindex> Instanzen.<\/p>\n

<\/p>\n

Benutzerdaten<\/strong> \u2014 wir geben die Benutzerdaten an. Wir werden die Datei bearbeiten, \/etc\/ecs\/ecs.config<\/code>in der die Konfiguration des ECS-Agenten gespeichert ist.
\nEin Beispiel daf\u00fcr, wie Benutzerdaten aussehen k\u00f6nnten:<\/p>\n

<\/p>\n

#!\/bin\/bash\necho ECS_CLUSTER=DemoApiClusterProd >> \/etc\/ecs\/ecs.config\necho ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> \/etc\/ecs\/ecs.config\necho ECS_CONTAINER_STOP_TIMEOUT=1m >> \/etc\/ecs\/ecs.config\necho ECS_ENGINE_AUTH_TYPE=docker >> \/etc\/ecs\/ecs.config\necho "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> \/etc\/ecs\/ecs.config<\/code><\/pre>\n
<\/p>\n
ECS_CLUSTER=DemoApiClusterProd<\/code> \u2014 dieser Parameter gibt an, dass die Instanz zum Cluster mit dem angegebenen Namen geh\u00f6rt, das hei\u00dft, dieser Cluster kann seine Aufgaben auf diesem Server ausf\u00fchren. Wir haben das Cluster noch nicht erstellt, aber wir werden diesen Namen bei der Erstellung verwenden.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 dieser Parameter gibt an, dass beim Empfang des Signals zum Ausschalten einer Spot-Instanz alle Aufgaben darauf in den Status Draining versetzt werden sollen.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 Dieser Parameter gibt an, dass nach dem Empfang des SIGINT-Signals alle Aufgaben 1 Minute Zeit haben, bevor sie beendet werden.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 Dieser Parameter gibt an, dass das Docker-Schema als Authentifizierungsmechanismus verwendet wird.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 Verbindungsparameter f\u00fcr das private Container-Registry, wo Ihre Docker-Images gespeichert sind. Wenn es \u00f6ffentlich ist, m\u00fcssen Sie nichts angeben.<\/p>\n
<\/p>\n
In diesem Artikel werde ich ein \u00f6ffentliches Image aus Docker Hub verwenden, daher m\u00fcssen keine Parameter angegeben werden. ECS_ENGINE_AUTH_TYPE<\/code> und ECS_ENGINE_AUTH_DATA<\/code> sind nicht notwendig.<\/p>\n
<\/p>\n
N\u00fctzliche Information<\/strong>: Es wird empfohlen, AMIs regelm\u00e4\u00dfig zu aktualisieren, da in neuen Versionen Docker, Linux, der ECS-Agent usw. aktualisiert werden. Um dies nicht zu vergessen, k\u00f6nnen Sie Benachrichtigungen einrichten<\/a><\/noindex> \u00fcber neue Versionen. Sie k\u00f6nnen Benachrichtigungen per E-Mail erhalten und manuell aktualisieren oder eine Lambda-Funktion schreiben, die automatisch eine neue Version des Launch-Templates mit dem aktualisierten AMI erstellt.<\/p>\n
<\/p>\n
EC2 Auto Scaling-Gruppe<\/strong><\/h3>\n
<\/p>\n
Die Auto Scaling-Gruppe ist verantwortlich f\u00fcr das Starten und Skalieren von Instanzen. Die Verwaltung der Gruppen erfolgt im Bereich EC2 -> Auto Scaling -> Auto Scaling-Gruppen.<\/p>\n
<\/p>\n
Launch-Template<\/strong> \u2014 W\u00e4hlen Sie das zuvor erstellte Template aus. Die Version lassen wir auf der Standardversion.<\/p>\n
<\/p>\n
Kaufe Optionen und Instanztypen<\/strong> \u2014 Wir geben die Instanztypen f\u00fcr den Cluster an. Adhere to launch template verwendet den Instanztyp aus der Vorlage. Combine purchase options and instance types erm\u00f6glicht eine flexible Anpassung der Instanztypen. Wir werden ihn nutzen.<\/p>\n
<\/p>\n
Optionale On-Demand-Basis<\/strong> \u2014 die Anzahl der regul\u00e4ren, nicht-spot Instanzen, die immer laufen werden.<\/p>\n
<\/p>\n
On-Demand-Prozentsatz \u00fcber der Basis<\/strong> \u2014 das prozentuale Verh\u00e4ltnis von regul\u00e4ren zu Spot-Instanzen; 50-50 w\u00fcrde gleichm\u00e4\u00dfig verteilen, 20-80 bedeutet, dass auf jede regul\u00e4re Instanz 4 Spot-Instanzen hinzugef\u00fcgt werden. In diesem Beispiel gebe ich 50-50 an, aber in der Realit\u00e4t machen wir oft 20-80 und in einigen F\u00e4llen 0-100.<\/p>\n
<\/p>\n
Instanztypen<\/strong> \u2014 hier k\u00f6nnen zus\u00e4tzliche Instanztypen angegeben werden, die im Cluster verwendet werden. Wir haben das nie genutzt, da ich den Sinn dieser Funktion nicht ganz verstehe. M\u00f6glicherweise h\u00e4ngt es mit den Limits f\u00fcr bestimmte Instanztypen zusammen, aber diese k\u00f6nnen leicht \u00fcber den Support erh\u00f6ht werden. Wenn Sie eine Anwendung wissen, w\u00fcrde ich mich freuen, in den Kommentaren dar\u00fcber zu lesen.)<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Netzwerk<\/strong> \u2014 Netzwerkeinstellungen, w\u00e4hlen Sie VPC und Subnetze f\u00fcr die Maschinen; in den meisten F\u00e4llen sollten Sie alle verf\u00fcgbaren Subnetze ausw\u00e4hlen.<\/p>\n
<\/p>\n
Lastenverteilung<\/strong> \u2014 Einstellungen des Load Balancers, aber das machen wir separat, hier fassen wir nichts an. \u00dcberpr\u00fcfungen der Gesundheit<\/strong> werden sp\u00e4ter ebenfalls konfiguriert.<\/p>\n
<\/p>\n
Gruppengr\u00f6\u00dfe<\/strong> \u2014 wir legen die Grenzen f\u00fcr die Anzahl der Maschinen im Cluster und die gew\u00fcnschte Anzahl der Maschinen beim Start fest. Die Anzahl der Maschinen im Cluster wird nie unter die minimal angegebene Anzahl fallen und nie \u00fcber die maximale Anzahl hinausgehen, selbst wenn die Metriken eine Skalierung erfordern.<\/p>\n
<\/p>\n
Skalierungsrichtlinien<\/strong> \u2014 Parameter f\u00fcr die Skalierung, jedoch skalieren wir basierend auf den laufenden ECS-Aufgaben, daher werden wir die Skalierung sp\u00e4ter einstellen.<\/p>\n
<\/p>\n
Instanz-Skalierungsschutz<\/strong> \u2014 Schutz der Instanzen vor der L\u00f6schung beim Herunterskalieren. Wir aktivieren dies, damit das ASG keine Maschine l\u00f6scht, auf der aktive Aufgaben vorhanden sind. Der Schutz wird f\u00fcr Instanzen, auf denen keine Aufgaben laufen, vom ECS Capacity Provider deaktiviert.<\/p>\n
<\/p>\n
Tags hinzuf\u00fcgen<\/strong> \u2014 es k\u00f6nnen Tags f\u00fcr die Instanzen angegeben werden (daf\u00fcr muss die Option \"Neue Instanzen taggen\" aktiviert sein). Ich empfehle, das Tag \"Name\" anzugeben, damit alle Instanzen, die innerhalb der Gruppe gestartet werden, denselben Namen tragen und bequem in der Konsole betrachtet werden k\u00f6nnen.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Nach der Erstellung der Gruppe \u00f6ffnen Sie diese und gehen Sie zum Abschnitt \"Erweiterte Konfigurationen\", da nicht alle Optionen in der Konsole w\u00e4hrend der Erstellung sichtbar sind.<\/p>\n
<\/p>\n
Beendigungsrichtlinien<\/strong> \u2014 Regeln, die beim L\u00f6schen von Instanzen zu beachten sind. Sie werden in der Reihenfolge angewendet. Wir verwenden normalerweise solche, wie im Bild unten. Zuerst werden die Instanzen mit dem \u00e4ltesten Launch-Template gel\u00f6scht (zum Beispiel, wenn wir das AMI aktualisiert haben, wurde eine neue Version erstellt, und alle Instanzen sind bereits darauf umgestiegen). Danach werden die Instanzen ausgew\u00e4hlt, die am n\u00e4chsten zur n\u00e4chsten Abrechnungszeit liegen. Schlie\u00dflich werden die \u00e4ltesten Instanzen nach dem Startdatum ausgew\u00e4hlt.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
N\u00fctzliche Information<\/strong>: Um alle Maschinen im Cluster zu aktualisieren, ist es praktisch, Instance Refresh<\/a><\/noindex>. Wenn Sie dies mit einer Lambda-Funktion aus dem vorherigen Schritt kombinieren, haben Sie ein vollst\u00e4ndig automatisiertes System zur Aktualisierung der Instanzen. Vor dem Upgrade aller Maschinen m\u00fcssen Sie den Instance Scale-In-Schutz f\u00fcr alle Instanzen in der Gruppe deaktivieren. Nicht die Gruppenverwaltung, sondern den Schutz der Maschinen selbst, dies erfolgt im Tab Instance Management.<\/p>\n
<\/p>\n
Application Load Balancer und EC2 Zielgruppe<\/h3>\n
<\/p>\n
Der Lastenausgleich wird im Abschnitt EC2 \u2192 Load Balancing \u2192 Load Balancers erstellt. Wir werden den Application Load Balancer verwenden; die Gegen\u00fcberstellung verschiedener Typen von Lastenausgleich kann auf der Dienstseite<\/a><\/noindex>.<\/p>\n
<\/p>\n
Listeners<\/strong> \u2014 es macht Sinn, die Ports 80 und 443 einzurichten und eine Weiterleitung von 80 nach 443 mithilfe von Lastenausgleichsregeln einzurichten.<\/p>\n
<\/p>\n
Verf\u00fcgbarkeitszonen<\/strong> \u2014 in den meisten F\u00e4llen w\u00e4hlen wir alle Verf\u00fcgbarkeitszonen aus.<\/p>\n
<\/p>\n
Sicherheitseinstellungen konfigurieren<\/strong> \u2014 hier wird das SSL-Zertifikat f\u00fcr den Lastenausgleich angegeben, die bequemste Variante ist \u2014 das Zertifikat<\/a><\/noindex> in ACM zu erstellen. Die Unterschiede Sicherheitspolitik<\/strong> k\u00f6nnen im Dokumentation.<\/a><\/noindex>, die standardm\u00e4\u00dfig ausgew\u00e4hlt bleiben kann, ELBSecurityPolicy-2016-08<\/code>. Nach der Erstellung des Lastenausgleichs sehen Sie seinen DNS-Namen<\/strong>, f\u00fcr den Sie CNAME f\u00fcr Ihre Domain einrichten m\u00fcssen. So sieht das beispielsweise in Cloudflare aus.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Sicherheitsgruppe<\/strong> \u2014 wir erstellen oder w\u00e4hlen eine Sicherheitsgruppe f\u00fcr den Lastenausgleich aus. Dar\u00fcber habe ich etwas weiter oben im Abschnitt EC2-Startvorlage \u2192 Netzwerkeinstellungen geschrieben.<\/p>\n
<\/p>\n
Zielgruppe<\/strong> \u2014 wir erstellen eine Gruppe, die f\u00fcr das Routing von Anfragen vom Lastenausgleich auf die Maschinen verantwortlich ist und deren Verf\u00fcgbarkeit \u00fcberpr\u00fcft, um sie im Falle von Problemen zu ersetzen. Zieltyp<\/strong> muss Instance sein, Protokoll<\/strong> und Port<\/strong> beliebig, wenn Sie HTTPS f\u00fcr die Kommunikation zwischen Lastenausgleich und Instanzen verwenden, m\u00fcssen diese das Zertifikat hochladen. Im Rahmen dieses Beispiels werden wir das nicht tun und einfach den Port 80 belassen.<\/p>\n
<\/p>\n
\u00dcberpr\u00fcfungen der Gesundheit<\/strong> \u2014 \u00dcberpr\u00fcfungsparameter des Dienstes. In diesem Dienst sollte dies eine separate Anfrage sein, die wichtige Teile der Gesch\u00e4ftslogik umsetzt; in diesem Beispiel lasse ich die Standardeinstellungen unver\u00e4ndert. Danach kann das Anfrageintervall, der Timeout, die Codes f\u00fcr erfolgreiche Antworten usw. ausgew\u00e4hlt werden. In unserem Beispiel geben wir die Erfolgscodes 200-399 an, da das Docker-Image, das verwendet wird, den Code 304 zur\u00fcckgibt.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Zielregistrierung<\/strong> \u2014 Hier werden Maschinen f\u00fcr die Gruppe ausgew\u00e4hlt, aber in unserem Fall wird dies vom ECS erledigt, daher \u00fcberspringen wir diesen Schritt einfach.<\/p>\n
<\/p>\n
N\u00fctzliche Information<\/strong>: Auf der Ebene des Lastenausgleichs k\u00f6nnen Protokolle aktiviert werden, die in S3 in einem bestimmten Format<\/a><\/noindex>. Von dort k\u00f6nnen sie in externe Dienste f\u00fcr die Analyse exportiert werden, oder man kann SQL-Anfragen direkt an die Daten in S3 mit Athena<\/a><\/noindex>richten. Das ist praktisch und funktioniert ohne zus\u00e4tzlichen Code. Ich empfehle auch, die Protokolle aus dem S3-Bucket nach Ablauf einer bestimmten Zeit zu l\u00f6schen.<\/p>\n
<\/p>\n
ECS-Aufgabendefinition<\/h3>\n
<\/p>\n
In den vorherigen Schritten haben wir alles geschafft, was mit der Infrastruktur des Dienstes zu tun hat. Nun wenden wir uns der Beschreibung der Container zu, die wir starten werden. Dies geschieht im Bereich ECS \u2192 Task Definitions.<\/p>\n
<\/p>\n
Kompatibilit\u00e4t des Starttyps<\/strong> \u2014 wir w\u00e4hlen EC2.<\/p>\n
<\/p>\n
IAM-Rolle f\u00fcr die Ausf\u00fchrung von Aufgaben<\/strong> \u2014 wir w\u00e4hlen ecsTaskExecutionRole<\/code>. Mit ihr werden Protokolle erstellt, der Zugriff auf geheime Variablen gew\u00e4hrt und mehr.<\/p>\n
<\/p>\n
Im Bereich Container Definitions klicken wir auf Add Container.<\/p>\n
<\/p>\n
Bild<\/strong> \u2014 Link zum Image mit dem Projektcode. In diesem Beispiel werde ich ein \u00f6ffentliches Image von Docker Hub verwenden: bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
Speicherlimits<\/strong> \u2014 Speichergrenzen f\u00fcr den Container. Harmlimit<\/strong> \u2014 harter Limit. Wenn der Container den angegebenen Wert \u00fcberschreitet, wird der Befehl docker kill ausgef\u00fchrt, und der Container wird sofort beendet. Weichlimit<\/strong> \u2014 weiche Begrenzung, der Container kann \u00fcber den angegebenen Wert hinausgehen, aber bei der Platzierung von Aufgaben auf den Maschinen wird dieser Parameter ber\u00fccksichtigt. Zum Beispiel, wenn auf der Maschine 4 GiB RAM vorhanden sind und die weiche Begrenzung des Containers 2048 MiB betr\u00e4gt, k\u00f6nnen auf dieser Maschine maximal 2 Aufgaben mit diesem Container ausgef\u00fchrt werden. In der Realit\u00e4t entsprechen 4 GiB RAM etwas weniger als 4096 MiB, dies kann auf der Seite ECS Instanzen im Cluster eingesehen werden. Die weiche Begrenzung darf nicht h\u00f6her sein als die harte Begrenzung. Es ist wichtig zu verstehen, dass wenn in einer Aufgabe mehrere Container vorhanden sind, deren Begrenzungen sich summieren.<\/p>\n
<\/p>\n
Portzuordnungen<\/strong> \u2013 daf\u00fcr braucht man 10-mal weniger Hardware. Host-Port<\/strong> wenn wir 0 angeben, bedeutet das, dass der Port dynamisch zugewiesen wird und von der Zielgruppe \u00fcberwacht wird. Container-Port<\/strong> \u2014 der Port, an dem Ihre Anwendung l\u00e4uft, wird h\u00e4ufig im Ausf\u00fchrungsbefehl angegeben oder im Code Ihrer Anwendung, im Dockerfile usw. festgelegt. F\u00fcr unser Beispiel verwenden wir 3000, da dies im Dockerfile<\/a><\/noindex> verwendeten Image angegeben ist.<\/p>\n
<\/p>\n
Health-Check<\/strong> \u2014 Parameter zur \u00dcberpr\u00fcfung der Funktionalit\u00e4t des Containers, nicht zu verwechseln mit dem, der in der Zielgruppe konfiguriert ist.<\/p>\n
<\/p>\n
Umgebung<\/strong> \u2014 Umgebungsparameter. CPU-Einheiten<\/strong> \u2014 \u00e4hnlich wie die Speicherkapazit\u00e4ten, jedoch f\u00fcr den Prozessor. Jedes Prozessorkern entspricht 1024 Einheiten; wenn der Server also einen Dual-Core-Prozessor hat und der Container einen Wert von 512 hat, k\u00f6nnen auf einem Server 4 Aufgaben mit diesem Container ausgef\u00fchrt werden. CPU-Einheiten entsprechen immer der Anzahl der Kerne, sie k\u00f6nnen nicht geringf\u00fcgig geringer sein wie im Fall von Speicher.<\/p>\n
<\/p>\n
Befehl<\/strong> \u2014 der Befehl zum Starten des Dienstes innerhalb des Containers, alle Parameter werden durch Kommas angegeben. Das kann gunicorn, npm etc. sein. Wenn nichts angegeben ist, wird der Wert der CMD-Direktive aus dem Dockerfile verwendet. Wir geben an npm,start<\/code>.<\/p>\n
<\/p>\n
Umgebungsvariablen<\/strong> \u2014 die Umgebungsvariablen des Containers. Dies k\u00f6nnen sowohl einfache Textdaten als auch geheime Variablen aus dem Secrets Manager<\/a><\/noindex> oder Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Speicherung und Protokollierung<\/strong> \u2014 hier konfigurieren wir das Logging in CloudWatch Logs (ein Logging-Dienst von AWS). Dazu reicht es, das Kontrollk\u00e4stchen Auto-configure CloudWatch Logs zu aktivieren. Nach der Erstellung der Task Definition wird automatisch eine Protokollgruppe in CloudWatch erstellt. Standardm\u00e4\u00dfig werden die Protokolle dort unbegrenzt gespeichert; ich empfehle, den Aufbewahrungszeitraum von Never Expire auf den gew\u00fcnschten Zeitraum zu \u00e4ndern. Dies geschieht in den CloudWatch-Protokollgruppen, man muss auf den aktuellen Zeitraum klicken und einen neuen ausw\u00e4hlen.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
ECS-Cluster und ECS Capacity Provider<\/h3>\n
<\/p>\n
Gehen Sie zum Bereich ECS \u2192 Cluster, um einen Cluster zu erstellen. W\u00e4hlen Sie als Vorlage EC2 Linux + Networking.<\/p>\n
<\/p>\n
Clustername<\/strong> \u2014 sehr wichtig, verwenden Sie hier denselben Namen wie im Launch Template im Parameter ECS_CLUSTER<\/code>, in unserem Fall \u2014 DemoApiClusterProd<\/code>. Setzen Sie das H\u00e4kchen bei Create an empty cluster. Optional k\u00f6nnen Sie Container Insights aktivieren, um die Metriken der Dienste in CloudWatch zu betrachten. Wenn Sie alles richtig gemacht haben, sehen Sie im Bereich ECS Instances die Maschinen, die in der Auto Scaling-Gruppe erstellt wurden.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Gehen Sie zum Tab Capacity Providers<\/strong> und erstellen Sie einen neuen. Denken Sie daran, dass dieser ben\u00f6tigt wird, um die Erstellung und das Herunterfahren von Maschinen je nach Anzahl der aktiven ECS-Tasks zu steuern. Es ist wichtig zu beachten, dass der Provider nur an eine Gruppe gebunden werden kann.<\/p>\n
<\/p>\n
Auto Scaling-Gruppe<\/strong> \u2014 w\u00e4hlen Sie die zuvor erstellte Gruppe aus.<\/p>\n
<\/p>\n
Managed Scaling<\/strong> \u2014 aktivieren, damit der Provider den Dienst skalieren kann.<\/p>\n
<\/p>\n
Target capacity %<\/strong> \u2014 welcher Prozentsatz der Maschinenlasten ben\u00f6tigen wir f\u00fcr Aufgaben. Wenn wir 100 % angeben, sind alle Maschinen immer mit aktiven Aufgaben besch\u00e4ftigt. Bei 50 % sind die H\u00e4lfte der Maschinen immer frei. In diesem Fall werden bei einem pl\u00f6tzlichen Anstieg der Last neue Aufgaben sofort auf die freien Maschinen geleitet, ohne dass es notwendig ist, auf die Bereitstellung von Instanzen zu warten.<\/p>\n
<\/p>\n
Verwalteter Terminierungsschutz<\/strong> \u2014 aktivieren, diese Einstellung erlaubt dem Provider, den Schutz der Instanzen vor L\u00f6schung aufzuheben. Dies geschieht, wenn auf der Maschine keine aktiven Aufgaben vorhanden sind und erm\u00f6glicht Target capacity %.<\/p>\n
<\/p>\n
ECS-Service und Skalierungseinstellungen<\/h3>\n
<\/p>\n
Der letzte Schritt :) Um einen Dienst zu erstellen, m\u00fcssen Sie in den zuvor erstellten Cluster auf die Registerkarte Dienste gehen.<\/p>\n
<\/p>\n
Starttyp<\/strong> \u2014 m\u00fcssen Sie auf Switch to capacity provider strategy klicken und den zuvor erstellten Provider ausw\u00e4hlen.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Aufgabenbeschreibung<\/strong> \u2014 w\u00e4hlen Sie die zuvor erstellte Aufgabenbeschreibung und deren Revision aus.<\/p>\n
<\/p>\n
Service-Name<\/strong> \u2014 um Verwirrung zu vermeiden, geben wir immer die gleiche an wie die Aufgabenbeschreibung.<\/p>\n
<\/p>\n
Diensttyp<\/strong> \u2014 immer Replica.<\/p>\n
<\/p>\n
Anzahl der Aufgaben<\/strong> \u2014 die gew\u00fcnschte Anzahl aktiver Aufgaben im Dienst. Diese Einstellung wird durch die Skalierung verwaltet, muss aber trotzdem angegeben werden.<\/p>\n
<\/p>\n
Minimale gesunde Prozentzahl<\/strong> und Maximale Prozentzahl<\/strong> \u2014 bestimmen das Verhalten der Aufgaben w\u00e4hrend des Deployments. Die Standardwerte von 100 und 200 bedeuten, dass sich w\u00e4hrend des Deployments die Anzahl der Aufgaben vervielfacht und anschlie\u00dfend wieder auf den gew\u00fcnschten Wert zur\u00fcckkehrt. Wenn Sie 1 Aufgabe haben, min=0 und max=100, wird diese w\u00e4hrend des Deployments beendet und danach wird eine neue gestartet, was zu einer Unterbrechung f\u00fchrt. Bei 1 Aufgabe, min=50 und max=150, findet das Deployment \u00fcberhaupt nicht statt, da eine Aufgabe nicht halbiert oder um das 1,5-fache erh\u00f6ht werden kann.<\/p>\n
<\/p>\n
Deploymentsart<\/strong> \u2014 wir lassen Rolling Update.<\/p>\n
<\/p>\n
Platzierungsvorlagen<\/strong> \u2014 Regeln zur Platzierung von Aufgaben auf Maschinen. Standardm\u00e4\u00dfig wird AZ Balanced Spread verwendet, was bedeutet, dass jede neue Aufgabe auf einer neuen Instanz platziert wird, bis die Maschinen in allen Verf\u00fcgbarkeitszonen gestartet sind. Wir verwenden normalerweise BinPack \u2014 CPU und Spread \u2014 AZ; mit dieser Politik werden die Aufgaben so dicht wie m\u00f6glich auf einer Maschine pro CPU platziert. Bei Bedarf wird eine neue Maschine in einer neuen Verf\u00fcgbarkeitszone erstellt.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Lastenausgleichstyp<\/strong> \u2014 wir w\u00e4hlen den Application Load Balancer.<\/p>\n
<\/p>\n
Service IAM-Rolle<\/strong> \u2014 wir w\u00e4hlen ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Name des Lastenausgleichs<\/strong> \u2014 wir w\u00e4hlen den zuvor erstellten Lastenausgleichs.<\/p>\n
<\/p>\n
Grace-Periode f\u00fcr Gesundheitspr\u00fcfungen<\/strong> \u2014 Pause vor der Durchf\u00fchrung von \u00dcberpr\u00fcfungen zur Funktionsf\u00e4higkeit nach dem Rollout einer neuen Aufgabe, wir setzen normalerweise 60 Sekunden.<\/p>\n
<\/p>\n
Container zum Lastenausgleich<\/strong> \u2014 im Feld Zielgruppennamen w\u00e4hlen wir die zuvor erstellte Gruppe aus, und alles wird automatisch ausgef\u00fcllt.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Service Auto Scaling<\/strong> \u2014 Parameter f\u00fcr die Skalierung des Dienstes. Wir w\u00e4hlen 'Configure Service Auto Scaling', um die gew\u00fcnschte Anzahl Ihrer Dienste anzupassen. Legen Sie die minimalen und maximalen Aufgabenanzahlen bei der Skalierung fest.<\/p>\n
<\/p>\n
IAM-Rolle f\u00fcr Service Auto Scaling<\/strong> \u2014 wir w\u00e4hlen AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Automatische Skalierungsrichtlinien f\u00fcr Aufgaben<\/strong> \u2014 Regeln f\u00fcr das Scaling. Es gibt 2 Typen:<\/p>\n
<\/p>\n
    \n
  1. Target-Tracking<\/strong> \u2014 Verfolgung einer Zielmetrik (CPU\/RAM-Nutzung oder Anzahl der Anfragen pro Aufgabe). Zum Beispiel wollen wir, dass die durchschnittliche CPU-Auslastung 85 % betr\u00e4gt. Wenn sie dar\u00fcber liegt, werden neue Aufgaben hinzugef\u00fcgt, bis der Zielwert erreicht ist. Liegt die Auslastung darunter, werden Aufgaben entfernt, es sei denn, die Skalierungsschutzfunktion ist deaktiviert (Scale-in deaktivieren<\/strong>).<\/li>\n
  2. Stufenskalierung<\/strong> \u2014 Reaktion auf ein beliebiges Ereignis. Hier k\u00f6nnen Sie eine Reaktion auf jedes Ereignis (CloudWatch Alarm) einrichten, sobald es eintritt. Sie k\u00f6nnen eine bestimmte Anzahl von Tasks hinzuf\u00fcgen oder entfernen oder auch eine genaue Anzahl von Tasks festlegen.<\/li>\n<\/ol>\n
    <\/p>\n
    Der Dienst kann mehrere Skalierungsregeln haben, was n\u00fctzlich sein kann. Wichtig ist, darauf zu achten, dass sie sich nicht gegenseitig behindern.<\/p>\n
    <\/p>\n
    Fazit<\/h2>\n
    <\/p>\n
    Wenn Sie die Anweisungen befolgt und dasselbe Docker-Image verwendet haben, sollte Ihr Dienst diese Seite zur\u00fcckgeben.<\/p>\n
    <\/p>\n
    \"Erstellung<\/p>\n
    <\/p>\n
      \n
    1. Wir haben eine Vorlage erstellt, auf deren Grundlage alle Maschinen im Dienst gestartet werden. Zudem haben wir gelernt, die Maschinen bei \u00c4nderungen an der Vorlage zu aktualisieren.<\/li>\n
    2. Wir haben die Verarbeitung des Stoppsignals f\u00fcr Spot-Instanzen eingerichtet. Daher werden innerhalb einer Minute nach Erhalt alle aktiven Tasks von der Maschine entfernt, sodass nichts verloren geht und keine Unterbrechung entsteht.<\/li>\n
    3. Wir haben einen Lastenausgleich eingerichtet, um die Last gleichm\u00e4\u00dfig auf die Maschinen zu verteilen.<\/li>\n
    4. Wir haben einen Dienst geschaffen, der auf Spot-Instanzen l\u00e4uft, wodurch die Kosten f\u00fcr Maschinen um etwa das Dreifache gesenkt werden.<\/li>\n
    5. Wir haben das automatische Scaling in beide Richtungen eingerichtet, um steigende Lasten zu bew\u00e4ltigen, ohne gleichzeitig f\u00fcr Leerlauf zu zahlen.<\/li>\n
    6. Wir nutzen einen Capacity Provider, damit die Anwendung die Infrastruktur (Server) verwaltet und nicht umgekehrt.<\/li>\n
    7. Wir machen das gut.<\/li>\n<\/ol>\n
      <\/p>\n
      Wenn Sie vorhersehbare Lastspitzen haben, beispielsweise durch eine gro\u00dfe E-Mail-Kampagne, k\u00f6nnen Sie das Scaling einfach nach Zeitplan<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      einrichten. Es ist auch m\u00f6glich, das Scaling auf Basis von Daten aus verschiedenen Teilen Ihres Systems zu steuern. Zum Beispiel haben wir die Funktionalit\u00e4t f\u00fcr das Versenden individueller Promotionen<\/a><\/noindex> an die Nutzer unserer mobilen Anwendung. Manchmal wird eine Kampagne an \u00fcber 1 Million Personen versendet. Nach einer solchen Aktion beobachten wir immer einen starken Anstieg der API-Anfragen, da viele Nutzer gleichzeitig die App \u00f6ffnen. Wenn wir sehen, dass die Warteschlange f\u00fcr das Versenden von Promo-Push-Nachrichten deutlich h\u00f6her ist als die \u00fcblichen Werte, k\u00f6nnen wir sofort mehrere zus\u00e4tzliche Maschinen und Tasks starten, um auf die Last vorbereitet zu sein.<\/p>\n
      <\/p>\n
      Ich w\u00fcrde mich freuen, wenn Sie in den Kommentaren interessante Anwendungsf\u00e4lle von Spot-Instanzen und ECS oder etwas \u00fcber das Scaling erz\u00e4hlen.<\/p>\n
      <\/p>\n
      Bald werden Artikel dar\u00fcber ver\u00f6ffentlicht, wie wir Tausende von Analyse-Events pro Sekunde auf einem \u00fcberwiegend serverlosen Stack (mit Kosteneffizienz) verarbeiten und wie der Deployment-Prozess von Services mittels GitLab CI und Terraform Cloud gestaltet wird.<\/p>\n
      <\/p>\n
      Folgen Sie uns, es wird spannend!<\/p>\n
      Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte melden Sie sich an.<\/a><\/noindex>Sind Sie an Contour interessiert?<\/p>\n
      Nutzen Sie Spot-Instanzen in der Produktion?<\/h2>\n