Using Data to Determine Where to Build a New Data Center
•Descargar como PPTX, PDF•
2 recomendaciones•4,923 vistas
Gene Yaacobi, Infrastructure Manager at Shutterstock, presents how his team uses active probing of their applications from around the world to help with choosing new data center locations.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Using Data to Determine Where to Build a New Data Center
Similar a Using Data to Determine Where to Build a New Data Center (20)
Más de ThousandEyes
Más de ThousandEyes (20)
Último
Último (20)
Using Data to Determine Where to Build a New Data Center
- 1. Using Data to Determine Where to Build a New Data Center Eugene Yaacobi, Shutterstock
- 2. Who Am I? • Nerd • Manager, Infrastructure @ Shutterstock • I also like cars
- 3. A Little About Shutterstock • We are a stock photo, footage, and music company • 12 years old - founded in 2003 • Made in NY • Offices in Amsterdam, Berlin, Chicago, Dallas, Denver, London, Los Angeles, Montreal, Paris, San Francisco, and Silicon Valley • Over 600 employees • 4 images sold every second • Focus on volume, unbiased search experience. • Translated into 20 languages • Accepting 9 currencies • Customers in 150+ countries
- 4. A Little About Shutterstock (cont.) • Two-sided marketplace • Over 1.3 million active customers from 150 countries • 80,000 contributors in 100 countries • 60 mm images; over 50,000 images added every day (look at the counter on the site and round down to the nearest million) • 3mm+ video clips; over 90% HD, 160,000 4K clips, and 3,000 videos added every day • 500 mm paid downloads to date, selling 4 images per second • $350 mm paid to contributors since 2003
- 5. Infrastructure at Shutterstock • The service that every other service is built on: • 3 Datacenters • 4,000 servers running CentOS • Servers are mostly virtualized • ~500 network devices • Brocade load balancers • Juniper routers and switches, running JunOS
- 6. The Infrastructure Group at Shutterstock • First responders to site issues • 1OC for immediate alerts • Made up of five teams: • SRE - training • Tools - internal tooling • Storage - Purchasable asset storage • Assets - Hardware acquisition • Traffic - Network engineering
- 7. Hey Infrastructure Where do we put our next deployment?
- 8. Great question! Our assets are downloaded all over the world
- 9. Every second counts! 40% of people abandon a website that takes more than 3 seconds to load.
- 10. If an e-commerce site is making $100,000 per day, a 1 second page delay could potentially cost you $2.5 million in lost sales every year This makes executives sad pandas
- 11. Step 1 Decide what regions are important to you
- 12. Step 2 Create some Tests
- 13. Step 3 Let Simmer
- 14. Step 4 Review and Analyze
- 15. Look at response times Pay attention to where the client is spending more time
- 16. Look at your page loads Good starting spot is your worst performer
- 17. Drill down into your data You can learn some cool things
- 18. Waterfalls are super useful Use them
- 19. What else can the data be used for? Things
- 20. Like what? • Ad-Hoc Troubleshooting • Monitor and Alert on Overall Site Performance • Does the site function properly and efficiently in all locations? • If not: • Which locations are performing under expectations? • Why are these locations seeing degraded performance?
- 21. Bananas are Yummy So are Grapes Now you know where to deploy your next site
Notas del editor
- Started my life as a sysadmin when I was in Junior High. I found a Red Hat 7.2 disc inside of a Red Hat For Dummies book, and popped the disc in Eventually I figured out my way around the command line I thought it would be a great idea to make some money with my uber linux skills and started a hosting company. Since being old enough to hold real jobs, I’ve mostly worked at various managed hosting companies and lead teams at them. Joined Shutterstock in 2013 as part of the WebOps group while on that group I built out an Openstack cluster, ultimately moved into the Infrastructure Group where I took over our datacenter and network operations before transitioning to my position today as Manager of Infrastructure.
- We are a stock photo, footage, and music company: 12 years old - founded in 2003 Made in NY Offices in Amsterdam, Berlin, Chicago, Dallas, Denver, London, Los Angeles, Montreal, Paris, San Francisco, and Silicon Valley Over 600 employees 4 images sold every second Focus on volume, unbiased search experience. Translated into 20 languages Accepting 9 currencies Customers in 150+ countries
- Everything you build or sell lives on top of the basic Infrastructure we design, scale & maintain. Our goal is to build & maintain a first class Infrastructure to enable + Sales and Accounts teams to keep our customers delighted + Product and Engineering teams to rapidly make new products Finance teams to support all business units What is the environment like Servers: CentOS Network: JunOS 4k Running Instances - Mostly Virtual 3 Datacenters Interesting facts Stacked end to end, the amount of hard drives we use today is as tall as the Eiffel Tower Power Statistic from 2020 Talk
- We are the first responders Infrastructure Supports over 30 product teams 1OC SEV-0/1 Rest of team works on longer term projects/assists as needed A day in the life of a network Engineer Office Build-outs WiFi Improvement Projects Standardization / Automation Standards Process (Using GitHub for +1,0,-1) Troubleshooting (should somehow tie in how we use ThousandEyes) Segway into Infra building out a new site
- https://blog.kissmetrics.com/loading-time/
- https://blog.kissmetrics.com/loading-time/
- Many ways to figure this out Google Analytics (see where your traffic is coming from) I picked 10 places that I’d like to visit for this example and setup a
- Let the data collect
- I built a report in ThousandEyes with some things you may want to look at Average page load times Average response times
- Sometimes a performance issue is related to the application and the network isn’t the bottleneck
- In my test example, I will use South Korea
- The important thing is to have the Connect, SSL, and Receive as low as possible By being closer to the end-user we can shorten these times and have better performance
- Adhoc Troubleshooting Better visualization into how pervasive a reported issue is: Is it global? Is it only occurring in one location? If so, is it widespread in that location, or just a few ISPs having trouble?