Amazon Redshift -4 (워크로드 관리)

https://nani-log.tistory.com/163

Amazon Redshift -3 (최적화 기법 - 분산/정렬/캐싱)

 

앞서 포스트에선 Redshift 최적화 기법에 대해 살펴봤다. 데이터 웨어하우스는 다수의 사용자가 다수의 데이터 처리를 요청할 때 각 쿼리의 우선순위를 염두에 두고 처리하는 것이 정말 중요한데, 오늘은 쿼리 요청을 처리하고 관리하는 부분인 WLM(WorkLoad Management)에 대해 살펴볼 것이다

 

Redshift에서는 WLM을 구성해 쿼리가 실행되는 순서를 큐(대기열)로 관리할 수 있고, 각 쿼리에 필요한 리소스 단위(메모리)를 슬롯으로 분할할 수 있다. 하나의 쿼리당 하나의 슬롯만 사용된다면 슬롯의 개수를 대기열에서 동시에 처리될 수 있는 쿼리 갯수라고 볼 수 있다

 

WLM은 자동과 수동으로 구성할 수 있는데, 각각의 장단점이 존재한다

자동 WLM

자동 WLM은 쿼리를 요청하면 자동으로 쿼리에 필요한 리소스 양을 결정하고, 워크로드에 근거해 큐의 동시성을 조정한다. 대량의 리소스가 필요한 쿼리가 있으면 동시성은 낮아지고, 더 가벼운 쿼리들로 구성되어 있으면 동시성이 높아진다

 

쿼리의 우선 순위를 지정할 수는 있지만 각 쿼리에 사용되는 이미 지정된 슬롯의 메모리 양은 조정할 수 없어 메모리 양을 초과해야 하는 쿼리의 경우 처리될 수 없다

 

 

수동 WLM

수동 WLM은 큐마다 사용자가 메모리 비율을 지정할 수 있고, 쿼리에 할당되는 메모리 양 또한 조절할 수 있다. 하지만 이를 위해선 쿼리를 지속적으로 모니터링하고 세부적으로 조정해주는게 필요할 것이다

 

예시로, 장시간 실행되는 쿼리와 단시간 실행되는 쿼리를 각각의 대기열로 구성해 각 대기열에 필요한 메모리를 비율로 할당하고 대기열 내에서 더 많은 메모리를 요하는 쿼리에게 더 많은 슬롯을 할당할 수 있게 된다

 

 

나의 생각

WLM을 공부하다 보니, 결국 쿼리를 처리하기 위해선 앞서 살펴봤던 최적화 기법들(분산, 정렬, 캐싱)과 맞물려 작동하는 포인트들이 보였다

1. 각 큐에 메모리를 할당할때 아무 리소스를 분배하는게 아닌, 결국 데이터가 잘 분산되어 있어야 데이터 지역성(각 슬라이스에서 처리되는 것)을 최적화할 수 있다는 점
2. 정렬을 잘 설정해두면 일차적으론 필요한 블록만을 읽을 수 있고, 압축률이 좋아 스토리지와 I/O 작업시의 효율을 높일 수 있다는 점
3. 캐싱을 전략적으로 사용하면, 처리할 워크로드를 줄일 수 있다는 점

결국 데이터 웨어하우스는 분산 시스템을 바탕으로 설계된 것이기에 하둡에서 중요하게 생각했던 포인트인 분산, 병렬 처리, 리소스 관리 등의 포인트를 잘 핸들링해줘야 한다. 물론 관리형 데이터 웨어하우스인 Redshift는 하둡보다 이를 더 쉽게 관리해주겠지만 아무 신경도 쓰지 않고 사용하면 결국 아주 비효율적으로 데이터 웨어하우스를 운영하게 된다

 

 

정리

4개의 포스트를 통해 설계적 특성부터 아키텍처, 최적화 기법, 워크로드 관리까지 살펴봤다. 사실 아주 깊게 들어가기엔 직접 구축하고 부딪혀봐야 알 수 있는 부분들이 많아서 더 깊이 건들일 순 없었다. 하지만 기술 블로그를 통해 각 회사에서 Redshift를 이용해 데이터 웨어하우스를 어떻게 구축했는지 살펴보면 어느 정도의 감은 생길 것이다. 다음 포스트에선 그 구축 사례에 대해 살펴볼 예정이다