데이터 쓰기 지연 처리 방법
개요¶
이 문서는 데이터 쓰기 지연 시간이 긴 문제를 해결하기 위한 트러블슈팅 가이드입니다.
인프라 설정 확인¶
1 시간 확인¶
Guance 관련 서비스 의 시스템 시간이 정상인지 확인합니다. 지연이 있는 경우 시스템 시간대와 시간을 조정합니다.
2 데이터 노드 설정 확인¶
스토리지 엔진의 데이터 노드 설정이 실제 리소스 상황에 맞게 수정되었는지 확인합니다.
1) 데이터 노드의 시스템 구성을 확인합니다.
2) 스토리지 엔진 관련 설정이 배포 시 수정되었는지 확인합니다.
3) 수정되지 않은 경우 아래 설정 가이드에 따라 수정합니다.
위에서 확인한 리소스 상태가 8c32g인 경우를 가정합니다.
# 일반적으로 limits 절반으로 설정
## 리소스가 충분히 큰 경우 최대 32g로 설정하면 그 이상은 리소스 낭비입니다.
- name: OPENSEARCH_JAVA_OPTS
value: -Xmx14g -Xms14g
# limits를 가득 채우지 말고 다른 프로그램 및 시스템에 CPU와 메모리 여유를 남겨둡니다.
resources:
limits:
cpu: "7"
memory: 28Gi
requests:
cpu: "7"
memory: 7Gi
비즈니스 로직 트러블슈팅¶
다음은 트러블슈팅 로직의 마인드맵입니다. 이에 따라 문제 해결 순서를 결정합니다.
1 kodo-x 서비스의 빈번한 재시작 확인¶
2 Redis 미들웨어 확인¶
Redis의 성능이 병목 지점에 도달했는지 확인합니다. CPU 또는 메모리 사용률이 너무 높으면 수직 확장이 필요합니다.
3 Topic 기반 스토리지 엔진 유형 확인¶
1) middleware 네임스페이스의 nsqadmin 서비스의 service 설정을 NodePort로 변경합니다.
브라우저를 사용하여 node_IP + 포트 형태로 접속합니다.
2) Topic 이름을 기준으로 스토리지 엔진 유형을 확인합니다.
df_metric_xxx로 시작하는 topic은 시계열 엔진이며, 나머지 topic은 모두 로그 엔진 데이터입니다.
3) 데이터 노드 성능 확인
리소스 사용량이 과도하게 발생하는 경우 엔진 예외 처리를 참조하세요.
4) 해당 서비스 데이터 확인
| 필드명 | 필드 설명 |
|---|---|
| Topic | 메시지 큐의 이름 |
| Depth | 현재 토픽 내 메시지 큐에서 처리되지 않은 메시지 수 |
| In-Flight | 현재 소비자가 가져갔지만 아직 처리가 완료되지 않은 메시지 수 |
| Deferred | 재전송 또는 명시적으로 지연되어 배포되지 않은 메시지 수 |
| Connections | 현재 최대 연결 동시 소비 수 |
4 엔진 예외 처리¶
4.1 단일 노드 부하 과다¶
Guance의 모든 인덱스 설정은 기본적으로 1개의 샤드로 구성되어 있어 하나의 데이터 노드만 처리하게 되어 성능 병목이 발생합니다. 따라서 백엔드 관리에 로그인하여 인덱스의 샤드 수를 조정하여 데이터 노드의 병렬 처리 능력을 높여야 합니다.
이 시점에 nsq 관리 페이지를 자주 새로고침하여 Channel의 Depth 누적 수가 현저히 감소하는지 확인합니다. 감소하면 처리가 성공한 것입니다.
4.2 클러스터 부하 과다¶
전체 클러스터 부하가 너무 높은 경우 수평 확장 또는 수직 확장을 고려합니다.
로그 엔진 용량 계획을 참조하세요.
5 소비 성능 부족, kodo-x 서비스 확장¶
위의 방법으로도 데이터 누적 문제가 해결되지 않으면 nsq 관리 인터페이스의 Channel connections 수가 너무 작아 대량의 데이터 요청을 처리하지 못하는 것일 수 있습니다. 이 경우 kodo-x 서비스의 수를 확장할 수 있습니다.
머신 리소스가 충분하다고 가정할 때, 일반적으로 2배씩 점진적으로 확장합니다. 위에서 언급한 nsq 관리 페이지의 Depth 누적이 현저히 감소할 때까지 진행합니다.