The Next Generation Application Server – How Event Based Processing yields scalability

  • 2,001 views
Uploaded on

GigaSapces on CANOE'09 …

GigaSapces on CANOE'09

More in: Technology , Sports
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,001
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
88
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Solution 1: Stored Procedures (not the best in every case. . .) Pros: Place logic and data together Faster processing Simpler management Cons: Inflexible With 99.999% how often can you modify your schema? Question: How do I live without my database?
  • Trainer will provide handouts with the architectural blueprints.
  • You don’t want to see this in the papers, do you?
  • Linda model 1992 David Gelernter and Nicholas Carriero Java, Sun Microsystems released in 1995 Sun introduced Jini in July of 1998
  • Use this slide to explain the space model. The space can be used to provide variety of middleware services under simple set of 4 API’s Explain how the four API’s can be used for: Caching Messaging (why there is no need for different implementation for both scenarios), Describe how content based routing is achieved Parallel processing – don’t put too much emphasize on that part at this stage – there is a separate slide on that

Transcript

  • 1. The Next Generation Application Server – How Event Based Processing yields scalability Guy Korland R&D Team Leader
  • 2. Agenda
    • Preview
    • The Problem
    • The Solution
    • Event Containers
    • Example
    • Benchmarks
    • Customer Use Cases
    • Summary Q&A
  • 3. About me…
    • Core Team Leader – GigaSpaces since 2005
    • MSc – Technion (Prof. Roy Friedman)
    • PhD candidate – Tel Aviv University (Prof. Nir Shavit)
    • Lead Deuce STM – ( www.deucestm.org )
    • Java Software Transactional Memory
  • 4. GigaSpaces XAP – Designed For: Performance Scalability Latency
  • 5. GigaSpaces Evolution Single space Load Balance Partition & Replication SLA container Event Container NG Application Server PaaS Cloud 2000 2003 2005 2006 2007 2008 2009
  • 6. Not going to talk about…
    • Jini (Java SOA)
    • Data Grid implementation.
    • Map-Reduce.
    • JDBC/JMS/JPA.
    • Cloud computing.
    • Batch processing.
    • Mule ESB.
    • WAN vs LAN
    • Different languages interoperability.
    • TupleSpace model extension.
    • JDK improvements (RMI, Reflection, Serialization, Classloading…)
  • 7. Agenda
    • Preview
    • The Problem
    • The Solution
    • Event Containers
    • Example
    • Benchmarks
    • Customer Use Cases
    • Summary Q&A
  • 8. Today’s Reality – Tier Based Architecture Separate technology implementation Bottlenecks in all areas where state is stored, architecture can’t scale linearly! Separate technology implementation Separate technology implementation bottlenecks bottlenecks
  • 9. Traditional Architecture - path to complexity… (marktplaats.nl) Auction Owner Auction Service Bid Service Trade Service Info Service Timer Service Auction Service Bid Service Trade Service Info Service Timer Service T Bidder Validate Result Process Bid Bid Accepted Bid Result Process Trade Get Bid Result Place bid
  • 10. Traditional Architecture - path to complexity… Business tier Back-up Back-up
    • Redundancy doubles network traffic
    • Bottlenecks are created
    • Latency is increased
    • Separate failover strategy and implementation for each tier
    Bidder Auction Owner Auction Service Bid Service Trade Service Info Service Timer Service
  • 11. Do you see the Problem? Business tier
    • Scalability is not linear
    • Scalability management nightmare
    Back-up Back-up Back-up Back-up Bidder Auction Owner
  • 12. There is a huge gap between peak and average loads
  • 13. Bottlenecks, Performance, Scalability and High availability headaches Bad Publicity Revenue Loss Customer Dissatisfaction Regulatory Penalties
  • 14.  
  • 15. TBA – Summary
    • • Historically the following has been done…
    • – Tune, tune and tune configuration and code
    • • Once a bottleneck has been resolved, the next one glooms
    • – Hardware over provision
    • • To make sure that at peak times the response times were still acceptable
    • – Hardware upgrades
    • • To get rid of bottlenecks, whose origin was impossible to track down
    • – Alternative patterns
    • • Avoiding 2-phase-commit, using patterns like ‘compensating transactions’
    • • Using Active/Passive failover, to make the response times faster, risking and
    • in fact accepting potential data-loss
    • • Partition the database, but not for size-reasons
  • 16. Agenda
    • Preview
    • The Problem
    • The Solution
    • Event Containers
    • Example
    • Benchmarks
    • Customer Use Cases
    • Summary Q&A
  • 17. Event Containers
  • 18. Based on JavaSpaces C++
  • 19. The Master Worker Pattern
  • 20. GigaSpaces - based on Shared Transactional Memory Read Write
      • Write – writes a data object
      • Read – reads a copy of a data object
      • Take – reads a data object and deletes it
      • Notify – generates an event on data updates
    Write Take Notify
      • Write + Read  Data Caching
      • Write + Notify  Messaging - Pub/Sub
      • Write + Take  Master Worker
  • 21. Event Containers
  • 22. Step 1 – Create a Processing Unit Business tier Processing Unit
    • Single model for design, deployment and management
    • No integration effort
    • Manage data in memory
    • Collapse the tiers
    • Collocate the services
    Auction Service Bid Service Trade Service Info Service Timer Service Bidder Auction Owner
  • 23. Step 2 – Async Persistency Processing Unit Validate Process Bid Process Trade Process Results Persist for Compliance & Reporting purposes:
          • - Storing State - Register Orders - etc.
    • Collocation of data, messaging and services in memory:
      • Minimum Latency (no network hops)
      • Maximum Throughput
    Auction Service Bid Service Trade Service Info Service Timer Service Bidder Auction Owner Place Bid Get Bid Results
  • 24. Step 3 – Resiliency Processing Unit
    • Single, built-in failover/redundancy investment strategy
    • Fewer points of failure
    • Automated SLA driven failover/redundancy mechanism
    • Continuous High Availability
    SLA Driven Container Backup
  • 25. Step 3 – Resiliency Processing Unit
    • Automated SLA driven failover/redundancy mechanism
    • Continuous Availability
    • Self Healing Capability
    SLA Driven Container Backup
    • Single, built-in failover/redundancy investment strategy
    • Fewer integration points mean fewer chances for failure
    Primary Backup
  • 26. Step 4 – Scale Processing Unit
    • Write Once Scale Anywhere:
      • Linear scalability
      • Single monitoring and management engine
      • Automated , SLA-Driven deployment and management
        • Scaling policy, System requirements, Space cluster topology
    Backup Backup
  • 27. Event Containers
  • 28. Step 5 – Auto Scale Out
  • 29. Processing Unit – Scalability Unit Single Processing Unit Processing Unit - Scaled Involves Config Change No code changes!
  • 30. Processing Unit – High-Availability Unit Sync Replication Primary - Processing Unit Business logic – Active mode Backup - Processing Unit Business logic – Standby mode
  • 31. Database Integration - Async persistency Sync Replication Primary - Processing Unit Business logic – Active mode Backup - Processing Unit Business logic – Standby mode Mirror Process ORM Initial Load Async Replication Async Replication
  • 32. XAP = Enterprise Grade Middleware
    • Scale-out application server
      • End 2 End scale-out middleware for: Web, Data, Messaging, Business logic
      • Space Based Architecture – designed for scaling stateful applications In-memory
    • Proven performance, Scalability, Low latency, Reliability
    • SLA Driven
    • Unique database scaling solution that fits cloud environment
      • In Memory Data Grid
      • O/R mapping support
    • Support major Enterprise languages
      • Java, .Net, C++
  • 33. Agenda
    • Preview
    • The Problem
    • The Solution
    • Event Containers
    • Example
    • Benchmarks
    • Customer Use Cases
    • Summary Q&A
  • 34. Built-in Event Containers
    • Polling Container
    • Notify Container
  • 35. Polling Container
    • Used for point-to-point messaging
    • Container polls the Space
    • for events
    • Comparable with the
    • way Ajax works
  • 36. Notify Container
    • Used for publish-subscribe messaging
    • Space notifies the container
  • 37. Typical Application
  • 38. Service Grid Summary
    • Powerful Universal Container
      • Java/Net/C++
      • Distributed
      • Fault Tolerant
      • Object based
      • Transactional
      • Publish/Subscribe
  • 39. Agenda
    • Preview
    • The Problem
    • The Solution
    • Event Containers
    • Example
    • Benchmarks
    • Customer Use Cases
    • Summary Q&A
  • 40. Event Containers
  • 41. The POJO Based Data Domain Model @SpaceClass(fifo=true) public class Data { … @SpaceId ( autoGenerate = true ) public String getId () { return id; } public String setId ( String id ) { this .id = id; } public void setProcessed ( boolean processed ) { this . processed = processed; } public boolean isProcessed ( boolean processed ) { return this . processed; } } SpaceClass indicate that this is a SpaceEntry – SpaceClass includes classlevel attributes such as FIFO,Persistent… SpaceId used to define the key for that entry.
  • 42. Data Processor Service Bean @SpaceDataEvent to be called when an event is triggered. public class DataProcessor{ @SpaceDataEvent public Data processData ( Data data ) { … data . setProcessed ( true ) ; //updates the space return data; } } Updates the data in the Space.
  • 43. Wiring Order Processor Service Bean through Spring <bean id=&quot; dataProcessor “ class=&quot;com.gigaspaces.pu.example1.processor.DataProcessor&quot; /> <os-events:polling-container id=&quot;dataProcessorPollingEventContainer&quot; giga-space=&quot;gigaSpace&quot;> <os-events:tx-support tx-manager=&quot;transactionManager&quot;/> <os-core:template> <bean class=&quot;org.openspaces.example.data.common.Data&quot;> <property name=&quot;processed&quot; value=&quot;false&quot;/> </bean> </os-core:template> <os-events:listener> <os-events:annotation-adapter> <os-events:delegate ref=&quot; dataProcessor &quot;/> </os-events:annotation-adapter> </os-events:listener> </os-events:polling-container> The event Template The event Listener
  • 44. Data Feeder public class DataFeeder { public void feed(){ Data data = new Data(counter++); data.setProcessed( false ); //feed data gigaSpace.write(data); } } Feed Data
  • 45. Remoting – Taking one step forward Event
  • 46. Remoting – Taking one step forward Reduce
  • 47. Remoting – IDataProcessor Service API public interface IDataProcessor { // Process a given Data object Data processData(Data data); }
  • 48. Remoting - DataProcessor Service @RemotingService public class DataProcessor implements IDataProcessor { public Data processData(Data data) { … data.setProcessed( true ); return data; } }
  • 49. Remoting - Order Feeder public class DataFeeder { private IDataProcessor dataProcessor; public void setDataProcessor(…) { this .dataProcessor = dataProcessor; } public Data feed(){ Data data = new Data(counter++); // remoting call return dataProcessor.process (data) } }
  • 50. Summary
  • 51. Agenda
    • Preview
    • The Problem
    • The Solution
    • Event Containers
    • Example
    • Benchmarks
    • Customer Use Cases
    • Summary Q&A
  • 52. Scale up Throughput Benchmark – Physical Deployment Topology
    • Remote (multiple machines , multiple processes)
    white box Client X4450 GigaSpaces 4 spaces , one per GSC X4450 GigaSpaces 4 spaces , one per GSC Switched Ethernet LAN Embedded (one machine , one process) X4450 Client GigaSpaces 8 spaces
  • 53. Scale up Throughput Benchmark – Embedded mode 1.8 Million read sec! 1.1 Million write/take sec!
  • 54. Scale up Throughput Benchmark – Remote mode 90,00 read sec! 45,00 write/take sec!
  • 55. Agenda
    • Preview
    • The Problem
    • The Solution
    • Event Containers
    • Example
    • Benchmarks
    • Customer Use Cases
    • Summary Q&A
  • 56. Event Containers
  • 57.
    • Web Container
    • Grid
  • 58. Web application – Pet Clinic
  • 59. Classic Architecture – Step 1- Request Submission Get request and invoke Service Data Grid
  • 60. Classic Architecture – Step 2- Retrieve Results Page Generation Data Grid
  • 61. Web Application Benchmark Results - Capacity
  • 62. Web Application Benchmark Results - Capacity
  • 63.
    • Game Server
  • 64. Query Notify Intercepts update events Game Servers Table Feeder
    • Loading Game Tables into the partitioned spaces
    • Randomly updates the game tables
    Publisher (lobby)
    • Game Table Directory
    • Game Table search
    • Player search
    Partitioned Space Pub/Sub messaging Scaling out GameTable Space Based Architecture – Game Server Publisher (II)
  • 65. Publisher Servers Game Servers GigaSpaces Service Grid
    • Uploading 30,000 players for 6000 tables
    • Randomly updates game tables
    Java runtime Physical backup
    • Running continues query per user
    Space Based Architecture – Game Server Partitioned Space GameTable Partitioned Space GameTable Partitioned Space GameTable Notify / Query Notify / Query Partitioned Space GameTable Partitioned Space GameTable Partitioned Space GameTable
  • 66. Dynamic repartitioning and load sharing I SLA Driven Container Indexed Notify / Query template Notify / Query template Partitioned Space Partitioned Space Partitioned Space
  • 67. Dynamic repartitioning and load sharing II SLA Driven Container SLA Driven Container Partitioned Space Partitioned Space Partitioned Space
  • 68. Scaling Throughput: ~6K/sec Throughput: ~12K/sec Throughput: ~18K/sec Partitioned Space Backup Space SLA Driven Container
    • 6000 tables
    • 30,000 players
    SLA Driven Container Partitioned Space Backup Space
    • 4000 tables
    • 20,000 players
    SLA Driven Container Partitioned Space Backup Space
    • 2000 tables
    • 10,000 players
  • 69. Agenda
    • Preview
    • The Problem
    • The Solution
    • Event Containers
    • Example
    • Benchmarks
    • Customer Use Cases
    • Summary Q&A
  • 70. Thank You! Q&A
  • 71. Appendix
  • 72. SLA Driven Deployment
    • SLA:
    • Failover policy
    • Scaling policy
    • Ststem requirements
    • Space cluster topology
    • PU Services beans definition
  • 73. Continuous High Availability Fail-Over Failure
  • 74. Dynamic Partitioning = Dynamic Capacity Growth VM 1 ,2G GSC VM 3 , 2G GSC VM 2 ,2G GSC Max Capacity=2G Max Capacity=4G Max Capacity=6G In some point VM 1 free memory is below 20 % - it about the time to increase the capacity – lets move Partitions 1 to another GSC and recover the data from the running backup! Later .. Partition 2 needs to move… After the move , data is recovered from the backup VM 5 , 4G GSC VM 4 ,4G GSC P - Primary B - Backup P P P B B B E F Partition 1 A B Partition 2 C D Partition 3 A B Partition 2 E F Partition 1 C D Partition 3
  • 75.
    • Executors
  • 76. Task Executors – Task Execution
    • Executing a task is done using the execute method
    AsyncFuture<Integer> future = gigaSpace .execute( new MyTask(2) ); int result = future.get(); 1 2 4 3
  • 77. Task Executors – Task Routing
    • Routing a task can be done in three ways
      • 1. Using the task itself
      • 2. Passing a POJO to the execute method
      • 3. Specifying a routing-parameter in the execute method
  • 78. Task Executors – DistributedTask Execution
    • Executing a distributed task is done using the execute method
    AsyncFuture<Integer> future = gigaSpace .execute( new MyDistTask() ); int result = future.get();
  • 79. Task Executors – DistributedTask Routing
    • Routing a distributed task can be done
      • 1. In the same ways as with the plain Task interface
      • 2. By broadcasting
      • 3. Specifying a number of routing-parameters in the execute method
  • 80. Service Executors
  • 81. Service Executors
  • 82.
    • IMDG
    • Operations
  • 83. IMDG Basic Operations
  • 84. IMDG Access – Space Operations – Write Operation
    • write -operation writes a new object to a space
      • Instantiate an object
      • Set fields as necessary
      • Write the object to the space
    Auction auction = new Auction(); auction.setType( &quot;Bicycle&quot; ); gigaSpace.write(auction);
  • 85. IMDG Access – Space Operations – Read Operation
    • read -operation reads an object from a space
    • A copy of the object is returned
    • The original copy remains in the space
      • Build a template/query (more on this later)
      • Read a matching object from the space
    Auction template = new Auction(); Auction returnedAuction = gigaSpace.read(template);
  • 86. Object SQL Query Support
    • Supported Options and Queries
      • Opeations: =, <>, <,>, >=, <=, [NOT] like, is [NOT] null, IN.
      • GROUP BY – performs DISTINCT on the POJO properties
      • Order By (ASC | DESC)
    • SQLQuery rquery = new SQLQuery(MyPojo.class,&quot;firstName rlike '(a|c).*' or ago > 0 and lastName rlike '(d|k).*'&quot;);
    • Object[] result = space.readMultiple(rquery);
    • Dynamic Query Support
      • SQLQuery query = new SQLQuery(MyClass.class,“firstName = ? or lastName = ? and ago>?&quot;);
      • query.setParameters(“david”,”lee”,50);
    • Supported Options via JDBC API
      • COUNT, MAX, MIN, SUM, AVG , DISTINCT , Blob and Clob , rownum , sysdate , Table aliases
      • Join with 2 tables
    • Non Supported
      • HAVING, VIEW, TRIGGERS, EXISTS, BETWEEN, NOT, CREATE USER, GRANT, REVOKE, SET PASSWORD, CONNECT USER, ON.
      • NOT NULL, IDENTITY, UNIQUE, PRIMARY KEY, Foreign Key/REFERENCES, NO ACTION, CASCADE, SET NULL, SET DEFAULT, CHECK.
      • Union, Minus, Union All.
      • STDEV, STDEVP, VAR, VARP, FIRST, LAST.
      • # LEFT , RIGHT [INNER] or [OUTER] JOIN
  • 87. IMDG Access – Space Operations – Take Operation
    • take -operation takes an object from a space
    • The matched object is removed from the space
      • Build a template/query (more on this later)
      • Take a matching object from the space
    Auction template = new Auction(); Auction removedAuction = gigaSpace.take(template);
  • 88. IMDG Access – Space Operations – Update Operation
    • update is equivalent to performing take and write
    • Executed in a single atomic call
    AuctionItem item = new AuctionItem(); item.setType( &quot;Bicycle&quot; ); gigaSpace.write(item); item = gigaSpace.read(item); item.setType( &quot;Motorbike&quot; ); Object returnedObject = space.update(item, null , Lease.Forever, 2000L, UpdateModifiers.UPDATE_OR_WRITE);
  • 89. IMDG Access – Space Operations – Batch API
    • Apart from the single methods GigaSpaces also provides batch methods
    • The methods are:
      • writeMultiple : writes multiple objects
      • readMultiple : reads multiple objects
      • updateMultiple : updates multiple objects
      • takeMultiple : reads multiple objects and deletes them
    • Notes:
      • Performance of the batch operations is generally higher
        • Requires one call to the space
      • Can be used with Template matching or SQLQuery
  • 90. IMDG Access – Space Operations – Batch API
    • writeMultiple writes the specified objects to the space.
    Auction[] auctions = new Auction[] { new Auction(10), new Auction(20) }; auctions = gigaSpace.writeMultiple(auctions, 100);
  • 91. IMDG Access – Space Operations – Batch API
    • readMultiple reads all the objects matching the specified template from the space.
    Auction auction = new Auction(); Auction[] auctions = gigaSpace.readMultiple(auction, 100);
  • 92. IMDG Access – Space Operations – Batch API
    • takeMultiple takes all the objects matching the specified template from the space.
    Auction auction = new Auction(); Auction[] auctions = gigaSpace.takeMultiple(auction, 100);
  • 93. IMDG Access – Space Operations – Batch API
    • updateMultiple updates a group of specified objects.
    Auction[] auctions = new Auction[] { new Auction(10), new Auction(20) }; auctions = gigaSpace.updateMultiple(auctions, 100);
  • 94. IMDG Summary
    • Powerful shared memory Service
      • Distributed
      • Fault Tolerant
      • Object based
      • Single and Batch Operations
      • Transactional