×
Community Blog [Best Practice] Instance Pause Released by AnalyticDB for PostgreSQL to Help Optimize Costs

[Best Practice] Instance Pause Released by AnalyticDB for PostgreSQL to Help Optimize Costs

This article introduces the pause feature of AnalyticDB for PostgreSQL, as well as its implementation mechanism and best practice.

Background

Traditional warehouses often use the resource pre-purchase method, which lacks business-oriented resource adjustment flexibility. Instances cannot be used on demand in data analysis scenarios where there are obvious business peaks and troughs or time-sharing requests, resulting in a large amount of cost waste.

Cloud-native data warehouse AnalyticDB for PostgreSQL was released Serverless in February 2022. Since then, based on the powerful resource management capabilities of the kernel and the cloud-native-oriented control system, Serverless instance computing pause has been released, and it implemented the transformation of per-second billing and free computing resources during the pause. This capability helps customers save costs during the computing idle period. The effect is clear in the following scenarios:

  • Periodic Archiving of Data: Serverless instances can be started and paused by APIs. They can be paused immediately after the archiving is complete and can only be used for computing during occasional analysis and archiving, which can save nearly 80% of archiving costs.
  • Low-Cost POC Testing: Users no longer need to release instances frequently during the test. Using instance startup and pause can reduce the POC cost by more than 80%. If users perform intensive use within one cycle, they tend to pause to save the complexity of each initialization and improve the POC efficiency.

Product Documentation: https://www.alibabacloud.com/help/en/analyticdb-for-postgresql/latest/manual-start-stop

Features

Instance Pause

Users can pause or start an instance using the console or OpenAPI. During the instance pause, we will pause the computing resources of the user instance and no longer charge for computing. At the same time, this pause will not affect the data storage and network linking string of the instance. The instance can be used without any changes after startup.

Event Centers and Alerts

We provide complete notification, alerting, and auditing processes for users for pausing and starting events. Users can view manual start and pause, planned start and pause, and scale in and out operations in the Event Center of the console for event-side display. At the same time, users can configure CloudMonitor alerts based on these events to track the start and pause effects timely.

Per-Second Billing

When an instance is paused, only storage fees are charged, without charging computing resources. We have transformed the underlying billing service to ensure accurate usage statistics, which perceives events of instance start and pause in real-time, calculates the actual usage duration in the second level, and bills the instance by the hour.

Technical Architecture

Start and Pause Architecture

Users can trigger instance start and pause using the console or OpenAPI. The service controller manages the lifecycle of various resources and drives per-second metering and billing and event alerts by events.

1

Resource Lifecycle Management

Computing Resources

The instance runs on Kubernetes, involving graceful Pod pause and creation, scheduling, and Pod information reconstruction:

  • It does not rely on the GraceTerminating of Pod to kill instances but uses the sole kernel to gracefully kill sessions to protect user SQL requests.
  • It retains complete control metadata and rebuilds Pod by applying for temporary instances and exchanging OwnerReference.
  • If the resource pool capacity is insufficient and so the resource reapplication fails, the resource scale-out is guaranteed to be completed within five minutes through alert processing.

Network Resources

In native Kubernetes, the lifecycle of network resources is the same as that of Pod. Most communities use IPPool to implement IP hold in scenarios where stateful services are strongly dependent on IP. We adopt a similar one-to-one correspondence between ENI and Pod to separately manage ENI retention and reuse to ensure:

  • The kernel and procedure use the original IP to accelerate the recovery startup time
  • Hold IP resources to prevent failure to restore instances due to exhaustion

Resource Storage

It includes user data, cache data, and backup data. If user data is stored in a cloud disk or OSS, we will retain it for reuse. The cache can be released to reduce resource waste. For backup data, we change the policy of regular cleaning (typically seven days) to retain the last backup set. As such, when the instance is restarted, the backup data before the pause can be used to ensure data reliability.

Event Management

We can see that more controllers in the cloud-native ecosystem are implemented based on event-driven. We adopt a similar solution, using Alibaba SLS as the CloudEvent channel to achieve.

  • Per-Second Billing: It calculates the actual usage duration of each resource based on the start and pause events.
  • Event Notification: It provides an OpenAPI operation and displays in a visualized manner in the console, so it can be tracked and interpreted.
  • CloudMonitor Alerts: Users can configure alerts with CloudMonitor (such as SMS, phone calls, emails, and webhook).

Best Practices

After purchasing a Serverless instance, users can perform the following operations to pause and start the instance. The corresponding computing resource usage bill can be seen in the Billing section.

Note: Currently, Serverless only supports pause in the pay-as-you-go method. Pause does not work well in the subscription method due to the pre-purchase of resources.

Click the link to purchase a Serverless instance: Pay-As-You-Go Trial

The Instance of Manual Pause

Log on to the AnalyticDB for PostgreSQL console. On the Instance Lists page, find the instance to be paused and click Pause Instance in the More Operations column.

2

Alternatively, on the Instance Details page, run Instance Management → Pause Instance.

3

When the task is issued, the instance will switch to the pause state. After about two minutes, the instance turns to the paused state.

4

The Instance of Manual Start

On the Instance Details page, run Instance Management → Start Instance:

5

View Start and Pause Events and Configuration Alert

All the start and pause events in the Notification Event category can be viewed in the Event Center of the AnalyticDB for PostgreSQL console.

6

Users can jump to the CloudMonitor page through the "Configuration Alert" link. We help users automatically fill in the default parameters. They can configure alert information (such as phone calls, SMS messages, emails, and webhook).

7

OpenAPI

In addition to using the console, we provide OpenAPI to start and pause.

Pause an instance:

http(s)://gpdb.aliyuncs.com/?Action=PauseInstance
&DBInstanceId=gp-bp***************
&Common request parameters

Start an instance:

http(s)://gpdb.aliyuncs.com/?Action=ResumeInstance
&DBInstanceId=gp-bp***************
&Common request parameters

Java SDK:

<dependency>
<groupId>com.aliyun</groupId>
<artifactId>gpdb20160503</artifactId>
<version>1.0.25</version>
</dependency>

Summary

Reducing costs and increasing efficiency has always been the common goal between users and us. With the help of cloud technology and exclusive product kernels, we can provide cost-effective products, so instances can be used on-demand and pay-as-you-go. We also attach importance to the user experience and strive to do a better job in terms of convenience and functions. The time of pausing and starting an instance can be compressed into a few minutes, which realizes the on-demand pause and start without any burdens. The technical dividend on the cloud can help enterprises increase efficiency and reduce costs.

0 1 0
Share on

ApsaraDB

385 posts | 70 followers

You may also like

Comments