S3 및 WebDAV 프로토콜을 통해 JuiceFS에 액세스하는 방법

다양한 애플리케이션은 데이터를 서로 다른 방식으로 접근합니다. 일부는 POSIX 파일 인터페이스에 의존하고, 일부는 S3 API를 기반으로 구축되었으며, 일부 사용자는 파일 관리자를 통해 원격 파일을 탐색하고 편집하기를 원합니다. JuiceFS의 다중 프로토콜 액세스 기능은 이러한 도구들이 동일한 파일 시스템에 접근할 수 있도록 설계되었습니다.

본 글에서는 S3 Gateway와 WebDAV의 공통 초기화 경로를 설명하고, 적용 가능한 시나리오와 일반적인 매핑을 기술하며, 구현 원리와 경계까지 깊이 있게 다루겠습니다.

공통 초기화 경로

JuiceFS는 메타데이터 엔진과 객체 스토리지로 구성됩니다:

• 메타데이터 엔진은 디렉터리, 속성(attributes), 잠금(locks), 세션 등을 관리합니다.
• 객체 스토리지는 실제 파일 데이터 블록을 저장합니다.

구현 관점에서 볼 때, S3 Gateway와 WebDAV는 먼저 동일한 서비스 초기화 경로를 거칩니다. 서비스 프로세스는 메타데이터 주소(metadata address), 리스닝 주소(listen address) 및 subdir, read-only, cache, limits, access-log, metrics와 같은 공통 매개변수를 기반으로 JuiceFS 클라이언트를 생성합니다. 그런 다음, 순차적으로 메타데이터 클라이언트, 객체 스토리지, 데이터 블록 캐시, VFS 설정을 초기화하여 궁극적으로 fs.FileSystem을 얻게 됩니다.

다시 말해, 두 프로토콜의 공통 기반은 FUSE 마운트 지점이 아니라 세션, 캐싱, 메트릭 및 백그라운드 작업을 갖춘 네이티브 JuiceFS 클라이언트입니다. S3 요청과 WebDAV 요청이 각각의 프로토콜 어댑테이션 레이어에 진입하기 전에, 이들은 이미 동일한 JuiceFS 파일 시스템과 동일한 파일 시스템 네임스페이스를 공유합니다.

적용 가능한 시나리오 및 일반적인 매핑

공유 초기화 경로는 두 가지가 동일한 파일 시스템에 연결되는 방법을 설명합니다. 실제 사용에서는 접근 방식을 선택하는 것이 더 중요하며, 어떤 시나리오가 S3 Gateway에 적합하고, 어떤 시나리오가 WebDAV에 적합하며, 일반적인 요청이 JuiceFS 작업과 어떻게 매핑되는지 알아야 합니다.

• 전체 파일 시스템 의미론(semantics)이 필요한 Linux 애플리케이션, 학습 작업 또는 워크로드는 FUSE/CSI를 선호해야 합니다.
• S3 SDK, AWS CLI, MinIO Client 또는 객체 스토리지 툴체인에 이미 구축된 애플리케이션은 S3 Gateway를 선호해야 합니다.
• 데스크톱 파일 관리자 접근, DAV/rclone 동기화, Office/애플리케이션 협업 및 간단한 공유는 WebDAV를 선호해야 합니다.

일반적인 S3 Gateway API의 JuiceFS 파일 시스템 작업으로의 매핑:

S3 Gateway 원칙: 객체 의미론에서 파일 시스템 작업으로

S3 Gateway는 S3 프로토콜 요청을 JuiceFS 파일 시스템 작업으로 변환합니다. 이 섹션에서는 네 가지 측면을 다룹니다:

• 요청 경로 (Request path)
• 내부 상태 (Internal state)
• 핵심 의미론적 변환 (Key semantic conversions)
• 권한 조정 (Permission coordination)

요청 경로: MinIO S3 서버에서 jfsObjects로

