지난 글에서는 Redash와 Metabase라는 두 가지 BI 툴의 특징과 장단점, 그리고 어떤 환경에서 어떤 툴을 선택하면 좋을지에 대해 이야기해봤습니다. 이번 글에서는 이 두 툴을 실제로 운영하면서 발생했던 주요한 문제들과, 이를 해결하거나 예방하기 위한 관리 방법을 좀 더 실무적인 관점에서 살펴보려고 합니다.
1. 용량 관리의 필요성 (Redash 사례)
대부분의 대시보드나 BI 도구를 구축할 때 초기 설정값(default)을 그대로 사용하거나 특별히 용량 관리를 하지 않고 시작하는 경우가 많습니다. 데이터가 많지 않은 초기에는 큰 문제가 없지만, 시간이 지나면서 데이터가 쌓이고 결국 디스크 용량이 한계치에 도달하는 문제가 발생할 수 있습니다.
실제로 Redash를 운영 중인 EC2 인스턴스에서도 이 문제가 발생했습니다. 특히 Redash는 쿼리의 결과를 자체적으로 저장하기 때문에 운영팀과 개발팀 모두가 오래된 쿼리나 사용 빈도가 낮은 대시보드를 제대로 정리하지 않고 무분별하게 생성하는 경우가 많았습니다. 결국 디스크 용량이 가득 차면서 시스템이 멈추는 상황에 이르렀습니다.
해결 방법
•
우선 급한 문제를 해결하기 위해 디스크 용량을 확장했습니다. 하지만 이는 근본적인 해결책이 아닙니다.
•
장기적으로는 다음과 같은 관리 방안을 적용할 필요가 있습니다.
◦
사용 빈도가 낮거나 오래된 쿼리를 정기적으로 삭제하거나 아카이빙합니다.
◦
실제 사용 중인 대시보드와 쿼리들의 용량과 사용 주기를 파악하여 미리 관리합니다.
◦
AWS CloudWatch와 같은 모니터링 도구를 사용해 디스크 용량과 메모리 사용률을 지속적으로 모니터링하고, 문제가 발생하기 전에 알림을 받도록 설정하는 것이 좋습니다.
실제로 CloudWatch를 통해 용량과 메모리를 상시 모니터링하면, 이러한 문제를 사전에 예방하고 빠르게 대응할 수 있습니다.
추가 고려 사항
특히나 용량에 대한 이슈는 어느 환경에서나 발생할 수 있습니다. 특히 Docker-Compose나 Helm을 기반으로 서비스를 바로 사용하려고 할 때, 이런 이슈가 많이 발생합니다. 디폴트 값을 기반으로 사용하기 때문에 DB 설정이나 용량 등 많은 옵션이 있지만 처음 사용할 때는 대부분 프로토타입처럼 한번 써보고 괜찮은지 확인해보고, 실제로 괜찮다보니 바로 이어서 사용하는 경우가 많습니다.
물론 이런 경우에도 나중에 수정을 해서 이슈를 해결하고 원하는 사용성에 맞게 수정할 수 있지만, AWS EC2 기반이라면 EBS 용량을 올려서 디스크 용량을 확보 한 후에, 문제가 생긴 파티션의 용량을 확장해서 사용해야 한다거나, k8s 환경이라면 PVC와 매핑된 PV를 찾아서 설정을 바꿔서 용량을 확보한다거나의 액션이 필요합니다.
2. 작업 큐(Worker Queue) 관리 이슈 (Redash 사례)
Redash를 사용하면서 자주 겪었던 또 하나의 문제가 쿼리가 처리되지 않고 큐에 계속 쌓이는 현상입니다. 특정 쿼리가 DB에서 오랜 시간 실행되며 다른 쿼리의 실행을 막아버리는 일이 실제로 발생했었습니다.
근본적인 원인은 Redash의 디폴트 워커(worker)의 수가 작았던 것이었지만, 당시에는 이를 알지 못했기 때문에 DB에서 실행 중인 프로세스를 직접 찾아서 kill 하는 방식으로 급하게 대응했습니다. 이로 인해 Redash 전체가 멈추는 현상이 발생했었습니다.
해결 방법 및 예방 조치
•
근본적인 해결책으로는 워커의 수를 늘리거나 병렬 처리 능력을 강화하는 방법이 필요합니다.
•
또한 다음과 같은 관리 방안을 추가로 적용하는 것이 좋습니다.
◦
쿼리 실행 시간을 적절히 제한하거나 timeout을 설정하여 지나치게 오래 걸리는 쿼리로 인해 전체 시스템이 멈추는 상황을 방지합니다.
◦
시스템의 작업 큐 상태를 지속적으로 모니터링하고, 병목 현상이 발생하면 즉시 알림을 받을 수 있도록 설정합니다.
결국 이러한 관리가 체계적으로 이루어진다면 안정적인 BI 환경을 구축하고 운영할 수 있을 것입니다.
3. Redash와 Metabase의 Query-Time Out 차이
두 툴은 기능적으로 유사하지만, 실무에서 겪게 되는 구체적인 차이가 존재합니다. 대표적인 예로는 쿼리 실행 시간 제한이 있습니다.
쿼리 실행 시간 제한
•
Redash의 경우 쿼리 실행 시간이 길더라도 끝까지 기다려 주기 때문에, 복잡하고 긴 쿼리를 실행하는 데 유리합니다.
•
Metabase는 기본적으로 5분 이상 걸리는 쿼리는 자동으로 종료되므로, 데이터 모델링을 잘하거나 구조화된 데이터를 기반으로 빠른 쿼리를 작성하는 것이 중요합니다.
마무리
실제로 Redash와 Metabase를 운영하면서 겪은 문제들을 돌아보면, 처음부터 체계적으로 용량을 관리하고, 작업 큐를 안정적으로 구성하며, 툴의 특성을 명확히 이해하고 선택하는 것이 중요하다는 점을 느끼게 됩니다. 단순히 이런 툴을 쓰면 해결되겠지로 시작할 수는 있겠지만, 각 툴마다 어떤 방식으로 구현이 되어있고, 어떻게 동작하는지 이해하는 것이 실제 운영하면서 다양한 이슈를 해결하는데 많은 도움이 됩니다.