[Redis] Redis 간단하게 모니터링 하는 방법(bigkey, latency, slowlog)

ㅁ 개요

 ㅇ Grafana나 다른 APM 툴이 없는 상태에서 Redis를 서버상에서 모니터링하는 방법에 대해서 정리해 보았다.

 

 

ㅁ Redis 접근 shell 작성

[ec2-user@PRD-PETERICA-BASTION ilovefran]$ cat cli.sh
#!/bin/sh
redis-cli -h prd-peterica-main.cache.amazonaws.com $@

 ㅇ 서버에서 접속하지 않고 명령어를 수행 할 수 있도록 shell를 하나 생성한다.

 

 

ㅁ Redis 키별 용량 확인

[ec2-user@PRD-PETERICA-BASTION ilovefran]$ sh cli.sh --bigkeys

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest set found so far 'peterica-admin:session:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:es1278' with 5 members
[00.00%] Biggest zset found so far 'peterica_Z_FB_MMS_DAK_1' with 17362 members
[00.00%] Biggest set found so far 'peterica-admin:session:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:yoonjh' with 15 members
[00.00%] Biggest hash found so far 'peterica_H_A2P_RPT@SM144206_002' with 1 fields
[00.00%] Biggest hash found so far 'peterica_H_A2P_RPT@SM143916_021' with 11 fields
[00.00%] Biggest string found so far 'peterica_S_CPS_CLIENT_SM139686_689_20220525235858' with 1 bytes
[00.00%] Biggest list found so far 'peterica_Q_A2P_RPT@SM139686_579@20220525' with 1 items
[00.00%] Biggest list found so far 'peterica_Q_A2P_RPT@SM142550_004@20220525' with 14 items
[05.85%] Biggest set found so far 'peterica-admin:session:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:hclee1212' with 17 members
[05.85%] Biggest zset found so far 'peterica_Z_FB_MMS_DAK_4' with 17846 members
[05.85%] Biggest hash found so far 'peterica_H_FB_MMS_DAK' with 88576 fields
[05.85%] Biggest set found so far 'peterica-admin:session:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:peterica83' with 35 members
[11.70%] Biggest list found so far 'peterica_Q_A2P_RPT@SM144027_004@20220525' with 101 items
[17.54%] Biggest zset found so far 'peterica_Z_TS_MSG_DUP_CHECK' with 160933 members
[25.73%] Biggest string found so far 'peterica_S_CPS_peterica_LGU_peterica_uplus_1_20220525235858' with 2 bytes
[47.37%] Biggest string found so far 'peterica-admin:cache:menu::ROLE_ADMIN' with 2929 bytes
[63.74%] Biggest set found so far 'peterica-admin:session:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:ljs7924' with 39 members
[63.74%] Biggest set found so far 'peterica-admin:session:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:soonggu81' with 45 members
[69.59%] Biggest hash found so far 'peterica_H_080_ARS_REJECT' with 1657146 fields
[81.29%] Biggest list found so far 'peterica_Q_A2P_RPT@SM144027_004@20220524' with 169 items

-------- summary -------

Sampled 160 keys in the keyspace!
Total key length in bytes is 7428 (avg len 46.42)

Biggest list found 'peterica_Q_A2P_RPT@SM144027_004@20220524' has 169 items
Biggest hash found 'peterica_H_080_ARS_REJECT' has 1657146 fields
Biggest string found 'peterica-admin:cache:menu::ROLE_ADMIN' has 2929 bytes
Biggest set found 'peterica-admin:session:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:soonggu81' has 45 members
Biggest zset found 'peterica_Z_TS_MSG_DUP_CHECK' has 160933 members

30 lists with 544 items (18.75% of keys, avg size 18.13)
35 hashs with 1942693 fields (21.88% of keys, avg size 55505.51)
35 strings with 4571 bytes (21.88% of keys, avg size 130.60)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
32 sets with 335 members (20.00% of keys, avg size 10.47)
28 zsets with 279526 members (17.50% of keys, avg size 9983.07)

 ㅇ Redis의 주어진 key들을 하나씩 점검하면서 key의 type별로 가장 bigkey들을 정리하여 제공해주고 있다.

 ㅇ 초기에 퍼센트로 표시된 부분은 bigkey가 갱신 될 때마다 표출되고 있다. 예를 들어 set의 경우 6번 갱신되었음을 알 수 있다.

 ㅇ summary에서는 type에 따라 가장 큰 키를 정리해 주고 있다.

 ㅇ 비중이 높거나 데이터가 비대하게 늘어난 경우를 모니터링 할 수 있다.

 

 

