[BigData] Ch07. Redis 장애 Case 및 대응

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

 

Redis 시스템을 운영하면서 발생할 수 있는 다양한 장애 상황과 그에 대한 대응 방법을 알아보자. 장애 발생 시 신속하고 효과적으로 대처할 수 있는 정보를 제공하여, 시스템의 안정성을 유지하는 데 도움이 되는 내용을 다룬다.

 

Case 1 : Master-Replica 전환 후 Client 의 인식

Redis 환경에서 Master와 Replica(이전 Slave)의 역할이 전환되는 경우가 있다. 이는 예를 들어 유지보수, 네트워크 이슈, 또는 Master 노드의 실패로 인한 자동 전환일 수 있다. Master-Replica 전환은 통상적으로 Redis Sentinel 같은 자동화된 도구를 사용하여 관리된다. 전환 과정에서 클라이언트는 새로운 Master에 쓰기를 시도해야 하는데, 캐시 된 이전 구성 때문에 오래된 Replica 정보를 참조하여 쓰기를 시도하게 되며, 이 Replica가 쓰기 금지 모드로 설정되어 있기 때문에 READONLY You can't write against a read-only replica라는 오류 메시지가 발생한다.

문제의 원인

클라이언트 라이브러리가 자동으로 새 Master를 인식하지 못하고 이전 구성을 계속 사용하기 때문에 발생한다.

 

Case 1 : Master-Replica 전환 후 Client 의 인식오류 : library 내 topology update 수행

클라이언트 라이브러리가 Redis 클러스터의 최신 구성을 정기적으로 갱신하도록 구성해야 한다. 대부분의 최신 Redis 클라이언트 라이브러리는 클러스터의 구성 변경을 자동으로 감지하고 적절히 반응할 수 있도록 설계되어 있다. 그러나, 몇몇 라이브러리는 수동으로 구성을 갱신하도록 설정해야 할 수도 있다.

• 라이브러리 업데이트: 사용 중인 Redis 클라이언트 라이브러리가 자동으로 구성 변경을 감지하지 못한다면, 이 기능을 지원하는 버전으로 업데이트를 고려한다.
• Topology Update 명령 실행: 일부 라이브러리는 명시적으로 topology update 명령을 실행해야 새 Master 노드에 대한 정보를 갱신할 수 있다. 이는 주로 라이브러리의 설정 파일이나 코드 내에서 실행할 수 있는 명령이다.
• Sentinel 설정 검토: Redis Sentinel 설정이 클라이언트와 동기화되어 구성 변경을 클라이언트에게 정확히 알릴 수 있도록 설정되어 있는지 확인한다. Sentinel은 Master 노드의 실패를 감지하고, 자동으로 Replica를 새 Master로 승격시키며, 연결된 클라이언트에게 변경 사항을 통보한다.

이러한 접근 방식을 통해 Redis 환경에서 Master-Replica 전환이 발생했을 때, 클라이언트가 즉시 새 Master에 적응하여 연속성 있게 데이터 쓰기 및 읽기 작업을 수행할 수 있도록 한다.

 

Case 2 : full sync 실패로 인한 장애 유발 : client-output-buffer-limit slave 수정

Redis에서 Master-Replica 간의 데이터 동기화 과정에서 Full Sync가 필요한 경우가 있다. 이는 주로 Replica가 처음 연결되었을 때, 또는 더 이상 Partial Sync가 가능하지 않을 때 발생한다. Full Sync 과정에서 Master는 현재 메모리 상태의 스냅샷을 RDB 파일로 만들고(즉, BGSAVE 명령 실행), 이 파일을 Replica에 전송한다. Replica는 이 RDB 파일을 사용하여 자신의 데이터 상태를 Master와 일치시킨다.

문제의 원인

Full Sync가 실패하는 주된 원인 중 하나는 Replica의 client-output-buffer-limit 설정이 너무 낮아 대량의 데이터를 받을 수 없는 경우다. Redis는 네트워크 버퍼를 관리하기 위해 client-output-buffer-limit를 사용하여, 특정 버퍼 크기를 초과하는 클라이언트 연결을 종료시킬 수 있다. 이 값이 너무 낮으면, 특히 대용량 데이터를 동기화해야 하는 경우 Replica가 동기화 중에 연결이 끊어질 수 있다.

 

