Snowflake 릴리스¶

Snowflake는 사용자에게 원활하고 항상 최신 상태의 경험을 제공하는 동시에 신속한 개발과 지속적인 혁신을 통해 지속적으로 더 많은 가치를 제공하기 위해 최선을 다하고 있습니다.

이러한 노력을 위해 매주 신규 릴리스가 배포됩니다. 이를 통해 Snowflake는 서비스 개선 사항을 새로운 기능, 개선 사항 및 수정 사항의 형태로 정기적으로 제공할 수 있습니다. 배포는 백그라운드에서 투명하게 수행되며, 사용자는 다운타임이나 서비스 중단 없이 항상 최신 기능에 액세스하여 최신 릴리스에서 작업을 수행할 수 있습니다.

이 항목에서는 추가 릴리스 테스트(원하는 경우)를 활성화하기 위해 Enterprise Edition 및 Business Critical Edition 계정에 대한 12시간 조기 액세스 또는 Virtual Private Snowflake(VPS) 계정에 대한 24시간 조기 액세스를 요청하는 옵션 등 주간 릴리스에 대해 따라야 하는 프로세스에 대해 설명합니다.

이 항목의 내용:

릴리스 타입(주간)¶

Snowflake는 매주 2개의 예정/예약 릴리스를 배포합니다.

전체 릴리스:

전체 릴리스에 포함되는 사항은 다음과 같습니다.

새로운 기능
기능 개선 또는 업데이트
수정 사항
동작 변경(이 항목의 다음 섹션 참조)

또한 전체 릴리스에는 주간 주기별로 업데이트된 Snowflake 릴리스 정보 설명서가 포함됩니다. 새로운 기능 섹션을 참조하십시오.

정식 릴리스는 주중에 배포할 수 있지만, 영업 시간이 아닐 때 발생할 수 있는 문제로 인한 곤란을 완화하기 위해 통상적으로 금요일에는 정식 릴리스 배포를 계획하지 않습니다.

패치 릴리스:

패치 릴리스에는 수정 사항만 포함됩니다. 어떤 주에 정식 릴리스가 너무 지연되거나 연장되는 경우에는 그 주에 예정/계획된 패치 릴리스를 취소할 수도 있습니다.

또한, 발생하는 모든 문제를 적시에 다룰 수 있도록 정식 릴리스 완료 도중이나 이후에 (필요에 따라) 패치 릴리스를 배포합니다.

동작 변경(월간)¶

Snowflake는 (11월과 12월은 제외하고) 매달 그 달의 주간 정식 릴리스 중 하나를 선택하여 동작 변경을 도입합니다. 동작 변경에 대해 선택되는 주간 릴리스는 다를 수 있지만, 일반적으로 해당 월의 세 번째 또는 네 번째 릴리스입니다.

동작 변경은 이전과는 다른 결과를 반환하고 고객 코드 또는 워크로드에 영향을 미칠 수 있는 기존 동작에 대한 모든 변경으로 정의됩니다. 동작 변경은 다음 명명 규칙을 활용하는 번들로 제공됩니다.

YYYY_NN

여기서 YYYY 는 연도이고 NN 은 해당 연도에서 릴리스의 순서를 나타내는 서수입니다. 예를 들어 2022_06 은 2022년에 도입된 6번째 동적 변경 번들입니다.

자세한 내용은 동작 변경 관리 섹션을 참조하십시오.

번들 수명 주기¶

동작 변경 번들 수명 주기는 다음 두 기간으로 구성됩니다.

테스트 기간(첫 번째 달):: 이 번들은 “기본적으로 비활성화된” 상태로 도입됩니다. 이 기간 중에 하나 이상의 계정에서 번들을 활성화 하도록 선택할 수 있습니다. 일반적으로, 프로덕션 계정에 영향을 주지 않고 변경 사항을 테스트할 수 있도록 개발 또는 QA(품질 보증)용으로 지정된 계정을 선택합니다.
옵트아웃 기간(두 번째 달):: 번들이 “기본적으로 비활성화됨”에서 “기본적으로 활성화됨”으로 이동합니다. 이 기간 중에 자신의 계정에서 번들을 비활성화 하도록 선택할 수 있습니다. 이를 통해 일반적으로 프로덕션 계정에 대해 번들에서 변경을 연기하는 동시에 변경의 영향을 완화하는 데 필요한 모든 조정 작업을 수행할 수 있습니다.

이 두 기간 중에 Snowflake는 주어진 번들에 대한 설정을 재정의하지 않습니다. 예를 들어 테스트 기간 중에 번들을 비활성화하면 옵트아웃 기간이 시작될 때 번들을 활성화하지 않습니다.

옵트아웃 기간이 종료되면 Snowflake는 모든 계정에 걸쳐 번들의 동작 변경을 활성화하며, 이때 번들은 “일반적으로 활성화된” 것으로 간주됩니다. 이 시점 이후로는 번들을 활성화하거나 비활성화할 수 없습니다. Snowflake 지원 에 연락하여 번들에서 개별 동작 변경을 여전히 일시적으로 비활성화하도록 요청할 수 있습니다.

