Messen, bevor Sie zurückholen: einen Cloud-Ausstieg aus der echten Nutzung dimensionieren

Der teuerste Fehler beim Verlassen der Public Cloud ist, den Bestand so zu kopieren, wie er ist. Cloud-Umgebungen wachsen durch Provisionierung, und provisioniert ist nicht genutzt: in Eile gewählte Instanzgrößen, Volumes, die für eine Spitze dimensioniert wurden, die nie kam, Dienste, an deren Start sich niemand erinnert. Verschieben Sie das eins zu eins, und Sie tragen die Verschwendung in einen festen Vertrag. Hier ist, wie Sie messen, was tatsächlich läuft, bevor irgendjemand ein neues Design zeichnet.

Das Problem: die Rechnung beschreibt, was Sie mieten, nicht, was Sie nutzen

Eine Cloud-Rechnung listet Instanztypen, Volume-Größen und Service-Stufen auf. Nichts davon sagt Ihnen, wie viel CPU Ihre Anwendung in ihrer geschäftigsten Stunde verbraucht hat, wie viele IOPS die Datenbank wirklich geleistet hat oder wie viel Arbeitsspeicher der Cache tatsächlich hält. Das sind die Zahlen, die ein Design für physische Infrastruktur oder eine Private Cloud braucht, und der Cloud-Anbieter hat die meisten davon die ganze Zeit für Sie aufgezeichnet.

Schritt eins: alles inventarisieren, nicht nur die Server

Beginnen Sie mit einer vollständigen Liste der Ressourcen in jeder Region, die Sie je genutzt haben. Tags helfen, aber nicht getaggte Ressourcen sind genau die, die Sie finden müssen:

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws resourcegroupstaggingapi get-resources --region "$r" \
    --query 'ResourceTagMappingList[].ResourceARN' --output text
done | tr '\t' '\n' | sort > inventory.txt

Dann gruppieren Sie nach Dienst. Die Server sind meist der einfache Teil. Die Arbeit steckt in dem, was sie umgibt: Managed Databases, Caches, Load Balancer, DNS-Zonen, Queues, Object Buckets, Zertifikate, geplante Functions, und die IAM-Rollen und Security Groups, die sie zusammenhalten. Jedes davon braucht einen Verantwortlichen und eine Entscheidung: verschieben, ersetzen, behalten oder stilllegen.

Schritt zwei: Perzentile lesen, nicht Durchschnitte

Ziehen Sie für jede Compute-Ressource mindestens einen Monat Auslastung, und lesen Sie das 95. Perzentil und das Maximum statt des Durchschnitts. Der Durchschnitt aus einer ruhigen Nacht und einem geschäftigen Abend beschreibt keines von beiden.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=<instance-id> \
  --start-time "$(date -u -d '-30 days' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --extended-statistics p95 \
  --query 'Datapoints[].ExtendedStatistics.p95' --output text \
  | tr '\t' '\n' | sort -n | tail -1

Arbeitsspeicher ist die Lücke: Hypervisor-Metriken sehen nicht in den Gast hinein. Wenn der CloudWatch-Agent installiert ist, liegen seine Speichermetriken im Namespace CWAgent. Wenn nicht, sammeln Sie ein paar Wochen lang aus den Instanzen heraus mit sar oder Ihrem bestehenden Monitoring, bevor Sie irgendetwas dimensionieren. Arbeitsspeicher zu raten ist der Weg, auf dem Designs entweder ausgehungert oder verschwenderisch enden.

Tun Sie dasselbe für den Storage: VolumeReadOps und VolumeWriteOps pro Volume liefern echte IOPS, VolumeReadBytes und VolumeWriteBytes den Durchsatz. Für Managed Databases lesen Sie CPUUtilization, FreeableMemory, ReadIOPS und WriteIOPS. Für Caches den tatsächlich genutzten Arbeitsspeicher und die Zahl der Verbindungen. Für den Traffic zeigt NetworkOut pro Instanz, woher der Egress wirklich kommt, was für das Netzwerkdesign zählt, nicht nur für die Rechnung.

Schritt drei: das Dimensionierungsblatt aufbauen

Tragen Sie die Messungen in ein Blatt ein, eine Zeile pro Workload:

Workload	CPU p95	Genutzter Arbeitsspeicher p95	IOPS p95	Egress-Anteil	Erwartetes Wachstum

