Von 1 auf 10 Millionen: Skalieren mit AWS. Matthias Jung, Solutions Architect AWS AWS Summit Berlin, 15.Mai 2014

Transkript

1 Von 1 auf 10 Millionen: Skalieren mit AWS Matthias Jung, Solutions Architect AWS AWS Summit Berlin, 15.Mai com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of.com, Inc.

2 Wie funktioniert das also mit dem Skalieren?

3

4 eine Menge Ergebnisse nicht der richtige Startpunk

5 Zunächst ein paar Grundlagen

6 AWS Regionen US-WEST (Oregon) AWS GovCloud (US) EU-WEST (Ireland) CHINA (Beijing) ASIA PAC (Tokyo) US-EAST (Virginia) US-WEST (N. California) ASIA PAC (Sydney) SOUTH AMERICA (Sao Paulo) ASIA PAC (Singapore)

7 Verfügbarkeitszonen (AZs) EU-WEST (Ireland) US-WEST (Oregon) AWS GovCloud (US) CHINA (Beijing) ASIA PAC (Tokyo) US-EAST (Virginia) US-WEST (N. California) ASIA PAC (Sydney) SOUTH AMERICA (Sao Paulo) ASIA PAC (Singapore)

8 Edge-Standorte

9 AWS OpsWorks CloudWatch Elastic Beanstalk AWS IAM AWS CloudFormation AWS Data Pipeline AWS CloudTrail SNS CloudSearch SQS Bereitstellung & Verwaltung DynamoDB ElastiCache RDS SES SWF Elastic Transcoder Anwendungsdienste RedShift DV Speicherung & Bereitstellung Datenbanken S3 EC2 EMR VPC Netzwerk AWS Storage Gateway Glacier CloudFront Kinesis Route 53 AWS Direct Connect AWS Globale Infrastruktur

10 1 (Sie selbst)

11 1.Tag, 1 Anwender Eine einzige EC2-Instanz mit komplettem Stack Web-App Datenbank Verwaltungswerkzeuge usw. Elastic IP Address Route 53 für DNS Anwender EC2- Instanz Route 53 Elastic IP Address

12 Wir brauchen eine grössere Kiste Wechseln der Instanz-Grösse Wechseln des Instanz-Typen EBS mit PIOPS konfigurieren Ziemlich unkompliziert Mehrere Tausend Anwender möglich i2.4xlarge m3.xlarge m1.small

13 Wir brauchen eine grössere Kiste Wechseln der Instanz-Grösse Wechseln des Instanz-Typen EBS mit PIOPS konfigurieren Ziemlich unkompliziert Mehrere Tausend Anwender möglich Funktioniert nicht unendlich i2.4xlarge m3.xlarge m1.small

14 Erste Schritte Keine Ausfallsicherheit Keine Redundanz Keine Risikostreuung Anwender Route 53 Elastic IP Address EC2 - Instanz

15 1000

16 1000 Anwender und mehr Trennen von Datenbank und Web-Anwendung Datenbank-Dienst statt Selbst-Verwaltung? Anwender Web- Instanz Elastic IP Address Route 53 Datenbank- Instanz

17 Datenbank-Optionen Selbst-Verwaltung Datenbank-Dienste Datenbank auf EC2 RDS DynamoDB Redshift Wahl der Software und Version Eigene Lizenz (BYOL) Microsoft SQL, Oracle, Postgre & MySQL als Dienst Lizenz inkludiert oder BYOL NoSQL-Dienst mit SSD-Speicher Nahtlose Skalierung, kein Betriebsaufwand Data-Warehouse- Dienst (SQL) Massiv parallel, hohe Skalierbarkeit, schneller Zugriff

18 Welche Datenbank- Technologie?

19 Warum eine SQL-Datenbank? Weit verbreitet und bestens verstanden Tausende Werkzeuge, Code, Communities, Bücher, Erprobte Skalierungsmuster und rezepte Schafft auch 10 Millionen Anwender* * Ausser bei extrem vielen Schreib-Operationen auf riesigen Datenmengen. Und selbst dann gibt es einen Platz für SQL-Datenbank in Ihrem Stack.

20 Wann passt NoSQL besser? Riesige Datenmengen (im TB-Bereich) Tausende von Schreib- und Update-Operationen Unstrukturierte Daten, keine festen Tabellen Daten mit losen Beziehungsstrukturen Speichern von Meta-Daten Anwendungen mit Anforderungen an geringe Latenz Erfahrung und Kompetenz im Team

21 DynamoDB Vollständig verwalteter Dienst Hohe und berechenbare Leistung Vollständig verteilte und fehlertolerante Architektur Konfigurierbarer und konstanter Durchsatz Automatische Skalierung von Tabellen Integrierte Fehlertoleranz Starke Konsistenz und atomare Zähler Integriertes Monitoring Hohe Sicherheit Integration mit EMR

