サービスでのSnowflakeステージボリュームの使用

注釈

Snowflakeステージボリュームをサービスで使用することは、現在Google Cloudのアカウントではご利用いただけません。

Snowflakeは、内部ステージ、ローカルストレージ、メモリストレージ、ブロックストレージボリュームなど、アプリケーションコンテナー用に、 various storage volume types をサポートしています。このセクションでは、内部ステージ用にボリュームとボリュームマウントを構成する方法を説明します。

ステージ・ボリュームは、FileSystemAPIs を使用して内部ステージにアクセスするためのサービスを提供します。Snowflake ドライバーと GET および PUTSQL コマンドを使用するのに比べてコードを簡素化します。。

ステージボリュームは、大きなデータファイルのストリーミング読み取りや書き込みを行うシナリオの場合に、よりパフォーマンスを向上させることもできます。ステージボリュームは、完全に機能するファイルシステムを期待するのではなく、ステージボリュームを便利な代替 API としてステージ用アプリケーションが使用する場合に最適に機能します。

現在、ステージボリュームには、一般に利用可能なバージョンと、現在プレビュー中の新しいバージョンの2つの実装があります。

新しいステージ・ボリュームの実装について

一般的に利用可能なステージボリュームの実装では、読み取りと書き込みに共有キャッシュを使用します。これは一部のシナリオではうまく機能しますが、キャッシュから、またはステージから直接、データを読み込むことは制御できません。これはすべてのアプリケーションに適しているとは限りません。さらに、キャッシュを読み取りと書き込みに使用すると、パフォーマンスのオーバーヘッドが発生する可能性があります。

現在プレビュー中の新しいステージボリュームの実装では、限られたインメモリキャッシュのみを使用します。これにより、より予測可能な動作と、スループットの大幅な向上が実現します。このバージョンは、最終的には現在の一般公開されている 実装を置き換えます。ワークロードにランダムな書き込みやファイルの追加が必要な場合を除き、Snowflakeはこのプレビューバージョンを評価することを推奨します。

新しいステージボリュームの実装を使用する場合は、以下の追加考慮事項に注意してください:

  • 大規模な連続読み取りおよび書き込み用に最適化されており、これらのアクセスパターンに強力なパフォーマンスを提供します。最良の結果を得るには、大きな連続したチャンクでデータを読み書きします。

  • キャッシュの削除により、新しい実装ではランダム読み取りのパフォーマンスが低下する可能性があります。ただし、ローカルディスクキャッシュがないと、ボリューム間の一貫性が向上します。ファイルの変更は、ファイルが閉じられると、ローカルディスクのバッファーなしでバックステージに直接書き込まれます。

  • 読み取りは常に最新のデータを返すため、この構成はサービス間でデータを共有するのに適しています。

  • ランダム書き込みやファイル追加はサポートされていません。これらの操作を試行すると、エラーが発生します。

サービス仕様でSnowflakeステージボリュームを指定します

サービスコンテナがSnowflakeステージボリュームを使用するサービスを作成するには、以下のステップに示すように、サービス仕様で必要な設定を指定します。

  1. ステージボリュームを指定するには、spec.volumes フィールドを使用します。

    • 次の例に示すように、ステージボリューム実装の一般的に利用可能なバージョンを使用します:

      volumes:
      - name: <name>
        source: <stage_name>
      
      Copy

      以下のフィールドは必須です。

      • name: ボリュームの名前。

      • source:搭載するSnowflake内部ステージまたはステージ上のフォルダー。例えば @my_stage, @my_stage/folder。この値は引用符で囲む必要があります。

    • 次の例に示すように、ステージボリューム実装の新しいプレビューバージョンを使用します。

      volumes:
       - name: <name>
         source: stage
         stageConfig:
            name: <stage_name>
      
      Copy

      以下のフィールドは必須です。

      • name: ボリュームの名前。

      • source:ボリュームのタイプを識別します(stage)。

      • stageConfig:マウントするステージ上のSnowflake内部ステージまたはフォルダーを識別します。例えば @my_stage, @my_stage/folder``または ``@my_db.my_schema.my_stage/folder/nestedfolder。この値は二重引用符で囲む必要があります。

  2. spec.containers.volumeMounts フィールドを使用して、アプリケーション・コンテナーのステージ・ボリュームをマウントする場所を次の例に示すように記述します:

    volumeMounts:
    - name: <name>
      mountPath: <absolute_directory_path>
    
    Copy

    このフィールドに入力する情報は、サポートされるすべてのストレージボリュームタイプで一貫しており、ステージボリュームの両方の実装に適用されます。

この例では、既存のステージボリュームと新しいステージボリュームを使用して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"
Copy

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 メモリが必要です。つまり、インスタンスのサイズに応じて使用できるステージボリュームの数に制限があることを意味します。複数のコンテナにボリュームをマウントしても、メモリ消費が増加することはありません。