서비스에 Snowflake 스테이지 볼륨 사용¶

Snowflake는 내부 스테이지, 로컬 저장소, 메모리 저장소, 블록 저장소 볼륨 등 애플리케이션 컨테이너를 위한 :ref:`다양한 저장소 볼륨 유형<label-snowpark_containers_spec_volume_types>`을 지원합니다. 이 섹션에서는 내부 스테이지에 대한 볼륨과 볼륨 마운트를 구성하는 방법을 설명합니다.*내부 스테이지 볼륨*은 Snowflake 스테이지를 영구 저장소로 사용하도록 구성된 볼륨입니다.

스테이지 볼륨을 사용하면 서비스가 파일 시스템의 파일처럼 내부 스테이지의 오브젝트에 액세스할 수 있으므로 Snowflake 드라이버와 GET 및 :doc:`/sql-reference/sql/put`SQL 명령을 사용하여 해당 오브젝트에 액세스하는 것에 비해 서비스 코드가 간소화됩니다. 또한 스테이지 볼륨은 대용량 데이터 파일의 읽기 또는 쓰기를 스트리밍하는 시나리오에서 더 뛰어난 성능을 발휘할 수 있습니다.

파일 시스템 작업을 스트리밍 GET 및 PUT 작업으로 쉽게 변환할 수 있는 경우 스테이지 볼륨이 해당 시나리오에 적합합니다. 애플리케이션이 파일의 이름을 바꾸거나 이동하거나, 기존 파일을 수정하거나, 파일 시스템 기반 잠금을 수행해야 하는 경우 스테이지 볼륨은 워크로드에 적합하지 않습니다.

참고

현재 스테이지 볼륨에는 일반 공급 버전과 사용 중단된 버전, 두 가지 구현이 있습니다. Snowflake는 새 서비스에 일반 공급으로 제공되는 버전을 사용하고 사용 중단된 버전에서 기존 애플리케이션을 마이그레이션할 것을 권장합니다.

스테이지 볼륨 구현은 파일 콘텐츠를 클라우드 저장소로 직접 스트리밍하거나 클라우드 저장소에서 직접 스트리밍하므로 항상 최신 콘텐츠를 얻을 수 있습니다. 스테이지 볼륨을 사용할 때 다음 사항을 고려하세요.

스테이지 볼륨은 대규모의 순차적 읽기 및 쓰기에 최적화되어 있어 이러한 액세스 패턴에 강력한 성능을 제공합니다. 최상의 결과를 얻으려면 대규모의 연속적인 청크에서 데이터를 읽고 씁니다.
읽기는 항상 최신 데이터를 반환하므로 서비스 간에 데이터 공유가 가능합니다.
임의 쓰기 또는 파일 추가 기능은 지원되지 않습니다. 이러한 작업을 시도하면 오류가 발생합니다. Snowflake는 해당 워크로드에 :doc:`블록 저장소 볼륨</developer-guide/snowpark-container-services/block-storage-volume>`을 사용할 것을 권장합니다.

서비스 사양에서 Snowflake 스테이지를 저장소 볼륨으로 구성하기¶

서비스 컨테이너가 스테이지 볼륨을 사용하는 서비스를 생성하려면 서비스 사양에서 필요한 설정을 지정하는 두 단계를 수행합니다.

저장소 볼륨으로 사용할 Snowflake 스테이지를 식별하는 스테이지 볼륨을 정의합니다.
애플리케이션 컨테이너에서 스테이지 볼륨을 탑재할 위치를 지정합니다.

1단계: 스테이지 볼륨 정의하기¶

스테이지 볼륨을 정의하려면 다음 예제와 같이 서비스 사양에 spec.volumes 필드를 추가합니다.

spec:
  containers:
    ..
  volumes:
  - name: <name>
    source: stage
     stageConfig:
       name: <stage_name>
       medataCache: <time_period>
       resources:
         requests:
           memory: <amount-of-memory>
           cpu: <cpu-units>
         limits:
           memory: <amount-of-memory>
           cpu: <cpu-units>

Copy

다음 목록은 예제의 필드를 정의합니다.

name: 볼륨의 이름을 제공합니다.
source: 볼륨 유형(스테이지)을 식별합니다.
stageConfig.name: 마운트할 스테이지의 Snowflake 내부 스테이지 또는 폴더를 식별합니다(예: @my_stage, @my_stage/folder 또는 @my_db.my_schema.my_stage/folder/nestedfolder). 이 값은 큰따옴표로 묶어야 합니다.

