Der Meister selbst persönlich. Ich freu mich.

Es geht um Erfahrungen mit Azure und Applikationen die in Azure gelaufen sind. Es werden aber keine Namen genannt sondern nur Architekturen. (bis auf eine Ausnahme)

Case - Election Results

Grosser US Staat wollte die Elections auf den Automaten einfach online auswerten und dort entsprechend abfackeln at Scale.

Im September eine kleine Election hat funktioniert, aber es war eng was Performance Themen betraf. Im November wollte man wesentlich grössere Elections machen. Review der Architektur stand an.

Im Wesentlichen wie im Bild zu sehen - eine Web Rolle, eine Worker Role sowie Database. Die Daten kommen von den Wahlmaschinen direkt in die Azure Blobs, werden vom Worker aufgearbeitet in die Datenbank und dort dann über Web Role wieder abgefragt. Das ganze Fault Tolerant mit zweiter Kopie im zweiten RZ und Azure Traffic Manager als DR Architecture.

HochRechnung:

1 Web Request, 10 SQL Queries, based 10.000.000 Million Page Views, 695 Page Views/s wurden geschätzt auf der Basis der September Daten.

Problem:

Azure DB, 5000 Connections, 180 Concurrent Requests, 1000 Requests per Second.

Wenn man die Hochrechnung durchkalkuliert - das geht sich ned aus im Azure.

Solution: Cache zwischen FrontEnd und BackEnd DB mit 40.000 Requests/s pro Instance.

Learning: Cache between Database and Web Role hilft!

Case - PAAS

Customer im Building Sektor, machen Building Plants und dgl. mit einer bestehenden OnPrem Applikation. Das aktuelle OnPrem Design wurde folgendermassen in Azure umgesetzt.

• ASP.NET moved to Web Role, application logic in Worker Role,
• SQL als IaaS => Warum ==> Stored Procedures wurden verwendet die in Azure DB nicht funktionieren

Ergebnisse vom ersten Test: OnPrem App hat ca. 33.174 Requests bei 200 usern, Azure rund 10.135

OnPrem hatte Web und SQL auf einer Maschine. Im Azure getrennt, der Hop dazwischen war das Problem. Der Vorteil dieser Rollen getrennt voneinander zu scalen war nicht so wichtig, daher wurde Worker und SQL Role zusammengelegt um die Latency und den Netzwerkhop zwischen den Rollen zu sparen.

Azure DB Througput aufgrund falscher VHD Layouts - 1844 IOPS / 15.2 MB/s

Optimized Configuration, 16 Disks, data + tempdb auf einer VHD mit 5378 IOPs / 336,15 MB/sec

Nach der Optimierung => Azure Throughput war slightly higher than onPrem. (ich konnte es aber auf den Folien nicht 100% erkennen, es war aber durchaus um den Faktor 1.2 höher)

Case - Move Streaming (BlinkBox)

"Catch me if you can" - PaaS Streaming Service

Web Role + Database + Azure Blog Storage. Dort liegen die Filme und in der Datenbank nur die Metadaten. Cache zwischen Web Role und Database um die Requests zu cachen.

Problem: Wenn der Cache nicht in 2 Sekunden geantwortet hat, dann ist die Web Role zur Database gegangen. Die Datenbank ist aber unter Stress in die Knie gegangen. (Beispiel die Cache Role rebootet)

Lösung: Cache auf den Web Servern direkt, dann fallts ned auf weil die Web Role ja auch weg ist und der Cache nicht einzeln ausfallen kann

Case - Cars Connected

Car Company mit Daten der Autos die ihre Infos in Azure reinwerfen um dort Auswertungen zu machen. (Car fails,...)

Azure Service Bus mit Messages die an eine Worker Rolle gegeben werden un ddie Workerrolle schaufelt das in die Datenbank. geplant waren rund 10.000 Requests, das Ergebnis waren - "Far less than 10.000 Requests as expected."

Problem: Synchronous Message processing => die Azure Service Bus messages dürfen nicht synchron abgerufen werden sondenr einfach parallel - einen Request - 20ms auf alle Messages warten die daherkommen in der Zeit und diese dann parallel abarbeiten