22 Mehr als 1000 Anwender Trennen von Datenbank und Web-Anwendung Datenbank-Dienst RDS statt Selbst-Verwaltung Anwender Web- Instanz Elastic IP Address Route 53 RDS Datenbank- Instanz

23 10,000

24 10000 Anwender und mehr Anwender Route 53 Ausfallsicherheit und Redundanz Verteilung auf Verfügbarkeitszonen Elastic Load Balancing RDS Multi-AZ Web- Instanz RDS DB-Instanz mit aktiviertem Multi-AZ Elastic Load Balancing Web- Instanz RDS DB-Instanz in Bereitschaft (Multi-AZ) Verfügbarkeitszone A Verfügbarkeitszone B

25 Elastic Load Balancing Für fehlertolerante und hochskalierbare Anwendungen Elastic Load Balancing Hochverfügbar und Elastisch Zustandsprüfungen Lastverteilung auf Layer 4 und 7 SSL-Unterstützung und -Auslagerung Integriertes Monitoring Protokollierung IPv6-Unterstützung

26 500,000

27 Horizontales Skalieren Anwender Route 53 Elastic Load Balancing Web- Instanz Web- Instanz Web- Instanz Web- Instanz Web- Instanz Web- Instanz Web- Instanz Web- Instanz RDS DB-Instanz Lese-Replica RDS DB-Instanz Lese-Replica RDS DB-Instanz Master (Multi-AZ) RDS DB-Instanz Standby (Multi-AZ) RDS DB-Instanz Lese-Replica RDS DB-Instanz Lese-Replica Verfügbarkeitszone A Verfügbarkeitszone B

28 Entlasten Anwender Route 53 CloudFront Von Web-Servern und Datenbank Statische Inhalte auf S3 speichern Elastic Load Balancing Statische (und dynamische) Inhalte über CloudFront ausliefern Web- Instanz S3 Datenbank-Abfragen in ElastiCache cachen Session-Zustände auf ElastiCache oder DynamoDB auslagern RDS DB-Instanz Master (Multi-AZ) Verfügbarkeitszone ElastiCache DynamoDB

29

30 Zugriffe im November auf.com November

31 Zugriffe im November auf.com Bereitgestellte Kapazitäten 76% November 24%

32 Zugriffe im November auf.com November

33 Auto Scaling Automatische Anpassung der Kapazitäten an die Last Integration mit CloudWatch Integration mit Elastic Load Balancing Für Skalierung und Verfügbarkeit Auslösen von Auto-Scaling Policy CloudWatch as-create-auto-scaling-group MyGroup --launch-configuration MyConfig --availability-zones us-east-1a --min-size 4 --max-size 200

34 500 Tsd Anwender Anwender Route 53 CloudFront Elastic Load Balancing S3 Web- Instanz Web- Instanz Web- Instanz Web- Instanz Web- Instanz Web- Instanz RDS DB-Instanz Master (Multi-AZ) RDS DB Instanz Lese-Replica ElastiCache RDS DB-Instanz Standby (Multi-AZ) RDS DB-Instanz Lese-Replica ElastiCache DynamoDB Availability Zone Availability Zone

35

36 Automatisierung AWS Elastic Beanstalk AWS OpsWorks AWS CloudFormation EC2 Bequemlichkeit Kontrolle

37 SERVER METRIKEN AGGREGIERTE METRIKEN LOG ANALYSE EXTERNE MESSUNGEN

38 AWS Marketplace & Partners Suche und Kauf von vorinstallierten Software- Lösungen Verbrauchsorientierte Abrechnung Starten in wenigen Minuten Abrechnung in AWS-Konto integriert Mehr als 1300 Produkte und 20 Kategorien Learn more at: aws.amazon.com/marketplace

39 1,000,000

40 Komponenten entkoppeln Entkoppeln hilft beim Skalieren und Optimieren Unabhängige Komponenten Konzeption als Blackbox Klare Schnittstellen Interaktionen entkoppeln

41 Komponenten entkoppeln Vorher Controller A Controller B Loose coupling Q SQS als Puffer Nachher Q Q Controller A Controller B

42 In Diensten denken Monolytische Blöcke in feingranulare Dienste teilen Dienste in eigene Module packen Jeden Dienst als 100% unabhängige Komponente betrachten Jeden Dienst unabhängig skalieren

43 In Diensten denken Monolytische Blöcke in feingranulare Dienste teilen Dienste in eigene Module packen Jeden Dienst als 100% unabhängige Komponente betrachten Jeden Dienst unabhängig skalieren = Grundprinzip von AWS und.com

44 Das Rad nicht neu erfinden Wenn ein passender Dienst bereits existiert, warum selbst einen eigenen bauen? Beispiele Benachrichtigungen SNS CloudSearch SQS Suche Workflows Queuing Transcoding SES SWF Elastic Transcoder Monitoring

