[Infra 시리즈] Kaia v2.1.0 – 블록 데이터 저장소 압축 (기본 설정 + 안전한 컴팩션)

[sean.lin]

Kaia v2.1.0의 “What’s new” 인프라 시리즈의 일환으로, 블록 데이터 저장소 압축에 대한 기술 글을 발행했습니다.

v2.1.0에서 변경된 점

• 블록 관련 테이블에 대해 LevelDB 압축을 켜는 새로운 기본 설정 플래그가 도입되었습니다.

  • 새로운 v2.1.0 노드를 동기화할 때, 별도 튜닝 없이도 압축의 이점을 받을 수 있습니다.

• 이미 많은 히스토리 데이터를 가지고 있는 노드를 위해,

  • 노드가 블록 동기화와 RPC 응답을 계속 유지한 상태에서 디스크 사용량을 줄일 수 있는 안전한 컴팩션 절차를 정리했습니다.

글에서는 다음 내용을 다룹니다:

• 어떤 테이블에 압축을 적용하는지, 그리고 그 이유

• 신규 v2.1.0 배포에서 기본 압축 설정이 어떻게 동작하는지

• 설정 값 확인 방법 및 구성 체크 포인트

• 기존 메인넷 노드에서 컴팩션을 수행하는 절차와, 운영 시 주의해야 할 부분 (디스크 I/O, 소요 시간, 모니터링 등)

운영자가 고려해야 할 사항

v2.1.0으로 업그레이드하셨다면:

• 현재 노드가 의도한 압축 설정으로 동작하고 있는지 한번 확인해 보시길 권장드립니다.

• 장기간 운영 중인 메인넷 노드의 경우, 글에서 제안하는 절차를 기반으로

  • 동기화를 중단하지 않고 디스크를 정리할 수 있는 컴팩션 작업 시간을 계획해 보시면 좋습니다.

전체 글: https://medium.com/kaiachain/노드-저장-공간-절반으로-줄이기-499352015713

앞으로도 v2.1.0에 포함된 인프라 변경 사항들을 중심으로, 노드 운영자와 인프라 사업자에게 도움이 되는 내용을 계속해서 공유할 예정입니다.

[sean.lin]

지난 주 저장소 압축 글에 대한 짧은 follow-up 입니다.

이 변경이 특히 의미 있는 한 가지 상황을 예로 들면:

• 단일 NVMe SSD 위에서 메인넷 풀노드를 오래 운영하고 있다면, v2.1.0의 기본 압축 설정을 적용하고 권장 컴팩션 절차를 한 번 실행하는 것만으로, 블록 히스토리 데이터가 차지하는 디스크 사용량을 체감 가능하게 줄일 수 있습니다. 실제 절감 폭은 노드의 히스토리 길이와 워크로드에 따라 달라집니다.
• 이 차이가 “현재 장비로 계속 버틴다” vs “더 복잡한 샤딩/증설을 고민해야 한다”의 갈림길이 될 수 있습니다.

컴팩션은 동기화를 멈추지 않고 실행하도록 설계되어 있기 때문에, 유지보수 창을 잡아 다운타임 없이 디스크를 정리할 수 있다는 점도 중요합니다.

직접 인프라를 운영 중이거나, 클라우드 RPC에서 자체 노드로 옮기는 것을 고민하고 계시다면 현재 노드 구성과 제약 사항을 댓글로 남겨 주세요. 어떤 문서와 운영 팁을 먼저 참고하시면 좋을지 함께 정리해 드리겠습니다.