``stageConfig``에 다음과 같은 선택적 필드를 포함할 수 있습니다.

stageConfig.resources 필드: 탑재된 스테이지 볼륨을 제공하는 Snowflake 구성 요소에는 CPU 및 메모리 리소스가 필요합니다. 이 필드를 사용하여 애플리케이션 컨테이너의 리소스 사양과 유사한 CPU 및 메모리 요구 사항을 지정합니다. 자세한 내용은 containers.resources 필드 필드를 참조하세요. 이 필드를 지정하지 않으면 다음 기본 리소스 설정이 적용됩니다.
- resources.requests.cpu: 0
- resources.requests.memory: 0.5Gi
- resources.limits.cpu: 0.5
- resources.limits.memory: 1Gi
스테이지 볼륨에 대한 일반적인 데이터 트래픽이 있는 대부분의 애플리케이션의 경우 기본 리소스 설정으로 충분해야 하므로 이 필드를 설정할 필요가 없습니다. 그러나 애플리케이션이 대량의 읽기 및 쓰기를 수행하는 경우 기본 설정으로 인해 성능 제약 또는 읽기/쓰기 실패가 발생할 수 있습니다. 자세한 내용은 두 가지 스테이지 볼륨 구현에 공통된 지침 섹션을 참조하십시오.

이러한 문제를 방지하려면 컨테이너에 대한 CPU 및 메모리 메트릭<label-monitoring_services_platform_metrics>`(``stage-mount-v2-sidecar-<stage-volume-name>`)을 확인합니다. Snowflake는 구성한 스테이지 볼륨의 구현을 제공하는 서비스에 이 컨테이너를 추가합니다. 이를 통해 스테이지 볼륨이 사용 중인 리소스를 정확히 확인하고 CPU 또는 메모리로 제한되는지 확인할 수 있습니다. 이러한 메트릭을 사용하여 필요에 따라 CPU 및 메모리 제한을 업데이트합니다.
stageConfig.metadataCache 필드: 애플리케이션이 파일 메타데이터를 자주 검색하거나 루프에서 Snowflake 스테이지의 파일을 나열하고 데이터가 자주 변경되지 않을 것으로 예상되는 경우 Snowflake 스테이지 저장소 볼륨에 대한 메타데이터 캐싱을 활성화하여 성능을 크게 개선할 수 있습니다. 캐시는 지정된 기간 동안 이 메타데이터를 저장한 후 지워집니다. 그런 다음 애플리케이션이 메타데이터에 액세스하려고 하면 Snowflake가 캐시를 새로 고칩니다. 시간, 분, 초 단위를 사용하여 metadataCache``를 지정합니다. 예: ``90s, 5m, 1h, 1h30m, 1h30m45s. 지정하지 않으면 캐싱이 없습니다.

참고

Snowflake 스테이지의 데이터가 서비스 수명 주기 동안 변경되지 않는 경우에만 메타데이터 캐싱을 구성합니다. 예를 들어, 스테이지의 정적 데이터 세트에서 작업해야 하는 읽기 전용 워크로드가 있는 서비스의 경우가 이에 해당합니다. 서비스가 실행되는 동안 Snowflake 스테이지의 데이터가 업데이트되는 워크로드에 대한 메타데이터 캐싱을 구성하지 마세요.

다음 spec.volumes 필드는 Snowflake 스테이지 볼륨을 정의합니다. 필드에는 선택적 stageConfig 필드가 포함됩니다.

spec:
  containers:
    ..
  volumes:
  - name: <name>
    source: stage
    stageConfig:
      name: <stage_name>
      metadataCache: 1h
      resources:
        requests:
          cpu: 0.35
          memory: 0.4Gi
        limits:
          cpu: 2.0
          memory: 1Gi

Copy

2단계: 컨테이너에서 스테이지 볼륨을 탑재할 위치 지정하기¶

spec.volumes 필드를 추가하여 Snowflake 스테이지 저장소 볼륨을 정의한 후, spec.containers.volumeMounts 필드를 사용하여 다음 예제와 같이 애플리케이션 컨테이너에서 스테이지 볼륨을 탑재할 위치를 설명합니다.

