적합한 DB 인스턴스 클래스 선택

적합한 인스턴스 클래스는 외부 테이블 쿼리가 메모리, 스토리지, CPU를 사용하는 방식에 따라 달라집니다. 이러한 각 리소스에 대한 자세한 내용은 리소스 관리 섹션을 참조하세요.

• 메모리: 외부 테이블 쿼리는 작업 데이터(정렬, 집계, 조인용 해시 테이블)를 메모리에 저장하며, 이 용량은 aurora_analytics.query_mem 설정(줄여서 query_mem)에 의해 제한됩니다. query_mem의 기본값은 인스턴스 크기에 따라 조정되므로 인스턴스 크기가 클수록 각 쿼리에 자동으로 더 많은 메모리가 할당됩니다. 쿼리가 query_mem 용량을 초과하면 작업 데이터가 로컬 스토리지로 스필되며, 이 경우 처리 속도가 느려집니다. 자세한 내용은 섹션을 참조하세요워크로드에 맞춘 query_mem 튜닝

• 동시성: 동시 실행되는 각 외부 테이블 쿼리는 최대 query_mem까지 메모리를 할당받지만, 실제 사용량은 쿼리에 따라 다르며 단순한 쿼리는 훨씬 적은 메모리를 사용할 수도 있습니다. 동시성 설계를 위해 규모를 조정하는 경우 모든 쿼리가 query_mem 전체를 사용한다고 가정하는 대신 최대 메모리 사용량을 기준으로 예산을 책정하세요. 자세한 내용은 섹션을 참조하세요동시성 규모 조정

• 캐싱 및 스필: Amazon S3 데이터용 온디스크 캐시와 쿼리에서 스필되는 임시 파일은 모두 인스턴스의 로컬 스토리지를 사용합니다. 로컬 NVMe(db.r8gd와 같은 d 유형 인스턴스에서 사용 가능)는 캐시와 스필 작업 모두에서 Amazon EBS보다 속도가 빠르므로, 외부 테이블을 쿼리하는 프로덕션 워크로드에는 로컬 NVMe 스토리지가 포함된 클래스를 선택하세요.

• 워크로드 격리: 외부 테이블 쿼리는 CPU와 메모리를 두고 인스턴스의 다른 트래픽과 경쟁합니다. 외부 테이블을 많이 쿼리하는 워크로드의 경우 대신 전용 리더에서 실행합니다. 외부 테이블 쿼리 비중이 높은 워크로드의 경우, 대신 전용 리더에서 실행하세요. 자세한 내용은 섹션을 참조하세요분석에 전용 리더 인스턴스 사용

워크로드에 맞는 클래스로 시작하고 다음 신호를 바탕으로 클래스를 조정하세요.

• AuroraAnalyticsMemoryUsage가 상승하는 것은 전체 메모리 압박이 커지고 있음을 의미합니다. 더 큰 인스턴스 클래스로 스케일 업하거나 query_mem을 낮춰 동시 실행을 위한 여유 공간을 확보하세요.

• AuroraAnalyticsDiskSpillSize가 상승하는 것은 개별 쿼리가 query_mem 용량을 초과하여 로컬 스토리지로 스필되고 있음을 의미합니다. 스케일 업하거나 query_mem을 높여 각 쿼리를 위한 여유 공간을 더 확보하세요.

• AuroraAnalyticsCacheHitRatio가 하락하는 것은 Amazon S3에서 더 많은 작업 데이터를 다시 읽어오고 있음을 의미합니다. 더 큰 인스턴스 클래스를 사용하면 더 많은 작업 데이터를 로컬에 캐싱할 수 있습니다.

• 외부 테이블을 쿼리할 때 CPU 사용량이 높다는 것은 쿼리에 더 많은 vCPU가 필요함을 의미합니다.

더 많은 동시 실행 쿼리를 처리하려면 메모리 여유 공간을 늘리기 위해 스케일 업하거나, 로드를 분산할 수 있도록 리더를 추가하세요.

이러한 지표와 지표를 모니터링하는 방법은 모니터링 및 문제 해결 섹션을 참조하세요.

EBS 전용 인스턴스를 사용해야 하는 경우

로컬 NVMe 스토리지(예: db.r8g 및 db.r8i)가 없는 인스턴스는 캐싱을 위해 Amazon EBS를 사용합니다. 이러한 인스턴스는 다음과 같은 경우에 사용하세요.

• 성능보다 비용에 더 민감한 워크로드

• 가벼운 쿼리 또는 임시 외부 테이블 쿼리

• 개발 및 테스트 환경