Performing billing in a HPC / cluster environment

Summary

Much of billing is an 'embarrassingly parallel' processing problem which could be distributed across a High Performance Computing (HPC) cluster. The division of billing's workload across a concurrent, multi-server architecture could be applied in functional areas such as transaction rating, bill generation, and credit management.

The move to cluster processing will have greater applicability as the focus for CPUs performance moves from single to multi-core architectures. A billing application that cannot segment and distribute its workload will incur higher infrastructure costs to sustain it.

Billing: a problem suitable for High Performance Computing (HPC)

High performance computing (HPC) tackles problems that come in a spectrum between two extremes: at one extreme, problems are classed as 'embarrassingly parallel' when a problem can be segmented into multiple pieces with little or no data communication required between concurrently running tasks; at the other extreme, a task is tackled as a whole with the processing for different parts of the larger problem exchanging interim data values with their peer tasks (e.g. adjacent geographical points in weather modeling).

Billing presents an example of the first extreme where much of the processing is customer, billing account or network service specific. The processing for one customer does not impact the processing for another and so can be performed in parallel.

Examples of billing processes that can be divided and processed in parallel include:

Transaction Rating: Divided (for example) by transaction source or product family
Bill Generation: Pricing, discounting, taxation, bill formatting, financial postings
Credit Management: Tracking delinquent accounts, generating reminder notices, evaluating next actions for debt recovery
Fraud assessment: Evaluating how new transactions adjust the 'fraud risk' for a specific network service, billing account or customer.
End-of-month: calculation of EOM financial postings across unbilled usage and non-network charges
Revenue assurance: concurrent processing to validate the end-to-end billing process

In each of these areas, high data volumes can be segmented and processed in parallel with little or no exchange of interim results.

Why split a billing function for parallel processing

Billing application processing is becoming more complex as additional network products are developed and additional functions are deployed (e.g. self-service portals, on-demand billing, complex network interconnect). Additional computing infrastructure is required to respond to this increase in processing scope, and HPC / cluster processing is one approach that could provide the necessary computing power to address these needs.

Additional reasons for moving to a HPC architecture include:

Packaged billing solutions (negative): The movement from bespoke systems to 'packaged' solutions means that a billing application has less opportunity for local tuning or customisation to meet a specific biller's needs. A standard (worldwide) release is provided by the software vendor that all clients are expected to deploy. Each biller will see in the standard package functionality that they will never employ, but must be include due to the 'packaged' approach. Changes to the package to address local processing must either be included in the 'standard release' or deployed as a local 'one-off' customisation.

Whilst the packaged software approach allows billers to share the costs of development, they are also limited to the development scope and development timetable of their software vendor. Bespoke systems can deploy just the functionality needed, and can be tuned to suit the products and customer base of a specific biller.

However, since packaged billing solutions are usually deployed on reserved infrastructure to a vendor recommended configuration, any movement to a cluster architecture will only occur when vendors can no longer address their peak performance needs (or client's limited budgets) using 'Enterprise' class server solutions.

Multi-core CPU (positive): The growth in peak CPU performance is slowing, and instead performance improvements are being generated by the move to multi-core chips. This change means that business applications cannot rely on Moore's Law to address their increasing processing needs, but must look to how processing can be parallelised to take advantage of the additional CPU cores.

Server commoditisation (positive): The choices in server infrastructure are reducing as the number of CPU architectures decreases and the operating system choices are reduced. This commoditisation is reducing the cost of infrastructure hardware allowing less complex (but powerful) servers to be linked together to build high performance computing clusters at lower 'per CPU' price points than 'Enterprise' class server hardware.

The same trade-off calculations used when deploying clusters at university departments and resource companies can be applied to deliver a computing infrastructure that can be extended with lower cost hardware, and take advantage of multi-core chips as they are deployed.

Differing peak workloads (positive): The billing functions listed above operate against different peak-load profiles. By sharing a computing infrastructure, a biller could reduce their total infrastructure requirements by operating a common platform upon which their computing was performed. Business applications would process at different times sharing the computing infrastructure. If required, less critical business applications could have their processing deferred to allow mission-critical processing to complete.

Point of competitive differentiation (positive): The Google cluster infrastructure provides a low cost computing platform for Google's core business applications, allowing (search) business applications to quickly perform core business processing. Google's developers can also use the Google cluster architecture to test and evaluate different 'what if' scenarios using their shared infrastructure.

Resource and mining businesses use cluster processing to evaluate where minerals are located, and quantify the size of the deposits. In bio-informatics, cluster computing provides a competitive advantage in drug design and three dimensional visualisation.

Developing an operational competency in cluster systems

HPC/cluster systems are deployed widely in environments such as universities (used to model complex calculations in areas such as physics, weather modeling, and mathematics), and businesses (mineral discovery and mining, engineering in areas such as car crash or wind-tunnel emulations, and financial services for portfolio assessments , risk modeling and market analysis). Clusters of commodity servers are a popular alternative in these circumstances to the 'enterprise-class servers' from major vendors whose 'price per CPU' and 'price per GHz' increase as the number of CPU/cores co-located on a single server increases.

Examples of sites that focus on the deployment and operation of clusters include:

TOP500: A bi-annual list of the fastest clusters in operation. Whilst these clusters are operated for 'high performance' applications, it provides a range of examples of situations where clusters can be employed. Most business applications would operate on smaller clusters.
ClusterMonkey: A website focusing on cluster operations including entry-level articles that explain how to build and operate simple clusters.
Beowulf mailing list: An active mailing list where operational and design issues pertinent to clusters are discussed, and where assistance can be sought for problems encountered.
VPAC (Victorian Partnership for Advanced Computing): which to quote their website '...is a leading, independent advanced computing R&D service provider. VPAC is a not-for-profit registered Research Agency ... by a consortium of Victorian [Australia] Member Universities.'

Tags: Billing, HPC, Cluster, Multi-core