Streamlit in Snowflake で PrivateLink 構成時のアカウント固有 URL を試してみた
はじめに
Snowflake の PrivateLink 構成時における、Snowflake ホスト型アプリサービスにおけるアカウント固有の URL（Per-Account URL）の設定時の挙動を確認した際の内容を記事としました。
本機能の概要
本機能については以下に記載があります。
上記の Snowflake 社のブログにあるように、以前は PrivateLink 構成時の Snowflake ホスト型アプリサービスのアクセス URL は「region-scoped model」と呼ばれる形式でした。記事では以下のように説明されています。
The previous region-scoped model required a wildcard CNAME like
*.abc123.privatelink.snowflake.app, which offered a single CNAME that was not account specific.
つまり、*.<identifier>.privatelink.snowflake.appのようなホスト名がクラウドプロバイダー・リージョン単位で共通の値として割り当てられており、アカウント固有のものではありませんでした。この形式では、ファイアウォールの許可設定で広めのワイルドカードが必要になることに加え、同一組織内で複数アカウントが同一クラウド・リージョンにある場合に DNS の名前空間が重複してしまい、特定のアカウントだけにトラフィックを制限したり、他アカウントのアプリサービスへのアクセスを防いだりすることが難しいという課題がありました。
この件は、以下の記事でも紹介されています。
現在は、この共通のホスト名に代えて、アカウントごとに一意な URL（<app-id>.<orgname>-<accountname>.<region>.<cloud>.privatelink.snowflake.app）を発行できるようになりました。これにより、アカウントごとにネットワークの境界を分離でき、DNS の名前空間の重複も解消されます。具体的には、以下のパラメータ・関数が提供されています。
- ENABLE_PER_ACCOUNT_APP_SERVICE_PRIVATELINK_URL
- 有効化すると、PrivateLink 経由でアクセスするアプリサービスの URL が、アカウント固有の形式で払い出されるようになる
- SYSTEM$ISSUE_PER_ACCOUNT_APP_SERVICE_CERTIFICATE
- アカウント固有 URL 用の TLS 証明書を発行するための関数
試してみる
前提条件
以下の環境を使用しています。
- Snowflake
- エディション：Business Critical
- クラウドサービス：AWS
- リージョン：ap-northeast-1
また、検証開始時点で、共通の識別子を使った従来形式の URL（*.<identifier>.privatelink.snowflake.app）経由でアプリにアクセスできることを前提とします。
アカウント固有 URL パラメータの有効化
ENABLE_PER_ACCOUNT_APP_SERVICE_PRIVATELINK_URL パラメータの有効化前に、アカウント固有 URL 用の証明書を発行しておく必要があります。そのため、はじめに以下を実行しアカウント固有 URL 用の証明書を発行します。
SELECT SYSTEM$ISSUE_PER_ACCOUNT_APP_SERVICE_CERTIFICATE();
証明書の発行後、パラメータを有効化します。
ALTER ACCOUNT SET ENABLE_PER_ACCOUNT_APP_SERVICE_PRIVATELINK_URL = TRUE;
設定後、アプリを更新して表示しようとしたところ、アプリへアクセスできなくなりました。従来の共通 URL 向けに設定していた DNS では、このアカウント固有 URL の名前解決ができていないことが原因でした。
デプロイ後も同様です。
PrivateLink 環境側（DNS）の設定変更
アカウント固有 URL でアクセスするためには、クライアント側の名前解決（DNS）の設定も変更します。
Streamlit 向けの PrivateLink 構成時に、privatelink.snowflake.appのプライベートホストゾーンを作成していたので、ホストゾーン自体は新規作成の必要はなく、そのまま再利用できます。
このゾーンに対して、アカウント名を含んだワイルドカード CNAME レコードを追加します。レコード値も既存の VPC エンドポイントの DNS 名のままで問題ありません。
Snowflake でSYSTEM$GET_PRIVATELINK_CONFIGを実行します。出力の内、app-service-privatelink-urlキーの値を使用します。
SELECT SYSTEM$GET_PRIVATELINK_CONFIG();
関連する項目：
app-service-privatelink-url "*.<orgname>-<accountname>.ap-northeast-1.aws.privatelink.snowflake.app"
この値をもとに、Route 53 側にワイルドカード CNAME レコードを追加します。
動作確認
設定が完了後、再度 Streamlit in Snowflake のアプリにアクセスし、動作を確認すると問題なくアクセスでき、下図のようにアプリが表示されることを確認できました。
デプロイ後も同様に確認できました。
なお、Snowsight 上のアプリ共有リンク自体は、変更前後で変わらず実際にアクセスする際の内部的なアプリサービス URL が、今回の設定変更に応じて切り替わっている形のようです。
無効化した場合の挙動
一通り動作確認ができたところで、Route 53 側の旧来の共通 URL 用レコードを削除します。そのうえで改めてENABLE_PER_ACCOUNT_APP_SERVICE_PRIVATELINK_URLパラメータを無効化してみます。
ALTER ACCOUNT SET ENABLE_PER_ACCOUNT_APP_SERVICE_PRIVATELINK_URL = FALSE;
この状態でブラウザを更新すると、アプリが表示できなくなりました。以前の CNAME レコードを Route 53 から削除済みだったため、パラメータの無効化によって参照先が戻った結果、名前解決ができなくなったことが原因です。
SYSTEM$GET_PRIVATELINK_CONFIG の出力の変化
ENABLE_PER_ACCOUNT_APP_SERVICE_PRIVATELINK_URLパラメータの有効化前後で、SYSTEM$GET_PRIVATELINK_CONFIGの出力内容が変化することも確認できました。
パラメータが無効な状態（証明書は発行済み）では、app-service-privatelink-urlとapp-service-privatelink-url-nextの2つのキーが出力されます。
key value
app-service-privatelink-url "*.<identifier>.privatelink.snowflake.app"
app-service-privatelink-url-next "*.<orgname>-<accountname>.ap-northeast-1.aws.privatelink.snowflake.app"
app-service-privatelink-urlが現在有効な URL、app-service-privatelink-url-nextがパラメータ有効化後に切り替わる予定の URL、という関係になっているようです。
パラメータを有効化すると、app-service-privatelink-url-nextは出力されなくなり、app-service-privatelink-urlの値がアカウント固有 URL の形式に変わります。
key value
app-service-privatelink-url "*.<orgname>-<accountname>.ap-northeast-1.aws.privatelink.snowflake.app"
さいごに
Streamlit in Snowflake の PrivateLink 構成時における、アプリサービスのアカウント固有 URL 対応を試してみました。同一クラウド・リージョンに複数アカウントが存在する環境では恩恵の大きい機能と思います。
こちらの内容がどなたかの参考になれば幸いです。
