작업 소개¶

서버리스 작업¶

작업을 위한 서버리스 컴퓨팅 모델을 사용하면 사용자 관리 가상 웨어하우스 대신 Snowflake에서 관리하는 컴퓨팅 리소스에 의존할 수 있습니다. Snowflake는 각 워크로드에 필요한 서버리스 컴퓨팅 리소스의 크기를 자동으로 조정합니다. Snowflake는 동일한 작업의 가장 최근 실행에 대한 통계의 동적 분석을 기반으로 주어진 실행에 대한 서버리스 컴퓨팅 리소스의 이상적인 크기를 결정합니다. 서버리스 작업의 최대 컴퓨팅 크기는 XXLARGE 사용자 관리 가상 웨어하우스와 동일합니다. 계정의 여러 워크로드가 공통 컴퓨팅 리소스 세트를 공유합니다.

서버리스 컴퓨팅 모델을 사용하려면 CREATE TASK 를 사용하여 작업을 만들 때 WAREHOUSE 매개 변수를 생략합니다. CREATE TASK 명령을 실행하는 역할은 전역 EXECUTE MANAGED TASK 권한이 있어야 합니다. 작업의 액세스 제어 요구 사항에 대한 자세한 내용은 작업 보안 섹션을 참조하십시오.

서버리스 작업 실행 요금 청구는 컴퓨팅 리소스를 위해 가상 웨어하우스에 의존하는 작업의 표준 크레딧 소비 모델과 다릅니다. 자세한 내용은 작업 비용 섹션을 참조하십시오.

사용자 관리 작업¶

또는 작업을 생성할 때 기존 가상 웨어하우스를 지정하여 개별 작업에 대한 컴퓨팅 리소스를 관리할 수도 있습니다. 이 옵션을 사용하려면 작업에 의해 실행되는 SQL 동작에 알맞은 크기의 웨어하우스를 선택해야 합니다.

웨어하우스 크기 선택하기¶

기존 웨어하우스를 사용하여 개별 작업에 컴퓨팅 리소스를 제공하기로 선택한 경우 웨어하우스 고려 사항 에 설명된 모범 사례를 따르십시오. 작업의 컴퓨팅 요구 사항을 파악하려면 웨어하우스 크기와 클러스터링을 기반으로 다양한 웨어하우스를 사용하여 단일 작업의 평균 실행 시간 또는 작업 그래프 를 분석합니다. 또한 웨어하우스가 여러 프로세스에 의해 공유되는지 여부도 고려해야 합니다.

작업의 평균 실행 시간을 분석하려면 TASK_HISTORY Account Usage 뷰 를 쿼리합니다. 작업의 예정 시간과 완료 시간 간의 평균 차이는 작업의 예상 평균 실행 시간입니다. 이 차이에는 다른 프로세스가 웨어하우스에서 컴퓨팅 리소스를 사용하는 동안 작업이 큐에서 대기된 시간이 포함됩니다.

작업 그래프의 경우, 이전 작업의 실행이 끝나고 하위 작업이 시작되면 잠시 지연이 발생합니다. 동시에 실행되는 여러 하위 작업을 수용할 수 있을 만큼 충분히 큰 웨어하우스 크기를 선택합니다.

다음 다이어그램은 단일 작업이 20초 동안 대기한 다음 40초 동안 실행된 1분의 윈도우를 보여줍니다. 이는 작업이 예약된 후 처음 20초 동안 다른 프로세스가 웨어하우스 리소스를 사용했음을 의미합니다.

다음 다이어그램은 각 실행을 완료하는 데 평균 5분이 필요한 작업 그래프를 보여줍니다. 다이어그램은 완료할 작업 그래프의 2회 실행에 대한 창을 보여줍니다. 이 윈도우는 루트 작업이 시작되도록 예약된 시간부터 마지막 하위 작업의 실행이 완료될 때까지 계산됩니다.

이 예제에서, 작업 그래프가 실행되는 웨어하우스는 다른 동시 작업과 공유됩니다. 이러한 동시 작업은 작업 그래프의 각 작업 실행이 완료되고 다음 작업 실행이 시작되기 전에 사용 가능한 모든 리소스를 소비합니다. 결과적으로, 각 작업의 윈도우에는 다른 작업이 완료되고 컴퓨팅 리소스를 확보할 때까지 기다리는 동안 약간의 큐가 포함됩니다.

컴퓨팅 모델 선택 권장 사항¶

다음 표에서는 서버리스 작업과 사용자 관리 작업을 사용할 시점을 결정하는 데 도움이 될 수 있는 다양한 요소를 설명합니다.

서버리스 작업 실행의 최대 크기는 XXLARGE 웨어하우스에 해당하는 크기입니다. 작업 워크로드에 더 큰 웨어하우스가 필요한 경우, 필요한 크기의 웨어하우스로 사용자 관리 작업을 만듭니다.

작업 일정 예약¶

