인스턴스별 성능 및 리소스 모니터링 - Amazon Aurora

인스턴스별 성능 및 리소스 모니터링

인스턴스 수준에서 모니터링하는 것은 연결 편중, 워크로드 편중 및 데이터 편중을 이해하고 라우터를 추가하거나 샤드를 분할하여 지연 시간을 유지하면서 처리량을 늘리는 데 중요합니다.

개요

애플리케이션이에 대해 쿼리를 실행하면 해당 요청은 결과를 반환하기 전에 정교한 분산 시스템을 통과합니다. 간결해 보이는 SELECT 문은 요청을 처리하는 데 각각 고유한 역할을 하는 여러 데이터베이스 인스턴스와 접촉할 수 있습니다. 이 여정과 이를 지원하는 인스턴스를 이해하면 애플리케이션을 설계하고, 모니터링 데이터를 해석하고, 성능 문제를 진단하는 방법이 혁신됩니다.

이 가이드는 인스턴스 아키텍처에 대한 심층적인 기술 인사이트를 제공합니다.

  • Limitless Architecture 리프레셔, 라우터 및 샤드

  • 성능 및 용량 요구 사항에 맞게 각 인스턴스 유형을 확장하는 시기와 방법

  • 인스턴스 수준 성능을 모니터링, 문제 해결 및 최적화하는 방법

  • 분산 아키텍처를 효과적으로 활용하는 애플리케이션 설계 모범 사례

인스턴스 아키텍처 기초는

두 가지 특수 인스턴스 유형에서 기능적 분리를 통해 수평적 확장성을 달성합니다.

  • 라우터 인스턴스는 오케스트레이션 계층을 제공합니다. 오케스트레이션 계층은 클라이언트 연결을 수락하고, 쿼리를 분석하고, 분산 작업을 조정하고, 결과를 집계합니다. 라우터는 상태 비저장이므로 데이터를 저장하지 않으며 데이터 마이그레이션 없이 추가하거나 제거할 수 있습니다.

  • 샤드 인스턴스는 테이블 데이터를 저장하고, 로컬 데이터에 대해 쿼리를 실행하고, 트랜잭션을 처리하는 데이터 및 컴퓨팅 계층을 제공합니다. 샤드는 상태 저장형이며, 각 샤드는 일관된 해싱으로 결정되는 데이터의 특정 하위 집합을 소유합니다.

이러한 분리를 통해는 워크로드 특성에 따라 연결 처리, 쿼리 조정 및 데이터 스토리지를 독립적으로 확장할 수 있습니다.

라우터와 샤드 비교

기능 라우터 인스턴스 샤드 인스턴스
기본 역할 쿼리 조정 및 배포 데이터 스토리지 및 쿼리 실행
State 상태 비저장(데이터 스토리지 없음) 상태 저장(데이터 소유)
확장성 즉시 추가/제거 데이터 리밸런싱 필요
리소스 포커스 조정을 위한 CPU, 중간 메모리 쿼리용 CPU, 캐시용 고용량 메모리
조정 트리거 높은 연결 수, 분산 txn 속도 높은 CPU, 데이터 볼륨, 쿼리 처리량

인스턴스 성능 모니터링

인스턴스 수준 성능을 이해하는 것은 효과적인 운영에 매우 중요합니다. 인스턴스별 모니터링은 연결 편중, 워크로드 편중, 데이터 편중 등 성능에 영향을 미치는 분산 패턴을 보여줍니다.

편중 감지

이상적인 배포에서는 워크로드와 리소스가 인스턴스 간에 균등하게 분산됩니다. 실제로 애플리케이션은 특정 인스턴스에 로드를 집중시키는 고르지 않은 분산을 자주 경험합니다.

모니터링할 편중의 세 가지 유형은 다음과 같습니다.

  • 연결 편중: 라우터 간 클라이언트 연결의 고르지 않은 분산

  • 워크로드 편중: 핫 샤드 키로 인한 샤드 간 고르지 않은 쿼리 로드

  • 데이터 편중: 샤드 키 빈도로 인해 샤드 간에 고르지 않은 데이터 볼륨

Database Insights 로드 배포

인스턴스 수준 상태를 평가하는 가장 빠른 방법은 Database Insights의 로드 분산 보기로, 활성 세션이 인스턴스 간에 배포되는 방식을 즉시 파악할 수 있습니다.

배포 액세스 로깅

  1. RDS 콘솔 → Limitless 클러스터로 이동

  2. '성능 개선 도우미' 탭을 선택합니다.

  3. '배포 로드' 섹션을 클릭합니다.

정상 패턴: 인스턴스 간에 비교적 균등하게 로드 분산

  • 라우터가 샤드보다 약간 높은 AAS를 표시할 수 있습니다(협정 오버헤드).

  • 서로의 20% 내에 있는 샤드 AAS 값은 균형이 양호함을 나타냅니다.

