• Speichern
MongoDB-Skalierung auf echter Hardware vs. Amazon EC2
Nächste SlideShare
Wird geladen in ...5
×

Das gefällt Ihnen? Dann teilen Sie es mit Ihrem Netzwerk

Teilen

MongoDB-Skalierung auf echter Hardware vs. Amazon EC2

  • 1,842 Views
Hochgeladen am

Robert und Markus von der Team Internet AG sprachen im Rahmen der MongoDB Usergroup München über die Erfahrungen von ParkingCrew & DNTX bzgl. MongoDB und die Unterschiede von echter Hardware und......

Robert und Markus von der Team Internet AG sprachen im Rahmen der MongoDB Usergroup München über die Erfahrungen von ParkingCrew & DNTX bzgl. MongoDB und die Unterschiede von echter Hardware und virtualisierten Umgebungen am Beispiel Amazon Web Services (EC2)

Mehr in: Technologie
  • Full Name Full Name Comment goes here.
    Sind Sie sicher, dass Sie...
    Ihre Nachricht erscheint hier
Keine Downloads

Views

Gesamtviews
1,842
Bei Slideshare
1,828
Aus Einbettungen
14
Anzahl an Einbettungen
2

Aktionen

Geteilt
Downloads
0
Kommentare
1
Gefällt mir
3

Einbettungen 14

https://twitter.com 13
https://www.rebelmouse.com 1

Inhalte melden

Als unangemessen gemeldet Als unangemessen melden
Als unangemessen melden

Wählen Sie Ihren Grund, warum Sie diese Präsentation als unangemessen melden.

Löschen
    No notes for slide

