Amazon Redshift

운영 데이터베이스에 BI 질의를 같이 태우면 사용자 요청과 집계 쿼리가 서로를 방해합니다. 분석용 데이터가 따로 정리돼 있지 않으면 리포트가 늘수록 운영 시스템이 먼저 흔들립니다.

운영 DB 위에 보고서를 얹는 방식은 규모가 커질수록 실제로 무너지기 시작했습니다. OLTP(Online Transaction Processing, 사용자 요청을 실시간으로 처리하는 트랜잭션 중심 데이터베이스) 위에서 수억 행 집계 쿼리를 돌리면 수십 분씩 걸리거나, 쿼리 자체가 운영 DB 성능에 영향을 줘 실사용자 응답이 느려지는 일이 반복됐습니다. 온프레미스 데이터 웨어하우스를 도입하면 분석은 분리할 수 있었지만, 초기 하드웨어 구매와 용량 산정에 수개월과 큰 비용이 들었습니다. 트래픽이 예상보다 적으면 장비가 놀고, 많으면 증설에 또 시간이 걸렸습니다. 클라우드 기반 웨어하우스는 필요한 만큼 노드를 늘리고 줄이면서 종량제로 비용을 맞출 수 있어, 분석 전용 인프라의 진입 장벽을 크게 낮췄습니다.

Redshift는 데이터를 행이 아닌 컬럼(열) 단위로 저장합니다. 분석 쿼리는 보통 전체 컬럼 중 일부만 참조하기 때문에, 컬럼형 저장 방식은 필요한 컬럼만 디스크에서 읽어 I/O를 크게 줄입니다. 여기에 MPP(Massively Parallel Processing, 여러 노드가 각자 맡은 데이터 조각을 동시에 처리하는 구조) 아키텍처가 결합됩니다. 리더 노드가 쿼리를 받아 실행 계획을 세우면, 컴퓨트 노드들이 자기 슬라이스에 저장된 데이터를 병렬로 집계해 결과를 합칩니다. 노드를 추가하면 처리량이 그만큼 늘어나는 구조입니다. 데이터는 보통 S3와 Glue를 거쳐 적재되고, BI(Business Intelligence, 데이터를 시각화하고 리포트로 만드는 도구) 도구는 클러스터에 연결해 반복 리포트와 대시보드를 만듭니다.

Redshift와 Athena는 둘 다 SQL 분석이 가능하지만 적재 전략이 다릅니다. Redshift는 데이터를 웨어하우스에 적재해 반복 분석하는 데 강하고, Athena는 S3 파일을 바로 읽는 데 강합니다. 반복 대시보드와 대규모 집계를 위해 데이터를 정리해 적재할 수 있으면 Redshift를 보고, 적재 없이 파일을 바로 탐색적으로 조회하려면 Athena를 보면 됩니다.

마케팅팀이 매주 캠페인별 전환율과 비용 대비 효과를 자동으로 집계해 리포트를 생성하거나, 데이터 분석팀이 여러 소스에서 모은 데이터를 한데 적재해 대시보드를 운영하는 데 적합합니다. 정기 리포트, 대규모 집계, 부서별 데이터 마트처럼 데이터를 정리해 반복적으로 돌려야 하는 분석에 강합니다. 임시 조사성 쿼리만 간헐적으로 실행하는 경우에는 과합니다.