트랜잭셔널 미러링(Transactional Mirroring)

원문 보기 위키 갱신 2026.10.11

lakeFS Team 및 lakeFS Enterprise에서 제공되는 기능이에요. 무료 체험을 시작하거나 문의하기를 통해 연락해 보세요.

출처: 문서

본문

lakeFS 트랜잭셔널 미러링이란?

lakeFS의 트랜잭셔널 미러링은 lakeFS 리포지토리("소스")를 서로 다른 위치의 읽기 전용 복사본("미러")으로 복제할 수 있게 해 줘요.

일반적인 미러링과 달리 데이터를 단순히 리전 간 복사하지 않아요 - lakeFS는 각 커밋의 상태를 추적하고, 커밋이 완전히 복제되어 모든 데이터가 준비되었을 때에만 미러의 커밋 로그를 진행시켜요.

사용 사례

재해 복구

보통 객체 스토리지는 재해 복구를 위해 복제/배치 복사 API를 제공해요: 새 객체가 쓰이는 대로 다른 지리적 위치로 비동기 복사되죠.

리전 장애가 발생하면 사용자는 비교적 최신 상태를 담고 있어야 할 다른 지리적 위치에 의존할 수 있어요.

문제는 재해 시점에 무엇이 도착했고 무엇이 도착하지 않았는지 판단하는 일이에요:

주어진 데이터셋에 필요한 모든 파일이 도착했나요?
데이터셋 간 의존성이 있다면 모든 의존성도 최신인가요?
지금 전송 중이거나 복제조차 시작하지 않은 것은 무엇인가요?

이런 판단은 만만치 않아요. 특히 리전 단위 재해 상황에서 더욱 그렇죠. 하지만 비즈니스 연속성을 보장하려면 이런 답이 필요할 수 있어요.

lakeFS 트랜잭셔널 미러링을 사용하면 이 답을 훨씬 쉽게 얻을 수 있어요: 복제본에 존재하는 최신 커밋은 일관된 상태이며 완전히 사용 가능하다는 것이 보장돼요. 절대 최신 커밋이 아니더라도 알려진, 일관된 시점을 반영하죠.

데이터 지역성(Data Locality)

일부 워크로드에서는 데이터를 여러 리전에 두는 편이 더 저렴할 수 있어요: GPU 같은 고가 하드웨어는 가격이 변동하니, 현재 가장 유리한 가격을 제공하는 리전을 고르고 싶겠죠. 그 차이가 복제 데이터 비용을 충분히 상쇄할 수 있어요.

과제는 재현성이에요 - ML 학습 작업이 객체 스토리지의 어떤 경로에서 이미지 파일을 읽는다고 해 봐요. 학습 시점에 어떤 파일들이 존재했을까요?

데이터가 리전 사이를 계속 흐른다면 이 답은 생각보다 어려워요. 그리고 답을 알더라도 프로세스를 다시 실행하고 싶을 때(예: 문제 해결을 위한 모델 재구축) 그 정확한 상태를 어떻게 재현할까요?

일관된 커밋이 이 문제를 해결해요 - lakeFS 트랜잭셔널 미러링을 사용하면 커밋 ID가 어느 위치에 있든 항상 정확히 동일한 데이터를 담는다는 것이 보장돼요.

리전 A에서 모델을 학습하고, 한 달 뒤 같은 커밋 ID를 다른 리전에 넣어도 동일한 결과를 얻을 수 있어요.

아키텍처 개요

최소한의 트랜잭셔널 미러링은 서로 다른 리전/위치에 있는 두 개의 lakeFS Enterprise 설치와, 각 설치 옆에서 실행되는 **복제 서비스(replication service)**로 구성돼요:

