[장애 이력 자동 작성 도구7] Redis 디스크 full 장애 상황 연출 및 deprecated 이유

두괄식 결론

디스크 full 장애상황 연출 및 로그 수집은 진행하지 않기로 결정

 

이유

• 회사에선 Redis를 데이터 저장 용도로 사용하지 않는다고 했음
• 애초에 디스크 full이 발생하지 않을텐데 이 부분이 구현은 의미가 없다고 판단

추후 시간이 남으면 고도화해볼 수 있음

• 장애 발생 직후 1차적으로 스크립트를 실행(원인 분석 및 휘발성 상태 정보 보존 목적) -> 1차 실행 때 수집한 정보를 사후 2차 실행에서 재활용하기
• => 이 고도화 부분에서 디스크 full, cpu 병목, too many connections 정보들도 수집할 수 있음
• 고도화 시 1차 정보 저장을 어떻게 할지, 2차 실행 때 어떻게 재활용할지 고민 필요

---

디스크 full 장애 상황 연출하기

 

• 방법1: dd로 더미 파일을 만들어 실제 디스크를 모두 채우는 방식
• 방법2: Redis dir 경로를 용량이 작은 tmpfs로 바꾸는 방식

=> 방법2 선정

이유: 테스트 서버이긴 하지만, 실제 디스크를 건드리지 않고 장애를 연출하기 위함. 방법1을 사용해 실제 장애와 동일한 상황을 연출하고 싶어도 55GB를 다 채워야 함

 

참고

tmpfs = 임시 파일 시스템(RAM 기반 데이터 저장 장소)

dd = "data duplicator"의 약자로, 파일이나 디바이스 간 데이터를 블록 단위로 복사하는 리눅스 명령어

 

cb801 디스크 여유 공간 확인 및 Redis 데이터 디렉토리 확인

 

Redis 설정에서 save 주기와 AOF 활성화 여부를 확인

=> AOF는 비활성화(appendonly no)이고 RDB만 사용 중

 

현재 Redis에 데이터가 얼마나 있는지도 확인(사진 생략)

 

Redis 포트와 현재 save 설정도 확인

port 6479
save 설정 없음 = RDB 자동 저장이 비활성화된 상태
save 설정이 없으면 Redis가 실제로 디스크에 쓰는 작업이 없는 셈
save 설정을 임시로 추가해서 장애를 연출해야 함

 

참고

AOF(Append Only File) vs. RDB(스냅샷 확장자 이름)

출처: [NHN FORWARD 2021] Redis 야무지게 사용하기

---

tmpfs 방식으로 RDB 저장 실패 장애 연출 계획

1. 작은 tmpfs(예: 10MB)를 /mnt/redis-test에 마운트

2. Redis dir을 /mnt/redis-test로 변경

3. Redis에 데이터를 넣고 BGSAVE 강제 실행

4. tmpfs를 가득 채워서 → RDB 저장 실패 유발

5. 로그 확인 후 복구

---

1단계: tmpfs 준비 및 Redis dir 변경

# 10MB tmpfs 마운트

sudo mkdir -p /mnt/redis-test

sudo mount -t tmpfs -o size=10m tmpfs /mnt/redis-test

sudo chown redis:redis /mnt/redis-test

 

# Redis dir을 tmpfs로 변경

redis-cli -p 6379 config set dir /mnt/redis-test

=> 오류 발생(dir가 보호 설정됨)해 redis.conf를 직접 수정하고 재시작 필요

 

# redis.conf에 dir 추가

sudo sed -i 's|^dir /var/lib/redis|dir /mnt/redis-test|' /etc/redis/redis.conf

sudo grep "^dir" /etc/redis/redis.conf  # 확인

 

# Redis 재시작

sudo systemctl restart redis-server

redis-cli -p 6379 config get dir  # 확인

---

2단계: 데이터 투입 후 BGSAVE 성공 확인

# 데이터 투입 (5MB 수준)

# lua 스크립트로 데이터 투입

redis-cli -p 6379 eval "for i=1,50000 do redis.call('set', 'key:'..i, string.rep('x', 100)) end" 0

 

# BGSAVE 실행 → 성공해야 함

redis-cli -p 6379 bgsave

sleep 2

redis-cli -p 6379 info persistence | grep rdb_last_bgsave_status

 

=> rdb_last_bgsave_status:err 장애가 이미 발생함

 

# Redis 로그 확인

sudo tail -20 /var/log/redis/redis-server.log

 

문제

기존 RDB 저장 장소인 /var/lib/redis를 /mnt/redis-test로 바꾸는 과정에서 /var/lib/redis에는 있던 dump.rdb가 /mnt/redis-test에 존재하지 않아 tmpfs를 dd로 채우기도 전에 장애 발생

 

tmpfs 권한을 수정하고 정상화시킨 뒤, 제대로 된 디스크 full 장애를 연출 시도

# tmpfs 권한 확인

ls -la /mnt/redis-test

 

# redis 소유권으로 수정

sudo chown redis:redis /mnt/redis-test

sudo chmod 750 /mnt/redis-test

 

# Redis 재시작 후 확인

sudo systemctl restart redis-server

sleep 2

redis-cli -p 6379 info persistence | grep rdb_last_bgsave_status

 

=> Redis 재시작 시 터미널이 멈춰버리는 상황에서 문제를 해결하지 않고, 디스크 full 장애 상황 로그 수집이 무가치하다고 판단. 폐기

더 조사한 내용

SAVE vs. BGSAVE

출처: https://inpa.tistory.com/entry/REDIS-📚-데이터-영구-저장하는-방법-데이터의-영속성

RDB 저장 시

SAVE 옵션: 순간적으로 redis의 동작을 정지시키고 그 snapshot를 디스크에 저장(blocking 방식). redis.conf 파일에서 SAVE 옵션을 설정하면 자동으로 RDB에 저장됨

BGSAVE 옵션: 백그라운드 SAVE 라는 의미로 별도의 자식 프로세스를 띄운 후, 명령어 수행 당시의 snapshot을 disk에 저장하고, redis는 동작을 멈추지 않게 됨(non-blocking 방식). cli 창에서 수동으로 RDB 파일 저장

SAVE 동작순서
1) Main process가 데이터를 새 RDB temp 파일에 쓴다.
2) 쓰기가 끝나면 기존 파일을 지우고, 새 파일로 교체한다.

BGSAVE 동작 순서
1) Child process를 fork() 한다.
2) Child process는 데이터를 새 RDB temp 파일에 쓴다.
3) 쓰기가 끝나면 기존 파일을 지우고, 이름을 변경한다.

---

여기서부터 deprecated(진행하지 않음)

 

3단계: tmpfs 가득 채우기 → 장애 유발

# tmpfs를 dd로 채움

sudo dd if=/dev/zero of=/mnt/redis-test/filler bs=1M count=9

 

# 디스크 full 확인

df -h /mnt/redis-test

 

# BGSAVE 강제 실행 → 실패해야 함

redis-cli -p 6379 bgsave

sleep 2

redis-cli -p 6379 info persistence | grep rdb_last_bgsave_status

 

# Redis 로그 확인

sudo tail -20 /var/log/redis/redis-server.log

 

4단계: 복구

sudo rm /mnt/redis-test/filler redis-cli -p 6379 config set dir /var/lib/redis sudo umount /mnt/redis-test