AWS Redshift 도입 배경과 간단한 설명

도입 배경

우리 회사에서는 주된 고객사인 쇼핑몰 데이터를 다루는데 그 수가 만 개(누적)를 넘어간다. 그런 이유로 쇼핑몰 별로 독립된 DB 를 가지고 이를 여러 개의 존으로 나눠서 관리하고 있다. DB 를 분리함에서 오는 관리의 장점이 있는데, 다수 고객사의 통계 데이터 조회 시 약점이 드러났다. 전체 혹은 다수 고객사들의 합산 통계를 내는 aggregate 류 연산 시에는 여러 개의 DB 를 순회하며 필요한 데이터를 조회하는 비효율이 있었다.

뉴스기사 - 크리마, 경쟁사 인기 상품 분석 ‘크리마 인사이트’ 런칭

‘크리마 인사이트’ 는 일종의 대시보드로, 개발 시 경쟁 그룹과 자사 통계를 비교하는 기능을 제공하는 요구사항이 있었다. 이 때, 내가 속한 데이터팀에서는 컬럼형 DB 인 Redshift 를 도입하기로 결정했다. 대시보드는 OLAP(Online Analytical Processing, 분석/리포트 처리)가 100% 라서 (대시보드를 통한) INSERT/UPDATE 가 전혀 없기 때문에 적합하다고 판단했다.

데이터 파이프라인

1. 다수의 쇼핑몰 DB 데이터를 정기적으로 AWS S3 로 gzip 파일 업로드
2. S3 -> Redshift 데이터 upsert (Airflow 로 배치 스케쥴 관리)

Redshift 가 주는 장점

1. Aggregation 에 최적화
   • 고객사 DB 로 사용하는 Maria DB 는 row-based DBMS 인데, 그에 반해 columnar(컬럼형) DBMS
   • 컬럼형으로 저장된 DB 조회 시 필요한 컬럼 데이터만을 조회함
2. 같은 컬럼에는 같은 형식/유사한 값이 많기 때문에 압축 효율이 좋음
   • 자주 사용되는 데이터는 메모리와 디스크 사이에서 효율적으로 압축 및 캐싱
3. 병렬 처리(Parallel Execution)
   • 각 컬럼은 독립적으로 처리 가능해서 멀티코어, 다중 노드에서 병렬 처리에 강함
   • Redshift는 내부적으로 각 컬럼을 슬라이스로 분할해 병렬 처리함

Redshift 쿼리 재실행 시 빠른 이유?

1. 쿼리 캐싱(query result caching) 으로 인해 쿼리 성능 향상
   • Query Result Cache (결과 캐시)
   • 조건: 완전히 동일한 SQL, 같은 사용자가 실행, 쿼리에 포함된 테이블/데이터가 변경되지 않았어야 함 - Compile Cache (쿼리 계획 캐시)
   • 쿼리 실행 시, 내부적으로 쿼리 실행 계획을 생성(compile)
   • 이 계획을 재사용할 수 있도록 일부를 캐시합
2. 자주 사용되는 데이터는 메모리와 디스크 사이에서 효율적으로 압축 및 캐싱
   • 위 장점 2번에서 나온 내용
   • 같은 쿼리를 여러 번 실행하면 I/O 비용이 줄어들면서 속도 개선

이러한 이유로 초기 쿼리 실행 시에는 좀 시간이 걸린다고 느껴지는 듯하다.

소회

• airflow 까지 도입하며 데이터 파이프라인을 구축하고 관리하는 계기가 됐음
• S3 에 저장된 파일들에 곧바로 쿼리할 수 있는 Athena 도 사용하려고 했으나 활성화되지 못함
  • 비개발자가 S3 데이터에 접근하여 조회할 수 있는 데이터 민주화(?) 실패
• 2-4주 정도에 한 번씩 10분 가량의 서비스 점검 다운타임이 발생하더라
• 제대로 100% 활용하고 있지는 못하고 있다