본문으로 건너뛰기
이 페이지는 영문에서 기계 번역되었으므로 오역이나 어색한 표현이 있을 수 있습니다. 따라서 정확한 정보는 영어 원문을 참조하시기 바랍니다. 또한 잦은 업데이트로 인해 일부 콘텐츠는 영문이 그대로 남아있을 수 있습니다. Crowdin에서 이 페이지의 번역을 개선하는 데 동참하여 도움을 주세요. (Crowdin translation page, Contributing guide)

노드 스토리지 최적화

Kaia v2.1.0은 디스크 공간 요구 사항을 크게 줄일 수 있는 두 가지 보완적인 스토리지 최적화 기능을 도입했습니다:

  • 데이터베이스 압축: 반복적인 블록 데이터를 압축하여 저장 공간을 줄입니다.
  • 플랫트리 상태 체계: 아카이브 노드 상태 데이터베이스 크기를 대폭 줄여주는 실험적 기능

이 가이드에서는 이러한 최적화를 Kaia 노드에 적용하는 방법을 설명합니다.

데이터베이스 압축​

데이터베이스 압축은 LevelDB의 내장된 Snappy 압축을 사용하여 블록 헤더, 트랜잭션 본문 및 영수증의 크기를 줄이며, 이는 종종 ABI 인코딩 트랜잭션에서 제로 패딩과 같은 반복적인 데이터를 포함합니다.

예상 절감액:

  • 전체 노드: ~2TB 감소(메인넷에서 ~4.2TB에서 ~2TB로)

전제 조건​

  • Kaia v2.1.0 이상
  • 수동 압축의 경우: 충분한 디스크 여유 공간과 지속적인 디스크 I/O 수용 능력(아래 리소스 영향 섹션 참조)

새 설치에 압축 사용​

v2.1.0부터는 압축이 기본적으로 활성화됩니다. 노드를 시작하기만 하면 됩니다:

패키지 설치:


# Configure network in kend.conf
sudo vi /etc/kend/conf/kend.conf
# Set: NETWORK=mainnet or NETWORK=kairos
# Start node (compression enabled by default in v2.1.0+)
kend start
# Verify
kend status
tail -f /var/kend/logs/kend.out

새로 작성된 모든 데이터는 자동으로 압축됩니다.

기존 노드에 압축 사용​

v2.1.0 이전 버전에서 업그레이드하는 경우:

1단계: 버전 확인


ken version

2단계: v2.1.0 이상**

압축은 이미 기본적으로 활성화되어 있습니다. 새 데이터는 자동으로 압축됩니다. 기존 데이터를 압축하려면 4단계로 건너뜁니다.

3단계: v2.1.0 이전 버전만 해당****

구성에 압축 플래그를 추가합니다:

패키지 설치:


sudo vi /etc/kend/conf/kend.conf
# Add to ADDITIONAL variable:
ADDITIONAL="--db.leveldb.compression 2"

압축 플래그 값은 다음과 같습니다:

  • 0: 압축 없음
  • 1: 영수증만 압축
  • 2: 헤더, 본문 및 영수증 압축(권장)
  • 3: 상태 트라이를 포함한 모든 테이블 압축(권장하지 않음)
노트

옵션 2는 상태 테스트 데이터가 잘 압축되지 않으므로(무작위로 표시됨) 옵션 3은 최소한의 추가 이점을 제공하므로 권장됩니다.

그런 다음 다시 시작합니다:


kend stop
kend start

4단계: 기존 데이터 압축(선택 사항이지만 권장)

RPC를 통해 데이터베이스 압축을 트리거합니다. 노드 콘솔에 연결합니다:


ken attach --datadir /var/kend/data

콘솔에서 "allbutstate" 프리셋을 사용하여 압축을 트리거합니다:


> debug.chaindbCompact({ "preset": "allbutstate" })
null

