Cloud Storage FUSE

이 페이지에서는 애플리케이션이 표준 파일 시스템 시맨틱스를 사용하여 버킷의 객체를 읽고 쓸 수 있도록 Cloud Storage 버킷을 로컬 파일 시스템으로 마운트하고 액세스할 수 있게 해주는 FUSE 어댑터인 Cloud Storage FUSE에 대해 간략히 설명합니다. Cloud Storage FUSE는 Google에서 지원하는 오픈소스 제품입니다.

Cloud Storage FUSE 사용 방법에 대한 안내는 다음 문서를 참조하세요.

gcsfuse CLI 설치 방법을 알아봅니다.
버킷 마운트 방법을 알아봅니다.
gcsfuse 명령줄 도구 또는 구성 파일을 사용하여 Cloud Storage FUSE의 동작을 구성하는 방법을 알아봅니다.
Cloud Storage FUSE GitHub 문서에서 시맨틱스, 성능, 측정항목에 대해 알아봅니다.

이 문서에는 항상 Cloud Storage FUSE의 최신 버전이 반영됩니다. 최신 버전에 대한 자세한 내용은 GitHub에서 Cloud Storage FUSE 출시를 참조하세요.

Cloud Storage FUSE 작동 방식

Cloud Storage FUSE는 FUSE 및 Cloud Storage API를 사용하여 버킷을 파일 시스템의 로컬 마운트된 폴더로 투명하게 노출합니다.

Cloud Storage FUSE는 객체 저장소 이름을 파일 및 디렉터리 시스템으로 번역하여 작동합니다. 이때 객체 이름의 슬래시 문자('/')는 디렉터리 구분 기호로 해석되므로 동일한 공통 프리픽스를 가진 객체는 같은 디렉터리에 있는 파일로 취급됩니다. 애플리케이션은 파일 시스템과 같이 마운트된 버킷 파일과 상호작용하므로, 클라우드에서 거의 제한이 없이 파일 저장소를 실행할 수 있습니다. Cloud Storage FUSE는 Google Kubernetes Engine, Compute Engine VM, 온프레미스 시스템을 비롯해 Cloud Storage에 연결하여 어디서나 실행할 수 있습니다.

Cloud Storage FUSE는 파일 시스템 시맨틱스가 필요한 애플리케이션에 적합한 성능과 확장성 특성을 가진 Cloud Storage 사용 사례에 적합합니다. 예를 들어 Cloud Storage FUSE는 데이터, 모델, 체크포인트, 로그를 Cloud Storage에 직접 저장할 수 있는 방법을 제공하므로 머신러닝(ML) 프로젝트에 유용합니다. 자세한 내용은 ML 워크로드용 Cloud Storage FUSE를 참조하세요.

Cloud Storage FUSE는 다른 Google Cloud 서비스와 통합됩니다. 예를 들어 Cloud Storage FUSE CSI 드라이버를 사용하면 Google Kubernetes Engine(GKE) API를 통해 버킷을 볼륨으로 사용할 수 있으므로 Kubernetes 포드 내에서 Cloud Storage를 읽고 쓸 수 있습니다. 다른 통합에 관한 자세한 내용은 통합을 참고하세요.

캐싱

Cloud Storage FUSE는 성능을 높이고 비용을 줄이는 데 도움이 되는 네 가지 유형의 캐싱(파일 캐싱, 통계 캐싱, 유형 캐싱, 목록 캐싱)을 제공합니다. 이러한 캐시에 관한 자세한 내용은 캐싱 개요를 참고하세요.

제한사항

Cloud Storage FUSE에 파일 시스템 인터페이스가 있기는 하지만 백엔드의 NFS 또는 CIFS 파일 시스템과는 다릅니다. 또한 Cloud Storage FUSE는 POSIX 규정을 준수하지 않습니다. Google Cloud의 POSIX 파일 시스템 제품은 Filestore를 참조하세요.