spec:
  containers:
  - name: ...
    image: ...
    volumeMounts:
    - name: <name>
      mountPath: <absolute_directory_path>

Copy

이 필드에 제공하는 정보는 지원되는 모든 저장소 볼륨 유형에서 일관되며, 스테이지 볼륨의 두 가지 구현 방식에 모두 적용됩니다.

예¶

기본 컨테이너의 /path/to/stage``에 탑재된 ``mydb.myschema.ai_models_stage 스테이지가 있는 서비스를 만듭니다.

CREATE SERVICE my_service
IN COMPUTE POOL tutorial_compute_pool
FROM SPECIFICATION $$
spec:
  containers:
  - name: echo
    image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
    volumeMounts:
    - name: stage-vol
      mountPath: /path/to/stage
  volumes:
  - name: stage-vol
    source: stage
    stageConfig:
      name: "@mydb.myschema.ai_models_stage"
$$;

Copy

기본 컨테이너의 /path/to/stage``에 탑재된 스테이지 하위 경로(``mydb.myschema.ai_models_stage/subpath)가 있는 서비스를 만듭니다.

CREATE SERVICE my_service
IN COMPUTE POOL tutorial_compute_pool
FROM SPECIFICATION $$
spec:
  containers:
  - name: echo
    image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
    volumeMounts:
    - name: stage-vol
      mountPath: /path/to/stage
  volumes:
  - name: stage-vol
    source: stage
    stageConfig:
      name: "@mydb.myschema.ai_models_stage/subpath"
      metadataCache: 1h
      resources:
        requests:
          cpu: 0.35
          memery: 0.4Gi
        limits:
          cpu 2.0
          memory: 1Gi
$$;

Copy

액세스 제어 요구 사항¶

서비스의 소유자 역할은 서비스를 생성하는 데 사용되는 역할입니다. 이는 Snowflake와 상호작용할 때 서비스가 사용하는 역할이기도 합니다. 이 소유자 역할은 마운트된 스테이지에 액세스하기 위해 애플리케이션 컨테이너에 부여되는 권한을 결정합니다. 소유자 역할에는 스테이지에 대한 READ 권한이 있어야 합니다.

소유자 역할에 스테이지 WRITE 권한이 없는 경우, 해당 스테이지의 마운트는 읽기 전용입니다. 즉, 컨테이너에서 스테이지의 파일을 읽을 수만 있습니다. 소유자 역할에 스테이지 WRITE 권한이 있어야 스테이지 마운트 시 읽기와 쓰기를 모두 지원할 수 있습니다.

사용 중단된 구현에 대한 정보¶

사용 중단된 스테이지 볼륨 구현에서는 읽기 및 쓰기에 공유 캐시를 사용합니다. 일부 시나리오에서는 이 방법이 효과적이지만, 캐시에서 데이터를 읽을지 또는 스테이지에서 직접 데이터를 읽을지 여부를 제어할 수 없으므로 모든 애플리케이션에 적합하지 않을 수 있습니다. 또한 읽기 및 쓰기에 캐시를 사용하면 성능 오버헤드가 발생할 수 있습니다.

사용 중단된 구현에서 코드 마이그레이션하기¶

최신 구현은 사용 중단된 구현을 다음과 같은 동작 변경 사항으로 대체합니다.

최신 스테이지 볼륨 구현은 파일 콘텐츠를 클라우드 저장소로 직접 스트리밍하거나 클라우드 저장소에서 직접 스트리밍하므로 항상 최신 콘텐츠를 얻을 수 있습니다. 이를 통해 동작을 잘 예측하고 처리량의 속도를 향상시킬 수 있습니다. 사용 중단된 스테이지 볼륨 구현은 파일 데이터 청크를 캐싱하므로 최신 데이터를 읽고 있는지 확인하기 어렵습니다.
캐싱 기능이 제거되어 새 구현에서는 임의 읽기 성능이 저하될 수 있습니다. 그러나 로컬 디스크 캐시가 없으면 볼륨 전체의 일관성이 개선됩니다. 파일 변경 사항은 파일을 닫을 때 로컬 디스크 버퍼링 없이 지원 스테이지에 바로 기록됩니다.
읽기는 항상 최신 데이터를 반환하므로, 서비스 간에 데이터를 공유하는 데에는 이 구성이 더 적합합니다.
임의 쓰기 또는 파일 추가 기능은 지원되지 않습니다. 이러한 작업을 시도하면 오류가 발생합니다. Snowflake는 해당 워크로드에 :doc:`블록 저장소 볼륨</developer-guide/snowpark-container-services/block-storage-volume>`을 사용할 것을 권장합니다.