사용 가능한 프리셋:

  • "기본값": 모든 데이터베이스 구성 요소의 전체 범위 압축
  • "allbutstate": 상태 트라이를 제외한 선택적 압축(압축에 권장)
  • "custom"`: 특정 데이터베이스 테이블에 대한 사용자 지정 범위 정의

압축은 백그라운드에서 실행됩니다. 노드 로그에서 진행 상황을 모니터링하세요:


tail -f /var/kend/logs/kend.out | grep -i Compact

다음과 같은 로그 항목이 표시되어야 합니다:


INFO[07/25,12:50:17 Z] [3] Compacting database started range=0x48-0x49
INFO[07/25,12:55:17 Z] [3] Compacting database completed range=0x48-0x49 elapsed=5m0.085s

노드는 압축하는 동안 블록을 계속 처리합니다.

**예상 소요 시간: 메인넷 풀 노드의 경우 약 10시간(최대 4TB 데이터의 SSD 사용 시). 기간은 하드웨어 및 데이터 크기에 따라 다릅니다.

리소스 영향:

  • 높은 디스크 I/O(피크 >400 MiB/s 읽기, >300 MiB/s 쓰기)
  • 높은 디스크 IOPS(종종 초당 2000개 이상의 작업)
  • 노드는 계속 작동하며 블록을 계속 동기화합니다.
노트

압축하는 동안 노드는 계속 작동하지만, I/O가 집중되는 기간에는 쿼리 성능이 영향을 받을 수 있습니다. 프로덕션 RPC 노드의 경우 유지보수 기간이나 트래픽이 적은 기간에 압축을 예약하세요.

사전 압축된 체인데이터 스냅샷 사용(미정)​

사전 압축된 체인데이터 스냅샷은 향후 릴리스에서 제공될 예정이지만 아직 제공되지 않습니다. 사용 가능한 경우 체인데이터 스냅샷 페이지에 나열됩니다.

현재로서는 둘 중 하나를 선택해야 합니다:

  • 새 v2.1.0 이상 설치 시 압축 사용(새 데이터의 경우 자동)
  • 기존 노드에서 수동 압축 실행(위 참조)

스냅샷 페이지에서 압축 스냅샷 가용성에 대한 업데이트를 주기적으로 확인하세요.

압축이 활성 상태인지 확인​

노드 시작 로그에서 압축 구성을 확인하세요:


grep "compressionType" /var/kend/logs/kend.out

상태 트리가 아닌 테이블에 대해 '압축 유형=스나피'를 나타내는 로그 항목을 찾습니다.

모니터링 및 문제 해결​

디스크 사용량 감소 확인:


du -h --max-depth=1 /var/kend/data/klay/chaindata

압축 전과 후를 비교하세요. 블록 본문과 영수증이 포함된 디렉터리에서 저장 공간이 크게 줄어든 것을 확인할 수 있습니다.

일반적인 문제:

  1. 압축 실패: 충분한 디스크 공간을 확보하세요. 압축은 일시적으로 데이터 재작성을 위한 추가 공간이 필요합니다.
  2. FlatTrie가 시작되지 않았습니다: FlatTrie에는 빈 데이터베이스가 필요합니다. 기존 데이터에 대한 오류가 표시되면 체인데이터 디렉터리를 삭제하고 제네시스에서 동기화하세요.
  3. 메르클 증명 API 오류: FlatTrie는 eth_getProof를 지원하지 않습니다. 이 API가 필요한 경우 기존 노드를 사용하세요.

플랫트리 상태 체계(실험적)​

플랫트리는 에리곤 이더리움 클라이언트에서 채택한 실험적인 상태 저장 방식입니다. 플랫 구조로 계정 상태를 저장하고 최신 블록의 완전한 머클 패트리샤 트리(MPT)만 유지하며, 필요에 따라 과거 시도를 재구성합니다.

예상 절감액:

  • 총 저장 공간: ~최대 75% 감소(카이로스 테스트넷 결과에서 예상)
  • 카이로스 테스트넷: 4.3TB → 1TB
  • 메인넷: ~35TB → ~10TB(비례적 감소에 따른 추정치)
경고

FlatTrie는 v2.1.0의 실험적 기능입니다. 프로덕션용으로는 권장하지 않습니다. 향후 릴리스에서는 잠재적인 안정성 문제, 성능 병목 현상 및 획기적인 변경 사항이 발생할 수 있습니다. 테스트 및 개발 환경에서만 사용하세요.

전제 조건​

  • Kaia v2.1.0 이상
  • 제네시스에서 동기화해야 함(기존 데이터베이스를 변환할 수 없음)
  • 빈 데이터 디렉터리

현재 제한 사항​

FlatTrie를 활성화하기 전에 이러한 제한 사항을 이해하세요:

지원되지 않는 기능:

  • 일괄 가지 치기 및 라이브 가지 치기
  • 블록 되감기(--start-block-number 플래그 및 debug_setHead API)
  • 머클 증명 생성(eth_getProof API)

비호환성:

  • 기존 데이터베이스에서 마이그레이션할 수 없습니다(제네시스부터 시작해야 함).
  • 플랫트리 모드와 비플랫트리 모드 간에 전환할 수 없습니다.
  • FlatTrie가 있는 데이터베이스와 없는 데이터베이스는 호환되지 않습니다.

플랫트리 사용​

1단계: 빈 데이터 디렉터리 준비


# Ensure clean data directory
sudo rm -rf /var/kend/data
sudo mkdir -p /var/kend/data

2단계: FlatTrie 플래그로 노드를 시작하고 제네시스로부터 동기화


# Mainnet
ken --state.experimental-flat-trie
# Kairos testnet
ken --state.experimental-flat-trie --kairos

노트

FlatTrie가 활성화되면 --gcmode 및 --state.block-interval 플래그에 관계없이 아카이브 모드가 자동으로 활성화됩니다. 플랫트리를 사용할 때는 이러한 플래그가 무시됩니다.

3단계: 전체 동기화 대기

노드는 제네시스의 모든 블록을 동기화합니다. 하드웨어와 네트워크에 따라 몇 주가 소요될 수 있습니다.

플랫트리가 활성 상태인지 확인​

노드 시작 로그를 확인하여 FlatTrie 모드를 확인하세요:


grep -i "flat" /var/kend/logs/kend.out | head -20

실험적인 플랫 트라이가 활성화되어 있다는 표시가 나타납니다.

플랫트리 성능 모니터링​

FlatTrie는 기존 상태 스토리지와 다른 리소스 프로필을 사용합니다:

예상되는 특성:

  • CPU 사용량 감소
  • 더 높은 메모리 사용량(~30GB)
  • 더 많은 고루틴 횟수(~900-1000)
  • 블록 확정 시간 단축

노드의 Prometheus 메트릭 엔드포인트 또는 Grafana 대시보드를 통해 이러한 메트릭을 모니터링하세요.

플랫트리 문제 해결​

기존 데이터베이스에서 FlatTrie를 시작할 수 없음: 비어 있지 않은 데이터에서 FlatTrie를 활성화할 수 없다는 오류가 표시되면 제네시스부터 시작해야 합니다. 체인데이터 디렉토리를 삭제하고 --state.experimental-flat-trie 플래그를 사용하여 전체 동기화를 수행합니다.

머클 증명 API 오류: FlatTrie는 eth_getProof 및 관련 머클 증명 API를 지원하지 않습니다. 애플리케이션에 이러한 API가 필요한 경우 기존 노드를 대신 사용하세요.

높은 메모리 사용량: 동기화 중 FlatTrie 노드에 약 30GB의 메모리 사용량이 예상됩니다. 시스템에 충분한 RAM이 있는지 확인합니다. 팀은 향후 버전에서 이 문제를 줄이기 위해 최적화 작업을 진행 중입니다.

느린 동기화 속도: FlatTrie를 사용한 초기 동기화는 기존 노드와 비슷합니다. 동기화 속도가 현저히 느리다면 확인해 보세요:

  • 디스크 I/O 성능(SSD 적극 권장)
  • 네트워크 대역폭
  • CPU 사용률

모범 사례​

  1. 주요 변경 전에는 항상 백업하세요: 특히 수동 압축을 실행하기 전에.
  2. 디스크 공간 모니터링: 압축하기 전에 충분한 여유 공간이 있는지 확인합니다. 압축은 일시적으로 데이터베이스 파일을 다시 쓰기 위한 추가 공간을 필요로 합니다.
  3. 트래픽이 적은 시간대에 압축을 예약하세요: 퍼블릭 RPC 엔드포인트를 실행하는 경우.
  4. 프로덕션 노드에 SSD 사용: 압축과 FlatTrie 모두 빠른 랜덤 I/O의 이점을 누릴 수 있습니다.
  5. 실험적 기능 계획: FlatTrie는 v2.1.x에서 실험 중입니다. 프로덕션 사용 전에 철저히 테스트하세요.
  6. 계속 업데이트: 향후 최적화에 대한 릴리스 노트와 FlatTrie가 실험적 상태를 졸업하는 시기를 확인하세요.
페이지를 개선해 주세요