Redshift Scaling, 분산 저장 방식

 

Redshift의 스케일링 방식 (1)

 

용량이 부족해질 때마다 새로운 노드를 추가하는 방식으로 스케일링합니다.

 

Scale Out 방식과 Scale Up 방식이 있습니다.

예를 들어 0.16TB 용량의 dc2.large를 사용중 공간이 부족해질 때 dc2.large 한대를 더 추가하면 Scale out입니다. 그게 아니라 더 성능이 좋고 용량이 큰 dc2.8xlarge로 교체하며 사양을 더 좋은 것으로 업그레이드하면 scale up입니다.

 

이를 Resizing이라고 부르며 Auto Scaling 옵션을 설정하면 자동으로 이루어집니다.

 

 

Redshift의 스케일링 방식 (2)

 

이는 Snowflake나 BigQuery의 방식과는 굉장히 다릅니다.

이 둘은 특별히 용량이 정해져있지 않고 사용한만큼 지불하는 온 디맨드(OnDemand) 방식으로 Redshift보다 훨씬 더 Scalable합니다. 다만 그렇기 때문에 비용 예측이 불가능하므로 기업의 재무 측면에서는 비용관리가 까다롭다는 단점이 있습니다. 

 

 

 

 

 

 

 

 

 

 

Redshift 최적화는 굉장히 복잡

 

Redshift는 Snowflake와 BigQuery에 비해 최적화가 굉장히 복잡합니다.

그 이유는 노드가 두 대 이상인 경우 한테이블의 레코드들이 어떤 방식으로 여러개의 노드들에 분산 저장되어야 할지 개발자가 순서를 하나하나 지정해줘야하기 때문입니다.

 

 

 

 

하지만 Snowflake와 BigQuery는 그럴 필요가 전혀 없습니다.

반면에 Redshift는 자칫 데이터 스큐(Data Skew)가 발생할 가능성이 매우 높습니다.

 

위의 이미지를 예로 들면 전체 데이터의 데이터 중 98%는 노드 1, 1%는 노드2와 3에 각각 저장될 수 있다는 것입니다. 이렇게 되면 노드2, 노드3는 데이터 프로세싱 시간이 굉장히 신속하게 이루어지지만 노드1은 시간이 오래 걸릴 수 있습니다. Hadoop, Map Reduce, Hive, Presto, Spark 모두 이런 문제를 갖고 있습니다.

 

Snowflake와 BigQuery가 Data Skew 방지를 100% 해주는 것은 아니지만 훨씬 편리한 것 역시 사실입니다.

 

 

 

 

 

 

 

 

Redshift의 레코드 분배와 저장 방식 (1)

그렇다면 Redshift는 두 대 이상의 노드로 구성됐을 시 어떻게 최적화를 할까요?

 

Distkey, Diststyle, Sortkey 세 개의 키워드를 알아야 합니다.

 

AWS Redshift에서 데이터는 여러 노드와 디스크에 분산되어 저장됩니다. 이 분산 저장 방식을 제어하는 데 사용되는 개념이 바로 Distkey, Diststyle, Sortkey입니다.

1. Distkey (Distribution Key): 테이블의 특정 열을 Distkey로 지정하면, Redshift는 해당 열의 값에 따라 행을 노드에 분산시킵니다. 이는 JOIN 연산 시에 효율적인 성능을 제공합니다. JOIN을 수행할 때 같은 Distkey를 가진 행들이 같은 노드에 위치하면 네트워크 I/O를 줄일 수 있습니다.

2. Diststyle (Distribution Style): Diststyle은 테이블의 행이 노드에 어떻게 분산되는지를 결정합니다. 세 가지 유형의 Diststyle이 있습니다: EVEN, KEY, ALL.

EVEN (기본값): 행이 노드에 균등하게 분산됩니다.

ex) 100개의 레코드들을 5개의 노드에 20개씩 저장합니다.

KEY: Distkey 열의 값에 따라 행이 노드에 분산됩니다.

Diststyle에서 KEY를 사용해야 Distkey 사용에 의미가 생깁니다.

ALL: 테이블의 모든 행이 모든 노드에 복사됩니다. 이는 작은 참조 테이블에 유용합니다.

ex) 100개의 레코드들을 5개의 노드에 100개씩 통채로 똑같이 저장합니다.

3. Sortkey (Sort Key): Sortkey를 지정하면, Redshift는 해당 열의 값에 따라 행을 디스크에 정렬하여 저장합니다. 이는 WHERE 절에 사용되는 열에 대해 데이터를 빠르게 읽는 데 도움이 됩니다. 두 가지 유형의 Sortkey가 있습니다: Compound와 Interleaved.

 

Sortkey는 타임스탬프로 사용하는 것이 일반적입니다.

Compound: 첫 번째 Sortkey 열을 기준으로 주요 정렬이 이루어지고, 그 다음 Sortkey 열은 첫 번째 열 값이 같은 행들 사이에서 추가 정렬을 제공합니다.
Interleaved: 모든 Sortkey 열이 동등하게 중요하게 취급되어, 여러 열을 기준으로 복잡한 쿼리를 빠르게 수행할 수 있습니다.

이러한 설정은 테이블 생성 시에 지정할 수 있으며, 데이터의 분포와 쿼리 성능에 큰 영향을 미칩니다. 따라서, 데이터의 특성과 쿼리 요구 사항에 따라 적절한 설정을 선택해야 합니다.

 

 

 

 

 

 

 

 

Redshift의 레코드 분배와 저장 방식 (2)

 

아래 그림을 보며 Redshift의 Diststyle의 3가지 방식을 알아보겠습니다.

 

 

 

ALL은 말 그대로 100개의 레코드들을 2개의 노드에 100개씩 똑같이 저장한다는 뜻입니다.

 

EVEN은 100개의 레코드들을 2개의 노드에 50개씩 저장한다는 뜻입니다.

 

여기서 가장 눈여겨 보아야 할 Tricky한 방식은 왼쪽 그림의 KEY방식입니다.

지정한 KEY에 맞춰 KEY가 같은 값들은 같은 노드로 저장됩니다. 의도한대로 잘 작동한다면 JOIN과 GROUP BY시 유리합니다. 문제는 어떤 KEY에 해당되는 레코드들이 너무 많다면 Data skew가 발생해 어떤 노드(들)에만 데이터들이 너무 쏠리게 되어 분산 저장 방식의 의미가 사라지게 됩니다. 때문에 Redshift, Hadoop, Map Reduce, Hive, Presto, Spark 등을 사용할 때 최적화를 잘 해주는 것이 개발자의 필수 역량입니다.

 

 

 

 

 

 

 

 

 

Redshift의 레코드 분배와 저장 방식 예

 

CREATE TABLE my_table (
	column1 INT,
	column2 VARCHAR(50),
	column3 TIMESTAMP,
	column4 DECIMAL(18,2)
) DISTSTYLE KEY DISTKEY(column1) SORTKEY(column3);

 

위의 SQL 쿼리에서 맨 마지막 줄을 주목해주세요.

 

이는 위의 이미지에서 가장 왼쪽의 그림과 같은 분산 저장 방식입니다.

 

my_table의 레코드들은 column1의 값을 기준으로 분배되고 같은 노드(슬라이스)안에서는 column3의 값을 기준으로 sorting된다는 뜻입니다.

 

Sortkey는 타임스탬프로 사용하는 것이 일반적입니다.