목록2026/03/10 (6)
ssuperjun 님의 블로그
[장애 이력 자동 작성 도구12] Redis 스크립트 추가 고도화
1. Failed with result 의 다른 요인현재 상황싱글 구성에서 "Failed with result" 키워드는 감지되는데, 'oom-kill', 'core-dump', 'signal' 외의 다른 요인으로 인해 "Failed with result"가 로그에 나타나는 상황은 전부 '미확인'처리 했음 하지만 systemd의 Failed with result 뒤에 올 수 있는 값은 여러가지임값의미oom-killOOM Killer가 프로세스 종료core-dumpSegfault 등으로 코어 덤프 발생signal외부 시그널로 종료 (SIGTERM 제외)exit-code프로세스가 비정상 종료 코드로 종료timeoutsystemd의 TimeoutStartSec/TimeoutStopSec 초과watchdogsy..
[장애 이력 자동 작성 도구11] Redis 복제 구조 장애 상황 연출 및 로그 수집 코드 구현
목표cb801에 있는 기존의 redis-server를 마스터로 하고(불가능하다면 재설치), ca801 서버(cb801과는 다른 서버)에 슬레이브를 설치 1. cb801의 bind 설정 변경=> 현재 cb801의 redis-server가 127.0.0.1:6379로 바인딩되어 있는데, ca801에서 접속하려면 cb801의 bind 설정을 0.0.0.0 또는 10.150.254.155로 변경해야 함# cb801에서 - redis.conf bind 설정 확인sudo grep "^bind" /etc/redis/redis.conf 2. ca801에서 cb801과 통신 - IP로 직접 연결 확인# ca801에서telnet cb801주소 6379=> 네트워크 연결 확인됨 3. protected mode와 인증 문제 ..
[장애 이력 자동 작성 도구10] Redis Sentinel 구조 장애 로그 수집 코드 구현
시간 관계 상 Redis Sentinel 설치 및 구성 부분은 생략(서버 최소 3개 필요, ACL 등록 필요)redis_의도된_shutdown.log 원본 로그 파일을 파싱하는 형태로 구현 복제 구성 환경과 관련된 장애가 발생하면, 원인을 파악하기 위해 조사할 부분 싱글 구성에서처럼 마스터의 1. OOM killed(메모리 full), 2. 디스크 full 및 병목, 3. CPU 병목, 4. Too many connections, 5. 내부 로직 segfault 등을 조사5가지 조사를 동일하게 진행해야 하므로, 5가지 장애 연출 및 스크립트 작성이 모두 완료된 후에 Sentinel 및 복제 구성 장애 상황 대응 진행(실제로는 OOM, Segfault만 진행 완료)'통신 등 외부 요인 장애'는 이 프로젝트..
[장애 이력 자동 작성 도구9] Redis Segfault 장애 상황 연출 및 로그 수집 코드 구현
Valkey 기준 장애 연출 - deprecated 참고valkey는 systemd로 관리되지 않고 irteam 계정으로 직접 실행 중이므로, journalctl이 아닌 valkey 로그 파일(/home1/irteam/valkey_10379/valkey_10379.log)에 기록될 가능성이 높음 Too many connections 연출 시 Valkey 변경한 항목 되돌리기/home1/irteam/valkey_10379/bin/redis-cli -p 10379 -a 비밀번호 redisconfig set maxclients 10000# 확인/home1/irteam/valkey_10379/bin/redis-cli -p 10379 -a 비밀번호 redisconfig get maxclients장애 연출 계획방법..
[장애 이력 자동 작성 도구8] Redis Too many connections(maxclients 초과) 장애 상황 연출 및 deprecated 이유 & CPU 병목 스킵 이유
현재 구현 상황항목상태OOM Kill 수집/타임라인/두레이 등록✅ 완료디스크 full❌ 스킵CPU 병목❌ 스킵Too many connections🔲 미시작Segfault🔲 미시작Sentinel 구조🔲 미시작마스터-슬레이브 복제 구조🔲 미시작 CPU 병목 스킵 이유keys *같은 O(N) 명령어를 대량 데이터에 실행하면 CPU 병목이 발생하는데, 대부분은 Redis의 응답 지연만 발생하고 프로세스는 그대로 살아있어 장애라고 보기 어려울 수 있음CPU 병목으로 인해 Redis를 죽이는 장애 상황은 연출하기 힘듦keys *같은 명령어가 CPU 병목의 원인이 됐다는 사실은 journalctl(systemd 레벨)에 기록되지 않고, Redis 내부에서 Redis가 살아있을 때만 접근 가능하기 때문에 Red..
[장애 이력 자동 작성 도구7] Redis 디스크 full 장애 상황 연출 및 deprecated 이유
두괄식 결론디스크 full 장애상황 연출 및 로그 수집은 진행하지 않기로 결정 이유회사에선 Redis를 데이터 저장 용도로 사용하지 않는다고 했음애초에 디스크 full이 발생하지 않을텐데 이 부분이 구현은 의미가 없다고 판단추후 시간이 남으면 고도화해볼 수 있음장애 발생 직후 1차적으로 스크립트를 실행(원인 분석 및 휘발성 상태 정보 보존 목적) -> 1차 실행 때 수집한 정보를 사후 2차 실행에서 재활용하기=> 이 고도화 부분에서 디스크 full, cpu 병목, too many connections 정보들도 수집할 수 있음고도화 시 1차 정보 저장을 어떻게 할지, 2차 실행 때 어떻게 재활용할지 고민 필요디스크 full 장애 상황 연출하기 방법1: dd로 더미 파일을 만들어 실제 디스크를 모두 채우는 ..