데이터베이스 스냅샷

데이터베이스 스냅샷은 데이터베이스 store의 특정 시점 view를 제공한다. Sui에서 데이터베이스 스냅샷은 특정 node에서 한 에포크의 끝 시점에 실행 중인 데이터베이스가 바라본 Sui 네트워크의 view를 포착한다. validators도 스냅샷을 활성화할 수 있지만, 일반적으로는 풀 노드 운영자에게 가장 가치가 크다.

Sui 네트워크의 스냅샷은 풀 노드 운영자가 genesis 이후 발생한 모든 트랜잭션을 실행하지 않고도 풀 노드를 bootstrap할 수 있게 한다. 스냅샷은 S3, Google Cloud 스토리지, Azure Blob 스토리지 같은 원격 객체 스토어와 유사 서비스에 업로드할 수 있다. 이러한 서비스는 일반적으로 export process를 백그라운드에서 실행하므로 풀 노드 성능이 저하되지 않는다. 스냅샷을 cloud에 저장하면 시스템이나 하드웨어의 catastrophic failures에서 더 쉽고 빠르게 복구할 수 있다.

건전한 Sui 네트워크를 유지하기 위해 Sui는 네트워크 전반에서 더 강한 데이터 availability를 보장할 수 있도록 Sui community가 추가 스냅샷을 운영하기를 장려한다.

지원 snapshot 유형

Sui는 두 가지 유형의 스냅샷을 지원한다:

• RocksDB 스냅샷은 데이터베이스 store의 특정 시점 view이다. 이는 snapshot이 snapshot을 생성한 순간의 시스템 state를, pruning되지 않은 데이터, 추가 indices, 기타 데이터를 포함해 유지한다는 뜻이다.
• 포멀 스냅샷은 minimalistic한 데이터베이스-agnostic format이다. 다시 말해, 지정한 에포크에서 노드를 유효한 state로 복원하는 데 필요한 데이터만 담는다. 따라서 스토리지 footprint가 훨씬 작고, 일반적으로 데이터베이스 스냅샷보다 복원이 더 빠르다. 포멀 스냅샷은 Sui 프로토콜에서도 기본적으로 지원된다. 이 맥락에서 복원하려는 에포크의 committee가 제공한 commitment와 포멀 스냅샷의 내용을 암호학적으로 검증할 수 있다. 이 검증은 포멀 스냅샷 restore 중에 자동으로, 그리고 기본적으로 수행된다(명시적으로 우회하지 않는 한).

정보

포멀 스냅샷은 과거 데이터 lookup을 수행하는 RPC 노드를 운영하는 경우에는 적합하지 않다. node 데이터 management에 대한 자세한 내용은 데이터 관리를 참고한다.

풀 노드 스냅샷은 각 에포크 끝에서 state snapshot을 생성하도록 구성할 수 있다. 단일 풀 노드는 RocksDB 스냅샷, 포멀 스냅샷, 또는 둘 다 생성할 수 있다.

포멀 스냅샷

포멀 스냅샷은 genesis 이후 발생한 모든 트랜잭션을 실행하지 않고도, 노드가 과거의 특정 시점에 canonical state(에포크 끝 시점의 fully pruned and compacted node state)로 복원할 수 있는 메커니즘을 제공한다. 기존 데이터베이스 스냅샷과 달리, 이러한 포멀 스냅샷은 다음과 같은 속성을 가진다:

1. Minimalism: 포멀 스냅샷은 현재 에포크 끝의 활성 객체 집합(향후 트랜잭션의 input 객체로 사용할 수 있는 모든 객체 versions의 집합)만 포함한다. Sui는 다른 중요한 chain 정보는 chain에서 동기화하거나 파생한다. 따라서 포멀 스냅샷은 노드가 에포크 boundary에서 시작해 네트워크에 참여하는 데 필요한 데이터만 포함한다.
2. Agnosticism: 포멀 스냅샷은 본질적으로 프로토콜의 기반 데이터베이스 선택이나 구현과 무관하다. live 객체 set이 프로토콜에 의해 정의되므로 포멀 스냅샷도 마찬가지이다.
3. Verifiability: 포멀 스냅샷은 핵심 Sui 프로토콜에서 first-class support를 받는다. 따라서 node operator는 다운로드할 때 이를 trustless/verifiable하게 확인할 수 있어야 한다. 이를 지원하기 위해 프로토콜은 에포크 끝의 live 객체 state에 대한 commitment에 서명하고, restore 시점에 포멀 스냅샷은 이 commitment와 대조해 검사된다. 이 검증이 실패하면 node state는 snapshot restore를 시도하기 전 상태로 되돌아간다.

