Aurora MySQL 데이터베이스의 워크로드 문제 해결 - Amazon Aurora
인스턴스 호스트 지표데이터베이스 지표

Aurora MySQL 데이터베이스의 워크로드 문제 해결

데이터베이스 워크로드는 읽기 및 쓰기로 볼 수 있습니다. '일반적인' 데이터베이스 워크로드를 이해하면 변화하는 수요에 맞춰 쿼리와 데이터베이스 서버를 튜닝할 수 있습니다. 성능이 변경될 수 있는 이유는 다양하므로 먼저 무엇이 변경되었는지 파악해야 합니다.

  • 메이저 버전 또는 마이너 버전 업그레이드가 있었나요?

    메이저 버전 업그레이드에는 쿼리 실행 계획을 변경할 수 있는 엔진 코드, 특히 최적화 프로그램의 변경 사항이 포함됩니다. 데이터베이스 버전, 특히 메이저 버전을 업그레이드할 때는 데이터베이스 워크로드를 분석하고 그에 따라 튜닝하는 것이 매우 중요합니다. 튜닝에는 테스트 결과에 따라 쿼리를 최적화 및 재작성하거나 파라미터 설정을 추가 및 업데이트하는 작업이 포함될 수 있습니다. 영향을 미치는 원인을 이해하면 해당 영역에 집중할 수 있습니다.

    자세한 내용은 MySQL 설명서의 What is new in MySQL 8.0과 Server and status variables and options added, deprecated, or removed in MySQL 8.0 및 Aurora MySQL 버전 2와 Aurora MySQL 버전 3의 비교 섹션을 참조하세요.

  • 처리 중인 데이터(행 수)가 증가했나요?

  • 동시에 실행되는 쿼리가 더 많나요?

  • 스키마 또는 데이터베이스 변경 사항이 있나요?

  • 코드 결함이나 수정이 있었나요?

목차

인스턴스 호스트 지표

CPU, 메모리, 네트워크 활동과 같은 인스턴스 호스트 지표를 모니터링하면 워크로드 변경 여부를 이해하는 데 도움이 됩니다. 워크로드 변화를 이해하는 데는 두 가지 주요 개념이 있습니다.

  • 사용률 - CPU 또는 디스크와 같은 디바이스의 사용량. 시간 기반 또는 용량 기반일 수 있습니다.

    • 시간 기반 - 특정 관찰 기간 동안 리소스가 많이 사용된 시간

    • 용량 기반 - 시스템 또는 구성 요소가 제공할 수 있는 처리량(용량의 백분율)

  • 포화도 - 리소스에 처리할 수 있는 것보다 더 많은 작업이 필요한 정도. 용량 기준 사용량이 100%에 도달하면 추가 작업을 처리할 수 없으므로 대기열에 추가되어야 합니다.

CPU 사용량

다음 도구를 사용하여 CPU 사용량 및 포화도를 파악할 수 있습니다.

  • CloudWatch는 CPUUtilization 지표를 제공합니다. 이 수치가 100%에 도달하면 인스턴스가 포화 상태입니다. 하지만 CloudWatch 지표는 1분 단위로 평균을 낸 값이며 세분성이 부족합니다.

    CloudWatch 지표에 대한 자세한 내용은 Amazon Aurora에 대한 인스턴스 수준 지표 섹션을 참조하세요.

  • 향상된 모니터링은 운영 체제 top 명령으로 반환된 지표를 제공합니다. 로드 평균과 다음 CPU 상태를 1초 단위로 보여줍니다.

    • Idle (%) = 유휴 시간

    • IRQ (%) = 소프트웨어 중단

    • Nice (%) = Niced 우선순위가 있는 프로세스의 Nice 시간

    • Steal (%) = 다른 테넌트에게 서비스를 제공하는 데 소요된 시간(가상화 관련)

    • System (%) = 시스템 시간

    • User (%) = 사용자 시간

    • Wait (%) = I/O 대기

    향상된 모니터링 지표에 대한 자세한 내용은 Aurora​의 지표 섹션을 참조하세요.

메모리 사용량

시스템이 메모리 부족 상태이고 리소스 사용량이 포화 상태에 이르면 페이지 스캔, 페이징, 교체 및 메모리 부족 오류가 많이 발생합니다.

