Snowflake 릴리스

Snowflake 릴리스 (Snowflake releases)

Snowflake는 사용자에게 매끄럽고 항상 최신 상태인 경험을 제공하면서도, 빠른 개발과 지속적인 혁신을 통해 점점 더 많은 가치를 전달하는 것을 목표로 해요. 이를 위해 매주 새 릴리스를 배포해요. 이렇게 하면 새 기능, 개선, 수정이라는 형태의 서비스 개선을 정기적으로 전달할 수 있어요. 배포는 백그라운드에서 투명하게 진행돼서, 사용자는 다운타임이나 서비스 중단을 겪지 않으면서 항상 가장 최신 릴리스에서 최신 기능에 접근할 수 있어요.

이 문서는 일일 및 주간 릴리스를 위해 따라가는 절차를 설명해요. 원하면 Enterprise Edition 이상 계정에서 24시간 조기 액세스를 요청해 추가 릴리스 테스트를 진행할 수도 있어요.

출처: Snowflake releases

본문

릴리스 유형 (일일 및 주간)

Snowflake는 매주 두 번의 계획된 전체 릴리스(full release)를 배포해요:

일일 릴리스 (Daily release): Early Access 계정에만 배포돼요.
주간 릴리스 (Weekly release): 모든 고객 계정에 배포돼요.
전체 릴리스 (Full release): 전체 릴리스에는 다음 중 무엇이든 포함될 수 있어요.
- 새 기능
- 기능 개선 또는 업데이트
- 수정
- 동작 변경 (이 문서의 다음 섹션 참고)
또한 전체 릴리스에는 주간 릴리스 주기에 맞춰 갱신된 Snowflake 릴리스 노트 문서가 포함돼요. Snowflake 서버 릴리스 노트 및 기능 업데이트를 참고하세요.
패치 릴리스 (Patch release): 패치 릴리스에는 수정 사항만 포함돼요. 패치 릴리스는 전체 릴리스가 진행되는 동안 또는 완료된 후, 발생하는 문제를 해결하기 위해 필요에 따라 배포돼요.

동작 변경 (월간)

Snowflake는 매달 — 11월과 12월을 제외하고 — 그 달의 주간 전체 릴리스 중 하나를 골라 동작 변경(behavior change)을 도입해요. 동작 변경을 위해 선택되는 주간 릴리스는 달라질 수 있지만, 보통 그 달의 3번째 또는 4번째 릴리스예요.

동작 변경이란 기존 동작에 대한 변경으로, 이전과 다른 결과를 반환하고 고객 코드나 워크로드에 영향을 줄 수 있는 변경을 뜻해요. 동작 변경은 다음의 명명 규칙을 사용하는 번들로 제공돼요:

YYYY_NN

여기서 YYYY는 연도이고, NN은 그 해의 릴리스 순번이에요. 예를 들어 2022_06은 2022년에 도입된 6번째 동작 변경 번들이에요. 자세한 내용은 동작 변경 관리를 참고하세요.

번들 수명 주기 (Bundle lifecycle)

동작 변경 번들의 수명 주기는 다음 두 기간으로 구성돼요:

테스트 기간 (1개월): 번들이 "기본 비활성(Disabled by Default)" 상태로 도입돼요. 이 기간 동안 하나 이상의 계정에서 번들을 활성화할 수 있어요. 보통 개발 또는 QA(품질 보증)용으로 지정된 계정을 선택해서 프로덕션 계정에 영향을 주지 않고 변경 사항을 테스트할 수 있어요.
옵트아웃 기간 (2개월): 번들이 "기본 비활성"에서 "기본 활성(Enabled by Default)"으로 전환돼요. 이 기간 동안 계정에서 번들을 비활성화할 수 있어요. 보통 프로덕션 계정에서 변경 사항을 연기하고, 변경 영향 완화를 위한 필요한 조정을 할 수 있게 해줘요.

이 두 기간 동안 Snowflake는 주어진 번들에 대한 설정을 덮어쓰지 않아요. 예를 들어 테스트 기간에 번들을 비활성화했다면, 옵트아웃 기간이 시작될 때 자동으로 활성화되지 않아요.