45 1 Mio Anwender und mehr Anwender Route 53 CloudFron t Elastic Load Balancing Web- Instanz Web- Instanz Web- Instanz Web- Instanz Worker- Instanz Worker- Instanz SQS S3 ElastiCache DynamoDB RDS DB-Instanz Lese-Replica RDS DB-Instanz Lese-Replica Verfügbarkeitszone RDS DB-Instanz Master (Multi-AZ) Interner App-Server Interner App-Server CloudWatch SES

46 10,000,000

47 Zwischen 5-10 Mio Anwendern Schreiben in die Datenbank wird zum Flaschenhals Lösungen Federation: Verteilen der Datenbank-Struktur auf mehrere Datenbank-Systeme nach Funktion Sharding: Verteilen der Daten auf mehrere Datenbank- Systeme (z.b. Anwender nach Region) NoSQL: Auslagerung von bestimmten Daten auf NoSQL- Datenbanken

48 Auslagerung in eine NoSQL-DB Beispiele Punktestände und Leaderboards Clickstream oder Log-Daten Zwischenspeicherung (z.b. Einkaufswagen, Session-Informationen) Extrem populäre Daten Meta-Daten DynamoDB

49 und so sind wir bei 10 Millionen Anwendern

50 Von 1 auf 10 Millionen Anwender Wahl der passenden DB zum passenden Usecase Komplette Infrastruktur auf Verfügbarkeitszonen verteilen (Multi-AZ) Caching, caching, caching Entkoppeln und in Diensten denken (SOA) Das Rad nicht neu erfinden Elastic Load Balancing, S3, SNS, SQS, SWF, SES,... Auto-Scaling (wenn die Grundlagen dafür gelegt wurden) Monitoring auf allen Ebenen Automatisierung des Betriebs

51 100,000,000?

52 Millionen Anwender Noch mehr und spezielle fein-granulare Dienste Noch mehr Leistungsoptimierung durch genaue Vermessung des gesamten Stacks Von Multi-AZ zu Multi-Region Mehr individuelle Lösungen

53 Nächste Schritte? Lesen? aws.amazon.com/de/documentation aws.amazon.com/de/architecture aws.amazon.com/de/start-ups Hören? Motain - Onefootball

54 From 1 to 10 Millions Jonathan Lavigne 15/05/ com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of.com, Inc.

55 Today Jonathan Lavigne, CTO/CPO, Onefootball What we ll talk about: From a German iphone app to a multi-countries success How we use AWS Lessons learned while growing Our TODOs for the next evolution of our infrastructure

56 We fuel people s addictions

57 It s a team effort Balancing new feature development, performance, monitoring, quality, process management All while avoiding silos, delays, systems being down, unhappy users Thanks to my team!

58 The initial infrastructure

59 The initial infrastructure Classic infrastructure 1 server to produce content, 4 servers to deliver it Very big servers: 2 x Xeon CPU w/ 16 cores, 48GB RAM, SSD Central NAS w/ 1TB space over a 1GB/s connection 1 DB master and 4 DB slaves on each frontend server 2 load balancers (1 active, 1 hot stand-by) Very predictable metrics Worked well for a long time

60 The initial infrastructure

61 Until Euro 2012

62 Until Euro 2012 From 1 to 2 millions users in 2 weeks International traffic: everybody follows the same games Servers start to send warnings, we NEED to do something

63 Until Euro 2012 Monolith = not easy to scale Fast code optimizations only get you so far Solution: CloudFront and S3 to the rescue Lessons learned Think early of systems Shift load to CDN or other services (S3, etc..)

64 Post Euro Optimizations From 2 to 4 million users Refine CDN caching and invalidation rules Move static assets to S3 (images, static files) Optimize code, services and infrastructure Admit when optimization effort costs more than benefits

65 Small change, big difference

66 Time for elasticity - AWS Difficult to do quickly Software too tightly coupled Internal resources busy with other projects Step-by-step Evaluate performance hot-spots Create a plan to decouple software Choose the setup for YOUR needs

67 Our score architecture today

68 Technologies we use EC2 RabbitMQ and HAProxy PHP & Go Stack RDS and Elastic Cache ELB and Route 53 OpsWork Deployment with Chef VPC

69 RabbitMQ OpsWork handles clustering with Chef Queues are mirrored across the instances HAProxy used to connect on EC2 instances which connect to Rabbit Balancing between various Rabbit hosts Don t change anything in the software messages/second on a C3.large instance

70 OpsWorks Facilitates for any engineer to manage the infrastructure Integrates with Chef out of the box Allows us to layer the infrastructure and optimize accordingly Benefit from time based scaling since usage patterns are predictable (football matches) Allows load-base scaling if required

71 Monitoring Basic CPU and Load usage Monitoring the ELBs Copper Egg Monitors instances, helps determine instance size and optimize/improve

72 The future Fine tune auto-scaling rules Move more of our infrastructure to OpsWorks Unify databases Deploy to multiple AWS regions Continue move to Go Leverage more AWS technologies such as RedShift and Elastic MapReduce

73 THANK YOU