대응 방법

• 버퍼 한계값 조정: client-output-buffer-limit slave 설정을 조정하여, Slave(Replica)가 더 큰 데이터를 처리할 수 있도록 한다. 예를 들어, Replica의 출력 버퍼 한계를 높여 주는 것이 필요하다. 기본 설정을 256mb 64mb 60에서 512mb 128mb 120 등으로 조정할 수 있다. 이는 더 큰 초기 동기화 데이터 또는 변경된 데이터를 처리할 수 있도록 버퍼 크기를 늘려주어 연결이 중단되는 것을 방지한다.
• 동기화 성능 모니터링: INFO replication 명령어를 사용하여 Replica의 동기화 상태와 성능을 모니터링한다. 이를 통해 동기화 진행 과정을 더 잘 이해하고 필요한 조치를 취할 수 있다.
• 네트워크 최적화: 네트워크 지연시간이나 대역폭 제한도 Full Sync 실패의 원인이 될 수 있다. 네트워크 인프라를 검토하고 최적화하여 데이터 전송 속도를 개선한다.

이러한 조치들을 통해 Full Sync 과정에서 발생할 수 있는 장애를 예방하고, Master와 Replica 간의 데이터 동기화의 안정성을 향상시킬 수 있다.

 

Case 3 : 통신불가로 인한 Buffer 증가, 데이터 삭제 : client-output-buffer-limit normal 수정

Redis에서 클라이언트와의 통신이 지연되거나 불가능할 때, 해당 클라이언트의 출력 버퍼가 계속해서 증가할 수 있다. 이는 네트워크 문제, 클라이언트의 처리 지연, 또는 클라이언트의 비정상적인 동작 등 다양한 원인으로 발생할 수 있다. Redis는 이러한 상황을 관리하기 위해 client-output-buffer-limit normal 설정을 사용하여 정상적인 클라이언트 연결의 출력 버퍼 사이즈를 제한한다.

문제의 원인

client-output-buffer-limit normal 설정이 너무 낮으면 정상적인 사용 중에도 클라이언트 연결이 종료될 수 있고, 설정이 너무 높으면 메모리 소모가 증가하여 서버 자체의 성능 저하나 안정성 문제를 일으킬 수 있다. 네트워크 문제로 인해 데이터 전송이 지연되는 경우, 클라이언트의 버퍼가 급격히 증가하고, 이는 시스템 리소스를 과도하게 사용하게 만들어 서버의 성능을 저하시킬 수 있다.

 

대응 방법

• 버퍼 한계값 조정: client-output-buffer-limit normal 설정을 적절히 조정하여, 클라이언트의 출력 버퍼 사이즈를 관리한다. 예를 들어, 기본값을 조금 높여 잠재적인 네트워크 지연에 대비하되, 너무 높지 않게 설정하여 메모리 소모를 방지한다. 예를 들면, 기본값인 0 0 0에서 8mb 16mb 60으로 조정할 수 있다. 이는 8MB를 초과하는 데이터가 버퍼에 쌓이고 16MB에 도달했을 때 60초 동안 지속되면 클라이언트 연결을 끊는다는 설정이다.
• 네트워크 모니터링 및 최적화: 네트워크 인프라를 모니터링하여 잠재적인 지연이나 문제를 사전에 감지하고, 필요한 경우 네트워크 설정을 최적화한다. 이는 클라이언트와 서버 간의 데이터 통신을 개선하여 출력 버퍼의 급격한 증가를 방지할 수 있다.
• 클라이언트 사이드 최적화: 클라이언트 애플리케이션에서도 비동기 처리 능력을 강화하거나 타임아웃 설정을 최적화하여, 서버로의 요청 처리가 느려지는 문제를 최소화한다. 클라이언트가 빠르게 요청을 처리하고 완료할 수 있도록 하여, 서버의 버퍼가 불필요하게 쌓이는 것을 방지한다.

이러한 조치를 통해 Redis 서버의 안정성을 유지하고, 통신 문제로 인한 장애를 효과적으로 예방할 수 있다.

 

Case 4 : 그 외 장애들

1. 클라이언트 무한 증가

