Redis의 CPU 한 코어가 바쁜데 서버에는 여러 스레드가 보입니다. 명령 실행·네트워크 I/O·백그라운드 작업을 어떻게 구분하고 병목을 판단하나요?

Redis가 싱글 스레드라는 말은 보통 클라이언트 명령을 주 실행 경로에서 한 번에 하나씩 처리한다는 뜻이지, 프로세스의 모든 작업이 하나의 OS 스레드에서만 실행된다는 뜻은 아닙니다. 네트워크 I/O 스레드, lazy freeing, RDB·AOF 백그라운드 저장과 같은 보조 작업의 범위는 Redis 버전·설정에 따라 다릅니다. 따라서 여러 스레드가 보인다는 사실만으로 명령 실행이 병렬화됐다고도, 한 코어가 바쁘다는 사실만으로 모든 병목이 명령이라고도 말하지 않겠습니다.

주 실행 경로의 긴 작업을 찾습니다

큰 컬렉션 순회, 큰 키 삭제, 긴 Lua, 비용 큰 명령은 주 실행 경로를 오래 차지해 다른 클라이언트의 짧은 GET까지 같은 큐에서 기다리게 할 수 있습니다. CPU 평균이 낮아도 순간적으로 긴 명령이 p99를 튀게 만들 수 있습니다. slow log·latency monitor·명령별 호출 수와 실행 시간·큰 키 크기·클라이언트 네트워크 대기를 함께 측정하겠습니다. 연결 수나 워커 스레드를 늘리는 것은 한 명령이 주 실행 경로를 점유한 시간을 줄이지 못합니다.

I/O 스레드가 읽기·쓰기 버퍼 처리 비용을 줄일 수 있어도 자료구조 조회·Lua 분기·키 변경을 여러 코어에서 동시에 실행해 서로 끼어들게 하는 것과는 다릅니다. RDB fork·AOF rewrite의 디스크·copy-on-write 비용, lazy free의 해제 대기, 복제·클라이언트 출력 버퍼를 주 명령 CPU와 분리해 보겠습니다. Redis 버전별 threaded I/O가 어떤 명령 구간을 담당하는지는 공식 설정과 실측으로 확인합니다.

원자성과 자원 한도를 함께 맞춥니다

한 명령이 중간에 다른 명령에 끼어들지 않는다는 것은 여러 명령의 GET-판단-SET 전체가 자동 원자적이라는 뜻이 아닙니다. 애플리케이션에서 GET 후 판단하고 SET하면 사이에 다른 클라이언트가 바꿀 수 있습니다. 조건부 명령, WATCH+MULTI/EXEC, 짧은 Lua 중 요구에 맞는 것을 선택하되 긴 스크립트가 전체 지연을 늘리지 않게 실행 시간을 제한합니다.

해법은 스레드 수 증가보다 큰 키 분할, 자료구조·명령 변경, 작업 배치·SCAN, lazy freeing 검토, 핫 키 분산에서 찾겠습니다. 단일 Redis 노드의 주 실행 병목이면 Cluster 샤딩이 도움될 수 있지만 다중 키 슬롯 제약과 핫 슬롯을 함께 설계해야 합니다. 검증은 짧은 GET과 큰 명령을 섞어 명령 지연·네트워크 지연·백그라운드 I/O·CPU 코어별 사용률을 비교하고, 스크립트 중단·큰 삭제·fork 피크에서 p99를 확인하는 방식입니다.

CPU 프로파일 하나만으로 주 실행 병목을 판정하지 않겠습니다. 명령별 실행 시간과 호출 빈도를 곱한 총량, 네트워크 읽기·쓰기 대기, fork·rewrite의 copy-on-write, 클라이언트 출력 버퍼를 각각 분리합니다. 큰 키를 쪼개면 명령 시간은 줄 수 있지만 여러 키의 원자성·슬롯 배치·네트워크 왕복이 늘 수 있습니다. 변경 뒤 짧은 요청의 p99와 긴 요청의 총 처리량을 함께 측정해 병목이 이동하지 않았는지 확인하겠습니다.