Baobab Public EN 성능 테스트 관련

안녕하세요.
일전에 공유 드렸던 이슈인 Klaytn Endpoint Node Dead - hwlee님의 글 #7 와 연관되는 이슈입니다.

저희 측에서 다음과 같이 저희측 EN, 그리고 오늘 아침에는 Baobab측 EN에 대해 각각 성능 테스트를 진행했는데 이 과정에서 저희측 아이피가 Malicious하다고 판단하셔서 아마 차단하셨을 거라 생각합니다.

괜찮으시다면 차단 해제 부탁드려도 될까요 :crying_cat_face: ㅠ_ㅠ

테스트 한 방법과 결과는 아래 공유드립니다.
$ loadtest -c 10 --rps 10 <특정 계정의 토큰 입출금 히스토리를 웹소켓을 사용하여 조회하는 액션을 트리거하는 URL>

즉 초당 10개의 리퀘스트를 보낸 것이고 그 경과 아래와 같이 공유드립니다.

[Tue Jul 28 2020 08:57:42 GMT+0900 (Korean Standard Time)] INFO Requests: 0, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:57:47 GMT+0900 (Korean Standard Time)] INFO Requests: 0, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:57:52 GMT+0900 (Korean Standard Time)] INFO Requests: 7, requests per second: 1, mean latency: 6733 ms 
[Tue Jul 28 2020 08:57:57 GMT+0900 (Korean Standard Time)] INFO Requests: 7, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:58:02 GMT+0900 (Korean Standard Time)] INFO Requests: 7, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:58:07 GMT+0900 (Korean Standard Time)] INFO Requests: 15, requests per second: 2, mean latency: 21726.4 ms 
[Tue Jul 28 2020 08:58:12 GMT+0900 (Korean Standard Time)] INFO Requests: 15, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:58:17 GMT+0900 (Korean Standard Time)] INFO Requests: 18, requests per second: 1, mean latency: 30219.1 ms 
[Tue Jul 28 2020 08:58:22 GMT+0900 (Korean Standard Time)] INFO Requests: 19, requests per second: 0, mean latency: 35590.3 ms 
[Tue Jul 28 2020 08:58:27 GMT+0900 (Korean Standard Time)] INFO Requests: 19, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:58:32 GMT+0900 (Korean Standard Time)] INFO Requests: 19, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:58:37 GMT+0900 (Korean Standard Time)] INFO Requests: 19, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:58:42 GMT+0900 (Korean Standard Time)] INFO Requests: 23, requests per second: 1, mean latency: 56955.1 ms 
[Tue Jul 28 2020 08:58:47 GMT+0900 (Korean Standard Time)] INFO Requests: 25, requests per second: 0, mean latency: 58123.3 ms 
[Tue Jul 28 2020 08:58:52 GMT+0900 (Korean Standard Time)] INFO Requests: 25, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:58:57 GMT+0900 (Korean Standard Time)] INFO Requests: 28, requests per second: 1, mean latency: 70287.9 ms 
[Tue Jul 28 2020 08:59:02 GMT+0900 (Korean Standard Time)] INFO Requests: 28, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:59:07 GMT+0900 (Korean Standard Time)] INFO Requests: 28, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:59:12 GMT+0900 (Korean Standard Time)] INFO Requests: 28, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:59:17 GMT+0900 (Korean Standard Time)] INFO Requests: 28, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:59:22 GMT+0900 (Korean Standard Time)] INFO Requests: 33, requests per second: 1, mean latency: 93387.7 ms 
[Tue Jul 28 2020 08:59:27 GMT+0900 (Korean Standard Time)] INFO Requests: 34, requests per second: 0, mean latency: 99719.4 ms 
[Tue Jul 28 2020 08:59:32 GMT+0900 (Korean Standard Time)] INFO Requests: 35, requests per second: 0, mean latency: 105958.8 ms 
[Tue Jul 28 2020 08:59:37 GMT+0900 (Korean Standard Time)] INFO Requests: 38, requests per second: 1, mean latency: 110077.2 ms 
[Tue Jul 28 2020 08:59:42 GMT+0900 (Korean Standard Time)] INFO Requests: 38, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:59:47 GMT+0900 (Korean Standard Time)] INFO Requests: 38, requests per second: 0, mean latency: 0 ms 
[Tue Jul 28 2020 08:59:52 GMT+0900 (Korean Standard Time)] INFO Requests: 38, requests per second: 0, mean latency: 0 ms 