Cloud Storage FUSE를 사용할 때는 POSIX 파일 시스템과 다른 제한사항 및 시맨틱스에 유의하세요. Cloud Storage FUSE는 해당 기능 내에서만 사용해야 합니다.

POSIX 파일 시스템과의 차이 및 제한사항

다음 목록에서는 Cloud Storage FUSE의 제한사항을 설명합니다.

메타데이터: Cloud Storage에서 파일 업로드 시 Cloud Storage FUSE는 객체 메타데이터를 전송하지 않습니다. 단, mtime 및 symlink 대상은 예외입니다. 즉, Cloud Storage FUSE를 사용하여 파일을 업로드할 때는 객체 메타데이터를 설정할 수 없습니다. 객체 메타데이터를 보존해야 하는 경우 Google Cloud CLI, JSON API 또는 Google Cloud 콘솔을 사용하여 파일을 업로드하는 것이 좋습니다.
동시 실행: Cloud Storage FUSE는 동일한 파일에 여러 쓰기에 대한 동시 실행 제어를 제공하지 않습니다. 파일 여러 개를 쓰기 위해 파일을 바꾸려고 하면 마지막 쓰기만 성공하고 이전의 모든 쓰기는 손실됩니다. 이후 덮어쓰기에 대한 병합, 버전 제어 또는 사용자 알림은 없습니다.
연결:: Cloud Storage FUSE는 하드 링크를 지원하지 않습니다.
파일 잠금 및 파일 패치: Cloud Storage FUSE는 파일 잠금 또는 파일 패치를 지원하지 않습니다. 즉, 버전 제어 시스템은 파일 잠금 및 패치에 의존하므로 Cloud Storage FUSE 마운트 지점에 버전 제어 시스템 저장소를 저장하면 안 됩니다. 또한 Cloud Storage FUSE를 파일 대체로 사용해서는 안 됩니다.
시맨틱스: Cloud Storage FUSE의 시맨틱스는 기존 파일 시스템의 시맨틱스와 다릅니다. 예를 들어 마지막 액세스 시간과 같은 메타데이터는 지원되지 않으며 계층적 네임스페이스가 사용 설정된 버킷을 사용하지 않는 한 디렉터리 이름 바꾸기와 같은 일부 메타데이터 작업은 원자적이지 않습니다. Cloud Storage FUSE 시맨틱스와 기존 파일 시스템 시맨틱스의 차이점 목록은 Cloud Storage FUSE GitHub 문서의 시맨틱스를 참조하세요.
파일 패치(또는 그대로 덮어쓰기) 워크로드: Cloud Storage FUSE는 한 번에 Cloud Storage에 전체 객체만 쓸 수 있으며 패치 메커니즘을 제공하지 않습니다. 파일을 패치하려고 하면 Cloud Storage FUSE가 전체 파일을 다시 업로드합니다. 이 동작에 대한 유일한 예외는 2MB 이상의 파일 끝에 콘텐츠를 추가할 수 있다는 점이며, 이 경우 Cloud Storage FUSE는 추가된 콘텐츠만 다시 업로드합니다.
액세스: 파일 승인은 Cloud Storage 권한으로 제어됩니다. POSIX 스타일의 액세스 제어는 작동하지 않습니다.
성능: Cloud Storage FUSE는 로컬 파일 시스템에 비해 지연 시간이 훨씬 깁니다. 따라서 데이터베이스를 저장하기 위한 백엔드로 사용해서는 안 됩니다. 작은 파일을 한 번에 하나씩 읽거나 쓰는 경우 처리량이 줄어들 수 있습니다. 큰 파일을 사용하거나 여러 파일을 한 번에 전송하면 처리량이 증가할 수 있습니다.
가용성: Cloud Storage FUSE를 사용하여 Cloud Storage에 액세스할 때 일시적인 오류가 발생할 수도 있습니다. 재시도 전략을 사용하여 실패한 작업을 재시도하는 것이 좋습니다.
객체 버전 관리: Cloud Storage FUSE는 객체 버전 관리가 사용 설정된 버킷의 사용을 공식적으로 지원하지 않습니다. 객체 버전 관리가 사용 설정된 버킷에 Cloud Storage FUSE를 사용하려고 하면 예기치 않은 동작이 발생할 수 있습니다.
파일 트랜스코딩: 메타데이터에 content-encoding: gzip가 있는 객체: Cloud Storage FUSE 마운트 디렉터리에 있는 이러한 객체는 압축 해제 트랜스코딩을 수행하지 않습니다. 대신 객체는 버킷에 저장된 것과 동일한 방식으로 압축된 상태로 유지됩니다.
예를 들어 --gzip-local 플래그와 함께 gcloud storage cp 명령어를 사용하여 버킷에 업로드된 1,000바이트의 파일은 Cloud Storage 객체로서 60바이트(실제 압축 크기는 콘텐츠 및 gcloud CLI에서 사용하는 gzip 구현에 따라 다름)가 될 수 있습니다. gcsfuse를 사용하여 버킷이 마운트되고 해당 파일을 마운트 디렉터리에서 나열하거나 읽는 경우 파일 크기는 60바이트로 반환되며 콘텐츠는 원래 1,000바이트 콘텐츠의 압축된 버전입니다.
이는 압축 해제 트랜스코딩을 거치는 gcloud storage cp gs://bucket/path /local/path를 사용한 다운로드와 대조됩니다. 즉, gcloud 명령어에서는 다운로드 중에 콘텐츠가 자동으로 압축 해제되어 압축되지 않은 원본 콘텐츠가 제공됩니다..
참고: Cloud Storage FUSE를 사용하여 content-encoding: gzip으로 객체를 수정하거나 수정하려고 시도하면 예측할 수 없는 동작이 발생할 수 있습니다. 이는 Cloud Storage FUSE가 content-encoding: gzip을 유지한 상태에서 객체 콘텐츠를 있는 그대로 (압축하지 않고) 업로드하기 때문입니다. 이 콘텐츠가 gzip으로 적절히 압축되지 않으면 gcloud CLI과 같은 다른 클라이언트에서 이를 서버에서 읽지 못할 수 있습니다. 이는 다른 클라이언트가 읽는 동안 압축 해제 트랜스코딩을 사용하고 부적절한 gzip 콘텐츠가 있는 경우 실패하기 때문입니다.
보관 정책: Cloud Storage FUSE는 보관 정책이 있는 버킷에 쓰기를 지원하지 않습니다. 보관 정책이 적용된 버킷에 쓰기 작업을 시도하면 쓰기 작업이 실패합니다.
Cloud Storage FUSE는 보관 정책이 적용된 버킷에서 객체를 읽을 수 있지만 버킷을 마운트하는 동안 -o RO 플래그를 전달하여 Read-Only로 마운트해야 합니다.
로컬 저장소: 새로운 또는 수정된 객체는 닫히거나 동기화될 때까지 로컬 임시 파일에 온전히 저장됩니다. 대용량 파일 작업 시 특히 Compute Engine 인스턴스로 작업하는 경우 파일의 임시 복사본을 저장하기에 로컬 스토리지 용량이 충분한지 확인하세요. 자세한 내용은 Cloud Storage FUSE GitHub 문서의 리드미를 참조하세요.
파일 핸들 제한: Linux 커널의 기본 열린 파일 핸들 제한은 1,024개입니다. Cloud Storage FUSE를 서버로 사용하여 여러 개의 동시 연결을 처리하는 경우 이 한도가 초과될 수 있습니다. 문제를 방지하려면 단일 호스트에 대한 동시 연결 수가 한도 미만이 되도록 하고 한도를 늘리는 것이 좋습니다. Cloud Storage FUSE 마운트를 사용하여 웹 콘텐츠를 제공하거나, 네트워크 연결 스토리지(NAS)를 호스팅하거나, 파일 전송 프로토콜(FTP) 서버를 호스팅하는 시나리오에서 이 작업이 중요합니다. Cloud Storage FUSE 마운트에서 Cloud Run에 웹 콘텐츠를 서빙하는 경우 인스턴스당 최대 동시 요청 수가 1,000개 미만으로 제한됩니다.
rsync 제한사항: Cloud Storage FUSE의 파일 시스템 지연 시간은 한 번에 파일을 하나만 읽고 쓰는 rsync에 영향을 줍니다. 여러 파일을 버킷으로 또는 버킷에서 병렬로 전송하려면 gcloud storage rsync를 실행하여 Google Cloud CLI를 사용합니다. 자세한 내용은 rsync 문서를 참조하세요.
목록 작업 제한사항: 마운트된 버킷의 모든 객체를 나열하면(예: ls 실행) Cloud Storage FUSE가 Cloud Storage에서 객체: 나열 API를 호출합니다. 이 API는 결과를 페이지로 나눠서 표시합니다. 즉, 버킷의 객체 수에 따라 Cloud Storage FUSE가 호출을 여러 번 실행해야 할 수 있으며, 이로 인해 목록 작업이 비용이 많이 들고 느려질 수 있습니다.

