# Aurora PostgreSQL Limitless Database 모니터링
Amazon CloudWatch, 향상된 모니터링 및 성능 개선 도우미를 사용하여 Aurora PostgreSQL Limitless Database를 모니터링할 수 있습니다. 또한 모니터링 및 진단에 사용할 수 있는 Aurora PostgreSQL Limitless Database에 대한 새로운 통계 함수 및 뷰와 대기 이벤트도 있습니다.
**Topics**
+ [Amazon CloudWatch를 사용하여 Aurora PostgreSQL Limitless Database 모니터링](limitless-monitoring.cw.md)
+ [CloudWatch Database Insights를 사용하여 Aurora PostgreSQL Limitless Database 모니터링](limitless-monitoring.cwdbi.md)
+ [Amazon CloudWatch Logs를 사용하여 Aurora PostgreSQL Limitless Database 모니터링](limitless-monitoring.cwl.md)
+ [향상된 모니터링을 사용한 Aurora PostgreSQL Limitless Database 모니터링](limitless-monitoring.em.md)
+ [성능 개선 도우미를 사용한 Aurora PostgreSQL Limitless Database 모니터링](limitless-monitoring.pi.md)
+ [Amazon GuardDuty RDS Protection을 사용하여 Aurora PostgreSQL Limitless Database 모니터링](limitless-monitoring.gd.md)
+ [Aurora PostgreSQL Limitless Database의 함수 및 뷰](limitless-monitoring-fns-views.md)
+ [Aurora PostgreSQL Limitless Database의 대기 이벤트](limitless-monitoring-waits.md)
+ [함수를 사용하여 효율성을 위한 구축](limitless-performance-functions.md)
# Amazon CloudWatch를 사용하여 Aurora PostgreSQL Limitless Database 모니터링
Aurora PostgreSQL Limitless Database에 대한 CloudWatch 지표는 다음 차원으로 보고됩니다.
+ [DBShardGroup](#limitless-monitoring.cw.DBShardGroup)
+ [DBShardGroupRouterAggregation](#limitless-monitoring.cw.DBShardGroupRouterAggregate)
+ [DBShardGroupInstance](#limitless-monitoring.cw.DBShardGroupInstance)
+ [DBClusterIdentifier](#limitless-monitoring.cw.DBClusterIdentifier)
CloudWatch 지표에 대한 자세한 내용은 [Amazon CloudWatch로 Amazon Aurora 지표 모니터링](monitoring-cloudwatch.md) 섹션을 참조하세요.
## DBShardGroup 지표
CloudWatch 콘솔에서 Aurora PostgreSQL Limitless Database에 대한 `DBShardGroup` 지표를 보려면 **RDS**를 선택한 다음 **DBShardGroup**을 선택합니다.
다음 CloudWatch 지표를 추적할 수 있습니다.
+ `DBShardGroupACUUtilization` - Aurora 용량 단위(ACU) 사용량이 `DBShardGroupCapacity`를 `DBShardGroupMaxACU`로 나누어 계산한 백분율로 표시됩니다.
+ `DBShardGroupCapacity` - DB 샤드 그룹의 라이터 인스턴스에서 사용하는 ACU의 개수입니다.
+ `DBShardGroupComputeRedundancyCapacity` - DB 샤드 그룹의 대기 인스턴스에서 사용하는 ACU의 개수입니다.
+ `DBShardGroupMaxACU` – DB 샤드 그룹에 대해 구성된 ACU의 최대 개수입니다.
+ `DBShardGroupMinACU` - DB 샤드 그룹에 필요한 ACU의 최소 개수입니다.
`DBShardGroupIdentifier` 차원 키는 `DBShardGroup` 지표를 집계하는 데 사용할 수 있습니다.
## DBShardGroupRouterAggregation 지표
CloudWatch 콘솔에서 Aurora PostgreSQL Limitless Database에 대한 `DBShardGroupRouterAggregation` 지표를 보려면 **RDS**를 선택한 다음 **DBShardGroupRouterAggregation**을 선택합니다.
다음 CloudWatch 지표를 추적할 수 있습니다.
+ `CommitThroughput` - DB 샤드 그룹에 있는 모든 라우터 노드의 초당 평균 커밋 작업 수입니다.
+ `DatabaseConnections` - DB 샤드 그룹의 모든 라우터 노드에 대한 모든 연결의 합계입니다.
## DBShardGroupInstance 지표
DBShardGroupInstance는 각 샤드 또는 라우터 하위 클러스터 내의 개별 DB 인스턴스입니다.
CloudWatch 콘솔에서 Aurora PostgreSQL Limitless Database에 대한 `DBShardGroupInstance` 지표를 보려면 **RDS**를 선택한 다음 **DBShardGroupInstance**를 선택합니다.
다음 CloudWatch 지표를 추적할 수 있습니다.
+ `ACUUtilization` - `ServerlessDatabaseCapacity` 지표를 하위 클러스터의 할당된 최대 ACU 값으로 나누어 계산된 백분율입니다.
+ `AuroraReplicaLag` - 컴퓨팅 중복이 활성화된 Limitless 클러스터의 경우 이는 하위 클러스터의 기본 인스턴스에서 업데이트를 복제할 때의 지연 시간입니다.
+ `AuroraReplicaLagMaximum` - 컴퓨팅 중복이 활성화된 Limitless 클러스터의 경우 이는 하위 클러스터의 기본 인스턴스에서 업데이트를 복제할 때의 최대 지연 시간입니다. 읽기 복제본이 삭제되거나 이름이 변경되면 이전 리소스가 재활용되면서 복제 지연 시간이 일시적으로 급증할 수 있습니다. 이 지표를 사용하여 리더 중 하나의 높은 복제 지연 시간으로 인해 장애 조치가 발생했는지 확인합니다.
+ `AuroraReplicaLagMinimum` - 컴퓨팅 중복이 활성화된 무제한 클러스터의 경우 이는 하위 클러스터의 기본 인스턴스에서 업데이트를 복제할 때의 최소 지연 시간입니다.
+ `BufferCacheHitRatio` - 인스턴스의 메모리 캐시(스토리지 볼륨이 아님)에서 제공된 데이터 및 인덱스의 백분율입니다.
+ `CommitLatency` - 엔진 및 스토리지가 특정 노드(라우터 또는 샤드)에 대한 커밋 작업을 완료하는 평균 기간입니다.
+ `CommitThroughput` - 초당 커밋 작업의 평균 수
+ `CPUUtilization` - CPU 사용량은 하위 클러스터에 할당된 최대 ACU 값의 백분율입니다.
+ `FreeableMemory` - 샤드 그룹이 최대 용량으로 조정될 때 사용 가능한 미사용 메모리의 양입니다. 이는 샤드 그룹의 할당된 ACU에 의해 결정됩니다. 현재 용량이 최대 용량 미만인 모든 ACU에 대해 이 값은 약 2GiB씩 증가합니다. 따라서 이 지표는 DB 샤드 그룹이 최대 한도까지 스케일 업될 때까지 0에 가까워지지 않습니다.
+ `MaximumUsedTransactionIDs` - 가장 오랫동안 vacuum되지 않은 트랜잭션 ID의 연령(트랜잭션 수)입니다. 이 값이 2,146,483,648(2^31 - 1,000,000)에 도달하면 트랜잭션 ID의 랩어라운드를 방지할 목적으로 데이터베이스가 읽기 전용 모드로 강제 전환됩니다. 자세한 내용은 PostgreSQL 설명서의 [P트랜잭션 ID 랩어라운드 실패 방지](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)를 참조하세요.
+ `NetworkReceiveThroughput` - DB 샤드 그룹의 각 인스턴스가 클라이언트에서 수신하는 네트워크 처리량입니다. 이 처리량에서 DB 샤드 그룹의 인스턴스와 클러스터 볼륨 간 네트워크 트래픽은 제외됩니다.
+ `NetworkThroughput` - DB 샤드 그룹의 클라이언트와 라우터, 라우터와 샤드 간에 집계된 네트워크 처리량(전송 및 수신 모두)입니다. 이 처리량에서 DB 샤드 그룹의 인스턴스와 클러스터 볼륨 간 네트워크 트래픽은 제외됩니다.
+ `NetworkTransmitThroughput` - DB 샤드 그룹의 각 인스턴스가 클라이언트에 전송하는 네트워크 처리량입니다. 이 처리량에서 DB 샤드 그룹의 인스턴스와 클러스터 볼륨 간 네트워크 트래픽은 제외됩니다.
+ `ReadIOPS` - 디스크 읽기 초당 입출력 작업량(IOPS)의 평균 수입니다.
+ `ReadLatency` - 디스크 읽기 입출력(I/O) 작업당 평균 처리 시간입니다.
+ `ReadThroughput` - 초당 디스크에서 읽은 평균 바이트 수입니다.
+ `ServerlessDatabaseCapacity` - DB 샤드 그룹 내 DB 샤드 또는 라우터 하위 클러스터의 현재 용량입니다.
+ `StorageNetworkReceiveThroughput` - DB 샤드 그룹의 각 인스턴스가 Aurora 스토리지 하위 시스템에서 수신하는 네트워크 처리량입니다.
+ `StorageNetworkThroughput` - DB 샤드 그룹의 각 인스턴스가 Aurora 스토리지 하위 시스템으로 전송하고 해당 시스템에서 수신한 네트워크 처리량의 집계입니다.
+ `StorageNetworkTransmitThroughput` - DB 샤드 그룹의 각 인스턴스가 Aurora 스토리지 하위 시스템으로 전송하는 네트워크 처리량입니다.
+ `SwapUsage` - DB 샤드 그룹에서 사용하는 스왑 공간의 양입니다.
+ `TempStorageIOPS` - DB 인스턴스에 연결된 로컬 스토리지에서 수행된 I/O 작업의 평균 수입니다. 여기에는 읽기 및 쓰기 I/O 작업이 모두 포함됩니다.
`TempStorageIOPS`는 `TempStorageThroughput`과 함께 사용되어 DB 인스턴스와 로컬 스토리지 디바이스 간의 전송에 대한 네트워크 활동이 예상치 못한 용량 증가의 원인이 되는 드문 경우를 진단하는 데 도움이 될 수 있습니다.
+ `TempStorageThroughput` - 라우터 또는 샤드와 연결된 로컬 스토리지로 전송되고 해당 스토리지에서 전송되는 데이터의 양입니다.
+ `WriteIOPS` - 디스크 쓰기 IOPS의 평균 수입니다.
+ `WriteLatency` - 디스크 쓰기 I/O 작업당 평균 처리 시간입니다.
+ `WriteThroughput` - 초당 디스크에 쓴 평균 바이트 수입니다.
다음 차원 키는 `DBShardGroupInstance` 지표를 집계하는 데 사용할 수 있습니다.
+ `DBClusterIdentifier` - Aurora PostgreSQL DB 클러스터입니다.
+ `DBShardGroupIdentifier` - 인스턴스가 속한 DB 샤드 그룹입니다.
+ `DBShardGroupSubClusterType` - 노드 유형으로, `Distributed Transaction Router`(라우터) 또는 `Data Access Shard`(샤드)입니다.
+ `DBShardGroupSubClusterIdentifier` - 인스턴스가 속한 라우터 또는 샤드의 이름입니다.
다음은 CloudWatch 지표 집계의 예입니다.
+ DB 샤드 그룹의 특정 샤드 또는 라우터에 속하는 모든 인스턴스 총 `CPUUtilization`입니다.
+ DB 샤드 그룹에 있는 모든 인스턴스의 총 `CPUUtilization`입니다.
## DBClusterIdentifier 지표
CloudWatch 콘솔에서 Aurora PostgreSQL Limitless Database에 대한 `DBClusterIdentifier` 지표를 보려면 **RDS**를 선택한 다음 **DBClusterIdentifier**를 선택합니다.
Aurora PostgreSQL Limitless Database를 사용하는 경우 Aurora DB 클러스터에 비해 입출력(I/O) 작업이 더 많을 수 있습니다. Limitless Database 클러스터에 대해 다음 CloudWatch 지표를 추적할 수 있습니다.
+ `VolumeReadIops` - 클러스터 볼륨에서 요금이 청구된 읽기 I/O 작업의 수로, 5분마다 보고됩니다.
+ `VolumeWriteIops` - 클러스터 볼륨에 대한 평균 디스크 쓰기 I/O 작업 수로, 5분마다 보고됩니다.
Aurora PostgreSQL Limitless Database는 Aurora I/O-Optimized 클러스터 스토리지 구성을 사용합니다. Aurora I/O-Optimized를 사용하면 I/O 요청 100만 건당 요금을 지불하지 않고 모든 I/O 작업에 대해 월간 고정 요금을 지불합니다. 자세한 내용은 [Amazon Aurora DB 클러스터의 스토리지 구성](Aurora.Overview.StorageReliability.md#aurora-storage-type) 섹션을 참조하세요.
Aurora DB 클러스터에 비해 더 많은 스토리지를 사용할 수도 있습니다. 스토리지에 대한 다음 CloudWatch 지표를 추적할 수 있습니다.
+ `BackupRetentionPeriodStorageUsed` - Aurora PostgreSQL Limitless Database 클러스터의 청구된 총 연속 백업 스토리지 사용량입니다.
+ `SnapshotStorageUsed` - Aurora PostgreSQL Limitless Database 클러스터의 청구된 총 스냅샷 스토리지 사용량입니다.
+ `TotalBackupStorageBilled` - 자동 백업 보존 및 DB 클러스터 스냅샷에 대한 비용의 합계입니다.
백업 스토리지 비용에 대한 자세한 내용은 [Amazon Aurora 백업 스토리지 사용량 파악](aurora-storage-backup.md) 섹션을 참조하세요.
+ `VolumeBytesUsed` - Aurora PostgreSQL Limitless Database 클러스터에서 사용하는 스토리지 양으로, 5분마다 보고됩니다.
# CloudWatch Database Insights를 사용하여 Aurora PostgreSQL Limitless Database 모니터링
Aurora PostgreSQL Limitless Database를 활성화하려면 Database Insights의 표준 모드가 필요합니다. 이를 사용하여 Limitless Database DB 인스턴스의 데이터베이스 로드(DB 로드)를 실시간으로 모니터링할 수 있습니다. DB 로드는 데이터베이스의 세션 활동 수준을 측정합니다. Database Insights를 사용하여 Aurora PostgreSQL Limitless Database DB 인스턴스의 성능을 대규모로 분석하고 문제를 해결할 수 있습니다.
CloudWatch Database Insights에 대한 자세한 내용은 다음을 참조하세요.
+ [CloudWatch Database Insights를 사용하여 Amazon Aurora 데이터베이스 모니터링](USER_DatabaseInsights.md)
+ *Amazon CloudWatch 사용 설명서*의 [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html)
+ *Amazon CloudWatch 사용 설명서*의 [Get started with CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Get-Started.html)
+ [Amazon Aurora용 Database Insights를 사용하여 느린 SQL 쿼리를 모니터링하도록 데이터베이스 구성](USER_DatabaseInsights.SlowSQL.md)
Database Insights의 고급 모드 또는 표준 모드를 켜는 방법에 대한 내용은 다음 항목을 참조하세요.
**Topics**
+ [Aurora PostgreSQL Limitless Database용 Database Insights의 고급 모드 켜기](limitless-monitoring.cwdbi.advanced.md)
+ [Aurora PostgreSQL Limitless Database용 Database Insights의 표준 모드 켜기](limitless-monitoring.cwdbi.standard.md)
# Aurora PostgreSQL Limitless Database용 Database Insights의 고급 모드 켜기
Aurora PostgreSQL Limitless Database에서 Database Insights의 고급 모드를 켜려면 다음 절차를 따르세요.
## Aurora PostgreSQL Limitless Database용 DB 클러스터를 생성할 때 Database Insights의 고급 모드 켜기
Aurora PostgreSQL Limitless Database에 대한 데이터베이스를 만들 때 Database Insights의 고급 모드를 켭니다.
------
#### [ Console ]
콘솔에서 DB 클러스터를 만들 때 Database Insights의 고급 모드를 켤 수 있습니다. Database Insights 설정은 DB 클러스터의 모든 DB 인스턴스에 적용됩니다.
**콘솔을 사용하여 DB 클러스터를 만들 때 Database Insights의 고급 모드를 켜는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. **데이터베이스**를 선택합니다.
1. **데이터베이스 생성**를 선택합니다.
1. **Database Insights** 섹션에서 **고급 모드**를 선택합니다. 그런 다음, 다음 옵션 중 하나를 선택합니다.
+ **보존** – 성능 개선 도우미 데이터를 보존할 시간입니다. Database Insights의 고급 모드에서 보존 기간은 15\$124개월이어야 합니다.
+ **AWS KMS key** - KMS 키를 지정합니다. 성능 개선 도우미는 KMS 키를 사용하여 잠재적으로 민감한 데이터를 모두 암호화합니다. 데이터는 암호화된 상태로 전송 및 저장됩니다. 자세한 내용은 [Amazon Aurora 리소스 암호화](Overview.Encryption.md) 섹션을 참조하세요.
1. **데이터베이스 생성**를 선택합니다.
------
#### [ AWS CLI ]
DB 클러스터를 만들 때 Database Insights의 고급 모드를 켜려면 [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI 명령을 직접 호출하고 다음 값을 제공합니다.
+ `--db-cluster-identifier` - DB 클러스터의 식별자입니다.
+ `--database-insights-mode advanced`를 사용하여 Database Insights의 고급 모드를 켭니다.
+ `--engine` – DB 클러스터는 `aurora-postgresql` DB 엔진을 사용해야 합니다.
+ `--engine-version` – DB 클러스터는 다음과 같은 DB 엔진 버전 중 하나를 사용해야 합니다.
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type` – DB 클러스터는 `aurora-iopt1` DB 클러스터 스토리지 구성을 사용해야 합니다.
+ `--cluster-scalability-type` - Aurora DB 클러스터의 확장성 모드를 지정합니다. `limitless`로 설정하면 클러스터가 Aurora PostgreSQL Limitless Database로 작동합니다. `standard`(기본값)로 설정하면 클러스터가 일반 DB 인스턴스 만들기를 사용합니다.
**참고**
DB 클러스터를 만든 후에는 이 설정을 수정할 수 없습니다.
+ `--master-username` - DB 클러스터의 마스터 사용자 이름입니다.
+ `--master-user-password` - 마스터 사용자의 암호입니다.
+ `--enable-performance-insights`를 사용하여 Database Insights에 대한 성능 개선 도우미를 켭니다.
+ `--performance-insights-retention-period` - DB 클러스터의 데이터 보존 기간입니다. Database Insights를 켜려면 보존 기간이 최소 465일이어야 합니다.
+ `--monitoring-interval` - DB 클러스터에 대한 확장 모니터링 지표를 수집하는 시점 사이의 간격(초)입니다. 이 값은 `0`일 수 없습니다.
+ `--monitoring-role-arn` - RDS에서 Amazon CloudWatch Logs로 확장 모니터링 지표를 전송할 수 있도록 하는 IAM 역할의 Amazon 리소스 이름(ARN)입니다.
+ `--enable-cloudwatch-logs-exports` - `postgresql` 로그를 CloudWatch Logs로 내보내야 합니다.
다음 예시에서는 DB 클러스터를 만들 때 Database Insights의 고급 모드를 활성화합니다.
Linux, macOS, Unix의 경우:
```
aws rds create-db-cluster \
--db-cluster-identifier my-limitless-cluster \
--database-insights-mode advanced \
--engine aurora-postgresql \
--engine-version 16.6-limitless \
--storage-type aurora-iopt1 \
--cluster-scalability-type limitless \
--master-username myuser \
--master-user-password mypassword \
--enable-performance-insights \
--performance-insights-retention-period 465 \
--monitoring-interval 5 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \
--enable-cloudwatch-logs-exports postgresql
```
Windows의 경우:
```
aws rds create-db-cluster ^
--db-cluster-identifier my-limitless-cluster ^
--database-insights-mode advanced ^
--engine aurora-postgresql ^
--engine-version 16.6-limitless ^
--storage-type aurora-iopt1 ^
--cluster-scalability-type limitless ^
--master-username myuser ^
--master-user-password mypassword ^
--enable-performance-insights ^
--performance-insights-retention-period 465 ^
--monitoring-interval 5 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^
--enable-cloudwatch-logs-exports postgresql
```
------
#### [ RDS API ]
DB 클러스터를 만들 때 Database Insights의 고급 모드를 켜려면 [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API 작업에 대해 다음 파라미터를 지정합니다.
+ `DatabaseInsightsMode`\$1`advanced`
+ `Engine`\$1`aurora-postgresql`
+ `EngineVersion`을 Limitless Database에 사용 가능한 엔진 버전으로
+ `StorageType`\$1`aurora-iopt1`
+ `ClusterScalabilityType`\$1`limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights`\$1`True`
+ `PerformanceInsightsRetentionPeriod`를 최소 `465`일로
+ `MonitoringInterval`을 `0`이 아닌 값으로
+ `MonitoringRoleArn`을 RDS에서 Amazon CloudWatch Logs로 확장 모니터링 지표를 전송할 수 있도록 하는 IAM 역할의 Amazon 리소스 이름(ARN)으로
------
## Aurora PostgreSQL Limitless Database용 DB 클러스터를 수정할 때 Database Insights의 고급 모드 켜기
Aurora PostgreSQL Limitless Database에 대한 데이터베이스를 수정할 때 Database Insights를 켭니다.
**참고**
Database Insights를 사용 설정하려면 DB 클러스터의 각 DB 인스턴스에 동일한 성능 개선 도우미 및 확장 모니터링 설정이 있어야 합니다.
------
#### [ Console ]
콘솔에서 DB 클러스터를 수정할 때 Database Insights의 고급 모드를 켤 수 있습니다. Database Insights 설정은 DB 클러스터의 모든 DB 인스턴스에 적용됩니다.
**콘솔을 사용하여 DB 클러스터를 수정할 때 Database Insights의 고급 모드를 켜는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. **데이터베이스**를 선택합니다.
1. DB 클러스터를 선택하고 **수정**을 선택합니다.
1. **Database Insights** 섹션에서 **고급 모드**를 선택합니다. 그런 다음, 다음 옵션 중 하나를 선택합니다.
+ **보존** – 성능 개선 도우미 데이터를 보존할 시간입니다. Database Insights의 고급 모드에서 보존 기간은 15\$124개월이어야 합니다.
+ **AWS KMS key** - KMS 키를 지정합니다. 성능 개선 도우미는 KMS 키를 사용하여 잠재적으로 민감한 데이터를 모두 암호화합니다. 데이터는 암호화된 상태로 전송 및 저장됩니다. 자세한 내용은 [Amazon Aurora 리소스 암호화](Overview.Encryption.md) 섹션을 참조하세요.
1. **Continue(계속)**를 선택합니다.
1. **수정 스케줄링**에 대해 **즉시 적용**을 선택합니다. **예약된 다음 유지 관리 기간에 적용**을 선택하면 데이터베이스에서 이 설정을 무시하고 Database Insights의 고급 모드를 즉시 켭니다.
1. **클러스터 수정**을 선택합니다.
------
#### [ AWS CLI ]
DB 클러스터를 수정 때 Database Insights의 고급 모드를 켜려면 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI 명령을 직접 호출하고 다음 값을 제공합니다.
+ `--database-insights-mode advanced`를 사용하여 Database Insights의 고급 모드를 켭니다.
+ `--db-cluster-identifier` - DB 클러스터의 식별자입니다.
+ `--enable-performance-insights`를 사용하여 Database Insights에 대한 성능 개선 도우미를 켭니다.
+ `--performance-insights-retention-period` - DB 클러스터의 데이터 보존 기간입니다. Database Insights의 고급 모드를 켜려면 보존 기간이 최소 465일이어야 합니다.
다음 예시에서는 DB 클러스터를 수정할 때 Database Insights의 고급 모드를 활성화합니다.
Linux, macOS, Unix의 경우:
```
aws rds modify-db-cluster \
--database-insights-mode advanced \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 465
```
Windows의 경우:
```
aws rds modify-db-cluster ^
--database-insights-mode advanced ^
--db-cluster-identifier sample-db-identifier ^
--enable-performance-insights ^
--performance-insights-retention-period 465
```
------
#### [ RDS API ]
DB 클러스터를 수정할 때 Database Insights의 고급 모드를 켜려면 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) Amazon RDS API 작업에 대해 다음 파라미터를 지정합니다.
+ `DatabaseInsightsMode`\$1`advanced`
+ `EnablePerformanceInsights`\$1`True`
+ `PerformanceInsightsRetentionPeriod`를 최소 `465`일로
------
# Aurora PostgreSQL Limitless Database용 Database Insights의 표준 모드 켜기
Aurora PostgreSQL Limitless Database에서 Database Insights의 표준 모드를 켜려면 다음 절차를 따르세요.
## Aurora PostgreSQL Limitless Database용 DB 클러스터를 생성할 때 Database Insights의 표준 모드 켜기
Aurora PostgreSQL Limitless Database에 대한 데이터베이스를 만들 때 Database Insights의 표준 모드를 켭니다.
------
#### [ Console ]
콘솔에서 DB 클러스터를 만들 때 Database Insights의 표준 모드를 켤 수 있습니다. Database Insights 설정은 DB 클러스터의 모든 DB 인스턴스에 적용됩니다.
**콘솔을 사용하여 DB 클러스터를 만들 때 Database Insights의 표준 모드를 켜는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. **데이터베이스**를 선택합니다.
1. **데이터베이스 생성**를 선택합니다.
1. **Database Insights** 섹션에서 **표준 모드**를 선택합니다. 그런 다음, 다음 옵션 중 하나를 선택합니다.
+ **보존** – 성능 개선 도우미 데이터를 보존할 시간입니다. Aurora PostgreSQL Limitless Database용 DB 클러스터를 만들려면 보존 기간이 31일 이상이어야 합니다.
+ **AWS KMS key** - KMS 키를 지정합니다. 성능 개선 도우미는 KMS 키를 사용하여 잠재적으로 민감한 데이터를 모두 암호화합니다. 데이터는 암호화된 상태로 전송 및 저장됩니다. 자세한 내용은 [Amazon Aurora 리소스 암호화](Overview.Encryption.md) 섹션을 참조하세요.
1. **데이터베이스 생성**를 선택합니다.
------
#### [ AWS CLI ]
DB 클러스터를 만들 때 Database Insights의 표준 모드를 켜려면 [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI 명령을 직접 호출하고 다음 값을 제공합니다.
+ `--db-cluster-identifier` - DB 클러스터의 식별자입니다.
+ `--database-insights-mode standard`를 사용하여 Database Insights의 표준 모드를 켭니다.
+ `--engine` – DB 클러스터는 `aurora-postgresql` DB 엔진을 사용해야 합니다.
+ `--engine-version` – DB 클러스터는 다음과 같은 DB 엔진 버전 중 하나를 사용해야 합니다.
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type` – DB 클러스터는 `aurora-iopt1` DB 클러스터 스토리지 구성을 사용해야 합니다.
+ `--cluster-scalability-type` - Aurora DB 클러스터의 확장성 모드를 지정합니다. `limitless`로 설정하면 클러스터가 Aurora PostgreSQL Limitless Database로 작동합니다. `standard`(기본값)로 설정하면 클러스터가 일반 DB 인스턴스 만들기를 사용합니다.
**참고**
DB 클러스터를 만든 후에는 이 설정을 수정할 수 없습니다.
+ `--master-username` - DB 클러스터의 마스터 사용자 이름입니다.
+ `--master-user-password` - 마스터 사용자의 암호입니다.
+ `--enable-performance-insights`를 사용하여 Database Insights에 대한 성능 개선 도우미를 켭니다.
+ `--performance-insights-retention-period` - DB 클러스터의 데이터 보존 기간입니다. Aurora PostgreSQL Limitless Database용 DB 클러스터를 만들려면 보존 기간이 31일 이상이어야 합니다.
+ `--monitoring-interval` - DB 클러스터에 대한 확장 모니터링 지표를 수집하는 시점 사이의 간격(초)입니다. 이 값은 `0`일 수 없습니다.
+ `--monitoring-role-arn` - RDS에서 Amazon CloudWatch Logs로 확장 모니터링 지표를 전송할 수 있도록 하는 IAM 역할의 Amazon 리소스 이름(ARN)입니다.
+ `--enable-cloudwatch-logs-exports` - `postgresql` 로그를 CloudWatch Logs로 내보내야 합니다.
다음 예시에서는 DB 클러스터를 만들 때 Database Insights의 표준 모드를 활성화합니다.
Linux, macOS, Unix의 경우:
```
aws rds create-db-cluster \
--db-cluster-identifier my-limitless-cluster \
--database-insights-mode standard \
--engine aurora-postgresql \
--engine-version 16.6-limitless \
--storage-type aurora-iopt1 \
--cluster-scalability-type limitless \
--master-username myuser \
--master-user-password mypassword \
--enable-performance-insights \
--performance-insights-retention-period 31 \
--monitoring-interval 5 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \
--enable-cloudwatch-logs-exports postgresql
```
Windows의 경우:
```
aws rds create-db-cluster ^
--db-cluster-identifier my-limitless-cluster ^
--database-insights-mode standard ^
--engine aurora-postgresql ^
--engine-version 16.6-limitless ^
--storage-type aurora-iopt1 ^
--cluster-scalability-type limitless ^
--master-username myuser ^
--master-user-password mypassword ^
--enable-performance-insights ^
--performance-insights-retention-period 31 ^
--monitoring-interval 5 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^
--enable-cloudwatch-logs-exports postgresql
```
------
#### [ RDS API ]
DB 클러스터를 만들 때 Database Insights의 표준 모드를 켜려면 [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) Amazon RDS API 작업에 대해 다음 파라미터를 지정합니다.
+ `DatabaseInsightsMode`\$1`standard`
+ `Engine`\$1`aurora-postgresql`
+ `EngineVersion`을 Limitless Database에 사용 가능한 엔진 버전으로
+ `StorageType`\$1`aurora-iopt1`
+ `ClusterScalabilityType`\$1`limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights`\$1`True`
+ `PerformanceInsightsRetentionPeriod`를 최소 `31`일로
+ `MonitoringInterval`을 `0`이 아닌 값으로
+ `MonitoringRoleArn`을 RDS에서 Amazon CloudWatch Logs로 확장 모니터링 지표를 전송할 수 있도록 하는 IAM 역할의 Amazon 리소스 이름(ARN)으로
------
## Aurora PostgreSQL Limitless Database용 DB 클러스터를 수정할 때 Database Insights의 표준 모드 켜기
Aurora PostgreSQL Limitless Database에 대한 데이터베이스를 수정할 때 Database Insights를 켭니다.
**참고**
Database Insights를 사용 설정하려면 DB 클러스터의 각 DB 인스턴스에 동일한 성능 개선 도우미 및 향상된 모니터링 설정이 있어야 합니다.
------
#### [ Console ]
콘솔에서 DB 클러스터를 만들 때 Database Insights의 표준 모드를 켤 수 있습니다. Database Insights 설정은 DB 클러스터의 모든 DB 인스턴스에 적용됩니다.
**콘솔을 사용하여 DB 클러스터를 수정할 때 Database Insights의 표준 모드를 켜는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. **데이터베이스**를 선택합니다.
1. DB 클러스터를 선택하고 **수정**을 선택합니다.
1. **Database Insights** 섹션에서 **표준 모드**를 선택합니다. 그런 다음, 다음 옵션 중 하나를 선택합니다.
+ **보존** – 성능 개선 도우미 데이터를 보존할 시간입니다. Aurora PostgreSQL Limitless Database용 DB 클러스터를 만들려면 보존 기간이 31일 이상이어야 합니다.
+ **AWS KMS key** - KMS 키를 지정합니다. 성능 개선 도우미는 KMS 키를 사용하여 잠재적으로 민감한 데이터를 모두 암호화합니다. 데이터는 암호화된 상태로 전송 및 저장됩니다. 자세한 내용은 [Amazon Aurora 리소스 암호화](Overview.Encryption.md) 섹션을 참조하세요.
1. **Continue(계속)**를 선택합니다.
1. **수정 스케줄링**에 대해 **즉시 적용**을 선택합니다. **예약된 다음 유지 관리 기간에 적용**을 선택하면 데이터베이스에서 이 설정을 무시하고 Database Insights의 표준 모드를 즉시 켭니다.
1. **클러스터 수정**을 선택합니다.
------
#### [ AWS CLI ]
DB 클러스터를 수정 때 Database Insights의 표준 모드를 켜려면 [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI 명령을 직접 호출하고 다음 값을 제공합니다.
+ `--db-cluster-identifier` - DB 클러스터의 식별자입니다.
+ `--database-insights-mode standard`를 사용하여 Database Insights의 표준 모드를 켭니다.
+ `--enable-performance-insights`를 사용하여 Database Insights에 대한 성능 개선 도우미를 켭니다.
+ `--performance-insights-retention-period` - DB 클러스터의 데이터 보존 기간입니다. Database Insights의 표준 모드를 켜려면 보존 기간이 최소 31일이어야 합니다.
다음 예시에서는 DB 클러스터를 수정할 때 Database Insights의 표준 모드를 활성화합니다.
Linux, macOS, Unix의 경우:
```
aws rds modify-db-cluster \
--database-insights-mode standard \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 31
```
Windows의 경우:
```
aws rds modify-db-cluster ^
--database-insights-mode standard ^
--db-cluster-identifier sample-db-identifier ^
--enable-performance-insights ^
--performance-insights-retention-period 31
```
------
#### [ RDS API ]
DB 클러스터를 수정할 때 Database Insights의 표준 모드를 켜려면 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) Amazon RDS API 작업에 대해 다음 파라미터를 지정합니다.
+ `DatabaseInsightsMode`\$1`standard`
+ `EnablePerformanceInsights`\$1`True`
+ `PerformanceInsightsRetentionPeriod`를 최소 `31`일로
------
# Amazon CloudWatch Logs를 사용하여 Aurora PostgreSQL Limitless Database 모니터링
Aurora PostgreSQL Limitless Database를 활성화하려면 PostgreSQL 로그를 CloudWatch Logs로 내보내야 합니다. 표준 Aurora PostgreSQL DB 클러스터에 대한 PostgreSQL 로그에 액세스하는 것과 마찬가지로 CloudWatch Logs Insights에서 이러한 로그에 액세스하고 분석할 수 있습니다. 자세한 내용은 [CloudWatch Logs Insights를 사용하여 PostgreSQL 로그 분석](AuroraPostgreSQL.CloudWatch.Analyzing.md) 단원을 참조하십시오.
DB 클러스터의 로그 그룹 이름은 Aurora PostgreSQL과 동일합니다.
```
/aws/rds/cluster/DB_cluster_ID/postgresql
```
DB 샤드 그룹의 로그 그룹 이름 형식은 다음과 같습니다.
```
/aws/rds/cluster/DB_cluster_ID/DB_shard_group_ID/postgresql
```
각 노드(라우터 또는 샤드)에 대한 로그 스트림이 있습니다. 이름의 형식은 다음과 같습니다.
```
[DistributedTransactionRouter|DataAccessShard]/node_cluster_serial_ID-node_instance_serial_ID/n
```
예시:
+ 라우터 - `DistributedTransactionRouter/6-6.2`
+ 샤드 - `DataAccessShard/22-22.0`
**참고**
DB 클러스터의 경우처럼 RDS 콘솔, AWS CLI 또는 RDS API에서 직접 DB 샤드 그룹의 PostgreSQL 로그 파일을 볼 수 없습니다. CloudWatch Logs Insights를 사용하여 확인해야 합니다.
# 향상된 모니터링을 사용한 Aurora PostgreSQL Limitless Database 모니터링
향상된 모니터링은 Aurora PostgreSQL Limitless Database 활성화할 경우 필수입니다. 이를 사용하여 Limitless Database DB 인스턴스의 운영 체제를 실시간으로 모니터링할 수 있습니다.
Aurora는 CloudWatch Logs에 향상된 모니터링 지표를 게시합니다. 사용 가능한 주요 지표로는 데이터베이스 연결, 스토리지 사용량, 쿼리 지연 시간 등이 있습니다. 이러한 지표는 성능 병목 현상을 파악하는 데 도움이 됩니다.
향상된 모니터링 지표에 대한 자세한 내용은 [Aurora의 지표](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS) 섹션을 참조하세요.
# 성능 개선 도우미를 사용한 Aurora PostgreSQL Limitless Database 모니터링
성능 개선 도우미를 사용하여 Aurora PostgreSQL Limitless Database 클러스터를 모니터링합니다. 성능 개선 도우미는 Aurora PostgreSQL Limitless Database에서도 표준 Aurora DB 클러스터에서와 마찬가지로 작동합니다. 그러나 Aurora PostgreSQL Limitless Database에서는 샤드 그룹 수준에서 지표를 추적합니다.
추적할 두 가지 주요 성능 개선 도우미 지표는 다음과 같습니다.
+ 데이터베이스 로드 - 데이터베이스의 활동 수준을 측정합니다. 성능 개선 도우미의 핵심 지표는 `DBLoad`이며, 1초 간격으로 수집됩니다.
성능 개선 도우미에서 `DBLoad` 지표의 단위는 평균 활성 세션(AAS)입니다. 평균 활성 세션을 구하기 위해 성능 개선 도우미는 쿼리를 동시에 실행하는 세션 수를 샘플링합니다. AAS는 특정 기간 동안의 총 세션 수를 총 샘플 수로 나눈 값입니다. `DBLoad` 및 AAS에 대한 자세한 내용은 [데이터베이스 부하](USER_PerfInsights.Overview.ActiveSessions.md) 섹션을 참조하세요.
+ 최대 CPU - 데이터베이스에서 사용할 수 있는 최대 컴퓨팅 성능입니다. 활성 세션이 최대 CPU를 초과하는지 확인하려면 `Max vCPU` 줄과의 관계를 확인합니다. `Max vCPU` 값은 DB 인스턴스에서 vCPU(가상 CPU) 코어의 수로 결정됩니다. `Max vCPU`에 대한 자세한 내용은 [최대 CPU](USER_PerfInsights.Overview.MaxCPU.md) 섹션을 참조하세요.
또한 `DBLoad` 지표를 이 지표의 하위 범주인 *차원*으로 '분할'할 수 있습니다. 가장 유용한 차원은 다음과 같습니다.
+ 상위 인스턴스 - 인스턴스(샤드 및 라우터)의 상대적 DB 로드를 내림차순으로 표시합니다.
+ 대기 이벤트 - SQL 문이 계속 실행되기 전에 특정 이벤트가 발생할 때까지 기다리도록 합니다. 대기 이벤트는 작업이 방해받는 위치를 나타냅니다.
+ 상위 SQL - DB 로드에 가장 많이 기여하는 쿼리를 표시합니다.
성능 개선 도우미에 대한 자세한 내용은 [차원](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions) 섹션을 참조하세요.
다음 그림은 DB 샤드 그룹의 **상위 인스턴스** 차원을 보여줍니다.
![\[DB 샤드 그룹의 상위 인스턴스 차원.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
**Topics**
+ [성능 개선 도우미 대시보드를 사용하여 Aurora PostgreSQL Limitless Database의 DB 로드 분석](USER_PerfInsights.AnalyzeLimitlessTables.md)
# 성능 개선 도우미 대시보드를 사용하여 Aurora PostgreSQL Limitless Database의 DB 로드 분석
성능 개선 도우미를 사용하면 Aurora PostgreSQL Limitless Database의 샤드 그룹 수준 및 인스턴스 수준에서 지표를 추적할 수 있습니다. Aurora PostgreSQL Limitless Database의 DB 로드를 분석할 때 각 샤드 및 라우터의 DB 로드를 최대 vCPU와 비교해볼 수 있습니다.
**참고**
Aurora PostgreSQL Limitless Database에는 항상 성능 개선 도우미 및 향상된 모니터링이 활성화되어 있습니다. Limitless Database에 대한 성능 개선 도우미 데이터의 최소 보존 기간은 31일(1개월)입니다.
**절대** 뷰에는 평균 활성 세션(AAS) 수와 예상 vCPU가 표시됩니다. **상대** 뷰는 AAS 대 추정 vCPU의 비율을 보여줍니다.
**Topics**
+ [성능 개선 도우미 대시보드를 사용하여 Aurora PostgreSQL Limitless Database의 상대 DB 로드 분석](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad)
+ [성능 개선 도우미 대시보드를 사용하여 대기를 기준으로 Aurora PostgreSQL Limitless Database의 DB 로드 분석](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md)
+ [성능 개선 도우미 대시보드를 사용하여 Aurora PostgreSQL Limitless Database의 로드 분산 분석](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md)
## 성능 개선 도우미 대시보드를 사용하여 Aurora PostgreSQL Limitless Database의 상대 DB 로드 분석
상대 DB 로드를 추적하여 Aurora PostgreSQL Limitless Database의 성능을 개선하고 싶을 수 있습니다. 인스턴스별로 Aurora PostgreSQL Limitless Database의 상대 DB 로드를 분석하려면 다음 프로시저를 사용합니다.
**콘솔을 사용하여 Aurora PostgreSQL Limitless Database의 상대 DB 로드를 분석하는 방법**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **성능 개선 도우미**을 선택합니다.
1. Aurora PostgreSQL Limitless Database를 선택합니다. 해당 Aurora PostgreSQL Limitless Database에 대한 성능 개선 도우미 대시보드가 표시됩니다.
1. **데이터베이스 로드(DB 로드)** 섹션에서 **분할 기준**에서 **인스턴스**를 선택합니다. Aurora PostgreSQL Limitless Database의 모든 인스턴스에 대해 평균 활성 세션(AAS) 대 vCPU 코어의 비율을 보려면 **다음으로 보기**에서 **상대**를 선택합니다.
평균 활성 세션 차트는 Aurora PostgreSQL Limitless Database의 인스턴스에 대한 DB 로드를 보여줍니다.
![\[인스턴스로 분할된 Aurora PostgreSQL Limitless Database의 성능 개선 도우미 대시보드를 봅니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png)
1. 최상위 인스턴스를 보려면 **상위 인스턴스** 탭을 선택합니다.
다음 예시에서 DB 로드가 가장 높은 인스턴스는 `DTR-2-2`입니다.
![\[인스턴스로 분할된 Aurora PostgreSQL Limitless Database의 경우 상위 인스턴스 탭을 사용합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
1. (선택 사항) Aurora PostgreSQL Limitless Database의 인스턴스에 대한 DB 로드를 분석하려면 **인스턴스** 열에서 인스턴스 이름을 선택합니다. `DTR-2-2`의 DB 로드를 보려면 **인스턴스** 열에서 `DTR-2-2`를 선택합니다.
**참고**
Aurora PostgreSQL Limitless Database의 인스턴스에 대해서만 성능 개선 도우미 지표를 볼 수 있습니다.
# 성능 개선 도우미 대시보드를 사용하여 대기를 기준으로 Aurora PostgreSQL Limitless Database의 DB 로드 분석
대기 이벤트를 추적하여 Aurora PostgreSQL Limitless Database의 성능을 개선하고 싶을 수 있습니다. 대기 이벤트별로 Aurora PostgreSQL Limitless Database의 DB 로드를 분석하려면 다음 프로시저를 사용합니다.
**콘솔을 사용하여 대기를 기준으로 Aurora PostgreSQL Limitless Database의 DB 로드를 분석하는 방법**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **성능 개선 도우미**을 선택합니다.
1. Aurora PostgreSQL Limitless Database를 선택합니다. 해당 Aurora PostgreSQL Limitless Database에 대한 성능 개선 도우미 대시보드가 표시됩니다.
1. **데이터베이스 로드(DB 로드)** 섹션에서 **분할 기준**에서 **대기**를 선택합니다. AAS 수와 예상 vCPU를 보려면 **다음으로 보기**보기에서 **절대**를 선택합니다.
평균 활성 세션 차트는 Aurora PostgreSQL Limitless Database의 인스턴스에 대한 DB 로드를 보여줍니다.
![\[대기를 기준으로 분할됨.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png)
1. **상위 SQL** 탭까지 아래로 스크롤합니다.
다음 예시에서 대기를 기준으로 로드가 가장 높은 SQL 문은 `DELETE` 문입니다.
![\[대기를 기준으로 분할한 경우 상위 SQL 탭.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png)
1. SQL 문을 선택하여 구성 요소 문으로 확장합니다.
다음 예시에서 `SELECT` 문에는 3개의 구성 요소 문이 있습니다.
![\[SQL 문을 선택하여 확장합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql-selected.png)
# 성능 개선 도우미 대시보드를 사용하여 Aurora PostgreSQL Limitless Database의 로드 분산 분석
Aurora PostgreSQL Limitless Database의 인스턴스에 대한 로드 분산의 균형을 맞추고 싶을 수 있습니다. Aurora PostgreSQL Limitless Database에서 인스턴스의 로드 분산을 분석하려면 다음 프로시저를 사용합니다.
**콘솔을 사용하여 Aurora PostgreSQL Limitless Database에서 인스턴스의 로드 분산을 분석하는 방법**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **성능 개선 도우미**을 선택합니다.
1. Aurora PostgreSQL Limitless Database를 선택합니다. 해당 Aurora PostgreSQL Limitless Database에 대한 성능 개선 도우미 대시보드가 표시됩니다.
1. **데이터베이스 로드(DB 로드)** 섹션에서 **분할 기준**에서 **인스턴스**를 선택합니다. Aurora PostgreSQL Limitless Database의 모든 인스턴스에 대한 AAS 수와 예상 vCPU를 보려면 **다음으로 보기**를 **절대**로 선택합니다.
평균 활성 세션 차트는 Aurora PostgreSQL Limitless Database의 인스턴스에 대한 DB 로드를 보여줍니다.
![\[인스턴스로 분할된 Aurora PostgreSQL Limitless Database의 절대 성능 개선 도우미 대시보드를 봅니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png)
1. Aurora PostgreSQL Limitless Database에서 인스턴스의 로드 분산 차트를 보려면 **로드 분산** 탭을 선택합니다.
다음 예시에서 DB 로드가 가장 높은 인스턴스는 `DTR-2-2`입니다.
![\[인스턴스 수준에서 대기로 분할할 경우 상위 SQL 탭.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png)
# Amazon GuardDuty RDS Protection을 사용하여 Aurora PostgreSQL Limitless Database 모니터링
Amazon GuardDuty는 AWS 환경 내 계정, 컨테이너, 워크로드 및 데이터를 보호하는 데 도움이 되는 위협 감지 서비스입니다. GuardDuty는 기계 학습(ML) 모델, 이상 및 위협 감지 기능을 통해 다양한 로그 소스와 런타임 활동을 지속적으로 모니터링하여 사용자 환경의 잠재적 보안 위험과 악의적 활동을 식별하고 우선순위를 지정합니다.
GuardDuty RDS Protection은 Amazon Aurora 데이터베이스에 대한 잠재적 액세스 위협 관련 로그인 이벤트를 분석하고 프로파일링합니다. RDS 보호를 켜면 GuardDuty는 Aurora 데이터베이스에서 RDS 로그인 이벤트를 사용합니다. RDS Protection은 이러한 이벤트를 모니터링하고 잠재적인 내부자 위협 또는 외부 행위자가 있는지 프로파일링합니다.
Aurora의 GuardDuty RDS Protection에 대한 자세한 내용은 [Amazon Aurora용 Amazon GuardDuty RDS Protection을 이용한 위협 모니터링](guard-duty-rds-protection.md) 섹션을 참조하세요.
GuardDuty RDS Protection 활성화에 대한 자세한 내용은 *Amazon GuardDuty 사용 설명서*의 [GuardDuty RDS Protection](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html)을 참조하세요.
# Aurora PostgreSQL Limitless Database의 함수 및 뷰
Aurora PostgreSQL Limitless Database에 함수와 뷰가 추가되었습니다. 이는 해당 Aurora PostgreSQL 함수 및 뷰를 기반으로 합니다.
**참고**
진행 중인 트랜잭션이 있는 경우 일부 통계는 일관되지 않은 결과를 반환할 수 있습니다.
**Topics**
+ [Aurora PostgreSQL Limitless Database 함수](limitless-monitoring-functions.md)
+ [Aurora PostgreSQL Limitless Database 뷰](limitless-monitoring-views.md)
# Aurora PostgreSQL Limitless Database 함수
다음 표에는 Aurora PostgreSQL Limitless Database의 새로운 함수가 나와 있습니다.
**참고**
이 표에 나열된 함수는 `rds_aurora` 스키마에 있습니다. Limitless Database 함수를 사용할 때는 `rds_aurora`.`object_name`.과 같은 정규화된 객체 이름을 포함해야 합니다.
| Aurora PostgreSQL Limitless Database 함수 | 해당 Aurora PostgreSQL 함수 |
| --- | --- |
| [limitless\$1backend\$1dsid](#limitless_backend_dsid) | pg\$1backend\$1pid |
| [limitless\$1cancel\$1session](#limitless_cancel_session) | pg\$1cancel\$1backend |
| [limitless\$1stat\$1clear\$1snapshot](#limitless_stat_clear_snapshot) | pg\$1stat\$1clear\$1snapshot |
| [limitless\$1stat\$1database\$1size](#limitless_stat_database_size) | pg\$1database\$1size |
| [limitless\$1stat\$1get\$1snapshot\$1timestamp](#limitless_stat_get_snapshot_timestamp) | pg\$1stat\$1get\$1snapshot\$1timestamp |
| [limitless\$1stat\$1prepared\$1xacts](#limitless_stat_prepared_xacts) | pg\$1prepared\$1xacts |
| [limitless\$1stat\$1relation\$1sizes](#limitless_stat_relation_sizes) | pg\$1indexes\$1size, pg\$1relation\$1size, pg\$1table\$1size, pg\$1total\$1relation\$1size |
| [limitless\$1stat\$1reset](#limitless_stat_reset) | pg\$1stat\$1reset |
| [limitless\$1stat\$1statements\$1reset](#limitless_stat_statements_reset) | pg\$1stat\$1statements\$1reset |
| [limitless\$1stat\$1system\$1waits](#limitless_stat_system_waits) | aurora\$1stat\$1system\$1waits |
| [limitless\$1terminate\$1session](#limitless_terminate_session) | pg\$1terminate\$1backend |
| [limitless\$1wait\$1report](#limitless_wait_report) | aurora\$1wait\$1report |
다음 예시에서는 Aurora PostgreSQL Limitless Database 함수에 대한 세부 정보를 제공합니다. PostgreSQL 함수에 대한 자세한 내용은 PostgreSQL 설명서에서 [Functions and operators](https://www.postgresql.org/docs/15/functions.html)를 참조하세요.
**limitless\$1backend\$1dsid**
`limitless_backend_dsid` 함수는 현재 세션의 분산 세션 ID를 반환합니다. 분산 세션은 DB 샤드 그룹의 라우터에서 실행되며 DB 샤드 그룹의 샤드 중 하나 이상에서 이루어지는 백엔드 프로세스를 포함합니다.
다음 예시에서는 `limitless_backend_dsid` 함수를 사용하는 방법을 보여줍니다.
```
SELECT rds_aurora.limitless_backend_dsid();
limitless_backend_dsid
------------------------
8CACD7B04D0FC2A5
(1 row)
```
**limitless\$1cancel\$1session**
`limitless_cancel_session` 함수는 `pg_cancel_backend`와 비슷하게 작동하지만 `SIGINT`(중단 신호)를 전송하여 제공된 분산 세션 ID와 관련된 모든 백엔드 프로세스를 취소하려고 합니다.
입력 파라미터는 다음과 같습니다.
+ `distributed_session_id`(text) - 취소할 분산 세션의 ID입니다.
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `pid`(text) - 백엔드 프로세스 ID입니다.
+ `success`(boolean) - 취소의 성공 여부입니다.
다음 예시에서는 `limitless_cancel_session` 함수를 사용하는 방법을 보여줍니다.
```
SELECT * FROM rds_aurora.limitless_cancel_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1stat\$1clear\$1snapshot**
`limitless_stat_clear_snapshot` 함수는 모든 노드에서 현재 통계 스냅샷 또는 캐싱된 정보를 삭제합니다.
다음 예시에서는 `limitless_stat_clear_snapshot` 함수를 사용하는 방법을 보여줍니다.
```
SELECT rds_aurora.limitless_stat_clear_snapshot();
```
**limitless\$1stat\$1database\$1size**
`limitless_stat_database_size` 함수는 DB 샤드 그룹의 데이터베이스 크기를 반환합니다.
입력 파라미터는 다음과 같습니다.
+ `dbname`(name) - 크기를 가져올 데이터베이스입니다.
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `subcluster_type`(text) - 이 프로세스가 속한 하위 클러스터 유형으로, `router` 또는 `shard`입니다.
+ `db_size` - 이 하위 클러스터의 데이터베이스 크기를 바이트 단위로 표시합니다.
다음 예시에서는 `limitless_stat_database_size` 함수를 사용하는 방법을 보여줍니다.
```
SELECT * FROM rds_aurora.limitless_stat_database_size('postgres_limitless');
subcluster_id | subcluster_type | db_size
---------------+-----------------+----------
1 | router | 8895919
2 | router | 8904111
3 | shard | 21929391
4 | shard | 21913007
5 | shard | 21831087
(5 rows)
```
**limitless\$1stat\$1get\$1snapshot\$1timestamp**
`limitless_stat_get_snapshot_timestamp` 함수는 현재 통계 스냅샷의 타임스탬프를 반환하거나 통계 스냅샷이 생성되지 않은 경우 `NULL`을 반환합니다. `stats_fetch_consistency`가 `snapshot`으로 설정된 경우 트랜잭션에서 누적 통계에 처음 액세스할 때 스냅샷이 생성됩니다. 모든 노드의 스냅샷 타임스탬프에 대한 통합 뷰를 반환합니다. `subcluster_id` 및 `subcluster_type` 열에는 데이터가 소스 노드가 표시됩니다.
다음 예시에서는 `limitless_stat_get_snapshot_timestamp` 함수를 사용하는 방법을 보여줍니다.
```
SELECT * FROM rds_aurora.limitless_stat_get_snapshot_timestamp();
subcluster_id | subcluster_type | snapshot_timestamp
---------------+-----------------+--------------------
1 | router |
2 | router |
3 | shard |
4 | shard |
5 | shard |
(5 rows)
```
**limitless\$1stat\$1prepared\$1xacts**
`limitless_stat_prepared_xacts` 함수는 현재 두 단계 커밋을 위해 준비된 모든 노드의 트랜잭션에 대한 정보를 반환합니다. 자세한 내용은 PostgreSQL 설명서에서 [pg\$1prepared\$1xacts](https://www.postgresql.org/docs/current/view-pg-prepared-xacts.html)를 참조하세요.
다음 예시에서는 `limitless_stat_prepared_xacts` 함수를 사용하는 방법을 보여줍니다.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_prepared_xacts;
subcluster_id | subcluster_type | transaction_id | gid | prepared | owner_id | database_id
---------------+-----------------+----------------+------------------------------+-------------------------------+------------+--------------------
8 | shard | 5815978 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659603+00 | auroraperf | postgres_limitless
12 | shard | 4599138 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659637+00 | auroraperf | postgres_limitless
(2 rows)
```
**limitless\$1stat\$1relation\$1sizes**
`limitless_stat_relation_sizes` 함수는 DB 샤드 그룹에 있는 테이블의 다양한 크기를 반환합니다.
입력 파라미터는 다음과 같습니다.
+ `relnspname`(name) - 테이블이 포함된 스키마의 이름입니다.
+ `relname`(name) - 테이블의 이름입니다.
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `subcluster_type`(text) - 이 프로세스가 속한 하위 클러스터 유형으로, `router` 또는 `shard`입니다.
+ `main_size` - 이 노드의 기본 데이터 포크 크기를 바이트 단위로 표시합니다.
+ `fsm_size` - 이 노드의 테이블에 대한 여유 공간 맵의 크기를 바이트 단위로 표시합니다.
+ `vm_size` - 이 노드의 테이블에 대한 가시성 맵의 크기를 바이트 단위로 표시합니다.
+ `init_size` - 이 노드에 있는 테이블 초기화의 크기를 바이트 단위로 표시합니다.
+ `toast_size` - 이 포크의 테이블과 연결된 토스트 테이블의 크기를 바이트 단위로 표시합니다.
+ `index_size` - 이 노드의 테이블에 대한 모든 인덱스의 크기를 바이트 단위로 표시합니다.
+ `total_size` - 이 노드에 있는 테이블의 모든 세그먼트의 크기를 바이트 단위로 표시합니다.
다음 예시에서는 `limitless_stat_relation_sizes` 함수를 사용하는 방법을 보여줍니다(일부 열은 생략됨).
```
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customers');
subcluster_id | subcluster_type | main_size | fsm_size | vm_size | toast_size | table_size | total_size
---------------+-----------------+-----------+----------+---------+------------+------------+------------
1 | router | 0 | 0 | 0 | 0 | 0 | 0
2 | router | 0 | 0 | 0 | 0 | 0 | 0
3 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928
4 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928
5 | shard | 3981312 | 4227072 | 1409024 | 1409024 | 11026432 | 11026432
(5 rows)
```
**limitless\$1stat\$1reset**
`limitless_stat_reset` 함수는 현재 데이터베이스의 모든 통계 카운터를 0으로 재설정합니다. `track_functions`이 활성화되면 `limitless_stat_database`의 `stats_reset` 열에 데이터베이스에 대한 통계가 마지막으로 재설정된 시간이 표시됩니다. 기본적으로 `limitless_stat_reset`은 슈퍼 사용자만 실행할 수 있습니다. `EXECUTE` 권한을 사용하여 다른 사용자에게 권한을 부여할 수 있습니다.
다음 예시에서는 `limitless_stat_reset` 함수를 사용하는 방법을 보여줍니다.
```
SELECT tup_inserted, tup_deleted FROM pg_stat_database
WHERE datname = 'postgres_limitless';
tup_inserted | tup_deleted
--------------+-------------
896 | 0
(1 row)
SELECT rds_aurora.limitless_stat_reset();
limitless_stat_reset
---------------------
(1 row)
SELECT tup_inserted, tup_deleted FROM pg_stat_database
WHERE datname = 'postgres_limitless';
tup_inserted | tup_deleted
-------------+-------------
0 | 0
(1 row)
```
**limitless\$1stat\$1statements\$1reset**
`limitless_stat_statements_reset` 함수는 `limitless_stat_statements`가 지금까지 수집한 지정된 `username`, `dbname`, `distributed_query_id` 및 `queryid` 파라미터에 해당하는 통계를 삭제합니다. 파라미터가 지정되지 않은 경우 각각에 기본값 `""` 또는 `0`(유효하지 않음)이 사용되며 다른 파라미터와 일치하는 통계가 재설정됩니다. 파라미터가 지정되지 않았거나 지정된 모든 파라미터가 `""` 또는 `0`(유효하지 않음)인 경우 함수는 모든 통계를 삭제합니다. `limitless_stat_statements` 뷰의 모든 통계가 삭제되면 함수는 `limitless_stat_statements_info` 뷰의 통계도 재설정합니다.
입력 파라미터는 다음과 같습니다.
+ `username`(name) - 문을 쿼리한 사용자입니다.
+ `dbname`(name) - 쿼리가 실행된 데이터베이스입니다.
+ `distributed_query_id`(bigint) - 코디네이터 노드에서 상위 쿼리의 쿼리 ID입니다. 이 열은 상위 쿼리인 경우 `NULL`입니다. 코디네이터 노드는 분산 쿼리 ID를 참가자 노드로 푸시다운합니다. 따라서 참가자 노드의 경우 분산 쿼리 ID와 쿼리 ID의 값이 다릅니다.
+ `queryid`(bigint) - 문의 쿼리 ID입니다.
다음 예시에서는 `limitless_stat_statements_reset` 함수를 사용하여 `limitless_stat_statements`가 수집한 모든 통계를 재설정하는 방법을 보여줍니다.
```
SELECT rds_aurora.limitless_stat_statements_reset();
```
**limitless\$1stat\$1system\$1waits**
`limitless_stat_system_waits` 함수는 모든 노드에서 인스턴스의 시스템 전체 대기 활동을 보고하는 `aurora_stat_system_waits`의 대기 이벤트 데이터에 대한 통합 뷰를 반환합니다. `subcluster_id` 및 `subcluster_type` 열에는 데이터가 소스 노드가 표시됩니다.
다음 예시에서는 `limitless_stat_system_waits` 함수를 사용하는 방법을 보여줍니다.
```
postgres_limitless=> SELECT *
FROM rds_aurora.limitless_stat_system_waits() lssw, pg_catalog.aurora_stat_wait_event() aswe
WHERE lssw.event_id=aswe.event_id and aswe.event_name='LimitlessTaskScheduler';
subcluster_id | subcluster_type | type_id | event_id | waits | wait_time | event_name
---------------+-----------------+---------+-----------+--------+--------------+------------------------
1 | router | 12 | 201326607 | 677068 | 616942216307 | LimitlessTaskScheduler
2 | router | 12 | 201326607 | 678586 | 616939897111 | LimitlessTaskScheduler
3 | shard | 12 | 201326607 | 756640 | 616965545172 | LimitlessTaskScheduler
4 | shard | 12 | 201326607 | 755184 | 616958057620 | LimitlessTaskScheduler
5 | shard | 12 | 201326607 | 757522 | 616963183539 | LimitlessTaskScheduler
(5 rows)
```
**limitless\$1terminate\$1session**
`limitless_terminate_session` 함수는 `pg_terminate_backend`와 비슷하게 작동하지만 `SIGTERM`(종료 신호)를 전송하여 제공된 분산 세션 ID와 관련된 모든 백엔드 프로세스를 종료하려고 합니다.
입력 파라미터는 다음과 같습니다.
+ `distributed_session_id`(text) - 종료할 분산 세션의 ID입니다.
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `pid`(text) - 백엔드 프로세스 ID입니다.
+ `success`(boolean) - 프로세스가 성공적으로 종료되었는지를 나타냅니다.
다음 예시에서는 `limitless_terminate_session` 함수를 사용하는 방법을 보여줍니다.
```
SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1wait\$1report**
`limitless_wait_report` 함수는 모든 노드에서 일정 기간 동안의 대기 이벤트 활동을 반환합니다. `subcluster_id` 및 `subcluster_type` 열에는 데이터가 소스 노드가 표시됩니다.
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `subcluster_type`(text) - 이 프로세스가 속한 하위 클러스터 유형으로, `router` 또는 `shard`입니다.
나머지 열은 `aurora_wait_report`의 열과 동일합니다.
다음 예시에서는 `limitless_wait_report` 함수를 사용하는 방법을 보여줍니다.
```
postgres_limitless=> select * from rds_aurora.limitless_wait_report();
subcluster_id | subcluster_type | type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
---------------+-----------------+-----------+------------+-------+-----------+-------------+--------------- +-------------
1 | router | Client | ClientRead | 57 | 741550.14 | 13009.652 | 0.19 | 2505.237
5 | shard | Client | ClientRead | 54 | 738897.68 | 13683.290 | 0.18 | 2496.276
4 | shard | Client | ClientRead | 54 | 738859.53 | 13682.584 | 0.18 | 2496.147
2 | router | Client | ClientRead | 53 | 719223.64 | 13570.257 | 0.18 | 2429.810
3 | shard | Client | ClientRead | 54 | 461720.40 | 8550.378 | 0.18 | 1559.86
```
# Aurora PostgreSQL Limitless Database 뷰
다음 표에는 Aurora PostgreSQL Limitless Database의 새 뷰가 나와 있습니다.
**참고**
이 테이블에 나열된 뷰는 `rds_aurora` 스키마에 있습니다. Limitless Database 뷰를 사용할 때는 `rds_aurora`.`object_name`.과 같은 정규화된 객체 이름을 포함해야 합니다.
| Aurora PostgreSQL Limitless Database 뷰 | 해당 Aurora PostgreSQL 뷰 |
| --- | --- |
| [limitless\$1database](#limitless_database) | pg\$1database |
| [limitless\$1locks](#limitless_locks) | pg\$1locks |
| [limitless\$1stat\$1activity](#limitless_stat_activity) | pg\$1stat\$1activity |
| [limitless\$1stat\$1all\$1indexes](#limitless_stat_all_indexes) | pg\$1stat\$1all\$1indexes |
| [limitless\$1stat\$1all\$1tables](#limitless_stat_all_tables) | pg\$1stat\$1all\$1tables |
| [limitless\$1stat\$1database](#limitless_stat_database) | pg\$1stat\$1database |
| [limitless\$1stat\$1progress\$1vacuum](#limitless_stat_progress_vacuum) | pg\$1stat\$1progress\$1vacuum |
| [limitless\$1stat\$1statements](#limitless_stat_statements) | pg\$1stat\$1statements |
| [limitless\$1stat\$1subclusters](#limitless_stat_subclusters) | 없음 |
| [limitless\$1stat\$1statements\$1info](#limitless_stat_statements_info) | pg\$1stat\$1statements\$1info |
| [limitless\$1statio\$1all\$1indexes](#limitless_statio_all_indexes) | pg\$1statio\$1all\$1indexes |
| [limitless\$1statio\$1all\$1tables](#limitless_statio_all_tables) | pg\$1statio\$1all\$1tables |
| [limitless\$1tables](#limitless_tables) | pg\$1tables |
| [limitless\$1table\$1collocations](#limitless_table_collocations) | 없음 |
| [limitless\$1table\$1collocation\$1distributions](#limitless_table_collocation_distributions) | 없음 |
다음 예시에서는 Aurora PostgreSQL Limitless Database 뷰에 대한 세부 정보를 제공합니다. PostgreSQL 뷰에 대한 자세한 내용은 PostgreSQL 설명서에서 [Viewing statistics](https://www.postgresql.org/docs/15/monitoring-stats.html#MONITORING-STATS-VIEWS)을 참조하세요.
**참고**
일부 통계 뷰는 진행 중인 트랜잭션이 있는 경우 일관되지 않은 결과를 반환할 수 있습니다.
**limitless\$1database**
이 뷰에는 DB 샤드 그룹에서 사용 가능한 데이터베이스에 대한 정보가 포함되어 있습니다. 예시:
```
postgres_limitless=> SELECT subcluster_id, subcluster_type, oid, datname, datacl FROM rds_aurora.limitless_database;
subcluster_id | subcluster_type | oid | datname | datacl
---------------+-----------------+-------+--------------------+------------------------------------------------------------------------------------------------------------------------
2 | router | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
2 | router | 5 | postgres |
2 | router | 16384 | rdsadmin | {rdsadmin=CTc/rdsadmin,rds_aurora_limitless_metadata_admin=c/rdsadmin,rds_aurora_limitless_heat_mgmt_admin=c/rdsadmin}
2 | router | 16477 | postgres_limitless |
2 | router | 1 | template1 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
6 | shard | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
```
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(텍스트) - 하위 클러스터의 ID(노드)
+ `subcluster_type`(텍스트) - 하위 클러스터(노드), 라우터 또는 샤드의 유형
나머지 열은 `pg_database`의 열과 동일합니다.
**limitless\$1locks**
이 뷰에는 노드마다 프로세스당 행이 하나씩 포함됩니다. 데이터베이스 서버의 활성 프로세스가 보유한 잠금 정보에 대한 액세스를 제공합니다.
**Example 두 트랜잭션으로 잠금 만들기**
이 예시에서는 두 라우터에서 두 트랜잭션을 동시에 실행합니다.
```
# Transaction 1 (run on router 1)
BEGIN;
SET search_path = public;
SELECT * FROM customers;
INSERT INTO customers VALUES (400,'foo','bar');
# Transaction 2 (run on router 2)
BEGIN;
SET search_path = public;
ALTER TABLE customers ADD COLUMN phone VARCHAR;
```
첫 번째 트랜잭션이 실행됩니다. 후속 트랜잭션은 첫 번째 트랜잭션이 완료될 때까지 기다려야 합니다. 따라서 두 번째 트랜잭션은 잠금으로 차단됩니다. 근본 원인을 확인하기 위해 `limitless_locks`을 `limitless_stat_activity`와 조인하여 명령을 실행합니다.
```
# Run on router 2
SELECT distributed_session_id, state, usename, query, query_start
FROM rds_aurora.limitless_stat_activity
WHERE distributed_session_id in (
SELECT distributed_session_id
FROM rds_aurora.limitless_locks
WHERE relname = 'customers'
);
distributed_session_id | state | usename | query | query_start
------------------------+---------------------+--------------------------+---------------------------------- -------------+-------------------------------
47BDE66E9A5E8477 | idle in transaction | limitless_metadata_admin | INSERT INTO customers VALUES (400,'foo','bar'); | 2023-04-13 17:44:45.152244+00
2AD7F370202D0FA9 | active | limitless_metadata_admin | ALTER TABLE customers ADD COLUMN phone VARCHAR; | 2023-04-13 17:44:55.113388+00
47BDE66E9A5E8477 | | limitless_auth_admin | |
2AD7F370202D0FA9 | | limitless_auth_admin | |
47BDE66E9A5E8477 | | limitless_auth_admin | |
2AD7F370202D0FA9 | | limitless_auth_admin | |
(6 rows)
```
**Example 잠금을 명시적으로 만들기**
이 예시에서는 잠금을 명시적으로 만든 다음 `limitless_locks` 뷰를 사용하여 잠금을 확인합니다(일부 열은 생략됨).
```
BEGIN;
SET search_path = public;
LOCK TABLE customers IN ACCESS SHARE MODE;
SELECT * FROM rds_aurora.limitless_locks WHERE relname = 'customers';
subcluster_id | subcluster_type | distributed_session_id | locktype | datname | relnspname | relname | virtualtransaction | pid | mode
---------------+-----------------+------------------------+----------+--------------------+------------+ ----------+--------------------+-------+-----------------
1 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600787 | 59564 | AccessShareLock
2 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600405 | 67130 | AccessShareLock
3 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 15/473401 | 27735 | AccessShareLock
4 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473524 | 27734 | AccessShareLock
5 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/472935 | 27737 | AccessShareLock
6 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473015 | 48660 | AccessShareLock
(6 rows)
```
**limitless\$1stat\$1activity**
이 뷰에는 노드마다 프로세스당 행이 하나씩 포함됩니다. 이는 전체 시스템 상태를 추적하고 시간이 오래 걸리는 프로세스를 분류하는 데 사용할 수 있습니다. 예시:
```
postgres=# SELECT
subcluster_id,
subcluster_type,
distributed_session_id,
distributed_session_state,
datname,
distributed_query_id,
is_sso_query
FROM
rds_aurora.limitless_stat_activity
WHERE
distributed_session_id in ('D2470C97E3D07E06', '5A3CD7B8E5FD13FF')
order by distributed_session_id;
subcluster_id | subcluster_type | distributed_session_id | distributed_session_state | datname | distributed_query_id | is_sso_query
---------------+-----------------+------------------------+---------------------------+--------------------+----------------------+--------------
2 | router | 5A3CD7B8E5FD13FF | coordinator | postgres_limitless | | f
3 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 |
4 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 |
2 | router | D2470C97E3D07E06 | coordinator | postgres_limitless | | t
3 | shard | D2470C97E3D07E06 | participant | postgres_limitless | 4058400544464210222 |
(5 rows)
```
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `subcluster_type`(text) - 이 프로세스가 속한 하위 클러스터 유형으로, `router` 또는 `shard`입니다.
+ `distributed_session_id`(text) - 이 프로세스가 속한 분산 세션의 ID입니다.
+ `distributed_session_state`(text) - 코디네이터, 참가자 또는 독립 실행형/미분산 프로세스(`NULL`로 표시됨) 중 무엇인지를 나타냅니다.
+ `datname`(text) - 이 프로세스가 연결된 데이터베이스입니다.
+ `distributed_query_id`(bigint) - 코디네이터 노드에서 상위 쿼리의 쿼리 ID입니다. 이 열은 상위 쿼리인 경우 `NULL`입니다. 코디네이터 노드는 분산 쿼리 ID를 참가자 노드로 푸시다운합니다. 따라서 참가자 노드의 경우 분산 쿼리 ID와 쿼리 ID의 값이 다릅니다.
+ `is_sso_query`(text) - 쿼리가 단일 샤드에 최적화되었는지, 아닌지를 알려줍니다.
나머지 열은 `pg_stat_activity`의 열과 동일합니다.
**limitless\$1stat\$1all\$1indexes**
이 뷰에는 DB 샤드 그룹의 인덱스에 대한 사용량 통계가 포함되어 있습니다. 예시:
```
postgres_limitless=> SELECT schemaname, relname, indexrelname, idx_scan
FROM rds_aurora.limitless_stat_all_indexes
WHERE relname LIKE 'orders_ts%' ORDER BY indexrelname LIMIT 10;
schemaname | relname | indexrelname | idx_scan
------------+----------------+---------------------+----------
ec_sample | orders_ts00001 | orders_ts00001_pkey | 196801
ec_sample | orders_ts00002 | orders_ts00002_pkey | 196703
ec_sample | orders_ts00003 | orders_ts00003_pkey | 196376
ec_sample | orders_ts00004 | orders_ts00004_pkey | 197966
ec_sample | orders_ts00005 | orders_ts00005_pkey | 195301
ec_sample | orders_ts00006 | orders_ts00006_pkey | 195673
ec_sample | orders_ts00007 | orders_ts00007_pkey | 194475
ec_sample | orders_ts00008 | orders_ts00008_pkey | 191694
ec_sample | orders_ts00009 | orders_ts00009_pkey | 193744
ec_sample | orders_ts00010 | orders_ts00010_pkey | 195421
(10 rows)
```
**limitless\$1stat\$1all\$1tables**
이 뷰에는 DB 샤드 그룹의 현재 데이터베이스에 있는 모든 테이블에 대한 통계가 포함되어 있습니다. 이는 vacuum 작업 및 데이터 조작 언어(DML) 작업을 추적할 때 유용합니다. 예시:
```
postgres_limitless=> SELECT subcluster_id, subcluster_type, relname, n_ins_since_vacuum, n_tup_ins, last_vacuum
FROM rds_aurora.limitless_stat_all_tables
WHERE relname LIKE 'orders_ts%' ORDER BY relname LIMIT 10;
subcluster_id | subcluster_type | relname | n_ins_since_vacuum | n_tup_ins | last_vacuum
---------------+-----------------+----------------+--------------------+-----------+-------------
5 | shard | orders_ts00001 | 34779 | 196083 |
5 | shard | orders_ts00002 | 34632 | 194721 |
5 | shard | orders_ts00003 | 34950 | 195965 |
5 | shard | orders_ts00004 | 34745 | 197283 |
5 | shard | orders_ts00005 | 34879 | 195754 |
5 | shard | orders_ts00006 | 34340 | 194605 |
5 | shard | orders_ts00007 | 33779 | 192203 |
5 | shard | orders_ts00008 | 33826 | 191293 |
5 | shard | orders_ts00009 | 34660 | 194117 |
5 | shard | orders_ts00010 | 34569 | 195560 |
(10 rows)
```
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `subcluster_type`(text) - 이 프로세스가 속한 하위 클러스터 유형으로, `router` 또는 `shard`입니다.
+ `relname`(name) - 테이블의 이름입니다.
나머지 열은 `pg_stat_all_tables`의 열과 동일합니다.
**limitless\$1stat\$1database**
이 뷰에는 DB 샤드 그룹의 모든 데이터베이스에 대한 통계가 포함되어 있습니다. 노드마다 데이터베이스당 행 하나를 반환합니다. 예시:
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
datname,
blks_read,
blks_hit
FROM
rds_aurora.limitless_stat_database
WHERE
datname='postgres_limitless';
subcluster_id | subcluster_type | datname | blks_read | blks_hit
---------------+-----------------+--------------------+-----------+----------
1 | router | postgres_limitless | 484 | 34371314
2 | router | postgres_limitless | 673 | 33859317
3 | shard | postgres_limitless | 1299 | 17749550
4 | shard | postgres_limitless | 1094 | 17492849
5 | shard | postgres_limitless | 1036 | 17485098
6 | shard | postgres_limitless | 1040 | 17437257
(6 rows)
```
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `subcluster_type`(text) - 이 프로세스가 속한 하위 클러스터 유형으로, `router` 또는 `shard`입니다.
+ `datname`(name) - 데이터베이스의 이름입니다.
나머지 열은 `pg_stat_database`의 열과 동일합니다.
**limitless\$1stat\$1progress\$1vacuum**
이 뷰에는 지속적 vacuum 작업에 대한 정보가 포함되어 있습니다. 예시:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;
-[ RECORD 1 ]----------+------------------
subcluster_id | 3
subcluster_type | shard
distributed_session_id | A56D96E2A5C9F426
pid | 5270
datname | postgres
nspname | public
relname | customer_ts2
phase | vacuuming heap
heap_blks_total | 130500
heap_blks_scanned | 100036
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 11184810
num_dead_tuples | 0
-[ RECORD 2 ]----------+------------------
subcluster_id | 3
subcluster_type | shard
distributed_session_id | 56DF26A89EC23AB5
pid | 6854
datname | postgres
nspname | public
relname | sales_ts1
phase | vacuuming heap
heap_blks_total | 43058
heap_blks_scanned | 24868
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 8569523
num_dead_tuples | 0
```
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `subcluster_type`(text) - 이 프로세스가 속한 하위 클러스터 유형으로, `router` 또는 `shard`입니다.
+ `distributed_session_id`(text) - Vacuum 작업을 시작한 세션의 식별자입니다.
+ `datname`(name) - Vacuum이 수행되는 데이터베이스입니다.
+ `nspname`(name) - Vacuum이 진행 중인 테이블의 스키마 이름입니다. Vacuum이 진행 중인 테이블이 사용자가 연결된 테이블과 동일한 데이터베이스에 있지 않은 경우 `null`입니다.
+ `relname`(name) - Vacuum이 진행 중인 테이블의 이름입니다. Vacuum이 진행 중인 테이블이 사용자가 연결된 테이블과 동일한 데이터베이스에 있지 않은 경우 `null`입니다.
나머지 열은 `pg_stat_progress_vacuum`의 열과 동일합니다.
**limitless\$1stat\$1statements**
이 뷰는 모든 노드에서 실행되는 모든 SQL 문에 대한 계획 및 실행 통계를 추적하는 수단을 제공합니다.
`limitless_stat_statements` 뷰를 사용하려면 [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) 확장을 설치해야 합니다.
```
-- CREATE EXTENSION must be run by a superuser
CREATE EXTENSION pg_stat_statements;
-- Verify that the extension is created on all nodes in the DB shard group
SELECT distinct node_id
FROM rds_aurora.limitless_stat_statements
LIMIT 10;
```
다음 예시는 `limitless_stat_statements` 뷰 사용을 보여 줍니다.
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
distributedqueryid,
username,
dbname,
sso_calls
FROM
rds_aurora.limitless_stat_statements;
subcluster_id | subcluster_type | distributedqueryid | username | dbname | sso_calls
---------------+-----------------+----------------------+-------------------------------------+--------------------+-----------
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 1
3 | shard | -7975178695405682176 | postgres | postgres_limitless |
[...]
```
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
+ `subcluster_type`(text) - 이 프로세스가 속한 하위 클러스터 유형으로, `router` 또는 `shard`입니다.
+ `distributedqueryid`(bigint) - 코디네이터 노드에서 상위 쿼리의 쿼리 ID입니다. 이 열은 상위 쿼리인 경우 `NULL`입니다. 코디네이터 노드는 분산 쿼리 ID를 참가자 노드로 푸시다운합니다. 따라서 참가자 노드의 경우 분산 쿼리 ID와 쿼리 ID의 값이 다릅니다.
+ `username`(name) - 문을 쿼리한 사용자입니다.
+ `dbname`(name) - 쿼리가 실행된 데이터베이스입니다.
+ `sso_calls`(name) - 문이 단일 샤드에 최적화된 횟수입니다.
나머지 열은 [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)와 동일합니다.
**limitless\$1stat\$1statements\$1info**
이 뷰에는 `limitless_stat_statements` 뷰에 대한 통계가 포함되어 있습니다. 각 행에는 각 노드의 [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7) 뷰에 대한 데이터가 포함되어 있습니다. `subcluster_id` 열은 각 노드를 식별합니다.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_statements_info;
subcluster_id | subcluster_type | dealloc | stats_reset
---------------+-----------------+---------+-------------------------------
1 | router | 0 | 2023-06-30 21:22:09.524781+00
2 | router | 0 | 2023-06-30 21:21:40.834111+00
3 | shard | 0 | 2023-06-30 21:22:10.709942+00
4 | shard | 0 | 2023-06-30 21:22:10.740179+00
5 | shard | 0 | 2023-06-30 21:22:10.774282+00
6 | shard | 0 | 2023-06-30 21:22:10.808267+00
(6 rows)
```
출력 파라미터는 다음과 같습니다.
+ `subcluster_id`(text) - 이 프로세스가 속한 하위 클러스터의 ID입니다.
나머지 열은 [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7)와 동일합니다.
**limitless\$1stat\$1subclusters**
이 뷰에는 라우터와 다른 노드 간의 네트워크 통계가 포함되어 있습니다. 여기에는 라우터 및 기타 노드 페어당 행이 포함됩니다. 예를 들면 다음과 같습니다.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_subclusters;
orig_subcluster | orig_instance_az | dest_subcluster | dest_instance_az | latency_us | latest_collection | failed_requests | received_bytes | sent_bytes | same_az_requests | cross_az_requests | stat_reset_timestamp
-----------------+------------------+-----------------+------------------+------------+-------------------------------+-----------------+----------------+------------+------------------+-------------------+-------------------------------
3 | us-west-2b | 2 | us-west-2a | 847 | 2024-10-07 17:25:39.518617+00 | 0 | 35668633 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.239675+00
3 | us-west-2b | 4 | us-west-2b | 419 | 2024-10-07 17:25:39.546376+00 | 0 | 101190464 | 248795719 | 883478 | 0 | 2024-10-05 12:39:55.231218+00
3 | us-west-2b | 5 | us-west-2c | 1396 | 2024-10-07 17:25:39.52122+00 | 0 | 72864849 | 172086292 | 0 | 557726 | 2024-10-05 12:39:55.196412+00
3 | us-west-2b | 6 | us-west-2c | 729 | 2024-10-07 17:25:39.54828+00 | 0 | 35668584 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.247334+00
3 | us-west-2b | 7 | us-west-2a | 1702 | 2024-10-07 17:25:39.545307+00 | 0 | 71699576 | 171634844 | 0 | 556278 | 2024-10-05 12:39:52.715168+00
2 | us-west-2a | 3 | us-west-2b | 868 | 2024-10-07 17:25:40.293927+00 | 0 | 35659611 | 92011872 | 0 | 302817 | 2024-10-05 12:39:54.420758+00
2 | us-west-2a | 4 | us-west-2b | 786 | 2024-10-07 17:25:40.296863+00 | 0 | 102437253 | 251838024 | 0 | 895060 | 2024-10-05 12:39:54.404081+00
2 | us-west-2a | 5 | us-west-2c | 1232 | 2024-10-07 17:25:40.292021+00 | 0 | 71990027 | 168828110 | 0 | 545453 | 2024-10-05 12:39:36.769549+00
```
출력 파라미터는 다음과 같습니다.
+ `orig_subcluster`(text) - 통신이 시작되는 라우터의 ID입니다.
+ `orig_subcluster_az`(text) - 발신자 라우터의 가용 영역(AZ)입니다.
+ `dest_subcluster`(text) - 대상 노드의 ID입니다.
+ `dest_subcluster_az`(text) - 대상 노드의 마지막으로 수집된 AZ입니다.
+ `latency_us`(bigint) - 노드 간에 마지막으로 수집된 네트워크 지연 시간으로, 마이크로초 단위입니다. 노드에 연결할 수 없는 경우 값은 `0`입니다.
+ `latest_collection`(timestamp) - 대상 노드의 최신 AZ 및 지연 시간 모음의 타임스탬프입니다.
+ `failed_requests`(bigint) - 실패한 내부 요청의 누적 수입니다.
+ `received_bytes`(bigint) - 이 노드에서 수신된 예상 누적 바이트 수입니다.
+ `sent_bytes`(bigint) - 이 노드로 전송된 예상 누적 바이트 수입니다.
+ `same_az_requests`(bigint) - 이 노드가 발신자 라우터와 동일한 AZ에 있는 경우 이 노드에 대한 내부 DB 요청의 누적 수입니다.
+ `cross_az_requests`(bigint) - 이 노드가 발신자 라우터와 다른 AZ에 있을 때 이 노드에 대한 내부 DB 요청의 누적 수입니다.
+ `stat_reset_timestamp`(timestamp) - 이 뷰의 누적 통계가 마지막으로 재설정된 시점의 타임스탬프입니다.
**limitless\$1statio\$1all\$1indexes**
이 뷰에는 DB 샤드 그룹의 모든 인덱스에 대한 입출력(I/O) 통계가 포함되어 있습니다. 예시:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_statio_all_indexes WHERE relname like'customers_ts%';
subcluster_id | subcluster_type | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit
---------------+-----------------+------------+-------------------+-------------------------------------+ --------------+--------------
3 | shard | public | customers_ts00002 | customers_ts00002_customer_name_idx | 1 | 0
3 | shard | public | customers_ts00001 | customers_ts00001_customer_name_idx | 1 | 0
4 | shard | public | customers_ts00003 | customers_ts00003_customer_name_idx | 1 | 0
4 | shard | public | customers_ts00004 | customers_ts00004_customer_name_idx | 1 | 0
5 | shard | public | customers_ts00005 | customers_ts00005_customer_name_idx | 1 | 0
5 | shard | public | customers_ts00006 | customers_ts00006_customer_name_idx | 1 | 0
6 | shard | public | customers_ts00007 | customers_ts00007_customer_name_idx | 1 | 0
6 | shard | public | customers_ts00008 | customers_ts00008_customer_name_idx | 1 | 0
(8 rows)
```
**limitless\$1statio\$1all\$1tables**
이 뷰에는 DB 샤드 그룹의 모든 테이블에 대한 입출력(I/O) 통계가 포함되어 있습니다. 예시:
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
schemaname,
relname,
heap_blks_read,
heap_blks_hit
FROM
rds_aurora.limitless_statio_all_tables
WHERE
relname LIKE 'customers_ts%';
subcluster_id | subcluster_type | schemaname | relname | heap_blks_read | heap_blks_hit
---------------+-----------------+------------+-------------------+----------------+---------------
3 | shard | public | customers_ts00002 | 305 | 57780
3 | shard | public | customers_ts00001 | 300 | 56972
4 | shard | public | customers_ts00004 | 302 | 57291
4 | shard | public | customers_ts00003 | 302 | 57178
5 | shard | public | customers_ts00006 | 300 | 56932
5 | shard | public | customers_ts00005 | 302 | 57386
6 | shard | public | customers_ts00008 | 300 | 56881
6 | shard | public | customers_ts00007 | 304 | 57635
(8 rows)
```
**limitless\$1tables**
이 뷰에는 Aurora PostgreSQL Limitless Database의 테이블에 대한 정보가 포함되어 있습니다.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables;
table_gid | local_oid | schema_name | table_name | table_status | table_type | distribution_key
-----------+-----------+-------------+-------------+--------------+-------------+------------------
5 | 18635 | public | placeholder | active | placeholder |
6 | 18641 | public | ref | active | reference |
7 | 18797 | public | orders | active | sharded | HASH (order_id)
2 | 18579 | public | customer | active | sharded | HASH (cust_id)
(4 rows)
```
**limitless\$1table\$1collocations**
이 뷰에는 공동 배치된 샤딩된 테이블에 대한 정보가 포함되어 있습니다.
다음 예시에서는 `orders` 및 `customers` 테이블이 공동 배치되고 `users` 및 `followers` 테이블이 공동 배치됩니다. 공동 배치된 테이블은 `collocation_id`가 같습니다.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocations ORDER BY collocation_id;
collocation_id | schema_name | table_name
----------------+-------------+------------
2 | public | orders
2 | public | customers
5 | public | users
5 | public | followers
(4 rows)
```
**limitless\$1table\$1collocation\$1distributions**
이 뷰는 각 공동 배치의 키 분배를 보여줍니다.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocation_distributions ORDER BY collocation_id, lower_bound;
collocation_id | subcluster_id | lower_bound | upper_bound
----------------+---------------+----------------------+----------------------
2 | 6 | -9223372036854775808 | -4611686018427387904
2 | 5 | -4611686018427387904 | 0
2 | 4 | 0 | 4611686018427387904
2 | 3 | 4611686018427387904 | 9223372036854775807
5 | 6 | -9223372036854775808 | -4611686018427387904
5 | 5 | -4611686018427387904 | 0
5 | 4 | 0 | 4611686018427387904
5 | 3 | 4611686018427387904 | 9223372036854775807
(8 rows)
```
# Aurora PostgreSQL Limitless Database의 대기 이벤트
Aurora PostgreSQL의 대기 이벤트는 입출력(I/O) 및 잠금과 같이 세션이 대기 중인 리소스를 나타냅니다. 대기 이벤트는 세션이 리소스를 기다리는 이유를 파악하고 병목 현상을 식별하는 데 유용합니다. 자세한 내용은 [Aurora PostgreSQL 대기 이벤트](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.waits) 단원을 참조하십시오.
Aurora PostgreSQL Limitless Database에는 라우터 및 샤드와 관련된 자체 대기 이벤트가 있습니다. 이 중 대부분은 작업을 완료하기 위해 샤드에서 기다리는 라우터를 위한 것입니다. 샤드 대기 이벤트에는 수행 중인 작업에 대한 세부 정보가 포함됩니다.
**Topics**
+ [대기 이벤트 쿼리](#limitless-monitoring-waits.query)
+ [Limitless Database 대기 이벤트](limitless-waits-reference.md)
## 대기 이벤트 쿼리
다음 예시와 같이 [limitless\$1stat\$1activity](limitless-monitoring-views.md#limitless_stat_activity) 뷰를 사용하여 대기 이벤트를 쿼리할 수 있습니다.
```
SELECT wait_event FROM rds_aurora.limitless_stat_activity WHERE wait_event_type='AuroraLimitless';
wait_event
----------------------
RemoteStatementSetup
RemoteStatementSetup
(2 rows)
```
다음 예시와 같이 `aurora_stat_system_waits` 함수를 사용하여 각 대기 이벤트의 대기 수와 소요된 총 시간을 나열할 수도 있습니다.
```
postgres_limitless=> SELECT type_name,event_name,waits,wait_time
FROM aurora_stat_system_waits()
NATURAL JOIN aurora_stat_wait_event()
NATURAL JOIN aurora_stat_wait_type()
WHERE type_name='AuroraLimitless'
ORDER BY wait_time DESC;
type_name | event_name | waits | wait_time
-----------------+---------------------------+---------+-------------
AuroraLimitless | RemoteStatementSetup | 7518 | 75236507897
AuroraLimitless | RemoteStatementExecution | 40 | 132986
AuroraLimitless | Connect | 5 | 1453
(3 rows)
```
# Limitless Database 대기 이벤트
다음 대기 이벤트는 Aurora PostgreSQL Limitless Database에 적용됩니다. 이러한 대기 이벤트를 모니터링하여 Aurora PostgreSQL Limitless Database 처리의 병목 현상을 식별할 수 있습니다.
**Topics**
+ [IO:TwophaseFilePoolWrite 대기 이벤트](#limitless-waits-TwophaseFilePoolWrite)
+ [IO:TwophaseFilePoolRead 대기 이벤트](#limitless-waits-TwophaseFilePoolRead)
+ [AuroraLimitless:Connect 대기 이벤트](#limitless-waits-Connect)
+ [AuroraLimitless:AsyncConnect 대기 이벤트](#limitless-waits-AsyncConnect)
+ [AuroraLimitless:RemoteStatementSetup 대기 이벤트](#limitless-waits-RemoteStatementSetup)
+ [AuroraLimitless:RemoteDDLExecution 대기 이벤트](#limitless-waits-RemoteDDLExecution)
+ [AuroraLimitless:RemoteStatementExecution 대기 이벤트](#limitless-waits-RemoteStatementExecution)
+ [AuroraLimitless:FetchRemoteResults 대기 이벤트](#limitless-waits-FetchRemoteResults)
+ [AuroraLimitless:AsyncGetInitialResponse 대기 이벤트](#limitless-waits-AsyncGetInitialResponse)
+ [AuroraLimitless:AsyncGetNextResponse 대기 이벤트](#limitless-waits-AsyncGetNextResponse)
+ [AuroraLimitless:AbortedCommandCleanup 대기 이벤트](#limitless-waits-AbortedCommandCleanup)
+ [AuroraLimitless:DistributedCommitPrepare 대기 이벤트](#limitless-waits-DistributedCommitPrepare)
+ [AuroraLimitless:DistributedCommit 대기 이벤트](#limitless-waits-DistributedCommit)
+ [AuroraLimitless:DistributedCommitPrepareThrottle 대기 이벤트](#limitless-waits-DistributedCommitPrepareThrottle)
+ [AuroraLimitless:PreparedTransactionResolution 대기 이벤트](#limitless-waits-PreparedTransactionResolution)
+ [AuroraLimitless:SendPreparedTransactionOutcome 대기 이벤트](#limitless-waits-SendPreparedTransactionOutcome)
+ [AuroraLimitless:CommitClockBarrier 대기 이벤트](#limitless-waits-CommitClockBarrier)
+ [AuroraLimitless:SnapshotClockBarrier 대기 이벤트](#limitless-waits-SnapshotClockBarrier)
+ [AuroraLimitless:ReaderSnapshotClockBarrier 대기 이벤트](#limitless-waits-ReaderSnapshotClockBarrier)
+ [AuroraLimitless:GatherDistributedDeadlockGraph 대기 이벤트](#limitless-waits-GatherDistributedDeadlockGraph)
+ [AuroraLimitless:DistributedDeadlockDetection 대기 이벤트](#limitless-waits-DistributedDeadlockDetection)
+ [AuroraLimitless:DistributedDeadlockAbort 대기 이벤트](#limitless-waits-DistributedDeadlockAbort)
+ [AuroraLimitless:GatherRemoteStats 대기 이벤트](#limitless-waits-GatherRemoteStats)
+ [AuroraLimitless:GlobalSequenceRefresh 대기 이벤트](#limitless-waits-GlobalSequenceRefresh)
+ [AuroraLimitless:GlobalVacuumTimeExchange 대기 이벤트](#limitless-waits-GlobalVacuumTimeExchange)
+ [AuroraLimitless:DistributedTransactionMonitorGather 대기 이벤트](#limitless-waits-DistributedTransactionMonitorGather)
+ [AuroraLimitlessActivity:AdminTaskSchedulerMain 대기 이벤트](#limitless-waits-AdminTaskSchedulerMain)
+ [AuroraLimitlessActivity:AdminTaskExecutorMain 대기 이벤트](#limitless-waits-AdminTaskExecutorMain)
+ [AuroraLimitlessActivity:AdminTaskMonitorMain 대기 이벤트](#limitless-waits-AdminTaskMonitorMain)
+ [AuroraLimitlessActivity:DatabaseCleanupMonitorMain 대기 이벤트](#limitless-waits-DatabaseCleanupMonitorMain)
+ [AuroraLimitlessActivity:TopologyCleanupMonitorMain 대기 이벤트](#limitless-waits-TopologyCleanupMonitorMain)
+ [AuroraLimitlessActivity:ToplogyChangeMonitorMain 대기 이벤트](#limitless-waits-ToplogyChangeMonitorMain)
+ [AuroraLimitlessActivity:DistributedTransactionMonitorMain 대기 이벤트](#limitless-waits-DistributedTransactionMonitorMain)
+ [AuroraLimitlessActivity:GlobalVacuumMonitorMain 대기 이벤트](#limitless-waits-GlobalVacuumMonitorMain)
## IO:TwophaseFilePoolWrite 대기 이벤트
두 단계 상태 파일 풀 내에서 두 단계 상태 파일의 쓰기를 기다리는 중입니다. 이는 Aurora 전용 이벤트입니다.
### 원인
Limitless Database 분산 트랜잭션의 참가자를 포함하여 `PREPARED TRANSACTION` 명령을 실행하는 프로세스는 두 단계 파일에서 트랜잭션 상태를 유지해야 합니다. Aurora는 파일 풀을 사용하여 이 작업의 성능을 개선합니다.
### 작업
이 작업은 동기식 쓰기 I/O 작업이므로 이 이벤트에서 지연 시간이 높으면 `IO:XactSync`와 원인이 유사하며 동일한 방식으로 조사할 수 있습니다. Limitless Database를 사용하는 경우 실행 중인 분산 트랜잭션 수를 줄여야 할 수 있습니다.
## IO:TwophaseFilePoolRead 대기 이벤트
두 단계 상태 파일 풀 내에서 두 단계 상태 파일의 읽기를 기다리는 중입니다.
### 원인
Limitless Database 분산 트랜잭션의 참가자를 포함하여 이전에 준비된 트랜잭션에 대해 `COMMIT PREPARED` 명령을 실행하는 프로세스는 두 단계 파일에서 이전에 지속된 트랜잭션 상태를 읽어야 할 수 있습니다. Aurora는 파일 풀을 사용하여 이 작업의 성능을 개선합니다.
### 작업
읽기 I/O 작업입니다. 따라서 이 이벤트에서 지연 시간이 높으면 `IO:DataFileRead`와 원인이 유사하며 동일한 방식으로 조사할 수 있습니다. Limitless Database를 사용하는 경우 실행 중인 분산 트랜잭션 수를 줄여야 할 수 있습니다.
## AuroraLimitless:Connect 대기 이벤트
프로세스가 클러스터의 다른 노드에 대한 연결이 설정되기를 기다리고 있습니다.
### 원인
쿼리, 분산 트랜잭션을 실행하고 DDL을 수행하기 위해 프로세스와 원격 노드 간에 연결이 설정됩니다.
### 작업
클러스터에 대한 동시 연결 수를 줄이거나 교차 샤드 쿼리 사용을 조정합니다.
## AuroraLimitless:AsyncConnect 대기 이벤트
이 이벤트는 `Connect`와 유사하지만 노드 세트에 대한 병렬 연결이 설정되기를 기다리는 프로세스를 나타냅니다.
### 원인
병렬 연결 설정은 DDL 문을 실행할 때 가장 일반적으로 수행됩니다.
### 작업
DDL 문 수를 줄이거나 동일한 세션에서 여러 DDL을 결합하여 연결 재사용을 개선합니다.
## AuroraLimitless:RemoteStatementSetup 대기 이벤트
프로세스가 커서 열기, 닫기 또는 준비된 문 만들기와 같은 원격 쿼리 실행 설정을 기다리고 있습니다.
### 원인
이 대기 이벤트는 문을 단일 샤드 최적화할 수 없는 샤딩된 테이블의 스캔 수에 따라 증가합니다.
### 작업
쿼리를 최적화하여 스캔 작업 수를 줄이거나 단일 샤드 최적화에 대한 자격을 높입니다.
## AuroraLimitless:RemoteDDLExecution 대기 이벤트
프로세스가 원격 DDL 명령이 완료되기를 기다리고 있습니다.
### 원인
DB 샤드 그룹에서 DDL 명령을 실행할 때는 작업을 확인하기 전에 다른 라우터 및 샤드 노드에 DDL 명령을 배포해야 합니다. 일부 DDL 작업은 스키마 변경에 맞게 데이터를 조정해야 하므로 장기간 실행될 수 있습니다.
### 작업
최적화를 위해 장기 실행 DDL 명령을 식별합니다.
## AuroraLimitless:RemoteStatementExecution 대기 이벤트
프로세스가 원격 명령이 완료되기를 기다리고 있습니다.
### 원인
SQL 명령이 원격 노드에서 실행 중입니다. 이 이벤트는 `auto_analyze` 및 하트비트 검사와 같은 내부 통신에 자주 표시됩니다.
### 작업
limitless\$1stat\$1statements 뷰를 사용하여 장기 실행 명령을 식별합니다. 대부분의 경우 이는 특히 백그라운드 작업자 또는 내부 프로세스에서 예상되는 이벤트이며 조치가 필요하지 않습니다.
## AuroraLimitless:FetchRemoteResults 대기 이벤트
프로세스가 원격 노드에서 행을 검색하기 위해 기다리고 있습니다.
### 원인
이 대기 이벤트는 샤딩된 테이블 또는 참조 테이블과 같은 원격 테이블에서 많은 수의 행을 가져올 때 증가할 수 있습니다.
### 작업
`limitless_stat_statements` 뷰를 사용하여 최적화되지 않은 `SELECT` 쿼리를 식별합니다. 필요한 데이터만 검색하도록 쿼리를 최적화합니다. `rds_aurora.limitless_maximum_adaptive_fetch_size` 파라미터를 조정할 수도 있습니다.
## AuroraLimitless:AsyncGetInitialResponse 대기 이벤트
프로세스가 쿼리 실행에 파이프라인 모드가 사용될 때 초기 응답을 기다리고 있습니다.
### 원인
이는 일반적으로 단일 샤드 데이터 배치를 사용하는 쿼리에 대한 샤드 실행을 라우터 중에 볼 수 있으며 정상적인 실행에서 예상되는 부분입니다.
### 작업
추가 조치가 필요하지 않습니다.
## AuroraLimitless:AsyncGetNextResponse 대기 이벤트
프로세스가 쿼리 실행에 파이프라인 모드를 사용할 때 추가 응답을 기다리고 있습니다.
### 원인
이는 일반적으로 단일 샤드 데이터 배치를 사용하는 쿼리에 대한 샤드 실행을 라우터 중에 볼 수 있으며 정상적인 실행에서 예상되는 부분입니다.
### 작업
추가 조치가 필요하지 않습니다.
## AuroraLimitless:AbortedCommandCleanup 대기 이벤트
프로세스가 원격 정리 쿼리의 결과를 기다리고 있습니다. 정리 쿼리는 분산 트랜잭션이 종료될 때 적절한 상태로 반환하기 위해 샤드 노드에 발급됩니다.
### 원인
트랜잭션 정리는 오류가 발견되었거나 사용자가 명시적 ABORT 명령을 실행했거나 실행 중인 쿼리를 취소했기 때문에 트랜잭션이 중단될 때 수행됩니다.
### 작업
트랜잭션이 취소되는 원인을 조사합니다.
## AuroraLimitless:DistributedCommitPrepare 대기 이벤트
프로세스가 분산 트랜잭션을 커밋하고 있으며 모든 참가자가 준비 명령을 승인하기를 기다리고 있습니다.
### 원인
여러 노드를 수정하는 트랜잭션은 분산 커밋을 수행해야 합니다. 참여 노드의 `IO:TwophaseFilePoolWrite` 이벤트에서 대기 시간이 길면 `DistributedCommitPrepare`의 대기 시간이 길어질 수 있습니다.
### 작업
여러 노드의 데이터를 수정하는 트랜잭션 수를 줄입니다. 클러스터의 다른 노드에서 `IO:TwophaseFilePoolWrite` 이벤트를 조사합니다.
## AuroraLimitless:DistributedCommit 대기 이벤트
프로세스가 분산 트랜잭션을 커밋하고 있으며 리드 참가자가 커밋 명령을 승인하기를 기다리고 있습니다.
### 원인
여러 노드를 수정하는 트랜잭션은 분산 커밋을 수행해야 합니다. 리드 참가자의 `IO:XactSync` 이벤트에서 대기 시간이 길면 `DistributedCommit`의 대기 시간이 길어질 수 있습니다.
### 작업
여러 노드의 데이터를 수정하는 트랜잭션 수를 줄입니다. 클러스터의 다른 노드에서 `IO:XactSync` 이벤트를 조사합니다.
## AuroraLimitless:DistributedCommitPrepareThrottle 대기 이벤트
프로세스가 분산 트랜잭션을 준비하려고 시도하고 있으며 기존 준비된 트랜잭션으로 인해 스로틀링되고 있습니다.
### 원인
여러 노드를 수정하는 트랜잭션은 분산 커밋을 수행해야 합니다. 이러한 트랜잭션의 참가자는 커밋 프로토콜의 일부로 준비 작업을 수행해야 합니다. Aurora는 동시 준비 수를 제한하며, 이 한도를 초과하면 프로세스가 `DistributedCommitPrepareThrottle` 이벤트에서 대기합니다.
### 작업
여러 노드의 데이터를 수정하는 트랜잭션 수를 줄입니다. `IO:TwophaseFilePoolWrite` 이벤트에서 시간이 길어지면 기존에 준비된 트랜잭션이 누적되어 새 준비 시도에 대한 스로틀링이 발생할 수 있으므로 해당 이벤트를 조사합니다.
## AuroraLimitless:PreparedTransactionResolution 대기 이벤트
프로세스가 준비된 상태의 분산 트랜잭션에 의해 수정된 튜플을 발견했습니다. 프로세스는 분산 트랜잭션이 스냅샷에 표시되는지 확인해야 합니다.
### 원인
여러 노드를 수정하는 트랜잭션은 준비 단계가 포함된 분산 커밋을 수행해야 합니다. 분산 트랜잭션 수가 많거나 분산 커밋에서 지연 시간이 증가하면 다른 프로세스에서 `PreparedTransactionResolution` 대기 이벤트가 발생할 수 있습니다.
### 작업
여러 노드의 데이터를 수정하는 트랜잭션 수를 줄입니다. 분산 커밋 관련 이벤트의 시간이 증가하면 분산 트랜잭션의 커밋 경로에서 지연 시간이 증가할 수 있으므로 해당 이벤트를 조사합니다. 네트워크 및 CPU 로드를 조사할 수도 있습니다.
## AuroraLimitless:SendPreparedTransactionOutcome 대기 이벤트
프로세스가 분산 트랜잭션을 조정하는 노드에서 실행 중이고 다른 프로세스가 해당 트랜잭션의 상태에 대해 문의했거나 프로세스가 분산 트랜잭션을 커밋하여 참가자에게 결과를 보내고 있습니다.
### 원인
`PreparedTransactionResolution` 대기 이벤트가 발생하는 프로세스는 트랜잭션 코디네이터를 쿼리합니다. 트랜잭션 코디네이터에 대한 응답은 SendPreparedTransactionOutcome이 발생합니다.
### 작업
여러 노드의 데이터를 수정하는 트랜잭션 수를 줄입니다. 분산 커밋 관련 이벤트와 `IO:TwophaseFilePoolWrite` 및 `IO:TwophaseFilePoolRead` 이벤트의 시간이 증가하면 분산 트랜잭션의 커밋 경로에서 지연 시간이 증가할 수 있으므로 해당 이벤트를 조사합니다. 네트워크 및 CPU 로드를 조사할 수도 있습니다.
## AuroraLimitless:CommitClockBarrier 대기 이벤트
프로세스가 트랜잭션을 커밋하고 있으며 클러스터의 모든 노드에 대해 할당된 커밋 시간이 과거가 되도록 기다려야 합니다.
### 원인
CPU 또는 네트워크 포화로 인해 클럭 드리프트가 증가하여 이 대기 이벤트에서 소요된 시간이 늘어날 수 있습니다.
### 작업
클러스터에서 CPU 또는 네트워크 포화를 조사합니다.
## AuroraLimitless:SnapshotClockBarrier 대기 이벤트
프로세스가 미래의 클럭이 있는 다른 노드에서 스냅샷 시간을 수신했으며 자체 클럭이 해당 시간에 도달하기를 기다리고 있습니다.
### 원인
이는 일반적으로 프로세스가 샤드로 푸시다운된 함수의 결과를 수신했고 노드 간에 클럭 드리프트가 있으면 발생합니다. CPU 또는 네트워크 포화로 인해 클럭 드리프트가 증가하여 이 대기 이벤트에서 소요된 시간이 늘어날 수 있습니다.
### 작업
클러스터에서 CPU 또는 네트워크 상태를 조사합니다.
## AuroraLimitless:ReaderSnapshotClockBarrier 대기 이벤트
이 이벤트는 읽기 노드에서 발생합니다. 프로세스가 프로세스 스냅샷 시간이 적용되기 전에 발생한 모든 쓰기가 적용되도록 읽기 노드가 쓰기 스트림을 다시 재생하기를 기다리고 있습니다.
### 원인
Aurora 복제본 지연이 증가하면 이 이벤트에서 대기 시간이 늘어날 수 있습니다.
### 작업
Aurora 복제본 지연을 조사합니다.
## AuroraLimitless:GatherDistributedDeadlockGraph 대기 이벤트
프로세스가 분산 교착 상태 감지의 일부로 잠금 그래프를 수집하기 위해 다른 노드와 통신하고 있습니다.
### 원인
프로세스가 잠금을 기다리고 있는 경우 `rds_aurora.limitless_distributed_deadlock_timeout`보다 오래 기다린 후 분산 교착 상태 확인을 수행합니다.
### 작업
애플리케이션에서 잠금 경합의 원인을 조사하고 `rds_aurora.limitless_distributed_deadlock_timeout` 조정을 고려합니다.
## AuroraLimitless:DistributedDeadlockDetection 대기 이벤트
프로세스가 분산 교착 상태를 감지하기 위해 다른 노드와 통신하고 있습니다.
### 원인
프로세스가 잠금을 기다리고 있는 경우 `rds_aurora.limitless_distributed_deadlock_timeout`보다 오래 기다린 후 분산 교착 상태 확인을 수행합니다.
### 작업
애플리케이션에서 잠금 경합의 원인을 조사하고 `rds_aurora.limitless_distributed_deadlock_timeout` 조정을 고려합니다.
## AuroraLimitless:DistributedDeadlockAbort 대기 이벤트
프로세스가 분산 교착 상태의 피해자로 선택된 세션을 중단하기 위해 다른 노드와 통신하고 있습니다.
### 원인
애플리케이션 패턴으로 인해 분산 교착 상태가 발생합니다.
### 작업
분산 교착 상태를 초래하는 애플리케이션 패턴을 조사합니다.
## AuroraLimitless:GatherRemoteStats 대기 이벤트
프로세스가 클러스터의 다른 노드에서 통계를 수집하고 있습니다.
### 원인
`limitless_stat_activity`와 같은 모니터링 또는 활동 쿼리 및 뷰는 다른 노드에서 통계를 검색합니다.
### 작업
추가 조치가 필요하지 않습니다.
## AuroraLimitless:GlobalSequenceRefresh 대기 이벤트
프로세스가 새 시퀀스 값을 생성하고 있으며 글로벌 시퀀스에서 새 청크를 요청해야 합니다.
### 원인
`rds_aurora.limitless_sequence_chunk_size`가 충분하지 않을 경우 시퀀스 값 생성 속도가 높아지면 이 이벤트가 중단될 수 있습니다.
### 작업
이는 정상적인 현상입니다. 이 이벤트에서 과도한 시간이 표시되면 `rds_aurora.limitless_sequence_chunk_size` 조정을 고려합니다. Limitless Database의 시퀀스에 대한 설명서를 참조하세요.
## AuroraLimitless:GlobalVacuumTimeExchange 대기 이벤트
프로세스가 vacuum을 지원하기 위해 스냅샷 데이터를 교환하고 있습니다.
### 원인
Limitless Database의 노드는 vacuum 실행을 위한 올바른 컷오프 시간을 계산하기 위해 가장 오래된 활성 스냅샷 시간 데이터를 다른 노드와 교환합니다.
### 작업
추가 조치가 필요하지 않습니다.
## AuroraLimitless:DistributedTransactionMonitorGather 대기 이벤트
프로세스가 분산 트랜잭션 정리를 지원하기 위해 다른 노드에서 트랜잭션 메타데이터를 수집하고 있습니다.
### 원인
Limitless Database의 노드는 분산 트랜잭션 상태를 제거할 수 있는 시기를 결정하기 위해 트랜잭션 메타데이터를 다른 노드와 교환합니다.
### 작업
추가 조치가 필요하지 않습니다.
## AuroraLimitlessActivity:AdminTaskSchedulerMain 대기 이벤트
작업 스케줄러 프로세스의 기본 루프에서 대기 중입니다.
## AuroraLimitlessActivity:AdminTaskExecutorMain 대기 이벤트
작업 실행기 프로세스의 기본 루프에서 대기 중입니다.
## AuroraLimitlessActivity:AdminTaskMonitorMain 대기 이벤트
작업 모니터 프로세스의 기본 루프에서 대기 중입니다.
## AuroraLimitlessActivity:DatabaseCleanupMonitorMain 대기 이벤트
데이터베이스 정리 모니터 프로세스의 기본 루프에서 대기 중입니다.
## AuroraLimitlessActivity:TopologyCleanupMonitorMain 대기 이벤트
토폴로지 정리 모니터 프로세스의 기본 루프에서 대기 중입니다.
## AuroraLimitlessActivity:ToplogyChangeMonitorMain 대기 이벤트
토폴로지 변경 모니터 프로세스의 기본 루프에서 대기 중입니다.
## AuroraLimitlessActivity:DistributedTransactionMonitorMain 대기 이벤트
분산 트랜잭션 모니터 프로세스의 기본 루프에서 대기 중입니다.
## AuroraLimitlessActivity:GlobalVacuumMonitorMain 대기 이벤트
글로벌 vacuum 모니터 프로세스의 기본 루프에서 대기 중입니다.
# 함수를 사용하여 효율성을 위한 구축
사용자 정의 함수는 기본적으로 단일 샤드에 최적화되어 있지 않지만 단일 샤드 작업으로 실행되도록 구성할 수 있습니다. 함수는 로직을 캡슐화하고 단일 샤드 최적화 방식으로 실행되도록 할 수 있습니다.
## 단일 샤드 작업이 중요한 이유
리소스 사용률은 성능 및 비용 효율성에 중요합니다. 단일 샤드 작업은 교차 샤드 작업에 비해 훨씬 적은 리소스를 사용합니다. 예를 들어 함수를 실행하여 백만 개의 행을 삽입할 때 단일 샤드 실행은 교차 샤드 실행의 경우 126.5ACU에 비해 약 90.5ACU를 사용하므로 리소스 효율성이 35% 향상됩니다.
또한 단일 샤드 실행은 다음을 제공합니다.
+ 교차 샤드 작업보다 35% 높은 처리량
+ 보다 예측 가능한 응답 시간
+ 데이터 증가에 따른 확장성 향상
## 단일 샤드 작업 및 함수
함수는 다음 사전 조건 중 하나가 충족되면 샤드에서 실행됩니다.
+ 함수는 변경할 수 없는 것으로 생성되어 단일 샤드 최적화 쿼리에 포함됩니다.
+ 함수는 사용자가 배포합니다.
샤드에서 실행되는 함수는 데이터가 있는 위치에서 실행되므로 더 잘 수행되고 확장됩니다.
## 함수 및 변동성
함수의 변동성을 확인하려면 PostgreSQL의 시스템 테이블에서 다음 쿼리를 사용합니다.
```
SELECT DISTINCT nspname, proname, provolatile
FROM pg_proc PRO
JOIN pg_namespace NSP ON PRO.pronamespace = NSP.oid
WHERE proname IN ('random', 'md5');
```
출력 예시:
```
nspname | proname | provolatile
------------+---------+-------------
pg_catalog | md5 | i
pg_catalog | random | v
(2 rows)
```
이 예제에서 `md5()`는 변경할 수 없으며 `random()`은 휘발성입니다. 즉, `md5()`를 포함하는 단일 샤드 최적화 문은 단일 샤드 최적화 상태로 유지되지만 `random()`를 포함하는 문은 그렇지 않습니다.
변경 불가능한 함수가 있는 예제:
```
EXPLAIN ANALYZE
SELECT pg_catalog.md5('123')
FROM s1.t1
WHERE col_a = 776586194
AND col_b = 654849524
AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5';
```
```
QUERY PLAN
----------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=3.409..3.409 rows=1 loops=1)
Single Shard Optimized
Planning Time: 0.313 ms
Execution Time: 4.253 ms
(4 rows)
```
휘발성 함수가 있는 예제:
```
EXPLAIN ANALYZE
SELECT pg_catalog.random()
FROM s1.t1
WHERE col_a = 776586194
AND col_b = 654849524
AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5';
```
```
QUERY PLAN
------------------------------------------------------
Foreign Scan on t1_fs00001 t1
(cost=100.00..15905.15 rows=1 width=8)
(actual time=0.658..0.658 rows=1 loops=1)
Planning Time: 0.263 ms
Execution Time: 2.892 ms
(3 rows)
```
출력은 `md5()`가 푸시다운되고 단일 샤드 최적화로 실행되지만 `random()`는 그렇지 않음을 보여줍니다.
## 함수 배포
하나의 샤드에서만 데이터에 액세스하는 함수는 성능 이점을 얻기 위해 해당 샤드에서 실행해야 합니다. 함수를 배포하고 함수 서명에 전체 샤드 키가 포함되어야 합니다. 샤드 키의 모든 열을 함수에 파라미터로 전달해야 합니다.
함수 예제:
```
CREATE OR REPLACE FUNCTION s1.func1(
param_a bigint,
param_b bigint,
param_c char(100)
)
RETURNS int AS $$
DECLARE
res int;
BEGIN
SELECT COUNT(*) INTO res
FROM s1.t1
WHERE s1.t1.col_a = param_a
AND s1.t1.col_b = param_b
AND s1.t1.col_c = param_c;
RETURN res;
END
$$ LANGUAGE plpgsql;
```
배포 전에 함수는 단일 샤드 최적화되지 않습니다.
```
EXPLAIN ANALYZE
SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5');
```
```
QUERY PLAN
------------------------------------------------------------------------------------------------------
Function Scan on func1 (cost=0.25..0.26 rows=1 width=4)
(actual time=37.503..37.503 rows=1 loops=1)
Planning Time: 0.901 ms
Execution Time: 51.647 ms
(3 rows)
```
함수를 배포하려면 다음을 수행하세요.
```
SELECT rds_aurora.limitless_distribute_function(
's1.func1(bigint,bigint,character)',
ARRAY['param_a','param_b','param_c'],
's1.t1'
);
```
배포 후에 함수는 단일 샤드에 최적화됩니다.
```
EXPLAIN ANALYZE
SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5');
```
```
QUERY PLAN
------------------------------------------------------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=4.332..4.333 rows=1 loops=1)
Single Shard Optimized
Planning Time: 0.857 ms
Execution Time: 5.116 ms
(4 rows)
```
`rds_aurora.limitless_stat_statements`에서 `sso_calls` 열을 확인하여 단일 샤드 최적화를 확인할 수 있습니다.
```
subcluster_id | subcluster_type | calls | sso_calls | query
--------------+-----------------+-------+-----------+--------------------------------------
2 | router | 2 | 1 | SELECT * FROM s1.func1( $1, $2, $3 )
3 | router | 1 | 1 | SELECT * FROM s1.func1( $1, $2, $3 )
(2 rows)
```
## 함수 및 효율성 패턴
데이터에 가까운 로직을 실행하는 것이 더 효율적이며 함수는 이를 달성하는 데 중요한 역할을 합니다. 함수의 효율성을 개선하기 위한 두 가지 주요 사용 사례가 있습니다.
1. 복잡한 데이터에서 샤드 키를 추출하여 별도의 단일 샤드 최적화 함수 호출
1. 교차 샤드 로직을 단일 샤드 최적화 문과 분리하여 교차 샤드 워크로드를 단일 샤드 최적화로 전환
### 복잡한 데이터에서 샤드 키 추출
여러 데이터베이스 작업을 수행하는 서명 `s3.func3(p_json_doc json)`이 있는 함수를 고려합니다. 이러한 작업은 모든 샤드에 걸쳐 있는 트랜잭션 내의 모든 샤드에서 실행됩니다. JSON 문서에 샤드 키가 포함된 경우 단일 샤드 최적화 함수를 빌드하여 데이터베이스 작업을 수행할 수 있습니다.
원래 패턴:
```
s3.func3(p_json_doc json)
database operation 1;
database operation 2;
database operation 3;
```
최적화된 패턴:
```
s3.func3(p_json_doc json)
DECLARE
v_a bigint;
BEGIN
v_a := (p_json_doc->>'field_a')::bigint;
SELECT s3.func3_INNER(v_a, p_json_doc);
END;
```
내부 함수가 다음을 수행하는 경우:
```
s3.func3_INNER(p_a, p_json_doc)
database operation 1 WHERE shard_key = p_a;
database operation 2 WHERE shard_key = p_a;
database operation 3 WHERE shard_key = p_a;
```
이 패턴에서 샤드 키는 복잡한 데이터 형식으로 캡슐화되거나 다른 파라미터에서 추론할 수 있습니다. 로직, 데이터 액세스 및 함수는 샤드 키를 결정, 추출 또는 구성한 다음 단일 샤드에 대한 작업만 수행하는 단일 샤드 최적화 함수를 호출할 수 있습니다. 애플리케이션 인터페이스는 변경되지 않으므로 최적화는 비교적 쉽게 테스트할 수 있습니다.
### 다른 함수 또는 데이터에서 샤드 키 연기
로직 또는 데이터 액세스가 샤드 키를 계산하거나 결정할 때 또 다른 설계 패턴이 적용됩니다. 이는 대부분의 호출에 대해 단일 샤드에서 함수를 실행할 수 있지만 경우에 따라 교차 샤드 실행이 필요한 경우에 유용합니다.
원래 패턴:
```
NEWORD(INTEGER, …) RETURNS NUMERIC
DECLARE
all_whid_local := true;
LOOP through the order lines
Generate warehouse ID;
IF generated warehouse ID == input warehouse ID
THEN
ol_supply_whid := input warehouse ID;
ELSE
all_whid_local := false;
ol_supply_whid := generated warehouse ID;
END IF;
…
END LOOP;
…
RETURN no_s_quantity;
```
별도의 함수가 있는 최적화된 패턴:
```
CREATE OR REPLACE FUNCTION NEWORD_sso(no_w_id INTEGER, …)
RETURNS NUMERIC
…
RETURN no_s_quantity;
…
END;
LANGUAGE 'plpgsql';
SELECT rds_aurora.limitless_distribute_function(
'NEWORD_sso(int,…)',
ARRAY['no_w_id'],
'warehouse'
);
CREATE OR REPLACE FUNCTION NEWORD_crosshard(no_w_id INTEGER, …)
RETURNS NUMERIC
…
RETURN no_s_quantity;
…
END;
LANGUAGE 'plpgsql';
```
그런 다음 기본 함수가 단일 샤드 최적화 버전 또는 교차 샤드 버전을 호출하도록 합니다.
```
IF all_whid_local THEN
SELECT NEWORD_sso(…) INTO no_s_quantity;
ELSE
SELECT NEWORD_crosshard(…) INTO no_s_quantity;
END IF;
```
이 접근 방식을 사용하면 대부분의 간접 호출이 단일 샤드 최적화의 이점을 활용하면서 교차 샤드 실행이 필요한 경우 올바른 동작을 유지할 수 있습니다.
## 단일 샤드 작업 확인
`EXPLAIN`을 사용하여 문이 단일 샤드에 최적화되어 있는지 확인합니다. 출력은 최적화된 작업을 위해 '단일 샤드 최적화'를 명시적으로 보고합니다.
배포 전 샤드 간 호출:
```
QUERY PLAN
---------------------------------------------------------------------
Function Scan on func1 (cost=0.25..0.26 rows=1 width=4)
(actual time=59.622..59.623 rows=1 loops=1)
Planning Time: 0.925 ms
Execution Time: 60.211 ms
```
배포 후 단일 샤드 호출:
```
QUERY PLAN
----------------------------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=4.576..4.577 rows=1 loops=1)
Single Shard Optimized
Planning Time: 1.483 ms
Execution Time: 5.404 ms
```
실행 시간의 차이는 단일 샤드 최적화의 성능 이점을 보여줍니다.