이 스냅샷에는 indexes가 없으므로 validators와 상태 동기화 풀 노드(SSFNs)에 가장 즉각적으로 유용하다. 스냅샷은 S3, Google Cloud 스토리지, Azure Blob 스토리지 같은 원격 객체 스토어와 유사 서비스에 업로드할 수 있다. 이러한 서비스는 일반적으로 export process를 백그라운드에서 실행하므로 풀 노드 성능이 저하되지 않는다. 스냅샷을 cloud에 저장하면 시스템이나 하드웨어의 catastrophic failures에서 더 효율적으로 복구할 수 있다.

snapshot으로 풀 노드 복원

RocksDB snapshot으로 복원

RocksDB snapshot으로 복원하려면 다음 단계를 따른다:

1. 복원하려는 에포크의 snapshot을 local disk에 다운로드한다. S3 bucket에는 에포크마다 snapshot이 하나 있다.

2. snapshot을 fullnode.yaml 파일에서 db-path 값이 가리키는 directory에 둔다. 예를 들어 db-path 값이 /opt/sui/db/authorities_db/full_node_db를 가리키고 에포크 10에서 복원하려면 다음 명령으로 해당 directory에 snapshot을 복사한다:

   다운로드에 사용할 credentials가 있다면 AWS CLI를 사용할 수 있다: aws s3 cp s3://<BUCKET_NAME>/epoch_10 /opt/sui/db/authorities_db/full_node_db/live --recursive --request-payer requester.

3. aws s3 cp(또는 gsutil cp)를 사용하면 데이터베이스는 --path에 전달한 위치 아래 epoch_[NUM]라는 이름의 directory로 복사된다. epoch_[NUM] directory를 노드의 live/ 아래 db_path로 이름 변경한다. 예를 들어 cp -r /tmp/epoch_[NUM] /opt/sui/db/authorities_db/full_node_db/live를 사용한다.

4. 다운로드한 directory의 ownership을 sui user(sui-node를 실행하는 Linux user)에 맞게 업데이트해야 한다. sudo chown -R sui:sui /opt/sui/db/authorities_db/full_node_db/live.

5. Sui 노드를 시작한다.

정보

스냅샷에서 풀 노드를 복원할 때는 /opt/sui/db/authorities_db/full_node_db/live 경로에 써야 한다. validator 노드를 복원할 때는 데이터베이스 대상 경로를 /opt/sui/db/authorities_db/live로 줄일 수 있다. 경로 위치를 확인하려면 풀 노드 또는 Validator configs의 db_path 필드를 확인한다.

포멀 스냅샷으로 restore

포멀 스냅샷으로 복원하려면 sui-tool binary를 사용한다. 다른 sui-tool binaries와 함께 sui을 다운로드할 수 있다. 자세한 내용은 Sui 설치를 참고한다.

다음 단계에 따라 포멀 스냅샷에서 노드를 복원할 수 있다:

1. 노드가 실행 중이면 중지한다.

2. 다음 명령을 실행한다:

   sui-tool download-formal-snapshot --latest --genesis "<PATH-TO-GENESIS-BLOB>" \
        --network <NETWORK> --snapshot-bucket <BUCKET-NAME> --snapshot-bucket-type <TYPE> \
        --path <PATH-TO-NODE-DB> --num-parallel-downloads 50 --no-sign-request

   • --epoch: 다운로드하려는 에포크이다. Mysten Labs hosted buckets는 마지막 90개 에포크만 보관하므로, suivision이나 suiscan 같은 sui explorers에서 최신 에포크를 확인할 수 있다.
   • --latest: --epoch로 에포크를 명시적으로 전달하는 대신 --latest flag를 전달하면 최신 snapshot이 자동으로 선택된다.
   • --genesis: 네트워크의 genesis.blob 위치 경로이다.
   • --network: snapshot을 다운로드할 네트워크이다. 기본값은 mainnet이다.
   • --path: local filesystem의 snapshot directory 경로이다.
   • --no-sign-request: 설정하면 --snapshot-bucket과 --snapshot-bucket-type은 무시되고 Cloudflare R2를 사용한다.
   • --snapshot-bucket: source snapshot bucket 이름(예: mysten-mainnet-snapshots)이다. --no-sign-request와 함께 사용할 수 없다.
   • --snapshot-bucket-type: snapshot bucket 유형이다. 현재 GCS와 S3를 지원한다. --no-sign-request와 함께 사용할 수 없다.

   --no-sign-request가 설정되지 않은 경우 다음 environment variables를 사용한다:

   • AWS: AWS_SNAPSHOT_ACCESS_KEY_ID, AWS_SNAPSHOT_SECRET_ACCESS_KEY, AWS_SNAPSHOT_REGION
   • GCS: GCS_SNAPSHOT_SERVICE_ACCOUNT_FILE_PATH
   • AZURE: AZURE_SNAPSHOT_STORAGE_ACCOUNT, AZURE_SNAPSHOT_STORAGE_ACCESS_KEY

