Canary release allows applications of old and new versions to be deployed in the same environment at the same time. In this case, some users can use the new version and others can continue to use the old version. Then, the proportion of new version users will be adjusted based on user feedback.

Scenarios

You want to frequently update your services and ensure high service quality at the same time. To ensure that you can control the impact if the new version is not working as expected, you must design a canary release system. In canary release, some users can use the new version and others can continue to use the old version. Then, you can evaluate the new version based on user feedback and metrics such as logs, performance, and stability. Based on your evaluation, you can determine whether to roll out the new version to more users until the old version is phased out. Alternatively, you can roll back the new version to the old version if the new one is not working as expected.

Prerequisites

  1. Deploy the services of the new version and old version on different servers. To ensure service availability, we recommend that you deploy the services on multiple servers.
  2. Create an Application Load Balancer (ALB) instance. Basic ALB instances do not support cookie-based rules. Therefore, you must create standard ALB instances. For more information, see Create an ALB instance.
  3. Create server groups. Then, add the backend servers where the old and new version are deployed to different server groups. For more information, see Manage server groups.
  4. Create a listener. Then, add the backend servers where the old version is deployed to the default server group of the listener. For more information, see Add an HTTP listener, Add an HTTPS listener, and Add a QUIC listener.

    After you complete the preceding tasks, all requests are forwarded to the old version. This topic provides the following ways to implement canary release. You can choose one or combine them based on your business requirements. In these examples, the new version service is deployed in Server Group A and the old version service is deployed in Server Group B.

Canary release based on HTTP headers

In this example, HTTP requests that contain the User-Agent header *Mozilla/4.0* are forwarded to the new version.

header
  1. Log on to the ALB console.
  2. In the top navigation bar, select the region where the ALB instance is deployed.
  3. On the Instances page, click the ID of the ALB instance that you want to manage.
  4. On the Listener tab, find the listener that you want to manage and click View/Modify Forwarding Rule in the Actions column.
  5. On the Forwarding Rules tab, click Add New Rule.
  6. Set the parameters and click OK.
    • Forwarding Condition: Select HTTP Header from the drop-down list, set the key to user-agent, and then set the value to *Mozilla/4.0*.
    • Forwarding Action: Select Forward from the drop-down list and select Server Group A.
    For more information about the parameters, see Create forwarding rules.
    Note You can configure more forwarding rules to increase the percentage of user traffic distributed to the new version. If the new version works as expected, you can discontinue the old version and forward all requests to the new version.

Canary release based on cookies

This example shows how to configure ALB to forward requests to the new version based on cookies that are specified in key-value pairs.

cookie
  1. Log on to the ALB console.
  2. In the top navigation bar, select the region where the ALB instance is deployed.
  3. On the Instances page, click the ID of the ALB instance that you want to manage.
  4. On the Listener tab, find the listener that you want to manage and click View/Modify Forwarding Rule in the Actions column.
  5. On the Forwarding Rules tab, click Add New Rule.
  6. Set the parameters and click OK.
    • Forwarding Condition: Select Cookie from the drop-down list and set the value to key:value.
    • Forwarding Action: Select Forward from the drop-down list and select Server Group A. If Domain Name is set to example1.com, select RS1 for Forward.
    For more information about the parameters, see Create forwarding rules.
    Note You can configure more forwarding rules to increase the percentage of user traffic distributed to the new version. If the new version works as expected, you can discontinue the old version and forward all requests to the new version.

Canary release based on server groups

In this example, 80% of the requests destined for example.com are forwarded to the old version and 20% of the requests are forwarded to the new version.

Diagram
  1. Log on to the ALB console.
  2. In the top navigation bar, select the region where the ALB instance is deployed.
  3. On the Instances page, click the ID of the ALB instance that you want to manage.
  4. On the Listener tab, find the listener that you want to manage and click View/Modify Forwarding Rule in the Actions column.
  5. On the Forwarding Rules tab, click Add New Rule.
  6. Set the parameters and click OK.
    • Forwarding condition: Select Domain Name from the drop-down list and set the domain name to example.com.
    • Forwarding Action: Select Forward from the drop-down list, and select Server Group B (set the weight to 80) and Server Group A (set the weight to 20).
    For more information about the parameters, see Create forwarding rules.
    Note You can change the weights of the server groups to meet your business requirements. If the new version works as expected, you can discontinue the old version and forward all requests to the new version.