General:Scaling
From InClickAdServer
Contents |
Scalability of the inClick Ad Server
The inClick Ad Server is based on a distributed architecture. Because of this architecture, any single server (single node) deployment can be scaled out as needed. It is through this distributed architecture that allows specific functions of the inClick Ad Server to be separated to specific nodes.
What does it mean "to scale" an application?
Scalability is a property of a system, in this case the inClick Ad Server, that allows for the handling and processing of growing amounts of work in a graceful manner. For an advertising server, to scale means much more than just delivering more advertisements, but also includes how the system handles the data created as a result of the increased number of impressions in a cost effective manner.
Scale Up, Scale Out, What's the Difference?
There are two basic methods of adding more capacity to an application: To scale up and to scale out.
Scale Up (Scale Vertically)
To scale up means to add more resources to an existing system. Typically, this involves adding memory, increasing CPUs, and/or adding additional hardware resources to an existing piece of hardware.
While this method works to increase capacity of the ad server, it is not the recommended approach as scaling up has its limits. For example, once you reach a certain point, doubling memory or CPUs will not double performance.
Cost Concerns
When an application needs to scale up, cost will increase. When costs of scaling up are concerned, it is important to understand the relationship between the cost and the corresponding impact on performance. For example, if you were to double the hardware resources, how much gain is achieved from the ad server and at what cost? What you will quickly find is that the percentage of improvement diminishes as costs increase. [INSERT GRAPH OF QPS VS MACHINE COST]
Reliability Concerns
What happens if the server crashes? Since this method uses a single server, a single point of failure exists. While creating backups of a deployment will allow you to resume operations, the downtime created from a crash can lead to lost advertisers and publishers.
Growth is Limited
This method also will have a finite limit with regard to advertisement delivery, likely no more than 100 queries per second. A bigger machine will not continue to give you more growth.
Scale Out (Scale Horizontally)
To scale out means adding more nodes, actual servers, to a system in order to handle growth. Not every application is designed to scale horizontally as much of the underlying architecture must be able to support this. In the case of the inClick Ad Server's distributed architecture, the system would be split into separate components across a set of servers - an ad server cluster.
This approach to scaling affords the most flexibility, a far greater amount of capacity, the ability to reduce single points of failure, all at a lower total operational cost.
Cost Concerns
When an application needs to scale out, cost will also increase. However, unlike the vertical approach, cost increases are not as dramatic as you increase capacity. For example, if you were to move advertisement delivery to its own dedicated server (node), you would not need a high-end dedicated server yet almost double advertisement delivery capacity.
Reliability Concerns
When properly configured, a horizontally scaled deployment can eliminate many single points of failure. For example, if a delivery node crashes, the others will take on the extra traffic until the crashed server is restored.
Virtually Unlimited Growth
Unlike its vertical counterpart, adding capacity to a horizontally scaled deployment is virtually unlimited since you can add capacity where capacity is needed. Need to deliver 1000 queries per second, add inexpensive delivery servers behind a load balancer. Need to processes more impression and click data for reports, add an inexpensive impression processor node. The point is clear: with the inClick Ad Server's ability to scale horizontally, your growth is planned.
Scaling Your inClick Ad Server
Scaling your inClick Ad Server requires planning. With each deployment comes its own requirements and its own strategy. Because the inClick Ad Server is not a "one-size-fits-all" system, it is recommended that you consult with your inClick Ad Server Agent to assist with designing a plan that covers your requirements.
Database Configuration
The inClick Ad Server has been designed to utilize a number of function specific connection options. For example, the "off-the-shelf" default system configuration utilizes just one database connection that requires full access to the database. This default connection performs all tasks within the ad server.
<?php
...
// <ADSERVER_ROOT>/globals/globals_database.php
$database_config['default'] = array('host'=>'localhost', 'user'=>'dbuser_rw', 'password'=>'yourpasswrd', 'database'=>'adserver_database');
...
?>
In order to allow growth beyond the single database server configuration, connections can be separated based on their expected usage:
<?php
...
// <ADSERVER_ROOT>/globals/globals_database.php
$database_config['default'] = array('host'=>'localhost', 'user'=>'dbuser_rw', 'password'=>'yourpasswrd', 'database'=>'adserver_database');
$database_config['ad_delivery-read'] = array('host'=>'inclick-rodb1', 'user'=>'as_ro', 'password'=>'password_1', 'database'=>'adserver_database');
$database_config['reporting-read'] = array('host'=>'inclick-rodb2', 'user'=>'as_ro', 'password'=>'password_2', 'database'=>'adserver_database');
...
?>
In the above configuration, advertisement delivery uses its own database located on a separate host. Additionally, reporting uses its own read-only database on its own host. All other connections continue to use the default connection.
Common Examples
The examples shown below are not limited to the example show but represent typical use-case scenarios. Each deployment will require its own unique strategy and as such, may use any combination or extension of those plans show here.
Stage 1: Separating the Database
This example is a simple separation of the inClick Ad Server system from the database server. In the simplest form, this model uses just two web servers:
- Ad Server Files - this server would contain the ad server files. Additionally, all administration and background processes would occur from this server.
- Database Server - This server contains the entire ad server database.
Stage 2: Segmentation of Advertisement Delivery
Extending on the separation of the database from the core system, this step separates advertisement delivery from the core system. In the most basic form, this deployment would contain three servers:
- User Interface Server - This server will provide web based access to the ad server. Typically, this server will also run the background processes.
- Advertisement Delivery Server - This server is dedicated to responding to advertisement requests. Typically, additional Advertisement Delivery Servers can be added to increase capacity. When using multiple Advertisement Delivery Servers, a load balancer strongly recommended to distribute traffic over the advertisement delivery servers (Scaled 2B Below)
- Database Server - This server contains the entire ad server database.
Stage 3: Segmentation of the Database for Ad Delivery
If advertisement delivery begins to exhibit signs of delays or database contention, it is time to separate advertisement delivery requests from the main database server. Using MySQL replication, a separate image of the master data is used for advertisement requests. Typically, each database replica serves up to six delivery nodes. For example:
Stage 4: Segmentation of Statistics Processing
Impressions are processed offline, in a background process. As a deployment continues to grow, processing of statistics will need to be handled independently from the master server. A dedicated Statistics Processor is recommended for every four advertisement delivery nodes.
Distributed Cache
The inClick Ad Server leverages the use of a distributed caching model. In order to avoid a single point of failure as well as to take advantage of low cost servers, multiple cache servers can be used at one time. When using more than one cache server, the inClick Ad Server will use all cache servers as if they were just a single server. If one cache server crashes, the ad server will automatically use an available cache server with no intervention by the administrator.
Distributed Indexing / Spidering
When using inContext, the contextual engine of the inClick Ad Server, a spider will physically visit and index pages where ad code has been inserted. This process occurs in the background. In a single server deployment, the inContext Spider can index up to 150,000 pages a day. When the inContext Spider is no longer able to keep up, the inClick Ad Server allows you to add as many indexing nodes as needed. To determine if your deployment is no longer able to keep up with indexing, review the Server Status report and note the inContext Status columns Awaiting First Index and Oldest Awaiting Reindex. If the Awaiting First Index is more than 100,000 and the Oldest Awaiting Reindex is more than seven days old, it may be time to add at least one dedicated inContext Spider server. Depending on the server configuration and its connection speed to the internet, a single dedicated inContext Spider server can index +300,000 URLs per day.
Using on-demand services such as Cloud Servers, you can start a few cloud servers to "catch up" with the delay, then turn off those cloud servers when they are no longer needed.
Licensing Considerations
When running a horizontally scaled deployment of the inClick Ad Server, each node of a scaled deployment is considered as part of the total deployment. Licensing costs do not increase as you increase the size of your ad server cluster. One web server, or dozens of web servers, the license or its cost does not change.
Technically speaking, you can deploy the above plan to respond to over 600 queries per second on our inClick Lite license (that would be our free license)!
