{"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! Ich bin Kirill, CTO bei Adapty. Der Gro\u00dfteil unserer Architektur l\u00e4uft auf AWS, und heute werde ich erl\u00e4utern, wie wir unsere Serverkosten um das Dreifache gesenkt haben, indem wir Spot-Instanzen in unserer Produktionsumgebung verwendet haben, sowie wie man ihre automatische Skalierung einrichtet. Zuerst gibt es einen \u00dcberblick, wie das funktioniert, gefolgt von einer detaillierten Anleitung zum Start.<\/p>\n

<\/p>\n

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

<\/p>\n

Spot-<\/a><\/noindex> Instanzen sind Server anderer AWS-Nutzer, die derzeit ungenutzt sind und diese zu einem gro\u00dfen Rabatt verkaufen (Amazon gibt bis zu 90% an, nach unserer Erfahrung etwa 3x, variiert je nach Region, AZ und Instanztyp). Das Hauptunterscheidungsmerkmal zu regul\u00e4ren Instanzen ist, dass sie jederzeit abgeschaltet werden k\u00f6nnen. Daher dachten wir lange, dass es in Ordnung sei, sie f\u00fcr Entwicklungsumgebungen oder f\u00fcr Berechnungsaufgaben zu verwenden, wobei die Zwischenergebnisse in S3 oder einer Datenbank gespeichert werden, aber nicht f\u00fcr Produktionen. Es gibt Drittanbieter-L\u00f6sungen, die die Verwendung von Spot-Instanzen in Produktionen erm\u00f6glichen, aber in unserem Fall gibt es viele Probleme mit diesen, 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 werde ich einige Screenshots zeigen, die die Preisentwicklung von Spot-Instanzen verdeutlichen.<\/p>\n

<\/p>\n

m5.large in der Region eu-west-1 (Irland). Der Preis ist \u00fcber einen Zeitraum von 3 Monaten \u00fcberwiegend stabil, derzeit liegt die Einsparung bei 2,9x.<\/p>\n

<\/p>\n

\"Erstellung<\/p>\n

<\/p>\n

m5.large in der Region us-east-1 (N. Virginia). Der Preis \u00e4ndert sich st\u00e4ndig \u00fcber einen Zeitraum von 3 Monaten, gegenw\u00e4rtig liegt die Einsparung zwischen 2,3x und 2,8x, je nach Verf\u00fcgbarkeitszone.<\/p>\n

<\/p>\n

\"Erstellung<\/p>\n

<\/p>\n

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

<\/p>\n

\"Erstellung<\/p>\n

<\/p>\n

Architektur des Dienstes<\/h2>\n

<\/p>\n

Die Grundarchitektur des Dienstes, \u00fcber den wir in diesem Artikel sprechen werden, ist im folgenden Diagramm 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 Lastverteilung wird der Application Load Balancer (ALB) verwendet, der Anfragen an die EC2 Target Group (TG) weiterleitet. Die TG sorgt daf\u00fcr, dass die Ports auf den Instanzen f\u00fcr den ALB ge\u00f6ffnet werden und sie mit den Ports der Container des Elastic Container Service (ECS) verbunden sind. ECS ist das Pendant zu Kubernetes in AWS, das das Management von Docker-Containern \u00fcbernimmt.<\/p>\n

<\/p>\n

Auf einer Instanz k\u00f6nnen mehrere Container mit denselben Ports ausgef\u00fchrt werden, weshalb wir diese nicht festlegen k\u00f6nnen. ECS teilt TG mit, dass es eine neue Aufgabe startet (in der Terminologie von Kubernetes wird dies als Pod bezeichnet), TG pr\u00fcft die verf\u00fcgbaren Ports auf der Instanz und weist einen davon f\u00fcr die gestartete Aufgabe zu. Au\u00dferdem \u00fcberpr\u00fcft TG regelm\u00e4\u00dfig, ob die Instanz und die API darauf funktionieren, indem es Health Checks durchf\u00fchrt, und wenn es Probleme feststellt, h\u00f6rt es auf, Anfragen dorthin zu senden.<\/p>\n

<\/p>\n

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

<\/p>\n

In dem obigen Diagramm wurde der Dienst EC2 Auto Scaling Groups (ASG) nicht dargestellt. Aus dem Namen kann man entnehmen, dass er f\u00fcr das Skalieren der Instanzen verantwortlich ist. Bis vor kurzem gab es in AWS keine integrierte M\u00f6glichkeit, die Anzahl der von ECS gestarteten Maschinen zu verwalten. ECS erlaubte es, die Anzahl der Aufgaben basierend auf der CPU-Nutzung, RAM oder der Anzahl der Anfragen zu skalieren. Wenn jedoch alle freien Instanzen von Aufgaben belegt waren, wurden keine neuen Maschinen automatisch gestartet.<\/p>\n

<\/p>\n

Das hat sich mit der Einf\u00fchrung von ECS Capacity Providers (ECS CP) ge\u00e4ndert. Jetzt kann jeder Dienst in ECS mit ASG verbunden werden, und wenn die Aufgaben nicht auf den laufenden Instanzen Platz finden, werden neue gestartet (aber innerhalb der festgelegten ASG-Grenzen). Das funktioniert auch umgekehrt: Wenn ECS CP ungenutzte Instanzen ohne Aufgaben sieht, gibt es ASG den Befehl, diese abzuschalten. ECS CP hat die M\u00f6glichkeit, einen Zielauslastungsprozentsatz f\u00fcr die Instanzen anzugeben, damit immer eine bestimmte Anzahl von Maschinen frei bleibt, um die Aufgaben schnell zu skalieren, mehr dazu sp\u00e4ter.<\/p>\n

<\/p>\n

EC2 Launch Templates<\/h3>\n

<\/p>\n

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

<\/p>\n

Einer der wichtigsten Parameter in diesem Artikel ist die Konfiguration \u2014 ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Wenn diese Option aktiviert ist, wechselt ECS, sobald es ein Signal erh\u00e4lt, dass der Spot-Instance zur\u00fcckgenommen wird, alle Aufgaben, die darauf ausgef\u00fchrt werden, in den Status Draining. Es werden keine neuen Aufgaben auf diese Instanz zugewiesen, und wenn Aufgaben derzeit darauf ausgef\u00fchrt werden sollen, werden sie abgebrochen. Anfragen vom Load Balancer kommen ebenfalls nicht mehr an. Die Benachrichtigung \u00fcber das Entfernen der Instanz erfolgt 2 Minuten vor dem tats\u00e4chlichen Ereignis. Wenn Ihr Dienst also keine Aufgaben l\u00e4nger als 2 Minuten ausf\u00fchrt und nichts auf der Festplatte speichert, k\u00f6nnen Sie Spot-Instanzen ohne Datenverlust nutzen.<\/p>\n

<\/p>\n

Bez\u00fcglich der Festplatte \u2013 AWS hat k\u00fcrzlich erm\u00f6glicht<\/a><\/noindex> die Verwendung des Elastic File System (EFS) zusammen mit ECS. Mit diesem Schema ist selbst die Festplatte kein Hindernis, aber wir haben das nicht ausprobiert, da wir im Grunde keine Festplatte zur Speicherung des Status ben\u00f6tigen. Standardm\u00e4\u00dfig werden nach Erhalt von SIGINT (das zum Zeitpunkt des Wechsels der Aufgabe in den Status Draining gesendet wird) alle aktiven Aufgaben nach 30 Sekunden gestoppt, selbst wenn sie nicht abgeschlossen sind. Diese Zeit kann mit dem Parameter ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>ge\u00e4ndert werden. Wichtig ist, ihn nicht auf mehr als 2 Minuten f\u00fcr Spot-Maschinen zu setzen.<\/p>\n

<\/p>\n

Erstellung des Dienstes<\/h2>\n

<\/p>\n

Wir gehen jetzt direkt zur Erstellung des beschriebenen Dienstes \u00fcber. Dabei werde ich einige n\u00fctzliche Punkte beschreiben, die oben nicht erw\u00e4hnt wurden. Insgesamt handelt es sich um eine Schritt-f\u00fcr-Schritt-Anleitung, aber ich werde sehr grundlegende oder sehr spezifische F\u00e4lle nicht behandeln. Alle Aktionen werden \u00fcber die visuelle AWS-Konsole ausgef\u00fchrt, k\u00f6nnen aber auch programmgesteuert mit CloudFormation oder Terraform reproduziert werden. Bei Adapty verwenden wir Terraform.<\/p>\n

<\/p>\n

EC2 Launch Template<\/strong><\/h3>\n

<\/p>\n

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

<\/p>\n

Amazon Machine Image (AMI)<\/strong> \u2013 wir geben das Disk-Image an, mit dem alle Instanzen gestartet werden. F\u00fcr ECS sollte in den meisten F\u00e4llen das von Amazon optimierte Image verwendet werden. Es wird regelm\u00e4\u00dfig aktualisiert und enth\u00e4lt alles, was f\u00fcr den Betrieb von ECS erforderlich ist. Um die aktuelle ID des Images zu erfahren, gehen wir auf die Seite Amazon ECS-optimized AMIs<\/a><\/noindex>, w\u00e4hlen die verwendete Region aus und kopieren die AMI-ID daf\u00fcr. Zum Beispiel, f\u00fcr die Region us-east-1 ist zu dem Zeitpunkt, zu dem dieser Artikel geschrieben wurde, die aktuelle ID \u2013 ami-00c7c1cf5bdc913ed<\/em>. Diese ID muss in den Punkt Specify a custom value eingef\u00fcgt werden.<\/p>\n

<\/p>\n

Instanztyp<\/strong> \u2014 der Typ der Instanz wird angegeben. W\u00e4hlen Sie den, der am besten zu Ihrer Aufgabe passt.<\/p>\n

<\/p>\n

Schl\u00fcsselpaar (Login)<\/strong> \u2014 das Zertifikat, mit dem eine Verbindung zur Instanz \u00fcber SSH hergestellt werden kann, falls erforderlich.<\/p>\n

<\/p>\n

Netzwerkeinstellungen<\/strong> \u2014 die Netzparameter werden angegeben. Netzwerktechnologie<\/strong> in den meisten F\u00e4llen sollte es sich um ein Virtual Private Cloud (VPC) handeln. Sicherheitsgruppen<\/strong> \u2014 Sicherheitsgruppen f\u00fcr Ihre Instanzen. Da wir einen Load Balancer vor den Instanzen verwenden werden, empfehle ich, hier eine Gruppe anzugeben, die eingehende Verbindungen nur vom Load Balancer zul\u00e4sst. Das bedeutet, dass Sie 2 Sicherheitsgruppen haben werden: eine f\u00fcr den Load Balancer, die eingehende (Inbound) Verbindungen von \u00fcberall \u00fcber die Ports 80 (http) und 443 (https) erlaubt, und eine zweite f\u00fcr die Maschinen, die eingehende Verbindungen \u00fcber alle Ports von der Gruppe des Load Balancers erlaubt. Ausgehende (Outbound) Verbindungen in beiden Gruppen m\u00fcssen \u00fcber das TCP-Protokoll auf alle Ports zu allen Adressen ge\u00f6ffnet sein. Es ist m\u00f6glich, die Ports und Adressen f\u00fcr ausgehende Verbindungen einzuschr\u00e4nken, aber dann m\u00fcssen Sie st\u00e4ndig \u00fcberwachen, dass Sie nicht versuchen, auf einen geschlossenen Port zuzugreifen.<\/p>\n

<\/p>\n

Speicher (Volumen)<\/strong> \u2014 die Plattenparameter f\u00fcr die Maschinen werden angegeben. Der Plattenumfang darf nicht kleiner sein als der, der in der AMI angegeben ist, f\u00fcr ECS-Optimierte \u2014 30 GiB.<\/p>\n

<\/p>\n

Erweiterte Details<\/strong> \u2014 zus\u00e4tzliche Parameter werden angegeben.<\/p>\n

<\/p>\n

Kaufoption<\/strong> \u2014 ob wir Spot-Instanzen kaufen m\u00f6chten. Wir m\u00f6chten das, aber hier werden wir dieses Kontrollk\u00e4stchen nicht aktivieren, wir konfigurieren es in der Auto Scaling Group, dort gibt es mehr Optionen.<\/p>\n

<\/p>\n

IAM-Instanzprofil<\/strong> \u2014 die Rolle angeben, mit der die Instanzen gestartet werden. Damit die Instanzen in ECS funktionieren, ben\u00f6tigen sie Rechte, die normalerweise in der Rolle ecsInstanceRole<\/em>liegen. In einigen F\u00e4llen kann sie erstellt werden, falls sie nicht existiert, dann hier Anleitung<\/a><\/noindex> finden Sie Informationen, wie das geht. Nach der Erstellung geben wir sie im Template an.
\nDanach folgen viele Parameter, die in der Regel auf den Standardwerten belassen werden k\u00f6nnen, aber jeder von ihnen hat eine verst\u00e4ndliche Beschreibung. Ich aktiviere immer die Parameter EBS-optimierte Instanz und T2\/T3 Unlimited, wenn verwendet werden. burstable<\/a><\/noindex> Instanzen.<\/p>\n

<\/p>\n

Benutzerdaten<\/strong> \u2014 die Benutzerdaten werden angegeben. Wir werden die Datei \/etc\/ecs\/ecs.config<\/code>bearbeiten, in der die Konfiguration des ECS-Agenten gespeichert ist.
\nEin Beispiel, wie die Benutzerdaten aussehen k\u00f6nnen:<\/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 Der Parameter gibt an, dass die Instanz zu einem Cluster mit dem angegebenen Namen geh\u00f6rt, d.h. dieses Cluster kann seine Aufgaben auf diesem Server hosten. Wir haben bisher noch keinen Cluster erstellt, werden jedoch beim Erstellen diesen Namen verwenden.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 Der Parameter gibt an, dass alle Aufgaben auf der Spot-Instanz beim Empfang des Abschaltsignals in den Status Draining versetzt werden sollen.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 Der Parameter gibt an, dass nach 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 Der Parameter gibt an, dass das Docker-Schema als Authentifizierungsmechanismus verwendet wird.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 Verbindungseinstellungen zu einem privaten Container-Registry, in dem Ihre Docker-Images gespeichert werden. Wenn es \u00f6ffentlich ist, m\u00fcssen keine Angaben gemacht werden.<\/p>\n
<\/p>\n
Im Rahmen dieses Artikels werde ich ein \u00f6ffentliches Bild aus dem Docker Hub verwenden, daher sind keine Angaben n\u00f6tig. ECS_ENGINE_AUTH_TYPE<\/code> und ECS_ENGINE_AUTH_DATA<\/code> sind nicht erforderlich.<\/p>\n
<\/p>\n
N\u00fctzliche Informationen<\/strong>: Es wird empfohlen, AMIs regelm\u00e4\u00dfig zu aktualisieren, da neue Versionen Docker, Linux, ECS-Agenten usw. aktualisieren. Um dies nicht zu vergessen, k\u00f6nnen Sie Benachrichtigungen einstellen<\/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-Vorlage<\/strong> \u2014 W\u00e4hlen Sie die im vorherigen Schritt erstellte Vorlage aus. Die Version bleibt auf der Standard-Einstellung.<\/p>\n
<\/p>\n
Kaufoptionen und Instanztypen<\/strong> \u2014 Geben Sie die Instanztypen f\u00fcr das Cluster an. Adhere to launch template verwendet den Instanztyp aus der Launch-Vorlage. Combine purchase options and instance types erm\u00f6glicht eine flexible Konfiguration der Instanztypen. Wir werden dies verwenden.<\/p>\n
<\/p>\n
Optionale On-Demand-Basis<\/strong> \u2014 Die Anzahl der normalen, nicht-Spot-Instanzen, die immer laufen werden.<\/p>\n
<\/p>\n
On-Demand-Prozentsatz \u00fcber der Basis<\/strong> \u2014 Das prozentuale Verh\u00e4ltnis von normalen und Spot-Instanzen; 50-50 wird gleichm\u00e4\u00dfig verteilen, 20-80 bedeutet, dass auf jede normale Instanz 4 Spot-Instanzen hochgefahren werden. Im Rahmen dieses Beispiels werde ich 50-50 angeben, aber in der Realit\u00e4t machen wir h\u00e4ufig 20-80, 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, weil ich den Sinn dieser Geschichte nicht ganz verstehe. Vielleicht liegt es an den Limits f\u00fcr bestimmte Instanztypen, aber diese lassen sich leicht \u00fcber den Support erh\u00f6hen. Wenn Sie eine Anwendung kennen, 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, Sie w\u00e4hlen VPC und Subnetze f\u00fcr die Maschinen aus, in den meisten F\u00e4llen sollten alle verf\u00fcgbaren Subnetze ausgew\u00e4hlt werden.<\/p>\n
<\/p>\n
Lastverteilung<\/strong> \u2014 Einstellungen f\u00fcr den Load Balancer, aber das werden wir separat machen, hier r\u00fchren wir nichts an. Health Checks<\/strong> werden ebenfalls sp\u00e4ter eingerichtet.<\/p>\n
<\/p>\n
Gruppengr\u00f6\u00dfe<\/strong> \u2014 wir geben die Limits f\u00fcr die Anzahl der Maschinen im Cluster und die gew\u00fcnschte Anzahl der Maschinen beim Start an. Die Anzahl der Maschinen im Cluster wird nie kleiner sein als die minimal angegebene und nie gr\u00f6\u00dfer als die maximale, selbst wenn das Scaling nach Metriken erfolgen sollte.<\/p>\n
<\/p>\n
Scaling-Richtlinien<\/strong> \u2014 Skalierungseinstellungen, aber wir werden die Skalierung basierend auf den laufenden ECS-Tasks vornehmen, daher werden wir die Skalierung sp\u00e4ter einstellen.<\/p>\n
<\/p>\n
Instanz-Skalierungsschutz<\/strong> \u2014 Schutz von Instanzen vor L\u00f6schung beim Downscaling. Wir aktivieren dies, damit ASG die Maschine, auf der aktive Tasks laufen, nicht l\u00f6scht. Der Schutz wird f\u00fcr Instanzen ohne Tasks von der ECS Capacity Provider deaktiviert.<\/p>\n
<\/p>\n
Tags hinzuf\u00fcgen<\/strong> \u2014 Sie k\u00f6nnen Tags f\u00fcr Instanzen angeben (daf\u00fcr muss das Kontrollk\u00e4stchen 'Neue Instanzen taggen' aktiviert sein). Ich empfehle, das Tag 'Name' anzugeben, sodass alle Instanzen, die innerhalb der Gruppe gestartet werden, denselben Namen haben, was die Anzeige in der Konsole erleichtert.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Nach der Erstellung der Gruppe \u00f6ffnen Sie diese und gehen Sie zu den erweiterten Konfigurationen, warum bei der Erstellung in der Konsole nicht alle Optionen sichtbar sind.<\/p>\n
<\/p>\n
Beendigungsrichtlinien<\/strong> \u2014 Regeln, die beim L\u00f6schen von Instanzen ber\u00fccksichtigt werden. Sie werden in der Reihenfolge angewendet. Wir verwenden normalerweise solche wie auf dem 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, aber alle Instanzen wurden rechtzeitig darauf umgestellt). Dann werden die Instanzen ausgew\u00e4hlt, die dem n\u00e4chsten Abrechnungszeitpunkt am n\u00e4chsten sind. Und weiter werden die \u00e4ltesten nach dem Startdatum ausgew\u00e4hlt.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
N\u00fctzliche Informationen<\/strong>: um alle Maschinen im Cluster zu aktualisieren, ist es sinnvoll, Instanz-Refresh<\/a><\/noindex>. Wenn Sie dies mit der Lambda-Funktion aus dem vorherigen Schritt kombinieren, erhalten Sie ein vollst\u00e4ndig automatisiertes Update-System f\u00fcr Instanzen. Vor der Aktualisierung aller Maschinen m\u00fcssen Sie den Schutz vor dem Skalieren von Instanzen f\u00fcr alle Instanzen in der Gruppe deaktivieren. Dies bezieht sich auf den Schutz der Maschinen selbst, diesen Schritt f\u00fchren Sie im Tab f\u00fcr das Instantenmanagement durch.<\/p>\n
<\/p>\n
Application Load Balancer und EC2 Zielgruppe<\/h3>\n
<\/p>\n
Der Lastenausgleich wird im Bereich EC2 \u2192 Load Balancing \u2192 Load Balancers erstellt. Wir werden den Application Load Balancer verwenden. Einen Vergleich verschiedener Arten von Lastenausgleich finden Sie auf der Service-Seite<\/a><\/noindex>.<\/p>\n
<\/p>\n
Listener<\/strong> \u2014 es macht Sinn, die Ports 80 und 443 zu erstellen und eine Weiterleitung von 80 nach 443 mit sp\u00e4teren Regeln des Lastenausgleichs 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 Option ist es, ein Zertifikat in ACM zu erstellen. Um die Unterschiede zu<\/a><\/noindex> der Sicherheitsrichtlinie k\u00f6nnen Sie auf<\/strong> lesen, Sie k\u00f6nnen die standardm\u00e4\u00dfig ausgew\u00e4hlte Option belassen, Dokumentation<\/a><\/noindex>ELBSecurityPolicy-2016-08 . Nach der Erstellung des Lastenausgleichs sehen Sie dessen<\/code>DNS-Namen , f\u00fcr den Sie einen CNAME f\u00fcr Ihre Domain einrichten m\u00fcssen. So sieht es beispielsweise in Cloudflare aus.<\/strong>\u2014 erstellen oder w\u00e4hlen Sie eine Sicherheitsgruppe f\u00fcr den Lastenausgleich, weitere Einzelheiten dazu finden Sie etwas weiter oben im Abschnitt EC2 Launch Template \u2192 Netzwerkeinstellungen.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Security Group<\/strong> Zielgruppe<\/p>\n
<\/p>\n
\u2014 erstellen Sie eine Gruppe, die f\u00fcr das Routing von Anfragen vom Lastenausgleich zu den Maschinen verantwortlich ist und deren Verf\u00fcgbarkeit \u00fcberpr\u00fcft, um sie bei Problemen zu ersetzen.<\/strong> Typ der Zielgruppe muss Instance sein,<\/strong> beliebig, wenn Sie HTTPS f\u00fcr die Kommunikation zwischen dem Lastenausgleich und den Instanzen verwenden, m\u00fcssen Sie das Zertifikat auf diesen hochladen. In diesem Beispiel werden wir dies nicht tun, sondern einfach Port 80 belassen. Protokoll<\/strong> und Port<\/strong> \u2014 Parameter zur \u00dcberpr\u00fcfung der Dienstverf\u00fcgbarkeit. In einem echten Dienst sollte dies eine separate Anfrage sein, die wichtige Teile der Gesch\u00e4ftsanwendung implementiert. In diesem Beispiel lasse ich die Standardeinstellungen. Danach k\u00f6nnen Sie das Anfragenintervall, die Zeit\u00fcberschreitung, die Codes f\u00fcr erfolgreiche Antworten usw. ausw\u00e4hlen. In unserem Beispiel geben wir die Erfolgs-Codes 200-399 an, da das Docker-Image, das verwendet wird, den Code 304 zur\u00fcckgibt.<\/p>\n
<\/p>\n
Health Checks<\/strong> Ziele registrieren<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
\u2014 hier w\u00e4hlen Sie die Maschinen f\u00fcr die Gruppe aus, aber in unserem Fall wird dies von ECS erledigt, daher \u00fcberspringen wir diesen Schritt einfach.<\/strong> : auf Ebene des Lastenausgleichs k\u00f6nnen Sie Protokolle aktivieren, die in S3 an einem bestimmten Ort gespeichert werden.<\/p>\n
<\/p>\n
N\u00fctzliche Informationen<\/strong>Auf der Ebene des Load Balancers k\u00f6nnen Protokolle aktiviert werden, die in S3 gespeichert werden. im SVG-Konturformat festgelegt wird.<\/a><\/noindex>. Von dort aus k\u00f6nnen sie in externe Dienstleistungen f\u00fcr Analysen exportiert werden, oder man kann SQL-Abfragen direkt auf die Daten in S3 mit Athena<\/a><\/noindex>. Das ist praktisch und funktioniert ohne zus\u00e4tzlichen Code. Ich empfehle au\u00dferdem, die Protokolldaten aus dem S3-Bucket nach Ablauf eines bestimmten Zeitraums zu l\u00f6schen.<\/p>\n
<\/p>\n
ECS Task Definition<\/h3>\n
<\/p>\n
In den vorherigen Schritten haben wir alles in Bezug auf die Infrastruktur des Dienstes erstellt, nun kommen wir zur Beschreibung der Container, die wir starten werden. Dies erfolgt im Abschnitt ECS \u2192 Task Definitions.<\/p>\n
<\/p>\n
Kompatibilit\u00e4tstyp des Startvorgangs<\/strong> \u2014 w\u00e4hlen Sie EC2.<\/p>\n
<\/p>\n
IAM-Rolle f\u00fcr die Taskausf\u00fchrung<\/strong> \u2014 w\u00e4hlen Sie ecsTaskExecutionRole<\/code>. Mit ihr werden Protokolle geschrieben, der Zugang zu geheimen Variablen gew\u00e4hrt usw.<\/p>\n
<\/p>\n
Im Abschnitt Container Definitions klicken wir auf Add Container.<\/p>\n
<\/p>\n
Bild<\/strong> \u2014 Link zum Image mit dem Code des Projekts, 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 Limits f\u00fcr den Speicher des Containers. Harter Limit<\/strong> \u2014 harter Limit, wenn der Container den angegebenen Wert \u00fcberschreitet, wird der Befehl docker kill ausgef\u00fchrt, der Container stirbt sofort. Weicher Limit<\/strong> \u2014 weicher Limit, der Container kann den angegebenen Wert \u00fcberschreiten, aber bei der Platzierung von Tasks auf den Maschinen wird dieser Parameter ber\u00fccksichtigt. Wenn beispielsweise auf der Maschine 4 GiB RAM vorhanden sind und das weiche Limit des Containers 2048 MiB betr\u00e4gt, k\u00f6nnen auf dieser Maschine maximal 2 Tasks mit diesem Container gestartet werden. Tats\u00e4chlich sind 4 GiB RAM etwas weniger als 4096 MiB, das kann man auf der Registerkarte ECS Instances im Cluster sehen. Das weiche Limit darf nicht gr\u00f6\u00dfer sein als das harte Limit. Wichtig zu verstehen ist, dass, wenn in einem Task mehrere Container vorhanden sind, deren Limits addiert werden.<\/p>\n
<\/p>\n
Portzuordnungen<\/strong> \u2014 bei Host-Port<\/strong> geben wir 0 an, das bedeutet, dass der Port dynamisch zugewiesen wird, er wird von der Target Group \u00fcberwacht. Container-Port<\/strong> \u2014 der Port, an dem Ihre Anwendung l\u00e4uft, wird oft im Ausf\u00fchrungsbefehl festgelegt oder im Code Ihrer Anwendung, Dockerfile usw. zugewiesen. F\u00fcr unser Beispiel verwenden wir 3000, weil er in der Dockerfile<\/a><\/noindex> verwendeten Abbildung angegeben ist.<\/p>\n
<\/p>\n
Health Check<\/strong> \u2014 Parameter zur \u00dcberpr\u00fcfung der Funktionsf\u00e4higkeit des Containers, nicht zu verwechseln mit dem, der in der Target Group konfiguriert ist.<\/p>\n
<\/p>\n
Umgebung<\/strong> \u2014 Umgebungsparameter. CPU-Einheiten<\/strong> \u2014 sieht \u00e4hnlich aus wie Memory-Limits, nur f\u00fcr die CPU. Jedes CPU-Kern entspricht 1024 Einheiten, daher k\u00f6nnen bei einem Server mit einer dual-core CPU und einem Wert von 512 f\u00fcr den Container insgesamt 4 Aufgaben mit diesem Container gestartet werden. CPU-Einheiten sind immer an die Anzahl der Kerne gebunden, es kann nicht leicht weniger wie bei dem Speicher sein.<\/p>\n
<\/p>\n
Befehl<\/strong> \u2014 Befehl zum Starten eines Dienstes innerhalb des Containers, alle Parameter werden durch ein Komma angegeben. Dies kann gunicorn, npm usw. sein. Wenn nicht angegeben, wird der Wert der CMD-Direktive aus der Dockerfile verwendet. Wir geben an npm,start<\/code>.<\/p>\n
<\/p>\n
Umgebungsvariablen<\/strong> \u2014 Umgebungsvariablen des Containers. Dies k\u00f6nnen sowohl einfache Textdaten als auch geheime Variablen aus Secrets Manager<\/a><\/noindex> oder Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Speicherung und Protokollierung<\/strong> \u2014 hier konfigurieren wir die Protokollierung in den CloudWatch Logs (AWS-Dienst f\u00fcr Protokolle). Dazu gen\u00fcgt es, das K\u00e4stchen Auto-configure CloudWatch Logs zu aktivieren. Nach dem Erstellen der Task-Definition wird automatisch eine Log-Gruppe 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 Log-Gruppen, 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-Kapazit\u00e4tsprovider<\/h3>\n
<\/p>\n
Wir gehen zum Abschnitt ECS \u2192 Clusters, um einen Cluster zu erstellen. Als Vorlage w\u00e4hlen wir EC2 Linux + Networking.<\/p>\n
<\/p>\n
Clustername<\/strong> \u2014 sehr wichtig, hier das gleiche Name wie im Launch Template im Parameter ECS_CLUSTER<\/code>, in unserem Fall \u2014 DemoApiClusterProd<\/code>. Wir aktivieren das K\u00e4stchen Create an empty cluster. Optional kann Container Insights aktiviert werden, um die Metriken der Dienste in CloudWatch zu sehen. Wenn Sie alles richtig gemacht haben, sehen Sie im Abschnitt ECS Instances die Maschinen, die in der Auto Scaling-Gruppe erstellt wurden.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Wechseln Sie zur Registerkarte Kapazit\u00e4tsanbieter<\/strong> und wir erstellen einen neuen. Ich erinnere daran, dass dieser ben\u00f6tigt wird, um die Erstellung und das Ausschalten von Maschinen abh\u00e4ngig von der Anzahl der laufenden ECS-Aufgaben zu verwalten. Es ist wichtig zu beachten, dass der Anbieter nur an eine Gruppe gebunden werden kann.<\/p>\n
<\/p>\n
Auto Scaling-Gruppe<\/strong> \u2014 wir w\u00e4hlen die zuvor erstellte Gruppe.<\/p>\n
<\/p>\n
Verwaltetes Scaling<\/strong> \u2014 aktivieren, damit der Anbieter den Dienst skalieren kann.<\/p>\n
<\/p>\n
Zielkapazit\u00e4t %<\/strong> \u2014 welcher Prozentsatz der Maschinenlast durch Aufgaben ben\u00f6tigt wird. Wenn 100% angegeben wird, sind alle Maschinen immer mit laufenden Aufgaben besch\u00e4ftigt. Wenn 50% angegeben wird, sind immer die H\u00e4lfte der Maschinen frei. In diesem Fall werden bei einem pl\u00f6tzlichen Anstieg der Last die neuen Aufgaben sofort auf die freien Maschinen verteilt, ohne auf die Bereitstellung von Instanzen warten zu m\u00fcssen.<\/p>\n
<\/p>\n
Verwalteter K\u00fcndigungsschutz<\/strong> \u2014 aktivieren, dieser Parameter erlaubt dem Anbieter, den Schutz von Instanzen vor der L\u00f6schung zu entfernen. Dies geschieht, wenn auf der Maschine keine aktiven Aufgaben vorhanden sind und erm\u00f6glicht Zielkapazit\u00e4ts %.<\/p>\n
<\/p>\n
ECS-Dienst und Skalierungseinstellungen<\/h3>\n
<\/p>\n
Letzter Schritt :) Um einen Dienst zu erstellen, muss man in den zuvor erstellten Cluster auf den Tab Dienste gehen.<\/p>\n
<\/p>\n
Starttyp<\/strong> \u2014 man muss auf \u201aWechseln zu Kapazit\u00e4tsanbieterstrategie\u2018 klicken und den zuvor erstellten Anbieter 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 dieselbe 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. Dieses Parameter wird durch die Skalierung gesteuert, muss aber dennoch angegeben werden.<\/p>\n
<\/p>\n
Minimaler gesunder Prozentsatz<\/strong> und Maximaler Prozentsatz<\/strong> \u2014 bestimmen das Verhalten der Aufgaben beim Deployment. Die Standardwerte von 100 und 200 bedeuten, dass sich die Anzahl der Aufgaben w\u00e4hrend des Deployments verdoppeln wird, bevor sie wieder auf das gew\u00fcnschte Niveau zur\u00fcckkehrt. Wenn Sie 1 Aufgabe haben, min=0 und max=100, wird die Aufgabe beim Deployment beendet und danach wird eine neue gestartet, es wird also eine Ausfallzeit geben. Wenn 1 Aufgabe aktiv ist, min=50, max=150, findet das Deployment nicht statt, da man die 1 Aufgabe nicht halbieren oder um eineinhalb erh\u00f6hen kann.<\/p>\n
<\/p>\n
Deploymenttyp<\/strong> \u2014 wir lassen Rolling update.<\/p>\n
<\/p>\n
Platzierungsvorlagen<\/strong> \u2014 Regeln f\u00fcr die Platzierung von Aufgaben auf Maschinen. Standardm\u00e4\u00dfig ist AZ Balanced Spread festgelegt \u2013 das bedeutet, dass jede neue Aufgabe auf eine neue Instanz gesetzt wird, bis alle Maschinen in allen Verf\u00fcgbarkeitszonen gestartet sind. Normalerweise verwenden wir BinPack \u2013 CPU und Spread \u2013 AZ, wobei die Aufgaben so nah wie m\u00f6glich auf eine Maschine nach CPU platziert werden. Bei Bedarf wird eine neue Maschine in einer neuen Verf\u00fcgbarkeitszone erstellt.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Typ des Lastenausgleichs<\/strong> \u2014 wir w\u00e4hlen den Application Load Balancer.<\/p>\n
<\/p>\n
IAM-Rolle f\u00fcr den Dienst<\/strong> \u2014 wir w\u00e4hlen ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Name des Lastenausgleichs<\/strong> \u2014 wir w\u00e4hlen den zuvor erstellten Lastenausgleich aus.<\/p>\n
<\/p>\n
Gesundheitspr\u00fcfungs-Gnadenfrist<\/strong> \u2014 Pause vor der Durchf\u00fchrung von Gesundheitspr\u00fcfungen nach dem Rollout neuer Aufgaben, wir setzen normalerweise 60 Sekunden.<\/p>\n
<\/p>\n
Container zum Lastenausgleich<\/strong> \u2014 im Punkt \u201aZielgruppename\u2018 w\u00e4hlen wir die zuvor erstellte Gruppe aus, und alles wird automatisch ausgef\u00fcllt.<\/p>\n
<\/p>\n
\"Erstellung<\/p>\n
<\/p>\n
Automatische Skalierung des Dienstes<\/strong> \u2014 Parameter zur Skalierung des Dienstes. Wir w\u00e4hlen \u201aDienst-Automatisierungskalierung konfigurieren, um die gew\u00fcnschte Anzahl Ihres Dienstes anzupassen\u2018. Wir geben die minimale und maximale Anzahl von Aufgaben bei der Skalierung an.<\/p>\n
<\/p>\n
IAM-Rolle f\u00fcr die automatische Skalierung des Dienstes<\/strong> \u2014 wir w\u00e4hlen AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Automatische Skalierungsrichtlinien f\u00fcr Aufgaben<\/strong> \u2014 Regeln zum Skalieren. Es gibt 2 Typen:<\/p>\n
<\/p>\n
    \n
  1. Zielverfolgung<\/strong> \u2014 Verfolgung einer Zielmetrik (Nutzung von CPU\/RAM oder die Anzahl der Anfragen f\u00fcr jede Aufgabe). Zum Beispiel, wir m\u00f6chten, dass die durchschnittliche CPU-Auslastung 85% betr\u00e4gt. Wenn sie dar\u00fcber steigt, werden neue Aufgaben hinzugef\u00fcgt, bis sie den Zielwert erreicht. Liegt die Auslastung darunter, werden Aufgaben abgebaut, es sei denn, die Downsizing-Skalierungsschutz ist aktiviert (Skalierung nach unten deaktivieren<\/strong>).<\/li>\n
  2. Step-Skalierung<\/strong> \u2014 Reaktion auf ein beliebiges Ereignis. Hier k\u00f6nnen Sie die Reaktion auf jedes Ereignis (CloudWatch Alarm) festlegen. Wenn es passiert, k\u00f6nnen Sie eine bestimmte Anzahl von Aufgaben hinzuf\u00fcgen oder entfernen, oder eine genaue Anzahl von Aufgaben angeben.<\/li>\n<\/ol>\n
    <\/p>\n
    Ein Dienst kann mehrere Skalierungsregeln haben, was n\u00fctzlich sein kann. Es ist wichtig, 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, nach der alle Maschinen im Dienst gestartet werden. Wir haben auch gelernt, 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 Aufgaben von der Maschine entfernt, sodass nichts verloren geht und nichts unterbrochen wird.<\/li>\n
    3. Wir haben einen Load Balancer eingerichtet, um die Last gleichm\u00e4\u00dfig auf die Maschinen zu verteilen.<\/li>\n
    4. Wir haben einen Dienst eingerichtet, der auf Spot-Instanzen l\u00e4uft, wodurch die Maschinenkosten um etwa das Dreifache gesenkt werden.<\/li>\n
    5. Wir haben das automatische Skalieren in beide Richtungen eingerichtet, um Lastspitzen zu bew\u00e4ltigen, aber gleichzeitig nicht f\u00fcr Leerlaufzeiten zu zahlen.<\/li>\n
    6. Wir verwenden einen Capacity Provider, damit die Anwendung die Infrastruktur (Maschinen) verwaltet und nicht umgekehrt.<\/li>\n
    7. Wir sind gro\u00dfartig.<\/li>\n<\/ol>\n
      <\/p>\n
      Wenn Sie vorhersehbare Laststeigerungen haben, z.B. wenn Sie in einem gro\u00dfen E-Mail-Newsletter werben, k\u00f6nnen Sie die Skalierung nach Zeitplan<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Au\u00dferdem k\u00f6nnen Sie die Skalierung basierend auf Daten aus verschiedenen Teilen Ihres Systems durchf\u00fchren. Zum Beispiel haben wir die Funktion Versand von individuellen Rabattangeboten<\/a><\/noindex> Nutzern der mobilen Anwendung. Manchmal wird die Kampagne an \u00fcber 1 Million Personen versendet. Nach einem solchen Versand beobachten wir immer einen deutlichen Anstieg der Anfragen an die API, da viele Benutzer gleichzeitig die Anwendung aufrufen. Wenn wir also sehen, dass die Anzahl der Warteschlangen f\u00fcr das Versenden von Promo-Push-Benachrichtigungen deutlich \u00fcber den Standardwerten liegt, k\u00f6nnen wir sofort mehrere zus\u00e4tzliche Maschinen und Aufgaben starten, um auf die Last vorbereitet zu sein.<\/p>\n
      <\/p>\n
      Ich w\u00fcrde mich freuen, wenn ihr in den Kommentaren interessante Anwendungsf\u00e4lle f\u00fcr Spot-Instanzen und ECS oder etwas zum Thema Skalierung erz\u00e4hlt.<\/p>\n
      <\/p>\n
      Bald erscheinen Artikel dar\u00fcber, wie wir tausende analytischer Events pro Sekunde auf einem \u00fcberwiegend serverless Stack (mit Finanzen) verarbeiten und wie das Deployment von Services mit GitLab CI und Terraform Cloud funktioniert.<\/p>\n
      <\/p>\n
      Folgt uns, es wird interessant!<\/p>\n
      Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte einloggen<\/a><\/noindex>.<\/p>\n
      Verwendet ihr Spot-Instanzen in der Produktion?<\/h2>\n