Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RedisDay London 2018 - How Redis Powers BBC Online's Biggest Pages

101 views

Published on

RedisDay London 2018

Published in: Technology
  • Be the first to comment

RedisDay London 2018 - How Redis Powers BBC Online's Biggest Pages

  1. 1. How Redis Powers BBC Online’s Biggest Pages Jonny Glancy BBC Sport
  2. 2. • Background
 • What
 • Why
 • How
 • Redis
 • Action
 • Summary 2
  3. 3. 3 Background
  4. 4. 4
  5. 5. 5
  6. 6. 6 Pattern
  7. 7. • Responsible for a single, non-trivial, business-understandable task
 • Smaller than a microservice, larger than a function
 • Likely to call other nanoservices, to offer rich functionality
 • The ideal sized package to release (or MVT) in a CD environment
 • All the benefits of microservices, without the infrastructure… right? Nanoservices 7
  8. 8. 8 Why Nanoservices?
  9. 9. 9
  10. 10. 10
  11. 11. 11 Dev Ops UX Test
  12. 12. 12 Benefits of Nanoservices
  13. 13. • Model means that teams can focus on building product differentiators – not re- creating platform infrastructure
 • Templates encapsulate logic or presentation that can be shared and reused • Reduced testing overhead with clear tools & processes
 • Managed CI deployment pipelines take nanoservice templates from laptop to live
 • ‘Deploy and forget’ - Centralised DevOps process embedded within platform team Benefits for our Teams 13
  14. 14. • Pages that load fast and update automatically • Faster development allows features to be released sooner with greater functionality • Greater quality of delivery • Platform is able to handle our biggest audiences, reliably Benefits for our Audience 14
  15. 15. • We’ve seen new teams spawn, producing entire websites in a fraction of the time that the organisation used to see
 • Ready to go… The editorial team were still trying to work out their strategy! CBBC Newsround 15
  16. 16. 16 Great… Lets Go Deeper!
  17. 17. 17 Scorecard Title Carousel Summary Live Stream Innings Table
  18. 18. 18 Live Page Header Body Carousel Title Media Data Media API Sport Event Data Sport Data API Content Data Content API Summary Innings Table Live Stream Stream Data Stream API Scorecard
  19. 19. 19
  20. 20. 20 Redis
  21. 21. 21
  22. 22. • For us, it is much more than just a key-value store • Multiple data types, LUA scripting, Pub/Sub
 • Automates common administrative tasks (failed nodes, server optimisation)
 • Multiple options available (different memory and network sizes)
 • Can grow with sharding and/or replication Elasticache 22
  23. 23. • Poor utilisation of resource • We’re often scaling vertically to satisfy capacity needs
 • Using 100% CPU of one core whilst 15 other cores are sat idle
 • Slow to receive engine version updates
 • Can’t extend with modules
 • £££££££££ Elasticache… 23
  24. 24. 24 Developer Data (APIs, etc.) Audience Nanoservice Store Nanoservice Platform Content Cache Metadata Store Queues
  25. 25. • Every output from every run of every nanoservice is stored
 • Cheap, simple, ephemeral
 • Flexible eviction policies, LRU in our case
 • Maximises reuse, speed, reliability, and scalability Redis: Content Cache 25
  26. 26. 26 Keys
  27. 27. 27 Memory
  28. 28. • Metadata about every request, and its ‘tree’, is stored in Redis
 • If the data changes, the metadata informs us what nanoservices to rerun
 • The ‘relationship’ is stored both ways: A>B and B>A
 • Lua can help make atomic Redis: Metadata Store 28 Scorecard Sport Event Data Sport Data API Innings Table
  29. 29. • Operations involving state mutations are critical
 • Loss of relationships, both up and down the tree, can cause “stuck” state
 • Using LUA vs Redis Transactions means we avoid clashes and can perform operations across multiple keys Redis: Metadata Store 29 Scorecard Sport Event Data Sport Data API Innings Table
  30. 30. • Redis, as a queue, is extraordinarily fast (<5 ms end-to-end journey)
 • It’s the only solution fast enough for this architecture
 • We comfortably do >10k messages per second Redis: Queues 30
  31. 31. • Doesn’t really work with replication, SPOF!
 • Lossy (due to consumer failure)
 • Can be offset with by using an in-progress-queue and something to analyse it
 • Harder to scale Redis: Queues 31
  32. 32. 32
  33. 33. 33 Action
  34. 34. 34 T1 T2 SD
  35. 35. 35 RendererFetcher API Caches Queues Service Data T1 T2 SD
  36. 36. 36 Summary
  37. 37. • Redis has mega performance potential, not just in caching content, but as a control and communication layer • This can let you build fast and flexible serverless-like platforms that allow your organisation to move faster
 • The nanoservice pattern is an interesting way to design for serverless, and can maximise the potential of continuous delivery, reusability, and flexibility
 • Without Redis, we wouldn’t be able to do what we’re doing as a product and a greater organisation Summary 37
  38. 38. Thank you!

×