옵트아웃 기간이 끝나면 Snowflake는 모든 계정에 걸쳐 번들의 동작 변경을 활성화하며, 이 시점부터 번들은 "일반 활성(Generally Enabled)"으로 간주돼요. 이때부터 번들을 활성화하거나 비활성화할 수 없어요. 다만 Snowflake Support에 연락해 번들 내 개별 동작 변경을 임시로 비활성화하도록 요청할 수는 있어요.

동작 변경 문서

동작 변경 번들을 포함하는 릴리스에는 (릴리스의 릴리스 노트 외에) 다음 문서가 포함돼요:

예정되었거나 최근 구현된 번들 변경 목록. 동작 변경 공지 참고.
각 동작 변경에 대한 설명. 동작 변경은 각 번들의 랜딩 페이지에 나열돼요.
예정되었거나 최근 구현된 번들되지 않은 변경 목록. 번들되지 않은 동작 변경 참고.

릴리스 전 테스트 및 검증

Snowflake에서 릴리스 품질은 최우선 순위예요. 각 릴리스가 배포되기 전에 다음을 포함한 전체 검증 테스트 세트를 거쳐요:

정기 빌드 테스트.
지속적인 워크로드 및 성능 테스트.

또한 고객 계정이 릴리스로 이동되기 전에 다음 검증이 수행돼요:

지원되는 모든 클라우드 플랫폼에서 내부 계정에 대한 전체 회귀 테스트.
영향을 받을 가능성이 높은 선택된 고객 워크로드(예: 고객 데이터에 대한 쿼리)의 실행 시뮬레이션. 릴리스의 변경 사항에 가장 영향을 받을 것으로 예상되는 워크로드에 초점을 맞춰요.

단계적 릴리스 프로세스

전체 릴리스가 배포된 후 Snowflake는 모든 계정을 동시에 릴리스로 옮기지 않아요. 계정은 여러 날에 걸친 다단계 방식으로 릴리스로 이동돼요. 계정은 Snowflake Edition에 따라 다음 순서로 전체 릴리스로 이동돼요:

1단계: 지정된 Enterprise (이상) 계정을 위한 (조기 액세스, early access).
2단계: Standard 계정을 위한 (일반 액세스, regular access).
3단계: Enterprise (이상) 계정을 위한 (후기 액세스, late access).
4단계: Enterprise (이상) 계정을 위한 (최종 안정 액세스, final stable access).

일반적으로 조기 액세스와 최종 단계 사이의 최소 시간은 48시간이지만, 더 길어질 수도 있어요. 이 단계적 방식 덕분에 Snowflake는 계정이 이동될 때 활동을 모니터링하고 발생할 수 있는 문제에 대응할 수 있어요. 또한 Enterprise 계정을 조기 액세스 테스트용으로 지정할 수도 있어요 (이 문서의 다음 섹션 참고).

참고: 이 단계적 방식은 전체 릴리스에만 적용돼요. 패치 릴리스의 경우 모든 계정이 같은 날 이동돼요.

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

전체 릴리스 조기 액세스

Enterprise Edition (이상) 계정이 여러 개 있다면, 그중 하나 이상의 계정을 조기 액세스로 지정해 전체 릴리스의 조기 액세스와 최종 단계 사이의 기간을 활용할 수 있어요. 개발/테스트용과 프로덕션용 계정을 분리해 운영한다면 특히 유용해요.

계정을 조기 액세스로 지정하려면 Snowflake 계정 담당자에게 문의하세요.

계정을 조기 액세스로 지정한 후에는 다음과 유사한 테스트 프레임워크를 구현할 수 있어요:

CURRENT_VERSION(또는 유사한 결과를 반환하는 UDF)을 사용해 조기 액세스 계정이 전체 릴리스에 있는지 확인해요.
조기 액세스 계정을 사용해 프로덕션 워크로드를 전체 릴리스에 대해 테스트해요.
문제가 발생하면 Snowflake Support에 알리면, 그들이 문제가 다른 계정에 영향을 주지 않도록 함께 해결해줘요.

팁: 모든 Enterprise Edition 계정을 가진 조직에 조기 액세스가 필요하거나 권장되는 건 아니에요. Snowflake의 엄격한 릴리스 테스트와 배포 중 모니터링은 대부분의 문제를 방지하기에 보통 충분해요. 조기 액세스는 주로 프로덕션 계정이 전체 릴리스의 영향을 받지 않을 것이라는 추가적인 확신을 원하는 조직을 위한 것이에요.

Snowflake 릴리스