AWS EC2 + RDS 위에 Redash 직접 구축하기
EAT-SSU 팀에서 서비스 운영 데이터를 시각화하기 위해 Redash를 도입했다.
Managed SaaS 대신 AWS EC2 위에 직접 설치하는 방식을 선택했고, 그 과정에서 인프라 전반을 직접 만지게 되었다.
공식 문서를 그대로 따라가면 금방 끝날 것 같았지만,
실제로는 디스크 용량, 메모리, 보안그룹, VPC 라우팅까지 연쇄적으로 문제가 발생했다.
이 글에서는
- EC2 + RDS 환경에서 Redash를 처음부터 끝까지 구축하는 과정
- 실제로 겪었던 트러블슈팅과 그로부터 얻은 교훈
을 정리한다.
1. Redash를 EC2에 직접 올린 이유
Redash는 데이터 분석과 대시보드를 위한 오픈소스 도구다.
팀에서는 다음 이유로 EC2 직접 설치 방식을 선택했다.
- 비용 통제 (사용량이 크지 않음)
- Docker 기반으로 비교적 단순한 설치
- 인프라 구조를 직접 이해하고 운영해보기 위함
다만, “생각보다 쉽다”는 기대와 달리 실제 구축 과정에서는 꽤 많은 인프라 요소를 고려해야 했다.
2. 아키텍처 개요
구성은 단순하다.
- EC2: Redash 서버 (Docker 컨테이너)
- RDS: 서비스 운영 DB (MySQL 또는 PostgreSQL)
- EC2와 RDS는 같은 VPC에 배치
- 보안그룹은 SG → SG 방식으로 연결
트래픽 흐름
- 브라우저 → EC2 퍼블릭 IP:80 → Nginx → Redash Server(5000)
- Redash Server → RDS:3306 (또는 5432)
3. EC2 인스턴스 준비
3-1. 인스턴스 타입
Redash는 생각보다 리소스를 많이 사용한다.
- 최소 권장:
t3.small(2vCPU, 2GB RAM) - 안정적:
t3.medium(2vCPU, 4GB RAM)
t2.micro(1GB)로도 시도해봤지만,
메모리·디스크 모두 부족해 설치 단계에서 실패했다.
3-2. 디스크 용량
Root EBS 볼륨은 최소 20GB, 가능하면 30GB 이상을 권장한다.
- Docker 이미지 레이어
- Postgres, Redis 데이터
- Python 패키지 설치 과정에서의 임시 공간
8GB 환경에서는 설치 중 no space left on device 오류가 거의 확정적으로 발생한다.
3-3. 네트워크
- EC2는 퍼블릭 서브넷에 생성
- Route Table에
0.0.0.0/0 → Internet Gateway
라우트 존재 확인 - 퍼블릭 IPv4 또는 Elastic IP 할당 필수
4. 보안그룹 설정
Redash용 EC2 보안그룹 예시 (redash-group)
Inbound
- 22/TCP → 내 IP (SSH)
- 80/TCP → 내 IP 또는 0.0.0.0/0 (웹 UI)
- 5000/TCP → 내 IP (디버깅용, 선택)
Outbound
- All traffic → 0.0.0.0/0
중요한 점은 DB 포트(3306/5432)는 EC2 인바운드에 열 필요가 없다는 것이다.
DB 포트는 RDS 보안그룹에서 제어해야 한다.
5. 스왑 메모리 설정
메모리가 2GB 이하라면 스왑을 설정해 두는 것이 안전하다.
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h6. Docker 설치
sudo apt update
sudo apt install -y docker.io docker-compose-plugin
sudo systemctl enable docker
sudo systemctl start docker7. Redash 설치
공식 setup 스크립트를 그대로 사용했다.
git clone https://github.com/getredash/setup.git
cd setup
sudo ./setup.sh설치 후 다음 컨테이너들이 떠 있어야 한다.
- redash-server
- redash-worker
- redash-scheduler
- redash-nginx
- redash-postgres
- redash-redis
EC2 내부 테스트:
curl http://localhost
curl http://localhost:50008. 브라우저 접속
http://<EC2 퍼블릭 IP>(Nginx 경유)- 또는
http://<EC2 퍼블릭 IP>:5000
관리자 계정 생성 화면이 나오면 정상이다.
9. RDS 보안그룹 설정
핵심은 IP가 아니라 보안그룹을 Source로 지정하는 것이다.
RDS 보안그룹 Inbound:
- 3306 (또는 5432)
- Source:
redash-group
이렇게 하면 Redash EC2만 DB에 접근할 수 있다.
10. 트러블슈팅 회고
1) 디스크 부족 (no space left on device)
t2.micro + 8GB 환경에서 Docker 이미지 레이어 추출 중 실패.
원인
- Docker + DB + 라이브러리 합쳐 8GB 초과
해결
- EBS 30GB 확장
- 파일시스템 확장 후 재설치
교훈
- 디스크는 넉넉하게 잡는 게 결국 더 싸다
2) 컨테이너는 떠 있는데 접속이 안 됨
docker ps정상- 브라우저 접속 불가
점검 순서
- EC2 내부
curl localhost - 보안그룹 포트
- 서브넷 Route Table
- 퍼블릭 IP 여부
교훈
- 애플리케이션 문제인지, 네트워크 문제인지 계층별로 분리해서 봐야 한다
3) DB 포트를 EC2 SG에 열어둔 실수
- DB 연결 안 된다고 EC2 SG에 3306 개방
문제
- DB는 EC2가 아니라 RDS가 “받는 쪽”
정답
- RDS SG Inbound에
3306 → Source: redash-group
교훈
- 보안그룹은 “누가 누구에게 접근하는가”를 기준으로 봐야 한다
11. 마무리
Redash를 EC2 위에 직접 올리는 작업은 단순 설치를 넘어
인프라 전반을 이해해야 가능한 작업이었다.
이번 경험으로 정리된 핵심은 다음이다.
- 리소스는 넉넉하게 잡는 것이 결국 효율적이다
- 보안그룹은 SG → SG 구조로 설계한다
- 문제 발생 시 컨테이너 → EC2 내부 → 보안그룹 → VPC/라우팅 순서로 점검한다
이 과정을 한 번 겪고 나니,
이후 다른 사내 도구(Grafana, Metabase 등)를 올릴 때도 훨씬 수월해졌다