프레임워크, 운영체제, 아키텍처

Cloud Storage FUSE는 다음 프레임워크로 검증되었습니다.

TensorFlow V2.x
TensorFlow V1.x
PyTorch V2.x
PyTorch V1.x
JAX 0.4.x

Cloud Storage FUSE는 다음 운영체제 및 아키텍처를 지원합니다.

Rocky Linux 8.9 이상
Ubuntu 18.04 이상
Debian 10 이상
CentOS 7.9 이상
RHEL 7.9 이상
x86_64
ARM64

지원 받기

Google Cloud의 공식 지원 채널 중 하나를 사용하여 지원을 받고 일반적인 질문을 제출하고 새로운 기능을 요청할 수 있습니다. GitHub에서 문제를 제출하여 지원을 받을 수도 있습니다.

일반적으로 발생하는 문제에 대한 해결 방법은 Cloud Storage FUSE GitHub 문서의 문제 해결을 참조하세요.

Cloud Storage FUSE 가격 책정

Cloud Storage FUSE는 무료로 사용할 수 있습니다. 하지만, Cloud Storage에서 발생하는 네트워크 I/O, 저장소, 메타데이터에는 다른 Cloud Storage 인터페이스와 같이 요금이 청구됩니다. 즉, Cloud Storage FUSE에서 수행하는 모든 데이터 전송과 작업은 Cloud Storage 전송과 작업에 매핑되며 그에 따라 요금이 청구됩니다. 일반적인 Cloud Storage FUSE 작업과 Cloud Storage 작업에 대한 매핑 방법에 대한 자세한 내용은 작업 매핑을 참조하세요.

