일시: 24.05.16 15:20 ~ 16:00
장소: 그랜드볼룸
작성자 : CTC/백소정
Redshift는 최적화를 통해 성능을 크게 향상 시킬 수 있기 때문에 고객사에서는 어떻게 최적화를 하여 사용하고 있는지 사례를 알아보기 위해 해당 세션에 참가하였습니다.
Redshift는 Postgre DB를 기반으로 한 클라우드 데이터웨어하우스입니다. 정형 데이터 외에 orc, parquet 및 json 등의 데이터도 Redshift 내에서 활용 가능합니다. Redshift는 완전 관리형 서비스로 구축하고 관리하기가 매우 쉽고 가격대비 훌륭한 성능을 자랑합니다. ANSI SQL을 그대로 사용할 수 있고 여러 조직에 데이터 공유도 쉽습니다.
초기에는 컴퓨트와 스토리지가 결합된 형태인 DC2, DS2를 제공했고, 2019년에는 컴퓨트와 스토리지가 분리된 RA3 타입을 제공했습니다. 스토리지로 Redshift 관리형 스토리지를 사용하게 되어 데이터 증가로 인한 노드 증설이 불필요해졌습니다.해당 타입의 장점으로는 당연히 컴퓨트, 스토리지의 독립적인 확장과 비용입니다. 자주 접근되는 데이터는 캐싱 기능을 통해 더 빠르게 응답이 가능하고 AZ 장애 시 자동 복구 기능도 제공됩니다.
Redshift의 아키텍처로는 리더 노드, 컴퓨트 노드 그리고 스토리지가 있습니다. 리더 노드는 클라이언트와 애플리케이션 간의 상호작용을 담당합니다. 컴파일된 코드는 컴퓨트 노드에서 수행하고 최종 집계를 위해 결과를 리더 노드로 다시 보냅니다. 각 컴퓨트 노드는 별도의 CPU와 메모리를 가지고 스토리지 영역은 S3를 사용합니다.
Redshift는 DW의 시장과 고객의 요구사항 변화에 맞게 빠르게 혁신해보고 있습니다. 데이터 레이크에 있는 데이터를 분석하기 위해 Spectrum 기능을 사용할 수 있고 concurrency scaling도 활용함으로써 추가적인 확장이 가능합니다.
연동쿼리 기능을 활용하면 한 쿼리 내 Redshift 뿐 아니라 다양한 데이터 베이스에서의 데이터를 활용해 사용할 수 있습니다. Data sharing과 Data exchange를 통해서 데이터를 빠르게 수집하고 공유할 수 있습니다. 서버리스 기능을 통해서는 프로비저닝 없이 손쉽게 데이터 분석을 할 수 있습니다.
쿠팡은 대규모 데이터를 처리하기 위해 데이터 레이크, 웨어하우스를 사용하고 있습니다. Redshift는 크게 3가지에 대한 장점과 단점이 공존하는 양면성이 있습니다.
세가지 단점을 해결하기 위한 아키텍처 전략 4가지를 사용했습니다.
공유되는 리소스를 효율적으로 사용하기 위해, WLM를 통해 각 큐에 대한 분할 구성을 진행했습니다. 큐의 분할 구성으로, 사용자 큐와 반드시 돌아야하는 배치 큐로 분할 구성을 했습니다. QUERY monotoring rules로 SQL이 특정 시간 이상 수행됐으면 이 쿼리를 취소하는 등 과도하게 리소스를 사용하는 것을 방지합니다. Adhoc큐는 사용자 큐, 배치 큐는 밤에 실행되는 쿼리, SLA 큐는 반드시 돌아 가야하는 큐입니다. 각 큐에 대한 QMR을 적용합니다. 실행 시간과 CPU 시간, 디스크 사용량을 바탕으로 규칙을 정의할 수 있습니다.
또 다른 문제는 성능을 위한 제한된 동시성입니다. Redshift는 성능을 위해 최대 동시 실행 가능한 쿼리의 개수는 50개 이고 그 이상은 대기열에 쌓이게 됩니다. 문제는 대기열에 쿼리가 쌓이는 것이 무제한이라는 것입니다. 사용자가 많은 날에는 쿼리 속도 편차가 크게 날수도 있고 사용자의 불만이 생길 수 있습니다. SQL의 피크 타임 때문에 노드를 증설하면 비용 효율적이지 않기 때문에, main cluster를 복제하는 방식, 즉 concurrency scaling을 하게 됩니다. 대기열에 있는 쿼리들이 concurrency scaling 클러스터에서 실행되고 동시성을 극복할 수 있습니다. 이를 통해서는 queue 대기 없이 50개 이상의 동시 수행이 가능하지만 전체 사용 시간에서 1시간만 무료인 점을 유념해 사용해야 합니다. concurrency scaling은 클러스터 단위로 사용하는게 아니라 큐 단위로 사용 가능합니다.
Redshift의 데이터는 독립적인 RMS에 저장됩니다. 클러스터 내의 데이터도 공유되지 않고 당연히 데이터 레이크와도 연결되지 않는 고립성이 발생합니다. 클러스터 간 공유를 위해서는 data sharing 기능을 사용하면 논리적으로 클러스터 간 데이터를 공유 받을 수 있습니다. 실시간으로 데이터 조회가 가능하고 데이터 퀄리티 이슈도 존재하지 않습니다.
기존에는 데이터 공유를 위해 물리적인 데이터 복사를 하고 이를 위한 데이터 파이프라인 구축, 데이터 퀄리티 검증이 필요했습니다. 최적화를 통해서는 producer cluster와 consumer cluster를 분리 구성하고 sharing 기능을 통해 물리적인 데이터 공유가 아닌 논리적인 공유를 구성했습니다.
데이터 레이크와의 고립성으로 인한 문제는 Redshift Spectrum으로 해결할 수 있었습니다. 기존에는 copy 명령어로 물리적인 복제를 하고 다른 테이블과 조인해서 데이터를 만들면 다시 S3로 데이터를 unload했습니다. spectrum을 사용하면 Redshift에서 데이터 레이크의 데이터를 읽고 실시간으로 Redshift 데이터와 조인 후 데이터 레이크로 insert합니다. 또한 Spectrum을 사용하면 data lifecycle management를 사용하여 데이터 생명주기를 관리할 수 있습니다.
비용 절감은 다음과 같은 전략으로 진행하였습니다. RI를 활용해 온디맨드 인스턴스를 사용함으로써 비용 절했습니다. CS 노드를 사용할 때는 클러스터를 RI로 사용하고 있더라도 CS 노드는 RI가 아닌 온디맨드로 청구되기 때문에 비용이 높게 청구될 수 있습니다. 이에 실제로 사용되는 노드를 파악해 RI 인스턴스로 노드를 2배로 늘렸고 이를 통해 총 비용이 30% 절감하였습니다.
RMS 비용은 컴퓨팅과는 별도로 청구되어 인스턴스가 중지된 상태에도 비용이 청구됩니다. 데이터 사이즈를 최소화해야 하는데, life cycle 기능을 통해 90일 이상 액세스하지 않은 데이터는 자동 삭제할 수 있도록 설정했습니다. 또 Spectrum을 통해 물리적인 복제가 아닌 논리적인 복제를 했습니다. Spectrum 사용 시, 데이터 레이크의 테이블 중 스캔된 사이즈만큼 비용이 청구됩니다. 1TB 스캔 당 5달러인데, Spectrum usage limit을 걸고 파일 포맷을 parquet, orc 및 파티션을 사용함으로써 비용 절감이 가능합니다. 데이터를 자주 그리고 많이 스캔해야 한다면 spectrum보다는 copy가 적합할 수도 있기 때문에 이 부분을 고려해 선택해야 합니다.
최근 데이터 웨어하우스에 대한 관심도 높아지고 시장에서의 경쟁도 치열해지는 것을 목격하고 있습니다. 시장 강자 답게, Redshift도 작년 리인벤트에서 성능 향상에 대한 많은 투자를 하고 있음을 확인할 수 있었습니다. 그 외에도 Redshift는 다양한 기능이 제공되어 Redshift를 더 “잘" 쓸 수 있는 방법들이 다양합니다. 이런 방안들을 실사례로 확인할 수 있는 흥미로운 세션이었습니다.