Multi-Region Solana 인프라의 이점과 최적화

Solana에서는 현재 리더 검증자와 물리적으로 가까이 있는 것이 중요하다는 점을 저희는 계속 강조해 왔습니다. 하지만 Solana는 전 세계에 분산되어 있고 리더는 끊임없이 회전합니다. 모든 것을 하나의 도시에 몰아넣는 방식은 이러한 현실과 맞지 않기 때문에, 멀티 리전 접근 방식이 의미를 갖습니다. 이 글에서는 에포크와 리더 일정에서 출발해, 실질적인 의미에서 "가깝다"는 것을 어떻게 판단하고 그 판단을 어떻게 운영에 적용할 수 있는지 보여드리겠습니다.

Solana는 슬롯 단위로 시간을 진행시킵니다. 약 400ms가 하나의 슬롯을 이루며, 슬롯은 다시 에포크로 묶입니다. 에포크는 슬롯의 집합(총 432,000개)으로, 체감상 약 이틀 정도에 해당합니다. RPC 메서드 getEpochInfo로 진행 상황을 추적할 수 있습니다. 네트워크의 현재 처리 속도와 슬롯이 얼마나 빠르게 진행되고 있는지 파악하려면 getRecentPerformanceSamples가 유용합니다. 각 에포크가 시작될 때 리더 일정이 고정되며, 매 순간 정확히 하나의 리더가 블록을 생산합니다. 이렇게 빠르게 리더가 바뀌기 때문에, 거리를 따라가는 접근 방식이 필요합니다.

거래 인프라의 역사에서, 거래소의 메인 서버와 물리적으로 가까운 것은 언제나 이점이었습니다. 케이블 길이에 따라 서버 가격이 달라진다는 말이 있을 정도입니다. 빛은 빠르지만 무한하지 않습니다. 거리가 짧을수록 수신과 송신 모두 빨라집니다. 이 원리는 블록체인에도 동일하게 적용되지만, 한 가지 차이가 있습니다. Solana의 블록 생산 지점은 전 세계를 이동한다는 점입니다. 지금 리더가 New York에 있다면 New York과 가까운 것이 도움이 됩니다. 다음 리더가 Frankfurt에 있다면 Frankfurt와 가까운 것이 도움이 됩니다. 이것이 바로 하나의 허브가 아니라 여러 위치를 준비해야 하는 이유입니다.

Solana 네트워크 데이터: Validators Solutions

주요 검증자 도시와 익스체인지 거점에 여러 개의 소규모 거점을 유지하고, 그 순간의 현재 리더와 가장 가까운 거점을 자동으로 사용합니다. 리더 슬롯이 New York에 있을 때는 New York에서 수신하고 송신합니다. 다음 리더가 Frankfurt로 넘어가면 즉시 Frankfurt로 전환해 가장 짧은 경로로 전송합니다. 목표는 평균치를 개선하는 것이 아니라, 계속해서 찾아오는 기회를 놓치지 않는 것입니다.

공유 네트워크와 공유 서버는 다른 사용자의 영향을 받기 쉬우며 피크 시간대에 흔들리는 경향이 있습니다. 지역별 전용 엔드포인트와 전용 서버를 이용하면 혼잡을 우회하고, 전용 고속도로처럼 데이터를 전달할 수 있습니다. 스트림 수신은 거리에 특히 민감하기 때문에, 이를 전용 자원으로 가장 가까운 곳에 배치하는 것이 체감 성능에 큰 영향을 미칩니다. 송신 또한 전용 경로를 통해 인근 거점에서 이루어질 때만 의도한 대로 작동합니다(전용 자원의 유일한 사용자이므로 공유 자원의 스로틀링이나 대기열의 영향을 덜 받습니다).

가까움은 감이 아니라 데이터로 판단해야 합니다. 먼저 현재 에포크에서 자신의 위치를 파악하십시오. getEpochInfo로 에포크 데이터를 가져와 경과 슬롯과 남은 슬롯을 확인합니다. 그다음 getRecentPerformanceSamples를 사용해 최근 평균 슬롯 시간을 추정합니다. 남은 슬롯 수에 평균 슬롯 시간을 곱하면 전환까지 대략 몇 초가 남았는지 알 수 있습니다. 이를 통해 준비와 거점 전환 계획을 더 쉽게 세울 수 있습니다.

