트래커 만들기 : 트래커 API 제작

eosBLACK_thumbnail_2000-1030_kor (1).jpg

안녕하세요. eosBLACK팀입니다.

연재로 진행되었던 트래커 만들기 개발일지 마지막 내용을 소개 드리겠습니다.

이전 포스팅까지는 EOSIO의 Plugin 개발에 대한 전반적인 내용을 이야기했었습니다. 오늘은 트래커 만들기를 주제로 연재 중인 글의 세 번째이자 마지막 포스팅으로 ‘트래커 제작’에 대해 알아보겠습니다.

Plugin의 성능 향상은 필수.

현재 약, 2,800만 블록이 생성된 상황인데다 DICE 게임 등의 카지노 게임들이 속속 등장하고 있는 상황이라서 매일매일 Transaction이 증가하고 있습니다. 이러한 상황에서 Node를 새로 생성하고 처음부터 Block을 Sync 하면서 mysql에 저장하려고 하면 많은 시간이 소요될 것입니다.

다음은 plugin의 성능에 영향을 주는 요인을 몇 가지 알아보도록 하겠습니다.

1.P2P로 블록을 Sync할 때 네트워크 상황

P2P로 블록을 받아오게 되면 연결된 노드와의 네트워크 상황에 따라 Sync 속도가 느려 질 수 있습니다. 처음부터 Sync를 하게 되면 이러한 상황이 많이 부담되므로 이미 저장된 block log를 다운받아 Hard replay를 진행하게 되면 시간을 많이 절약할 수 있습니다. BP중 하나인 Block Matrix는 매일매일 block log를 저장하여 다운로드 할 수 있는 사이트를 운영하고 있으니 참고하시기 바랍니다.

URL : https://eosnode.tools/blocks

2.DB Insert 속도

한 개의 블록은 다수의 트랜잭션을 포함하고 트랜잭션은 또 다수의 액션들을 포함하고 있으므로 하나씩 Insert Query를 처리하게 되면 시간이 많이 소모될 수 있으므로 Plugin에서 Bulk로 record를 모아 DB에 Insert하면 시간을 많이 절약하고 성능도 높일 수 있습니다. 이러한 작업은 1번에서 언급한 Hard replay 때에 적용하면 좋은 팁입니다.

3.블록 수의 몇 배에 달하는 action trace 정보

두 번째에서도 언급했지만 action과 inline action은 1천만번대 블록까지 약 3억개 정도가 되며, 그 이후로는 더 증가하고 있습니다 (blocktwitter의 “We love BM”이 한 몫 하고 있죠). action 과 inline action은 applied transaction 이벤트에서 처리할 수 있고 transaction id를 key로 사용하고 있으므로 Insert하는 순서는 중요하지 않습니다. 그러므로 applied transaction을 처리하는 thread를 여러 개 만들면 성능을 높일 수 있습니다.

위와 같은 상황에 대해 참고하셔서 성능을 높일 수 있는 방안을 생각해 보시면 좋을 것 같습니다. 이 글을 쓰고 있는 현재 전체 Sync를 완료한 상태의 노드를 운영하고 있으며 계속해서 Sync 시간을 단축하기 위한 방법을 고민하고 있습니다. 좋은 아이디어나 개선 방안에 대한 내용을 Github에 올려 주시거나 개발에 같이 참여해 주시는 개발자 분들을 언제나 환영합니다.

Github : https://github.com/eosBLACK/eosio_mysqldb_plugin

Tracker API를 위한 서버를 구성해 보자.

API 서버의 개발은 Third-Party 개발자들이 DBMS에 자유롭게 접속할 경우에 발생할 수 있는 Risk를 최소화하기 위한 것이 가장 큰 이유입니다. Plugin을 통해 저장된 데이터를 활용하기 위한 API 서버 개발 예시를 소개해 보겠습니다.

간략히 예제 작성을 위한 환경 구성을 살펴보도록 하겠습니다.