[AWS Aurora] binlog I/O cache 도입으로 Aurora MySQL (2.10 later) 성능 향상

 

l  Version : AWS Aurora MySQL 2.10 later

 

Binlog 복제는 소스 데이터베이스에서 트랜잭션 작업 오프로드, 분석을 실행하기 위한 별도의 전용 시스템으로 변경 사항 복제, 다른 시스템으로 데이터 스트리밍을 포함하여 여러 사용 사례를 제공하는 인기 있는 기능 이지만 무료(기능에 따른 오버헤드 비용으로 해석) 제공되지 않는다.

 

바이너리 로깅은 binlog 이벤트에 대한 로깅이 트랜잭션 커밋의 중요한 경로의 일부로 통합되기 대문에 데이터베이스에 오버헤드가 발생할 있다. 뜻은 높은 커밋 대기 시간 낮은 처리량으로 해석할 있다. MySQL 엔진은 추가 정보(binlog 이벤트) binlog 파일에 쓰기 시작한다. 일반적으로 binlog 파일은 로컬 스토리지에 기록 되지만 Aurora MySQL-Compatible Edition 이러한 binlog 파일을 Aurora 스토리지 엔진에 기록 한다. Binlog 파일은 MySQL binlog 이벤트를 binlog 파일에 기록 뿐만 아니라 동일한 파일에서 binlog 이벤트를 읽기 때문에 MySQL 이러한 binlog 이벤트를 다른 MySQL 데이터베이스에 복제하기 시작할 성능 병목 현상이 있다.

 

Aurora MySQL 2.10 릴리스에서는 사용 사례를 개선하기 위해  binlog I/O 캐시라는 새로운 기능이 도입되었다. 사용 사례에서는 Aurora MySQL 바이너리 로깅을 켜고 binglog 이벤트를 동일한 파일에 적극적으로 복제한다. 이번 포스트에서는 새로운 binlog I/O 캐시의 성능 향상 관련 모니터링 메트릭과 상태 변수에 대해 알아 본다.

 

Binlog I/O 캐시는 순환 캐시에 가장 최근의 binlog 이벤트를 유지하여 Aurora 스토리지 엔진의 읽기 I/O 최소화 한다.  Binlog I/O 캐시는 db.t2, db.t3 인스턴스를 제외한 대부분의 Aurora MySQL 인스턴스에 대해 활성화 된다. 아래 그래프는 binlog I/O 캐시를 활성(파란선), 비활성(주황선) 했을때 초당 평균 쓰기를 측정한 결과이다. 그래프를 통해서  binlog I/O 캐시로 얻을 있는 처리량 향상 정도를 확인할 있다.

 

그래프에서 읽기 전용 복제본의 I/O 경합 없이 최적의 성능을 보여주는 복제본 없음설정(회색선) 처리량도 표시했다. 그림을 보면 binlog I/O 캐시가 활성화 경우 쓰기 처리량 증가(파란색) 따라 원본 인스턴스가 연결된 복제본이 없는 것처럼 (회식) 최적의 쓰기 처리량으로 확장될 있음을 보여준다.

 

Binlog I/O 캐시를 출시하기 전에 aurora_binlog_replication_max_yield_seconds 매개변수를 사용하여 관련 binlog 성능 향상을 구현했으며, 이는 MySQL 5.7(2.04.5 later) 5.6(1.17.6)에서 출시 되었다. 매개변수는 binlog 덤프 스레드가 “aurora_bin_log_replication_max_yield_seconds” 초까지 기다리도록 지시한다. 덤프 스레드의 이러한 양보(yield)” 통해 binlog 기록기 스레드는 binlog 덤프 스레드와의 경합없이 활성 binlog 파일에 있지만 잠재적으로 높은 복제 지연이 발생할 있다. Binlog I/O 캐시를 사용하기 위해서는 추가 구성이 필요하지 않지만 기능을 최대한 활용하려면 기존 최대 산출량 기능인 aurora_bin_log_replication_max_yield_seconds 다시 0으로 재설정 하는 것이 좋다.

 

Binlog I/O cache 대한 모니터링을 위해 두가지 상태 변수(aurora_binlog_io_cache_reads, aurora_binlog_io_cache_read_requests) 새로운 로그인 dump thread metrics 도입되었다. aurora_binlog_io_cache_read_requests 변수는 binlog 파일에 대한 읽기 I/O수를 보여주고  aurora_binlog_io_cache_reads 캐시에서 읽을 있는 읽기 I/O 수를 보여준다. 아래 코드는 binlog I/O 캐시의 적중률을 구하는 예제이다.