소스 lakeFS - 데이터가 쓰이는 기본 설치.
대상 lakeFS - 읽기 전용 미러 리포지토리를 호스팅하는 설치.
복제 서비스 - 각 lakeFS 설치 옆에 배포되는 사이드카 서비스. 소스 리포지토리를 모니터링하고, 커밋 메타데이터를 동기화하며, 모든 데이터가 준비되면 대상에서 브랜치를 승격해요. 브랜치만 복제되고 태그는 미러링되지 않아요.
객체 스토리지 복제 - 기반 객체 스토리지(예: S3)가 소스 버킷과 대상 버킷 사이 객체 복제를 수행하도록 구성되어야 해요. lakeFS는 객체 데이터 자체를 복사하지 않아요.
미러 데이터베이스 - 모든 복제 서비스가 미러 상태를 조율하는 데 사용하는 공유 데이터베이스(예: DynamoDB 글로벌 테이블).

멀티 리전 토폴로지

아키텍처는 두 리전에 국한되지 않아요. 소스 리포지토리는 여러 대상으로 미러링될 수 있고(일대다), 각 설치는 여러 미러링 관계에 참여할 수 있어요. dst_endpoints 항목을 추가하고 대상마다 객체 스토리지 복제를 구성하기만 하면 돼요.

트랜잭셔널 미러링 설정

사전 준비

각각 다른 리전/위치에 있는 두 개 이상의 lakeFS Enterprise 설치.
트랜잭셔널 미러링 기능이 포함된 유효한 lakeFS Enterprise 라이선스. 라이선스 구성을 참고하세요.
소스 버킷과 대상 버킷 사이에 구성된 객체 스토리지 복제 (아래 참고).
모든 리전에서 접근 가능한 미러 조율용 공유 데이터베이스 (예: DynamoDB 글로벌 테이블).
네트워크 연결: 각 리전의 복제 서비스가 다른 리전의 lakeFS API 엔드포인트에 HTTP로 접근할 수 있어야 해요.

객체 스토리지 복제 구성

리포지토리 내 객체는 클라우드 제공자의 객체 스토리지 복제 메커니즘으로 복사돼요.

AWS S3Other object stores

소스 lakeFS 리포지토리의 스토리지 네임스페이스에서 대상 버킷으로 복제를 구성하려면 AWS S3 복제 문서를 참고하세요.

복제 규칙을 설정하면 이후의 새 객체가 대상 버킷으로 복제돼요.

기존 객체를 복제하려면 S3 배치 복제를 사용하세요.

Tip

양방향 미러링(각 리전이 일부 리포지토리의 소스 역할)을 원한다면 양방향으로 복제 규칙을 구성하세요.

소스 스토리지 네임스페이스에서 대상 버킷으로 객체를 복제하도록 객체 스토리지의 네이티브 복제 메커니즘을 구성하세요. 구체적 단계는 클라우드 제공자에 따라 달라요.

"복제자(replicator)" 정책을 가진 lakeFS 사용자 만들기

각 lakeFS 설치에서 Administration 아래에 복제 서비스가 사용할 새 사용자를 만드세요. 이 사용자에는 다음 RBAC 정책이 붙어야 해요:

{
   "id": "ReplicationPolicy",
   "statement": [
      {
         "action": [
            "fs:ReadRepository",
            "fs:CreateRepository",
            "fs:UpdateRepository",
            "fs:DeleteRepository",
            "fs:ListRepositories",
            "fs:AttachStorageNamespace",
            "fs:ReadObject",
            "fs:WriteObject",
            "fs:DeleteObject",
            "fs:ListObjects",
            "fs:CreateCommit",
            "fs:ReadCommit",
            "fs:ListCommits",
            "fs:CreateBranch",
            "fs:DeleteBranch",
            "fs:RevertBranch",
            "fs:ReadBranch",
            "fs:ListBranches",
            "fs:ListMirrors"
         ],
         "effect": "allow",
         "resource": "*"
      }
   ]
}

대신 특정 리포지토리와/또는 미러로만 범위를 좁힌 정책을 만들 수도 있어요:

{
   "id": "ReplicationPolicy",
   "statement": [
      {
         "action": [
            "fs:ListRepositories"
         ],
         "effect": "allow",
         "resource": "*"
      },
      {
         "action": [
            "fs:ReadRepository",
            "fs:ReadObject",
            "fs:ListObjects",
            "fs:ReadCommit",
            "fs:ListCommits",
            "fs:ReadBranch",
            "fs:ListBranches",
            "fs:ListMirrors"
         ],
         "effect": "allow",
         "resource": "arn:lakefs:fs:::repository/{sourceRepositoryId}"
      },
      {
         "action": [
            "fs:ReadRepository",
            "fs:CreateRepository",
            "fs:UpdateRepository",
            "fs:DeleteRepository",
            "fs:AttachStorageNamespace",
            "fs:ReadObject",
            "fs:WriteObject",
            "fs:DeleteObject",
            "fs:ListObjects",
            "fs:CreateCommit",
            "fs:ReadCommit",
            "fs:ListCommits",
            "fs:CreateBranch",
            "fs:DeleteBranch",
            "fs:RevertBranch",
            "fs:ReadBranch",
            "fs:ListBranches"
         ],
         "effect": "allow",
         "resource": "arn:lakefs:fs:::repository/{mirrorId}"
      },
      {
         "action": [
            "fs:AttachStorageNamespace"
         ],
         "effect": "allow",
         "resource": "arn:lakefs:fs:::namespace/{DestinationStorageNamespace}"
      }
   ]
}

사용자가 만들어지고 복제 정책이 붙으면 복제 서비스용 액세스 키와 시크릿을 생성하세요.

모든 설치에서 동일한 자격 증명 사용

복제 서비스는 동일한 lakeFS 자격 증명으로 여러 리전에 걸친 요청을 인증해요. 복제 사용자는 미러링에 참여하는 모든 lakeFS 설치에서 동일한 액세스 키 ID와 시크릿 액세스 키를 가져야 해요.

lakefs create-credentials로 각 설치에 특정 자격 증명을 가진 사용자를 만드세요:

lakefs create-credentials --access-key-id <ACCESS_KEY_ID> --secret-access-key <SECRET_ACCESS_KEY> <username>

복제 사용자가 어디서나 동일한 자격 증명을 갖도록 각 lakeFS 설치에 이 명령을 실행하세요.

복제 서비스 배포

복제 서비스는 lakeFS Helm 차트로 각 lakeFS Enterprise 설치 옆에 배포돼요. 같은 Helm 릴리스 안에서 별도의 Deployment로 실행되며, 소스뿐 아니라 미러링에 참여하는 모든 리전에 배포되어야 해요.

미러 데이터베이스

복제 서비스는 리전 간 미러 상태를 조율할 공유 데이터베이스가 필요해요. 이 데이터베이스는 양쪽 리전에서 접근 가능해야 해요. lakeFS와 동일한 데이터베이스 유형을 지원해요(데이터베이스 구성 참고). 테이블/스키마는 아직 없다면 복제 서비스가 시작 시 자동 생성해요.

DynamoDBPostgreSQL / CockroachDB

mirrors_database 설정에 테이블 이름을 제공하세요. 복제 서비스가 없으면 자동으로 테이블을 만들어요.

크로스 리전 복제를 활성화하려면 테이블을 대상 리전에 복제본을 둔 DynamoDB 글로벌 테이블로 구성해야 해요. 이를 위해 테이블에 NEW_AND_OLD_IMAGES 뷰 유형으로 DynamoDB Streams를 활성화해야 해요.

크로스 계정 구성은 DynamoDB 멀티 계정 글로벌 테이블을 참고하세요.

양쪽 리전에서 접근 가능한 PostgreSQL 또는 CockroachDB 데이터베이스를 제공하세요. 각 설치의 mirrors_database 구성에 동일한 연결 문자열을 사용하세요.

Helm 차트 구성

각 lakeFS 설치의 values.yaml에서 복제 서비스를 활성화하세요:

replication:
  enabled: true
  image:
    repository: treeverse/replication
    tag: <version>
  serviceAccountName: <service-account-with-required-permissions>
  extraEnvVarsSecret: <secret-name>  # K8s secret containing replication credentials
  config:
    # Identifier for the region where this lakeFS installation runs
    region: "us-east-1"

    # Organization identifiers
    organization_id: "my-org"

    # The lakeFS endpoint in this region (accessible from within the cluster)
    regional_endpoint: "http://lakefs.default.svc.cluster.local:80"

    # lakeFS endpoints in other regions that this installation mirrors to/from
    dst_endpoints:
      us-west-2: "https://lakefs-west.example.com"

    # Mirror coordination database (must be shared between all regions)
    mirrors_database:
      type: dynamodb
      dynamodb:
        table_name: lakefs-replication-table
        aws_region: us-east-1

    # Block storage configuration (must match the lakeFS blockstore config)
    blockstore:
      type: s3
      s3:
        region: us-east-1

    auth:
      encrypt:
        # Must match the auth.encrypt.secret_key used by the lakeFS installation
        secret_key: "<same-secret-key-as-lakefs>"

    logging:
      level: INFO
      format: json

Note

refstore_database(복제 메타데이터용)는 lakeFS database 구성에서 자동으로 채워져요. 별도 데이터베이스를 쓰고 싶지 않다면 설정할 필요가 없어요.

복제 자격 증명 시크릿

복제 사용자 자격 증명과 인증 암호화 키를 담은 Kubernetes 시크릿을 만드세요:

kubectl create secret generic replication-secrets \
  --from-literal=source_lakefs_access_key_id=<ACCESS_KEY_ID> \
  --from-literal=source_lakefs_secret_access_key=<SECRET_ACCESS_KEY> \
  --from-literal=auth_encrypt_secret_key=<AUTH_ENCRYPT_SECRET_KEY>

각 항목의 의미:

ACCESS_KEY_ID & SECRET_ACCESS_KEY - 이전 단계에서 만든 복제 사용자의 자격 증명.
AUTH_ENCRYPT_SECRET_KEY - lakeFS 설치에 구성된 auth.encrypt.secret_key와 반드시 동일해야 해요. 복제 서비스가 요청을 인증하는 데 필요해요.

그다음 Helm values에서 이 시크릿을 참조하세요:

replication:
  extraEnvVarsSecret: replication-secrets

예시: AWS의 두 리전 구성

us-east-1(소스)과 us-west-2(대상) lakeFS가 있는 두 리전 구성의 전체 예시예요.

소스 리전(us-east-1) 복제 구성:

replication:
  enabled: true
  config:
    region: "us-east-1"
    organization_id: "my-org"
    regional_endpoint: "http://lakefs-source.mirroring.svc.cluster.local:80"
    dst_endpoints:
      us-west-2: "http://lakefs-dest-internal.example.com:80"
    mirrors_database:
      type: dynamodb
      dynamodb:
        table_name: my-replication-table
        aws_region: us-east-1
    blockstore:
      type: s3
      s3:
        region: us-east-1
    auth:
      encrypt:
        secret_key: "<shared-secret>"
    logging:
      level: INFO

대상 리전(us-west-2) 복제 구성:

replication:
  enabled: true
  config:
    region: "us-west-2"
    organization_id: "my-org"
    regional_endpoint: "http://lakefs-dest.mirroring.svc.cluster.local:80"
    dst_endpoints:
      us-east-1: "http://lakefs-source-internal.example.com:80"
    mirrors_database:
      type: dynamodb
      dynamodb:
        table_name: my-replication-table
        aws_region: us-west-2
    blockstore:
      type: s3
      s3:
        region: us-west-2
    auth:
      encrypt:
        secret_key: "<shared-secret>"
    logging:
      level: INFO

Important

두 설치는 동일한 organization_id와 동일한 auth.encrypt.secret_key를 사용해야 해요. mirrors_database 테이블은 양쪽 리전에서 접근 가능한 글로벌/공유 테이블이어야 해요.

미러 만들기

두 lakeFS 설치와 복제 서비스가 모두 실행되면 소스 리전 복제 서비스의 복제 API를 호출해 미러를 만드세요. 이 호출은 한 번만 하면 돼요 - 대상 복제 서비스가 새 미러를 자동 감지하고 대상에 리포지토리를 생성해요.