서비스 사양에서 Snowflake 스테이지 볼륨 지정하기(사용 중단됨)¶

서비스 컨테이너에서 Snowflake 스테이지 볼륨을 사용하는 서비스를 만들려면 다음 단계에 표시된 대로 서비스 사양에 필요한 설정을 지정합니다.

스테이지 볼륨을 지정하려면 다음 예제와 같이 spec.volumes 필드를 추가합니다.
```
volumes:
- name: <name>
  source: <stage_name>
```
Copy
다음 필드는 필수입니다.
- name: 볼륨의 이름입니다.
- source: 마운트할 스테이지의 폴더 또는 Snowflake 내부 스테이지(예: @my_stage, @my_stage/folder). 이 값은 따옴표로 묶어야 합니다.
다음 예제와 같이 애플리케이션 컨테이너에서 스테이지 볼륨을 마운트할 위치를 설명하려면 spec.containers.volumeMounts 필드를 사용합니다.
```
volumeMounts:
- name: <name>
  mountPath: <absolute_directory_path>
```
Copy
이 필드에 제공하는 정보는 지원되는 모든 저장소 볼륨 유형에서 일관되며, 스테이지 볼륨의 두 가지 구현 방식에 모두 적용됩니다.

예제(사용 중단됨)¶

예제 서비스 사양에서는 앱 컨테이너가 사용 중단된 스테이지 볼륨 구현을 사용하여 내부 스테이지 ``@model_stage``를 마운트합니다.

spec:
  containers:
  - name: app
    image: <image1-name>
    volumeMounts:
    - name: models-legacy
      mountPath: /opt/model-legacy
  volumes:
  - name: models-legacy
    source: "@model_stage"

Copy

volumeMounts 필드는 스테이지 볼륨을 마운트할 컨테이너 내부의 위치를 지정합니다. 이 사양은 스테이지 볼륨 구현 모두에서 동일하게 유지됩니다.

스테이지 볼륨 사용 시 지침¶

이 섹션에서는 컨테이너가 Snowflake 스테이지를 저장소 볼륨으로 사용하는 애플리케이션 코드를 구현할 때 따라야 할 지침을 제공합니다.

두 가지 스테이지 볼륨 구현에 공통된 지침¶

스테이지 마운트는 순차적 읽기 및 쓰기에 최적화되어 있습니다.
스테이지 마운트 I/O 작업은 컨테이너의 파일 시스템 및 블록 저장소 볼륨의 I/O 작업보다 대기 시간이 길어질 수 있습니다. I/O 작업의 상태 코드를 항상 확인하여 성공했는지 확인해야 합니다.
스테이지 마운트는 파일 업데이트를 비동기적으로 업로드합니다. 스테이지 마운트의 파일 변경 사항은 파일 설명자를 성공적으로 닫거나 플러시해야만 스테이지에 유지됩니다. 스테이지 마운트의 파일 변경 사항이 다른 컨테이너와 Snowflake에 표시되기까지 지연이 발생할 수 있습니다.
마운트된 스테이지의 각 디렉터리에는 100,000개 미만의 파일이 포함되어야 합니다. 디렉터리 내 파일 수에 따라 readdir 지연 시간이 증가할 것으로 예상됩니다.

사용 중단된 버전의 스테이지 볼륨 구현 사용 시 지침¶

스테이지 마운트 내에서 여러 파일에 동시에 쓰기를 피합니다.
스테이지 마운트는 네트워크 파일 시스템이 아닙니다. 다중 클라이언트를 조정하는 데 스테이지 마운트를 사용하지 마세요.
같은 파일에 여러 핸들을 동시에 열지 마십시오. 열린 파일 핸들은 읽기 또는 쓰기 작업 중 하나에만 사용되지만, 두 가지를 혼합해서 사용하면 안 됩니다. 파일에 쓴 후 읽으려면 먼저 파일을 닫았다가 다시 열어서 읽어야 합니다.

일반 공급 버전의 스테이지 볼륨 구현 사용 시 지침¶