우려되는 패턴: 특정 인스턴스에 상당한 집중

  • 라우터 로드의 >70%인 라우터 1개 → 연결 편중

  • 샤드 로드의 >50%인 샤드 1개 → 워크로드 또는 데이터 편중

  • 샤드 간 큰 분산 → 샤드 키 배포 조사

CloudWatch 지표

Database Insights 이외의 심층 분석을 위해 CloudWatch는 리소스 사용률 패턴을 나타내는 인스턴스별 지표를 제공합니다.

DBShardGroupInstance 차원이 있는 ServerlessDatabaseCapacity 지표는 인스턴스당 ACU 소비를 표시하여 리소스 사용률에 대한 가장 직접적인 보기를 제공합니다.

조사 시기:

  • 라우터 ACU 분산 >30% → 연결 편중 또는 교차 샤드 워크로드 집중

  • 샤드 ACU 분산 >40% → 데이터 또는 워크로드 편중

  • 최대 ACU에서 일관되게 모든 인스턴스 → 용량 제약 조건

라우터 모니터링 및 문제 해결

라우터는 고르지 않은 연결 분산과 교차 샤드 워크로드 집중이라는 두 가지 주요 원인으로 인해 성능 문제를 겪을 수 있습니다.

고르지 않은 분산 세션

증상: 라우터 하나가 불균형한 연결 공유를 처리합니다.

근본 원인: DNS 캐싱으로 인해 여러 연결 요청이 동일한 라우터 엔드포인트로 확인됩니다.

가장 일반적인 경우는 다음과 같습니다.

  • pgbench와 같은 도구를 사용한 벤치마킹

  • 연결 풀 초기화(대부분의 연결이 빠르게 설정됨)

  • 애플리케이션 서버 재시작

해결 방법:

  • 콘솔에 지정된 Limitless 엔드포인트를 사용해야 합니다.

  • 수동 밸런싱: 라우터 엔드포인트를 추출하고 서로 다른 애플리케이션을 서로 다른 라우터에 연결

  • libpq 애플리케이션의 경우 LOADBALANCEHOSTS 기능을 사용합니다.

  • JDBC 애플리케이션의 경우 Limitless Connection 플러그인 사용

  • NLB를 사용하여 세션 및 배포 관리

샤드 모니터링 및 문제 해결

샤드는 리소스 제약, 데이터 편중, 워크로드 편중의 세 가지 주요 원인으로 인해 성능 문제를 겪습니다.

샤드 리소스 사용

널리 사용되는 샤드 키가 있는 샤드에는 더 많은 데이터와 더 높은 워크로드가 있습니다. 이는 리소스 사용률로 매니페스트됩니다. 즉, 인스턴스는 더 많은 ACU를 소비합니다.

문제 해결 전략:

  1. 샤드 키 선택 재평가: 샤드 키 카디널리티 및 액세스 패턴을 검토합니다. 더 나은 배포를 위해 복합 샤드 키를 고려합니다.

  2. 샤드 분할: 더 많은 샤드 인스턴스에 로드 분산

샤드를 분할하는 경우:

  • 최대 ACU가 >80%인 단일 샤드

  • 단일 샤드 용량으로 제한된 쿼리 처리량

샤드 데이터 볼륨

SQL 함수를 사용하여 데이터 볼륨을 쿼리합니다.

SELECT subcluster_id, subcluster_type, pg_size_pretty(db_size) FROM rds_aurora.limitless_stat_database_size('postgres_limitless') ORDER BY 1;

테이블별 및 샤드별 데이터를 보려면 다음을 수행합니다.

SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public', 'table_name');

고르지 않은 사용률 해결

워크로드 또는 데이터 편중이 특정 샤드에 집중되면 샤드를 분할하면 더 많은 인스턴스에 로드가 재배포됩니다.

중요 고려 사항:

  • 이동할 샤드 키를 제어할 수 없음

  • 분할 전에 생성된 수동 스냅샷으로 복구하지 않고 분할을 취소할 수 있는 방법은 없습니다.

  • 새 샤드를 포함한 모든 인스턴스는 유휴 시 인스턴스 최소 ACU를 사용합니다.

샤드를 분할하면 추가 조정이 가능하며, 연속 샤드 분할은 짧은 지연 시간을 유지하면서 처리량을 높이고 확장할 수 있는 경로입니다.

제한 사항

다음 운영 제약 조건에 유의하세요.

라우터 제한 사항:

  • 라우터를 제거할 수 없음 - 추가된 라우터는 클러스터에 남아 있습니다.

  • 불필요한 기준 비용을 방지하기 위해 라우터 추가를 신중하게 계획합니다.

샤드 제한 사항:

  • 샤드를 병합할 수 없음 - 샤드 분할은 단방향 작업입니다.

  • 복구 옵션만 해당: 분할 전에 생성된 스냅샷에서 복원

완화 전략

  • 최소 실행 가능 인스턴스 수로 시작

  • 필요에 따라 용량을 점진적으로 추가

  • 주요 토폴로지 변경 전에 스냅샷 생성

  • 클러스터 증가에 따른 기준 비용 모니터링