데이터베이스 성능 튜닝의 주요 개념

DevOpsGuru for RDS는 사용자가 몇 가지 주요 성능 개념을 잘 알고 있다고 가정합니다. 이러한 개념에 대해 자세히 알아보려면 Amazon Aurora 사용 설명서의 성능 개선 도우미 개요 또는 Amazon RDS 사용 설명서의 성능 개선 도우미 개요를 참조하십시오.

지표

지표는 시간 순서별 데이터 포인트 집합을 나타냅니다. 지표는 모니터링할 변수로, 데이터 요소는 시간에 따른 변수의 값을 나타내는 것으로 간주합니다. Amazon RDS는 DB 인스턴스가 실행되는 운영 체제(OS) 및 데이터베이스 측정치를 실시간으로 제공합니다. Amazon RDS 콘솔에서 Amazon RDS DB 인스턴스에 대한 모든 시스템 지표 및 프로세스 정보를 볼 수 있습니다. DevOpsGuru for RDS는 이러한 지표 중 일부에 대한 통찰력을 모니터링하고 제공합니다. 자세한 내용은 Amazon Aurora 클러스터의 모니터링 지표 또는 Amazon 관계형 데이터베이스 서비스 인스턴스의 모니터링 지표를 참조하십시오.

문제 감지

DevOpsGuru for RDS는 데이터베이스 및 운영 체제 (OS) 메트릭을 사용하여 문제가 임박했든 진행 중이든 관계없이 중요한 데이터베이스 성능 문제를 탐지합니다. DevOpsGuru for RDS 문제 감지를 위한 두 가지 주요 작동 방식은 다음과 같습니다.

• 임계값 사용

• 이상 사용

임계값으로 문제 감지

임계값은 모니터링된 지표를 평가하는 데 기준이 되는 경계 값입니다. 임계값은 지표 차트에서 정상 동작과 잠재적 문제가 될 수 있는 동작을 구분하는 수평선으로 생각할 수 있습니다. DevOpsGuru for RDS는 특정 메트릭을 모니터링하고 지정된 리소스에서 잠재적으로 문제가 될 것으로 간주되는 수준을 분석하여 임계값을 생성합니다. DevOps그런 다음 Guru for RDS는 새 지표 값이 일정 기간 동안 지속적으로 지정된 임계값을 초과할 경우 DevOps Guru 콘솔에서 통찰력을 생성합니다. 인사이트에는 미래의 데이터베이스 성능에 영향을 미칠 수 있는 요소를 방지하기 위한 권장 사항이 포함되어 있습니다.

예를 들어 DevOps Guru for RDS는 15분 동안 디스크를 사용하는 임시 테이블 수를 모니터링하여 임시 테이블의 초당 디스크 사용률이 비정상적으로 높을 때 통찰력을 얻을 수 있습니다. 디스크의 임시 테이블 사용량이 증가하면 데이터베이스 성능에 영향을 미칠 수 있습니다. DevOpsGuru for RDS는 심각해지기 전에 이 상황을 파악하여 문제를 예방하기 위한 수정 조치를 취할 수 있도록 지원합니다.

이상으로 문제 감지

임계값은 간단하고 효과적으로 데이터베이스 문제를 탐지하는 방법을 제공하지만 일부 상황에서는 이것만으로 충분하지 않습니다. 일일 보고 작업과 같은 알려진 프로세스로 인해 지표 값이 정기적으로 급증하여 잠재적으로 문제가 될 수 있는 동작으로 이어지는 경우가 그 예입니다. 이러한 스파이크가 예상되므로 각 항목에 대한 인사이트와 알림을 생성하는 것은 역효과를 유발하고 알림으로 인한 피로로 이어질 수 있습니다.

그러나 다른 지표보다 훨씬 높거나 더 오래 지속되는 지표는 실제 데이터베이스 성능 문제를 나타낼 수 있기 때문에 이례적인 스파이크를 감지하는 것은 여전히 필요합니다. 이 문제를 해결하기 위해 DevOps Guru for RDS는 특정 메트릭을 모니터링하여 메트릭의 동작이 매우 비정상적이거나 변칙적인 경우 이를 탐지합니다. DevOps그런 다음 Guru는 이러한 이상 현상을 통찰력으로 보고합니다.

예를 들어 DevOps Guru for RDS는 DB 부하가 높을 뿐만 아니라 일반적인 동작에서 크게 벗어날 때 통찰력을 생성할 수 있습니다. 이는 예상치 못한 데이터베이스 작업 속도가 크게 저하되었음을 나타냅니다. DevOpsGuru for RDS를 사용하면 비정상적인 DB 로드 스파이크만 인식하므로 사용자는 정말 중요한 문제에 집중할 수 있습니다.

DB 부하

데이터베이스 튜닝의 핵심 개념은 데이터베이스 부하(DB 로드) 지표입니다. DB 로드는 특정 시점의 데이터베이스 사용량을 나타냅니다. DB 로드가 증가하면 데이터베이스 활동이 증가합니다.

