Snowflakeリリース¶

Snowflakeは、ユーザーにシームレスで常に最新のエクスペリエンスを提供すると同時に、迅速な開発と継続的な革新を通じて価値を高め続けています。

このコミットメントを満たすために、毎週新しいリリースを展開しています。これにより、サービスの改善を定期的に新機能、機能強化、修正の形で提供できます。展開はバックグラウンドで透過的に行われます。ユーザーはダウンタイムやサービスの中断を経験せず、常に最新機能にアクセスできる最新のリリースで実行できます。

このトピックでは、追加のリリーステスト（必要な場合）を有効にするために、Enterprise EditionおよびBusiness Critical Editionアカウント向けの12時間前の早期アクセス、またはVirtual Private Snowflake（VPS）アカウント向けの24時間前の早期アクセスをリクエストするオプションを含む、週次リリースで従うプロセスについて説明します。

このトピックの内容:

リリースタイプ（週次）¶

Snowflakeは毎週、2つの計画/スケジュールされたリリースを展開します。

総合リリース:

総合リリースには、次のいずれかが含まれる場合があります。

新機能
機能の強化または更新
修正
動作の変更（このトピック内の次のセクションを参照）

さらに、総合リリースには、週サイクルごとに更新されたSnowflakeリリースノートのドキュメントが含まれます。新着情報をご参照ください。

総合リリースは、営業時間外に発生する可能性のある問題を軽減するために通常は総合リリースを計画していない金曜日を除き、どの曜日でも展開できます。

パッチリリース:

パッチリリースには修正のみが含まれます。特定の週に予定/計画されたパッチリリースは、その週の総合リリースが遅れたり延長されたりする場合、キャンセルされる可能性があることに注意してください。

さらに、発生した問題に対処するために、総合リリース中または完了後にパッチリリースが（必要に応じて）展開されます。

動作の変更（月次）¶

毎月（11月と12月を除く）、Snowflakeはその月における毎週の総合リリースの1つを選択して、動作の変更を導入します。動作変更のために選択される週次リリースは異なる場合がありますが、通常はその月の3回目または4回目のリリースです。

動作の変更は、以前とは異なる結果を返し、顧客のコードまたはワークロードに影響を与える可能性がある、既存の動作に対する変更として定義されます。動作の変更は、次の命名規則を利用するバンドルで提供されます。

YYYY_NN

YYYY は年、 NN は年内のリリースの序数です。たとえば、 2022_06 は、2022年に導入された6番目の動作変更バンドルです。

詳細については、動作変更の管理をご参照ください。

バンドルのライフサイクル¶

動作変更バンドルのライフサイクルは、次の2つの期間で構成されます。

テスト期間（1か月目）:: バンドルは「デフォルトで無効」として導入されます。この期間中、1つまたは複数のアカウントでバンドルを 有効にする ことができます。通常、実稼働アカウントに影響を与えずに変更をテストできるように、開発用または QA （品質保証）用に指定されたアカウントを選択します。
オプトアウト期間（2か月目）:: バンドルは、「デフォルトで無効」から「デフォルトで有効」に移行します。この期間中は、アカウントでバンドルを 無効にする ことができます。これにより、変更の影響を軽減するために必要な調整を行いながら、通常は実稼働アカウントのバンドルの変更を延期できます。

これら2つの期間中、Snowflakeは特定のバンドルの設定を上書きしません。たとえば、テスト期間中にバンドルを無効にした場合は、オプトアウト期間の開始時に有効にはなりまません。

オプトアウト期間の終了時に、Snowflakeはすべてのアカウントでバンドルの動作変更を有効にします。この時点で、バンドルは「一般的に有効」と見なされます。これ以降、バンドルを有効または無効にすることはできません。ただし、 Snowflakeサポートに連絡して、バンドル内の個々の動作変更を一時的に無効にするようリクエストすることはできます。

動作変更のドキュメント¶

動作変更バンドルを含むリリースには、次のドキュメントが含まれます（リリースのリリースノートに加えて）:

今後予定されている、および最近実施された、バンドル化された変更の一覧。動作変更ログをご参照ください。
各動作変更の説明。各バンドルのランディングページには、動作変更が記載されています。
今後予定されている、および最近実施された、バンドル化されていない変更の一覧。バンドル化されていない動作変更をご参照ください。

プレリリーステスト/検証¶

Snowflakeでは、リリース品質を最優先事項とします。各リリースを展開する前に、以下を含む包括的な検証テスト一式を実行します。

定期的なビルドテスト。
継続的なワークロードとパフォーマンスのテスト。

さらに、顧客アカウントをリリースに移行する前に、次の検証を実行します。

サポートされているすべてのクラウドプラットフォームにわたる、内部アカウントでの包括的な回帰テスト。
リリースの変更によって影響を受ける可能性が最も高いワークロードに焦点を当てて、影響を受ける顧客のワークロード（顧客データに対するクエリなど）の実行をシミュレーション。

段階的リリースプロセス¶

総合リリースが展開されると、Snowflakeはアカウントすべてを同時にはリリースに移行しません。アカウントは、複数日にわたって3段階のアプローチを使用してリリースに移行されます。アカウントは、 Snowflake Edition に基づいて、次の順序で総合リリースに移行されます。

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サポートに通知してください。Snowflakeサポートは、他のアカウントを混乱させないように協力することができます。

Tip

早期アクセスは、Enterprise Editionのアカウントを持つすべての組織にとって必須または推奨されるとは限りません。Snowflakeの厳格なリリーステストと展開中のモニタリングは、通常、ほとんどの問題を防ぐのに十分です。早期アクセスは主に、実稼働アカウントが総合リリースの影響を受けないことを確認したい組織を対象としています。