다음 도구를 사용하여 메모리 사용량 및 포화도를 파악할 수 있습니다.

CloudWatch는 일부 OS 캐시와 현재 사용 가능한 메모리를 비워서 회수할 수 있는 메모리 양을 보여주는 FreeableMemory 지표를 제공합니다.

CloudWatch 지표에 대한 자세한 내용은 Amazon Aurora에 대한 인스턴스 수준 지표 섹션을 참조하세요.

향상된 모니터링은 메모리 사용 문제를 식별하는 데 도움이 되는 다음과 같은 지표를 제공합니다.

  • Buffers (KB) - 스토리지 디바이스에 쓰기 전에 I/O 요청을 버퍼링하는 데 사용되는 메모리의 양(KB)

  • Cached (KB) - 파일 시스템 기반 I/O를 캐시하는 데 사용된 메모리의 양

  • Free (KB) - 할당되지 않은 메모리의 양(KB)

  • Swap - 캐시됨, 사용할 수 있음, 합계

예를 들어 DB 인스턴스에서 Swap 메모리를 사용하는 경우 워크로드의 총 메모리 용량은 현재 인스턴스에서 사용할 수 있는 양보다 큽니다. DB 인스턴스의 크기를 늘리거나 메모리 사용량을 줄이도록 워크로드를 튜닝하는 것이 좋습니다.

향상된 모니터링 지표에 대한 자세한 내용은 Aurora​의 지표 섹션을 참조하세요.

성능 스키마 및 sys 스키마를 사용하여 메모리를 사용하는 연결 및 구성 요소를 확인하는 방법에 대한 자세한 내용은 Aurora MySQL 데이터베이스의 메모리 사용량 문제 해결 섹션을 참조하세요.

네트워크 처리량

CloudWatch는 총 네트워크 처리량에 대해 다음과 같은 지표를 제공하며, 모두 1분 단위로 평균을 낸 값입니다.

  • NetworkReceiveThroughput - Aurora DB 클러스터의 각 인스턴스가 클라이언트에서 수신하는 네트워크 처리량

  • NetworkTransmitThroughput - Aurora DB 클러스터의 각 인스턴스가 클라이언트로 전송하는 네트워크 처리량

  • NetworkThroughput - Aurora DB 클러스터의 각 인스턴스가 클라이언트에서 수신하고 클라이언트로 전송하는 네트워크 처리량

  • StorageNetworkReceiveThroughput - DB 클러스터의 각 인스턴스가 Aurora 스토리지 하위 시스템에서 수신하는 네트워크 처리량

  • StorageNetworkTransmitThroughput - Aurora DB 클러스터의 각 인스턴스가 Aurora 스토리지 하위 시스템으로 전송하는 네트워크 처리량

  • StorageNetworkThroughput - Aurora DB 클러스터의 각 인스턴스가 Aurora 스토리지 하위 시스템과 송수신하는 네트워크 처리량

CloudWatch 지표에 대한 자세한 내용은 Amazon Aurora에 대한 인스턴스 수준 지표 섹션을 참조하세요.

향상된 모니터링은 network 수신(RX) 및 전송(TX) 그래프를 최대 1초의 세부 단위로 제공합니다.

향상된 모니터링 지표에 대한 자세한 내용은 Aurora​의 지표 섹션을 참조하세요.

데이터베이스 지표

워크로드 변화에 대한 다음 CloudWatch 지표를 살펴보세요.

  • BlockedTransactions - 데이터베이스에서 1초마다 차단되는 평균 트랜잭션 수

  • BufferCacheHitRatio - 버퍼 캐시에서 처리하는 요청 비율

  • CommitThroughput - 초당 커밋 작업의 평균 수

  • DatabaseConnections - 데이터베이스 인스턴스에 대한 클라이언트 네트워크 연결 수

  • Deadlocks - 데이터베이스 1초마다 발생하는 평균 교착 수

  • DMLThroughput - 초당 평균 삽입, 업데이트 및 삭제 수

  • ResultSetCacheHitRatio - 쿼리 캐시에서 처리하는 요청 비율

  • RollbackSegmentHistoryListLength - 삭제 표시 레코드로 커밋된 트랜잭션을 기록하는 실행 취소 로그

  • RowLockTime - InnoDB 테이블에 대한 행 잠금을 획득하는 데 걸린 총 시간

  • SelectThroughput - 초당 평균 선택 쿼리 수

