Achieve bottleneck-free grid applications

Grid computing is a natural evolution of distributed computing. For compute-heavy applications such as scientific calculations, grid computing has delivered strong cost savings. Yet for more data-intensive enterprise applications, data bottlenecks between grid applications and databases can easily wipe the grid’s cost advantages.

Achieving the cost-effective scalability promised by the compute grid (shown in Figure 1) can be achieved only when grid application performance is not throttled by data bottlenecks. The data grid is a way to “grid-enable” any data-intensive application, using distributed caching to eliminate bottlenecks between databases and grid applications.

This article discusses how to overcome the data management bottlenecks associated with grid computing and describes the three critical data services that make up the data grid:

• Caching: Staging frequently-used data in-memory near the application for optimal performance and scalability
• Replication: Ensuring each cache has up-to-date data even for dynamically-changing information
• Mapping: Transforming relational data into the appropriate object format to be used by Java, C++, or C# applications

Finally, this article presents a case study for a mission-critical, data grid deployment in the financial services industry. The case study describes how one bank is using grid data services to provision data to more than 40 distributed grid applications for front and middle office equity trading. These applications process over billion a day in trades, with peak transaction rates of more than 5,000 transactions per second.

Grid computing: Virtualizing IT infrastructure

In many industries such as financial services, brutal pricing pressures are forcing firms to turn increasingly to IT for a competitive advantage. Firms can maintain profits by only lowering IT costs and differentiating their services, which requires a robust, cost-effective, and extensible infrastructure.

The traditional approach to custom application development is to provide every application with its own dedicated database, hardware environment, and tightly coupled application modules. Today, these application silos are seen as inflexible and expensive. Key issues driving companies away from standalone silos include:

1. Dedicated silo hardware is expensive: Many silo applications run on dedicated application server and database computers. This equipment is typically provisioned to handle the worst case load, and is usually highly underutilized.
2. Synchronizing silo data is complex and error-prone: Most silo applications have their own operational datastores, thereby creating a complex data synchronization infrastructure, particularly for shared data about products, partners, and customers.
3. Integrating silo applications is difficult: Getting silo applications to talk to one another is an ongoing challenge, particularly when the underlying reference data between two silos is out of sync.

Data: The Achilles heel for grids

The basic constraint addressed by grid computing is the ability to scale an application across multiple computers. Where multithreading allows an application to scale across multiple CPUs, grid computing allows an application to scale across multiple host computers. However, this increased compute power is only as good as the data infrastructure that supports it.

A number of simplifying assumptions hold true in the world of application silos that do not hold true in a computing grid. In an application silo, the application can rely on the presence of a dedicated database that provides optimal data access. In a grid environment, these assumptions do not apply:

1. Data integration: It is not practical to have a dedicated database for each grid computer. Unless each grid application has a consistent view of critical reference data, achieving reliable results is impossible. Instead, grid applications should be written against a common “virtual data layer” that provides a consistent view of reference data across all applications running in the grid.
2. Data performance: Delays due to heavy data traffic can wipe out a grid’s computational benefits. For this reason, careful thought must be given to minimizing the delays caused by data movement within the grid. For example, if several grid applications repeatedly access shared products, pricing, or security data, it may make sense to copy this data to each grid computer and maintain it there.
3. Data scalability: One nightmare grid scenario is bottlenecked applications within the grid, waiting for response from a single database. Where each application silo typically has dedicated datastores, an efficient grid architecture has fewer databases shared by many applications, making the ability to scale the data infrastructure a gating factor in the overall ability to scale the grid.
4. Data availability: In a grid, the boundaries among applications blur and the ability to recover from a failure becomes more difficult—it is not just a matter of bringing an application silo down and then bringing it back up. Particularly in a service-oriented architecture, the applications running in the grid are interdependent, creating more points of failure and more disruption from the failure of any one component. Thus, high availability data is more important in a grid environment.

Three data services make up the data grid