문제 설명: Redis 설정에서 timeout을 설정하더라도, 특정 라이브러리가 주기적으로 신호를 보내 idle 연결로 인식되지 않는 경우가 있다. 이로 인해 서버에 불필요한 연결이 계속 유지되어 성능 저하 또는 서비스 거부(DoS) 상태를 초래할 수 있다.

대응 방법:

• 클라이언트 측 연결 관리: 클라이언트 애플리케이션에서 명시적으로 연결을 종료하도록 구현한다. 또는 필요에 따라 TCP 연결을 임의로 종료(kill)하는 스크립트를 작성하여 사용한다.
• Redis 설정 조정: timeout과 maxclient 옵션을 적절히 설정하여 무응답 상태의 클라이언트 연결을 자동으로 종료하고, 최대 허용 클라이언트 수를 관리한다.
  • 예: timeout 21600, maxclient 10000

2. AOF(Apend Only File) 쓰기 작업

문제 설명: AOF는 모든 명령을 하드 디스크에 기록하는 파일로, 데이터의 지속성을 보장하지만 너무 빈번하게 발생하면 Redis 서버의 성능에 영향을 줄 수 있다.

대응 방법:

• AOF 설정 조정: appendfsync 옵션을 조정하여 디스크 쓰기 동작의 빈도를 조절한다. 너무 빈번한 디스크 쓰기는 성능 저하를 초래할 수 있으므로, 적절한 설정을 찾는 것이 중요하다.
  • 예: appendfsync everysec
• 대량 쓰기 최적화: 대량의 데이터 쓰기 작업 시, no-appendfsync-on-rewrite 옵션을 사용하여 fsync를 하지 않도록 설정한다. 이는 쓰기 작업의 오버헤드를 줄여 성능을 개선한다.

3. 과도한 요청 처리

문제 설명: KEYS, HGETALL 등과 같은 명령어는 서버에 과도한 부하를 주어 성능 저하를 초래할 수 있다. 특히, 이러한 명령어들은 전체 데이터셋을 스캔하는 작업으로, 대규모 데이터셋을 처리할 때 매우 비효율적이다.

대응 방법:

• 명령어 사용 제한: rename-command 옵션을 사용하여 위험한 명령어의 사용을 제한한다. 이를 통해 실수나 악의적인 사용으로부터 시스템을 보호할 수 있다.
  • 예: rename-command KEYS "", rename-command FLUSHALL "", rename-command FLUSHDB ""

이러한 다양한 장애 상황에 대한 대응 방법을 이해하고 적절히 적용함으로써, Redis 환경을 더 안정적으로 운영할 수 있으며, 잠재적인 성능 문제를 예방할 수 있다.

 

Redis Server Command

Redis 서버는 다양한 관리 및 모니터링 명령어를 제공하여, 시스템의 상태를 확인하고, 데이터를 관리할 수 있도록 돕습니다. 이러한 명령어들은 시스템 운영자가 Redis 인스턴스를 보다 효율적으로 관리할 수 있게 하며, 문제가 발생했을 때 신속하게 대응할 수 있는 기능을 제공한다.

 

1. INFO

• 용도: Redis 서버의 현재 상태와 통계 정보를 보여준다.
• 사용 예: INFO 명령은 메모리 사용량, 클라이언트 연결, 키 스페이스 정보 등 다양한 통계를 제공한다.

2. SAVE

• 용도: 명령이 호출될 때의 데이터 기준으로 디스크에 RDB 파일을 즉시 생성한다.
• 사용 예: SAVE 명령은 서버가 실행 중인 동안 호출되며, 호출되는 동안 Redis 서버는 다른 작업을 수행할 수 없다.

3. BGSAVE

• 용도: RDB 파일을 백그라운드에서 생성한다.
• 사용 예: BGSAVE 명령을 사용하면, 서버의 작업을 방해받지 않으면서 데이터 스냅샷을 안전하게 저장할 수 있다.

4. BGREWRITEAOF

• 용도: AOF(Append Only File) 로그 파일을 최적화하기 위해 백그라운드에서 재작성한다.
• 사용 예: AOF 파일이 너무 커지면 BGREWRITEAOF를 사용하여 파일 크기를 줄이고 성능을 향상시킬 수 있다.