작업은 일반적으로 일정에 따라 실행됩니다. CREATE TASK 를 사용하여 작업을 생성할 때 일정을 정의할 수 있으며, 이후에는 ALTER TASK 를 사용하여 일정을 정의할 수 있습니다.

독립 실행형 작업 또는 작업 그래프의 루트 작업은 일반적으로 일정에 따라 실행됩니다. CREATE TASK 를 사용하여 작업을 생성할 때 일정을 정의할 수 있으며, 이후에는 ALTER TASK 를 사용하여 일정을 정의할 수 있습니다.

Snowflake는 일정에 따라 한 번에 하나의 작업 인스턴스만 실행되도록 보장합니다. 다음으로 예약된 실행 시간이 발생할 때 작업이 계속 실행 중이면 예약된 시간을 건너뜁니다.

Snowflake는 서버리스 작업을 위해 자동으로 컴퓨팅 리소스의 크기를 조정하고 확장합니다. 사용자 관리 작업의 경우 일정 내에서 워크로드를 완료할 수 있도록 작업에 적합한 웨어하우스 크기를 선택합니다. 자세한 내용은 웨어하우스 크기 선택하기 섹션을 참조하십시오.

트리거된 작업¶

트리거 작업을 사용하면 정의된 스트림에 새 데이터가 있을 때만 작업을 실행할 수 있습니다. 이를 통해 예측할 수 없는 새 데이터가 있는 소스를 자주 폴링하는 일반적인 사용 사례가 간소화되고, 새 데이터가 있을 때 즉시 처리하여 지연 시간이 줄어듭니다.

트리거된 작업은 정의된 스트림에 데이터가 있고 작업 실행을 트리거할 때까지 컴퓨팅 리소스를 사용하지 않습니다.

트리거 작업에 대한 실행 조건은 다음과 같습니다.

• 연관된 스트림이 추적하는 테이블의 데이터가 변경되는 경우.

• 작업이 처음 재개될 때 스트림에 이미 있는 모든 데이터를 사용합니다.

• 트리거된 작업은 스트림이 부실 해지는 것을 방지하기 위해 12시간마다 자동으로 상태 검사를 실행합니다. 스트림에 데이터가 없으면 Snowflake는 컴퓨팅 리소스를 사용하지 않고 실행을 건너뜁니다.

CREATE TASK triggeredTask  WAREHOUSE = my_warehouse
  WHEN system$stream_has_data('my_stream')
  AS
    INSERT INTO my_downstream_table
    SELECT * FROM my_stream;

ALTER TASK triggeredTask RESUME;

ALTER TASK task SUSPEND;
ALTER TASK task UNSET SCHEDULE;
ALTER TASK task RESUME;

수동으로 작업 실행하기¶

EXECUTE TASK 명령은 수동으로 단일 작업 실행을 트리거합니다. 이 SQL 명령은 프로덕션에서 SQL 코드를 실행하도록 설정하기 전에 새 작업이나 수정된 작업을 테스트하는 데 유용합니다.

스크립트나 저장 프로시저에서 이 SQL 명령을 직접 호출할 수 있습니다. 또한 이 명령은 외부 데이터 파이프라인에서 작업 통합을 지원합니다. Snowflake 계정을 인증하고 SQL 작업을 승인할 수 있는 모든 서드 파티 서비스는 EXECUTE TASK 명령을 실행하여 작업을 실행할 수 있습니다.

작업 실행의 버전 관리¶

독립 실행형 작업을 처음 재개하거나 수동으로 실행하면 작업의 초기 버전이 설정됩니다. 독립 실행형 작업은 이 버전을 사용하여 실행됩니다. 작업이 일시 중단 및 수정된 후 독립 실행형 작업이 다시 시작되거나 수동으로 실행될 때 새 버전이 설정됩니다.

작업이 일시 중단되면 향후 예정된 모든 작업 실행이 취소되지만, 현재 실행 중인 작업은 현재 버전을 사용하여 계속 실행됩니다.

예를 들어, 작업이 일시 중단되었지만 이 작업의 예약된 실행이 이미 시작되었다고 가정하겠습니다. 작업의 소유자는 작업이 실행 중인 동안 작업에서 호출하는 SQL 코드를 수정합니다. 작업은 작업 실행을 시작할 때 최신 버전의 작업을 사용하여 정의에 있는 SQL 코드를 실행하고 실행합니다. 작업이 다시 시작되거나 수동으로 실행된 후의 새 작업 버전이 설정됩니다. 이 새 버전에는 작업에 대한 수정 사항이 포함됩니다.

작업 버전 기록을 검색하려면 SNOWFLAKE 공유 데이터베이스에서 TASK_VERSIONS Account Usage 뷰 를 쿼리하십시오.

실행 실패 후 작업 자동 일시 중단하기¶

선택적으로, 지정된 횟수의 연속 실행이 실패하거나 시간 초과되면 작업을 자동으로 일시 중단합니다. 이 기능을 사용하면 Snowflake 크레딧을 소비하지만 완료에 실행 완료에 실패하는 작업을 일시 중단함으로써 비용을 절감할 수 있습니다.

