Lessons Learned: APAC 지역에서 이더리움 퍼포먼스 개선 사례, SSV DVT

Published in

A41 Tech Blog

13 min readAug 21, 2024

A41은 다양한 블록체인에서 검증인으로 활동하고 있으며, 주로 한국에서 Tier III & Tier IV 데이터센터에서 베어메탈 장비를 사용하여 서비스를 제공하고 있습니다. 이 글에서 사용한 데이터는 A41 밸리데이터 노드에서 수집한 데이터를 기반으로 하고 있으며 운영 환경에 따라 데이터가 다를 수 있습니다.

0. TL;DR

SSV 네트워크에서 오퍼레이터가 합의하는 과정을 살펴보고, 퍼포먼스에 영향을 미칠 수 있는 주요 지점을 찾아봅니다.
한국의 데이터센터, AWS 한국 인스턴스, OVH 독일 지역 등 여러 환경에서의 오퍼레이터 퍼포먼스 비교를 토대로, SSV 오퍼레이터를 한국의 데이터센터에서 운영할 때 겪을 수 있는 퍼포먼스 이슈와 그 원인을 알아봅니다.
현 상황에서 APAC 지역 IP 대역의 P2P 통신만 허용하는 것이 유효한 이유와 장기적으로는 더 많은 SSV 오퍼레이터가 지역적으로 고르게 분포해야 근본적인 문제 해결이 가능한 이유도 함께 제시합니다.

1. SSV Consensus

Source: https://ssv.network/blog/technology/ssv-protocol-implementation-deep-dive/

SSV 네트워크를 통해 이더리움 합의에 참여할 때에는 위 다이어그램과 같은 과정을 거치게 되며, 총 세 단계 Pre-consensus, Consensus, Post-consensus로 나뉩니다.

Pre-consensus: Blue Steps, Fetch Duty Data
Consensus: Yellow Steps, SSV Consensus
Post-consensus: Orange Steps, Aggregate & Submit

주로 살펴보아야 할 부분은 Yellow Steps입니다. SSV는 기본적으로 BFT 알고리즘을 토대로 오퍼레이터 간 합의에 도달하며, Proposal-Prepare-Commit 과정을 거칩니다.

이때 SSV 네트워크에 참여하는 모든 오퍼레이터가 하나의 상태에 합의하는 것은 아닙니다. 오퍼레이터 별로 운영 중인 이더리움 밸리데이터에 따라서 서브넷이 결정되며, 해당 서브넷에 구독 중인 오퍼레이터 간 합의가 이뤄집니다. 참고로 서브넷은 최대 128개로 한정적이며, 오퍼레이터가 운영하는 이더리움 밸리데이터가 결정되었다면 구독해야 하는 서브넷도 결정되는 방식입니다.

Source: https://ssv.network/blog/technology/introduction-to-the-first-ssv-network-fork/

따라서 오퍼레이터는 서브넷을 구성하는 피어 상태에 따라 퍼포먼스가 달라지며, 다시 말해 다수의 이더리움 밸리데이터를 운영 중인 하나의 오퍼레이터임에도 각 밸리데이터가 속한 서브넷은 다르기 때문에 합의 퍼포먼스는 서로 다를 수 있습니다.

2. Our Problem

저희가 운영 중인 SSV 오퍼레이터 중, 한국 데이터센터에서 동작 중인 오퍼레이터는 4개가 있습니다. 이 4개의 오퍼레이터는 하나의 SSV 클러스터를 구성하며, 126개의 이더리움 밸리데이터 키를 운영합니다. 여러 이더리움 밸리데이터 의무 중 Attester를 기준으로 얘기하자면, 앞서 파악한 합의 과정을 토대로 SSV 네트워크에서의 합의는 늦어도 8초 안에 끝마쳐야 합니다. 이를 위해서는 각 오퍼레이터가 동작하고 있는 머신 리소스가 병목 지점이 되어서는 안되며, 서브넷을 구성하는 피어 소통에 소요되는 네트워크 지연 시간이 크지 않아야 합니다.

위 그래프는 한국에서 운영 중인 4개 오퍼레이터의 평균 Attestation 성공률 데이터입니다. 전반적으로 안정적이지 않으며, 상황에 따라서 큰 폭으로 값이 변하는 것을 알 수 있습니다. 저희는 퍼포먼스에 영향을 줄 수 있는 여러 변수들을 하나씩 제거해 가며 주요 병목 지점으로 예상되는 요소를 찾고자 했습니다.

먼저, 머신 연산 처리 능력 부족 가능성을 검토했습니다. 기존 구성은 32 Core & 128 GB RAM 스펙인 하나의 베어메탈 머신에서 이더리움 클라이언트와 4개의 SSV 오퍼레이터가 구동 중인 상황입니다. 지속적으로 울리는 알러트와 에러 로그를 토대로 파악했을 때 이더리움 합의 계층 클라이어트에서의 리소스 병목 가능성이 존재했고, 동일한 스펙인 머신을 하나 추가해서 클라이언트를 분배해 주었습니다. 하지만 여전히 퍼포먼스에는 큰 변함이 없었고, SSV 클라이언트 구동으로는 충분히 오버 스펙인 상황이기 때문에 이 항목은 주요 문제가 아니라고 판단했습니다.

이어서, 4개의 오퍼레이터를 한국 데이터센터에서 운영하고 있기에 마주할 수 있는 가능성을 고려했습니다. SSV 피어 통신 간에 발생하는 네트워크 지연 개선이 주요 목표가 되며, 이를 직접적으로 혹은 간접적으로 해결할 수 있는 여러 시도를 진행했고 각 항목을 이어서 기술하겠습니다.

3. Our Attempts

3.1. Comparison by Operating Environment

가장 먼저, 서로 다른 운영 환경에서 SSV 오퍼레이터를 운영함으로써 실제 퍼포먼스에 어떤 변화가 있는지 확인하고자 했습니다. 검증하고자 하는 대상은 다음과 같습니다.

대부분의 피어가 한국과 지역적으로 먼 곳에 위치하여, 네트워크 지연으로 인해 퍼포먼스에 영향을 받는가
구동 중인 데이터센터의 해외향 트래픽 대역폭 가용 리소스가 병목 지점인가

첫 번째 항목을 확인하기 위해서 많은 피어가 위치한 EU 지역에서 오퍼레이터를 운영하고 데이터를 수집했고, 두 번째 항목을 위해서는 해외향 트래픽 대역폭 SLA 수준이 높은 AWS 서울 지역에서의 인스턴스 상에서 오퍼레이터를 운영하고 데이터를 수집했습니다. 그 결과를 그래프로 정리하면 다음과 같습니다.

같은 한국 지역에서도 운영 환경의 리소스에 따라서 퍼포먼스 차이가 꽤나 크게 났고, 이외에도 한국과 독일에서의 지역적인 차이도 분명히 존재함을 알 수 있었습니다. 위 결과로 알 수 있는 주요 정보는 “데이터센터의 해외향 대역폭 리소스 문제가 주요 병목 지점이 되고 있으며, 지역적으로 멀리 위치한 피어 집합에 따라서도 퍼포먼스 영향을 받는다” 입니다. 특히 고려해야 할 부분은 한국 지역의 데이터센터가 주로 국내향 서비스를 운영하기 때문에 해외향 트래픽에 대한 최적화가 되어있지 않고, ISP와 데이터센터 사이의 SLA 계약이 상대적으로 낮은 수준으로 맺어져 있다는 점입니다. 저희는 이 사항을 모두 고려하여 SSV 클라이언트 컨피그를 조절하거나 운영 환경에 변화를 주는 등 적합한 방안을 찾고자 합니다.

3.2. Control Peers Count

SSV 클라이언트 v1.3.7 버전에는 피어 수를 조절할 수 있는 두 가지 방안이 있습니다.

전체 피어 수 상한 (기본값 60)
서브넷 별 피어 수 상한 (기본값 10)

피어 수를 높임으로써 기대할 수 있는 효과는 SSV 합의를 위해 소요되는 RTT (Round Trip Time) 를 감소시켜서 결과적으로 합의 퍼포먼스를 개선하는 것입니다. 더 많은 피어를 갖도록 하는 것은, 보다 다양한 지역에서 운영 중인 오퍼레이터와 소통할 수 있다는 것이고, 이는 지역적으로 한국과 가까이 위치한 피어의 존재 확률을 높이는 것입니다.

SSV 합의는 서브넷 단위별로 이뤄지기 때문에 전체 피어 수 상한 뿐만 아니라 서브넷 별 피어 수 상한도 함께 증가시켜 줘야 합니다. 따라서 저희는 전체 피어 수 상한을 200, 서브넷 별 피어 수 상한을 20으로 늘린 후 수일 동안 퍼포먼스 추이를 지켜보았습니다.

피어 수를 늘린 후 때때로 합의에 소요된 시간이 3~4초대 결과를 보이지만, 대부분의 경우 8~9초대 결과를 보입니다. 이는 피어 집합에 따라 가끔 빠른 합의에 성공하지만, 많은 피어가 지역적으로 먼 곳에 위치하며 데이터센터의 해외향 트래픽 대역폭이 최적화가 되어있지 않기 때문에 여전히 합의에 소요되는 시간이 지연되어 퍼포먼스에 문제가 되는 상황입니다. 이에 따라 평균적인 Attestation 성공 비율에 유의미한 개선은 없었고, 데이터센터 대역폭 사용량이 약 30% 증가한 모습을 보였습니다.

3.3. Use AWS Instance as Relay

데이터센터의 머신을 최대한 활용하면서도 우수한 합의 퍼포먼스를 보이기 위해서는 단순히 SSV 클라이언트 컨피그 조정으로는 무리가 있었습니다. 주요 문제점은 데이터센터의 해외향 트래픽 대역폭 가용 리소스가 충분하지 않다는 점이기 때문에, 보다 높은 수준의 SLA를 가진 AWS 인스턴스를 사용하여 해결하고자 했습니다.

이 구조를 위해서는 AWS 인스턴스에서 운영 중인 오퍼레이터와 데이터센터에서 운영 중인 오퍼레이터 사이의 피어 연결이 보장되어야 합니다. 최근 릴리즈된 SSV 클라이언트 v1.3.8 버전의 TrustedPeers 설정 덕분에, 특정 피어를 우선적으로 연결하도록 보장할 수 있게 되었습니다. 새롭게 시도해 보는 SSV 클라이언트 설정과 구조는 다음과 같습니다.

# ssv/config.yaml

p2p:
  # ...
  TrustedPeers:
    - /ip4/<ip-1>/tcp/<port-1>/p2p/<peerid-1>
    - /ip4/<ip-2>/tcp/<port-2>/p2p/<peerid-2>
    - /ip4/<ip-3>/tcp/<port-3>/p2p/<peerid-3>
    - /ip4/<ip-4>/tcp/<port-4>/p2p/<peerid-4>

기본적으로 4개의 오퍼레이터는 TrustedPeers설정을 통해 우선적으로 상호 연결합니다. 그리고 리소스가 부족한 데이터센터의 해외향 트래픽 대역폭 대신 AWS 인스턴스의 대역폭을 사용하여, 즉 릴레이 역할로 활용하여 트래픽 병목 지점을 제거하고자 했습니다.

위 그래프는 새로운 구조로 수시간 운영한 오퍼레이터 데이터입니다. 실제로 초반 3시간 정도는 SSV 합의에 1초 미만의 시간을 소요하고 98% 이상의 퍼포먼스를 보입니다. 하지만 피어 수가 상한에 도달하고 시간이 지난 후 SSV 클라이언트의 PubSubScoring 이 동작함에 따라, 더 나은 피어 구성을 위해 지속적으로 피어 집합이 업데이트됩니다. 여기서 TrustedPeers에 명시된 피어는 항상 피어 집합에 포함되도록 보장되는 것은 아니기 때문에 배제될 수 있고, 그렇게 된다면 더 이상 릴레이로서 AWS 인스턴스 활용이 무의미해지므로 합의에 소요되는 시간이 급증하는 것을 알 수 있습니다. 결국 AWS 인스턴스를 릴레이로서 활용한다고 하더라도 StaticPeers와 같은 설정이 존재하지 않는 한, 퍼포먼스 개선에 한계가 있습니다.

3.4. Accept Only APAC Peers

결국 저희가 마주한 문제는 “한국에 위치한 데이터센터의 해외향 대역폭 최적화가 되어있지 않은 환경에서 합의에 소요되는 네트워크 TTL을 개선한다”가 됩니다. 이 문제를 SSV 네트워크 구성 상황과 연관 지어보면, 많은 오퍼레이터가 EU와 US 지역에 위치하기 때문에 피어 집합은 대부분 한국과 거리가 먼 오퍼레이터로 구성되어 라우팅이 비효율적으로 이뤄지고 있는 상황입니다. 이를 위해 SSV 클라이언트의 PubSubScoring 동작상에서 빠른 네트워크 응답 시간을 주요 지표로 피어 집합이 구성되는 것이 이상적이지만, libp2p 라이브러리와 클라이언트의 수정이 필요하므로 당장 적용하기에는 여러 어려움이 있습니다. 따라서 저희는 한국과 지역적으로 가까운 APAC에 위치한 오퍼레이터가 피어 집합으로 구성되도록 방화벽 정책을 설정했습니다. 이 정책을 통해 데이터센터의 해외향 대역폭 리소스를 보다 효율적으로 사용할 수 있게 됩니다.

SSV 합의 시간은 ms 단위로 감소했고, 동시에 Attestation 성공률도 98% 수준으로 개선되었습니다. 또 하나 눈여겨 볼만한 점은 오퍼레이터 피어 수가 상한인 60에 도달하지 못하고 30 중반대에 머무는 모습을 보입니다. 다시말해, APAC 지역에서 운영되고 있는 오퍼레이터의 수가 이 정도로 적다는 것을 의미하며, SSV 클라이언트의 TrustedPeers 설정과 피어 수 상한에 도달하지 않았기 때문에 동일한 머신에서 동작 중인 오퍼레이터들간의 피어링이 유지되어 합의에 소요되는 시간이 적다는 것 또한 알 수 있습니다. 처음의 데이터센터 구성과 현재의 구성 그리고 독일에서 운영했을 때의 데이터를 비교하면 아래와 같습니다.

APAC 지역에서 운영 중인 오퍼레이터를 대상으로 피어링하고 동일한 머신에 위치한 오퍼레이터를 우선 피어링 대상으로 설정한 덕분에 처음의 구성과 비교하여 확실한 개선이 이뤄졌고, 대부분의 오퍼레이터가 위치한 EU 지역에서 운영하는 것만큼의 퍼포먼스를 달성할 수 있었습니다.

4. Conclusion

다양한 블록체인에 밸리데이터로서 참여하면서, 종종 많은 오퍼레이터가 EU 혹은 US 지역에 위치하고 있는 상황 때문에 기술적인 챌린지를 겪기도 합니다. 이더리움의 Sync Committee로 참여할 때 종종 지역적으로 거리가 먼 밸리데이터가 다수로 구성되어 퍼포먼스가 낮을 때가 있고, 블록 타임이 1초 이하인 Sei 혹은 Injective 같은 블록체인에 밸리데이터로서 참여하기 위해서는 불가피하게 EU 지역에 노드를 운영해야 할 때도 있습니다.

그럼에도 A41은 APAC 지역에서의 밸리데이터 운영을 우선 목표로 삼으며, 이번 도전처럼 지역적 탈중앙화를 위한 시도를 하고 있습니다. 저희가 사용하는 한국 지역의 Tier III, Tier IV 데이터센터의 망에도 불구하고, 짧은 시간 내에 전송, 검증, 합의까지 끝내야 하는 경우 APAC 지역에 위치한 피어가 충분하지 않다면 데이터센터의 해외향 트래픽은 문제가 될 수 있습니다.

SSV는 이더리움 DVT 구현체 중 하나로, 이더리움 탈중앙화의 철학과 가치를 위해 나아가고 있습니다. SSV 네트워크가 보다 성숙해지기 위해서는 APAC 지역의 오퍼레이터가 더 운영되어야 하며, StaticPeers와 같은 컨피그 설정도 뒷받침되어야 합니다. SSV와 함께 A41은 APAC 지역에서의 밸리데이터 운영을 지속하여 지역적 탈중앙화를 위해서 가능한 고민과 실험을 해보며 더 나은 이더리움과 DVT를 위해 기여하겠습니다.