Dann dimensionieren Sie jede auf ihre gemessene Spitze mit einer Reserve, die Sie begründen können, nicht auf die Instanz, auf der sie heute läuft. Zwei Regeln, die wir auf jedes Design anwenden:

• Geben Sie einer virtuellen Maschine nie mehr vCPUs, als ein CPU-Socket physische Kerne hat, und nie mehr Arbeitsspeicher, als ein NUMA-Knoten bedient. Eine über Sockets verteilte VM zahlt bei jedem Zugriff eine Strafe für entfernten Speicher und läuft oft langsamer als eine kleinere. Wenn eine Workload mehr als einen Socket braucht, muss sie horizontal skalieren oder auf Bare Metal wechseln.
• Richtig dimensionieren, dann aufhören. Cloud-Bestände sind routinemäßig überdimensioniert, weil Umdimensionieren riskant war. Auf dedizierter Infrastruktur ist die richtige Größe günstiger und häufig schneller.

Schritt vier: jeden Managed Service etwas Eigenem zuordnen

Schreiben Sie für jeden Managed Service auf, was ihn ersetzt und was sich für die Anwendung ändert:

Managed Service	Ersatz in Ihrem Eigentum	Was die Anwendung bemerkt
Managed MySQL oder MariaDB	Percona XtraDB Cluster oder repliziertes MariaDB, hinter ProxySQL	ein neuer Endpoint, sonst nichts
Managed Redis	Valkey oder Redis mit Sentinel	Verbindung über Sentinel
Application Load Balancer	HAProxy-Paar mit Floating-Adressen	nichts
Managed DNS	Ihr eigener PowerDNS-Bestand	nichts, wenn der Umzug in der richtigen Reihenfolge erfolgt
Managed Kubernetes	OpenShift oder OKD auf Bare Metal	dieselben Manifeste, mit geprüften Storage Classes

Manche Dienste haben in Ihrem neuen Zuhause keine sinnvolle Entsprechung, oder sie sind günstig und bequem dort, wo sie sind. Hybrid ist eine legitime Antwort: Lassen Sie sie in der Cloud und verbinden Sie beides privat. Ein Rückführungsplan, der alles verschieben will, ist oft der, der stecken bleibt.

Schritt fünf: für die Failure Domains planen, die Sie zurücklassen

Availability Zones haben echte Arbeit für Sie geleistet, also muss das neue Design dieselbe Arbeit ausdrücklich leisten. Ordnen Sie jedes Tier getrennten Hosts, getrennten Storage-Arrays und, wo es zählt, getrennten Standorten zu. Quorum-Dienste (Datenbanken, Caches, Koordinatoren) brauchen drei Mitglieder in drei Failure Domains. Schreiben Sie es Tier für Tier auf. «Es war Multi-AZ» ist kein Design.

Schritt sechs: den DNS-Umzug als den kritischen Pfad planen, der er ist

DNS ist meist das Letzte, was umzieht, und das Einzige, was alles auf einmal kaputtmachen kann. Wenn die Zone mit DNSSEC signiert ist, sequenzieren Sie den Wechsel von Schlüssel und DS-Eintrag so, dass validierende Resolver nie eine gebrochene Kette sehen. Den vollständigen Umzug eines Kunden weg von AWS DNS beschreiben wir auf unserer Seite zu Managed DNS.

Ihre Checkliste

• Ein vollständiges Inventar über alle Regionen, mit Verantwortlichem und Entscheidung pro Ressource.
• Mindestens ein Monat p95- und Spitzenauslastung für CPU, Arbeitsspeicher, IOPS und Egress.
• Arbeitsspeicher aus den Gästen heraus gemessen, nicht geraten.
• Ein Dimensionierungsblatt, das auf gemessene Spitzen dimensioniert, mit VMs innerhalb eines Sockets.
• Jeder Managed Service einem Ersatz zugeordnet oder bewusst behalten.
• Failure Domains ausdrücklich geplant, und der DNS-Umzug sequenziert.

Wenn Sie eine Rückkehr auf Infrastruktur in Ihrem Eigentum abwägen, beginnen wir gern mit dem Messen.

CTA

Mit einem Ingenieur sprechen

Related

Verwandt: Cloud-Rückführung (Cloud Repatriation) und Colocation-Ausstieg · Managed Rechenzentrumsmigrationen, geprobt · Hochverfügbare Plattform-Builds