Building a Scalable Architecture for Web Apps - Part I Lessons Learned Directi

Building a scalable architecture for web apps part i lessons learned @ directi l.jpg
1 / 46
0
0
1410 days ago, 544 views
PowerPoint PPT Presentation

Presentation Transcript

Slide 1

By Bhavin Turakhia CEO, Directi ( http://www.directi.com | http://wiki.directi.com | http://careers.directi.com ) Building a Scalable Architecture for Web Apps - Part I (Lessons Learned @ Directi) Licensed under Creative Commons Attribution Sharealike Noncommercial

Slide 2

Agenda Why is Scalability critical Introduction to the Variables and Factors Building our own particular Scalable Architecture (in incremental strides) Vertical Scaling Vertical Partitioning Horizontal Scaling Horizontal Partitioning … and so on Platform Selection Considerations Tips Creative Commons Sharealike Attributions Noncommercial

Slide 3

Why is Scalability Important in a Web 2.0 world Viral promoting can bring about moment victories RSS/Ajax/SOA pull based/surveying sort XML conventions - Meta-information > information Number of Requests exponentially develops with client base RoR/Grails – Dynamic dialect scene picking up prevalence In the end you need to assemble a Web 2.0 application that can serve a great many clients with ZERO downtime Creative Commons Sharealike Attributions Noncommercial

Slide 4

The Variables Scalability - Number of clients/sessions/exchanges/operations the whole framework can perform Performance – Optimal use of assets Responsiveness – Time taken per operation Availability - Probability of the application or a bit of the application being accessible at any given point in time Downtime Impact - The effect of a downtime of a server/benefit/asset - number of clients, kind of effect and so on Cost Maintenance Effort High : versatility, accessibility, execution & responsiveness Low : downtime affect, cost & upkeep exertion Creative Commons Sharealike Attributions Noncommercial

Slide 5

The Factors Platform determination Hardware Application Design Database/Datastore Structure and Architecture Deployment Architecture Storage Architecture Abuse avoidance Monitoring instruments … and more Creative Commons Sharealike Attributions Noncommercial

Slide 6

Lets Start … We will now fabricate a case engineering for a case application utilizing the accompanying iterative incremental strides – Inspect ebb and flow Architecture Identify Scalability Bottlenecks Identify SPOFs and Availability Issues Identify Downtime Impact Risk Zones Apply one of - Vertical Scaling Vertical Partitioning Horizontal Scaling Horizontal Partitioning Repeat handle Creative Commons Sharealike Attributions Noncommercial

Slide 7

Step 1 – Lets Start … Appserver & DBServer Creative Commons Sharealike Attributions Noncommercial

Slide 8

Step 2 – Vertical Scaling CPU Appserver, DBServer CPU RAM Creative Commons Sharealike Attributions Noncommercial

Slide 9

Step 2 - Vertical Scaling Introduction Increasing the equipment assets without changing the quantity of hubs Referred to as "Scaling up" the Server Advantages Simple to actualize Disadvantages Finite cutoff Hardware does not scale straightly (unavoidable losses for each incremental unit) Requires downtime Increases Downtime Impact Incremental costs increment exponentially CPU Appserver, DBServer CPU RAM Creative Commons Sharealike Attributions Noncommercial

Slide 10

Step 3 – Vertical Partitioning (Services) Introduction Deploying every administration on a different hub Positives Increases per application Availability Task-based specialization, improvement and tuning conceivable Reduces setting changing Simple to actualize for out of band procedures No progressions to App required Flexibility expands Negatives Sub-ideal asset usage May not expand general accessibility Finite Scalability AppServer DBServer Creative Commons Sharealike Attributions Noncommercial

Slide 11

Understanding Vertical Partitioning The term Vertical Partitioning means – Increase in the quantity of hubs by dispersing the undertakings/capacities Each hub (or bunch) performs isolate Tasks Each hub (or group) is unique in relation to the next Vertical Partitioning can be performed at different layers (App/Server/Data/Hardware and so forth) Creative Commons Sharealike Attributions Noncommercial

Slide 12

Step 4 – Horizontal Scaling (App Server) Introduction Increasing the quantity of hubs of the App Server through Load Balancing Referred to as "Scaling out" the App Server Load Balancer AppServer DBServer Creative Commons Sharealike Attributions Noncommercial

Slide 13

Understanding Horizontal Scaling The term Horizontal Scaling indicates – Increase in the quantity of hubs by recreating the hubs Each hub plays out similar Tasks Each hub is indistinguishable Typically the gathering of hubs perhaps known as a group (however the term bunch is regularly abused) Also alluded to as "Scaling Out" Horizontal Scaling can be performed for a specific kind of hub (AppServer/DBServer and so forth) Creative Commons Sharealike Attributions Noncommercial

Slide 14

Load Balancer – Hardware versus Software Hardware Load balancers are speedier Software Load balancers are more adaptable With HTTP Servers stack adjusting is normally joined with http quickening agents Creative Commons Sharealike Attributions Noncommercial

Slide 15

Load Balancer – Session Management Sticky Sessions Sticky Sessions Requests for a given client are sent to a settled App Server Observations Asymmetrical load appropriation (particularly amid downtimes) Downtime Impact – Loss of session information User 1 User 2 Load Balancer AppServer Creative Commons Sharealike Attributions Noncommercial

Slide 16

Load Balancer – Session Management Central Session Storage Central Session Store Introduces SPOF An extra factor Session peruses and composes produce Disk + Network I/O Also known as a Shared Session Store Cluster Load Balancer AppServer Session Store Creative Commons Sharealike Attributions Noncommercial

Slide 17

Load Balancer – Session Management Clustered Session Management Easier to setup No SPOF Session peruses are immediate Session composes produce Network I/O Network I/O increments exponentially with increment in number of hubs In extremely uncommon conditions a demand may get stale session information User ask for achieves ensuing hub quicker than intra-hub message Intra-hub correspondence fizzles AKA Shared-nothing Cluster Clustered Session Management Load Balancer AppServer Creative Commons Sharealike Attributions Noncommercial

Slide 18

Load Balancer – Session Management Sticky Sessions Sticky Sessions with Central Session Store Downtime does not bring about loss of information Session peruses require not produce arrange I/O Sticky Sessions with Clustered Session Management No particular favorable circumstances User 1 User 2 Load Balancer AppServer Creative Commons Sharealike Attributions Noncommercial

Slide 19

Load Balancer – Session Management Recommendation Use Clustered Session Management in the event that you have – Smaller Number of App Servers Fewer Session composes Use a Central Session Store somewhere else Use sticky sessions just on the off chance that you need to Creative Commons Sharealike Attributions Noncommercial

Slide 20

Load Balancer – Removing SPOF Active-Passive LB In a Load Balanced App Server Cluster the LB is a SPOF Setup LB in Active-Active or Active-Passive mode Note: Active-Active by the by expect that every LB is autonomously ready to take up the heap of the other If one needs ZERO downtime, then Active-Active turns out to be genuinely fetched helpful just if numerous LBs (more than 3 to 4) are daisy binded as Active-Active shaping a LB Cluster Users Load Balancer Load Balancer AppServer Active-Active LB Users Load Balancer Load Balancer AppServer Creative Commons Sharealike Attributions Noncommercial

Slide 21

Step 4 – Horizontal Scaling (App Server) Load Balanced App Servers Our organization toward the end of Step 4 Positives Increases Availability and Scalability No progressions to App required Easy setup Negatives Finite Scalability DBServer Creative Commons Sharealike Attributions Noncommercial

Slide 22

Step 5 – Vertical Partitioning (Hardware) Load Balanced App Servers Introduction Partitioning out the Storage work utilizing a SAN config alternatives Refer to "Demystifying Storage" at http://wiki.directi.com - > Dev University - > Presentations Positives Allows "Scaling Up" the DB Server Boosts Performance of DB Server Negatives Increases Cost DBServer SAN Creative Commons Sharealike Attributions Noncommercial

Slide 23

Step 6 – Horizontal Scaling (DB) Load Balanced App Servers Introduction Increasing the quantity of DB hubs Referred to as "Scaling out" the DB Server Options Shared nothing Cluster Real Application Cluster (or Shared Storage Cluster) DBServer SAN Creative Commons Sharealike Attributions Noncommercial

Slide 24

Shared Nothing Cluster Each DB Server hub has its own total duplicate of the database Nothing is shared between the DB Server Nodes This is accomplished through DB Replication at DB/Driver/App level or through an intermediary Supported by most RDBMs locally or through 3 rd party programming DBServer Database Note: Actual DB documents perhaps put away on a focal SAN Creative Commons Sharealike Attributions Noncommercial

Slide 25

Replication Considerations Master-Slave Writes are sent to a solitary ace which reproduces the information to various slave hubs Replication perhaps fell Simple setup No peace making required Multi-Master Writes can be sent to any of the various experts which imitate them to different bosses and slaves Conflict Management required Deadlocks conceivable if same information is all the while altered at different spots Creative Commons Sharealike Attributions Noncommercial

Slide 26

Replication Considerations Asynchronous Guaranteed, yet out-of-band replication from Master to Slave Master overhauls its own particular db and returns a reaction

SPONSORS