Snowflakeネイティブアプリで利用者が更新時間帯を制御

Snowflakeネイティブアプリで、アプリを利用する側が保守ポリシーを作成し、アップグレードを受け入れる時間帯をアカウント単位または個別アプリ単位で指定できる機能が一般提供になりました。

今回の更新で変わること

これまでアプリ提供者が新しいリリースディレクティブを公開すると、利用者側の重要な処理時間や変更凍結期間と更新時期が衝突する可能性がありました。今回の機能では、利用者が保守ポリシーを作り、アカウント全体または特定のSnowflakeネイティブアプリへ適用できます。月末集計、営業時間中の分析、規制対象の変更時間帯などを避け、アプリ更新を受け入れる枠を利用者側の運用計画へ合わせられます。一般提供になったため、本番利用を前提としたポリシー設計と変更手順を整備できます。

一方、利用者が時間帯を指定するだけでは、提供者側の更新が自動的にその指定へ従うとは限りません。アプリ提供者はリリースディレクティブでUPGRADE_IN_MAINTENANCE_WINDOWを設定し、利用者の保守ポリシーを尊重する必要があります。Snowpark Container Servicesを使うアプリでは、アプリケーションパッケージのAUTOMATIC_APPLICATION_MAINTENANCEを設定すると、コンピュートプールのノード保守も利用者の保守時間帯へ合わせられます。アプリのバージョン更新と基盤ノードの保守は対象が異なるため、どちらを制御しているのかを分けて確認する必要があります。

運用では、アカウントポリシーと個別アプリポリシーが重なる場合の優先順位、時間帯のタイムゾーン、更新を長期間受け入れなかった場合の扱いを確認しておきたいです。提供者は新旧バージョンの互換期間や緊急修正の配布方法を明示し、利用者は更新後の動作確認と切り戻し手順を保守枠へ組み込みます。セキュリティ修正まで通常の保守枠を待たせるのか、緊急時に別経路を使うのかも、利用者と提供者の双方で決める必要があります。

影響を受ける人

Snowflakeネイティブアプリを本番利用する管理者、アプリ更新を配布する提供者、Snowpark Container Servicesのコンピュートプールを運用するチームに関係します。

実務で確認したいこと

業務の停止可能時間を基に保守ポリシーを作り、検証用アプリで更新時刻を確認します。提供者は両パラメーターの設定状況、緊急更新、互換期間、更新失敗時の復旧方法を利用者へ示す必要があります。