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.

Knowledge share about scalable application architecture

scalable application architecture key point description

  • Login to see the comments

Knowledge share about scalable application architecture

  1. 1. 1 Scalable Application Architecture Common Patterns & Approaches AHM Pervej Kabir & ERA-InfoTech Limited Cell:+8801757051005
  2. 2. 2 Presentation Indicator  1. Introduction for understanding Scalable Apps.  2. Network Based Architecture  3. Application Based Architecture
  3. 3. 3 Introduction Scalable Web Architectures? - What does scalable mean? - What’s an architecture? An answer has in next 12 parts.
  4. 4. 4 Understanding- 1. Scaling  What is Scalable? Scalable means Expandable. Referring to hardware or software or application that can handle a large increase in users, workload or transactions without undue strain. Scalability is a system's ability to process more workload.  What is scalability not ?  Raw Speed / Performance  HA / BCP  Technology X  Protocol Y
  5. 5. 5 Understanding- 1. Scaling  Objectives of scalability  Traffic growth  Dataset growth  Maintainability  Two kinds of scalability:  Vertical (get bigger)  Horizontal (get more)
  6. 6. 6 Understanding-2.Architecture Architectures then?  The way the bits fit together  What grows where  The trade-offs between good/fast/cheap Storage array Cache AJAX!!!1 App server DatabaseInternet
  7. 7. 7 Understanding-2.Architecture App servers scale in two ways:  Really well  Quite badly Sessions :  (State)  Local sessions == bad  When they move == quite bad  Centralized sessions == good  No sessions at all == awesome!
  8. 8. 8 Understanding-2.Architecture Super slim sessions Properties:  If you need more than the cookie (login status, user id, username), then pull their account row from the DB  Or from the account cache  None of the drawbacks of sessions  Avoids the overhead of a query per page  Great for high-volume pages which need little personalization  Turns out you can stick quite a lot in a cookie too  Pack with base64 and it’s easy to delimit fields
  9. 9. 9 Understanding-2.Architecture Apps Server:
  10. 10. 10 Understanding-2.Architecture  Scaling the web app server part is easy  The rest is the trickier part  Database  Serving static content  Storing static content  Other services scale similarly to web apps  That is, horizontally  The canonical examples:  Image conversion  Audio trans coding  Video trans coding  Web crawling  Compute
  11. 11. Hardware Load balance:  A hardware appliance  Often a pair with heartbeats for HA  Expensive!  But offers high performance  Many brands  Alteon, Cisco, Netscalar, Foundry, etc  L7 - web switches, content switches, etc 11 Understanding-3. Load Balancing
  12. 12. Software Load balance:  Lots of options  Pound  Perlbal  Apache with mod_proxy  Wackamole with mod_backhand 12 Understanding-3. Load Balancing Wakamole
  13. 13. Parallelizable:  If we can transcode/crawl in parallel, it’s easy  But think about queuing  And asynchronous systems  The web ain’t built for slow things  But still, a simple problem 13 Understanding-4. Queuing
  14. 14. 14 Understanding-4. Queuing Asynchronous SystemSynchronous System
  15. 15. 15 Understanding-5. Relational Data Databases:  Unless we’re doing a lot of file serving, the database is the toughest part to scale  If we can, best to avoid the issue altogether and just buy bigger hardware  Dual Opteron/Intel64 systems with 16+GB of RAM can get you a long way Read Power of Apps:  Web apps typically have a read/write ratio of somewhere between 80/20 and 90/10  If we can scale read capacity, we can solve a lot of situations  Database replication!
  16. 16. 16 Understanding-5. Relational Data
  17. 17. 17 Understanding-6. Caching  Caching avoids needing to scale!  Or makes it cheaper  Simple stuff  mod_perl / shared memory  Invalidation is hard  Database query cache  Bad performance (in most cases)  Getting more complicated…  Write-through cache  Write-back cache  Sideline cache
  18. 18. 18 Understanding-6. Caching  Getting more complicated…  Write-through cache  Write-back cache  Sideline cache Write-through Write-back Sideline
  19. 19. 19 Understanding- 7.HA Data  The key to HA is avoiding SPOFs  Identify  Eliminate  Some stuff is hard to solve  Fix it further down the tree  Dual DCs solves Router/Switch SPOF
  20. 20. 20 Understanding-7. HA Data Master-Master:  Either hot/warm or hot/hot  Writes can go to either  But avoid collisions  No auto-inc columns for hot/hot  Bad for hot/warm too  Unless you have DB  But you can’t rely on the ordering!  Design schema/access to avoid collisions  Hashing users to servers
  21. 21. 21 Understanding-7. HA Data Ring:  Master-master is just a small ring  With 2 nodes  Bigger rings are possible  But not a mesh!  Each slave may only have a single master  Unless you build some kind of manual replication
  22. 22. 22 Understanding-7. HA Data Dual Tree:  Master-master is good for HA  But we can’t scale out the reads (or writes!)  We often need to combine the read scaling with HA  We can simply combine the two models
  23. 23. 23 Understanding-8. Federation Data Federation:  At some point, you need more writes  This is tough  Each cluster of servers has limited write capacity  Just add more clusters  Split up large tables, organized by some primary object  Usually users  Put all of a user’s data on one ‘cluster’  Or shard, or cell  Have one central cluster for lookups
  24. 24. 24 Understanding-8. Federation Data Federation:  Need more capacity  Just add shards!  Don’t assign to shards based on userid!  For resource leveling as time goes on, we want to be able to move objects between shards  Maybe – not everyone does this  ‘Lockable’ objects
  25. 25. 25 Understanding-8. Federation Data Federation:  Need more capacity?  Just add shards!  Don’t assign to shards based on userid!  For resource leveling as time goes on, we want to be able to move objects between shards  Maybe – not everyone does this  ‘Lockable’ objects
  26. 26. 26 Understanding-8. Federation Data Federation:  Heterogeneous hardware is fine  Just give a larger/smaller proportion of objects depending on hardware  Bigger/faster hardware for paying users  A common approach  Can also allocate faster app servers via magic cookies at the LB
  27. 27. 27 Understanding-8. Federation Simple things first:  Vertical partitioning  Divide tables into sets that never get joined  Split these sets onto different server clusters  Logical limits  When you run out of non-joining groups  When a single table grows too large
  28. 28. 28 Understanding-9. Multi-site HA Multiple Data centers:  Having multiple datacenters is hard  Not just with one DB  Hot/warm with DB slaved setup  But manual (reconfig on failure)  Hot/hot with master-master  But dangerous (each site has a SPOF)  Hot/hot with sync/async manual replication  But tough (big engineering task)
  29. 29. 29 Understanding-10. File Servings  Serving lots of files is not too tough  Just buy lots of machines and load balance!  We’re IO bound – need more spindles!  But keeping many copies of data in sync is hard  And sometimes we have other per-request overhead (like auth.) Reverse Proxy
  30. 30. 30 Understanding-10. File Servings  Serving out of memory is fast!  And our caching proxies can have disks too  Fast or otherwise  More spindles is better  We stay in sync automatically  We can parallelize it!  50 cache servers gives us 50 times the serving rate of the origin server  Assuming the working set is small enough to fit in memory in the cache cluster Reverse Proxy
  31. 31. 31 Understanding-10. File Servings Invalidation:  Dealing with invalidation is tricky  We can prod the cache servers directly to clear stuff out  Scales badly – need to clear asset from every server – doesn’t work well for 100 caches  We can change the URLs of modified resources  And let the old ones drop out cache naturally  Or prod them out, for sensitive data  Good approach!  Avoids browser cache staleness  Hello Akamai (and other CDNs)
  32. 32. 32 Understanding-10. File Servings Perlbal backhanding:  Perlbal can do redirection magic  Client sends request to Perbal  Perlbl plugin verifies user credentials  token, cookies, whatever  tokens avoid data-store access  Perlbal goes to pick up the file from elsewhere  Transparent to user
  33. 33. 33 Understanding-10. File Servings Permission URLs:  If we bake the auth into the URL then it saves the auth step  We can do the auth on the web app servers when creating HTML  Just need some magic to translate to paths  We don’t want paths to be guessable
  34. 34. 34 Understanding-11. Storing File  Storing files is easy!  Get a big disk  Get a bigger disk  Horizontal scaling is the key  Again Connecting to storage:  NFS  Stateful == Sucks  Hard mounts vs Soft mounts, INTR  SMB / CIFS / Samba  Turn off MSRPC & WINS (NetBOIS NS)  Stateful but degrades gracefully  HTTP  Stateless == Yay!  Just use Apache
  35. 35. 35 Understanding-11. Storing File Multiple volumes:  Volumes are limited in total size  Except (in theory) under ZFS & others  Sometimes we need multiple volumes for performance reasons  When using RAID with single/dual parity  At some point, we need multiple volumes
  36. 36. 36 Understanding-11. Storing File HA Storage:  HA is important for assets too  We can back stuff up  But we tend to want hot redundancy  RAID is good  RAID 5 is cheap, RAID 10 is fast  But whole machines can fail  So we stick assets on multiple machines  In this case, we can ignore RAID  In failure case, we serve from alternative source  But need to weigh up the rebuild time and effort against the risk  Store more than 2 copies.
  37. 37. 37 Understanding-12. Field work  Flickr  Because we know it  LiveJournal  Because everyone copies it
  38. 38. 38 Understanding-12. Field work Flickr Architecture:
  39. 39. 39 Understanding-12. Field work LiveJournal Architecture:
  40. 40. 40 Network Based Architecture
  41. 41. 41 Application Base Architecture Contain: 1. Why n-tier? 2. Layers. 3. Monolithic or 1-tier architecture. 4. 2-tier architecture. 5. 3-tier architecture. 6. Need of MVC. 7. MVC architecture. 8. MVC components. 9. Comparison between MVC and 3-tier.
  42. 42. 42 Application Base Architecture 1. Why n-tier: Need of e-commerce solutions; increase in users and merchant sites all over the world. Applications should be scalable, user-friendly, have tight security and easily maintainable. 2. Layer: Layer means logical. Tier means physical. Generally there are three layers:- Presentation Business Data access layer
  43. 43. 43 Application Base Architecture Layers Presentation: Presentation Layer: involves with client and application interaction. Provides user friendly interface for the clients. Business Layer: contains the application code or the core functionalities of the application or what the application will perform. Data access Layer: involves with the maintaining database and storage of data.
  44. 44. 44 Application Base Architecture 3. Monolithic or 1-tier: 1.Presentation layer, Business layer and Data Access layer are tightly connected. As the layers are tightly connected(depends on each other), if any of the layer code are changed then other layers should be affected and the codes in other layers need to be changed. 2.Traditional approaches of the applications are based on this type of architecture. Typically implementation of 1-tier architecture can be a C program running in a computer. 4. 2-tier: 1.In this type of architectures the presentation layer, the business logic layer are separated from the data access layer. 2.The advantages of this layer is that the code of the data access layer can be changed any time without affecting the code of the other layer i.e. the whole database and the layer can be changed anytime. 3.The database(i.e. the data access layer) can be present anywhere around but the other two layers should be together(tightly connected). 4.As the presentation and the business logic are still connected they should be present at the client side to work together; due to the concentration of the client this type of client is called thick client. 5.Problems faced by this type of architecture is the client should always get the updated copies of the application if there is a change in the application codes or application developer modifies the application. 6.The application developer may not want to give the code to the relatively third parities even if the code is pre compiled
  45. 45. 45 Application Base Architecture 2-Tire Architected:
  46. 46. 46 Application Base Architecture 5. 3-tier: 1.In this type of architecture the presentation layer, the business logic layer and the data access layer are separated from each other and are present on three different tiers therefore they are loosely connected. 2.The main advantages is that any change in the code in one layer will not affect the other layers and the platform can also be changed independently. 3.Now the web designer can concentrate on the design of the user interface i.e. the presentation logic, the application developer concentrate on developing the application i.e. the business logic and the database manager can handle the database independently. 4.Today’s application are based on 3-tier architecture which are scalable, easy to maintain, components are reusable and faster development
  47. 47. 47 Application Base Architecture 6. Need Of MVC Architecture : Need to access the data from different context such as mobiles, touch screen, desktop, etc.  Need to show the data in different context such as mobiles, touch screen, desktop, etc.  Need to show multiple views of the same data such as Thumbnails, List or details. Need to change the designs without changing the core business logic. 7. MVC Solution:  Separate the core business logic form the presentation logic.  Separate views for the same data.
  48. 48. 48 Application Base Architecture MVC Architecture :
  49. 49. 49 Application Base Architecture 8. MVC Component: Model: It contains the core functionalities and the business logic of the application. It accepts the state query from the model and controller and it provides the updated information to the view component. View: This component is responsible for the presentation logic and the user interaction between the application. The model provides different information to different user which can be represented in different ways. The main work of the view component is to provide the suitable information to the user. Controller: It accepts the user input through the view component and process them and if any changes are required then it perform the changes after that it response to the client 9. MVC Vs. 3-tier: 1. In MVC architecture the components communicate directly with each other in order to maintain a coherent user interaction but in case of 3-tier the presentation layer(front end) communicates with the data access layer(back end) through the business layer(middleware). 2. In 3-tier the Layers are present on three different tiers or machines where as in MVC the layers are present on single tier or machines.
  50. 50. 50 Scalable Application Architecture Thank You