본 포스팅은 < 원본 : Run Blockchain Nodes like a Pro >의 번역본으로 Unmarshal 언마샬 프로젝트에 관심이 있는 커뮤니티 투자자분들의 편의를 위해 작성되었습니다.

오타나 번역 관련 문의가 있으시다면 댓글로 부탁드립니다!

Geth 노드가 동기화 해제되었으며 당신은 무엇이 잘못된건지 고민하고 계실 것입니다. 하지만 걱정하지 마세요, 메트릭스가 당신을 구하러 왔습니다. Geth는 노드와 서버의 퍼포먼스를 추적할 수 있는 메트릭스를 많이 내보냅니다. 따라서 다시 동기화하는 것은 옵션이 될 필요가 없습니다.

최근 블록 사이즈와 늘어난 트랜잭션(역대 최대)을 보면 BSC가 폭발적인 성장을 하고 있음을 확인할 수 있으며, 싱크된 노드를 유지하는 것은 노드 실행자들에게 매우 어려운 일이 되었습니다. 전체 노드의 리소스 소모량은 매우 높으며 (8 코어 CPU, 48GB RAM), 그렇다 하더라도 싱크가 해제되는 경우가 많습니다. 아카이브 노드는 전체 노드의 두배에 달하는 리소스 소모량을 보입니다. 노드를 이해하고 튜닝하는 데에는 올바른 매트릭스를 갖고 있는 것이 매우 중요하며, 이에 대해 이 글을 통해 다룰 것입니다.

 

Geth 메트릭스에 대한 소개

메트릭스는 시스템의 퍼포먼스를 가늠하는 양적 데이터입니다. 타임스탬프와 함께 이를 분석하는 것은 시스템을 보다 올바른 방향으로 추적할 수 있게 해줍니다.

현재, geth미터, 타이머, 카운터, 게이지와 같은 메트릭스를 지원하고, 가장 큰 장점은 우리가 직접 독자적인 메트릭스를 추가해 코드 내 특정 이벤트를 추적할 수 있다는 것입니다. 이와 같은 메트릭스는 인사이트를 위해 저장되고 평가될 수 있는 influxdb (오픈소스 타임 시리즈 데이터베이스)로 푸시됩니다. 이 메트릭스는 또한 RPC 엔드포인트의 지정 포트에서 찾아볼 수 있습니다.

이제 메트릭스의 기본값과, 이들로부터 어떻게 인사이트를 얻을 수 있는지에 대해 알아보겠습니다. 기본적으로 메트릭스는 모듈에 대해 특정지을 수 있으며, 적절한 조치를 통해 가상 데이터를 수집할 수 있습니다.

 

모듈 & 메트릭스

트랜잭션 풀, 리소스 사용, 체인 헤드와 같은 geth 모듈 메트릭스는 노드의 상태를 추적하는 데 큰 역할을 합니다. 채굴자에게 트랜잭션 풀과 트랜잭션 계정 슬롯, 그리고 피어 카운트는 채굴을 계속하는데 매우 중요합니다. 비채굴 노드는 geth txpool을 최소로 세팅해 플래그 트랜잭션 풀 사이즈를 최소로 유지하고 트랜잭션 계정 슬롯을 기본값으로 유지할 수 있습니다. 이는 컴퓨팅 리소스를 절약해줍니다.

네트워크 모듈

P2P 모듈은 싱크 프로세스 및 노드 브로드캐스트를 보다 잘 이해하는 데 도움을 주는 노드의 데이터 송수신 속도를 제공합니다. eht/transaction/broadcast와 eth/transaction/announcements와 같은 메트릭스는 트랜잭션 풀의 송신 데이터 속도를 나타냅니다.

eth/egress.meter 메트릭은 geth 디스커버리 포트에서 측정되는 전체 송신 노드 트래픽을 나타냅니다. 이상적으로, 노드가 싱크 해제되면 피어로부터 상태와 트랜잭션을 가져오기 때문에 트래픽이 더 높습니다. 일반적 동기화는 트래픽이 비교적 일정하지만 블록 사이즈가 평균보다 높을 때 스파이크가 일어날 수 있습니다.

디스크 모듈

또 하나의 중요한 모듈은 DB 액세스와 체인 데이터 검증입니다. 디스크 사용량은 일어난 정확한 DB 작성 및 읽기를 알려주는 DB 모듈 메트릭스를 사용해 추출할 수 있습니다.

우리는 이 데이터를 사용해 인프라에 결함이 있는 경우 디버깅할 수 있습니다. 디스크의 읽기 및 작성 데이터 속도는 노드에서 RPC 또는 웹소켓 클라이언트로 더욱 많은 오래된 데이터가 전송될 때 스파이크되며, 주기적 짧은 스파이크는 스테이트 작성 및 메모리 플러시 이벤트이기 때문에 걱정할 것이 아닙니다. eth/db/chaindata/disksize는 메인 DB와 옛 DB를 포함하는 체인데이터 DB의 점유율을 나타냅니다.

