# 인스턴스별 성능 및 리소스 모니터링
<a name="limitless-instance-monitoring"></a>

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

## 개요
<a name="limitless-instance-monitoring-overview"></a>

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

이 가이드는 인스턴스 아키텍처에 대한 심층적인 기술 인사이트를 제공합니다.
+ Limitless Architecture 리프레셔, 라우터 및 샤드
+ 성능 및 용량 요구 사항에 맞게 각 인스턴스 유형을 확장하는 시기와 방법
+ 인스턴스 수준 성능을 모니터링, 문제 해결 및 최적화하는 방법
+ 분산 아키텍처를 효과적으로 활용하는 애플리케이션 설계 모범 사례

## 인스턴스 아키텍처 기초는
<a name="limitless-instance-monitoring-architecture"></a>

 두 가지 특수 인스턴스 유형에서 기능적 분리를 통해 수평적 확장성을 달성합니다.
+ **라우터 인스턴스**는 오케스트레이션 계층을 제공합니다. 오케스트레이션 계층은 클라이언트 연결을 수락하고, 쿼리를 분석하고, 분산 작업을 조정하고, 결과를 집계합니다. 라우터는 상태 비저장이므로 데이터를 저장하지 않으며 데이터 마이그레이션 없이 추가하거나 제거할 수 있습니다.
+ **샤드 인스턴스**는 테이블 데이터를 저장하고, 로컬 데이터에 대해 쿼리를 실행하고, 트랜잭션을 처리하는 데이터 및 컴퓨팅 계층을 제공합니다. 샤드는 상태 저장형이며, 각 샤드는 일관된 해싱으로 결정되는 데이터의 특정 하위 집합을 소유합니다.

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

### 라우터와 샤드 비교
<a name="limitless-instance-monitoring-comparison"></a>


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

## 인스턴스 성능 모니터링
<a name="limitless-instance-monitoring-performance"></a>

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

### 편중 감지
<a name="limitless-instance-monitoring-skew"></a>

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

모니터링할 편중의 세 가지 유형은 다음과 같습니다.
+ **연결 편중**: 라우터 간 클라이언트 연결의 고르지 않은 분산
+ **워크로드 편중**: 핫 샤드 키로 인한 샤드 간 고르지 않은 쿼리 로드
+ **데이터 편중**: 샤드 키 빈도로 인해 샤드 간에 고르지 않은 데이터 볼륨

### Database Insights 로드 배포
<a name="limitless-instance-monitoring-insights"></a>

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

배포 액세스 로깅

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

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

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

**정상 패턴:** 인스턴스 간에 비교적 균등하게 로드 분산
+ 라우터가 샤드보다 약간 높은 AAS를 표시할 수 있습니다(협정 오버헤드).
+ 서로의 20% 내에 있는 샤드 AAS 값은 균형이 양호함을 나타냅니다.

**우려되는 패턴:** 특정 인스턴스에 상당한 집중
+ 라우터 로드의 >70%인 라우터 1개 → 연결 편중
+ 샤드 로드의 >50%인 샤드 1개 → 워크로드 또는 데이터 편중
+ 샤드 간 큰 분산 → 샤드 키 배포 조사

### CloudWatch 지표
<a name="limitless-instance-monitoring-cloudwatch"></a>

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

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

**조사 시기:**
+ 라우터 ACU 분산 >30% → 연결 편중 또는 교차 샤드 워크로드 집중
+ 샤드 ACU 분산 >40% → 데이터 또는 워크로드 편중
+ 최대 ACU에서 일관되게 모든 인스턴스 → 용량 제약 조건

## 라우터 모니터링 및 문제 해결
<a name="limitless-instance-monitoring-router"></a>

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

### 고르지 않은 분산 세션
<a name="limitless-instance-monitoring-router-connections"></a>

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

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

**가장 일반적인 경우는 다음과 같습니다.**
+ pgbench와 같은 도구를 사용한 벤치마킹
+ 연결 풀 초기화(대부분의 연결이 빠르게 설정됨)
+ 애플리케이션 서버 재시작

**해결 방법:**
+ 콘솔에 지정된 Limitless 엔드포인트를 사용해야 합니다.
+ 수동 밸런싱: 라우터 엔드포인트를 추출하고 서로 다른 애플리케이션을 서로 다른 라우터에 연결
+ libpq 애플리케이션의 경우 `LOADBALANCEHOSTS` 기능을 사용합니다.
+ JDBC 애플리케이션의 경우 Limitless Connection 플러그인 사용
+ NLB를 사용하여 세션 및 배포 관리

## 샤드 모니터링 및 문제 해결
<a name="limitless-instance-monitoring-shard"></a>

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

### 샤드 리소스 사용
<a name="limitless-instance-monitoring-shard-utilization"></a>

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

**문제 해결 전략:**

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

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

**샤드를 분할하는 경우:**
+ 최대 ACU가 >80%인 단일 샤드
+ 단일 샤드 용량으로 제한된 쿼리 처리량

### 샤드 데이터 볼륨
<a name="limitless-instance-monitoring-shard-data"></a>

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');
```

### 고르지 않은 사용률 해결
<a name="limitless-instance-monitoring-shard-split"></a>

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

중요 고려 사항:
+ 이동할 샤드 키를 제어할 수 없음
+ 분할 전에 생성된 수동 스냅샷으로 복구하지 않고 분할을 취소할 수 있는 방법은 없습니다.
+ 새 샤드를 포함한 모든 인스턴스는 유휴 시 인스턴스 최소 ACU를 사용합니다.

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

## 제한 사항
<a name="limitless-instance-monitoring-limitations"></a>

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

**라우터 제한 사항:**
+ **라우터를 제거할 수 없음** - 추가된 라우터는 클러스터에 남아 있습니다.
+ 불필요한 기준 비용을 방지하기 위해 라우터 추가를 신중하게 계획합니다.

**샤드 제한 사항:**
+ **샤드를 병합할 수 없음** - 샤드 분할은 단방향 작업입니다.
+ 복구 옵션만 해당: 분할 전에 생성된 스냅샷에서 복원

**완화 전략**
+ 최소 실행 가능 인스턴스 수로 시작
+ 필요에 따라 용량을 점진적으로 추가
+ 주요 토폴로지 변경 전에 스냅샷 생성
+ 클러스터 증가에 따른 기준 비용 모니터링