CloudWatch 지표에 대한 자세한 내용은 Amazon Aurora에 대한 인스턴스 수준 지표 섹션을 참조하세요.

워크로드를 검토할 때는 다음 질문을 고려해 보세요.

  1. 인스턴스 크기를 8xlarge에서 4xlarge로 줄이거나 db.r5에서 db.r6으로 변경하는 등 최근에 DB 인스턴스 클래스를 변경했나요?

  2. 클론을 생성하여 문제를 재현할 수 있나요? 아니면 해당 인스턴스에서만 발생하나요?

  3. 서버 리소스 고갈, 높은 CPU 또는 메모리 고갈이 있나요? 그렇다면 추가 하드웨어가 필요할 수 있습니다.

  4. 하나 이상의 쿼리가 더 오래 걸리나요?

  5. 변경 사항이 업그레이드, 특히 메이저 버전 업그레이드로 인해 발생했나요? 그렇다면 업그레이드 전후 지표를 비교하세요.

  6. 리더 DB 인스턴스 수에 변화가 있나요?

  7. 일반, 감사 또는 바이너리 로깅을 활성화했나요? 자세한 내용은 Aurora MySQL 데이터베이스에 대한 로깅 단원을 참조하십시오.

  8. 바이너리 로그(binlog) 복제 사용을 활성화, 비활성화 또는 변경나요?

  9. 다수의 행 잠금이 있는 장기 실행 트랜잭션이 있나요? InnoDB 기록 목록 길이(HLL)에서 장기 실행 트랜잭션의 징후를 확인하세요.

    자세한 내용은 InnoDB 기록 목록 길이가 크게 늘어남 및 Amazon Aurora MySQL DB 클러스터에서 SELECT 쿼리가 느리게 실행되는 이유는 무엇인가요? 블로그 게시물을 참조하세요.

    1. 쓰기 트랜잭션으로 인해 큰 HLL이 발생한 경우 UNDO 로그가 누적되고 있다는 의미입니다(정기적으로 정리되지 않음). 대규모 쓰기 트랜잭션의 경우 이 누적이 빠르게 증가할 수 있습니다. MySQL에서는 UNDO가 SYSTEM 테이블스페이스에 저장됩니다. SYSTEM 테이블스페이스는 축소할 수 없습니다. UNDO 로그로 인해 SYSTEM 테이블스페이스가 몇 GB, 심지어는 몇 TB까지 증가할 수 있습니다. 삭제 후에는 데이터를 논리적으로 백업(덤프)하여 할당된 공간을 해제한 다음 덤프를 새 DB 인스턴스로 가져오세요.

    2. 읽기 트랜잭션(장기 실행 쿼리)으로 인해 큰 HLL이 발생하는 경우 쿼리가 많은 양의 임시 공간을 사용하고 있다는 의미일 수 있습니다. 재부팅하여 임시 공간을 해제하세요. 성능 개선 도우미 DB 지표를 검토하여 Temp 섹션의 변경 사항(예: created_tmp_tables)이 있는지 확인하세요. 자세한 내용은 성능 개선 도우미를 통한 Amazon Aurora 모니터링 단원을 참조하십시오.

  10. 장기 실행 트랜잭션을 더 적은 행을 수정하는 더 작은 트랜잭션으로 분할할 수 있나요?

  11. 차단된 트랜잭션에 변경 사항이 있거나 교착 상태가 증가했나요? 성능 개선 도우미 DB 지표를 검토하여 Locks 섹션의 상태 변수 변경 사항(예: innodb_row_lock_time, innodb_row_lock_waits, innodb_dead_locks)이 있는지 확인하세요. 1분 또는 5분의 간격을 사용하세요.

  12. 대기 이벤트가 늘어났나요? 1분 또는 5분 간격을 사용하여 성능 개선 도우미의 대기 이벤트와 대기 유형을 검사하세요. 상위 대기 이벤트를 분석하고 이러한 이벤트가 워크로드 변경 또는 데이터베이스 경합과 상관관계가 있는지 확인하세요. 예를 들어, buf_pool mutex는 버퍼 풀 경합을 나타냅니다. 자세한 내용은 대기 이벤트로 Aurora MySQL 튜닝 단원을 참조하십시오.