mysql> SELECT(SELECT VARIABLE_VALUE
              FROM INFORMATION_SCHEMA.GLOBAL_STATUS
              WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')/
             (SELECT VARIABLE_VALUE
              FROM INFORMATION_SCHEMA.GLOBAL_STATUS
              WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')*100
              as binlog_io_cache_hit_ratio;
 
+-------------------------+
| binlog_io_cache_hit_ratio |
+-------------------------+
|       99.99847949080622 |
+-------------------------+
1 row in set, 2 warnings (0.00 sec)

 

또한 소스에서 작성된 최신 binlog 이벤트에서 binlog 복제본의 거리(바이트) 모니터링할 있다. 정보는 원본에서 가져온 복제본을 읽은 최신 binlog이벤트가 binlog I/O 캐시에서 제공되는지 여부를 분석할 있기 때문에 중요하다. 검색 키워드 “dump thread metric” 사용하여 메트릭을 필터링 있다. “dump thread”라는 이름은 MySQL 문서의 binary log dump thread에서 차용했다. 지표는 복제본이 소스 인스턴스에 연결될 기록되며 1분마다 내보낸다. Aurora MySQL log_error_verbosity 기본값인 3 경우에만 메시지를 생성한다. Log_error_verbosity값은 Aurora MySQL DB 파라미터 그룹 또는 DB 클러스터 파라미터 그룹을 통해 구성할 있다.

 

 

[참고자료]

l  https://aws.amazon.com/ko/blogs/database/introducing-binlog-i-o-cache-in-amazon-aurora-mysql-to-improve-binlog-performance/

 

 

2022-05-11 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, Aurora, binlog, Binlog I/O cache, Aurora performance, Aurora replication

[AWS EC2] Region, Availability Zone, AWS Local Zone, Wavelength, AWS Outposts 개념 정리

 

l  Version : AWS Elastic Compute Cloud

 

클라우드 서비스의 여러 장점 하나는 다양한 지역에 서비스를 배포하고 원하는 지역에서 빠르게 서비스를 제공할 있는 것이다. Amazon EC2 세계 각지의 여러 곳에서 호스팅 되고 있으며 위치는 리전, 가용 영역, Local Zone, AWS Outposts Wavelength Zone으로 구성된다. 이번 포스트는 이러한 구성에 따른 개념 특징을 정리해 본다.

 

리전(Region)

AWS에는 리전이라는 개념이 있다. AWS 세계에서 데이터 센터를 클러스터링하는 물리적 위치를 리전이라고 한다. 논리적 데이터 센터의 그룹을 가용 영역이라고 하는데, AWS 리전은 지리적 영역 내에서 격리되고 물리적으로 분리된 여러 개의 AZ 구성된다. AZ 독립된 전원, 냉각 물리적 보안을 갖추고 있으며 지연 시간이 매우 짧은 중복 네트워크를 통해 연결된다.

(아래 그림에서 설명은 현재와 맞지 않으므로 그림만 참고한다.)

AWS 북미, 남미, 유럽, 중국, 아시아 태평양, 남아프리카 중동의 리전을 포함하여 여러 지리적 리전을 유지 관리하고 있다. 리전은 추가 또는 변경될 있으므로 최신의 리전 정보는 아래 링크를 참고 한다.

l  리전 엣지 네트워크 : https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/

 

글을 쓰는 현재, 세계 26개의 지리적 리전에 84개의 가용 영역을 운영하고 있으며, 호주, 캐나다, 인도, 이스라엘, 뉴질랜드, 스페인, 스위스 아랍에미리트(UAE) 8개의 리전과 24개의 가용영역을 추가할 계획이다.

 

일부 정부기관 중국의 경우 리전 제약이 있으므로 공식 문서를 반드시 확인할 있도록 한다.

 

가용 영역 (Availability Zone)

AZ(가용 영역) AWS 리전의 이중화 전력, 네트워킹 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성된다. AWS 리전의 모든 AZ 높은 대역폭, 지연 시간이 짧은 네트워킹, 완전한 이중화를 갖춘 전용 메트로 네트워크와 상호 연결되어 있어 AZ 간에 높은 처리량과 지연 시간이 짧은 네트워킹을 제공한다. 네트워크 성능은 AZ 동기 복제 기능을 충분히 수행할 있으며 AZ 간의 모든 트래픽은 암호화된다. AZ 다른 모든 AZ 킬로미터에 상당하는 유의미한 거리를 두고 물리적으로 분리되어 있다. 다만 모든 AZ 서로 100km(60마일) 이내의 거리에 위치한다.

(아래 그림에서 설명은 현재와 맞지 않으므로 그림만 참고한다.)

 

AWS Local Zone

AWS 로컬 영역은 컴퓨팅, 스토리지, 데이터베이스 기타 셀렉트 AWS 서비스를 최종 사용자에게 가까운 위치에서 실행할 있게 한다. , 주요 리전이 없는 전략적 위치에 소규모 데이터 센터( AWS Outposts 설계 기반) 구축하여 범위를 확장한다. AWS 로컬 영역을 사용하면 미디어 엔터테인먼트 콘텐츠 작성, 실시간 게임, 저장소 시뮬레이션, 전자 설계 자동화, 기계 학습과 같이 지연 시간이 10밀리초 미만이어야 하는 매우 까다로운 애플리케이션을 쉽게 실행할 있다.

 

AWS 로컬 영역 위치는 최종 사용자에게 근접한 지역에서 Amazon Elastic Compute Cloud, Amazon Virtual Private Cloud, Amazon Elastic Block Store, Amazon File Storage, Amazon Elastic Load Balancing 등의 AWS 서비스를 사용하여 지연 시간에 민감한 애플리케이션을 실행할 있는 AWS 리전의 확장이다. AWS 로컬 영역은 로컬 워크로드와 AWS 리전에서 실행 중인 워크로드 간의 고대역폭 보안 연결을 제공하여 동일한 API 도구 세트를 통해 전체 리전 서비스에 원활하게 다시 연결할 있게 한다.

 

AWS Wavelength

AWS Wavelength 사용하면 개발자가 모바일 디바이스 최종 사용자 측에서 발생하는 지연 시간이 10밀리초 미만인 애플리케이션을 제작할 있다. AWS 개발자는 이동 통신 사업자 데이터 센터 내의 5G 네트워크 엣지에 AWS 컴퓨팅 스토리지 서비스를 포함하는 AWS 인프라 배포 환경인 Wavelength Zone 애플리케이션을 배포하고 해당 리전의 다양한 AWS 서비스에 원활하게 액세스할 있다. 이를 통해 개발자는 게임 라이브 동영상 스트리밍, 엣지의 기계 학습 추론, 증강 가상 현실(AR/VR) 10밀리초 미만의 지연 시간이 요구되는 애플리케이션을 제공할 있다. AWS Wavelength 5G 네트워크 엣지에 AWS 서비스를 제공하여 모바일 디바이스에서 애플리케이션에 연결할 발생하는 지연 시간을 최소화 한다. 애플리케이션 트래픽은 모바일 사업자 네트워크 내의 Wavelength Zone에서 실행되는 애플리케이션 서버로 전송될 있다. 이를 통해 지연 시간이 100밀리초를 초과하게 만들어 고객이 5G 향상된 대역폭 지연 시간을 완전히 활용하지 못하게 있는 인터넷에 대한 추가적인 네트워크 홉이 줄어들게 된다. 아래 그림은 미국 버라이즌 통신사에 구축된 Wavelength 이다.

 

Wavelength 여러 면에서 Outpost 유사하지만 다르다. 물리적으로 엣지 액세스에서 컴퓨팅을 제공하는 개념은 비슷하지만 Wavelength 주요 목표는 가용성 영역과 같은 리전의 확장이다. Wavelength 데이터 센터에서 물리적으로 구매하고 컴퓨팅을 배치할 필요가 없다는 점에서 매우 유사하지만 이동 통신사에서 제공된다.

 

AWS Outposts

AWS Outposts() AWS 인프라, 서비스, API 도구를 고객 온프레미스로 확장하는 완전관리형 서비스이다. AWS 관리형 인프라에 대한 로컬 액세스를 제공하는 AWS Outposts() 통해 고객은 AWS 리전에서 사용하는 것과 동일한 프로그래밍 인터페이스를 사용해 온프레미스에서 애플리케이션을 구축하고 실행할 있으며, 짧은 지연 시간과 로컬 데이터 처리가 필요한 경우에 로컬 컴퓨팅 스토리지 리소스를 사용할 있다. , 데이터 센터 또는 코로케이션 시설에 설치형 기반 솔루션을 제공하여 AWS 기술 서비스를 사용하는 것이다.

 

Outposts 고객 사이트에 배포된 AWS 컴퓨팅 스토리지 용량 풀이다. AWS 용량을 AWS 리전의 일부로 운영, 모니터링 관리한다. Outposts 서브넷을 만들고 EC2 인스턴스, EBS 볼륨, ECS 클러스터 RDS 인스턴스와 같은 AWS 리소스를 생성할 해당 서브넷을 지정할 있다. Outposts 서브넷의 인스턴스는 프라이빗 IP 주소를 사용하여 AWS 리전의 다른 인스턴스와 통신한다 (모두 동일한 VPC 있음).

 

아래 그림은 Outposts 서비스에 사용되는 랙의 모습이다.

 

 

 

 

 

[참고자료]

l  글로벌 인프라 : https://aws.amazon.com/ko/about-aws/global-infrastructure/

l  리전 영역 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#az-ids

l  리전 가용 영역 : https://aws.amazon.com/ko/about-aws/global-infrastructure/regions_az/

l  AWS Outposts : https://docs.aws.amazon.com/ko_kr/outposts/latest/userguide/what-is-outposts.html

l  Local Zone: https://aws.amazon.com/blogs/aws/announcing-a-second-local-zone-in-los-angeles/

l  Outpost vs Azure MEC: https://msandbu.org/amazon-outpost-vs-azure-stack-hub/  https://noise.getoto.net/2019/12/03/aws-now-available-from-a-local-zone-in-los-angeles/

 

2022-05-08 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, Region, Availability Zone, Local Zone, Wavelength Zone, Outposts

[AWS RDS] Devops Guru for RDS 기능을 사용하여 데이터베이스의 이상 현상을 사전에 감지하기

 

l  Version : Devops Guru for RDS

 

이전 포스트에서 AWS Performance Insight(성능 개선 도우미) 사용하여 데이터베이스 운영에 필요한 다양한 지표 쿼리 관련 모니터링에 대해서 살펴 보았다.

l  [AWS RDS] Performance Insight DB부하의 원인 찾기 : https://sungwookkang.com/1503

 

이러한 모니터링은 데이터를 수집하고 관리자가 대시보드를 통한 정보 확인후 문제점 여부를 확인하는데 매우 도움이 된다. 하지만 조금 발전시켜 이러한 이상 현상을 사전에 탐지하고 진단 결과를 알려준다면 조금 빠르게 사전 대응이 가능하지 않을까 생각해 있다. 물론 AWS CloudWatch 사용하여 이상 패턴 발견 SNS 등을 사용하여 알림을 보낼 수도 있지만, 알림은 단순 임계치 값에서 변경이 발생하였을 경우에만 가능 하기 때문에 아래 솔루션을 사용하면 조금 스마트한 모니터링 병목 구간에 대한 진단이 가능하다.

 

Amazon DevOps Guru for RDS 기계 학습(ML) 기반으로 하는 서비스로 모든 AWS RDS 엔진에서 사용할 있으며 이를 통해 애플리케이션의 운영 성능 가용성을 쉽게 개선할 있다.

l  Amazon DevOps Guru for RDS : https://aws.amazon.com/ko/devops-guru/features/devops-guru-for-rds/

 

서비스는 ML 사용하여 호스트 리소스의 과도한 사용, 데이터베이스 병목 현상 또는 SQL 쿼리의 오작동과 같은 광범위한 성능 관련 데이터베이스 문제를 자동으로 식별하고 분석한다. 또한 발견한 문제를 수정하기 위한 가이드라인을 제공한다. 이상 현상이 감지되면 콘솔에서 결과를 확인할 있을 뿐만 아니라 Amazon Event Bridge또는 Amazon SNS 사용하여 알림을 보낼 있다.

 

 

 DevOps Guru for RDS 사용하기 위해서는 Amazon Console에서 RDS 성능 개선 도우미(Performance Insight) 활성화 DevOps Guru 콘솔로 이동하여 활성화 한다.

 

RDS DevOps Guru 데이터베이스 로드(DB Load) 성능 메트릭에서 이상 감지를 사용하여 문제를 감지한다. DB 로드는 AAS(Average Active Sessions) 단위로 측정된다. DB 로드는 데이터베이스의 활동 수준을 측정하므로 DB 부하가 높으면 성능 문제가 발생할 있다. 메트릭은 가상 CPU(vCPU) 수와 비교할 있으며, DB 부하가 수보다 높으면 문제가 발생할 있다.

 

아래 그림은 DevOps Guru for RDS리포트 결과로, 그래프는 AAS에서 대부분이 테이블 또는 CPU 대한 액세스를 기다리고 있음을 보여준다. 대기 이벤트는 현재 실행 중인 SQL 기다리고 있는 상태로 가장 일반적인 이유는 CPU 기다리거나 읽기 또는 쓰기를 기다리거나 잠긴 리소스를 기다리는 상태이다. Top SQL 차원은 DB 로드에 가장 많이 기여하는 쿼리를 보여준다.

 

DevOps Guru for RDS 분석 페이지에서는 문제의 원인과 해결을 위한 가지 권장 사항도 보여주는데 메트릭에서의 이상 징후는 높은 로드 대기 이벤트와 CPU 용량 초과라는 가지 문제가 감지되었다. 그리고 아래와 같은 분석결과는 나타내었다.

l  IO CPU 대기 유형에 대한 27개의 AAS 있는 고부하 대기 이벤트를 있으며 전체 DB 로드의 99%이다.

l  실행 중인 작업이 6 프로세스를 초과했음을 알려준다. 데이터베이스에는 2개의 vCPU 있으며 권장되는 실행 프로세스 수는 최대 4(vCPU 2)여야 한다.

 

다른 예외에서 그래프는 대기 이벤트의 로드가 높았고 하나의 SQL 쿼리에 추가 조사가 필요한 것으로 나타났다. SQL 다이제스트 ID 클릭하면 정확한 SQL 쿼리를 수도 있다. 예를 들어 대기 이벤트 wait/io/table/sql/handler 또는 문제 해결 문서 보기 링크에서 대기 이벤트를 클릭하면 자세한 정보를 많이 얻을 있다.

 

 

외에도 데이터베이스 분석을 보려면 Insight 페이지로 이동하여 분석 정보를 확인할 있다.

 

 

 

[참고자료]

-          Amazon DevOps Guru for RDS : https://aws.amazon.com/ko/devops-guru/features/devops-guru-for-rds/

-          Amazon DevOps Guru for RDS to Detect, Diagnose, and Resolve Amazon Aurora-Related Issues using ML : https://aws.amazon.com/ko/blogs/aws/new-amazon-devops-guru-for-rds-to-detect-diagnose-and-resolve-amazon-aurora-related-issues-using-ml/

 

 

 

 

2022-04-25 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, RDS, Performance Insight, 성능 개선 도우미, DB 모니터링, 쿼리 모니터링, DB 성능 개선, DevOps Guru for RDS, 사전탐지, 장애방지, 장애대응

[AWS RDS] Performance Insight DB부하의 원인 찾기

 

l  Version : Performance Insight

 

AWS RDS 데이터베이스를 사용할 , 데이터베이스 인스턴스의 성능 지표 로그를 CloudWatch에서 수집하여 여러 성능 지표에 대한 모니터링을 진행할 있다. 하지만 슬로우 쿼리, 대기정보, 세션별 쿼리 실행 데이터베이스를 운영하기 위해 조금 자세한 정보를 확인하려면 RDS 성능 개선 도우미(Performance Insight) 사용할 있다.

 

성능 개선 도우미를 사용하려면 DB 인스턴스 또는 다중 AZ DB 클러스터에서 활성화 해야한다. 필요에 따라 활성/비활성이 가능하며, 상태 변경 재부팅 또는 장애조치가 발생하지 않는다. 성능 개선 도우미를 사용하면 에이전트가 실행되는데 이때 약간의 오버헤드가 발생하기 때문에 DB 로드가 높은 경우 수집 빈도를 조절하여 사용할 있도록 한다.

 

성능 개선 도우미는 콘솔에서 쉽게 설정이 가능하며 AWS CLI RDS API 통해서도 설정이 가능하다.

 

성능 개선 도우미의 활성화에 대한 자세한 내용은 아래 공식 문서를 참고 한다.

l  성능 개선 도우미 설정 해제 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Enabling.html

 

성능 개선 도우미에 액세스 하려면 IAM(Identity and Access Management) 적절한 권한이 있어야 한다. IAM 대한 정책은 아래 문서를 참고한다.

l  Performance Insights 대한 액세스 정책 구성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.access-control.html

 

성능 개선 도우미의 대시 보드는 기본적으로 마지막 1시간 동안 수집된 데이터를 표시한다.

 

대시보드는 아래와 같이 부분으로 나눌 있다.

l  카운터 지표 : 특정 성능 카운터 지표의 데이터를 표시

l  DB 부하 차트 : DB 부하와 DB 인스턴스 용량을 비교하여 최대 vCPU 선으로 표시

l  상위 항목(Top Item) : DB 로드에 기여하는 상이 차원을 표시

 

부분에 대한 자세한 내용은 아래 링크를 참고한다.

l  성능 개선 도우미 대시보드 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.html

 

대시보드 화면의 데이터베이스 로드(Database load) 차트에서는 병목 현상에 대한 정보를 확인할 있다. 어떤 데이터베이스 로그가 최대 CPU(Max CPU) 선을 상회하는지 확인할 있고 어떤 작업이 DB 부하를 차지하는지 보여준다. 아래 그림에서는 로그 파일 동기화 대기 시간이 대부분의 DB 부하를 차지한다. 그리고 LGWR all worker groups 대기 시간도 높다. TOP SQL 차트는 로그 파일 동기화 대기의 원인에 사용된 SQL 구문인 COMMIT 문을 보여준다.

 

TOP SQL 에서는 데이터베이스 로드에 영향을 미치는 상위 SQL 쿼리가 표시된다. TOP SQL 탭에서는  SQL 통계(SQL Statistics) 대기별 로드(AAS), SQL 정보, 환경설정 정보 등을 확인할 있다.

 

SQL 통계 (SQL Statistics) SQL 쿼리에 대한 성능 관련 지표이다. 초당 실행 횟수 초당 처리된 행을 표시한다.

 

 

대기 시간별 로드(Load by waits AAS) 상위 로드 항목과 연결된 데이터베이스 로드의 비율을 나타낸다. 예를 들어 DB 로드 차트를 대기 상태별로 그룹화 있다. 쿼리가 영향을 미치는 대기 상태의 정도를 크기, 세그먼트 컬러 코드로 표시한다.

 

 

SQL 정보에서는 TOP SQL 실행된 쿼리와 SQL ID, Support Digest ID등을 확인할 있다.

 

환경설정에서는 수집되는 항목을 설정 있다.

 

 

위에서 나열한 항목의 자세한 내용은 아래 공식 문서를 참고 한다.

l  상위 SQL(Top SQL) 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL.html

 

 

기본적으로 TOP SQL 테이블의 행에는 SQL 문에 대해 500 byte SQL 텍스트가 표시된다. SQL 문이 500byte 이상인 경우 성능 개선 도우미 대시보드에서 해당문을 열어 많은 텍스트를 있다. 경우 최대 4KB까지 표시된다. 또한 쿼리를 다운로드 있다. TOP SQL 텍스트에 대한 자세한 내용은 아래 문서를 참고 한다.

l  SQL 문의 텍스트 액세스 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.SQLTextSize.html

 

 

성능 개선 도우미를 사용할 있는 RDS 엔진 버전은 지속적으로 업데이트 되므로 항상 최신의 정보를 확인할 있도록 아래 링크의 공식 문서를 참고한다. 현재 Aurora 서버리스는 성능 개선 도우미를 지원하지 않는다.

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

 

성능개선 도우미는 대부분의 리전에서 사용 가능하며, 아래 링크를 참고한다.

l  AWS성능 개선 도우미를 위한 리전 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Regions.html

 

 

 

[참고자료]

l  성능 개선 도우미 설정 해제 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Enabling.html

l  Performance Insights 대한 액세스 정책 구성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.access-control.html

l  성능 개선 도우미 대시보드 개요 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.Components.html

l  SQL 문의 텍스트 액세스 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.SQLTextSize.html

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

l  Amazon RDS DB 엔진의 성능 개선 도우미 지원 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.Engines.html

 

 

2022-04-24 / Sungwook Kang / http://sungwookkang.com

 

 

AWS, RDS, Performance Insight, 성능 개선 도우미, DB 모니터링, 쿼리 모니터링, DB 성능 개선

+ Recent posts