サービスでのSnowflakeステージボリュームの使用¶
注釈
Snowflakeステージボリュームをサービスで使用することは、現在Google Cloudのアカウントではご利用いただけません。
Snowflakeは、内部ステージ、ローカルストレージ、メモリストレージ、ブロックストレージボリュームなど、アプリケーションコンテナー用に、 various storage volume types をサポートしています。このセクションでは、内部ステージ用にボリュームとボリュームマウントを構成する方法を説明します。
ステージ・ボリュームは、FileSystemAPIs を使用して内部ステージにアクセスするためのサービスを提供します。Snowflake ドライバーと GET および PUTSQL コマンドを使用するのに比べてコードを簡素化します。。
ステージボリュームは、大きなデータファイルのストリーミング読み取りや書き込みを行うシナリオの場合に、よりパフォーマンスを向上させることもできます。ステージボリュームは、完全に機能するファイルシステムを期待するのではなく、ステージボリュームを便利な代替 API としてステージ用アプリケーションが使用する場合に最適に機能します。
現在、ステージボリュームには、一般に利用可能なバージョンと、現在プレビュー中の新しいバージョンの2つの実装があります。
新しいステージ・ボリュームの実装について¶
一般的に利用可能なステージボリュームの実装では、読み取りと書き込みに共有キャッシュを使用します。これは一部のシナリオではうまく機能しますが、キャッシュから、またはステージから直接、データを読み込むことは制御できません。これはすべてのアプリケーションに適しているとは限りません。さらに、キャッシュを読み取りと書き込みに使用すると、パフォーマンスのオーバーヘッドが発生する可能性があります。
現在プレビュー中の新しいステージボリュームの実装では、限られたインメモリキャッシュのみを使用します。これにより、より予測可能な動作と、スループットの大幅な向上が実現します。このバージョンは、最終的には現在の一般公開されている 実装を置き換えます。ワークロードにランダムな書き込みやファイルの追加が必要な場合を除き、Snowflakeはこのプレビューバージョンを評価することを推奨します。
新しいステージボリュームの実装を使用する場合は、以下の追加考慮事項に注意してください:
大規模な連続読み取りおよび書き込み用に最適化されており、これらのアクセスパターンに強力なパフォーマンスを提供します。最良の結果を得るには、大きな連続したチャンクでデータを読み書きします。
キャッシュの削除により、新しい実装ではランダム読み取りのパフォーマンスが低下する可能性があります。ただし、ローカルディスクキャッシュがないと、ボリューム間の一貫性が向上します。ファイルの変更は、ファイルが閉じられると、ローカルディスクのバッファーなしでバックステージに直接書き込まれます。
読み取りは常に最新のデータを返すため、この構成はサービス間でデータを共有するのに適しています。
ランダム書き込みやファイル追加はサポートされていません。これらの操作を試行すると、エラーが発生します。
サービス仕様でSnowflakeステージボリュームを指定します¶
サービスコンテナがSnowflakeステージボリュームを使用するサービスを作成するには、以下のステップに示すように、サービス仕様で必要な設定を指定します。
ステージボリュームを指定するには、
spec.volumes
フィールドを使用します。次の例に示すように、ステージボリューム実装の一般的に利用可能なバージョンを使用します:
volumes: - name: <name> source: <stage_name>
以下のフィールドは必須です。
name
: ボリュームの名前。source
:搭載するSnowflake内部ステージまたはステージ上のフォルダー。例えば@my_stage
,@my_stage/folder
。この値は引用符で囲む必要があります。
次の例に示すように、ステージボリューム実装の新しいプレビューバージョンを使用します。
volumes: - name: <name> source: stage stageConfig: name: <stage_name>
以下のフィールドは必須です。
name
: ボリュームの名前。source
:ボリュームのタイプを識別します(stage
)。stageConfig
:マウントするステージ上のSnowflake内部ステージまたはフォルダーを識別します。例えば@my_stage
,@my_stage/folder``または ``@my_db.my_schema.my_stage/folder/nestedfolder
。この値は二重引用符で囲む必要があります。
spec.containers.volumeMounts
フィールドを使用して、アプリケーション・コンテナーのステージ・ボリュームをマウントする場所を次の例に示すように記述します:volumeMounts: - name: <name> mountPath: <absolute_directory_path>
このフィールドに入力する情報は、サポートされるすべてのストレージボリュームタイプで一貫しており、ステージボリュームの両方の実装に適用されます。
例¶
この例では、既存のステージボリュームと新しいステージボリュームを使用してSnowflakeステージをマウントする場合の違いを示します。サービス仕様の例では、 app
コンテナが既存および新しいステージ @model_stage
ボリュームの実装の両方を使用することによって内部ステージをマウントします。
@model-legacy
ステージボリューム構成は、ステージボリュームの一般的に利用可能な実装を使用するようにSnowflakeに指示します。@model-new
ステージボリューム構成では、stageConfig
Snowflakeにステージボリュームのプレビュー実装を使用するよう指示するフィールドを指定します。
spec:
containers:
- name: app
image: <image1-name>
volumeMounts:
- name: models-legacy
mountPath: /opt/model-legacy
- name: models-new
mountPath: /opt/model-new
volumes:
- name: models-legacy
source: "@model_stage"
- name: models-new
source: stage
stageConfig:
name: "@model_stage"
volumeMounts
フィールドは、ステージ・ボリュームをマウントするコンテナ内の場所を指定します。この仕様は、両方のステージ・ボリュームの実装で同じままです。
アクセス制御の要件¶
サービス所有者ロールは、サービスを作成するために使用されるロールです。また、サービスがSnowflakeとやりとりする際に使用するロールでもあります。所有者ロールは、マウントされたステージへのアクセス向けとしてコンテナーに付与される権限を決定します。サービスの所有者ロールには、ステージ上で READ 権限が必要です。
たとえば、ステージでサービスロールが WRITE 権限を持っていない場合、そのステージのマウントは読み取り専用になります。つまり、コンテナーができるのはステージからファイルを読み取ることのみです。所有者ロールが読み取りと書き込みの両方をサポートするステージ・マウントには、ステージ上で WRITE 権限が必要です。
ステージボリュームを使用する際のガイドライン¶
このセクションでは、コンテナーがステージボリュームを使用するアプリケーションコードを実装するときに従うべきガイドラインを提供します。
ステージ・ボリュームの両方の実装の共通ガイドライン¶
ステージ・マウントはシーケンシャルな読み書きに最適化されています。
ステージ・マウントのI/O操作は、コンテナーのファイル・システムやブロック・ストレージ・ボリュームのI/O操作よりも待機時間が高くなる可能性があります。I/O操作が成功したかどうかを確認するために、常にステータスコードをチェックすべきです。
ステージは、アップロードファイルの更新を非同期にマウントします。ステージ・マウント上のファイルへの変更は、ファイル・ディスクリプターが正常にクローズまたはフラッシュされた後にのみ、ステージに永続化されることが保証されます。ステージマウント上のファイルへの変更が他のコンテナーやSnowflakeから見えるようになるまで、多少の遅延が発生する場合があります。
マウントされたステージの各ディレクトリに含まれるファイルは、100,000個以下である必要があります。ディレクトリ内のファイル数に応じて
readdir
待機時間が長くなることが予想されます。
ステージボリューム実装の一般公開バージョンを使用する場合のガイドライン¶
ステージ・マウント内で複数のファイルへの同時書き込みを避けます。
ステージ・マウントはネットワーク・ファイルシステムではありません。マルチクライアントの調整にステージマウントを使わないでください。
同じファイルへの複数のハンドルを同時に開かないでください。オープンされたファイル・ハンドルは、読み取り操作か書き込み操作のどちらかに使用します。ファイルに書き込んだ後、そのファイルから読み込むには、読み込む前に一旦ファイルを閉じ、再度ファイルを開きます。
ステージボリューム実装の新しいプレビューバージョンを使用する際のガイドライン¶
複数のステージマウント(異なるコンテナーにマウントされた同じステージボリューム)から同じファイルへの同時書き込みはサポートされていません。
ローカルディスクキャッシュがないため、マウント間の一貫性が向上します。ファイルの変更は、ファイルを閉じると、ローカルディスクのバッファーなしでバックステージに直接フラッシュされます。読み取りは常に最新のデータを返すため、新しいステージ・マウントはサービス間でデータを共有するのに適しています。
最適なパフォーマンスのため、大きな連続したチャンクでデータを読み書きします。 一般に利用可能なステージボリュームの実装と比較して、小規模な読み取りおよび書き込みのパフォーマンスコストは、新しい実装によるパフォーマンス向上を軽減することができます。
ステージボリュームを使用する際の制限事項¶
このセクションでは、コンテナーがステージボリュームを使用するアプリケーションコードを実装するときに注意すべき制限について説明します。これらの限度額に関する問題が発生した場合は、アカウント担当者にお問い合わせください。
ステージボリュームの両方の実装における共通の制限¶
ステージまたはサブディレクトリをステージでマウントすることができます。例: @my_stage
@my_stage/folder
.例えば、@my_stage/folder
のように、1つのファイルを1つのステージにマウントすることはできません。外部ステージはサポートされていません。Snowflake内部ステージのみがサポートされています。
1つのサービスにつき最大5つのステージ・ボリュームを使用できます。詳細については、spec.volumes をご参照ください。
コンピューティングプールノードあたり最大8ステージボリュームがサポートされています。Snowflake は、メモリ、 CPU、 GPU を管理する方法と同様に、ノードごとのステージマウントの制限を管理します。新しいサービスインスタンスを起動すると、既存のノードにリクエストされたステージマウントをサポートする容量がない場合に、Snowflakeが新しいノードを起動することがあります。
ステージマウントは、 POSIX 互換性のあるファイルシステムではありません。例:
ファイル名とディレクトリ名の変更はアトミックではありません。
ハードリンクはサポートされていません。
ファイルシステムの変更を監視する Linux カーネルサブシステムの inode notify(
inotify
) は、ステージマウントでは動作しません。
ステージ・ボリューム実装の一般公開バージョンを使用する場合の制限事項¶
ステージボリュームの機能は、Snowflakeアカウントのクラウドプラットフォームによって異なります:
アカウントは、SNOWFLAKE_FULL および SNOWFLAKE_SSE ステージ暗号化の両方に対応する内部ステージを AWS でサポートします。詳細については、内部ステージパラメーター をご参照ください。
Azure 上のアカウントは現在、SNOWFLAKE_SSE 暗号化の内部ステージをサポートしています。SNOWFLAKE_SSE を実行する場合は、 :doc:` パラメーターを使用して暗号化タイプを指定します。 CREATE
Google Cloud上のアカウントはサポートされていません。
複数のステージマウント(異なるコンテナーにマウントされた同じステージボリューム)から同じファイルへの同時書き込みはサポートされていません。
ステージ・ボリューム実装の新しいプレビュー・バージョンを使用する際の制限事項¶
ステージボリュームの機能は、Snowflakeアカウントのクラウドプラットフォームによって異なります:
AWS のアカウントは、SNOWFLAKE_FULL および SNOWFLAKE_SSE ステージ暗号化の両方で内部ステージをサポートします(詳細は :ref:`内部ステージパラメーター <label-create_stage_internalstageparams>`を参照してください)。
AzureおよびGoogle Cloudのアカウントは現在、SNOWFLAKE_SSE 暗号化の内部ステージをサポートしています。 を実行する場合は、 :doc:` パラメーターを使用して暗号化タイプを指定します。 CREATE
ランダム書き込み、ファイル追加はサポートされていません。
マウントされる各ステージには、ステージごとに512 MB メモリが必要です。つまり、インスタンスのサイズに応じて使用できるステージボリュームの数に制限があることを意味します。複数のコンテナにボリュームをマウントしても、メモリ消費が増加することはありません。