MinIO S3 서버는 요청 라우팅, 서명 검증, 인증 및 권한 부여, 그리고 멀티파트 업로드 오케스트레이션을 포함하는 S3 프로토콜 계층을 처리합니다. 요청이 프로토콜 계층을 통과하면 JuiceFS가 구현한 ObjectLayer, 즉 jfsObjects로 진입합니다. jfsObjects는 객체 수준의 읽기, 쓰기, 목록 조회(listing), 삭제 및 속성 접근을 JuiceFS 파일 시스템 호출로 변환합니다.

상태 저장소(State storage): 내부 네임스페이스가 게이트웨이 상태를 전파하는 방식

요청 변환 과정에서 게이트웨이는 사용자에게 보이는 객체 경로에만 접근하는 것이 아니라, 서비스 자체에 필요한 상태를 저장하기 위해 내부 네임스페이스도 사용합니다. 예를 들어, 임시 쓰기에는 .sys/tmp가 사용되고, 멀티파트 업로드 상태에는 .sys/uploads가 사용되며, MinIO/IAM 관련 메타데이터 저장을 위해서는 .minio.sys가 사용됩니다.

이러한 내부 경로는 일반적인 사용자 관점의 애플리케이션 데이터는 아니지만, 게이트웨이가 업로드 프로세스, 파트 상태 및 권한 구성을 유지하는 데 필요한 기반입니다.

의미론적 변환(Semantic conversion): PutObject, Multipart, Bucket, 및 Metadata

S3 객체 모델과 파일 시스템 모델은 완전히 같지 않기 때문에, 게이트웨이는 여러 주요 지점에서 의미론적 변환을 수행해야 합니다.

PutObject는 업로드가 완료된 후에만 객체가 보이도록 보장해야 합니다. 클라이언트가 불완전한 객체를 읽는 것을 방지하기 위해, JuiceFS S3 Gateway는 임시 파일에 쓰기하고 메타데이터 및 태그와 같은 객체 속성을 저장하며, 완료 후 리네임(rename)을 통해 대상 경로에 커밋합니다. 파일 시스템 리네임의 원자성(atomicity)을 활용하여, 게이트웨이는 객체 쓰기를

Multipart upload는 여러 파트를 최종 객체로 병합해야 합니다. JuiceFS S3 Gateway는 CopyFileRange와 같은 파일 시스템 기능을 사용하여 이미 작성된 파트들을 결합하고, 이름을 변경(rename)하여 최종 파일을 커밋할 수 있습니다. 이는 모든 데이터를 다시 이동하는 것보다는 주로 파일 시스템 메타데이터 관계를 조정합니다.

버킷 매핑(Bucket mapping)은 객체 네임스페이스와 파일 경로 간의 관계를 처리합니다. 단일 버킷 모드(single-bucket mode)에서는 파일 시스템 이름이 버킷에 해당하며, 다중 버킷 모드(multi-bucket mode)에서는 최상위 디렉터리가 버킷에 매핑됩니다. 메타데이터, 태그(tag), ETag와 같은 객체 속성은 파일 확장 속성(xattr)을 통해 저장됩니다.

권한 조정: IAM 및 다중 인스턴스

S3 Gateway는 또한 루트 사용자(root users), 일반 사용자(regular users), 정책(policies), 서비스 계정(service accounts) 등을 포함하는 ID 및 권한 정보도 처리해야 합니다. 이러한 설정들은 JuiceFS 파일 시스템 내의 내부 경로에 저장되어 여러 Gateway 인스턴스에서 재사용될 수 있도록 합니다.

따라서, 다수의 Gateway 인스턴스는 동일한 IAM 설정을 공유할 수 있습니다. 하지만 각 인스턴스가 IAM 정보를 캐시하기 때문에 권한 변경 사항이 즉각적으로 동기화되지는 않습니다. 실제 배포에서는 이 새로고침 주기(refresh cycle)를 고려해야 합니다.

