• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Scalability meetup-05-2013-presentation

Scalability meetup-05-2013-presentation







Total Views
Views on SlideShare
Embed Views



4 Embeds 11

http://localhost 5
https://twitter.com 3
http://formacionmestreacasa.gva.es 2
http://pulse.me&_=1368658857269 HTTP 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.


11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Hackaton

Scalability meetup-05-2013-presentation Scalability meetup-05-2013-presentation Presentation Transcript

  • How to scale yourplatform when youare not Facebook2013 Carlos Herreracaherrerapa@gmail.com
  • CTO - Binumi, former Head of Product and IT –Lazada TH (Rocket Internet)MBA and B. Computer Science7 countries10 years in tech. Contributed to some OSSProduct Management, Software dev, ethicalhacking, corporate governanceCoca Cola FEMSA, Infosys, among othersWho am i?
  • Be humble“Normal” scale platforms are different.–Customer paying vs Like a cat–Sensitivity*–Structured information vs Unstructured–Concurrency–Reach across regions–GBs vs Several TB or PBWhy I shouldn’t do exactly as fb?
  • You scale a platform not a language*Language selection drivers– Problem– Maturity– Community– Talent poolNice to experiment but focus on theproblem (yes, im talking about youmongodb guys)Different solutions / Creativity
  • No silverbullet
  • Scaling in 7steps
  • How does it start?Everything on thesame serverReading the DBall the timeJS, CSS, Imagesserved from yourserver
  • 1. Define, measure, benchmarkb. MeasureMuninIcingaStatsdNew Relic $Pingdom $c. BenchmarkSiegeJmeterSysbencha. Baremetal vs Cloud (Amazon)Physical vs VirtualizedPowerful vs FlexibleNormal skills vs Hard core skillsSupport vs On your ownOutages?Avoid anything with Cpanel for God’s sakeInternational gateway
  • Cache?Set content in memory/driveFaster than DBKey = ValueTTLMemcached (> 1 server), APC (1server)Other Common use: sessionsExtremely important in cloudLive without cacheConstant hits to DBDB easily the bottleneckWasting $$ you paid for memory2. Cache system
  • 2. Cache systema. Customer goes to your website’s homepageb. The page requested needs to load a list ofproductsc. Is the list of products in the cache by the key“XXXXX”?a. Yes. Retrieve from cache using key“XXXXX”, use it and return page.b. No. Go to the Database, perform the queryand save it in cache for later, use the infoand return the page.IntroducingCache
  • Content DeliveryNetworkStatic files (CSS, JS, HTML,JPG)Amazon, Rackspace,Cloudflare, AkamaiCDN< Page Load time< Server load (importantin cloud)Inexpensive> Automation3. Content Delivery Network
  • 4. Decouple and revisit yourweb node Separation of concernsWebnodes apart from DBMore visibilityEasier to scaleHorizontalVerticalEvaluate Nginx, Puma(RoR)PHP-FPM
  • 5. Adding web nodes / load balancingLoad BalancerSends traffic to internal web nodesEasier to pay. ELB*, RackspaceNo budget? Nginx, HAProxyLocation depends if you pay or youbuild it*www.yourapp.comweb01.yourapp.comweb02.yourapp.com
  • Beware of the sessionmanagementIf you don’t use sticky sessionsbe careful you can end up notremembering your customers asthe load balancer sends trafficto the less busy5. Adding web nodes / load balancing
  • 6. Scaling the database:verticalVerticalBigger serverRDS (downtime)EasierBut there is a limit
  • 7. Scaling the database:horizontalMaster / SlaveMore of effort for sysadminMasterImportant readsAlways writesSlaveOnly ReadsConsider delayEnough for1000RPM pernode*
  • Need more?Separate memcache serversShardingRAIDsIf you are doing heavy search addApache SolrRevisit your problemDo you need HadoopCan you use NoSQL (Cassandra,Mongo)?
  • Something is not working?Revisit your database designIndexes anyone?Revisit your app designPessimistic locks?Lack of good algorithms?
  • Bottleneck => web nodesWe added one web and dbRPMUsed historical performance dataRackspace (no choice)Reduce loaded elements on frontpageStandby - Monitor APDEXWe did well. No downtimesTV and BTS at Lazada
  • 20-25% of the traffic just to one pageThat page was on a small server wecontrolled in TH2 hours handling our own end of theworld12/12/12 Campaign
  • Tech communication with businessMonitoringVPSStatic filesCacheWhat could be done better?SolutionDelay traffic / Business guysEC2CloudfrontCache and fix codeNew relic
  • 1M video clips20K+ video clips per monthHeavy searchStreamingFast quick preview. Faster than Animoto orWevideoRendering
  • Somelessonslearnt
  • 7 DO’s
  • 1. No fear
  • 2. Iterate fast
  • 3. Decouple andcreate interfaces
  • 4. Track andMonitor
  • 5. Version andmanagebranches
  • 6. Use the right tools
  • …”mmm I will need abigger drill”
  • 7. Codeconventions /Process
  • 7 DON’Ts
  • 1. Don’t do“Temporary fixes”Bad code is likeKarma
  • 2. “DRY”*
  • 3. Don’tmodify“Live” filesordatabasesdirectly
  • 4. Don’tforgettestingenvironment
  • 5. Don’t use self-managedservers
  • 6. Don’t be thelast to know
  • 7. Don’t scaletoo soon just beprepared
  • Where do I see how the big guys do?https://github.com/blog/530-how-we-made-github-fasthttp://nerds.airbnb.com/http://www.facebook.com/Engineeringhttp://engineering.twitter.com/http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html
  • Interesting projectsApache Mesos (Distributed apps).Cassandra (Database)Kentrel (Queue)BERT (RPC)Apache HadoopApache ZookeeperHipHopVM
  • Do you code in PHP?I’m Hiringcaherrerapa@gmail
  • “Scaling is like replacingall components on a carwhile driving it at 100mph.”“Initial scaling won’t beglamorous”