위 테스트 결과가 시사하는 바로는

  • Websocket을 사용해서 이벤트 히스토리를 가져오는 연산은 상당히 비싸고 또 느리다. 느리다의 기준은 특정 계정의 토큰 잔액을 단순 Http로 확인하는 액션은 평균 조회시간이 80ms 미만이었기 때문입니다 (테스트 방법은 동일).
  • 저희측 EN은 처리속도가 느렸고 심지어 죽기까지하여… 혹시 우리 EN이 이상한 건 아닐까 Baobab은 어떨까 하고 테스트를 해보았던 겁니다. :innocent:
  • 그렇다면… 토큰 입출금 내역 히스토리 조회 액션이 초당 10 이상은 발생할 것으로 예상되는 서비스를 개발한다면… 어떻게 하면 좋을까요? 혹시 괜찮은 아이디어 있으신지요 ;ㅂ; EN에서 가져오기엔… 부하가 심하고 속도도 안나오는 것 같습니다 ㅜ 저의 아이디어는 아래 추가 댓글로 남겨보겠습니다.

혹시 위 내용 중 엄한 내용이 있거나 잘못된 내용이 있으면 언제든 피드백 부탁드립니다. 도와주십쇼 클레이튼 형님들 ㅠ

사용한 툴에 대한 상세한 정보는 아래에서 확인해보실 수 있습니다.

토큰 입출금 내역을 블록체인에서 읽어오는 게 아니라 따로 디비화하는 방법론에 대해 제 아이디어 남겨봅니다.

가정

  • 유저수는 10만명
  • 디비에 있는 10만개 계정의 입출금 히스토리 내역 동기화를 10초마다 하게끔 크론잡을 설정해둠

크론잡 프로세스 동작 매커니즘

  1. 10만개 계정에 대해 먼저 토큰 잔액조회를 일괄 실행
  2. 최근 잔액과 비교했을 때 변동이 있는 고객에 한하여 입출금 히스토리 동기화를 진행
  3. 동기화를 마칠 때 최근 잔액과 조회를 끝마친 fromBlock을 디비에 기록

위와 같이 설계한 근거

  • 잔액 조회 액션은 부하가 거의 없고 속도도 합리적임.
  • 웹소켓을 통해 이벤트 히스토리를 찾는 액션은 부하가 심하고 속도도 느리므로 이 호출을 최소화해야함.

빠르게 짜낸 아이디어라… 부족한 점이 많이 보이네요.
만약 모든 유저가 아주 활발하게 토큰을 주고받는 상황이 발생하면 결국 웹소켓으로 초당 리퀘가 많이 발생할 것이고… EN이 죽거나 서비스 속도가 현저히 저하되는 상황은 근본적으로 해결되기 어렵겠네요 ㅜㅜ

클레이튼에서는 이런 문제들을 겪어본 적이 있으실까요…? 어떤 식으로 처리를 하면 좋을까요.

현재 각 계정에 대한 입출금 내역 조회는 fromBlock: 0 부터 하고 있는데 혹시 이 부분에서 비용이 많이 발생하는 거라면, 동기화 과정에서 fromBlock을 가장 최신것부터 적용하게 하는 등 처리를 잘하면 부하가 덜 해질까요?

질문이 많고 좀 번잡스럽지만… 잘부탁드립니다 (꾸벅)

1 Like

안녕하세요, 클레이튼 포럼에 질문을 올려주셔서 감사드립니다.

먼저, filter를 이용하시면 현재블록 이후부터 발생하는 transaction에 대해서 필터링하여 데이터를 받아서 처리할 수 있습니다. 그걸 DB화 하실 수도 있을 것 같습니다. 아래 URL참고 부탁드립니다.

https://docs.klaytn.com/bapp/json-rpc/api-references/klay/filter

별도로 저희도 token transaction history를 API화 하는 방법론에 대해서는 논의 후 공개하겠습니다. fromBlock:0부터 실행을 하게 되시면 EN에 상당히 큰 부하를 주게 될 것 같습니다. 다른 방법을 고안하시는 것을 추천드립니다.

추가적으로 저희도 해당 이슈를 별도의 DB화로 문제를 풀고 있고, 해당 기능은 KAS에서 제공하고자 합니다.

감사합니다.

1 Like

안녕하세요 :slight_smile:
질문한 일자로부터 시간이 많이 지났지만, 현황 공유드리고 싶어 글 남겨봅니다.

말씀해주신 방법 등을 사용하여 디비화 안정적으로 완료했고 EN에도 이제는 부하가 거의 없습니다.
도움 주셔서 감사합니다.

3 Likes