curl '<REPLICATION_ENDPOINT>/service/replication/v1/repositories/<SOURCE_REPO>/mirrors' \
--header 'Content-Type: application/json' \
-u <ACCESS_KEY_ID>:<SECRET_ACCESS_KEY> \
-X POST \
--data '{
    "name": "<MIRROR_NAME>",
    "region": "<DESTINATION_REGION>",
    "storage_namespace": "<MIRROR_STORAGE_NAMESPACE>"
}'

사용되는 파라미터:

REPLICATION_ENDPOINT - 소스 리전 복제 서비스의 URL
SOURCE_REPO - 복제 소스 역할을 하는 리포지토리 이름. 소스 설치에 존재해야 해요
ACCESS_KEY_ID & SECRET_ACCESS_KEY - 여러분의 lakeFS 복제 사용자 자격 증명 (아래 나열된 RBAC 권한이 있는지 확인하세요)
MIRROR_NAME - 대상에 생성될 읽기 전용 미러의 이름
DESTINATION_REGION - 대상의 리전 식별자 (대상 복제 서비스에 구성된 region과 일치해야 해요)
MIRROR_STORAGE_NAMESPACE - 복제된 데이터가 저장되는 대상 버킷의 스토리지 네임스페이스

트랜잭셔널 미러링과 가비지 컬렉션

미러된 리포지토리에서는 가비지 컬렉션이 실행되지 않아요. 가비지 컬렉션의 삭제는 소스에서 복제되어야 해요:

소스 버킷에서 DELETED 마커 복제를 활성화하세요.
대상 버킷에 DELETED 마커가 붙은 객체를 삭제하는 라이프사이클 정책을 만드세요.

RBAC

트랜잭셔널 미러링 작업에 필요한 RBAC 권한이에요:

미러 생성:

Action	ARN
fs:CreateRepository	arn:lakefs:fs:::repository/{mirrorId}
fs:MirrorRepository	arn:lakefs:fs:::repository/{sourceRepositoryId}
fs:AttachStorageNamespace	arn:lakefs:fs:::namespace/{storageNamespace}

미러된 브랜치 편집:

Action	ARN
fs:MirrorRepository	arn:lakefs:fs:::repository/{sourceRepositoryId}

미러 삭제:

Action	ARN
fs:DeleteRepository	arn:lakefs:fs:::repository/{mirrorId}

리포지토리의 미러 목록/조회:

Action	ARN
fs:ListRepositories	*

기타 복제 연산

리포지토리의 모든 미러 나열

curl '<REPLICATION_ENDPOINT>/service/replication/v1/repositories/<SOURCE_REPO>/mirrors' \
-u <ACCESS_KEY_ID>:<SECRET_ACCESS_KEY> -s

특정 미러 조회

curl '<REPLICATION_ENDPOINT>/service/replication/v1/repositories/<SOURCE_REPO>/mirrors/<MIRROR_ID>' \
-u <ACCESS_KEY_ID>:<SECRET_ACCESS_KEY> -s

특정 미러 삭제

curl -X DELETE '<REPLICATION_ENDPOINT>/service/replication/v1/repositories/<SOURCE_REPO>/mirrors/<MIRROR_ID>' \
-u <ACCESS_KEY_ID>:<SECRET_ACCESS_KEY>

구성 레퍼런스

복제 서비스는 Helm 차트 values의 replication.*로 구성해요. 아래 모든 필드는 values.yaml에 설정해요.

Note

단순 설정 값은 REPLICATION_ 접두사 환경 변수로도 설정할 수 있어요 (예: REPLICATION_REGION=us-east-1). dst_endpoints 같은 맵 필드는 설정 파일로만 설정해야 해요. 자격 증명 같은 민감 값은 replication.extraEnvVarsSecret으로 참조되는 Kubernetes Secret으로 제공해야 해요.

Helm 차트 값