The introduction of grid computing can create data bottlenecks. The purpose of a data grid is to eliminate the data bottlenecks that otherwise threaten to bog down grid computing performance. Three critical services make up the data grid:

1. Data integration services
2. Data caching services
3. Data replication services

Data integration services

To solve the grid computing problem generated by fragmented and out-of-date data silos, companies must build a logical data services layer that hides the physical data’s complexities. This data services layer has no storage of its own. Instead, a model-driven tool provides a consistent view of data across the enterprise, usually through an object-relational mapping between Java, C++, or C# objects and relational data sources.

Alternatively, an enterprise information integration tool can be used to map many relational data stores into a single virtual database. There is even a proposed standard for data access and integration from the Open Grid Services Architecture group.

Data caching services

To ensure that compute grids can process efficiently, data must be staged strategically within the compute infrastructure. If grid computers are geographically distributed, this requires a caching solution that can replicate cached data across locations. Any data that is going to be used more than once is a candidate for distributed caching.

For example, in the financial services world, most applications require access to reference data about securities and counter-parties. Staging this data by preloading it into an in-memory cache is an effective performance enhancement.

Data replication services

To provide data scalability to match a grid’s compute scalability, critical reference data associated with an application must be replicated to caches on every computer where that application runs. A dedicated synchronization mechanism tied to in-memory caching can be an elegant and powerful way to eliminate data and network latencies.

Data replication services can also significantly increase an IT infrastructure’s overall resilience. That is accomplished by replicating transactions at the grid data services level across inexpensive and geographically dispersed computers to back one another up. This ensures uninterrupted processing within the grid, even if a datastore becomes unavailable.

Finally, data replication services provide a cost-effective mechanism for distributing applications across wide geographies. The ability to have centralized data storage with distributed application execution also addresses the increasing performance challenges in achieving acceptable performance for globally distributed Web applications.

Banking case study: Grid data services

A top-tier global bank has deployed more than 40 equity trading systems using a grid data services architecture. These applications process more than billion per day in trading volume, with maximum transaction rates of more than 5,000 transactions per second.

The applications are built using a service-oriented architecture in which an intelligent data layer is used to model a shared set of data objects such as counter-parties, securities, and order books, which are common to all the applications. The deployment approach uses a grid architecture, in which the number of servers running a given application can change dynamically to accommodate changes in load.

In an intelligent data layer, caching is used to position the appropriate reference data in-memory on each grid server, thus ensuring outstanding performance, even as transaction volumes grow. This solution provides three important business benefits:

• Productivity through data mapping services: The time to develop new trading systems is cut by 50 percent using model-driven O/R mapping in the intelligent data layer
• Performance through data-caching services: Caching critical reference data in-memory within the intelligent data layer allows performance of 5,000 transactions per second
• Scalability through data replication services: The ability to replicate data caches flexibly increases processing capacity by more than 100 percent, greatly lowering cost per trade
• Resilience through intelligent fault management: Logic within the data services layer can transparently recover from intermittent database and network failures, significantly increasing application availability

The figure below shows the architecture for this application. Each software service—such as the order service—can be run on its own server, and multiple servers can be dynamically allocated to a service to handle peak load requirements.

Summary

Grid computing delivers flexibility by enabling applications to run on many small, inexpensive computers rather than a few big, expensive computers. Yet slow data access can throttle performance of data-intensive applications running on grid computers. Therefore it is critical that a grid architecture include a well-designed data grid to eliminate data bottlenecks between databases and grid applications.

To take advantage of the compute scalability offered by grid computing, custom enterprise applications must be built using a data grid. The data grid is a way to grid-enable any data-intensive application, using distributed caching to eliminate bottlenecks between databases and grid applications.

Not surprisingly, this is a hot market opportunity. In a 2003 report on grid computing, the Tabb Group said, “The vast amount of new grid growth will not come from compute-intensive solutions, but from data and service grids, whose applications we believe to be much wider than traditional compute grids.” The Tabb Group expects the market for grid services to grow from 0 million in 2003 to 80 million in 2007.