Fetcher 모듈

Fetcher 모듈은 공지와 브로드캐스트와 관련된 모든 메트릭스를 포함하며, 모든 형태의 브로드캐스트와 ingress, known, underpriced, malicious 등의 지표를 측정합니다. Fetcher는 또한 노드에 들어오는 송신 요청을 추적합니다.

fetcher/transaction/fetching/peers는 상호작용하는 피어의 수를 계산하고, 나머지 피어는 대기열 상태로 처리됩니다.

RPC 모듈

RPC 모듈은 성공 및 실패와 함께 RPC콜의 수를 추적하기 위해 카운터를 제공합니다. 특정 eth 방법에 대한 개별 카운트 또한 응답 기간과 함께 추적됩니다. RPC 콜 카운터의 파생물은 리소스 사용량, fetcher 상태, 그리고 피어 트래픽과 함께 더 나은 척도가 되어 퍼포먼스와 관련된 문제를 디버깅합니다.

대부분의 노드는 높은 RPC 트래픽이 가져오는 디스크 부하와 CPU가 fetcher 프로세스 속도를 늦추는 문제로 인해 싱크가 해제됩니다. 블록 숫자를 매개변수로 둬 블록 데이터를 회수하는 eth_getBlockByNumber와 같은 특정 콜이 있으며, 이러한 콜이 이전 블록의 데이터를 가져오게 하는 것은 현재 메모리 캐시에 이와 같은 데이터가 더 이상 존재하지 않기 때문에 노드에 과부하를 가져오고, DB를 쿼리해 모든 데이터를 회수합니다. 이와 같은 콜은 또한 노드에 발생하는 모든 RPC 콜의 지연율을 높입니다

이러한 콜의 속도에 제한을 두는 것은 항상 좋은 생각입니다. RPC 콜 기간 (타이머)은 노드에 발생하는 모든 콜의 응답 시간을 집계하고, 이를 사용해 우리는 노드 지연을 발생시키는 콜을 쉽게 확인할 수 있습니다.

패킷당 네트워크 트래픽 데이터와 같이 비싼 것으로 알려진 네트워크 퍼포먼스에 대한 깊이 있는 인사이트를 제공하는 여러 메트릭스가 있으며, 이와 같은 메트릭스 컬렉션은 제공된 리소스가 한정적일 때 전반적 퍼포먼스를 제한할 수 있을 만큼 노드에 추가적인 작업량을 부여할 수 있습니다. 그러나, 앞서 언급한 것과 같은 저렴한 메트릭스도 퍼포먼스를 저해하는 요소를 추적하고 디버깅하기에 충분합니다. 이들을 이해하는 것은 높은 업타임과 함께 노드를 원활하게 실행하는 데 도움을 줄 것입니다.

Unmarshal에서는 데이터를 위해 노드를 쿼리하고 사용자에게 도움을 주는 강력한 인덱서를 운영합니다. 노드 업타임은 당사의 모든 서비스에 대한 데이터 소스이기 떄문에 가장 중요합니다. 우리는 노드를 보다 잘 실행하기 위해 모든 메트릭스를 지켜보고 분석합니다.

“즐겁게 싱크하시기 바랍니다” 😃

 

Unmarshal은?

Unmarshal은 멀티체인 DeFi 데이터 네트워크로, 모든 형태의 분산형 애플리케이션이 블록체인 데이터에 원활하게 액세스할 수 있도록 지원합니다.

현재 이더리움, 바이낸스 스마트체인, 솔라나, 폴카닷, Near와 같은 블록체인으로부터 데이터를 쿼리하는 가장 쉬운 방법을 제공합니다. Unmarshal 네트워크는 모든 체인에서 DeFi 애플리케이션을 구동할 수 있는 변형적인 툴과 데이터 인덱서로 구성되었습니다.

 

* 해당 포스팅은 투자 관련 정보 공유의 목적으로 포스팅된 글이며 투자 권유가 아닙니다. 그러므로 개인 투자의 책임은 모두 본인에게 있으니 참고하셔서 투자하시기 바랍니다.

 

잘못된 정보 혹은 재미있게 보셨다면 댓글 부탁드립니다.

보다 빠른 정보는 텔레그램 채널과 채팅방, 카카오톡 채팅방을 통해 받아보세요 :)

텔레그램 공지방 : https://t.me/minted_labs

텔레그램 채팅방 : https://t.me/minted_chat

카카오톡 오픈 채팅방 : http://open.kakao.com/o/gDtWugpb (입장코드 : 200311)

Unmarshal 한국 공지방 : https://t.me/unmarshalKoreaAnn

Unmarshal 한국 채팅방 : https://t.me/UnmarshalKorea

+ Recent posts