Field	Default	Description
replication.enabled	false	true로 설정하면 복제 서비스 배포가 활성화돼요
replication.image.repository	treeverse/replication	Docker 이미지 리포지토리
replication.image.tag	0.1.17	Docker 이미지 태그
replication.image.pullPolicy	IfNotPresent	이미지 pull 정책
replication.port	8008	서비스 포트
replication.serviceAccountName	""	복제 파드용 Kubernetes 서비스 계정. 서비스 계정과 클라우드 권한 참고
replication.extraEnvVarsSecret		민감 구성을 담은 Kubernetes Secret 이름. 설정하면 다음 키가 환경 변수로 주입돼요: source_lakefs_access_key_id, source_lakefs_secret_access_key, auth_encrypt_secret_key
replication.extraEnvVars	[]	복제 파드의 추가 환경 변수
replication.resources	{}	Kubernetes 리소스 requests/limits
replication.podAnnotations	{}	추가 파드 어노테이션
replication.local_cache.base_dir	/cache	로컬 캐시 디렉터리 경로
replication.local_cache.size_bytes	512000000	로컬 캐시 크기(바이트)

서비스 계정과 클라우드 권한

복제 서비스가 클라우드 리소스(예: DynamoDB, S3)에 접근해야 한다면 적절한 어노테이션이 붙은 Kubernetes 서비스 계정으로 권한을 부여하세요. AWS에서는 IAM Roles for Service Accounts (IRSA)를 사용해요. IAM 역할 설정에 대한 자세한 안내는 lakeFS 배포 가이드를 참고하세요.

서비스 계정 예시:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: replication-sa
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>

그다음 Helm values에 replication.serviceAccountName: replication-sa를 설정하세요.

복제 서비스 config (replication.config)

필수 필드

