TuneWiki scale-out architecture
Posted 11 January 2008 @ 5:52 am by Nati Shalom
Geva Perry, and Jim Liddle wrote nice posts about the work that was done by our partner GridDynamics to scale-out TuneWiki using GigaSpaces. "GridDynamics is a GigaSpaces partner, headed by Victoria Livschitz, that has been doing tremendous work around our product. Check out their web site and the very cool projects they are working on in their blog, including the GigaPult project and the GigaSpaces Maven Archetype."
Here are some of the technical aspects of the work on TuneWiki.
It consisted of:
- 2 Dell 8-CPU blade servers,
- Windows 2003,
- PostGRE SQL,
- Delphi-based API, IIS
It was built using:
- 2 Dell 8-CPU blade servers,
- Ubuntu Linux,
- PostGRE SQL,
- Apache Tomcat,
- TuneWiki Servlet,
- GigaSpaces XAP 6.0 - Data Grid/SLA Driven Container
- Spring - through OpenSpaces/Spring framework
Tomcat replaced the IIS server and was used for
the front-end for user requests with a thin client user interface. The GigaSpaces Data Grid (read/write distributed cache) is used as the shared data store holding the lyrics information. The GigaSpaces data grid is front-ending a PostGRE database using a PaaS (Persist ence as a Service) approach. With this approach the lyrics information is loaded to memory during initialization. Updates are done in-memory and kept synchronized with the back-end database through an asynchronous reliable replication mechanism to ensure that all updates arrive successfully to the underlying database, even in the event that one of the memory instances crashes. This enabled a system throughput increase of 6-8 times compared to the baseline JBDC servlet, and a 20
times increase compared to the original version. The system can easily scale by adding additional instances to the GigaSpaces In-Memory Data Grid. System availability is ensured by the GigaSpaces fail-over mechanism.
Because the database was moved to a background server, the system can survive a database crash or downtime without effecting the users. During the downtime, users are served by the Data Grid. The Data Grid keeps logs of all the changes and "replays" them to the database when it comes back to life.
The SLA-driven container simplifies the deployment (it makes sure that the primaries and their backups do not run on the same machine. If a primary fails, the backup will become a primary and the system provisions a new backup. Concurrent client scalability is achieved by
making the servlet stateless and load-balancing the http access. From a capacity perspective so far it has gone as high as a
quarter billion streams per day!
Summary:
The TuneWiki case study is interesting, not just because of the scalability it demonstrates, but because it shows how simple it is to scale. The fact that a complete re-write of the application was done in a very short period of time (a few days) is the best proof that with the right tools a Java-based web framework can be as productive or even more productive than the alternatives. It also shows that once scaling becomes simple, it can be easily applied at early stages of the application deployment, avoiding the need for continuous re-design. The use of the SLA-driven container demonstrates how concepts from the grid world can be successfully applied to next-generation web applications, and provides self-healing and automation capabilities.
If any of you have a cool application or idea like this one, it's not too late to submit them to our Killer Application contest and win the $10k grand prize!
