[Redis] Reids 내용 정리

Monitoring Metrics

• Redis는 많은 트래픽을 처리할 수 있기 때문에, Redis에 문제가 생기면 전체 성능 저하로 이어질 수 있다.
• 문제를 감지하고자 모니터링을 사용한다.

---

Monitoring Metrics 수집 방법

• info all 명령으로 Redis 자체에서 제공하는 Metrics를 확인할 수 있다.

대항목	항목	내용
memory	used_memory_rss	Redis가 현재 사용하고 있는 실제 물리 메모리 양, 실제 메모리 양이 많으면 Swap이 일어나서 성능이 많이 떨어진다.
	used_memory	현재 Redis가 계산하고 있는 사용 메모리 양, malloc의 값을 저장하고 있다가 보여준다.
	mem_fragmentation_ratio	used_memory와 used_memory_rss의 비율, 비율이 높으면 fragmentation이 높다고 보면 되고, 1보다 적으면 swap이 발생하고 있다고 생각하면 된다.
stats	instantaneous_ops_per_sec	초당 실행 명령 수, Redis는 CPU의 영향을 받으므로, 더 좋은 CPU를 사용하면 명령 처리량이 늘어난다.
	total_commands_processed	지금까지 처리한 명령 수
	expired_keys	지금까지 expireation이 발생한 이벤트의 수
	keyspace_hits	캐시 Hit한 수
	keyspace_misses	캐시 Miss한 수
clients	connected_clients	현재 접속해 있는 클라이언트의 수, Redis는 싱글 스레드 기반이라 클라이언트가 지속적으로 연결/연결 해제를 할 경우 성능이 저하되므로, 해당 값이 크게 계속 바뀌면 성능이 떨어진다.
	maxclients	접속할 수 있는 최대 클라이언트의 수
replication	master_repl_offset	Primary의 replication offset
	slave_repl_offset	Secondary의 repliacation offset, replica에만 존재하고, master_repl_offset - slave_repl_offset이 현재 replication lag이다.

• Host Metrics
  • Redis CPU 사용률
  • 메모리 사용량(Free Memory)
  • Network In/Out Size
  • Disk Usage
    
    
• 명령 모니터링
  • info all 명령어 결과의 Commandstats 파트를 확인한다.
  • keys 명령어는 되도록 사용하지 않아야 한다. -> 해당 calls 값이 증가하면 잘못된 명령어를 사용하고 있다는 것
    1. 매우 느린 명령어 처리 속도
       

---

Redis 장애

• 장애 원인
  • Redis는 Main Thread가 대부분의 처리를 하는 Single Threaded 형태이기 때문에, 하나의 명령에서 시간이 많이 걸리면 전체적인 성능 저하가 발생한다.
  • 더 빠른 CPU, 더 많은 메모리를 달수록 성능이 좋아지지만, Scale Up을 하더라도, 잘못된 사용 패턴은 장애를 일으킬 수 있다.
    
    
• 장애 종류
  • Redis 메모리 부족으로 인한 이슈
    1. Redis의 처리 속도가 떨어진다. (Swap 등의 이슈)
    2. OOM 이슈로 처리 되지 않고 명령이 실패한다.
    3. Redis가 fork를 할 때, 메모리 사용량이 최대 두 배까지 늘어날 수 있다.
       * Redis가 fork 하게 되는 경우
       ** Replica가 연결이 되는 순간 데이터 이전을 위한 RDB를 만들면서 fork한다.
       ** AOF Rewrite를 하기 위한 경우(bgrewriteof 명령) fork
       ** RDB 생성을 하기 위한 경우 (bgsave 명령) fork
       
       * Copy on Write 이슈
       ** fork를 할 경우 부모와 자식 프로세스가 읽기용 메모리는 공유해서 메모리를 절약한다.
       ** 공유 메모리에 쓰기가 발생하는 프로세스가 해당 메모리를 복사해서 사용하게 된다.
       ** Redis에서 Child Process는 RDB 생성을 담당하기 때문에 주로 읽기만 발생한다.
       ** Write로 인해 해당 메모리 Page에 변경이 발생한 프로세스는 해당 메모리 Page를 복사하고 여기에 Write를 실행한다.
       ** 이로 인해, 전체 공유된 Page에 Write가 발생하면서 최대 메모리 사용량이 두 배까지 증가한다.
       ** 최대 메모리 사용량이 두 배가 될 수 있기 때문에, 한 대의 Redis 서버의 메모리 사용량을 물리 메모리의 절반 이하로 유지하는 것이 좋다.
       
       
  • Redis SlowLog의 문제점
    1. Redis의 SlowLog는 실제 요청이 처리된 시간을 기준으로 한다.
    2. 앞의 명령어 대기로 인한 느린 실행 시간은 Redis 내에서 SlowLog를 남기지 않는다.
       
  • Redis Single Threaded 장애
    1. Redis의 Sorted Set, Hash, Set 등의 자료구조는 내부적으로 다시 Hash Table 등을 구성해서 관리하기 때문에 과도한 Value로 인한 장애가 발생할 수 있다.
       
    2. 사용하면 안되는 명령어를 사용 중인지 확인한다.
    3. O(N) 계열 커맨드의 사용이 늘어나는지 확인한다.
    4. Monitor 명령을 통해 들어오는 KEY 들의 빈도를 확인한다. -> Monitor 명령은 해당 서버에 부하를 추가로 주게 되므로 사용에 유의해야 한다.
    5. Scan 명령어를 통해서 각 Key의 사이즈를 확인하고 특정 크기 이상의 Key를 제거한다.
       
       

장애 타입	분류	내용
메모리	메모리 과다 사용 (maxmemory 설정)	Maxmemory가 설정되었을 때, maxmemory policy에 따라서, 더 이상 eviction 할 수 있는 메모리가 없다면 OOM 에러를 Redis가 전달한다.
	RSS 관리	Redis에서 실제 물리 메모리보다 더 많은 메모리를 사용하면, 해당 페이지에 Swap이 발생하고 이에 접근할 때마다 디스크 페이지에 접근할 수 있어 성능이 떨어진다. 실제 used memory와 RSS사용은 다르다.
설정	기본 설정 사용	기본 설정으로 사용 시에 SAVE 설정이 1시간에 1개, 5분에 100개, 1분에 10000개가 변경이 되면 디스크에 메모리를 덤프하게 되므로, IO를 과다하게 사용해서 장애가 발생한다.
싱글 스레드	과도한 Value 크기	Redis는 싱글 스레드이기 때문에 하나의 명령이 긴 시간을 차지하면 결국 Redis의 성능 저하로 이루어진다. Hgetall, hvals 등의 collection의 데이터를 과도하게 많이 가져오거나 몇 MB 이상의 Key, Value를 사용할 경우 문제가 발생한다.
	O(N) 명령어 사용	Keys나 flushdb/flushall, 큰 크기의 collection을 지우는 등의 명령어는 Redis의 성능을 떨어트린다.

• save 옵션 설정
  • SAVE "" 를 넣고 다른 SAVE 설정을 지운다. -> DISK에 RDB를 생성하지 않는다.

---

Redis 보안 관련

• 절대로 Redis의 포트를 public에 공개하면 안 된다.
  • Redis 6부터 ACL 설정을 제공한다.
    
    
• 해당 이슈로 전체 시스템의 보안 위협이 높아지는 경우가 많다.