지금, Solana에서
Solana에서 더 빨라지려면?
Solana에서 개발해 봤다면, 이 말 한 번쯤은 해봤을 겁니다.
옆 데스크랑 전략이 똑같은데 — 내 봇만 체결이 밀린다.
가격이 찍힌다. 주문을 쏜다. 그런데 내 트랜잭션이 안 들어간다.
RPC 제공자란 제공자는 다 갈아봤는데 — 그대로다.
프로의 튜닝이라는 것
코드도 다듬었고, 장비도 키웠습니다. 둘 다 병목이 아닙니다 — 너무 멀리서, 한순간도 멈추지 않는 leader를 쫓고 있는 겁니다.
하드웨어와 코드만으로는 슬롯을 못 잡습니다. 슬롯은 타이밍과 위치로 잡는 겁니다.
속도는 돈으로 삽니다. 진짜 우위는 ‘이해’입니다.
먼저 도달하는 법 보기
움직이는 표적
가장 빠른 자리는 한자리에 머물지 않습니다.
slot마다 — Solana가 블록을 만드는 약 400ms의 한 차례 — 다른 validator가 leader가 되고, 거기에 가장 가까이 붙은 쪽이 이깁니다.
한 번 옆에 자리 잡으면 끝인 고정석과 달리, Solana에서 가장 빠른 자리는 연달아 같은 곳인 적이 없습니다.
~400 ms · slot마다 새 leader
slot마다 옮겨가는 가장 빠른 자리
leader는 slot마다 전 세계를 돌며 자리를 바꿉니다. 한 slot을 잡아도, 다음 slot은 이미 딴 데 가 있습니다.
움직임 보기
고성능 Solana RPC, Geyser gRPC & ShredStream
Epoch —
— countries
Leader
—
Live block producer
거리가 곧 지연
대륙 하나만 건너도 100–300 ms 밀립니다.
광섬유 속 빛의 속도와 거쳐 가는 라우터들이, 어떤 하드웨어로도 못 깨는 한계를 만듭니다. 같은 랙이면 약 0.1 ms. 바다를 건너면 100–300 ms — 그런데 slot은 고작 약 400 ms입니다.
그래서 leader가 코앞이면 시간 안에 들어가고, 지구 반대편이면 이미 끝난 뒤입니다. 모든 slot에서 빠르다는 건, leader가 어디에 떨어지든 늘 그 곁에 있다는 뜻입니다.
거리별 왕복 하한선 · 벤치마크가 아니라 물리 법칙
거리가 패킷에 매기는 값
- 같은 네트워크
- 0.1 ms
- 같은 데이터센터
- 0.3 ms
- 같은 도시
- 1 ms
- 인접 국가
- 5–10 ms
- 대륙 횡단
- 100–300 ms
대륙을 건너면 같은 랙 안에서의 한 홉보다 수백 배 멀고 — slot 하나보다도 깁니다. 가까이 있다는 건 미세 조정이 아니라, 쓸 수 있는 시간 그 자체입니다.
커버리지 — 도시 하나로는 부족한 이유
가장 붐비는 도시조차 네트워크의 4분의 1 정도입니다.
운영자가 가장 몰리는 곳은 Frankfurt입니다 — 그런 곳마저 validator 수로 봐도, stake로 봐도 네트워크의 4분의 1쯤입니다. 대부분의 slot에서 정작 leader는 다른 데 있습니다.
어디든 빠짐없이 까는 게 최선이지만, 예산 때문에 골라야 합니다. 그래서 따져야 할 건 누가 제일 큰가가 아니라, 머신이 덜 몰려 가장 덜 붐비는 곳이 어디냐입니다. Amsterdam은 Frankfurt에 맞먹는 stake를 훨씬 적은 validator로 담아냅니다 — 더 한산하고, 더 나은 자리인 경우가 많습니다.
Solana validator가 모여 있는 곳
커버리지 — 어느 leader 옆에도 이미 있는 노드
leader가 어디에 떨어지든, 강력한 Solana 직결 노드가 이미 그 자리에 있습니다.
leader 역할은 slot마다 지구를 돌고 또 돕니다 — 그래서 이기는 노드는 이미 거기에 가장 가까운 노드입니다. 같은 리전에 있는 노드는 지연을 키우는 장거리 홉을 건너뜁니다.
그래서 우리는 한곳에 기대지 않습니다. 꾸준히 빠르다는 건 모든 slot에서 가까이 있다는 뜻이고 — leader가 리전을 넘나드는 이상, 그러려면 여러 리전에 걸친 커버리지가 필요합니다. 우리는 Solana의 stake가 몰리는 곳마다 validator급 노드를 하나의 저지연 패브릭 위에서 돌리고, 리전을 계속 늘려갑니다 — 리전이 하나 늘 때마다, 이미 leader 옆에 있는 slot도 그만큼 늘어납니다.
Global Data Center Partner
속도는 Solana까지의 거리로 결정됩니다.
지역이 중요합니다. 하지만 도시 이름만으로는 네트워크 경로가 결정되지 않습니다. 같은 도시 안에서도 외부 transit과 추가 hop이 지연을 더할 수 있습니다. ERPC는 Solana 서버에 가까운 데이터 센터를 선택한 다음, 외부 transit 없이 경로를 짧게 유지하고 지속적인 터보 부스트를 유지합니다.
ERPC 프리미엄 루트
외부 transit 없음
최소 RTT
도시 이름만으로 선택
외부 transit/7 hops
70배 느림
- 01동일한 데이터 센터먼저 지역을 선택한 다음, Solana에 가장 가까운 데이터 센터를 선택하세요.
- 02외부 transit 없음RTT와 지터를 낮고 안정적으로 유지하려면 외부 AS 경로를 피하세요.
- 03최대 출력ERPC는 절전 프로필을 제외하고 리소스를 지속적인 터보 부스트 상태로 유지합니다.
stake 가중 우선순위 (SWQoS)
트랜잭션이 자꾸 실패한다면, 스팸 차선에 갇힌 겁니다.
Solana의 leader는 우선순위 대역폭을 둘로 나눕니다. stake — validator에 위임된 SOL — 로 뒷받침된 연결이 그중 80%를 가져갑니다. 나머지는 전부 남은 20%를 두고 다툽니다 — 스팸으로 꽉 막힌 차선입니다.
leader에게 곧장 쏘는 게 빠른 길처럼 보이지만 — stake가 없으면 그게 바로 붐비는 20% 차선이고, 부하가 걸리면 트랜잭션은 끝내 블록에 못 들어갑니다.
그래서 진짜 답은 stake를 확보한 validator입니다. 우리는 고품질 RPC 라인에 직결된 최상급 validator를 — 하드웨어는 Solana 바로 옆에 두고 — 운영합니다. 그래서 당신의 트랜잭션을 넓은 차선에 태웁니다.
우리 Shinobi Performance Pool의 최상급 validator
Solana leader가 우선순위 대역폭을 가르는 방식
stake는 수수료를 내기도 전에 넓은 80% 차선을 타고 validator로 들어갑니다. stake가 없으면 20% 스팸 차선에 끼어버립니다.
80 / 20 분배는 우리가 아니라 Solana의 leader가 정합니다
실측 벤치마크
같은 등급 머신. 같은 속도는 아닙니다.
AMD Turin, 4 vCPU, Amsterdam, Ubuntu 24.04 — 두 장비 모두 똑같습니다. 한쪽은 메이저 cloud, 다른 한쪽은 우리. 스펙 시트는 둘이 동급이라지만, 벤치 결과는 다릅니다.
같은 실리콘. 차이는 우리의 튜닝입니다 — 정교하게 맞춰, Solana 바로 옆에 앉힌 장비.
node_bench · 같은 실행, 같은 리전
ERPC vs 메이저 cloud · 동일 스펙
- CPU 연산sysbench · 4 threads · 높을수록 좋음
- 더 높은 CPU 처리량1.9×
- 메모리 대역폭STREAM Triad · 4 GiB · 높을수록 좋음
- 더 높은 메모리 대역폭3.2×
- 디스크 IOPSfio · 4K randread · QD32 · 높을수록 좋음
- 더 높은 디스크 IOPS16.6×
- 디스크 지연 · p99fio · 4K randread · QD32 · 낮을수록 좋음
- 꼬리 구간에서 더 빠름25.7×
events/s
MB/s
IOPS
µs