Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Scale to Infinity with ECS

46 Aufrufe

Veröffentlicht am

Our challenge is to provide a container cluster as part of the Cloud Platform at Scout24. Our goal is to support all the different applications with varying requirements the Scout24 dev teams can throw at us. Up until now, we have run all of them on the same ECS cluster with the same parameters. As we get further into our AWS migration, we have learned this does not scale. We combat this by introducing categories in one cluster with different configurations for the service. We will introduce how we tune each category differently, with different resource limits, different scaling approaches and more…

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Scale to Infinity with ECS

  1. 1. www.scout24.com Scale to Infinity with ECS Berlin | 2018 | Christine Trahe, Cloud Platform Engineering
  2. 2. 2 Overview
  3. 3. Who are Scout24? 3
  4. 4. 4 Containerized Applcations Hosted on AWS
  5. 5. Platform Engineering, Scout24 Enabling product engineers to focus on devliering value to Scout24 consumers and customers.
  6. 6. What does an application need? 6
  7. 7. Platform Vision 8
  8. 8. Running at Scale
  9. 9. Multi-Account Strategy 10
  10. 10. Keeping it simple 11 Custom resource Basic configuration Mandatory Tagging
  11. 11. Shared compute resources 12
  12. 12. Centralized compute infrastructure 13
  13. 13. Logging and Monitoring 14
  14. 14. Overview 15
  15. 15. Problems we faced
  16. 16. But it doesn‘t scale to Infinity just yet… 17 Too much CPU consumption on the container instances Load Balancer response time (latency) increases, causing real time customer impact
  17. 17. Sharing resources not ideal… 18
  18. 18. Categorizing Services
  19. 19. Application differences 20
  20. 20. Categorizing Services to their needs 21
  21. 21. Outcome 22 CPU Hard Limit • Latency sensitive run more reliably • Not burstable above reservation à Faster scaling on lower threshold CPU Burst Ability • Cannot rely on getting the CPU needed. • Consider hard limit as • Right-size containers
  22. 22. Next Steps
  23. 23. Evaluating EKS/K8S 24 • Tools/solutions/support with a huge community • More than a container orchestrator, but an ecosystem
  24. 24. Christine Trahe October, 2018 | Cloud Platform Engineering, Scout24 Questions?