Redash 쿼리 큐 쌓이는 이슈

제보 받았던 이슈

redash는 데이터 소스를 연결해 쿼리를 날려 결과를 얻고 시각화도 할 수 있는 도구이다. 현재 redash는 aws ec2에 올려서 사용하고 있다. 슬랙 채널에 쿼리결과가 안나온다는 제보를 받고 redash 상태를 확인했다.

왼쪽 하단의 system status에 들어가면 admin 페이지가 나오고 여기서 시스템과 queue의 상태를 볼 수 있다. 

RQ status 라는 탭으로 들어가면 Queued Jobs 에서 큐에 쌓여있는 쿼리가 몇개 인지 볼 수 있다. 각 사용자들이 쿼리 결과를 보기 위해 쿼리를 실행시키면 큐에 쌓이게 되고 순차적으로 처리가 된다. 제보를 받은 그때 당시에는 몇십개의 큐가 결과를 기다리며 쌓여 있는 상태였다. 어디선가 부하가 걸려서 실행이 막힌 상태인 것 같았다.

Redash Issue 확인을 위한 Redash 구조

1. 웹 서버 (Server): 웹 서버는 Redash의 메인 서비스로, 웹 인터페이스를 제공하고 HTTP 요청을 처리합니다. 웹 서버는 사용자 인터페이스(UI), API 엔드포인트 등을 관리.
2. 작업자 (Worker): 작업자는 데이터베이스에서 쿼리를 실행하고 결과를 처리하는 역할로 크게 두가지로 나뉨. 
   • scheduled_worker: 주기적으로 실행되는 작업들을 수행. ex) 데이터 소스로부터 데이터를 주기적으로 불러오는 작업
   • adhoc_worker: ad-hoc성 쿼리 실행을 처리. 사용자가 직접 작성하고 실행하는 쿼리를 처리하는 역할.
3. 스케줄러 (Scheduler): 스케줄러는 정기적으로 실행해야 하는 작업을 관리. 스케줄러는 특정 시간에 실행해야 할 작업을 예약하고, 해당 시간이 되면 작업을 Worker에게 전달한다. 
4. Redis: Redis는 메모리 기반의 데이터베이스로, Redash에서는 메시지 큐와 캐시로 사용된다. Worker와 Scheduler 사이에서 메시지를 전달하는 데 사용되며, 자주 사용되는 데이터를 임시 저장하는 데도 사용.
5. PostgreSQL: PostgreSQL은 Redash의 메인 데이터베이스로, 사용자 정보, 대시보드 설정, 쿼리 결과 등 Redash의 다양한 데이터를 저장한다. 

원인 파악

대부분 리대시가 올라가있는 ec2 인스턴스를 재시작하면 리대시에 걸려있던 큐들이 사라지면서 리소스가 원상태로 돌아오고 부하도 풀리게 된다. 하지만 이번엔 인스턴스 재시작을 해도 큐가 사라지지 않았다. 결론적으로 말하면 리대시가 아닌 production-read DB의 문제 였다. read DB가 이번주 내내 지속적으로 지연되었는데 원인이 되는 쿼리가 리대시에서 누군가가 만들어 실행시킨 쿼리였다. 처음에 read DB 지연의 원인이 되는 쿼리를 리대시에서 찾아내 아카이브 시켜서 read DB도 원상복귀 될 것이라고 생각했다. 하지만 그렇지 않고 여전히 read DB에 살아서 실행이 되고 있었다. 문제가 된 쿼리는 limit과 기간 설정이 안되어 있어서 연산이 엄청나게 오래 걸리는 쿼리로 며칠때 실행이 되고 있던 것이다.. 이 쿼리가 read DB의 리소스를 다 잡아먹고 있어서 read DB로 날린 다른 쿼리가 실행되지 못하고 계속 큐에 쌓이고만 있었다. 그리고 앞선 쿼리들이 큐에서 나가지 못하니 뒤에 다른 DB로 날렸던 쿼리들도 Queued Jobs에 쌓인 상태로 막혀서 실행이 멈춘 것처럼 되었다. 

해결

read DB는 MYSQL을 사용하고 있다. MYSQL은 쿼리를 실행하는 process를 확인하고 직접 kill 해서 종료 시킬 수 있다. 아래와 같이 process id 를 찾아내 문제가 되는 process를 kill 하니 read DB cpu가 정상화 되면서 이후 쿼리 모두 실행되어 문제가 해결되었다. 

# 현재 process 확인
SELECT *
FROM information_schema.processlist
where info is not null
and user = 'userName'
ORDER BY id;

# process kill

kill [process_id]