5. CONFIG REWRITE

• 용도: 실행 중인 Redis의 설정을 변경한 후, 이 변경사항을 redis.conf 파일에 저장한다.
• 사용 예: CONFIG SET 명령으로 변경된 설정을 CONFIG REWRITE를 통해 영구적으로 저장할 수 있다.

6. CLIENT KILL

• 용도: 특정 조건에 맞는 클라이언트 연결을 종료한다.
• 사용 예: 연결 수가 너무 많거나 문제를 일으키는 클라이언트를 강제로 끊을 때 사용한다.

7. MONITOR

• 용도: 서버에 실행되는 모든 명령을 실시간으로 콘솔에 출력한다.
• 사용 예: 시스템의 동작을 이해하거나 문제를 진단할 때 유용하다.

8. SLOWLOG

• 용도: 설정된 시간보다 느리게 수행된 명령의 로그를 기록한다.
• 사용 예:
  • SLOWLOG GET 명령으로 최근의 느린 명령들을 조회할 수 있다.
  • SLOWLOG MAX-LEN으로 보관할 로그의 수를 설정할 수 있다.

9. LATENCY

• 용도: Redis 명령의 지연 시간을 모니터링하고 관련 데이터를 제공한다.
• 사용 예: LATENCY MONITOR를 실행하여 시스템의 반응 시간과 성능 저하를 분석할 수 있다.

이러한 명령들은 Redis 서버의 성능을 모니터링하고, 문제를 신속하게 해결하며, 데이터 무결성을 유지하는 데 필수적이다. 서버 관리자는 이러한 도구를 활용하여 시스템의 안정성과 효율성을 높일 수 있다.

 

Redis 고급 설정과 유용한 도구 소개

Redis를 효과적으로 모니터링하고 관리하기 위한 고급 설정과 유용한 도구를 소개한다. 이 설정들과 도구들은 Redis 성능 최적화, 문제 해결, 데이터 관리에 큰 도움이 된다.

고급 설정 명령어

1. Latency Monitoring 설정
   • config set latency-monitor-threshold 3은 지연 감시 임계값을 3밀리초로 설정한다. 이 설정을 통해 3밀리 초를 초과하는 지연이 발생하면 기록된다.
   • latency doctor는 Redis 인스턴스의 지연 문제를 진단하고 가능한 원인과 해결책을 제공한다.
2. Slowlog 설정
   • config get slowlog-log-slower-than은 현재 slowlog 기록 임계값을 조회한다.
   • config set slowlog-log-slower-than 10000은 slowlog 기록 임계값을 10,000마이크로초로 설정한다. 이 설정을 통해 임계값을 초과하는 명령만 slowlog에 기록된다.
   • slowlog get 3은 최근에 기록된 slowlog 중 3개를 조회한다.
3. Debug Command
   • debug sleep 1은 Redis 서버를 1초 동안 일시 정지시킨다. 이 명령은 네트워크 지연의 영향을 시뮬레이션하는 데 사용할 수 있다.
4. Latency History
   • latency history command은 특정 명령의 지연 시간 변화를 역사적으로 확인할 수 있다. 이를 통해 시간에 따른 패턴 또는 이상을 파악할 수 있다.

추가 유용한 도구들

1. Redis 관련 UI 도구
   • RedisInsight는 Redis 데이터를 시각화하고 성능을 모니터링하며 질의를 실행할 수 있는 GUI 도구이다. AWS EC2에 설치하는 방법은 https://redis.io/resources/tools/ , https://docs.redis.com/latest/ri/installing/install-ec2/에서 확인할 수 있다.
2. Redis RDB Parser
   • Redis RDB Tools는 Redis의 RDB 파일을 분석하고 내용을 조회하며 메모리 사용량 등을 분석할 수 있는 도구이다. 사용법은 https://github.com/sripathikrishnan/redis-rdb-tools에서 확인할 수 있다.

이러한 고급 설정과 도구들을 활용하면 Redis 인스턴스의 운영 효율성을 높이고 잠재적인 문제를 신속하게 해결하며 성능을 지속적으로 개선할 수 있다. Redis 운영에 있어서 이러한 도구와 설정들은 관리자에게 매우 중요하다.