ㅁ 지연속도 체크

[ec2-user@PRD-PETERICA-BASTION ilovefran]$ cat latency.sh
#!/bin/sh
#redis-cli -h prd-peterica.cache.amazonaws.com $@
sh cli.sh --latency-history

[ec2-user@PRD-PETERICA-BASTION ilovefran]$ sh latency.sh
min: 0, max: 4, avg: 0.17 (1460 samples) -- 15.00 seconds range
min: 0, max: 5, avg: 0.18 (1457 samples) -- 15.00 seconds range
min: 0, max: 4, avg: 0.16 (1461 samples) -- 15.01 seconds range

 ㅇ 15초 동안 명령어 처리되었던 시간을 체크하여 평균 시간을 history로 남겨준다.

 

[ec2-user@PRD-PETERICA-BASTION ilovefran]$ sh subLatency.sh
min: 0, max: 6, avg: 0.97 (1356 samples) -- 15.00 seconds range
min: 0, max: 10, avg: 0.93 (1353 samples) -- 15.01 seconds range
min: 0, max: 8, avg: 0.97 (1354 samples) -- 15.00 seconds range
min: 0, max: 4, avg: 0.94 (1355 samples) -- 15.01 seconds range
min: 0, max: 5, avg: 0.92 (1355 samples) -- 15.01 seconds range

 ㅇ Redis는 메모리 기반이기 때문에 메모리가 증가할 수록 처리 속도가 늦어진다.

 ㅇ 실제로 subRedis의 용량은 현재 8기가를 사용 중이고, mainRedis는 1.2기가를 사용 중이다.

     성능은 동일한 인스턴스를 사용하고 있지만 main이 4개를 처리하는 동안 sub는 1개를 처리할 수 있는 것이다.

 ㅇ 속도의 변화가 발생하였을 때를 모니터링하면, 특정 큐가 적체되어 있거나, 롱쿼리가 돌아간 경우가 많다.

 

 

ㅁ 롱쿼리 확인

[ec2-user@PRD-PETERICA-BASTION ilovefran]$ sh cli.sh slowlog get
1)  1) (integer) 47227
	2) (integer) 1653494993
	3) (integer) 74442
	4) 	1) "HGETALL"
		2) "PETERICA_H_STAT_MIN"
	5) "172.xxx.xxx.221:40006"
	6) ""
2) 	1) (integer) 47226
	2) (integer) 1653489960
	3) (integer) 18430
	4) 	1) "KEYS"
		2) "PETERICA_Q_RPT@139686_884@*"
	5) "172.xxx.xxx.134:46904"
	6) ""
3) 	1) (integer) 47225
	2) (integer) 1653489000
	3) (integer) 11117
	4) 1) "HGETALL"
		2) "PETERICA_H_CLIENT"
	5) "172.xxx.xxx.221:40006"
	6) ""
4) 	1) (integer) 47224
	2) (integer) 1653487216
	3) (integer) 11363
	4) 	1) "HKEYS"
		2) "PETERICA_H_STAT_MIN_SEND_CNT"
		5) "172.xxx.xxx.221:40006"
		6) ""

 ㅇ 롱쿼리가 돌았던 정보를 확인할 수 있다.

 ㅇ 소요된 시간과 실행된 시간(int형태로), 명령어, 그리고 접속 정보를 확인할 수 있다. 

 

ㅁ 경험

 ㅇ 실제로 롱쿼리가 돌았던 큐가 가비지성 데이터가 많이 적체가 되어 있었고,

     적체된 key는 bigkey 조회 시에도 확인이 되었다.

 ㅇ 해당 큐의 데이터가 2기가가 넘게 쌓여 있었는데, 이를 제가하였고,

     이로 인해 레디스 명령어 처리 지연속도가 개선되었다.

 ㅇ 결국, 메인 레디스의 처리 속도가 개선되면서 subNode(elasticSearch, batch, stat, mongodb가 있음)의 Disk IO가 부족하여

     병목현상이 발생하기도 하였지만 뜻밖의 성능개선 방법을 알게 되었던 기회였다. 

 

 

ㅁ 함께보면 좋은 사이트

http://redisgate.kr/redis/server/latency.php

https://mongsil1025.github.io/til/redis/redis/

http://redisgate.kr/redis/server/slowlog.php