Processing Messages war auch Sequentiell=> auch hier parallel einfach weil alle Messages komplett unabhängig voneinander sind.

...

Viele weitere Beispiele

für mich sind folgende Punkte immer wieder aufgekommen:

Asynchron vor Synchron

Wenn möglich immer versuchen die Kommunikation zwischen Komponenten oder Work asynchron zu machen. Wenn etwas warten muss, dann kostet das Zeit.

Scale Out not Scale Up

Parallel arbeiten hilft wesentlich mehr als die einzelne Kiste dicker machen. Die kochen halt auch nur mit Wasser und irgendwann ist jede CPU am Ende, jedes Storage am Limit. Wer also die Daten in Chunks aufteilt und parallel arbeitet kann kumulativ einfach mehr erreichen.

Cache where needed

Wenn Sinnvoll immer die Daten cachen. Ähnlich wie bei Synchron / Asynchron – wer auf ein Ergebniss wartet hat a schlechtere User Expirience. Warten ist immer schlecht.

Azure Lessons

VIP Swap

Very small number of Customers Worte von Herrn Russinovich waren ungefähr “Couple of hundred customers could not manage Environment”, für uns klingt das eher dramatisch, aber in Azure Scales ist das halt im Rahmen der normalen Fehlerrate. Dafür gabs sogar an “The Register” Artikel

Microsoft Azure goes TITSUP (Total Inability To Support Usual Performance)

Whats a VIP Swap

Production hat IP / DNS die verwendet wird, Stage Umgebung hat Temp IP / DNS. beim VIP Swap wird Stage auf Production gewechselt. Man kann also die gesamte Architektur ändern durch einen VIP Swap.

VIP Swap Internals:  RDFE wird für Monitoring verwendet und durch eine Race condition beim Update von Stage auf Production kommt es zu doppelten Daten respektive Überschreibungen und RDFE lässt aufgrund der Inconsistency keine Management Operations mehr zu.

RDFE Developer Explanation: "Unintuitive behaviour of ADO.NET"

Ja das stand so auf den Folien!

Subscription Delete

Operator regular clean up internal Azure Subscriptions – das wird halt gemacht für Subscriptions die intern angelegt werden oder als Microsoft INTERNAL markiert werden. Diese Deletes dürften eine ganze Menge gewesen sein und diese haben sich quasi etwas aufgestaut. Damit es schneller geht hat der Operator ein “Batch Delete” durch gewunken (vorbei am Prozess der das auch gestoppt hätte)

Leider waren auch eine Menge an Subscriptions dabei die von Microsoft für Customer angelegt wurden und deshalb als “internal” markiert waren.

Learning:

Use Soft-Delete, Resource inaccessable to customer, wait 90 days, really delete.

Storage Certificate Expiration

22 Februar 2013 | 12:29 PM no SSL Connection to Storage

Azure Problem that shuld never happen ever (=> es fällt auf das TheRegister hier immer als erster schimpft)

Was wirklich passiert ist

Automatisierter Process überprüft die Expiration von Zertifikaten im Secure Store (Ich vermute mal er meinte HSM Module), Wenn diese in 180 Tagen ablaufen, dann muss ein neues Zertifikate her.

Breakdown hat begonnen mit dem 7 Januar. Das Storage Team hat seine Zertifikate aktualisiert und das Zertifikate im Secure Store aktualisiert. Was vergessen wurde – die Deadline für das Rollout des neuen Zertifikats auf die Storage VMs. Bedeutet es ist alles weitergelaufen, weil der Check am BackEnd im TPM ja “ok” war. Aber wichtigere Deployments haben das Cert Deployment in Produktion immer weiter nach hinten geschoben bis …

Learning: Monitoring überprüft nicht nur die HSM DAten sondern auch die Production Endpoints Sprich – überprüf immer den gesamten Life Cycle. not just a part of it.

Letzte Folie

• Cache aggressivle to hide latency
• Async with queues when possible
• Process in batches to minimize round trips
• Partition data and compute to scale out
• Roll out with monitored slices
• Log excessively

War a gute Session, klingt alles spannend. Man kriegt halt so ein wenig das Gefühl doch sehr klein zu sein und Azure zu betreiben dürfte die ein oder andere Schlaflose Nacht bedeuten.

LG Christoph