Field	Description
region	이 lakeFS 설치의 리전 식별자 (예: us-east-1)
organization_id	조직 식별자, 미러 데이터베이스에서 파티션 키로 내부 사용돼요. 온프레미스 배포에서는 일관된 문자열(예: 회사 이름)을 사용하세요. 모든 설치에서 동일해야 해요
regional_endpoint	이 리전의 lakeFS API URL (예: http://lakefs.default.svc.cluster.local:80)
dst_endpoints	각 원격 리전의 리전 식별자→lakeFS URL 맵
mirrors_database	미러 조율용 데이터베이스 구성 (DynamoDB, PostgreSQL 또는 CockroachDB). 모든 리전에서 공유되어야 해요. 미러 데이터베이스 참고
blockstore	블록 스토리지 구성. lakeFS 블록스토어 구성과 일치해야 해요
lakefs_access_key_id	복제 lakeFS 사용자의 액세스 키 ID. extraEnvVarsSecret으로도 제공 가능 (권장)
lakefs_secret_access_key	복제 lakeFS 사용자의 시크릿 액세스 키. extraEnvVarsSecret으로도 제공 가능 (권장)
auth.encrypt.secret_key	암호화 시크릿 키. lakeFS auth.encrypt.secret_key와 일치해야 해요. extraEnvVarsSecret으로도 제공 가능 (권장)

선택 필드

Field	Default	Description
organization_name		조직 이름. lakeFS Cloud용 regional_endpoint 자동 구성에만 사용돼요. regional_endpoint가 설정되어 있으면 불필요해요
listen_address	0.0.0.0:8008	복제 서비스 API의 HTTP 리슨 주소
refstore_database		복제 메타데이터(커밋, 범위, 메타범위)용 데이터베이스. Helm 차트로 배포 시 명시적으로 설정하지 않으면 lakeFS 데이터베이스 구성이 기본값이에요. Helm 차트 밖에서 실행할 때는 이 필드가 필수예요
list_mirrors_page_size	1000	미러 나열 시 페이지 크기
list_repositories_page_size	1000	리포지토리 나열 시 페이지 크기
logging.level	INFO	로그 레벨 (DEBUG, INFO, WARN, ERROR)
logging.format	text	로그 형식 (text, json)

커밋된 메타데이터

커밋된 메타데이터(범위와 메타범위) 구성이에요.

Field	Default	Description
committed.local_cache.size_bytes	1073741824 (1 GiB)	로컬 캐시 크기(바이트)
committed.local_cache.dir		캐시 디렉터리 경로
committed.local_cache.range_proportion	0.9	범위에 할당되는 캐시 비율
committed.local_cache.metarange_proportion	0.1	메타범위에 할당되는 캐시 비율
committed.metadata_prefix	_lakefs/	lakeFS가 스토리지 네임스페이스의 메타데이터 파일에 사용하는 프리픽스. lakeFS의 committed.block_storage_prefix와 일치해야 해요

커밋 센서

서비스가 소스에서 대상으로 새 커밋을 감지·동기화하는 방식을 제어해요.

Field	Default	Description
commit_sensor.process_branches_duration	1m	브랜치 변경을 스캔하는 주기
commit_sensor.branches_scanner_concurrency_limit	10	동시 브랜치 스캔 워커 수
commit_sensor.list_branch_page_size	1000	브랜치 나열 시 페이지 크기
commit_sensor.log_commit_page_size	1000	커밋 로그 조회 시 페이지 크기

미러 매니저

서비스가 미러 상태를 조정(미러 리포지토리 생성/삭제)하는 방식을 제어해요.

Field	Default	Description
mirrors_manager.process_mirrors_interval_duration	20s	미러 조정 실행 사이의 간격

검증기

서비스가 미러를 진행시키기 전에 승격된 커밋의 모든 메타데이터가 블록 스토리지에 존재하는지 검증하는 방식을 제어해요.

Field	Default	Description
validator.run_interval	1m	검증 실행 사이의 간격
validator.num_workers	3	동시 메타범위 검증 워커 수
validator.cooldown_on_missing	1m	누락된 메타범위 검증 재시도 전 쿨다운
validator.cooldown_on_error	1m	오류 후 검증 재시도 전 쿨다운
validator.metarange_presence_cache.size	5000	캐시할 메타범위 존재 여부 결과 수
validator.metarange_presence_cache.expiry	1440h (60 days)	메타범위 캐시 항목 만료
validator.metarange_presence_cache.cooldown	30s	캐시의 누락된 메타범위 재시도 전 쿨다운
validator.range_presence_cache.size	500000	캐시할 범위 존재 여부 결과 수
validator.range_presence_cache.expiry	1440h (60 days)	범위 캐시 항목 만료
validator.range_presence_cache.cooldown	10s	캐시의 누락된 범위 재시도 전 쿨다운
validator.object_presence_cache.size	5000000	캐시할 객체 존재 여부 결과 수
validator.object_presence_cache.expiry	24h	객체 캐시 항목 만료
validator.object_presence_cache.cooldown	5s	캐시의 누락된 객체 재시도 전 쿨다운
validator.storage_namespace_cache.size	1000	캐시할 리포지토리→스토리지 네임스페이스 매핑 수
validator.storage_namespace_cache.expiry	17s	스토리지 네임스페이스 캐시 항목 만료

인증

Field	Default	Description
auth.encrypt.secret_key	(required)	저장된 자격 증명의 암호화 키. lakeFS 설치와 일치해야 해요. extraEnvVarsSecret으로도 제공 가능 (권장)
auth.cache.enabled	false	인증 응답 캐싱 활성화
auth.cache.size		캐시된 인증 항목 수
auth.cache.ttl		캐시 항목 time-to-live
auth.cache.jitter		thundering herd를 막기 위해 캐시 TTL에 더해지는 무작위 지터

제한 사항

트랜잭셔널 미러링은 현재 AWS S3에서만 지원돼요
읽기 전용 미러에는 쓸 수 없어요. 트랜잭셔널 미러링은 소스에서 대상으로 향하는 단방향이에요
현재 브랜치만 미러링돼요. 태그와 어느 브랜치에도 속하지 않는 임의 커밋은 복제되지 않아요
lakeFS Hooks는 미러 복제본이 아니라 소스 리포지토리에서만 실행돼요
복제는 비동기적이에요: 브랜치에서 읽으면 항상 소스가 가리킨 유효한 커밋을 반환하지만, 소스 브랜치가 가리키는 최신 커밋이라는 보장은 없어요

더 알아보기 (Learn more)

공식 문서의 트랜잭셔널 미러링 페이지는 https://docs.lakefs.io/admin/mirroring 에서 확인할 수 있어요.