4. Warum?
Weil man sich mit ein paar Mausklicks ein
komplettes Rechenzentrum zusammenbauen
kann!
5. Warum?
• Weil Ressourcen unmittelbal bei Bedarf
unmittelbar zugreifbar sind
– keine Vertragsabschlüsse
– keine langen Laufzeiten
– Stunden- bzw. Verbrauchs-bezogene Abrechnung
– keine Wartezeiten bis Bereitstellung
– zeitnahe Kostentransparenz
– für Neunutzer 1 Jahr Nutzung einiger Dienste in
kleinsten Einheiten kostenlos
6. Warum?
• Und weil sich dadurch extrem schnell
skalieren lässt
– manuell, geplant
– automatisch, nach Bedarf
7. Warum?
• Weil Amazon verteilte und redundante
Infrastruktur bietet
– Ausfallsicherheit
– Skalierbarkeit
– geographische Nähe zu den Nutzern
9. Warum? - Verfügbarkeitszonen
• und an jedem Standort mehrere räumlich
getrennte Rechenzentren (Verfügbarkeitszonen):
– Northern Virginia (us-east-1): vier
– Northern California (us-west-1): zwei
– Oregon (us-west-2): drei
– Ireland (eu-west-1): drei
– Sao Paulo (sa-east-1): zwei
– Tokyo (ap-northeast-1): drei
– Singapore (ap-southeast-1): zwei
– Sydney (ap-southeast-2): zwei
10. Warum?
• Weil viele komplex zu administrierende
Dienste als Services bereitgestellt werden
– z.B. schnell mal eine Datenbank anstarten, ohne
Installation
– oder Filme transcodieren, ohne vorher passende
Software zu suchen und zu lizensieren
• AWS nimmt Arbeit ab, befreit aber nicht von
der Notwendigkeit, Know-How zu den
einzelnen Services zu haben
13. Wie werden AWS genutzt?
• Viele Funktionen der Webservices sind über
die Management Console steuerbar
14. Wie werden AWS genutzt?
• Für zig Programmiersprachen stehen fertige
SDKs bereit, ansonsten ist der Zugriff dank
REST auch leicht implementierbar
15. Wie werden AWS genutzt?
• Für PHP gibt es zwei SDKs:
– das alte 1.x-SDK, sehr gewachsen, für bestehende
Dienste
– moderne 2.x-SDK, Namespaces-basierend,
modular, ordentliches Objektmodell,
zukunftssicher
16. Dienste im Detail: EC2
• virtuelle Maschinen gibt es in verschiedensten
Größen, je nach Anwendungsfall
– winzig (z.B. Tests und Entwicklung)
– moderat (z.B. als genau skalierbare Server)
– mit viel CPU-Power (z.B. Numbercrunching)
– mit viel IO-Performance (z.B. Datenbanken)
– mit hohem Netzwerkdurchsatz
– und Kombinationen (z.Z. 34 Typen)
17. Dienste im Detail: EC2
Instanzentyp CPU RAM/GB HD/GB $/h $/mon
t1.micro/Linux 1 0.6 - 0.020 14.40
m1.small/Linux 1 1.7 240 0.044 31.68
m1.large/Linux 2 7.5 840 0.175 126.00
i2.8xlarge/Linux 32 244 6400 (SSD) 6.820 4910.40
m1.large/Windows 2 7.5 840 0.299 215.28
• Instanzen sind jederzeit stopp- und wieder startbar
• Start dauert ca. 5 Minuten
• nur reale Laufzeit wird bezahlt
• alternative Preismodelle:
• für 1 oder 3 Jahre im Voraus buchen (für langfristige Serveraufgaben)
• im Spotmarkt auf freie Instanzen bieten (für Batch-Jobs)
• zu obigen Kosten kommt Traffic
18. Dienste im Detail: EC2
• Verschiedene Basis-Images verfügbar
– Amazon Linux, Redhat-basierend
– Ubuntu Linux
– RHEL 7, SLES mit Lizenz
– Windows mit Lizenz
– … hunderte "Appliances" im Marketplace
• Login via SSH
• Administration als root wie auf normalem
Server
19. Dienste im Detail: EC2
• Eine einzelne Instanz kann jederzeit wegfallen
• Software auf Ausfall hin entwerfen
• Daten ausserhalb der Instanz speichern
(EBS/S3/RDS)
• Skalierungsmöglichkeit kann genutzt werden,
um auf "1" zu skalieren -> immer genau ein
Host ist verfügbar, auch wenn mal einer
wegkippt
20. Dienste im Detail: S3
• S3 ist ein Object Storage (Key-Value)
• S3 ist kein Filesystem, aber Keys können auch
Slashes ('/') enthalten, so sieht es nach außen
wie ein Filesystem aus
• individuelle S3-Instanzen sind Buckets, in
diese passen quasi unbegrenzt Objekte
• S3 kann sowohl als interner Storage für einen
Dienst dienen als auch seine gespeicherten
Inhalte direkt via HTTP ausliefern
21. Dienste im Detail: S3
• S3 ist lahm (GETs dauern im Schnitt 70msec,
können aber nach oben ausreißen) für
performante Auslieferung immer ein CDN davor
• S3 wird automatisch über Verfügbarkeitszonen
repliziert
• S3 kann neben Daten an einem Objekt auch
Metadaten speichern, z.B. HTTP-Header, die bei
der Auslieferung via HTTP gesandt werden sollen
- wichtig z.B. für Cache-Parametrisierung
23. Dienste im Detail: Route 53
• Name Server, auch delegierbar für Zonen und
Subzonen
• Amazon selbst verkauft keine Domains
• Zoneninhalte nicht als Dateien (traditioneller
Nameserver), sondern via Management
Console oder SDK pflegbar, damit leicht
dynamisch updatebar
• Integriert in Amazon-Services-Welt
25. Dienste im Detail: CloudFront
• CloudFront ist ein CDN – ein globales Content
Delivery Network
• aber auch ohne globalen Anteil als
vorgeschalteter HTTP-Cache einsetzbar
– vor EC2-Instanzen
– vor S3-Buckets
• CloudFront kostet nur den Traffic
27. Drupal auf AWS: Use-Case Demo-Site
Szenario:
• Abnahme durch Kunden
• gemeinsame Entwicklung via Internet
Typische Lösung:
• EC2-Micro-Instanz mit allem "an Bord"
(Dateisystem, Datenbank, Storage)
• Bei Bedarf gestartet/gestoppt
• Drupal läuft einfach so "out of the box"
28. Einschub: Wie fester Hostname bei wechselnder IP?
• Route 53 to the rescue
#! /bin/sh
export AWS_USER=drupal
export AWS_ACCESS_KEY_ID="<IDENTIFIER_DES_SCHLUESSELS>"
export AWS_SECRET_ACCESS_KEY="<GEHEIMER_KEY>"
PUBLIC_IP=`ec2metadata | awk '/^public-ipv4/{print $2}'`
/usr/local/bin/cli53 rrcreate aws.wayforward.de '' A
$PUBLIC_IP --ttl 60 --replace
echo "Updated aws.wayforward.de to $PUBLIC_IP - $?"
echo "$PUBLIC_IP" | mail -s "[AWS] aws.wayforward.de is
now at $PUBLIC_IP" sven@karlsruhe.org
mit https://github.com/barnybug/cli53
30. Drupal auf AWS: Use-Case Testballon
Szenario:
• Kleine Site, zunächt langsam startend
• Soll durchgehend laufen, aber gff. schnell wieder
gekillt werden
Typische Lösung:
• eine EC2-Instanz mit passendem Profil
• Entweder alles an Bord (Storage auf EBS)
• oder MySQL nach RDS ausgelagert
• mit Auto Scaling sichergestellt, dass permament
online
31. Drupal auf AWS: Use-Case Testballon
Route 53
EC2-
Instance
Auto scaling Group
Amazon RDS ElastiCache
Users
32. Drupal auf AWS: Use-Case skalierbare Site
Szenario:
• voll ausgebaute Site mit wechselndem Lastprofil
Typische Lösung:
• dynamische skalierendes Set von EC2-Small-
Instanzen mit vorgeschaltetem LoadBalancer und
CloudFront-CDN
• alle Storage-Dinge auf Services verlagert
– Datenbank: RDS
– Memcache: ElastiCache
– Dateien: S3
33. Drupal auf AWS: Use-Case skalierbare Site
Route 53
EC2-
Instances
Auto scaling Group
Amazon RDS
ElastiCache
Users
Security Group
Elastic Load
Balancing
CloudFront
Amazon S3
CloudFront
34. Drupal auf AWS: Storage auf S3
Dateien auf S3?
Aber S3 ist doch kein Dateisystem?
35. Drupal auf AWS: Storage auf S3
• Zum Glück abstrahiert Drupal 7 intern
Dateizugriffe über StreamWrapper-Klassen
36. Drupal auf AWS: Storage auf S3
• Und zum Glück hat sich schon jemand die
Arbeit gemacht, einen S3-StreamWrapper zu
bauen:
– https://drupal.org/project/amazons3
– aufbauend auf https://drupal.org/project/awssdk
• dies basiert auf der AWS SDK 1.x for PHP
37. Drupal auf AWS: Storage auf S3
• Installation ist straight forward:
– ggf. libraries-Modul 2.x installieren
– awssdk-Modul installieren
– unter sites/all/libraries/awssdk das AWS SDK for
PHP ablegen (z.B. in Version 1.6.2)
– amazons3-Modul installieren
– Module aktivieren
– Module konfigurieren
– ???
– PROFIT!!!
39. Drupal auf AWS: Storage auf S3
• amazons3-Modul konfigurieren
40. • In Configuration/Media/File System S3 als
Default-Speicherort wählen
(ach so, die untere Option ist ein Vorgriff um ca. 5 Folien, einfach ignorieren!)
41. Drupal auf AWS: Storage auf S3
• Lustige
Randgeschichte:
Bilderskalierung
im S3-Stream-
Wrapper
43. Drupal auf AWS: Storage auf S3
Nein!
Es werden noch immer Dinge ins lokale
Filesystem geschrieben aka hardgecodete
Annahmen in core sind doof.
44. Drupal auf AWS: Storage auf S3
• public-StreamWrapper umbiegen
– Es gibt einen Patch "Override the public file
stream with S3" für das amazons3-Modul:
https://drupal.org/node/2044509
– Damit landen auch minifyte und combinete CSS-
und JavaScript-Dateien brav auf dem S3
– Existierende Dateien aus sites/default/files
müssen manuell nach S3 übertragen werden!
45. Drupal auf AWS: Storage auf S3
• Was broken ist:
– nach Umbiegen des public-Streams auf s3
stimmen die relativen Pfade zu aus CSS-
referenzierten Icons nicht mehr (anderer Host),
d.h. die Icons im Admin-Mode sind fehlend
46. Drupal auf AWS: Storage auf S3
• Was noch unschön ist:
– awssdk-Modul möchte AWS-Key/Secret explizit
konfiguriert, aber besser gäbe man der EC2-
Instanz über Rollen die Servicezugriffsrechte
– awssdk- und amazons3-Module basieren auf der
ältlichen AWS SDK for PHP 1.x, nicht auf der 2.x
– das Umbiegen des public-Streams ist ein Patch auf
das amazons3-Modul
– kein Support für ggf. einen zweiten Bucket für den
private-Stream
47. Drupal auf AWS: Storage auf S3
• Alternative
– s3fs-Modul, basierend auf AWS SDK 2.x
https://drupal.org/project/s3fs
– Fork von amazons3-Modul, umgearbeitet auf AWS
SDK 2.x
– Verspricht mehr Performance
48. Zusammenfassung
• Nutzung von AWS kann je nach
Anwendungsfall sinnvoll sein, muss aber nicht
• AWS kann Arbeit abnehmen, nicht aber Know-
How
• Drupal lässt sich auf AWS in verschiedenen
Formen betreiben