참고: 이 내용은 2021. 11. 18에 게시된 컨텐츠(More Throughput and Faster Execution for Interactive Use Cases: Now in Public Preview)에서 번역되었습니다.
Snowflake는 수천 개의 비즈니스를 위한 데이터 중추로, 가치를 제공하는 데 필요한 데이터 액세스 및 거버넌스를 지원합니다. 그러나 일부 데이터 애플리케이션 및 임베디드 분석의 대화형 사용 사례는 특정 문제를 제기합니다. 기존에는 이러한 솔루션에 필요한 속도와 처리량을 제공하기 위해 추가 캐싱 레이어가 필요했으며 이로 인해 비용과 아키텍처 복잡성도 증가했습니다.
오늘 우리는 이러한 대화형 사용 사례를 지원하기 위해 유연한 성능 엔진을 개선했음을 발표하게 되어 기쁩니다. 이제 이 업데이트의 공개 미리 보기가 제공되며, 동시성, 처리량 및 더 빠른 실행이라는 측면에서 크게 향상되었습니다.
비공개 미리 보기 중에 사이버 보안 회사인 HUMAN은 아키텍처를 단순화하고 대화형 대시보드를 Snowflake로 마이그레이션할 수 있었습니다. 이를 통해 데이터 새로 고침이 몇 시간에서 몇 분으로 향상되고 쿼리의 최대 대기 시간이 1분 초과에서 2초 미만으로 줄었습니다. Snowflake BUILD 2021에서 HUMAN의 플랫폼 엔지니어링 부사장인 Swati Baradia는 자사의 인간 검증 엔진이 수조 건의 상호작용을 사전에 처리하여 봇을 식별하고 디지털 광고 사기를 예방하는 방법과 대시보드에 고객을 위한 더 많은 정보를 표시하여 자신만의 개인화된 통찰력을 얻을 수 있는 방법 등을 공유했습니다.
“Snowflake는 모든 캡처된 데이터를 생성된 지 20분 이내로 사용할 수있는 생태계를 구축할 수 있게 해주었습니다. 이전에는 2시간 30분이 넘었던 것에서 줄어든 것입니다.”라고 Baradia는 말했습니다. “데이터 새로 고침 덕분에 활동적인 위협을 더 빨리 탐지할 수 있습니다.”
캘리포니아 공중 보건국(CDPH)과 캘리포니아 기술국(CDT) 역시 California 디지털 COVID-19 백신 기록 포털에서 작업하는 동안 동시성과 대기 시간의 개선 사항을 이용해 수백만 명의 캘리포니아 주민이 기록을 신속하게 받을 수 있도록 했습니다. CDT는 포털 코드를 GitHub에 공유했으며 이는 이후에 콜로라도 및 기타 주에서 사용되었습니다.
동시성 및 대기 시간 개선: 우리의 방법
다음을 통해 대화형 사용 사례에 대해 이러한 개선을 이뤘습니다.
- 동시 쿼리 처리를 다루는 핵심 엔진 재설계
- 포인트 조회 및 집계를 포함하여 자주 사용되는 데이터 액세스 패턴 최적화
포인트 조회는 사용자가 검색 키 및 기타 조건자로 소수의 레코드를 검색하는 쿼리입니다. 예를 들어, 사용자는 세션 ID와 시간 범위를 사용하여 웹 페이지 클릭을 검색할 수 있습니다.
반면에 집계는 계산, 합산 또는 최댓값 계산과 같은 연산이며 그룹화를 포함하거나 포함하지 않을 수 있습니다. 집계의 예에는 특정 세션 ID에 대한 웹 페이지 클릭 수 계산 및 세션 ID에 대한 웹 페이지 클릭 수 계산이 포함되지만 먼저 페이지 URL별로 그룹화됩니다.
고객이 새로운 대화형 워크로드를 구축하고 기존 워크로드를 개선할 수 있도록 우리는 쿼리 처리 인프라의 모든 부분을 분석하여 대기 시간과 동시성을 최적화했습니다.
Snowflake에서 쿼리는 다음 단계를 거칩니다(그림 1 참조).
- 설정: 클라이언트 애플리케이션이 Snowflake에 쿼리를 보낸 후 우리가 초기 리소스를 할당합니다.
- 컴파일: 쿼리 문이 구문 분석되고 그 쿼리를 실행하기 위한 계획을 세웁니다.
- 스케줄링: Snowflake는 가상 웨어하우스에 쿼리를 실행하기에 충분한 리소스가 있는지 확인합니다. 있는 경우 쿼리가 실행 단계로 전환됩니다. 그렇지 않으면 쿼리가 대기열에 추가됩니다.
- 실행: 이 단계에서 우리는 데이터에 액세스하고, 테이블을 결합하고, 조건자로 데이터를 필터링하고, 집계를 수행합니다. 결과는 요청한 클라이언트 애플리케이션으로 반환됩니다.
- 대기 중: 쿼리를 실행할 여유 리소스가 없는 경우 쿼리는 대기열 단계에서 시간을 보내고 또 다른 실행 시도를 위해 다시 스케줄링으로 이동합니다.
그림 1: 쿼리 처리의 다섯 단계
가장 큰 변경 사항은 스케줄링 단계에 있었습니다. 이 단계에서 메타데이터 액세스 속도를 높이고 실행 리소스 할당을 위한 알고리즘을 미세 조정했습니다. 이를 통해 특히 멀티 클러스터 웨어하우스에서 동시성이 크게 향상되었습니다. 또한 쿼리 시작 시간도 단축했습니다. 이는 특히 100밀리초 미만이 소요되는 단기 쿼리와 관련이 있습니다. 컴파일 시간은 대부분의 쿼리에 대해 최대 15%까지 단축되었으며 IF-THEN-ELSE 문 및 문자열 비교 작업의 실행을 최적화하여 실행 시간을 최대 50%까지 단축했습니다. 이러한 개선 사항은 Snowflake에서 실행되는 모든 유형의 쿼리와 모든 종류의 워크로드에 도움이 되지만 단기 실행 쿼리와 높은 수준의 동시성이 지배적인 대화형 사용 사례에 매우 효과적입니다.
대기 시간 및 동시성 개선은 또한 Snowflake의 검색 최적화 서비스의 이점을 증폭합니다. 검색 최적화 서비스는 포인트 조회 쿼리의 대기 시간을 크게 줄이고 동시성 개선과 결합하면 웨어하우스에 높은 수준의 동시성이 있는 경우에도 빠른 조회를 제공할 수 있습니다.
숫자로 따져보기: 성능 자세히 살펴보기
대화형 사용 사례의 개선 사항을 확인하기 위해 변경 전후 Snowflake의 성능을 평가했습니다. 매장 매출, 반품, 재고 등이 담긴 테이블과 함께 10 TB TPC-DS 데이터 세트를 사용했습니다. 그리고 성능을 평가하기 위해 세 가지 유형의 쿼리(글로벌 집계, 그룹화 및 집계, 포인트 조회)를 정의했습니다. 이러한 쿼리는 다양한 날짜, 매장 및 기타 매개변수와 함께 실행되어 Snowflake의 결과 집합 캐시를 재사용하지 못하도록 하였으므로 더 까다로운 테스트가 되었습니다. 10TB 데이터 세트에서 가장 큰 테이블은 290억 개의 레코드를 포함하는 Store_Sales였습니다.
실제 대화형 사용 사례에서 흔히 볼 수 있듯이, 우리의 쿼리는 전체 5년 동안의 매장 판매보다 더 좁은 시간 범위의 데이터에 액세스했습니다. 이를 통해 Snowflake는 이전에 액세스한 일부 데이터를 로컬 데이터 캐시에 캐시하여 쿼리 수명 주기의 일부를 가속화할 수 있었습니다. 전체적으로 약 3억 2천만 개의 Store_Sales 레코드가 로컬로 캐시되었습니다.
쿼리 1: 전역 카운트(집계)
기능: 하루 동안 모든 매장의 매출을 합산합니다.
select sum(ss_quantity), sum(ss_list_price), sum(ss_sales_price), sum(ss_net_profit)
from store_sales, date_dim
where ss_sold_date_sk = d_date_sk
and d_date = $randomDate
쿼리 2: 그룹화 및 계산(집계)
기능: 30일 동안 100개 매장에 대한 매출을 매장별로 분류합니다.
select ss_store_sk, sum(ss_quantity), sum(ss_list_price), sum(ss_sales_price), sum(ss_net_profit)
from store_sales, date_dim
where ss_sold_date_sk = d_date_sk
and d_date between $randomDate and ($randomDate + 30)
and ss_store_sk between $randomStore and ($randomStore +100)
group by ss_store_sk
쿼리 3: 포인트 조회
기능: 특정 제품 및 티켓 번호에 대한 구체적인 판매 기록을 찾습니다.
select ss_ticket_number, ss_store_sk, ss_quantity, ss_list_price, ss_sales_price, ss_net_profit
from store_sales
where ss_ticket_number = $randomTicketNumber
and ss_item_sk = $item_sk
성능 향상을 켜고 검색 최적화 서비스를 활성화하기 전에 테스트 제품군을 실행한 다음, 활성화된 상태에서 테스트를 다시 실행했습니다. 두 경우 모두 8개 클라이언트에서 시작하여 최대 80개까지 증가하는 클라이언트 연결 수에서 대기 시간과 처리량을 관찰했습니다. 실제 대화형 대시보드에서는 이것이 수백 명의 동시 대시보드 사용자에 달합니다.
대기 시간 개선 정량화
개선의 정도가 인상적이었습니다. 이전에는, 가상 웨어하우스에 더 많은 로드를 추가함에 따라 세 쿼리 모두의 쿼리 대기 시간이 증가하는 경향이 있었습니다. 개선 후에는 추가 리소스 없이 동일한 가상 웨어하우스가 가장 높은 동시성 수준에서도 동일한 속도를 유지할 수 있었습니다.
‘전역 카운트’ 쿼리 1의 대기 시간은 그림 2와 같이 가장 높은 동시성 수준(80 스레드)에서 1.1초에서 0.25초(4배 감소)로 감소했습니다. ‘그룹화 및 계산’ 집계 쿼리 2의 대기 시간은 1.25초~0.5초, 2.7배 감소했습니다(그림 3 참조).
그림 2: 다양한 동시성 수준에서 집계 쿼리 1의 대기 시간, 2021년 5월 대 2021년 11월
그림 3: 다양한 동시성 수준에서 집계 쿼리 2의 대기 시간, 2021년 5월 대 2021년 11월
최근의 최적화가 없었다면 포인트 조회 쿼리 3은 높은 수준의 동시성에서 5초 이상 걸릴 수 있었습니다. 동시성 최적화를 켜면 모든 동시성 수준에서 쿼리에 걸리는 시간이 최대 20% 감소했습니다. Store_Sales 테이블에서 검색 최적화 서비스를 활성화하면, 클라이언트 수와 관계없이 거의 일정한 0.5초의 대기 시간을 달성했습니다(그림 4 참조).
그림 4: 동시성 및 검색 최적화가 있는 경우와 없는 경우, 다양한 동시성 수준에서 포인트 조회 쿼리 3의 대기 시간, 2021년 5월 대 2021년 11월
처리량 개선 정량화
개선된 엔진과 검색 최적화 서비스를 모두 적용했을 때 처리량 역시 긍정적인 영향을 받았습니다. 이러한 개선 사항이 없었다면, 더 많은 수의 클라이언트가 쿼리를 제출하더라도 웨어하우스 처리량은 약간만 증가할 것입니다(그림 5 참조).
업데이트 후 집계 쿼리 1 및 2의 처리량은 더 많은 클라이언트가 쿼리를 실행함에 따라 거의 선형으로 증가했습니다. 쿼리 1의 처리량은 317,000 시간당 쿼리(QPH)로 3.7배 증가했습니다(그림 5 참조). 쿼리 2의 처리량은 176,000QPH로 이전보다 2.1배 증가했습니다(그림 6 참조).
그림 5: 다양한 동시성 수준에서 집계 쿼리 1의 처리량, 2021년 5월 대 2021년 11월
그림 6: 다양한 동시성 수준에서 집계 쿼리 2의 처리량, 2021년 5월 대 2021년 11월
대기 시간과 유사하게 포인트 조회 쿼리 3의 처리량은 동시성 개선만으로도 최대 30%의 혜택을 받았으며 최고 40,000QPH에 이르렀습니다. 진정한 돌파구는 검색 최적화 서비스 활성화로 이뤄졌으며, 2021년 5월에 비해 6.3배 증가한 180,000 QPH로 처리량이 증가했습니다(그림 7 참조).
그림 7: 동시성 및 검색 최적화 서비스가 있는 경우와 없는 경우, 다양한 동시성 수준에서 포인트 조회 쿼리 3의 처리량, 2021년 5월 대 2021년 11월
공개 미리 보기 참여: 지금 시작하기
2021년 6월에 처음 발표한 이후 거의 100명의 고객이 대기 시간 및 동시성 개선에 대한 비공개 미리 보기를 시도했습니다. 오늘, 공개 미리 보기에서 이러한 개선 사항의 첫 번째 세트를 광범위하게 출시합니다.
이러한 핵심 엔진 개선 사항의 이점을 얻으려면 다음을 포함하여 개선 사항이 기본적으로 활성화되어 있는 네 가지 배포 중 하나에서 운영해야 합니다.
- AWS ap-southeast-1(싱가포르)
- AWS eu-west-1(아일랜드)
- AWS eu-central-1(프랑크푸르트)
- Azure West Europe
다른 배포의 가상 웨어하우스는 2022년 상반기에 이러한 개선 사항의 이점을 누릴 수 있도록 자동으로 업그레이드됩니다. 다른 배포에서 가상 웨어하우스를 활성화하려면 Snowflake 계정 팀에 지원을 요청하십시오.
이러한 개선 사항을 활성화하기 전과 후에 웨어하우스의 성능을 비교하려면 계정 사용량 보기 쿼리에 대한 당사 가이드를 검토하십시오.
더 많은 업데이트를 기대해 주십시오. Snowflake 성능을 개선하고 이러한 이점을 고객에게 전달하기 위해 우리는 지속적으로 노력하고 있습니다!