Redshift를 활용한 데이터 웨어하우스 구축기
*지난 7월 1일 ~ 8월 15일까지 6주간 진행했던 데이터 엔지니어링 프로젝트에 대한 회고 포스팅이다
데이터를 분석하고 서비스를 개선하려면, 먼저 가상의 서비스를 직접 만들어야했다. 따라서 글 초반엔 이 서비스 자체에 대해 조금 언급하고 넘어갈 예정이며, 내가 직접 설계한 부분을 중점으로 데이터 웨어하우스를 어떻게 구축했는지 이야기할 것이다
1. 아키텍처
아키텍처는 다음과 같다. 서비스할 데이터를 API에서 Airflow를 통해 배치 처리로 가져오면 Redshift엔 계속 적재되는 형태로 쌓고, Production DB엔 새로 추출된 데이터만 업데이트했다
2. 주제 구체화 및 서비스를 위한 프로덕션 DB 모델링
우리는 서울로 여행오는 외국인 관광객을 위한 항공/관광 웹서비스라는 주제를 정하고, 프로덕션 DB를 모델링했다. 내가 맡았던 부분은 항공과 환율 파트였는데, 아래 사진에서 보이듯 사용자가 출발 공항과 출발 날짜를 선택하면 인천국제공항으로 오는 편도 항공권에 대한 정보와 예약 페이지로 넘어갈 수 있는 버튼을 제공한다. 환율 정보는 사용자가 선택한 출발 공항에 맞추어 제공하고, 날씨 정보는 사용자가 선택한 출발 날짜에 맞추어 작년 동일한 날짜의 날씨를 제공해준다
사용자에게 서비스를 제공하기 위해선 프로덕션 DB에 사용자가 원하는 정보가 있어야 한다. 따라서 프로덕션 DB는 항공권 엔티티, 환율 엔티티, 날씨 엔티티로 구성했다. 이렇게 구성함으로 사용자가 출발 날짜와 출발 공항을 선택했을때 항공권 정보와 날씨, 환율 정보를 가져와 제공할 수 있다
3. 데이터 웨어하우스 모델링
1) AWS Redshift 선택 이유
먼저, AWS Redshift를 데이터 웨어하우스로 선택한 이유는 데브코스에서 제공하는 옵션이었기 때문이다. 옵션마다 여러 장단점이 있겠지만 학생 여럿이 사비로 구축하기는 어려웠기에 제공하는 옵션을 선택했다
2) 데이터 웨어하우스 모델링
보통은 프로덕션 DB나 다른 데이터 원천에서 가져올 소스들을 파악하는게 먼저고, 그 데이터를 어떤 형태로 싣을지 고민하는게 두번째인것 같다. 우리는 현재 운영되고 있는 서비스가 아닌 직접 서비스를 만들면서 동시에 데이터 웨어하우스를 구축해야 했기 때문에, 서비스를 제공할 수 있는 데이터를 가진 API를 통해 적재하고 사용자 로그 데이터는 더미데이터로 직접 만들었다
먼저 서비스 제공을 위한 데이터는 다음과 같이 모델링했다. API 명세는 우리가 컨트롤할 수 없기에 API에서 우리가 사용할 수 있는 각 컬럼을 선별하고 데이터를 처리한 뒤 적재하는 방식으로 진행했다
더미데이터로 생성한 사용자 로그 데이터는 다음과 같이 모델링했다. 사실 사용자를 직접 받아 서비스를 운영하기 어려웠기에, '사용자가 서비스를 이용한다면 어떤 로그 데이터를 적재할 수 있을까?'를 예상하며 데이터를 모델링했다. 사용자가 웹사이트에 접속해 항공권을 검색하고, 클릭하고, 티켓을 구매할 것이다. 또한 모든 사용자가 가입하진 않겠지만 구매한 사용자에 한해선 회원가입이 필수기 때문에 사용자 정보가 존재할 것이다. 각 엔티티를 뽑아내 테이블을 만들었다
4. 최적화 기법 적용
AWS Redshift는 정렬키, 분산키, 캐싱, 쿼리 최적화, 서브쿼리 테이블화 등을 활용해 쿼리를 효율적으로 처리할 수 있다. 노드가 1개인 클러스터를 허용했기 때문에 분산키의 이점을 보긴 어려웠다. 따라서 정렬키, 서브쿼리 테이블화에 중점을 둬 최적화 기법을 실험해봤다
4-1. 정렬키(sort key) 지정
정렬키 여부에 따른 쿼리 성능을 분석하기 위해 테이블 생성시 정렬키를 지정한 것과 지정하지 않은 것을 모두 만들어 비교했다. 정렬키는 Redshift 데이터 노드 내 블록에 데이터가 저장될 때, 데이터를 정렬한 형태로 저장할 수 있게 하는 기법이다. 정렬키를 사용하면 조건절을 처리할 때 필요한 블록만을 검색할 수 있고, 조인시 이미 해당 컬럼이 정렬되어 있어 성능이 높아진다
가장 성능이 뚜렷했던 경우는 유입 채널별 구매수를 집계하기 위해 3개의 테이블을 조인한 쿼리였다. 사용자의 클릭 로그(4억건), 세션 채널 이력(400만건), 사용자의 구매 로그(2,000만건)가 사용됐고 각각 테이블에 JOIN시 사용되는 user_id, session_id를 sort key로 지정했다
sort key 지정 전에는 824초가 소요됐고, sort key 지정 후에는 174초로 소요 시간이 80% 가량 개선되었다
4-2. 서브쿼리 테이블화
우리가 구성한 대시보드에서 공통적으로 자주 쓰이는 서브쿼리가 존재했다. 이 서브쿼리 결과를 테이블화해 쿼리 실행시 다시 서브쿼리가 실행되는 것이 아닌, 결과 테이블을 불러오게 해 실행 시간을 단축시켰다. 아래 예시의 경우 60%가 개선되었다
5. 아쉬운 점
1) AWS Redshift의 기능을 다수 활용하진 못했다는 점이 아쉽다. Redshift는 여러 노드로 데이터를 분산할 수 있는 분산키(dist key)의 이점을 비교해 볼 수도 있지만 노드를 1개만 사용하도록 허용되어 분산키의 이점을 실험해보기 어려웠다
2) 더미데이터로 테이블의 레코드를 억 단위로 생성해보긴 했으나, 그 이상의 데이터를 처리할 때의 이점을 맛보긴 어려웠다. 학생의 입장에서 데이터 웨어하우스를 구축해보는 경험을 해본 것은 좋았지만, 현업에서의 데이터를 맛보고 싶었기에 약간은 아쉬웠다
6. 그럼에도 불구하고
그럼에도 불구하고... 혼자서는 구축해보지 못할 데이터 웨어하우스를 구축해봤다는 것에 의의가 있다. 사실 다른 소프트웨어 엔지니어들과 다르게 프로젝트를 구현해 포트폴리오를 만드는게 정말 어려운 분야인 것 같다. 이론적으로만 배우던 데이터 웨어하우스 제품을 직접 모델링하고 구성한 작은 경험이 바탕이 될 수 있길 바란다