데이터베이스 세션은 관계형 데이터베이스와 애플리케이션의 대화를 나타냅니다. 활성 세션은 데이터베이스 요청을 실행 중인 세션입니다. 세션은 CPU에서 실행 중이거나 리소스가 계속 진행될 수 있도록 대기 중일 때 활성화됩니다. 예를 들어 활성 세션은 페이지가 메모리로 읽힐 때까지 기다린 다음 페이지에서 데이터를 읽는 동안 CPU를 사용할 수 있습니다.

성능 개선 도우미의 DBLoad 지표는 평균 활성 세션(AAS)으로 측정됩니다. AAS를 계산하기 위해 성능 개선 도우미는 활성 세션 수를 매초마다 샘플링합니다. AAS는 특정 기간 동안의 총 세션 수를 총 샘플 수로 나눈 값입니다. AAS 값이 2이면 평균적으로 2회의 세션이 요청 활성화 상태였음을 의미합니다.

DB 로드는 창고의 활동에 비유할 수 있습니다. 창고에 100명의 근로자를 고용한다고 가정합니다. 한 주문이 들어오면 한 명의 작업자가 주문을 이행하고 다른 작업자는 유휴 상태입니다. 100개 또는 그 이상 주문이 접수되면 100명의 작업자 모두가 동시에 주문을 처리합니다. 지정된 기간 동안 활성 상태의 작업자 수를 주기적으로 샘플링하는 경우 평균 활성 근로자 수를 계산할 수 있습니다. 계산에 따르면 평균적으로 N명의 근로자가 주어진 시간에 주문을 이행하는 중입니다. 어제 평균 근로자가 50명이고 오늘 75명의 근로자라면 창고의 활동 수준은 높아진 것입니다. 마찬가지로 세션 활동이 증가함에 따라 DB 로드가 증가합니다.

자세한 내용은 Amazon Aurora 사용 설명서의 데이터베이스 로드 또는 Amazon RDS 사용 설명서의 데이터베이스 로드를 참조하십시오.

대기 이벤트

대기 이벤트는 데이터베이스 세션이 진행할 수 있도록 대기 중인 리소스를 알려주는 일종의 데이터베이스 계측입니다. 성능 개선 도우미는 활성 세션을 계산하여 데이터베이스 부하를 계산할 때 활성 세션을 기다리게 하는 대기 이벤트도 기록합니다. 이 기법을 사용하면 성능 개선 도우미에서 DB 로드에 영향을 미치는 대기 이벤트를 확인할 수 있습니다.

모든 활성 세션이 CPU에서 실행 중이거나 대기 중입니다. 예를 들어 세션은 메모리를 검색하거나 계산을 수행하거나 프로시저 코드를 실행할 때 CPU를 사용합니다. 세션에서 CPU를 사용하지 않는 경우, 읽을 데이터 파일 또는 기록할 로그가 나올 때까지 대기할 수 있습니다. 세션이 리소스를 기다리는 시간이 길수록 CPU에서 실행되는 시간이 줄어듭니다.

데이터베이스를 튜닝할 때 세션이 기다리는 리소스를 찾으려고 하는 경우가 많습니다. 예를 들어 두 개 또는 세 개의 대기 이벤트가 DB 로드의 90%를 차지할 수 있습니다. 이 측정은 평균적으로 활성 세션이 소수의 리소스를 기다리는 데 대부분의 시간을 소비한다는 것을 의미합니다. 이러한 대기의 원인을 찾을 수 있는 경우, 문제를 해결할 수 있습니다.

창고 작업자 비유를 기억하세요. 책에 대한 주문이 들어옵니다. 작업자의 주문 이행은 지연될 수 있습니다. 예를 들어 다른 작업자가 현재 선반을 재입고 중이거나 트롤리를 사용하지 못할 수 있습니다. 또는 주문 상태를 입력하는 데 사용된 시스템이 느릴 수 있습니다. 작업자가 기다리는 시간이 길수록 주문을 이행하는 것이 더 오래 걸립니다. 대기는 창고 워크플로의 자연스러운 부분이지만 대기 시간이 지나치게 되면 생산성이 떨어집니다. 같은 방식으로 세션 대기가 반복되거나 길면 데이터베이스 성능이 저하될 수 있습니다.

Amazon Aurora의 대기 이벤트에 관한 자세한 내용은 Amazon Aurora 사용 설명서의 Aurora PostgreSQL의 대기 이벤트를 사용한 튜닝과 Aurora MySQL의 대기 이벤트를 사용한 튜닝을 참조하세요.

다른 Amazon RDS 데이터베이스의 대기 이벤트에 대한 자세한 내용은 Amazon RDS 사용 설명서의 RDS for PostgreSQL의 대기 이벤트를 사용한 튜닝을 참조하십시오.