동작 변경 설명서¶

동작 변경 번들이 있는 릴리스는 (릴리스에 대한 릴리스 정보 외에) 다음 설명서를 포함합니다.

예정된 변경 사항과 최근에 구현되어 번들로 제공되는 변경 사항 목록입니다. 동작 변경 로그 섹션을 참조하십시오.
각 동작 변경에 대한 설명입니다. 동작 변경 사항은 각 번들의 랜딩 페이지에 나열됩니다.
예정된 변경 사항과 최근에 구현되어 번들로 묶이지 않은 변경 사항 목록입니다. 번들로 제공되지 않는 동작 변경 사항 섹션을 참조하십시오.

릴리스 전 테스트/유효성 검사¶

Snowflake는 릴리스 품질을 최우선으로 생각합니다. 각 릴리스는 배포되기 전 다음과 같은 모든 유효성 검사 단계를 거칩니다.

일반 빌드 테스트.
연속 워크로드 및 성능 테스트.

또한, 고객 계정이 릴리스로 이동되기 전에 수행되는 유효성 검사는 다음과 같습니다.

지원되는 모든 클라우드 플랫폼에서 내부 계정에 대한 전체 회귀 테스트.
릴리스 변경의 영향을 가장 많이 받는 워크로드 중심의 영향을 받는 고객 워크로드(예: 고객 데이터 쿼리) 실행 시뮬레이션.

스테이징된 릴리스 프로세스¶

전체 릴리스 배포 이후에 Snowflake가 모든 계정을 동시에 릴리스로 이동하는 것은 아닙니다. 계정은 여러 날에 걸쳐 3단계 방식을 통해 릴리스로 이동됩니다. 계정은 Snowflake 에디션 에 따라 다음의 순서로 전체 릴리스로 이동됩니다.

1일차:: 지정된 Enterprise 이상 계정에 대한 1단계(조기 액세스).
1일차 또는 2일차:: Standard 계정에 대한 2단계(일반 액세스).
2일차:: Enterprise 이상 계정에 대한 3단계(최종).

일반적으로 조기 액세스와 최종 단계 사이의 최소 시간은 Snowflake Edition에 따라 12~24시간이지만, 더 짧거나 더 길 수 있습니다. 이러한 단계적 접근 방식을 통해 Snowflake는 계정 이동 시 활동을 모니터링하고 발생할 수 있는 모든 문제에 대응할 수 있습니다. 또한, 얼리 액세스 테스트를 위해 Enterprise 계정을 지정할 수도 있습니다(이 항목의 다음 섹션 참조).

참고

이러한 단계별 방식은 전체 릴리스에만 적용됩니다. 패치 릴리스의 경우에는 모든 계정이 같은 날짜에 이동됩니다.

또한, 계정을 전체 릴리스 또는 패치 릴리스로 이동하는 동안 문제가 발견되면 릴리스가 중단되거나 롤백될 수 있습니다. 대부분의 경우 중단/롤백된 릴리스에 대한 후속 릴리스가 24~48시간 이내에 완료됩니다.

전체 릴리스에 조기 액세스¶

Enterprise Edition 이상 계정이 여러 개인 경우 이러한 계정 중 1개 이상을 얼리 액세스로 지정하여 정식 릴리스에서 얼리 액세스와 최종 단계 사이의 기간을 활용할 수 있습니다. 이러한 시간은 개발/테스트 및 프로덕션에서 사용하기 위해 별도의 계정을 유지 관리하는 경우에 특히 유용할 수 있습니다.

조기 액세스용 계정을 지정하려면 Snowflake 계정 담당자에게 문의하십시오.

얼리 액세스 계정을 지정한 이후에는 다음과 유사한 테스트 프레임워크를 구현할 수 있습니다.

CURRENT_VERSION (또는 유사한 결과를 반환하는 UDF)을 사용하여 얼리 액세스 계정이 정식 릴리스에 있는지 확인합니다.
얼리 액세스 계정을 사용하여 정식 릴리스에 대한 프로덕션 워크로드를 테스트합니다.
문제가 발생하면 Snowflake 지원 에 알려주십시오 그러면 다른 계정에 지장을 주지 않고 문제를 방지할 수 있도록 도움을 드립니다.

팁

Enterprise Edition 계정이 있는 모든 조직에게 조기 액세스가 필요하거나 권장되는 것은 아닙니다. 배포 중 Snowflake는 엄격한 릴리스 테스트 및 모니터링을 수행하여 일반적으로 대부분의 문제를 방지할 수 있습니다. 조기 액세스는 프로덕션 계정이 전체 릴리스의 영향을 받지 않음을 추가적으로 확인하려는 조직에게 적합합니다.