CDP:Scale Up pattern

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
{{CDP List}} {{NoT}}  Dynamic Server Spec Up/Down   
+
{{CDP List}} {{NoT}}   
 +
Dynamic Server Spec Up/Down   
  
 
== Problem to Be Solved ==  
 
== Problem to Be Solved ==  

Revision as of 20:02, 14 November 2012

Template:CDP List
Architect

Dynamic Server Spec Up/Down

Contents

Problem to Be Solved

Typically it is difficult to estimate, during the system development phase, the server resources that will be required after deployment.

If the server resources are insufficient after deployment, then the server will provide insufficient functionality, or will be unable to keep up with batch processes. Conversely, excessive server resources result in unnecessary investments and actually produce losses.

While it would be nice to be able to adjust server resources after system deployment, this is difficult because the server resources depend on the specification of the physical machine.

Explanation of the Cloud Solution/Pattern

The AWS Cloud makes it possible to switch the virtual server specifications (CPU, memory size, and the like) as needed. The specification can be adjusted even after launching of the virtual server.

While in the past it has been necessary to replace the physical server and reinstall the operating system if resources become inadequate after deployment, there is no such need to do so in the AWS Cloud. A system may be deployed by launching a virtual server, and the server specifications can be adjusted while monitoring the resource usage.

Implementation

(Procedure)

  • Launch an EC2 instance and build the system.
  • The resource utilization is monitored using vmstat or a resource monitor, CloudWatch, or the like, and if the specification is inadequate (or excessive), the EC2 instance is stopped, and then restarted after adjusting the instance type using the Change Instance Type menu of the AWS Management Console.

Configuration

6wNg0ISJczU5Pz1m-67127.png

Benefits

  • Eliminates the need for precise estimation of server specifications at the time of system design/development.
  • Reduces opportunity costs due to system stoppages and the inability to provide services to customers caused by inadequate resources.
  • Enables reduction in waste, in terms of expenses, due to the ability to switch to a reduced specification if it is determined that the resources are excessive.

Cautions

  • When there is an adjustment to a server specification, it is necessary to stop the EC2 instance temporarily. The system will go off-line at this time for a period of time from about 30 seconds up to several minutes (depending on the disk space and the setup of the server).
  • Despite being able to adjust the server specifications, it is not possible to exceed the upper limit for the instance type. Consequently, if the resources are inadequate despite selecting the instance type with the maximum processing performance, it is necessary to consider the use of Scale-out Pattern, caching, substituting another service of AWS, or the like.

Other

  • If it is possible to predict the processing peak, then it is also possible to adjust the server specification automatically to match. For example, if closing processes with high overhead are performed at the end of the month, then it becomes possible to put together a schedule wherein the specification is adjusted upward at that time, and adjusted downward otherwise.
  • Frequent processing delays can be handled through temporarily modifying the server specification, and then returning the server specification to the original after making improvements to performance of the application or database. This is used particularly often in areas such as consumer-oriented servers wherein the access frequency cannot be read, database servers, and the like, which are difficult to scale-out.

See the Scale-out Pattern.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox