Klaytn State Trie Cache Series #2: 최적의 cache 찾기
전체 포스팅 목록은 여기에서 확인하세요.
Klaytn은 블록체인 플랫폼의 성능을 개선하기 위해 다양한 노력들을 했습니다. 아래의 포스팅을 통해 state trie cache 성능 개선 과정을 살펴보고자 합니다.
전 포스팅을 통해 메모리 과사용의 원인이 큰 Heap 할당을 오랫동안 했기 때문이라는 것을 알았습니다. fastcache와 freecache와 같이 Go GC overhead가 적은 cache가 있습니다. 이 포스팅에서는 메모리 과사용이 적은 cache를 찾기 위한 방법에 대해 소개합니다.
위 포스팅에서는 Go에서 빠른 cache는 ristretto, bigcache, freecache, fastcache 가 있다고 합니다. 이 cache들이 Klaytn에 적합한지 확인하기 위해, Klaytn에 적용해 보고 결과를 확인해 보았습니다.
KLAY 전송 테스트
사용 AWS instance : m5.2xlarge
CN 4, PN 4, EN 4, locust slave 4
memory size : 32G
cache size : 6G
RPS 2000, accounts : 0.5M
- 총 메모리 사용량은 gc를 포함한 전체 메모리 사용량입니다.
- 저장 entry 수는 각 cache에서 제공하는 stat 값을 이용한 것입니다.
Bigcache는 기존에 사용하는 cache입니다.
Ristretto는 LFU(Least Frequently Used), 즉 최근에 얼마나 자주 사용했는지를 추적하고 관리합니다. 이 때문에 메모리를 많이 사용하여 out of memory가 발생한 것으로 보입니다. 또한, cache miss도 많은 것을 보아 저장하는 entry 수도 적을 것이라 추측할 수 있습니다.
Ristretto의 이런 예상 밖의 결과는 Klaytn에서만 나타난 것이 아닙니다. CODASYL에서 발표한 benchmark를 보면, 다른 cache에 비해 현저히 낮은 hit ratio를 확인할 수 있습니다. 이는 데이터 입력 방식에 따라 LRU에 적합한 것과 LFU에 적합한 것이 따로 존재하기 때문입니다. Klaytn은 state trie 생성 방식을 생각해보면, LRU가 더 적합한 것을 알 수 있습니다. 최신 trie를 생성하기 위해서는 최근에 저장한 node들을 다시 접근하는 경우가 많기 때문입니다. 마찬가지로, 위의 throughput 차트에서는 Ristretto가 가장 좋은 성능을 보여주었지만, Klaytn의 실험결과에서는 가장 높은 캐시 미스를 확인할 수 있었습니다.
결론적으로, Ristretto는 다른 cache에 비해 안 좋은 성능을 보여주었기에 Klaytn에 적합하지 않다고 판단했습니다.
Freecache는 GC overhead를 없애는 새로운 구조를 가지고 있다고 합니다. Bigcache 보다 메모리 사용량이 낮으며 저장 entry수도 많습니다.
Fastcache는 기존에 사용하던 Bigcache와 똑같은 구조를 가지고 있으며, 구현을 좀 더 효율적으로 했다고 합니다. 마찬가지로, Bigcache 보다 메모리 사용량이 적고 더 많은 entry를 저장하고 있습니다.
Freecache와 Fastcache를 비교해 보면 저장하는 수는 같지만, 메모리 사용량에서 의미있는 차이를 볼 수 있습니다. 따라서, 메모리 사용량이 가장 적은 Fastcache를 Klaytn의 새로운 캐시로 선택하였습니다.
Fastcache가 Bigcache보다 얼마나 좋은지 알아보기 위해 좀 더 큰 인스턴스로 TPS를 테스트 해보았습니다. 똑같은 사양의 인스턴스 2 대에 cache의 종류만 다르게 하여 테스트 하였습니다.
KLAY 전송 테스트
AWS instance : m5.18xlarge
CN 4, PN 8, EN 8, locust slave 4
memory size : 144G
RPS 4000, accounts : 5M
메모리 사용량이 98G에서 69G로 약 30% 줄었고, 저장 entry 수도 147M에서 165M로 12% 증가한 것을 확인할 수 있습니다.
속도가 향상되었는지 확인하기 위해 Cypress sync 테스트를 진행하였으며, 작은 instance에서도 cache miss로 인해 sync 속도가 차이나는 것을 확인할 수 있습니다.
Cypress sync test
AWS instance : m5.2xlarge
memory size : 32G
cache : Bigcache, Fastcache
cache Size : 6GB, 9GB
왼쪽 그래프의 실험 결과를 통해, Fastcache가 Bigcache보다 저장하는 entry수가 많아, cache miss가 늦고 낮게 발생하고 있는 것을 확인할 수 있습니다. 또한, 오른쪽 그래프에서는 현재 블럭 넘버를 나타내고 있는데, Fastcache가 Bigcache보다 블럭 넘버가 높은 것을 확인할 수 있습니다. 이것은 Fastcache가 Bigcache보다 더 빠르게 Cypress 블록 정보를 동기화하는 것을 의미합니다.
이번 포스트에서는 Bigcache를 대체할 수 있는 여러 캐시들를 찾아보았고, 다양한 실험을 통해 Fastcache가 Bigcache보다 메모리 관리 측면과 성능 측면에서 모두 뛰어난 것을 확인할 수 있었습니다. Klaytn v1.5.0 버전부터는 Fastcache가 적용되었으니, 아직 낮은 버전으로 노드를 운영하고 계시다면 버전을 올려보시기를 권장드립니다.
다음 포스트에서 state trie cache miss에 영향을 미치는 요인은 무엇인지 알아보겠습니다.