WebDAV 원칙: 파일 프로토콜에서 JuiceFS 작업으로

WebDAV는 S3 Gateway와 다른 지점에서 시작합니다. 이는 macOS Finder, DAV/rclone 등 일반 클라이언트 및 일부 오피스/앱 클라이언트를 포함하는 파일 액세스 시나리오를 목표로 합니다. WebDAV 프로토콜은 파일(files), 디렉토리(directories), 속성(attributes)과 같은 개념을 포함하므로, S3 Gateway와 달리 한편에서는 버킷(buckets), 객체(objects), 키(keys) 간의 모델 변환을 처리하고 다른 한편에서는 경로(paths) 및 파일로 변환할 필요가 없습니다.

요청 경로: HTTP 엔트리에서 webdavFS까지

WebDAV 요청이 JuiceFS에 들어오면:

1. net/http와 indexHandler를 거칩니다. 이 계층은 주로 인증(authentication), 전송(transport), 디렉토리 액세스 요청 변환 등 HTTP 엔트리 관련 기능을 처리합니다.

2. 요청은 x/net/webdav.Handler로 진입하며, 이곳에서 WebDAV 프로토콜 계층을 처리하고 프로토콜 메서드를 webdavFS가 처리할 수 있는 파일 액세스 요청으로 변환합니다.

3. webdavFS에 진입한 후, Handler가 전달하는 파일 액세스 요청은 open, create, read/write, rename, delete, 속성 설정과 같은 JuiceFS 파일 시스템 호출로 변환됩니다. WebDAV 프로토콜이 파일 시스템 의미론(file system semantics)에 가깝기 때문에, 여기서의 초점은 객체 모델을 재구축하는 것이 아니라 요청 메서드, 파일 열 플래그(file open flags), 속성 상태가 JuiceFS 작업에 어떻게 매핑되는지를 처리하는 것입니다.

상태 경계: 데드 속성과 LOCK

WebDAV 적응(adaptation)은 데이터 읽기 및 쓰기뿐만 아니라 프로토콜 자체의 상태도 포함합니다. 데드 속성(Dead properties)은 xattr에 JSON으로 저장되어 JuiceFS의 파일 속성 시스템에 기록될 수 있습니다. 하지만 LOCK 상태는 다릅니다—현재 서비스 프로세스 메모리에 보관됩니다. 단일 인스턴스 배포(Single-instance deployments)에서는 일반적으로 문제가 없지만, 다중 인스턴스 배포(multi-instance deployments)에서는 서로 다른 인스턴스가 락 상태를 자동으로 동기화할 수 없습니다.

이러한 제한 사항들은 보통 Finder 브라우징, 간단한 공유, 또는 DAV/rclone 동기화에는 영향을 미치지 않습니다. 하지만 애플리케이션이 WebDAV 파일 잠금(file lock) 의미론에 강하게 의존하는 경우, 배포 모드와 클라이언트 동작을 별도로 확인해야 합니다.

S3 Gateway와 WebDAV는 동일한 JuiceFS 클라이언트 초기화 경로를 공유하며 동일한 파일 시스템 네임스페이스에 액세스합니다. 차이점은 S3 Gateway가 오브젝트 의미론(object semantics)을 파일 시스템 작업으로 변환해야 하는 반면, WebDAV는 파일 접근 의미론에 더 가깝다는 것입니다.

따라서, 어떤 액세스 방법을 선택할지는 궁극적으로 애플리케이션 자체에 달려 있습니다. 즉, 데이터가 오브젝트로 구성되어 있는지 아니면 파일 및 디렉터리로 작동하는지에 따라 달라집니다.

이 아티클에 대한 피드백이나 공유하고 싶은 아이디어가 있다면, GitHub의 토론에 참여하여 저희 커뮤니티인 Discord에 가입해 주시기를 바랍니다.