예정이 없던 요금이 청구되지 않도록 Cloud Storage FUSE 사용으로 인한 Cloud Storage 요금이 얼마인지 파악해야 합니다. 예를 들어, Cloud Storage FUSE를 사용하여 로그 파일을 저장하는 경우, 로그가 동시에 수백 또는 수천 개의 시스템에서 공격적으로 밀려들면 요금이 빠르게 증가할 수 있습니다.

스토리지, 네트워크 사용량, 작업과 같은 요금에 대한 자세한 내용은 Cloud Storage 가격 책정을 참조하세요.

Cloud Storage 작업에 대한 Cloud Storage FUSE 작업 매핑

또한 Cloud Storage FUSE를 사용하여 작업을 수행할 때는 Cloud Storage FUSE 작업과 연관된 Cloud Storage 작업을 수행합니다. 다음 표에서는 일반적인 Cloud Storage FUSE 명령어 및 연관된 Cloud Storage JSON API 작업을 설명합니다. --debug_gcs 플래그를 사용하여 Cloud Storage FUSE 작업에 대한 정보를 표시할 수 있습니다.

명령어	JSON API 작업
`gcsfuse --debug_gcs example-bucket mp`	Objects.list(사용자 인증 정보 확인)
`cd mp`	해당 사항 없음
`ls mp`	Objects.list("")
`mkdir subdir`	Objects.get("subdir") Objects.get("subdir/") Objects.insert("subdir/")
`cp ~/local.txt subdir/`	Objects.get("subdir/local.txt") Objects.get("subdir/local.txt/") Objects.insert("subdir/local.txt"), 빈 객체 만들기 Objects.insert("subdir/local.txt"), 쓰기 완료 후 닫을 때
`rm -rf subdir`	Objects.list("subdir") Objects.list("subdir/") Objects.delete("subdir/local.txt") Objects.list("subdir/") Objects.delete("subdir/")