작업에 SUSPEND_TASK_AFTER_NUM_FAILURES = num 매개 변수를 설정합니다. 매개 변수를 0 보다 큰 값으로 설정하면 지정된 횟수의 연속 작업 실행이 실패하거나 시간 초과되면 작업이 자동으로 일시 중단됩니다.

매개 변수는 CREATE TASK 를 사용하여 작업을 생성할 때 설정하거나 나중에 ALTER TASK 를 사용하여 설정할 수 있습니다. 이 값은 Snowsight 에서 변경할 수도 있습니다.

SUSPEND_TASK_AFTER_NUM_FAILURES 매개 변수는 계정, 데이터베이스 또는 스키마 수준에서도 설정할 수 있습니다. 이 설정은 수정된 오브젝트에 포함된 모든 작업에 적용됩니다. 매개 변수를 더 낮은 수준에서 명시적으로 설정하면 더 높은 수준에서 설정된 매개 변수 값이 재정의됩니다.

실패한 작업 실행 자동 재시도¶

작업 그래프가 FAILED 상태에서 완료되면 Snowflake는 작업을 자동으로 다시 시도할 수 있습니다. 자동 작업 재시도는 기본적으로 비활성화됩니다. 이 기능을 사용하려면 TASK_AUTO_RETRY_ATTEMPTS 를 0보다 큰 값으로 설정합니다.

오류 알림을 사용하는 작업은 실패한 재시도 시도에 대해 알림을 보냅니다. 자세한 내용은 오류 알림을 보내도록 작업 구성하기 섹션을 참조하십시오.

계정, 데이터베이스 또는 스키마 수준에서 TASK_AUTO_RETRY_ATTEMPTS 매개 변수 값을 설정하면 다음 예약된 실행 중에 수정된 오브젝트에 포함된 작업에 변경 사항이 적용됩니다.

액세스 제어 권한¶

작업 권한을 관리하기 위한 사용자 지정 역할 만들기¶

사용자 지정 역할을 사용하면 Snowflake에서 각 계정이나 역할에 부여된 권한을 쉽게 관리할 수 있습니다. 사용자 지정 역할을 사용하여 모든 계정 또는 역할에 대한 권한을 변경하려면 사용자 지정 역할을 업데이트합니다. 또는 사용자 지정 역할을 제거하여 권한을 취소합니다.

USE SYSADMIN;

CREATE ROLE warehouse_task_creation
  COMMENT = 'This role can create user-managed tasks.';

USE ACCOUNTADMIN;

GRANT CREATE TASK
  ON SCHEMA schema1
  TO ROLE warehouse_task_creation;

GRANT USAGE
  ON WAREHOUSE warehouse1
  TO ROLE warehouse_task_creation;

USE SYSADMIN;

CREATE ROLE serverless_task_creation
  COMMENT = 'This role can create serverless tasks.';

USE ACCOUNTADMIN;

GRANT CREATE TASK
  ON SCHEMA schema1
  TO ROLE serverless_task_creation;

GRANT EXECUTE MANAGED TASK ON ACCOUNT
  TO ROLE serverless_task_creation;

USE ROLE securityadmin;

CREATE ROLE taskadmin;

USE ROLE accountadmin;

GRANT EXECUTE TASK, EXECUTE MANAGED TASK ON ACCOUNT TO ROLE taskadmin;

USE ROLE securityadmin;

GRANT ROLE taskadmin TO ROLE myrole;

작업 소유자 역할 삭제¶

작업의 소유자 역할을 삭제하면 해당 작업의 소유권은 소유자 역할을 삭제한 역할로 이전됩니다. 작업의 소유권이 이전되면 해당 작업은 자동으로 일시 중지되고 새 소유자가 작업을 재개할 때까지 새로운 실행은 예약되지 않습니다.

작업이 실행되는 중에 역할을 삭제하면 작업 실행은 삭제된 역할에서 처리를 완료합니다.

시스템 서비스 작업 실행¶

Snowflake는 작업 소유자의 권한으로 작업을 실행하지만 작업 실행은 사용자와 연결되지 않습니다. 대신 각 실행은 시스템 서비스에 의해 실행됩니다. 작업은 특정 사용자와 분리되어 사용자가 삭제되거나 인증 문제로 인해 잠기거나 역할이 제거될 때 발생할 수 있는 복잡성을 방지합니다.

작업 실행은 사용자와 분리되기 때문에 작업 실행에 대한 쿼리 기록은 시스템 서비스와 연결됩니다. 따라서 이 서비스에는 사용자 자격 증명이 없으며, 어떤 개인도 이 서비스의 ID를 추정할 수 없습니다. 시스템 서비스에 대한 활동은 사용자의 계정으로 제한됩니다. 다른 작업에 적용되는 것과 동일한 암호화 보호 및 기타 보안 프로토콜이 이 서비스에 내장되어 있습니다.