Amazon Timestream for LiveAnalytics와 유사한 기능을 원하는 경우 Amazon Timestream for InfluxDB를 고려해 보세요. 간소화된 데이터 수집과 실시간 분석을 위한 10밀리초 미만의 쿼리 응답 시간을 제공합니다. 여기에서 자세히 알아보세요.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
InfluxDB 2 Timestream의 모니터링 및 구성 최적화
개요
효과적인 모니터링 및 구성 최적화는 Timestream for InfluxDB 배포에서 최적의 성능, 안정성 및 비용 효율성을 유지하는 데 매우 중요합니다. 이 가이드에서는 InfluxDB 인스턴스를 사전에 관리하는 데 도움이 되는 CloudWatch 지표, 성능 임계값 및 구성 튜닝 전략에 대한 포괄적인 지침을 제공합니다.
CloudWatch 지표 참조
Amazon CloudWatch는 Timestream for InfluxDB 인스턴스를 모니터링하기 위한 자세한 지표를 제공합니다. 이러한 지표와 임계값을 이해하는 것은 시스템 상태 및 성능을 유지하는 데 필수적입니다.
리소스 사용률 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
|---|---|---|---|---|
| CPUUtilization | DbInstanceName | 사용 중인 CPU의 백분율 | % |
|
| MemoryUtilization | DbInstanceName | 사용 중인 메모리의 백분율 | % |
|
| HeapMemoryUsage | DbInstanceName | 사용 중인 힙 메모리의 양 | 바이트 |
|
| ActiveMemoryAllocation | DbInstanceName | 현재 활성 메모리 할당 | 바이트 |
|
| DiskUtilization | DbInstanceName | 사용 중인 디스크 공간의 백분율 | % |
|
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 작업 수(읽기 + 쓰기) | 개수/초 | 프로비저닝된 IOPS 미만으로 ≥ 30% 헤드룸 유지 인스턴스 클래스 기능에 대한 모니터링 |
처리량 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
|---|---|---|---|---|
| ReadThroughput | DbInstanceName | 데이터 읽기 처리량 | 바이트/초 | 스토리지 처리량 제한을 기준으로 모니터링 |
| WriteThroughput | DbInstanceName | 데이터 쓰기 처리량 | 바이트/초 | 스토리지 처리량 제한을 기준으로 모니터링 |
API 성능 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
|---|---|---|---|---|
| APIRequestRate | DbInstanceName, 엔드포인트, 상태 | 상태 코드가 있는 특정 엔드포인트에 대한 API 요청 속도(2xx, 4xx, 5xx) | 개수/초 |
오류 발생률:
|
| QueryResponseVolume | DbInstanceName, 엔드포인트, 상태 | 엔드포인트 및 상태 코드별 쿼리 응답 볼륨 | 바이트 |
|
쿼리 실행 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 권장 임계값 |
|---|---|---|---|---|
| QueryRequestsTotal | DbInstanceName, 결과 | 결과 유형별 총 쿼리 요청 수(성공, runtime_error, compile_error, queue_error) | 개수 |
성공률: > 99% 오류 발생률:
|
데이터 조직 지표
| CloudWatch 지표 이름 | 측정 기준 | 설명 | 단위 | 중요 임계값 |
|---|---|---|---|---|
| SeriesCardinality | DbInstanceName, 버킷 | 버킷의 고유 시계열 수 | 개수 |
|
| TotalBuckets | DbInstanceName | 인스턴스의 총 버킷 수 | 개수 |
|
시스템 상태 지표
| 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 + WriteOpsPerSec) / 프로비저닝된 IOPS × 100
대상: IOPS 사용률 < 70% 유지
경고: IOPS 사용률 > 70%
심각: IOPS 사용률 > 90%
시리즈 카디널리티 성능 영향 이해
시리즈 카디널리티는 시스템 리소스에 여러 효과를 미칩니다.
| 시리즈 수 | 메모리 영향 | 쿼리 성능 영향 | 인덱스 크기 영향 | 권장 사항 |
|---|---|---|---|---|
| < 100K | 최소화 | 무시할 수 있음 | 작은 | 표준 구성 |
| 100K~1M | 보통 | 10~20% 느림 | 중간 | 캐시 설정 튜닝 |
| 1M~5M0만 | 중요 | 30~50% 느림 | 대형 | 적극적인 최적화 필요 |
| 5M~10M | 높음 | 50~70% 느림 | 매우 큼 | 최대 튜닝, 재설계 고려 |
| > 10M | 심각 | 70% 이상 느림 | 과도한 | InfluxDB 3.0으로 마이그레이션 |
10M이 중요 임계값인 이유:
InfluxDB 2.x 아키텍처는 인 메모리 인덱싱을 사용합니다.
10M 시리즈에서 인덱스 작업은 엄청난 비용이 듭니다.
메모리 요구 사항이 비선형으로 증가
쿼리 계획 오버헤드가 크게 증가
InfluxDB 3.0은 높은 카디널리티를 위해 설계된 열 기반 스토리지 엔진을 사용합니다.
인스턴스 크기 조정 및 성능 지침
다음 표에서는 시리즈 카디널리티 및 워크로드 특성에 따라 적절한 인스턴스 크기 조정에 대한 지침을 제공합니다.
| 최대 시리즈 수 | 쓰기(회선/초) | 읽기(쿼리/초) | 권장 인스턴스 | [Storage Type] | 사용 사례 |
|---|---|---|---|---|---|
| < 100K | ~50,000 | < 10 | db.influx.large | Influx IO 포함 3K | 소규모 배포, 개발, 테스트 |
| < 1M | ~150000 | < 25 | db.influx.2xlarge | Influx IO 포함 3K | 중소 규모의 프로덕션 워크로드 |
| ~1백만 | ~200,000 | ~25 | db.influx.4xlarge | Influx IO 포함 3K | 중간 프로덕션 워크로드 |
| < 5M | ~250,000 | ~35 | db.influx.4xlarge | Influx IO 포함 12K | 대규모 프로덕션 워크로드 |
| < 10M | ~500,000 | ~50 | db.influx.8xlarge | Influx IO 포함 12K | 매우 큰 프로덕션 워크로드 |
| ~1천만 | < 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~75%로 설정
예: 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_error 또는 runtime_error에서 이러한 임계값을 초과하는 쿼리가 실패합니다. QueryRequestsTotal 이렇게 하면 시스템이 리소스 소진으로부터 보호되지만 이전에 작동했던 기존 쿼리가 중단될 수 있습니다.
모범 사례: 이러한 변경 사항을 적용하기 전에 QueryResponseVolume 및 QueryRequestsTotal 지표를 사용하여 쿼리 패턴을 분석합니다. 가장 비용이 많이 드는 쿼리를 먼저 식별하고 최적화 - 시간 범위 필터가 없는 쿼리, 높은 카디널리티 시리즈에 걸친 쿼리 또는 과도한 데이터 포인트를 요청하는 쿼리를 찾습니다. 기능을 손상시킬 수 있는 엄격한 제한을 적용하는 것보다 애플리케이션 수준에서 쿼리를 최적화하는 것이 항상 좋습니다.
하드웨어 작업:
vCPUs 더 많은 다음 인스턴스 클래스로 확장
쿼리 패턴에서 최적화 기회 검토
높은 메모리 사용률(MemoryUtilization > 70%)
증상:
MemoryUtilization > 70% 지속
HeapMemoryUsage 상향 추세
스파이크를 보여주는 ActiveMemoryAllocation
SeriesCardinality(카디널리티가 높으면 메모리 사용량이 증가함)
구성 조정:
우선 순위 1: 캐시 메모리 감소
storage-cache-max-memory-size: 총 RAM의 10~15%로 설정
예: 32GB RAM → 3,355,443,200~5,033,164,800바이트
storage-cache-snapshot-memory-size: 26,214,400(25MB)
우선 순위 2: 쿼리 메모리 제한
query-memory-bytes: 총 RAM의 60~70%로 설정
query-max-memory-bytes: query-memory-bytes와 동일
query-initial-memory-bytes: query-memory-bytes의 10%
우선 순위 3: 시리즈 캐시 최적화
storage-series-id-set-cache-size: 카디널리티가 높은 경우 축소
고용량 메모리: 100~200
정상: 500-1000
중요 고려 사항:
이러한 변경으로 인해 메모리 부담이 줄어들지만 애플리케이션 성능에 직접적인 부정적인 영향을 미칩니다. 데이터를 줄storage-cache-max-memory-size이면 메모리에 캐시되는 데이터가 줄어들어 디스크 읽기가 강제로 늘어나고 쿼리 지연 시간이 늘어납니다. ReadOpsPerSec가 증가하고 QueryResponseVolume 응답 시간이 저하될 수 있습니다.
제한query-memory-bytes으로 인해 QueryRequestsTotal의 runtime_error, 특히 대규모 데이터 세트를 집계하거나 상당한 결과 세트를 반환하는 쿼리로 인해 메모리 집약적 쿼리가 실패합니다. 이전에 성공한 쿼리에 대해 사용자에게 "메모리 부족" 오류가 발생할 수 있습니다.
를 줄이면 캐시에서 검색하는 대신 시리즈 결과를 더 자주 다시 계산해야 하므로 카디널리티가 높은 데이터에 대한 쿼리 성능이 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시간 동안 로컬 스토리지에 보관됩니다.
로그가 큰 경우 즉시 작업:
설정
log-level: info(디버그에서)flux-log-enabled: FALSE설정즉각적인 개선을 위해 DiskUtilization 모니터링
압축 구성 절충 사항:
이러한 구성 변경은 수집 처리량이 높고 디스크 사용량이 크게 변동하는 보존 기간이 짧은 워크로드를 위해 특별히 설계되었습니다. 압축 엔진이 더 적극적으로 작동하도록 하므로 특정 시나리오에서만 유용합니다.
중요한 장단점: 압축 빈도를 늘리면 리소스 소비가 크게 증가합니다.
압축 작업에서 CPU 주기를 소비하면 CPU CPUUtilization 증가합니다.
데이터가 로드되고 처리되면 압축 중에 MemoryUtilization이 증가합니다.
WriteOpsPerSec 및 WriteThroughput은 압축 기간 동안 급증하여 잠재적으로 30% IOPS 헤드룸을 초과할 수 있습니다.
압축 I/O가 애플리케이션 쓰기와 경쟁하는 경우 WriteTimeouts가 증가할 수 있습니다.
이러한 변경으로 인해 공격적인 압축이 쿼리 및 쓰기 작업에 필요한 리소스를 소비하여 디스크 사용량을 줄이더라도 전체 시스템 성능이 저하되는 계단식 성능 문제가 발생할 수 있습니다.
모범 사례: 압축 설정을 조정하기 전에 데이터 및 로깅 관리에 집중하세요.
로깅 먼저 확인(가장 일반적인 문제): 로그 수준이 '정보'이고 flux-log-enabled가 FALSE인지 확인
데이터 모델 검토: 실제로 필요하지 않은 데이터를 쓰고 있나요? 측정 또는 필드 세분화를 줄일 수 있나요?
보존 정책 최적화: TotalBuckets 확인 및 각 버킷의 보존 설정 검토
압축 영향 모니터링: 변경 전에 CPUUtilization, MemoryUtilization 및 WriteOpsPerSec 기준 지정
대체 접근 방식:
스토리지 용량 증가(종종 더 간단하고 비용 효율적)
데이터 다운샘플링 또는 집계 전략 구현
버킷 통합(TotalBuckets 수 감소)으로 오버헤드 감소
보존 정책을 더 엄격하게 검토 및 적용
데이터 관리를 최적화하고 인스턴스에 늘어난 부하를 처리하기에 충분한 CPU, 메모리 및 IOPS 헤드룸이 있는지 확인한 경우에만 공격적인 압축 설정을 적용합니다.
하드웨어 작업:
스토리지 용량 늘리기
높은 IOPS 사용률(ReadIOPS/WriteIOPS/TotalOperationsPerSecond > 프로비저닝의 70%)
모니터링할 CloudWatch 지표:
ReadOpsPerSec + 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_error 비율이 증가할 수 있습니다.
스냅샷 빈도 줄이기:
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_error 비율이 증가할 수 있음)
구성 조정:
우선 순위 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_error와 함께 합법적인 쿼리가 실패합니다. 이전에 작동한 대시보드가 중단될 수 있으며 사용자는 쿼리를 수정해야 합니다. 이는 다음과 같은 경우에 특히 문제가 됩니다.
여러 호스트/서비스에서 집계되는 대시보드 모니터링
여러 엔터티를 비교해야 하는 분석 쿼리
플릿 전체 조건을 평가하는 알림 쿼리
더 작은 값으로 조정storage-max-index-log-file-size하면 인덱스 압축 빈도가 증가하여 시스템에서 인덱스 유지 관리를 더 자주 수행할 때 CPUUtilization 및 WriteOpsPerSec가 증가합니다.
중요한 이해:
SeriesCardinality가 5M을 초과하면 InfluxDB 2.x의 아키텍처 제한에 근접하게 됩니다. 10M 이상의 시리즈에서는 구성에 관계없이 성능이 기하급수적으로 저하됩니다.
쿼리 계획 비용이 매우 많이 듭니다(CPUUtilization).
메모리 요구 사항이 비선형으로 증가(MemoryUtilization 높음)
인덱스 작업이 I/O를 지배함(ReadOpsPerSec, WriteOpsPerSec)
쿼리 제한 시간 또는 소진 메모리에 따라 QueryRequestsTotal runtime_error 속도가 증가합니다.
모범 사례: 구성 변경은 임시 밴드 지원입니다. 근본 원인을 해결해야 합니다.
데이터 모델 분석:
버킷당 SeriesCardinality를 검토하여 문제 영역 식별
고유 값 수가 높은 태그 식별
무제한 태그 값(UUIDs, 타임스탬프, 사용자 IDs, 세션 IDs) 찾기
대신 필드여야 하는 태그 찾기
데이터 모델 작업:
태그 설계를 검토하여 불필요한 카디널리티 감소
유사한 시리즈 통합 고려
> 10M 시리즈인 경우: InfluxDB 3.0으로 마이그레이션 계획
쿼리 성능 문제
모니터링할 CloudWatch 지표:
결과 유형별 QueryRequestsTotal(성공, runtime_error, compile_error, queue_error)
상태=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_error rate가 감소하지만 사용자 경험이 개선되지 않을 수 있습니다.
를 늘리면 조기 쿼리 취소를 http-read-timeout 방지할 수 있지만 다음과 같습니다.
장기 실행 쿼리는 리소스를 더 오래 소비하여 다른 쿼리의 용량을 줄입니다.
사용자가 제한 시간 오류를 수신하기 전에 더 오래 대기
최적화해야 하는 비효율적인 쿼리를 숨길 수 있음
느린 쿼리가 많이 누적되면 리소스가 소진될 수 있습니다.
모범 사례: 쿼리 성능 문제는 일반적으로 리소스 부족이 아닌 비효율적인 쿼리로 인해 발생합니다. 리소스 할당을 늘리기 전에:
쿼리 패턴 분석:
QueryResponseVolume을 검토하여 과도한 데이터(> 1MB)를 반환하는 쿼리를 식별합니다.
QueryRequestsTotal runtime_error 패턴 확인 - 실패의 원인은 무엇입니까?
상태=499(클라이언트 제한 시간)인 APIRequestRate 찾기 - 쿼리가 너무 느림
자주 실행되는 값비싼 쿼리 식별
먼저 쿼리 최적화:
일반 쿼리 안티 패턴:
시간 범위 필터 누락 → 명시적 시간 범위 추가
모든 시리즈 쿼리 → 특정 태그 필터 추가
과도한 집계 기간 → 적절한 간격 사용
SELECT → Request only needed data의 불필요한 필드
LIMIT 절 없음 → 합리적인 제한 추가
애플리케이션 수준 솔루션:
쿼리 결과 캐싱 구현(Redis, Memcached)
작업을 사용하여 공통 패턴 사전 집계
대규모 결과 집합에 페이지 매김 추가
사용자/대시보드당 쿼리 속도 제한 구현
기록 쿼리에 다운샘플링된 데이터 사용
리소스 가용성 확인:
CPUUtilization 확인 - 이미 > 70%인 경우 동시성이 증가하면 상황이 악화됩니다.
MemoryUtilization 확인 - 이미 > 70%인 경우 더 많은 쿼리 메모리를 할당하면 OOM이 발생합니다.
쿼리 로드를 늘리기 전에 TotalIOpsPerSec에 30%의 헤드룸이 있는지 확인
권장 접근 방식:
먼저 가장 비용이 많이 드는 상위 10개 쿼리를 최적화합니다(QueryResponseVolume 기준).
애플리케이션 수준에서 쿼리 결과 캐싱 구현
쿼리가 최적화되고 지표에 헤드룸이 표시되는 경우에만 리소스 할당을 늘리세요.
워크로드가 현재 용량을 초과한 경우 더 큰 인스턴스 클래스로 확장
하드웨어 작업:
컴퓨팅 용량 확장, 쿼리는 추가 처리 성능(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_error인 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 비활성화됩니다.
검증 검사를 건너뛰어 쓰기 처리량을 개선합니다.
심각한 위험: 형식이 잘못되었거나 악의적인 데이터를 작성할 수 있습니다.
쓰기에 잘못된 필드 크기가 포함된 경우 데이터가 손상될 수 있습니다.
디버깅 데이터 문제를 훨씬 더 어렵게 만듭니다.
데이터 소스를 완벽하게 제어하고 신뢰할 수 있는 경우에만 사용
모범 사례: 쓰기 성능 문제는 일반적으로 용량 제한 또는 비효율적인 쓰기 패턴을 나타냅니다. 구성을 튜닝하기 전에:
쓰기 패턴 분석:
WriteThroughput 및 WriteOpsPerSec 추세 검토
쓰기 로드와 WriteTimeouts 상관 관계 확인
상태 코드별 APIRequestRate의 쓰기 엔드포인트 모니터링
쓰기 배치 크기 및 빈도 식별
먼저 쓰기 작업 최적화:
일반적인 쓰기 방지 패턴:
개별 포인트 쓰기 → 배치 쓰기(5,000~10,000 포인트)
쓰기 빈도가 너무 높음 → 버퍼 및 배치
동기 쓰기 → 비동기 쓰기 대기열 구현
무제한 쓰기 버스트 → 속도 제한 구현
불필요한 정밀도 작성 → 타임스탬프를 적절하게 반올림
I/O 용량 확인:
TotalIOpsPerSec 확인 - 이미 > 70%인 경우 WAL 동시성이 증가하면 상황이 악화됩니다.
피크 기간 동안 WriteOpsPerSec 검토
쓰기 설정을 튜닝하기 전에 30% IOPS 헤드룸이 존재하는지 확인합니다.
3K IOPS로 충분한지 또는 12K IOPS 계층이 필요한지 고려
애플리케이션 수준 개선 사항:
구성 가능한 배치 크기로 쓰기 버퍼링 구현
지수 백오프를 사용하여 쓰기 재시도 로직 추가
비동기 쓰기 작업 사용
피크 기간 동안 쓰기 속도 제한 구현
쓰기 대기열 깊이 모니터링 및 역압 적용
권장 접근 방식:
먼저 애플리케이션 수준에서 쓰기 배치 크기를 최적화합니다(배치당 5,000~10,000포인트 목표).
쓰기 버퍼링 및 비동기 작업 구현
TotalIOpsPerSec에 적절한 헤드룸이 있는지 확인
사용률이 지속적으로 70%를 초과하는 경우 다음 스토리지 계층(3K IOPS → 12K IOPS → 16K IOPS)으로 업그레이드
쓰기가 최적화되고 I/O 용량이 적절한 경우에만 WAL 설정을 조정합니다.
데이터 소스를 완전히 제어할 수 없는 한 필드 검증을 비활성화하지 마세요.
하드웨어 작업:
더 높은 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_error):
임계값: 총 쿼리의 > 1%
작업: 워크로드 또는 트래픽의 변경 사항 검토
WriteTimeouts:
임계값: 쓰기 작업의 > 1%
작업: 워크로드 또는 트래픽의 변경 사항 검토
SeriesCardinality:
임계값: > 5,000,000
작업: 데이터 모델 최적화 검토
사전 모니터링 체크리스트
일별:
APIRequestRate에서 오류 스파이크(400, 404, 499, 500) 검토
QueryRequestsTotal에서 runtime_error 및 queue_error 비율 확인
WriteTimeouts 수가 최소인지 확인
중요한 경보가 있는지 확인
EngineUptime 확인(예상치 않게 다시 시작되지 않음)
매주:
CPUUtilization, MemoryUtilization 및 DiskUtilization 추세 검토
결과 유형별 QueryRequestsTotal 패턴 분석
버킷당 SeriesCardinality 증가율 확인
TotalIOpsPerSec 사용률 추세 검토
구성 파라미터가 최적인지 확인
TaskExecutionFailures 패턴 검토
월별:
용량 계획 검토(3~6개월 전 프로젝트)
현재 지표와 크기 조정 테이블 비교
보존 정책 검토 및 최적화
APIRequestRate 및 QueryResponseVolume의 쿼리 패턴 분석
SeriesCardinality 및 데이터 모델 효율성 검토
인스턴스 크기 조정 또는 구성 변경의 필요성 평가
TotalBuckets 및 통합 기회 검토
문제 해결 안내서
시나리오: 갑작스러운 성능 저하
조사 단계:
최근 변경 사항 확인:
AWS 관리 콘솔에서 구성 파라미터 수정
애플리케이션 배포 변경 사항
쿼리 패턴 변경
데이터 모델 수정
인프라 변경(인스턴스 유형, 스토리지)
CloudWatch 지표 검토:
CPU 스파이크? → CPUUtilization, QueryRequestsTotal 확인
메모리 압력? → MemoryUtilization, HeapMemoryUsage, ActiveMemoryAllocation 확인
IOPS 포화 여부 → TotalIOpsPerSec, ReadOpsPerSec, WriteOpsPerSec 확인
시리즈 카디널리티 점프? → SeriesCardinality 증가 확인
오류율 증가 여부 → QueryRequestsTotal(runtime_error), APIRequestRate(Status=500) 확인
예기치 않은 재시작? → EngineUptime 확인
세부 로깅 활성화:
구성 변경:
로그 수준: 디버그
flux-log-enabled: TRUE
1~2시간 동안 모니터링한 다음 로그 검토
로그 수준: 조사 후 정보로 돌아가기
해결 단계:
조사 결과에 따라 적절한 구성 변경 사항 적용
한도에 도달하면 리소스 규모 조정
필요한 경우 쿼리 또는 데이터 모델 최적화
갑작스러운 부하 증가 시 속도 제한 구현
시나리오: 메모리 소진
증상:
MemoryUtilization > 90%
HeapMemoryUsage가 최댓값에 가까워짐
runtime_error(메모리 부족)를 보여주는 QueryRequestsTotal
상태=500을 보여주는 APIRequestRate
해결 단계:
즉각적인 조치(중요한 경우):
인스턴스를 다시 시작하여 메모리를 지웁니다(안전한 경우).
쿼리 동시성 일시적 감소
가능하면 장기 실행 쿼리 제거
구성 변경 사항:
우선 순위 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 감소
애플리케이션 수준에서 쿼리 결과 크기 제한 구현
쿼리 제한 시간 적용 추가
가장 일반적인 쿼리를 검토하여 섹션에 언급된 모범 사례를 따르는지 확인합니다. 쿼리 성능 문제
시나리오: 높은 시리즈 카디널리티 영향
CloudWatch 지표 검토:
SeriesCardinality > 5M
MemoryUtilization 높음
런타임_오류 증가를 보여주는 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~3개월)
먼저 데이터 하위 집합으로 테스트
마이그레이션을 위한 애플리케이션 준비
InfluxDB 3.0은 수십억 개의 시리즈에 최적화된 열 기반 스토리지를 사용합니다.
시나리오: 쿼리 대기열 빌드업
CloudWatch 지표 검토:
결과=queue_error가 증가하는 QueryRequestsTotal(쿼리가 거부됨)
상태=429 또는 상태=503인 APIRequestRate(서비스를 사용할 수 없음/요청이 너무 많음)
CPUUtilization이 상승(> 70%)되어 리소스 포화를 나타낼 수 있습니다.
MemoryUtilization은 쿼리 용량을 제한(> 70%)할 수 있습니다.
큰 응답 크기를 보여주는 QueryResponseVolume(과도한 리소스를 사용하는 쿼리)
조사 단계:
대기열 및 동시성 지표 분석:
결과 유형별 QueryRequestsTotal 분석 검토:
queue_error 수가 높으면 쿼리가 거부되고 있음을 나타냅니다.
성공률을 기준과 비교 - 감소하나요?
runtime_error 증가 확인(시작 후 쿼리 실패)
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% 지속: 메모리 최적화 인스턴스로 확장
쿼리 속도가 인스턴스 용량을 초과하는 경우: 크기 조정 테이블당 다음 계층으로 확장