디렉터리 시맨틱스

Cloud Storage는 플랫 네임스페이스로 작동합니다. 즉, 디렉터리가 Cloud Storage 내에 실제로 존재하지 않습니다. 디렉터리는 슬래시(/)로 끝나는 객체 이름으로 대신 표현됩니다. 예를 들어 객체 이름 my-bucket/directory/file.txt에서 my-bucket/directory/는 디렉터리를 나타냅니다. 객체 이름에 포함되어 존재하지만 실제 객체로는 존재하지 않는 디렉터리를 암시적으로 정의된 디렉터리라고 합니다.

기본적으로 시뮬레이션된 폴더가 있는 버킷을 마운트하면 Cloud Storage FUSE가 해당 디렉터리를 추론하거나 액세스할 수 없습니다. Cloud Storage FUSE는 명시적으로 정의된 디렉터리, 즉 Cloud Storage 버킷 내에 실제 객체로 존재하는 디렉터리만 추론할 수 있습니다.

예를 들어 my-bucket/directory/file1.txt 객체가 포함된 my-bucket이라는 버킷을 마운트한다고 가정해 보겠습니다. 버킷 마운트 지점에서 ls를 실행하면 directory가 Cloud Storage의 객체로 존재하지 않으므로 Cloud Storage FUSE가 my-bucket/directory/ 디렉터리나 그 안에 있는 file1.txt 객체에 액세스할 수 없습니다. Cloud Storage FUSE가 디렉터리와 그 안에 있는 객체를 추론할 수 있게 하려면 mkdir 명령어를 사용하여 로컬 파일 시스템에 디렉터리를 만들거나, gcsfuse 명령어에 --implicit-dirs 옵션을 포함하여 디렉터리를 명시적으로 정의하면 됩니다. 이 경우 추가 요청과 같은 추가 오버헤드가 발생합니다. 또는 계층적 네임스페이스가 사용 설정된 버킷을 사용하면 됩니다.

기존 프리픽스와 함께 버킷을 마운트하는 방법을 포함해서 디렉터리 시맨틱스에 대한 자세한 내용은 GitHub 문서의 파일 및 디렉터리를 참조하세요. --implicit-dirs 옵션에 대한 자세한 내용은 Cloud Storage FUSE 명령줄 문서를 참조하세요.

재시도 전략

기본적으로 Cloud Storage FUSE에서 Cloud Storage로의 실패한 요청은 기본적으로 값이 30s(30초)인 지정된 최대 백오프 기간까지 지수 백오프로 재시도됩니다. 백오프 기간이 지정된 최대 기간을 초과하면 지정된 최대 기간 동안 재시도가 계속됩니다. --max-retry-sleep 옵션을 gcsfuse 호출의 일부로 사용해서 백오프 기간을 지정할 수 있습니다.

--max-retry-sleep 옵션에 대한 자세한 내용은 gcsfuse 명령줄 문서를 참조하세요.

알려진 문제

Cloud Storage FUSE의 알려진 문제 목록은 GitHub를 참조하세요.

다음 단계

빠른 시작을 완료하여 Cloud Storage FUSE 살펴보기
Cloud Storage FUSE 설치
Cloud Storage FUSE가 다른 Google Cloud 제품과 통합되는 방법 알아보기