전환이 다가오면 getSlotLeaders로 목표 구간의 리더를 가져와 단기 후보를 좁혀 나갑니다. getClusterNodes로 클러스터 노드 목록을 확인할 수 있습니다. 리더의 신원을 노드 데이터와 대조한 다음, 공개 IP나 gossip 주소를 이용해 지리적 후보를 추정합니다.

다만 주의가 필요합니다. IP 기반 위치 추정은 부정확하거나 오래된 정보일 수 있으므로, 대략적인 지도를 얻은 뒤에는 실제로 각 거점에서 핑을 보내 왕복 시간을 직접 측정해야 합니다. 네트워크는 자동차 여행과 비슷합니다. 거리도 중요하지만 경로 선택에 따라 도착 시간이 달라집니다. 핑은 오늘의 "도로"가 얼마나 혼잡한지를 압축적으로 보여주는 지표입니다. 한 번의 측정에 의존하지 말고, 짧은 시간 안에 여러 차례 가벼운 핑을 실행한 뒤 중앙값을 기준으로 판단해 노이즈를 줄이십시오.

측정 결과는 버리지 마십시오. 거점별 측정값과 매핑을 자체 데이터베이스에 저장하고, 각 에포크가 바뀔 때마다 경량 워커가 변동분을 업데이트하도록 하십시오. 그러면 일상적인 운영이 더 안정되고 판단도 더 빨라집니다.

모든 것을 매번 처음부터 다시 계산한다면, 그 속도는 측정 자체에 소모됩니다. 실제로는 리더와 지역의 매핑, 그리고 거점별 지연 값을 데이터베이스에 저장해 두는 것이 효율적입니다. 각 에포크 경계마다 워커로 이를 업데이트하십시오. 런타임 애플리케이션은 이 데이터베이스를 읽어 어떤 거점을 사용할지 즉시 판단하게 됩니다. 수신은 스트림 소스 인근에 배치하고, 송신은 다음 리더의 지역에서 조금 미리 준비하십시오. 역할을 분리하면 전체 결합 지연이 낮아집니다.

각 거점에서는 고클럭 CPU, DDR5 메모리, 최신 NVMe를 사용하고 평상시 사용률을 낮게 유지하십시오. 마이크로 레벨의 튜닝은 멀티 리전 설계가 제 효과를 발휘하게 하는 기반입니다. 매크로 레벨에서는 전용 엔드포인트와 서버를 동일한 네트워크 안에 공동 배치하여, 공용 인터넷을 거치지 않는 "제로 거리 통신"을 최대화하십시오. 거점 간 릴레이의 경우, 자체 전용 경로가 일반적인 공용 RPC 경로보다 전환 대기 시간을 줄여주는 경우가 많습니다.

리더 인근에서 수신하고, 리더 인근에서 송신하십시오. "인근"이라는 위치가 계속 바뀌기 때문에 여러 지역에 거점을 분산해야 합니다. 필요한 것은 최신 일정을 추적하는 작은 메커니즘과, 거점을 합리적으로 배치하는 방법입니다. 저희는 데이터 왕복 시간을 줄이기 위한 구체적인 단계를 함께 설계해 드릴 수 있습니다. 여기에는 데이터베이스와 워커 설계, 거점 배치, 전용 엔드포인트 준비, 도시 간 전환 처리가 포함됩니다.

업데이트와 문의사항은 ERPC 웹 대시보드에서 확인하실 수 있습니다. 무료 체험과 테스트 환경도 이용 가능합니다. ERPC 웹 대시보드: https://dashboard.erpc.global/ko

항상 감사드립니다. 저희는 현장에서 꾸준히 테스트하고 성실하게 개선해 나가겠습니다. 여러분의 프로젝트가 성공하기를 바랍니다.