CDP:Scale Up pattern

From AWS-CloudDesignPattern
(Difference between revisions)
Jump to: navigation, search
 
(4 intermediate revisions by one user not shown)
Line 1: Line 1:
{{List of CDP}} {{NoT}}  
+
[[Category:CDP: All Patterns]][[Category:CDP: Basic Patterns]]{{List of CDP}}{{NoT}}
 
Dynamic Server Spec Up/Down   
 
Dynamic Server Spec Up/Down   
  
Line 5: Line 5:
 
Typically it is difficult to estimate, during the system development phase, the server resources that will be required after deployment.  
 
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.  
+
If the server resources are insufficient after deployment, the server will not perform well, or will be unable to keep up with batch processes. On the other hand, excessive server resources require excessive investments and mayactually 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.  
+
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 ==
 
== 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.
+
The AWS Cloud lets you switch the virtual server specifications (CPU, memory size, and the like) as needed. You can adjust the specifications 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.  
+
While in the past you would have to replace the physical server and reinstall the operating system if resources prove inadequate after deployment, there is no such need to do so in the AWS Cloud. You can deploy a system by launching a virtual server, and adjust the server specifications while monitoring the resource usage.  
  
 
== Implementation ==  
 
== Implementation ==  
(Procedure)
+
(Procedure)  
 
* Launch an EC2 instance and build the system.
 
* 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.  
+
* Monitorthe resource utilization using vmstat or a resource monitor, CloudWatch, or the like, and if the specification is inadequate (or excessive), stop the EC2 instance, and then restart after adjusting the instance type using the Change Instance Type menu of the AWS Management Console.
  
 
== Configuration ==     
 
== Configuration ==     
Line 23: Line 23:
  
 
== Benefits ==  
 
== Benefits ==  
* Eliminates the need for precise estimation of server specifications at the time of system design/development.
+
* This 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.
+
* This 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.  
+
* This enables reduction in waste, in terms of expenses, because you can switch to a reduced specification if you discover that the resources are excessive.  
  
 
== Cautions ==   
 
== Cautions ==   
 
+
* When you need to adjust a server specification, you will need 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).
* 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, iyou are still limited by the upper limit for the instance type. As a result, if the resources are inadequate despite selecting the instance type with the maximum processing performance, you will have to consider the use of [[CDP: Scale-Out Pattern | Scale-out Pattern]], caching, substituting another service of AWS, for example.
* 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 [[CDP: Scale-Out Pattern | Scale-out Pattern]], caching, substituting another service of AWS, or the like.  
+
  
 
== Other ==   
 
== Other ==   
 +
* If you can predict the processing peak, then you can also adjust the server specification automatically to match. For example, if closing processes with high overhead are performed at the end of the month, then you can put together a schedule where the specification is adjusted upward at that time, and adjusted downward otherwise.
 +
* You can handle Frequent processing delays 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 where the access frequency cannot be read, and in database servers, for example, which are difficult to scale-out.
  
* 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.
+
See the [[CDP: Scale-Out Pattern | Scale-out Pattern]].
* 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.
+

Latest revision as of 07:49, 26 November 2012

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, the server will not perform well, or will be unable to keep up with batch processes. On the other hand, excessive server resources require excessive investments and mayactually 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 lets you switch the virtual server specifications (CPU, memory size, and the like) as needed. You can adjust the specifications even after launching of the virtual server.

While in the past you would have to replace the physical server and reinstall the operating system if resources prove inadequate after deployment, there is no such need to do so in the AWS Cloud. You can deploy a system by launching a virtual server, and adjust the server specifications while monitoring the resource usage.

Implementation

(Procedure)

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

Configuration

6wNg0ISJczU5Pz1m-67127.png

Benefits

  • This eliminates the need for precise estimation of server specifications at the time of system design/development.
  • This reduces opportunity costs due to system stoppages and the inability to provide services to customers caused by inadequate resources.
  • This enables reduction in waste, in terms of expenses, because you can switch to a reduced specification if you discover that the resources are excessive.

Cautions

  • When you need to adjust a server specification, you will need 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, iyou are still limited by the upper limit for the instance type. As a result, if the resources are inadequate despite selecting the instance type with the maximum processing performance, you will have to consider the use of Scale-out Pattern, caching, substituting another service of AWS, for example.

Other

  • If you can predict the processing peak, then you can also adjust the server specification automatically to match. For example, if closing processes with high overhead are performed at the end of the month, then you can put together a schedule where the specification is adjusted upward at that time, and adjusted downward otherwise.
  • You can handle Frequent processing delays 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 where the access frequency cannot be read, and in database servers, for example, which are difficult to scale-out.

See the Scale-out Pattern.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox