caverjs - 1.8.1
node - 16.13.1
ken - 1.8.2+7584e71de6
const caver = new Caver(" domain ");
while ( true ) {
try{
let blockInfo = await caver.rpc.klay.getBlolck( 93646409 , true )
}
catch(e){
}
} @Jay
구조로 로직이 설정되어있습니다. ( 입금을 확인 하기 위해서 매블록을 모두 조회하고있습니다 )
문제는 해당 블록과 같이 특정 한개의 블록데이터가 제대로 response를 못주는 경우가 있습니다.
문제점 : 스케줄러가아닌 무한반복문으로 돌아가기에 req요청이 자체적으로 구축한 en노드에 req요청이 많아서 그런걸까 싶었는데 ken attach 로 같은 메소드 조회해보니 transaction object 데이터가 존재합니다. 그래서 따로 해당블록만 단건 조회를 해봤는데도 같은 에러를 뱉어버리네요
메인넷(cypress) 네트워크 인데요, 퍼블릭에서는 데이터가 잘 옵니다. 소스 로직상에 문제라기 보기는 어려운듯 싶습니다. ken 버전이 낮아서 그런걸까요? 오랫동안 유지해온 블록데이터와 ken 버전을 계속 갱신해왔던걸로 아는데, 아얘 최신버전으로 셋팅하는게 좋을까요?
추가적으로 해당 블록번호만 건너띄고 로직을 돌리니 잘돌아갑니다. 의문점이 생기는게 현재 제가 ken console 로 attach해서 klay.getBlock(93646409 , true) 를 같이 조회 해본결과론 적인 느낌으로 해당블록데이터 길이가 생각보다 데이터 길이가 많은 것 같습니다. return 뱉는속도가 상대적으로 느리네요.
이런 경우 인스턴스 스펙의 단순문제 때문일까요? aws 스펙상 권장사양( 2xlarge ) 은 지키고있습니다.
ken 버전 최신으로 올려주시면 좋을 거 같습니다.
→ 신규로 4xlarge 스펙으로 snapshot 데이터 다운중입니다. 동기화 후 비교해보겠습니다
느낌으로 해당 블록데이터가 길다고 해주시는 것보다는 실제 데이터를 비교하시고 팩트를 공유해주시면 좋을 거 같아요.
→ 93646409 , 팩트 체크해드리자면 말씀드린 블록의 트렌젝션수는 361개 입니다. 빠르게 생성되는 클레이튼 블록대비 많은 수의 tx가 한블록에 컨펌되어있고 조회하면 아시다 싶이 바이트 크기가 93646409 블록에서는 215,718 bytes 를 차지하고있습니다. 평균 1블록에 10~30개 tx를 들고 있으며 3~4만 bytes를 사용하는 블록데이터 대비 상대적으로 조금 많은 양이긴 합니다. klaytnfinder 가서 비교해보시면 더 확실하게 보이실 겁니다.
AWS 에서는 다양한 2xlarge 스펙이 존재해요. r6g.2xlarge, r6gd.2xlarge 등 다양하게 존재하는데 정확히 어떤 스펙을 사용하고 계시다는 말씀이신가요?
→ 메모리 최적화 r5.2xlarge 쓰고있습니다. 아카이브 노드를 운영하면 cpu 보다 메모리가 부족할때가 간간히 있더군요. 그래서 메모리최적화 위주의 인스턴스를 사용중에 있습니다.
@Denver , 거래소 입장에서 입출금 로직을 생각해보신다면, 반복적으로 블록을 조회할 수 밖에없는 것은 아실겁니다. 근데 제가 경험한 내용은 가끔(?) 이번 경우와 같이 한 블록에 많은 트렌젝션이 담긴경우 getBlock( “블록번호”, true) 의 return 값을 못뱉어낼때가 있습니다. 이게 몇 개의 특정 블록(tx가 많은) 일때마다 이러니까 제입장에서 처리를 어떻게 해야 최선일지 찾고 있습니다. exception 에 걸려서 따로 처리를 해야해서요 ^^
블록들을 파싱해서 따로 디비화 (기획에 따라 다르겠지만 기본적으로 입금 여부를 확인한다고 하셨으니 KLAY의 흐름을 파악하기 용이한 구조로 스키마를 짜야겠죠)
어떤 블록까지 파싱을 완료했는지 디비에 기록
디비에 기록된 블록번호에서 +1 한 번호에 해당하는 블록부터 실행 당시 노드의 최신 블록번호까지 노드로부터 수신해서 파싱해서 디비화하는 스크립트를 만들고 해당 스크립트를 Cron job 으로 실행.
와 같이 구현할 거 같습니다.
P.S @Victor 님이 첨부해주신 while loop은 하나의 프로세스로 계속 루프를 돌며 블록을 받아와서 파싱하는 구조인 거 같은데, 이렇게 단일 프로세스로 계속 그 작업을 하게 돌리는 게 효율적인지는 모르겠어요.
에러 처리도 번거로울 거 같구요. 디비에 어떤 블록까지 처리했는지를 기록해두고 그 기록 바탕으로 동작하는 스크립트를 만들고 Cronjob 으로 스케쥴링하는 게 더 낫지 않나 싶습니다.
신규 4xlarge 인스턴스를 생성한뒤 최신버전의 ken 을 동기화하여 돌려보니 잘되네요. Invaild JSON RPC ""의 문제는 아마 낮은 버전의 ken 버전에 따른 블록데이터가 caverjs 와 안맞아서 블록 데이터 길이가 길 경우 간혹 return 을 잘못던져주는구나 싶습니다. 노드 최신화 관리에 신경써야겠네요. 프라이빗 구성만아니면 현재 이슈있는 상태의 노드를 공유해드리고 싶은데 아쉽게도 불가능하네요. 많이 신경써주셔서 감사합니다.