EN 노드의 블럭 차이가 open-api 노드와 종종 벌어지는 경우가 있는데 어떤 원인때문에 그럴까요?

한국어🇰🇷 Kaia
1

안녕하세요.

노드 싱크와 관련해서 글을 남기게 되었습니다.

상황

  • 현재 클라우드 서비스에 EN 노드 1개를 띄워서 DAPP 서비스를 운영하고 있습니다.
  • 메인넷의 경우 리소스를 vCPU 2와 메모리 8G 주고 띄우고 있습니다.
  • 그리고 주기적으로 메인넷 open-api의 klay_blockNumber JSON-RPC를 통해서 내부적으로 관리하는 EN과 블럭 넘버를 비교하고 있습니다.
  • 노드 버전은 v1.5.3입니다.
  • https://packages.klaytn.net/cypress/chaindata/에서 데이터를 받아 싱크를 맞췄습니다.

문제

  • 그런데 종종 open-api 노드와 블럭넘버 차이가 100개 이상 벌어질 때가 있습니다.

질문

  1. 처음에는 노드의 리소스가 부족하다 생각하여 리소스를 늘렸습니다. 하지만 그럼에도 불구하고 지속적으로 위의 문제가 계속 발생하고 있었습니다.
    ken에서 지원되는 prometheus 메트릭을 통해서 살펴본 결과 disk write 작업이 많거나 block processing 시간이 길 때 싱크가 벌어지는 현상이 나타나고 있었습니다.
    그런데 이것은 저의 관찰을 통한 단순한 추측에 불과하여 질문드립니다. 혹시 노드 사이에 싱크가 벌어지는 원인에는 어떤 것들이 있을까요?

  2. 위의 문제를 해결하기 위해서 노드를 스케일링하고 싶습니다. 그런데 각 노드는 stateful한 상태라 단순 로드밸런싱을 통해서는 노드 스케일링이 불가능할 거 같습니다. 혹시 어떻게 하면 '데이터 일관성’을 깨뜨리지 않고 스케일링을 할 수 있을까요?
    '데이터 일관성’이라는 단어는 예를 들어 한 클라이언트가 klay_blockNumber를 통해서 블럭 넘버를 조회할 때, 여러 노드의 싱크 상태에 관계없이 항상 증가하는 블럭 넘버를 받을 수 있는 등 사용자가 일관된 데이터를 받아볼 수 있는 특성을 나타내기 위해 썼습니다.

1개의 좋아요
2

안녕하세요. 문의주셔서 감사합니다.

해당 노드 spec이 저희가 권장하는 spec보다는 약간 낮아 보입니다.

또한 disk를 SSD로 필수적으로 해주시길 권장드립니다.
(이외에도 권장스펙이상 노드들에서 특정 transaction이 몰릴때 블럭 처리가 늦어지는 현상이 종종 있어 Database/Disk 쪽의 이슈로 보고 개선중입니다.)

open-api 라 하면 KAS 서비스를 말씀하시는 것인지요?
저희도 부분적으로는 KAS를 통해서 일관성을 가지면서 스케일링이 되도로 지원중이며 지속적으로 일관성을 높여나가려고 노력중입니다. KAS를 사용해보시는 것을 먼저 권장드립니다.

자체적으로 운영하시는 EN을 통해서 일관성 있게 스케일링을 하시려는 부분은 아래와 같은 방안을 고려해보면 좋겠습니다.

  • 유저별로 바라보는 EN을 항상 동일한 EN으로 하는 방법
  • API의 특정정보 (from)을 기준으로 동일 EN을 바라보게 하는 방법

감사합니다.

3

답변 감사합니다.

SSD는 사용중이었고 권장 스펙은 제가 놓치고 있는 부분이었습니다. 8 vCPU 이면 비용이 상당하겠네요. open-api라함은 https://api.cyprss.klaytn.net 을 가리키는 것이었습니다.

이외에도 권장스펙이상 노드들에서 특정 transaction이 몰릴때 블럭 처리가 늦어지는 현상이 종종 있어 Database/Disk 쪽의 이슈로 보고 개선중입니다.

아하 그렇군요. 아마 그렇다면 디스크 IO 쪽이 병목일 가능성이 높겠네요. 얼른 개선되면 좋겠습니다.

두번째 질문에 대해서도 답변을 통해서 좋은 힌트를 얻을 수 있었습니다.

감사합니다

1개의 좋아요