여러 스테이지 마운트(다른 컨테이너에 마운트된 동일한 스테이지 볼륨)에서 동일한 파일에 동시에 쓰기는 권장되지 않습니다.
로컬 디스크 캐시가 없으면 마운트 전반의 일관성이 개선됩니다. 파일 변경 사항은 파일을 닫을 때 로컬 디스크 버퍼링 없이 지원 스테이지에 바로 플러시됩니다. 읽기는 항상 최신 데이터를 반환하므로, 서비스 간에 데이터를 공유하는 데에는 새로운 스테이지 마운트가 더 적합합니다.
최적의 성능을 얻으려면 대규모의 연속 청크에서 데이터를 읽고 쓰세요. 일반 공급 버전의 스테이지 볼륨 구현과 비교해 볼 때 소규모 읽기/쓰기 작업의 성능 저하가 발생하지만, 이로 인해 새로운 구현의 성능 향상을 상쇄할 수 있습니다.

스테이지 볼륨 사용 시 제한 사항¶

이 섹션에서는 컨테이너가 스테이지 볼륨을 사용하는 애플리케이션 코드를 구현할 때 알고 있어야 하는 제한 사항을 설명합니다. 이러한 제한과 관련된 문제가 발생하면 계정 담당자에게 문의하세요.

두 가지 스테이지 볼륨 구현에 공통된 제한 사항¶

스테이지에서는 스테이지 또는 하위 디렉터리만 마운트할 수 있습니다(예: @my_stage, @my_stage/folder). 스테이지에서는 단일 파일을 마운트할 수 없습니다(예: @my_stage/folder/file).
외부 스테이지는 지원되지 않습니다. Snowflake 내부 스테이지만 지원됩니다.
스테이지 마운트는 POSIX와 완전 호환되지 않는 파일 시스템입니다. 예:
- 파일 및 디렉터리 이름 변경은 원자적이지 않습니다.
- 하드 링크는 지원되지 않습니다.
파일 시스템의 변경 사항을 모니터링하는 Linux 커널 하위 시스템 inode notify(inotify)는 스테이지 마운트에서 작동하지 않습니다.

사용 중단된 버전의 스테이지 볼륨 구현 사용 시 제한 사항¶

서비스당 최대 5개의 스테이지 볼륨이 허용됩니다. 자세한 내용은 spec.volumes 섹션을 참조하세요.
컴퓨팅 풀 노드당 최대 8개의 스테이지 볼륨이 지원됩니다. Snowflake는 메모리, CPU, GPU를 관리하는 방식과 유사하게 노드당 스테이지 마운트 제한을 관리합니다. 새로운 서비스 인스턴스를 시작하면 기존 노드에 요청된 스테이지 마운트를 지원할 용량이 없을 때 Snowflake가 새로운 노드를 시작할 수 있습니다.
스테이지 볼륨 기능은 Snowflake 계정의 클라우드 플랫폼에 따라 다릅니다.
- AWS의 계정은 SNOWFLAKE_FULL 및 SNOWFLAKE_SSE 스테이지 암호화를 모두 사용하는 내부 스테이지를 지원합니다. 자세한 내용은 내부 스테이지 매개 변수 섹션을 참조하세요.
- Azure의 계정은 현재 SNOWFLAKE_SSE 암호화를 사용하는 내부 스테이지를 지원합니다. CREATE STAGE 실행 시 ENCRYPTION 매개 변수를 사용하여 CREATE STAGE my_stage ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE'); 암호화 유형을 지정합니다.
- Google Cloud의 계정은 지원되지 않습니다.
여러 스테이지 마운트(즉, 다른 컨테이너에 마운트된 동일한 스테이지 볼륨)에서 동일한 파일에 동시에 쓰기는 지원되지 않습니다.

일반 공급 버전의 스테이지 볼륨 구현 사용 시 제한 사항¶

임의 쓰기 및 파일 추가 기능은 지원되지 않습니다.
마운트된 각 스테이지에는 스테이지당 512MB의 메모리가 필요합니다. 즉, 인스턴스 크기에 따라 사용할 수 있는 스테이지 볼륨 수에는 제한이 있습니다. 여러 컨테이너에 볼륨을 마운트해도 메모리 사용량이 증가하지는 않습니다.
서비스당 최대 20개의 스테이지 볼륨이 허용됩니다. 자세한 내용은 spec.volumes 섹션을 참조하세요.