Mysten Labs 관리형 snapshot

Mysten Labs는 두 계층의 snapshot 스토리지 access를 호스팅한다. High 처리량, Requester Pays enabled buckets와 free, permissionless buckets이다.

High 처리량, Requester Pays enabled buckets:

• GCS와 S3는 둘 다 requester pays로 설정되어 있다. 따라서 이 buckets에서 다운로드할 때 유효한 AWS/GCP credentials 세트를 제공해야 한다. Requester Pays는 snapshot 데이터를 가져오는 egress 비용을 사용자가 부담한다는 뜻이다.
• 가장 빠른 다운로드 속도가 필요하다면 transfer acceleration이 활성화된 S3 buckets 사용을 권장한다.

Free, permissionless buckets:

• 이 buckets는 현재 Cloudflare R2에서 호스팅되며, 현재는 북미에만 있지만 곧 더 많은 리전를 추가할 계획이다.
• bucket이 인터넷에 공개되어 있으므로 cloud credentials를 제공할 필요가 없다.
• 무료 buckets(예: sui-tool download-formal-snapshot --no-sign-request)는 이제 formal snapshots에서만 사용할 수 있다. db snapshot을 다운로드하려면 requester pays(S3 또는 GCS) buckets 중 하나를 사용해야 한다.

bucket 이름

S3

Testnet: s3://mysten-testnet-snapshots/, s3://mysten-testnet-formal/

Mainnet: s3://mysten-mainnet-snapshots/, s3://mysten-mainnet-formal/

GCS

Testnet: gs://mysten-testnet-snapshots/, gs://mysten-testnet-formal/

Mainnet: gs://mysten-mainnet-snapshots/, gs://mysten-mainnet-formal/

snapshot 활성화

풀 노드는 기본적으로 스냅샷을 생성하지 않는다. 이 기능을 활성화하려면 풀 노드에 특정 configs를 적용해야 한다.

다음 단계에 따라 풀 노드의 configs를 변경한다:

1. 노드가 실행 중이면 중지한다.
2. fullnode.yaml 구성 파일을 열고 다음 섹션에 나온 대로 구성 업데이트를 적용한다.
3. fullnode.yaml 파일을 저장한 뒤 노드를 다시 시작한다.

DB snapshot 활성화

구성 파일에 db-checkpoint-config 항목을 추가한다. 예시는 Amazon의 S3 서비스를 사용한다:

db-checkpoint-config:
  perform-db-checkpoints-at-epoch-end: true
  perform-index-db-checkpoints-at-epoch-end: true
  object-store-config:
    object-store: "S3"
    bucket: "<BUCKET-NAME>"
    aws-access-key-id: “<ACCESS-KEY>”
    aws-secret-access-key: “<SHARED-KEY>”
    aws-region: "<BUCKET-REGION>"
    object-store-connection-limit: 20

• object-store: snapshots를 업로드할 원격 객체 스토어이다. 예시에서는 Amazon의 S3 서비스로 설정한다.
• bucket: snapshots를 저장할 S3 bucket 이름이다.
• aws-access-key-id와 aws-secret-access-key: bucket에 write access가 있는 AWS 인증 정보이다.
• aws-region: bucket이 있는 리전이다.
• object-store-connection-limit: 객체 store에 대한 동시 연결 수이다.

포멀 스냅샷 enable

구성 파일에 state-snapshot-write-config 항목을 추가한다. 예시는 Amazon의 S3 서비스를 사용한다:

state-snapshot-write-config:
  object-store-config:
    object-store: "S3"
    bucket: "<BUCKET-NAME>"
    aws-access-key-id: “<ACCESS-KEY>”
    aws-secret-access-key: “<SHARED-KEY>”
    aws-region: "<BUCKET-REGION>"
    object-store-connection-limit: 200

예시에 나온 구성 settings는 AWS S3에 관한 것이지만, GCS, Azure 스토리지, Cloudflare R2도 모두 지원한다.