Autoscale a Load-Balanced Web Application

To run your web applications in the cloud, you need reliable and secure infrastructure, a topology that's elastic and easy to maintain, and usage-based billing. An Oracle Cloud feature that fulfills all of these requirements is autoscaling.

Autoscaling ensures that your resources in the cloud are utilized efficiently and available when required. You can configure your cloud deployment to automatically adjust the compute resources based on performance metrics, such as CPU utilization. Your users experience consistent performance even when the load is high. And your costs are proportionately low during periods of low demand.

Architecture

This reference architecture shows a 3-tier topology consisting of a load balancer (LB), an autoscaling web tier, and a highly available database.

All the resources are deployed in a single availability domain in an Oracle Cloud Infrastructure region. The LB tier, web tier, and database tier are isolated in separate subnets within a single VCN. Network security groups (NSGs) serve as firewalls to regulate the network traffic to and from the resources in each tier. A route table attached to each subnet contains rules to direct traffic to destinations outside the VCN.

The following diagram illustrates the reference architecture.

Description of the illustration autoscaling.eps

autoscaling-oracle.zip

This architecture has the following components:

• Region

  An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  All the resources in this architecture are in a single region.

• Availability domains

  Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  The resources in this architecture are deployed in a single availability domain.

• Fault domains

  A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  The resources in each tier in this architecture are distributed across multiple fault domains.

• Virtual cloud network (VCN) and subnets

  A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  The load balancing and web tiers in this architecture use separate public subnets. The database is attached to a private subnet.

• Load balancer

  The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.

• Network security groups (NSGs)

  NSGs act as virtual firewalls for your cloud resources. With the zero-trust security model of Oracle Cloud Infrastructure, all traffic is denied, and you can control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of VNICs in a single VCN.

  Separate NSGs are used for the resources in each tier in this architecture.

• Route tables

  Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

• Internet gateway

  The internet gateway allows traffic between the public subnets in a VCN and the public internet.

• Instance configuration

  An instance configuration is a template that defines the settings to use when creating compute instances, including details such as the base image, shape, and metadata. You can also specify the associated resources for the instance, such as block volume attachments and the network configuration.

• Instance pool

  An instance pool is a group of instances within a region that are created from the same instance configuration and managed as a group.

• Autoscaling

  Autoscaling enables you to automatically adjust the number of compute instances in an instance pool based on performance metrics, such as CPU utilization.

  When the instance pool scales out or in, the associated load balancer's backend set is updated automatically.

• Autonomous Transaction Processing

  Oracle Autonomous Transaction Processing is a self-driving, self-securing, self-repairing database service that is optimized for transaction processing workloads. You do not need to configure or manage any hardware, or install any software. Oracle Cloud Infrastructure handles creating the database, as well as backing up, patching, upgrading, and tuning the database.

Recommendations

Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

• VCN

  When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

  Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

  After you create a VCN, you can change, add, and remove its CIDR blocks.

  When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

  Use regional subnets.

• Instance pool

  If there are no restrictions, include all the available availability domains in the pool.

• Instance configuration

  Choose instance shapes that offer the best performance-cost ratio and meet the minimum requirements of your workload.

• Autoscaling configuration

  Assess the resource requirements of your application, and use that information to define the scaling limits and the cool-down behavior while scaling in. This determines the maximum cost of the pool of instances.

Considerations

When deploying an autoscaling multitier application stack, consider the following factors:

• Database scalability

  You can manually scale the number of CPU cores of the database up or down at any time. The autoscaling feature of autonomous databases allows your database to use up to three times the current base number of CPU cores at any time. As demand increases, autoscaling automatically increases the number of cores in use. Autonomous databases allow you to scale the storage capacity at any time without affecting availability or performance.

• Database availability

  The architecture diagram shows a single Oracle Autonomous Transaction Processing database. While deploying the architecture, you can enable Oracle Autonomous Data Guard to provision and manage a standby database.

• Application availability

  Fault domains provide the resiliency within an availability domain. Where feasible, consider distributing your resources across multiple availability domains or multiple regions.

• Access control

  Use policies to restrict who can access your resources in the cloud and the actions that they can perform.

• Performance

  The size of the pool can scale in or out automatically, but it’s important to know the behavior of the application so that you can fine-tune the autoscaling policy. Resource limits can impact the ability of the pool to scale out.

Deploy

The code required to deploy this reference architecture is available in GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

• Deploy by using Oracle Cloud Infrastructure Resource Manager:
  1. Click

     If you aren't already signed in, enter the tenancy and user credentials.

  2. Review and accept the terms and conditions.
  3. Select the region where you want to deploy the stack.
  4. Follow the on-screen prompts and instructions to create the stack.
  5. After creating the stack, click Terraform Actions, and select Plan.
  6. Wait for the job to be completed, and review the plan.

     To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

  7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
• Deploy by using the Terraform CLI:
  1. Go to GitHub.
  2. Download or clone the code to your local computer.
  3. Follow the instructions in the README file.

Explore More

Learn more about deploying autoscaling applications in the cloud.

• Oracle Cloud Infrastructure documentation for autoscaling
• Best practices for designing reliable and resilient cloud topologies
• Deploy HA Applications Using Load Balancers Workshop
• Deploy an autonomous database with a private endpoint
• Stream IoT data to an autonomous database using serverless functions

Change Log

This log lists only the significant changes:

March 31, 2022	Added the option to download editable versions (.SVG and .DRAWIO) of the architecture diagram.
December 4, 2020	Updated the architecture. Updated the data tier to use an Oracle Autonomous Transaction Processing database instead of a DB system. Replaced security lists with network security groups (NSGs). Changed the web-tier subnet to a public subnet. Added the Deploy section.