Amazon Timestream for LiveAnalytics와 유사한 기능을 원하는 경우 Amazon Timestream for InfluxDB를 고려해 보세요. 간소화된 데이터 수집과 실시간 분석을 위한 10밀리초 미만의 쿼리 응답 시간을 제공합니다. [여기](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)에서 자세히 알아보세요.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# InfluxDB 2의 Timestream에 대한 모니터링 및 구성 최적화
## 개요
효과적인 모니터링 및 구성 최적화는 Timestream for InfluxDB 배포에서 최적의 성능, 안정성 및 비용 효율성을 유지하는 데 매우 중요합니다. 이 가이드에서는 InfluxDB 인스턴스를 사전에 관리하는 데 도움이 되는 CloudWatch 지표, 성능 임계값 및 구성 튜닝 전략에 대한 포괄적인 지침을 제공합니다.
## CloudWatch 지표 참조
Amazon CloudWatch는 Timestream for InfluxDB 인스턴스를 모니터링하기 위한 자세한 지표를 제공합니다. 이러한 지표와 임계값을 이해하는 것은 시스템 상태 및 성능을 유지하는 데 필수적입니다.
### 리소스 사용률 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
| --- | --- | --- | --- | --- |
| CPUUtilization | DbInstanceName | 사용 중인 CPU의 백분율 | % | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | 사용 중인 메모리의 백분율 | % | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | 사용 중인 힙 메모리의 양 | 바이트 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | 현재 활성 메모리 할당 | 바이트 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | 사용 중인 디스크 공간의 백분율 | % | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### I/O 작업 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
| --- | --- | --- | --- | --- |
| ReadOpsPerSec | DbInstanceName | 초당 읽기 작업 수 | 개수/초 | 프로비저닝된 IOPS 미만으로 ≥ 30% 헤드룸 유지예: 12K IOPS → 총 < 8,400 IOPS 유지 |
| WriteOpsPerSec | DbInstanceName | 초당 쓰기 작업 수 | 개수/초 | 프로비저닝된 IOPS 미만으로 ≥ 30% 헤드룸 유지예: 12K IOPS → 총 < 8,400 IOPS 유지 |
| TotalIOpsPerSec | DbInstanceName | 초당 총 I/O 작업 수(읽기 \$1 쓰기) | 개수/초 | 프로비저닝된 IOPS 미만으로 ≥ 30% 헤드룸 유지인스턴스 클래스 기능에 대한 모니터링 |
### 처리량 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
| --- | --- | --- | --- | --- |
| ReadThroughput | DbInstanceName | 데이터 읽기 처리량 | 바이트/초 | 스토리지 처리량 제한을 기준으로 모니터링 |
| WriteThroughput | DbInstanceName | 데이터 쓰기 처리량 | 바이트/초 | 스토리지 처리량 제한을 기준으로 모니터링 |
### API 성능 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
| --- | --- | --- | --- | --- |
| APIRequestRate | DbInstanceName, 엔드포인트, 상태 | 상태 코드가 있는 특정 엔드포인트에 대한 API 요청 속도(2xx, 4xx, 5xx) | 개수/초 | 오류 발생률: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName, 엔드포인트, 상태 | 엔드포인트 및 상태 코드별 쿼리 응답 볼륨 | 바이트 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 쿼리 실행 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
| --- | --- | --- | --- | --- |
| QueryRequestsTotal | DbInstanceName, 결과 | 결과 유형별 총 쿼리 요청 수(성공, runtime\$1error, compile\$1error, queue\$1error) | 개수 | 성공률: > 99% 오류 발생률: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 데이터 조직 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 중요 임계값 |
| --- | --- | --- | --- | --- |
| SeriesCardinality | DbInstanceName, 버킷 | 버킷의 고유 시계열 수 | 개수 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | 인스턴스의 총 버킷 수 | 개수 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### 시스템 상태 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
| --- | --- | --- | --- | --- |
| EngineUptime | DbInstanceName | InfluxDB 엔진이 실행된 시간 | 초 | 예기치 않은 재시작 모니터링알림: 가동 시간이 예기치 않게 재설정됨 |
| WriteTimeouts | DbInstanceName | 시간 초과된 쓰기 작업 수 | 개수 | 알림: 쓰기 작업의 > 0.1%심각: 증가 추세 |
### 작업 관리 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
| --- | --- | --- | --- | --- |
| ActiveTaskWorkers | DbInstanceName | 활성 작업 작업자 수 | 개수 | 구성된 작업 작업자 제한에 대해 모니터링알림: 일관되게 최대 |
| TaskExecutionFailures | DbInstanceName | 실패한 작업 실행 수 | 개수 | 알림: 태스크 실행의 > 1%심각: 실패율 증가 |
### 주요 지표 관계 이해
#### IOPS 및 처리량 관계
**30% 헤드룸 규칙:** 지속적인 초당 작업과 프로비저닝된 IOPS 사이에 항상 최소 **30%의 헤드룸**을 유지합니다. 이는 다음에 대한 버퍼를 제공합니다.
+ 압축 작업(IOPS를 크게 급증시킬 수 있음)
+ 원활한 실행을 위한 모든 데이터베이스 재시작
+ 사용량이 가장 많은 동안 버스트 쿼리
+ 배치 수집에서 스파이크 쓰기
+ 인덱스 유지 관리 작업
**계산 예:**
+ 프로비저닝된 IOPS: 12,000
+ 목표 최대 지속 IOPS(TotalIOpsPerSec): 8,400(70% 사용률)
+ 예약 헤드룸: 3,600IOPS(30%)
TotalIOpsPerSec가 지속적으로 8,400을 초과하는 경우: → 스토리지 계층을 업그레이드하거나 워크로드를 최적화합니다.
**모니터링 공식:**
IOPS 사용률 % = (ReadOpsPerSec \$1 WriteOpsPerSec) / 프로비저닝된 IOPS × 100
+ 대상: IOPS 사용률 < 70% 유지
+ 경고: IOPS 사용률 > 70%
+ 심각: IOPS 사용률 > 90%
### 시리즈 카디널리티 성능 영향 이해
시리즈 카디널리티는 시스템 리소스에 여러 효과를 미칩니다.
| **시리즈 수** | **메모리 영향** | **쿼리 성능 영향** | **인덱스 크기 영향** | **권장 사항** |
| --- | --- | --- | --- | --- |
| < 100K | 최소화 | 무시할 수 있음 | 작은 | 표준 구성 |
| 100K\$11M | 보통 | 10\$120% 느림 | 중간 | 캐시 설정 튜닝 |
| 1M\$15M만 | 중요 | 30\$150% 느림 | 대형 | 적극적인 최적화 필요 |
| 5M\$110M | 높음 | 50\$170% 느림 | 매우 큼 | 최대 튜닝, 재설계 고려 |
| > 10M | 심각 | 70% 이상 느림 | 과도한 | InfluxDB 3.0으로 마이그레이션 |
**10M이 중요 임계값인 이유:**
+ InfluxDB 2.x 아키텍처는 인 메모리 인덱싱을 사용합니다.
+ 10M 시리즈에서 인덱스 작업은 엄청난 비용이 듭니다.
+ 메모리 요구 사항이 비선형으로 증가
+ 쿼리 계획 오버헤드가 크게 증가
+ InfluxDB 3.0은 높은 카디널리티를 위해 설계된 열 기반 스토리지 엔진을 사용합니다.
## 인스턴스 크기 조정 및 성능 지침
다음 표는 시리즈 카디널리티 및 워크로드 특성에 따라 적절한 인스턴스 크기 조정에 대한 지침을 제공합니다.
| **최대 시리즈 수** | **쓰기(회선/초)** | **읽기(쿼리/초)** | **권장 인스턴스** | [**Storage Type**] | **사용 사례** |
| --- | --- | --- | --- | --- | --- |
| < 100K | \$150,000 | < 10 | db.influx.large | Influx IO 포함 3K | 소규모 배포, 개발, 테스트 |
| < 1M | \$1150000 | < 25 | db.influx.2xlarge | Influx IO 포함 3K | 중소 규모의 프로덕션 워크로드 |
| \$11백만 | \$1200,000 | \$125 | db.influx.4xlarge | Influx IO 포함 3K | 중간 프로덕션 워크로드 |
| < 5M | \$1250,000 | \$135 | db.influx.4xlarge | Influx IO 포함 12K | 대규모 프로덕션 워크로드 |
| < 10M | \$1500,000 | \$150 | db.influx.8xlarge | Influx IO 포함 12K | 매우 큰 프로덕션 워크로드 |
| \$11천만 | < 750,000 | < 100 | db.influx.12xlarge | Influx IO 포함 12K | 최대 InfluxDB 2.x 용량 |
| > 10M | 해당 사항 없음 | 해당 사항 없음 | InfluxDB 3.0으로 마이그레이션 | 해당 사항 없음 | InfluxDB 2.x 최적 범위 초과 |
## 지표별 구성 최적화
### 높은 CPU 사용률(CPUUtilization > 70%)
**증상:**
+ **CPUUtilization** > 70% 지속
+ **QueryRequestsTotal**(높은 볼륨 또는 느린 쿼리)
+ **ActiveTaskWorkers**(작업 부하 높음)
**구성 조정:**
**우선 순위 1: 쿼리 동시성 제어**
+ query-concurrency: vCPU 수의 50\$175%로 설정
+ 예: vCPU 인스턴스 8개 → query-concurrency = 4-6
**우선 순위 2: 쿼리 복잡성 제한**
+ influxql-max-select-series: 10000(무제한 쿼리 방지)
+ influxql-max-select-point: 100000000
+ query-queue-size: 2048(대기열 빌드 방지)
**우선 순위 3: 쿼리 분석 활성화**
+ flux-log-enabled: TRUE(디버깅의 경우 일시적으로)
+ 로그 수준: 정보(또는 세부 분석을 위한 디버그)
**중요 고려 사항:**
를 줄`query-concurrency`이면가 동시에 실행할 수 있는 쿼리 수가 제한되어 대기 중인 쿼리가 증가하고 피크 기간 동안 쿼리 지연 시간이 길어질 수 있습니다. 쿼리 수요가 축소된 동시성 제한을 초과하는 경우 대시보드 로드 속도가 느려지거나 제한 시간이 보고될 수 있습니다.
보호 제한(`influxql-max-select-series`, `influxql-max-select-point`)을 설정하면 QueryRequestsTotal의 **compile\$1error** 또는 **runtime\$1error**에서 이러한 임계값을 초과하는 쿼리가 실패합니다. **QueryRequestsTotal** 이렇게 하면 시스템이 리소스 소진으로부터 보호되지만 이전에 작동했던 기존 쿼리가 중단될 수 있습니다.
**모범 사례:** 이러한 변경 사항을 적용하기 전에 **QueryResponseVolume** 및 **QueryRequestsTotal** 지표를 사용하여 쿼리 패턴을 분석합니다. 가장 비용이 많이 드는 쿼리를 먼저 식별하고 최적화 - 시간 범위 필터가 없는 쿼리, 높은 카디널리티 시리즈에 걸친 쿼리 또는 과도한 데이터 포인트를 요청하는 쿼리를 찾습니다. 기능을 손상시킬 수 있는 하드 제한을 적용하는 것보다 애플리케이션 수준에서 쿼리를 최적화하는 것이 항상 좋습니다.
**하드웨어 작업:**
+ vCPUs 더 많은 다음 인스턴스 클래스로 확장
+ 쿼리 패턴에서 최적화 기회 검토
### 높은 메모리 사용률(MemoryUtilization > 70%)
**증상:**
+ **MemoryUtilization** > 70% 지속
+ **HeapMemoryUsage** 상향 추세
+ 스파이크를 보여주는 **ActiveMemoryAllocation**
+ **SeriesCardinality**(카디널리티가 높으면 메모리 사용량이 증가함)
**구성 조정:**
**우선 순위 1: 캐시 메모리 감소**
+ storage-cache-max-memory-size: 총 RAM의 10\$115%로 설정
+ 예: 32GB RAM → 3,355,443,200\$15,033,164,800바이트
+ storage-cache-snapshot-memory-size: 26,214,400(25MB)
**우선 순위 2: 쿼리 메모리 제한**
+ query-memory-bytes: 총 RAM의 60\$170%로 설정
+ query-max-memory-bytes: query-memory-bytes와 동일
+ query-initial-memory-bytes: query-memory-bytes의 10%
**우선 순위 3: 시리즈 캐시 최적화**
+ storage-series-id-set-cache-size: 카디널리티가 높은 경우 축소
+ 고용량 메모리: 100\$1200
+ 정상: 500-1000
**중요 고려 사항:**
이러한 변경은 메모리 압력을 줄이지만 애플리케이션 성능에 직접적인 부정적인 영향을 미칩니다. 데이터를 줄`storage-cache-max-memory-size`이면 메모리에 캐시되는 데이터가 줄어들어 디스크 읽기가 강제로 늘어나고 쿼리 지연 시간이 늘어납니다. **ReadOpsPerSec**가 증가하고 **QueryResponseVolume** 응답 시간이 저하될 수 있습니다.
제한`query-memory-bytes`으로 인해 **QueryRequestsTotal**의 **runtime\$1error**, 특히 대규모 데이터 세트를 집계하거나 상당한 결과 세트를 반환하는 쿼리로 인해 메모리 집약적 쿼리가 실패합니다. 이전에 성공한 쿼리에 대해 사용자에게 "메모리 부족" 오류가 발생할 수 있습니다.
를 줄이면 캐시에서 검색하는 대신 시리즈 결과를 더 자주 다시 계산해야 하므로 카디널리티가 높은 데이터에 대한 쿼리 성능이 `storage-series-id-set-cache-size` 저하됩니다. 이는 특히 동일한 시리즈 조합을 반복적으로 쿼리하는 대시보드에 영향을 미칩니다.
**모범 사례:** 이러한 제한적인 변경 사항을 적용하기 전에 먼저 쿼리 패턴을 분석하고 최적화합니다.
+ **QueryResponseVolume**을 검토하여 과도한 데이터를 반환하는 쿼리 식별
+ **QueryRequestsTotal**을 사용하여 최적화의 이점을 누릴 수 있는 자주 실행되는 쿼리를 찾습니다.
+ 시간 범위 필터를 추가하여 워크로드에 필요한 데이터 스캔 감소
+ 애플리케이션 수준에서 쿼리 결과 캐싱 구현
+ 다운샘플링 작업을 사용하여 데이터 사전 집계 고려
+ **SeriesCardinality**를 검토하고 데이터 모델을 최적화하여 불필요한 태그 줄이기
쿼리 최적화는 항상 첫 번째 접근 방식이어야 합니다. 최적화가 충분하지 않은 경우 구성 제한은 최후의 수단이어야 합니다.
**하드웨어 작업:**
+ 더 많은 RAM을 위해 인스턴스 크기 증가
### 높은 스토리지 사용률(DiskUtilization > 70%)
**모니터링할 CloudWatch 지표:**
+ **DiskUtilization** > 70%
+ **WriteThroughput** 패턴
+ **TotalBuckets**(많은 버킷이 오버헤드 증가)
**구성 조정:**
**우선 순위 1: 로깅 구성 확인**
+ 로그 수준:가 "info"("debug"가 아님)로 설정되어 있는지 확인합니다.
+ flux-log-enabled: 적극적으로 디버깅하지 않는 한 FALSE로 설정
**우선순위 2: 공격적 보존**
+ storage-retention-check-interval: 15m0s(더 자주 정리)
**우선순위 3: 압축 최적화**
+ storage-compact-full-write-cold-duration: 2h0m0s(더 자주)
+ storage-cache-snapshot-write-cold-duration: 5m0s
**우선 순위 4: 인덱스 크기 축소**
+ storage-max-index-log-file-size: 524,288(빠른 압축을 위해 512KB)
**중요 고려 사항:**
**중요한 첫 번째 단계 - 로깅 구성 확인:** 다른 사항을 변경하기 전에 로깅 설정을 확인합니다. **디버그 로깅 및 Flux 쿼리 로그는 실제 시계열 데이터보다 더 많은 디스크 공간을 소비할 수** 있으며, 이는 예상치 못한 스토리지 소진의 가장 일반적인 원인 중 하나입니다.
**로깅 영향:**
+ `log-level: debug`는 매우 세부적인 로그를 생성하며, 시간당 수백 MB일 수 있습니다.
+ `flux-log-enabled: TRUE`는 전체 세부 정보로 모든 Flux 쿼리 실행을 로깅하여 대량 로그 파일을 생성합니다.
+ 이러한 로그는 빠르게 누적되며 용량 계획 중에 간과되는 경우가 많습니다.
+ 로그 파일은 특히 더 작은 인스턴스에서 데이터 수집보다 더 빠르게 디스크 공간을 채울 수 있습니다.
+ 시계열 데이터와 달리 로그는 삭제 전 24시간 동안 로컬 스토리지에 보관됩니다.
**로그가 큰 경우 즉시 작업:**
1. 설정`log-level: info`(디버그에서)
1. `flux-log-enabled: FALSE` 설정
1. 즉각적인 개선을 위해 **DiskUtilization** 모니터링
**압축 구성 절충 사항:**
이러한 구성 변경은 **수집 처리량이 높고 디스크 사용량이 크게 변동하는 보존 기간이 짧은** 워크로드를 위해 특별히 설계되었습니다. 압축 엔진이 더 적극적으로 작동하도록 하므로 특정 시나리오에서만 유용합니다.
**중요한 절충: 압축 빈도를** 늘리면 리소스 소비가 크게 증가합니다.
+ 압축 작업이 CPU 주기를 소비하면 CPU **CPUUtilization** 증가합니다.
+ 데이터가 로드되고 처리되면 압축 중에 **MemoryUtilization**이 증가합니다.
+ **WriteOpsPerSec** 및 **WriteThroughput**은 압축 기간 동안 급증하여 잠재적으로 30% IOPS 헤드룸을 초과할 수 있습니다.
+ 압축 I/O가 애플리케이션 쓰기와 경쟁하는 경우 **WriteTimeouts**가 증가할 수 있습니다.
이러한 변경으로 인해 공격적인 압축이 쿼리 및 쓰기 작업에 필요한 리소스를 소비하여 디스크 사용량을 줄이더라도 전체 시스템 성능이 저하되는 계단식 성능 문제가 발생할 수 있습니다.
**모범 사례:** 압축 설정을 조정하기 전에 데이터 및 로깅 관리에 집중하세요.
1. **로깅 먼저 확인(가장 일반적인 문제):** 로그 수준이 '정보'이고 flux-log-enabled가 FALSE인지 확인
1. **데이터 모델 검토:** 실제로 필요하지 않은 데이터를 쓰고 있나요? 측정 또는 필드 세분화를 줄일 수 있나요?
1. **보존 정책 최적화:** **TotalBuckets** 확인 및 각 버킷의 보존 설정 검토
1. **압축 영향 모니터링:** 변경 전에 **CPUUtilization**, **MemoryUtilization** 및 **WriteOpsPerSec** 기준 지정
**대체 접근 방식:**
+ 스토리지 용량 증가(종종 더 간단하고 비용 효율적)
+ 데이터 다운샘플링 또는 집계 전략 구현
+ 버킷 통합(**TotalBuckets** 수 감소)으로 오버헤드 감소
+ 보존 정책을 더 엄격하게 검토 및 적용
데이터 관리를 최적화하고 인스턴스에 늘어난 부하를 처리하기에 충분한 CPU, 메모리 및 IOPS 헤드룸이 있는지 확인한 경우에만 공격적인 압축 설정을 적용합니다.
**하드웨어 작업:**
+ 스토리지 용량 늘리기
### 높은 IOPS 사용률(ReadIOPS/WriteIOPS/TotalOperationsPerSecond > 프로비저닝의 70%)
**모니터링할 CloudWatch 지표:**
+ **ReadOpsPerSec** \$1 **WriteOpsPerSec** = **TotalIOpsPerSec**
+ **ReadThroughput** 및 **WriteThroughput**
+ 프로비저닝된 IOPS(3K, 12K 또는 16K)와 비교
**구성 조정:**
**우선 순위 1: 압축 I/O 제어**
+ storage-max-concurrent-compactions: 2-3(동시 압축 제한)
+ storage-compact-throughput-burst: 디스크 기능에 따라 조정
+ 3K IOPS: 25,165,824(24MB/s)
+ 12K IOPS: 50,331,648(48MB/s)
**우선 순위 2: 쓰기 작업 최적화**
+ storage-wal-max-concurrent-writes: 8-12
+ storage-wal-max-write-delay: 5m0s
**우선순위 3: 스냅샷 타이밍 조정**
+ storage-cache-snapshot-write-cold-duration: 15m0s(빈도 낮음)
+ storage-compact-full-write-cold-duration: 6h0m0s(빈도 낮음)
**중요 고려 사항:**
이러한 변경으로 인해 I/O 사용률과 시스템 성능 간에 상당한 장단점이 발생합니다.
**압축 I/O 제한:**
+ 를 줄`storage-max-concurrent-compactions`이면 압축 작업이 느려져 TSM 파일이 누적되고 **DiskUtilization**이 더 빠르게 증가합니다.
+ 를 낮추면 압축 기간이 `storage-compact-throughput-burst` 연장되어 압축기를 더 오래 활성 상태로 유지하고 잠재적으로 다른 작업을 차단할 수 있습니다.
+ 압축 속도가 느리면 스토리지 엔진이 통합 파일 대신 더 작고 더 많은 TSM 파일에서 읽어야 하므로 시간이 지남에 따라 쿼리 성능이 저하됩니다.
+ I/O를 기다리는 동안 쿼리 제한 시간이 초과되면 **QueryRequestsTotal** runtime\$1error 속도가 증가하는 것을 볼 수 있습니다.
**스냅샷 빈도 줄이기:**
+ `storage-cache-snapshot-write-cold-duration` 및를 늘리`storage-compact-full-write-cold-duration`면 데이터가 미리 쓰기 로그(WAL)에 더 오래 보관됩니다.
+ 이렇게 하면 디스크로 플러시되기 전에 캐시에 더 많은 데이터가 보관됨에 따라 **MemoryUtilization**이 증가합니다.
+ 캐시된 데이터가 유지되기 전에 인스턴스가 충돌하면 데이터 손실 위험이 약간 증가합니다.
+ 더 많은 WAL 데이터를 재생해야 하므로 재시작 후 복구 시간이 증가합니다.
**쓰기 작업 튜닝:**
+ 를 줄`storage-wal-max-concurrent-writes`이면 쓰기 작업이 더 직렬화되어 처리량이 많은 기간 동안 **WriteTimeouts**가 증가할 수 있습니다.
+ 를 늘리`storage-wal-max-write-delay`면 쓰기가 거부되기 전에 더 오래 기다릴 수 있으므로 용량 문제를 마스킹 처리하지만 느린 응답으로 사용자를 좌절시킬 수 있습니다.
**모범 사례:** IOPS 사용률이 높으면 일반적으로 구성 문제가 아닌 스토리지 계층이 확장되었음을 나타냅니다. I/O를 제한하기 전에 I/O 패턴을 분석하고 최적화한 후 제한합니다.
**하드웨어 작업:**
+ 더 높은 IOPS 스토리지 계층으로 업그레이드(3K → 12K)
+ 30% IOPS 헤드룸 유지
### High Series Cardinality(SeriesCardinality > 1M)
**모니터링할 CloudWatch 지표:**
+ 버킷당 **SeriesCardinality** 및 합계
+ **MemoryUtilization**(카디널리티로 증가)
+ **CPUUtilization**(쿼리 계획 오버헤드)
+ **QueryRequestsTotal**(runtime\$1error 비율이 증가할 수 있음)
**구성 조정:**
**우선 순위 1: 시리즈 처리 최적화**
+ storage-series-id-set-cache-size: 1000-2000(캐시 증가)
+ storage-series-file-max-concurrent-snapshot-compactions: 4-8
**우선 순위 2: 보호 한도 설정**
+ influxql-max-select-series: 10000(런어웨이 쿼리 방지)
+ influxql-max-select-buckets: 1000
**우선순위 3: 인덱스 작업 최적화**
+ storage-max-index-log-file-size: 2,097,152(2MB)
**중요 고려 사항:**
높은 시리즈 카디널리티는 기본적으로 구성 문제가 아니라 데이터 모델링 문제입니다. 구성 변경은 증상을 완화할 수만 있으며 근본적인 문제를 해결할 수는 없습니다.
**구성 절충:**
를 늘리`storage-series-id-set-cache-size`면 시리즈 조회를 캐싱하여 쿼리 성능이 향상되지만 **MemoryUtilization**은 증가합니다. 각 캐시 항목은 메모리를 소비하며, 시리즈가 수백만 개인 경우 이는 상당할 수 있습니다. 이 변경 후 **HeapMemoryUsage** 및 **ActiveMemoryAllocation**을 모니터링합니다.
보호 제한(`influxql-max-select-series`, `influxql-max-select-buckets`)을 설정하면 이러한 임계값을 초과하는 경우 **QueryRequestsTotal**의 **compile\$1error**에서 합법적인 쿼리가 실패합니다. 이전에 작동한 대시보드가 중단될 수 있으며 사용자는 쿼리를 수정해야 합니다. 이는 다음과 같은 경우에 특히 문제가 됩니다.
+ 여러 호스트/서비스에서 집계되는 대시보드 모니터링
+ 여러 엔터티를 비교해야 하는 분석 쿼리
+ 플릿 전체 조건을 평가하는 알림 쿼리
더 작은 값으로 조정`storage-max-index-log-file-size`하면 인덱스 압축 빈도가 증가하여 시스템에서 인덱스 유지 관리를 더 자주 수행할 때 **CPUUtilization** 및 **WriteOpsPerSec**가 증가합니다.
**중요한 이해:**
**SeriesCardinality**가 5M을 초과하면 InfluxDB 2.x의 아키텍처 제한에 근접하게 됩니다. 10M 이상에서는 구성에 관계없이 성능이 기하급수적으로 저하됩니다.
+ 쿼리 계획 비용이 매우 많이 듭니다(**CPUUtilization**).
+ 메모리 요구 사항이 비선형으로 증가(**MemoryUtilization** 높음)
+ 인덱스 작업이 I/O를 지배함(**ReadOpsPerSec**, **WriteOpsPerSec**)
+ 쿼리 제한 시간 또는 소진 메모리에 따라 **QueryRequestsTotal** runtime\$1error 속도가 증가합니다.
**모범 사례:** 구성 변경은 임시 밴드 지원입니다. 근본 원인을 해결해야 합니다.
1. **데이터 모델 분석:**
+ 버킷당 **SeriesCardinality**를 검토하여 문제 영역 식별
+ 고유 값 수가 높은 태그 식별
+ 무제한 태그 값(UUIDs, 타임스탬프, 사용자 IDs, 세션 IDs) 찾기
+ 대신 필드여야 하는 태그 찾기
**데이터 모델 작업:**
+ 태그 설계를 검토하여 불필요한 카디널리티 감소
+ 유사한 시리즈 통합 고려
+ **> 10M 시리즈인 경우:** InfluxDB 3.0으로 마이그레이션 계획
### 쿼리 성능 문제
**모니터링할 CloudWatch 지표:**
+ 결과 유형별 **QueryRequestsTotal**(성공, runtime\$1error, compile\$1error, queue\$1error)
+ 상태=500 또는 상태=499인 **APIRequestRate**
+ **QueryResponseVolume**(대규모 응답은 비용이 많이 드는 쿼리를 나타냄)
**구성 조정:**
**우선 순위 1: 쿼리 리소스 증가**
+ 쿼리 동시성: vCPUs의 75%로 증가
+ query-memory-bytes: 총 RAM의 70% 할당
+ query-queue-size: 4096
**우선 순위 2: 쿼리 실행 최적화**
+ storage-series-id-set-cache-size: 1000(더 나은 캐싱을 위해 증가)
+ http-read-timeout: 60초(조기 제한 시간 방지)
**우선순위 3: 합리적인 제한 설정**
+ influxql-max-select-point: 100000000
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
**중요 고려 사항:**
쿼리 리소스를 늘리면 리소스 경쟁과 잠재적인 시스템 불안정성이 발생합니다.
**리소스 할당 절충 사항:**
를 늘리`query-concurrency`면 더 많은 쿼리를 동시에 실행할 수 있지만 각 쿼리는 CPU와 메모리에 대해 경쟁합니다.
+ **CPUUtilization** 증가하여 피크 쿼리 기간 동안 포화 상태에 도달할 수 있음
+ **MemoryUtilization**은 더 많은 쿼리가 메모리를 동시에 할당함에 따라 증가합니다.
+ 적절한 리소스 없이 동시성을 높이면 일부 대기열만 있는 대신 모든 쿼리가 느려집니다.
+ 동시 쿼리에서 사용 가능한 리소스가 소진될 경우 계단식 실패 위험
더 많이 할당`query-memory-bytes`하면 캐싱 및 기타 작업에 사용할 수 있는 메모리가 줄어듭니다.
+ **HeapMemoryUsage**가 증가합니다.
+ `storage-cache-max-memory-size` 보정을 위해를 줄여야 할 수 있습니다.
+ 캐시 적중 횟수가 적을수록 **ReadOpsPerSec**가 향상되고 쿼리 성능이 느려집니다.
+ 쿼리가 전체 할당을 사용하는 경우 시스템이 메모리 소진에 더 취약해집니다.
를 늘리면 문제`query-queue-size`만 지연되며 용량 문제는 해결되지 않습니다.
+ 쿼리는 대기열에서 더 오래 대기하여 end-to-end 지연 시간을 늘립니다.
+ 사용자는 처리량이 변경되지 않더라도 시스템을 더 느리게 인식합니다.
+ 큰 대기열은 기본 용량 문제를 마스킹할 수 있습니다.
+ **QueryRequestsTotal** queue\$1error rate가 감소하지만 사용자 경험이 개선되지 않을 수 있습니다.
를 늘리면 조기 쿼리 취소를 `http-read-timeout` 방지할 수 있지만 다음과 같습니다.
+ 장기 실행 쿼리는 리소스를 더 오래 소비하여 다른 쿼리의 용량을 줄입니다.
+ 사용자가 제한 시간 오류를 수신하기 전에 더 오래 대기
+ 최적화해야 하는 비효율적인 쿼리를 숨길 수 있음
+ 느린 쿼리가 많이 누적되면 리소스가 소진될 수 있습니다.
**모범 사례:** 쿼리 성능 문제는 일반적으로 리소스 부족이 아닌 비효율적인 쿼리로 인해 발생합니다. 리소스 할당을 늘리기 전에:
1. **쿼리 패턴 분석:**
+ **QueryResponseVolume**을 검토하여 과도한 데이터(> 1MB)를 반환하는 쿼리를 식별합니다.
+ **QueryRequestsTotal** runtime\$1error 패턴 확인 - 실패의 원인은 무엇입니까?
+ 상태=499(클라이언트 제한 시간)인 **APIRequestRate** 찾기 - 쿼리가 너무 느림
+ 자주 실행되는 값비싼 쿼리 식별
1. **먼저 쿼리 최적화:**
일반적인 쿼리 안티 패턴:
+ 시간 범위 필터 누락 → 명시적 시간 범위 추가
+ 모든 시리즈 쿼리 → 특정 태그 필터 추가
+ 과도한 집계 기간 → 적절한 간격 사용
+ SELECT → Request only needed data의 불필요한 필드
+ LIMIT 절 없음 → 합리적인 제한 추가
1. **애플리케이션 수준 솔루션:**
+ 쿼리 결과 캐싱 구현(Redis, Memcached)
+ 작업을 사용하여 공통 패턴 사전 집계
+ 대규모 결과 집합에 페이지 매김 추가
+ 사용자/대시보드당 쿼리 속도 제한 구현
+ 기록 쿼리에 다운샘플링된 데이터 사용
1. **리소스 가용성 확인:**
+ **CPUUtilization** 확인 - 이미 > 70%인 경우 동시성이 증가하면 상황이 악화됩니다.
+ **MemoryUtilization** 확인 - 이미 > 70%인 경우 더 많은 쿼리 메모리를 할당하면 OOM이 발생합니다.
+ 쿼리 로드를 늘리기 전에 **TotalIOpsPerSec**에 30%의 헤드룸이 있는지 확인
**권장 접근 방식:**
1. 가장 비용이 많이 드는 상위 10개 쿼리를 최적화하여 시작합니다(**QueryResponseVolume** 기준).
1. 애플리케이션 수준에서 쿼리 결과 캐싱 구현
1. 쿼리가 최적화되고 지표에 헤드룸이 표시되는 경우에만 리소스 할당을 늘리세요.
1. 워크로드가 현재 용량을 초과한 경우 더 큰 인스턴스 클래스로 확장
**하드웨어 작업:**
+ 컴퓨팅 용량을 확장하면 쿼리가 추가 처리 성능(vCPUs.
#### Flux 쿼리의 RegEx 성능 위험
Flux에서 데이터를 필터링할 때는 정확한 일치 또는 간단한 패턴 일치에 정규식을 사용하지 마세요. 이로 인해 상당한 성능 페널티가 발생하기 때문입니다. Flux의 RegEx 작업은 **단일 스레드**이며 **기본 TSM 인덱스를 완전히 우회**합니다. 빠른 조회를 위해 InfluxDB의 최적화된 태그 인덱스를 활용하는 대신 RegEx 필터는 쿼리 엔진이 스토리지에서 일치하는 모든 시리즈를 검색하고 각 값에 대해 순차적으로 텍스트 비교를 수행하도록 강제합니다. 이는 다음과 같은 경우에 특히 문제가 됩니다.
+ **정확한 태그 값을 기준으로 필터링** - 다음과 같은 RegEx 패턴 대신 등식 연산자(`==`) 또는 `contains()` 함수를 사용합니다. `/^exact_value$/`
+ **여러 특정 값 일치** - 다음과 같은 변경 패턴 대신 값 배열과 함께 `in` 연산자 사용 `/(value1|value2|value3)/`
+ **간단한 접두사 또는 접미사 일치** - RegEx 앵커보다 더 효율적인 `strings.hasPrefix()` 또는 `strings.hasSuffix()` 함수를 사용하는 것이 좋습니다.
여러 패턴 일치가 필요한 시나리오의 경우 논리 연산자와 결합된 여러 필터 조건자를 사용하도록 쿼리를 재구성하거나 더 복잡한 문자열 작업을 적용하기 전에 태그 동등성을 사용하여 사전 필터링합니다. 더 간단한 비교 연산자를 통해 표현할 수 없는 실제 패턴 일치가 필요한 경우에만 RegEx를 예약합니다.
### 쓰기 성능 문제
**모니터링할 CloudWatch 지표:**
+ **WriteTimeouts**(개수 증가)
+ **WriteOpsPerSec** 및 **WriteThroughput**
+ 쓰기 엔드포인트의 경우 상태=500인 **APIRequestRate**
+ 쓰기 중 결과=runtime\$1error인 **QueryRequestsTotal**
**구성 조정:**
**우선 순위 1: WAL 쓰기 최적화**
+ storage-wal-max-concurrent-writes: 12-16
+ storage-wal-max-write-delay: 1,000초
+ http-write-timeout: 60초
**우선 순위 2: 캐시 스냅샷 최적화**
+ storage-cache-snapshot-memory-size: 52,428,800(50MB)
+ storage-cache-snapshot-write-cold-duration: 10m0s
**우선순위 3: 제어 필드 검증**
+ storage-no-validate-field-size: TRUE(데이터 소스를 신뢰할 수 있는 경우)
**중요 고려 사항:**
쓰기 성능 튜닝에는 처리량, 신뢰성 및 리소스 소비 간의 신중한 절충이 필요합니다.
**WAL 구성 절충 사항:**
를 늘리면 더 많은 병렬 쓰기 작업이 `storage-wal-max-concurrent-writes` 가능하지만 다음과 같습니다.
+ **CPUUtilization** 증가
+ WAL 플러시 전에 메모리에 더 많은 데이터가 버퍼링되면 **MemoryUtilization**이 증가합니다.
+ **WriteOpsPerSec**가 급증하여 잠재적으로 30% IOPS 헤드룸을 초과할 수 있음
+ 디스크 I/O에 대한 경합이 증가하면 실제로 개별 쓰기 속도가 느려질 수 있습니다.
+ 디스크 I/O 용량을 초과하면 **WriteTimeouts**가 감소하지 않고 증가할 수 있습니다.
를 늘리면 쓰기가 시간 초과 전에 더 오래 대기`storage-wal-max-write-delay`한다는 의미입니다.
+ 쓰기가 빠르게 실패하는 대신 대기하도록 하여 용량 문제를 마스킹합니다.
+ 쓰기가 결국 성공하더라도 쓰기 응답 시간이 느려집니다.
+ 쓰기 대기열 빌드업 및 메모리 압력으로 이어질 수 있음
+ 실제로 용량을 늘리지 않음 - 제한 시간만 지연
를 늘리면 제한 시간 오류가 `http-write-timeout` 비슷하게 지연됩니다.
+ 더 큰 배치 쓰기가 완료되도록 허용
+ 그러나 느린 쓰기가 리소스를 더 오래 소비하도록 허용
+ 기본 성능 문제를 숨길 수 있음
+ 느린 쓰기가 많이 누적되면 리소스가 소진될 수 있습니다.
**캐시 스냅샷 트레이드오프:**
를 늘리`storage-cache-snapshot-memory-size`면 플러시하기 전에 메모리에 더 많은 데이터가 누적됩니다.
+ **MemoryUtilization**이 크게 증가함
+ 스냅샷 전에 인스턴스가 충돌하면 데이터 손실 위험이 증가합니다.
+ 스냅샷이 클수록 쓰기 시간이 길어지므로 **WriteOpsPerSec** 스파이크가 커집니다.
+ 더 많은 데이터를 일괄 처리하여 쓰기 처리량을 개선할 수 있지만 메모리와 안정성은 비용이 듭니다.
`storage-cache-snapshot-write-cold-duration` 지연 스냅샷 증가:
+ 데이터가 캐시에 더 오래 머무르면 **MemoryUtilization**이 더욱 증가합니다.
+ 데이터 손실 위험 기간을 늘립니다.
+ **WriteOpsPerSec** 빈도를 줄이지만 스냅샷이 발생할 때 더 큰 스파이크를 생성합니다.
+ 더 많은 WAL을 재생해야 하므로 재시작 후 복구 시간이 증가합니다.
**필드 검증 절충:**
를 설정하면 필드 크기 검증이 `storage-no-validate-field-size: TRUE` 비활성화됩니다.
+ 검증 검사를 건너뛰어 쓰기 처리량을 개선합니다.
+ **중요 위험:** 형식이 잘못되었거나 악의적인 데이터를 작성할 수 있습니다.
+ 쓰기에 잘못된 필드 크기가 포함된 경우 데이터가 손상될 수 있습니다.
+ 디버깅 데이터 문제를 훨씬 더 어렵게 만듭니다.
+ **데이터 소스를 완벽하게 제어하고 신뢰할 수 있는 경우에만 사용**
**모범 사례:** 쓰기 성능 문제는 일반적으로 용량 제한 또는 비효율적인 쓰기 패턴을 나타냅니다. 구성을 튜닝하기 전에:
1. **쓰기 패턴 분석:**
+ **WriteThroughput** 및 **WriteOpsPerSec** 추세 검토
+ 쓰기 로드와 **WriteTimeouts** 상관 관계 확인
+ 상태 코드별 **APIRequestRate**의 쓰기 엔드포인트 모니터링
+ 쓰기 배치 크기 및 빈도 식별
1. **먼저 쓰기 작업 최적화:**
일반적인 쓰기 방지 패턴:
+ 개별 포인트 쓰기 → 배치 쓰기(5,000\$110,000 포인트)
+ 쓰기 빈도가 너무 높음 → 버퍼 및 배치
+ 동기 쓰기 → 비동기 쓰기 대기열 구현
+ 무제한 쓰기 버스트 → 속도 제한 구현
+ 불필요한 정밀도 작성 → 타임스탬프를 적절하게 반올림
1. **I/O 용량 확인:**
+ **TotalIOpsPerSec** 확인 - 이미 > 70%인 경우 WAL 동시성이 증가하면 상황이 악화됩니다.
+ 피크 기간 동안 **WriteOpsPerSec** 검토
+ 쓰기 설정을 조정하기 전에 30% IOPS 헤드룸이 존재하는지 확인합니다.
+ 3K IOPS로 충분한지 또는 12K IOPS 계층이 필요한지 고려
1. **애플리케이션 수준 개선 사항:**
+ 구성 가능한 배치 크기로 쓰기 버퍼링 구현
+ 지수 백오프를 사용하여 쓰기 재시도 로직 추가
+ 비동기 쓰기 작업 사용
+ 피크 기간 동안 쓰기 속도 제한 구현
+ 쓰기 대기열 깊이 모니터링 및 역압 적용
**권장 접근 방식:**
1. 먼저 애플리케이션 수준에서 쓰기 배치 크기를 최적화합니다(배치당 5,000\$110,000개 포인트 목표).
1. 쓰기 버퍼링 및 비동기 작업 구현
1. **TotalIOpsPerSec**에 적절한 헤드룸이 있는지 확인
1. 사용률이 지속적으로 70%를 초과하는 경우 다음 스토리지 계층(3K IOPS → 12K IOPS → 16K IOPS)으로 업그레이드
1. 쓰기가 최적화되고 I/O 용량이 적절한 경우에만 WAL 설정을 조정합니다.
1. 데이터 소스를 완전히 제어할 수 없는 한 필드 검증을 비활성화**하지 마세요**.
**하드웨어 작업:**
+ 더 높은 IOPS 스토리지로 업그레이드(3K → 12K → 16K)
+ I/O 헤드룸이 적절한지 확인
+ CPU 또는 메모리가 제한된 경우 더 큰 인스턴스 클래스로 확장
## 모니터링 모범 사례
### CloudWatch 경보 구성
**중요 경보(즉시 조치 필요):**
**CPUUtilization:**
+ 임계값: 5분 동안 > 90%
+ 조치: 트래픽 수정 조치 또는 컴퓨팅 조정 구현
**MemoryUtilization:**
+ 임계값: 5분 동안 > 90%
+ 조치: 트래픽 수정 조치 또는 컴퓨팅 조정 구현
**DiskUtilization:**
+ 임계값: > 85%
+ 작업: 이전 버킷을 삭제하고 보존 구성 또는 Storage Scaling을 업데이트하여 공간을 확보해 보세요.
**TotalIOpsPerSec:**
+ 임계값: 10분 동안 프로비저닝된의 > 90%
+ 조치: 트래픽 수정 조치 구현 또는 IOPS 증가
**SeriesCardinality:**
+ 임계값: > 10,000,000
+ 작업: 데이터 모델을 검토합니다. 가능한 변경 사항이 없는 경우 InfluxDB 3으로 마이그레이션하거나 데이터를 샤딩합니다.
**EngineUptime:**
+ 임계값: 예기치 않은 재설정(< 300초)
+ 작업: Timestream 지원 티켓을 생성하지 않은 경우 유지 관리 기간과 일치하는지 확인합니다.
**경고 경보(조사 필요):**
**CPUUtilization:**
+ 임계값: 15분 동안 > 70%
+ 작업: 워크로드 또는 트래픽의 변경 사항 검토
**MemoryUtilization:**
+ 임계값: 15분 동안 > 70%
+ 작업: 워크로드 또는 트래픽의 변경 사항 검토
**DiskUtilization:**
+ 임계값: > 70%
+ 작업: 보존 정책 검토
**TotalIOpsPerSec:**
+ 임계값: 15분 동안 프로비저닝된의 > 70%
+ 작업: 워크로드 또는 트래픽의 변경 사항 검토
**QueryRequestsTotal(runtime\$1error):**
+ 임계값: 총 쿼리의 > 1%
+ 작업: 워크로드 또는 트래픽의 변경 사항 검토
**WriteTimeouts:**
+ 임계값: 쓰기 작업의 > 1%
+ 작업: 워크로드 또는 트래픽의 변경 사항 검토
**SeriesCardinality:**
+ 임계값: > 5,000,000
+ 작업: 데이터 모델 최적화 검토
### 사전 모니터링 체크리스트
**일별:**
+ APIRequestRate에서 오류 스파이크(400, 404, 499, 500) 검토
+ QueryRequestsTotal에서 runtime\$1error 및 queue\$1error 비율 확인
+ WriteTimeouts 수가 최소인지 확인
+ 중요한 경보가 있는지 확인
+ EngineUptime 확인(예상치 않게 다시 시작되지 않음)
**매주:**
+ CPUUtilization, MemoryUtilization 및 DiskUtilization 추세 검토
+ 결과 유형별 QueryRequestsTotal 패턴 분석
+ 버킷당 SeriesCardinality 증가율 확인
+ TotalIOpsPerSec 사용률 추세 검토
+ 구성 파라미터가 최적인지 확인
+ TaskExecutionFailures 패턴 검토
**월별:**
+ 용량 계획 검토(3\$16개월 전 프로젝트)
+ 현재 지표와 크기 조정 테이블 비교
+ 보존 정책 검토 및 최적화
+ APIRequestRate 및 QueryResponseVolume의 쿼리 패턴 분석
+ SeriesCardinality 및 데이터 모델 효율성 검토
+ 인스턴스 크기 조정 또는 구성 변경의 필요성 평가
+ TotalBuckets 및 통합 기회 검토
## 문제 해결 안내서
### 시나리오: 갑작스러운 성능 저하
**조사 단계:**
**최근 변경 사항 확인:**
+ AWS 관리 콘솔에서 구성 파라미터 수정
+ 애플리케이션 배포 변경 사항
+ 쿼리 패턴 변경
+ 데이터 모델 수정
+ 인프라 변경(인스턴스 유형, 스토리지)
**CloudWatch 지표 검토:**
+ **CPU 스파이크?** → CPUUtilization, QueryRequestsTotal 확인
+ **메모리 압력?** → MemoryUtilization, HeapMemoryUsage, ActiveMemoryAllocation 확인
+ **IOPS 포화 여부** → TotalIOpsPerSec, ReadOpsPerSec, WriteOpsPerSec 확인
+ **시리즈 카디널리티 점프?** → SeriesCardinality 증가 확인
+ **오류율 증가 여부** → QueryRequestsTotal(runtime\$1error), APIRequestRate(Status=500) 확인
+ **예기치 않은 재시작?** → EngineUptime 확인
**세부 로깅 활성화:**
구성 변경:
+ 로그 수준: 디버그
+ flux-log-enabled: TRUE
1\$12시간 동안 모니터링한 다음 로그 검토
로그 수준: 조사 후 정보로 돌아가기
**해결 단계:**
+ 조사 결과에 따라 적절한 구성 변경 사항 적용
+ 한도에 도달하면 리소스 규모 조정
+ 필요한 경우 쿼리 또는 데이터 모델 최적화
+ 갑작스러운 부하 증가 시 속도 제한 구현
### 시나리오: 메모리 소진
**증상:**
+ MemoryUtilization > 90%
+ HeapMemoryUsage 최대치에 가까워짐
+ runtime\$1error(메모리 부족)를 보여주는 QueryRequestsTotal
+ 상태=500을 보여주는 APIRequestRate
**해결 단계:**
즉각적인 조치(중요한 경우):
1. 인스턴스를 다시 시작하여 메모리를 지웁니다(안전한 경우).
1. 쿼리 동시성 일시적 감소
1. 가능하면 장기 실행 쿼리 제거
구성 변경 사항:
**우선 순위 1: 캐시 메모리 감소**
+ storage-cache-max-memory-size: RAM의 10%로 축소
+ 예: 32GB → 3,355,443,200바이트
+ storage-cache-snapshot-memory-size: 26,214,400(25MB)
**우선 순위 2: 쿼리 메모리 제한**
+ query-memory-bytes: 총 RAM의 60%로 설정
+ query-max-memory-bytes: query-memory-bytes 일치
+ query-initial-memory-bytes: query-memory-bytes의 10%
**우선순위 3: 보호 한도 설정**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
+ 쿼리 동시성: vCPUs의 50%로 감소
**장기 솔루션:**
+ 데이터 모델을 최적화하여 **SeriesCardinality** 감소
+ 애플리케이션 수준에서 쿼리 결과 크기 제한 구현
+ 쿼리 제한 시간 적용 추가
+ 가장 일반적인 쿼리를 검토하여 이러한 쿼리가 섹션에 언급된 모범 사례를 따르는지 확인합니다. [쿼리 성능 문제](#query-performance-issues)
### 시나리오: High Series Cardinality 영향
**CloudWatch 지표 검토:**
+ **SeriesCardinality** > 5M
+ **MemoryUtilization** 높음
+ 런타임\$1오류 증가를 보여주는 **QueryRequestsTotal**
+ 쿼리 계획 오버헤드로 인한 **CPUUtilization** 상승
**조사 단계:**
**카디널리티 성장 분석:**
+ SeriesCardinality 성장률(일별/주별)
+ 10M 임계값으로 프로젝션
+ 카디널리티가 높은 소스 식별
+ 태그 설계 및 사용 검토
**성능 영향 평가:**
+ **QueryRequestsTotal** 성공률
+ **MemoryUtilization** 상관관계 검토
+ **CPUUtilization** 패턴 확인
+ **QueryResponseVolume** 추세 분석
**카디널리티 소스 식별:**
데이터 모델 검토:
+ SeriesCardinality가 가장 높은 버킷은 무엇입니까?
+ 고유 값 수가 높은 태그는 무엇입니까?
+ 불필요한 태그가 있나요?
+ 태그 값이 제한되지 않나요(UUIDs, 타임스탬프 등)?
**현재 구성 검토:**
최적화 파라미터를 확인합니다.
+ storage-series-id-set-cache-size: 현재 값?
+ influxql-max-select-series: 런어웨이 쿼리를 제한하나요?
+ storage-max-index-log-file-size: 카디널리티에 적합합니까?
**해결 단계:**
즉각적인 구성 변경:
**우선 순위 1: 시리즈 처리 최적화**
+ storage-series-id-set-cache-size: 1500-2000
+ storage-series-file-max-concurrent-snapshot-compactions: 6-8
+ storage-max-index-log-file-size: 2,097,152(2MB)
**우선 순위 2: 보호 한도 설정**
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
+ query-concurrency: 메모리 제약 시 감소
**우선순위 3: 리소스 증가**
+ 다음 인스턴스 계층으로 확장
+ 메모리 할당 증가
+ 12K IOPS 스토리지 계층 고려
**마이그레이션 계획(> 10M 시리즈인 경우):**
+ **InfluxDB 3.0은 우수한 높은 카디널리티 성능을 제공합니다.**
+ 마이그레이션 일정 계획(2\$13개월)
+ 먼저 데이터 하위 집합으로 테스트
+ 마이그레이션을 위한 애플리케이션 준비
+ InfluxDB 3.0은 수십억 개의 시리즈에 최적화된 열 기반 스토리지를 사용합니다.
### 시나리오: 쿼리 대기열 빌드업
**CloudWatch 지표 검토:**
+ 결과=queue\$1error가 증가하는 **QueryRequestsTotal**(쿼리가 거부됨)
+ 상태=429 또는 상태=503인 **APIRequestRate**(서비스를 사용할 수 없음/요청이 너무 많음)
+ **CPUUtilization**이 승격(> 70%)되어 리소스 포화를 나타낼 수 있습니다.
+ **MemoryUtilization**은 쿼리 용량을 제한(> 70%)할 수 있습니다.
+ 응답 크기가 큰 **QueryResponseVolume**(쿼리에 과도한 리소스 사용)
**조사 단계:**
**대기열 및 동시성 지표 분석:**
+ 결과 유형별 **QueryRequestsTotal** 분석 검토:
+ queue\$1error 수가 높으면 쿼리가 거부되고 있음을 나타냅니다.
+ 성공률을 기준과 비교 - 감소하나요?
+ runtime\$1error 증가 확인(시작 후 쿼리 실패)
+ **APIRequestRate** 패턴 모니터링:
+ 상태=429(요청이 너무 많음) 또는 상태=503(서비스 사용 불가)을 찾습니다.
+ 거부가 발생한 엔드포인트 식별
+ 시간 경과에 따른 요청 속도 추세 확인
**리소스 사용률 검토:**
+ CPU대기열이 많은 기간 동안의 **CPUUtilization**:
+ > 70%인 경우 쿼리는 CPU 바운드이며 더 빠르게 실행할 수 없습니다.
+ < 50%인 경우 대기열 제한이 너무 제한적일 수 있습니다.
+ **MemoryUtilization** 상관관계:
+ 메모리가 높으면 쿼리 동시성이 제한될 수 있습니다.
+ **HeapMemoryUsage** 및 **ActiveMemoryAllocation**에서 메모리 압력 확인
+ **TotalIOpsPerSec** 패턴:
+ I/O가 높으면 쿼리 실행 속도가 느려질 수 있습니다.
+ 쿼리가 I/O 바인딩되었는지 확인
**쿼리 패턴 식별:**
+ **QueryResponseVolume** 검토:
+ 쿼리가 과도한 데이터(> 1MB)를 반환하나요?
+ 응답 볼륨이 가장 큰 엔드포인트 식별
+ 값비싼 쿼리에서 패턴 찾기
+ **QueryRequestsTotal** 비율 분석:
+ 초당 쿼리 속도는 얼마입니까?
+ 버스트 패턴이나 지속적인 높은 부하가 있습니까?
+ 크기 조정 테이블의 인스턴스 용량과 비교
+ 엔드포인트별 **APIRequestRate** 확인:
+ 트래픽이 가장 높은 쿼리 엔드포인트는 무엇입니까?
+ 중복 또는 중복 쿼리가 있습니까?
**리소스 가용성 확인:**
+ 현재 지표와 크기 조정 테이블 권장 사항을 비교합니다.
+ **SeriesCardinality**와 인스턴스 클래스 용량 비교
+ 쿼리 속도 대 초당 권장 쿼리
+ **CPUUtilization** 및 **MemoryUtilization** 헤드룸
+ IOPS 용량 확인:
+ **TotalIOpsPerSec**에는 30%의 헤드룸이 있어야 합니다.
+ 쿼리가 디스크 I/O에서 대기 중인지 확인
**해결 단계:**
구성 변경 사항:
**우선 순위 1: 대기열 용량 증가**
+ query-queue-size: 4096(기본값 1024부터)
**우선순위 2: 동시성 향상(리소스가 허용하는 경우)**
+ 쿼리 동시성: vCPUs의 75%로 증가
+ 예: 16 vCPU → query-concurrency = 12
+ 변경 후 CPUUtilization이 < 80%로 유지되는지 확인
+ 변경 후 MemoryUtilization이 < 80%로 유지되는지 확인
**우선순위 3: 쿼리 실행 최적화**
+ query-memory-bytes: 적절한 할당 보장
+ storage-series-id-set-cache-size: 1000-1500
+ http-read-timeout: 120초(조기 제한 시간 방지)
**우선 순위 4: 보호 한도 설정**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
**애플리케이션 수준 솔루션:**
+ **쿼리 결과 캐싱 구현**(Redis, Memcached)
+ 자주 실행되는 쿼리에 대한 캐시 결과
+ 데이터 최신성 요구 사항에 따라 적절한 TTLs 설정
+ 모니터 캐시 적중률
+ **연속 쿼리를 사용하여** 공통 패턴 사전 집계
+ 공통 집계 사전 계산
+ 원시 데이터 대신 사전 집계된 데이터 쿼리
+ 대규모 결과 집합에 **페이지 매김 추가**
+ 초기 쿼리 크기 제한
+ 온디맨드 추가 데이터 로드
+ 사용자/대시보드당 **쿼리 속도 제한 구현**
+ 단일 사용자가 시스템에 부담을 주지 않도록 방지
+ 공정 사용 할당량 설정
+ 기록 쿼리에 **다운샘플링된 데이터 사용**
+ 이전 시간 범위에 대한 저해상도 데이터 쿼리
+ 최근 데이터에 대한 전체 해상도 쿼리 예약
**조정 결정:**
+ CPUUtilization > 70% 지속: 더 큰 인스턴스로 확장
+ MemoryUtilization > 70% 지속: 메모리 최적화 인스턴스로 확장
+ 쿼리 속도가 인스턴스 용량을 초과하는 경우: 크기 조정 테이블당 다음 계층으로 확장