Transcript

  • 1. WanneszuspätzumHochskalierenist,wiemanmitBalancingdenClusterabschießtundanderelehrreicheKatastrophen:ÜberunsereErfahrungenmitMongoDBaufechterHardwareundAmazonEC2Markus Ostertag und Robert Schmalholz
  • 2. Werist„MarkusOstertag“?• Online-Business seit>15 Jahren• Diplom-Informatik TU München• Gründer MovieMaze.de(Verkauf 2012)• Skalierungs- und AWS-“Experte“• Seit 11/2012 bei TeamInternetalsHead of Development (AdvertiserProducts)
  • 3. Werist„RobertSchmalholz“?• Head of Development(Publisher Products)bei Team Internet• Angefangen 09/2010 als Nebenjobim IT-Studium• Unglaubliche23 Jahrejung• 15 JahreProgrammiererfahrung
  • 4. ParkingCrew• UngenutzteDomains monetarisieren– Einblenden von passenden Anzeigen auf optimierten Templates(Targeting)• Anbindung an DNTX für Direct Navigation Traffic• IntelligentesOptimierungssystem
  • 5. ZahlenzuParkingCrew• 15 Mio. Domains im System• 50 Mio Uniques / Monat• 400 Impressions/ Sekunde• 1k inserts& 10k queries / Sekunde• 1 TB Trackingdaten/ Monat
  • 6. Anforderungen andieDatenbank• Writesund Readsstark parallelisiert(Concurrency)– Trackingdaten vs. Abfragen von Domaindaten, Blocklisten etc.• Scalability– Wachstum vor allem in der DB• Availability– Jede Sekunde Downtime kostet Geld
  • 7. Hardware• ErsteSetups mit Single-HDD Servern– Anfänglicher Gedanke: rein horizontale Skalierung– Limits pro einzelner Maschine schnell erreicht• Performance-Tuning:– readahead klein halten (16k oder 8k)– syncdelay klein halten (10s)
  • 8. Setup1–AllerAnfangistschwer• Master/SlaveReplication• Immer wiederLastprobleme– Reads während Writes stark verzögert
  • 9. Setup2-Replication• Schreibenauf Primary,lesen vonSecondaries• Probleme:– Zuviele Daten pro Maschine– Slave-Lag
  • 10. Setup3–Sharding(Theoretisch)• Setup wie in Ideal-Vorstellung• Theoretischspätererweiterbar– Aber: Wie bekommt man dieDaten auf die neuenMaschinen?
  • 11. Balancer• Idee:– Autom. Splitten vorhandener Einträge und Neuverteilungunter allenShards• Problem:– Während der Balancerläuft, erhöht sich dieLast des Clustersexponentiell• Out-of-the-BoxMaßnahmen:– Balancer Windowsnutzen(sowie möglich)– So gut wie möglich pre-splitten und pre-sharden– Chunksizeverringern auf 32MB oder sogar 16MB
  • 12. Trackingdatenrotieren• Wegen Remove-und Balancerproblemen-> Alternativlösungnotwendig• Vor dem Hinzufügen von Maschinen(oder regelmäßig):– Anlegen einer neuen Datenbank (+Indexe, Sharding etc.)– Umschalten des Live-Tracking auf die neue Datenbank– Archivieren vorhandener Trackingdaten
  • 13. Shard-Key• Ziele:– Optimale Wahl um Balancerarbeit zu verringern/vermeiden– Möglichst gute Gleichverteilung des Shard-Key– Shard-Key in den meisten Queries nutzbar
  • 14. Shard-Key• Beispiel 1:– { _id: ObjectId(„...“), date: „2013-05-23“, domain:„example.com“,views: 10 }– Shard-Key (+Index) : { date: 1, domain:1 }• Vorteile:– Abfrage auf Date+Domain Kombination trifft genau einen Shard– Abfragen auf alle Domainseines bestimmten Tages nutzen Index• Nachteile:– Neue Datensätze entstehen immer am „rechten“ Ende des Clusters
  • 15. Shard-Key• Beispiel 2:– { _id : ObjectId(„...“),date: „2013-05-23“, domain: „example.com“,views:10, hash: „acdef0132...“}– Shard-Key(+Index): { hash : 1 }• Vorteile:– Identisch zu Beispiel 1– Zusätzlich: Neue Datensätzewerden gleichverteiltin den Clustereingefügt• Nachteile:– ErhöhteKomplexität durch zusätzlichen Hashingschritt– Keine Möglichkeit mehr Range-Queriesauf dem Shard-Indexauszuführen
  • 16. Setup4–Sharding(Variante2)• 2 UI-Webserver• 20 Parking-Webserver• 3 Config Serverfür MongoDB• 4 MongoS Server(je 5 Webserververbunden)• 3x3 MongoD Server (RAID10, 64GB RAM)
  • 17. Backup• Backup über Mongodumps– http://docs.mongodb.org/manual/tutorial/backup-databases-with-binary-database-dumps/– http://docs.mongodb.org/manual/tutorial/backup-sharded-cluster-with-database-dumps/• Backup über FilesystemSnapshots / Backups• Sharding+Replicationsichertdie meistenHardware-Faults• Absicherungprimär gegen menschlichesVersagen
  • 18. MongoDBaufBare-Metal-Takeaways• Readaheadso klein wie möglich• Syncdelay anpassen (fsync Delays)• Längerfristigplanen• RAID• Optional: Journaling auf SSD auslagern– Dazu /mongo-lib-path/journal auf die SSD einhängen– Und damit { j : true } in den Writes nutzen
  • 19. WasistDNTX?• Monetarisierungvon Domain Parking Traffic– DNTX bekommt Anfrage für jeden User von Parkingplattform– Sucht nach höchstem Gebot für diesen User (Real Time Bidding)– DNTX antwortet der Parkingplattform mit dem höchsten Gebotund einem Tracking-Link– Parkingplattform nimmt Gebot an und leitet auf DNTX-Trackinglink– DNTX übernimmt User und leitet auf Advertiser-Landingpage
  • 20. Anforderungen /aktuellerStand• >250 Requests/Sekundeauf den Feed (> 21 Mio. pro Tag)• >300 Mio. Unique User im Monat• Antwortzeitenmüssen <1 Sek. sein• RTBkomplex• >350.000 DB-Queries pro Sekunde– Ca. 80% Writes• >99,9% allerDB-Queries werden in <50msbeantwortet/verarbeitet
  • 21. Learnings vonParkingCrew• ReplicationSets• Sharding• Eigene Shard-Keys• Pre-Splittingund –Sharding• Rotationder Tracking-DB
  • 22. MongoDBaufAWS• Grundlegendes Setup– Instanztypen– Sharding / Replica-Sets– AZ-Verteilung• PIOPS vs. Non-PIOPS• RAID10 vs. RAID0• Readahead• Backupstrategie
  • 23. Grundlegendes Setup• Lesen:http://aws.amazon.com/whitepapers/mongodb-on-aws/• Instanztypen– m1.xlarge – EBS optimized– m2.xlarge – High Memory (aber kein EBS optimized)– m2.2/4xlarge – High Memory und EBS optimized (aber teuer)
  • 24. Grundlegendes Setup• Sharding– Frühzeitig einplanen– Ermöglicht Write-Skalierung• ReplicaSets– Auf AWS immer wenn möglich– Datensicherheit– Hochverfügbarkeit
  • 25. Grundlegendes Setup• AZ-Verteilung bei ReplicaSetsQuelle: http://docs.mongodb.org/ecosystem/tutorial/install-mongodb-on-amazon-ec2/
  • 26. PIOPSvs.Non-PIOPS• ProvisionedIOPS empfehlenswertaber teuer• Normale EBS haben ca. 100-200 IOPS, aber instabil• PIOPS ermöglichenMongoDB ohne RAID(nur ein EBS)– Vorteile für Backupstrategie
  • 27. RAID10vs.RAID0• RAID10 – Striping mit Mirroring– Erhöhter Datendurchsatz (Striping)– Datensicherheit (Mirroring)• RAID0 – Striping– Erhöhter Datendurchsatz• RAID0 bei Replica Setsausreichend– Datensicherheit wird auf MongoDB-Ebene sicher gestellt
  • 28. Readahead• EBS-Devices:RA auf 0• Raid-Device:RA auf 32k/16k• Generell gilt: Sehr klein und dauerhaft(/etc/rc.localetc.)• Page-Faults und ResidentMemory per MMS beobachten
  • 29. Backupstrategie• Bei PIOPS:– Nur ein EBS-Volume, davon Snapshot• Bei RAID:– „unsichtbaren“ Secondary (prio:0, hidden:true, votes:0)in jedemShard• slaveDelayfür Sicherheit• PIOPS-EBS• Snapshot von dieser Maschine
  • 30. MongoDBaufAWS–Takeaways• ReplicaSetsüber AZ verteilen• RAID0 stattRAID10 bei ReplicaSet• PIOPS nicht immer nötig• EBS-optimized wenn möglich• Readahead so klein wie möglich• Backups per EBS-Snapshot (mit „unsichtbarem“Secondarybei RAID)
  • 31. Socialising• Robert:– Mail:robert@teaminternet.de– Facebook:fb.me/DarkSn4ke– Skype:lordkhonsu• Markus– Mail:markus@teaminternet.de– Xing:xing.to/mo– LinkedIn:de.linkedin.com/in/ostertag– Facebook:fb.me/markus.ostertag