Solana Shreds가 도착하지 않나요? 수신 환경 점검

빠른 Solana Shreds 스트림을 구독했지만 패킷은 띄엄띄엄 도착합니다. 수신한 Shreds는 정상적으로 파싱되지만, 누락된 조각이 너무 많아 트랜잭션을 추출할 수 없습니다. 같은 서버에서 gRPC는 정상적으로 작동하니, 다음으로 무엇을 확인해야 할지 알기 어렵습니다.

송신 측을 확인하는 동시에 애플리케이션 서버와 그 서버가 위치한 데이터센터도 살펴봐야 합니다. ERPC가 Shreds를 빠르게 전달하더라도 경로상의 UDP 제한이나 수신 서버의 처리 병목 때문에 애플리케이션이 그 속도의 이점을 누리지 못할 수 있습니다.

Shreds 스트림을 선택할 때는 패킷이 어떻게 도착하고, 어떻게 사용 가능한 데이터가 되는지 전체 경로를 고려해야 합니다. 네트워크 품질, 거리, 데이터센터 운영 정책은 Geyser Yellowstone gRPC, 일반 RPC와 API 트래픽, 트랜잭션 제출에도 공통으로 영향을 주는 성능 조건입니다.

ERPC의 빠른 Shreds 전달에서 수신 측 데이터센터와 애플리케이션 서버를 거쳐 사용 가능한 데이터에 이르는 개념도. 네트워크 제한과 서버 내부 처리 병목을 구분해 보여줍니다.

송신 측 기록과 수신 후 사용 가능한 데이터는 서로 다른 사실입니다

최근 ERPC 지원 문의 사례에서 송신 측이 짧은 시간 동안 측정한 결과, 초당 약 3,400–3,900개의 패킷이 기록되었습니다. 수신 측은 수신량이 초당 약 13개의 패킷이며 슬롯 재구성을 완료하지 못했다고 보고했습니다.

이 수치는 서로 다른 기간에 측정되었으며, 측정 방식이 서로 비교 가능한지도 확인되지 않았습니다. 따라서 이 수치로 전달 성공률이나 손실률을 판단할 수 없습니다. 송신 측 기록만으로 도착을 입증할 수는 없으며, 작성 시점에도 원인은 아직 확정되지 않았습니다.

수천 PPS라는 수치만으로 범용 서버에 이례적으로 높은 부하가 발생했다고 볼 수도 없습니다. 확인할 사항은 실제 경로에서 어떤 일이 일어나는지, 어떤 제한이 적용되는지, 짧은 시간에 트래픽이 어떻게 집중되는지, 수신이 어떻게 처리되는지, 각 카운터가 무엇을 측정하는지입니다.

같은 프랑크푸르트라도 네트워크 경로는 다를 수 있습니다

스트림 소스와 애플리케이션 서버가 모두 프랑크푸르트에 있어도 서로 다른 데이터센터에 있을 수 있습니다. 이런 구성에서는 트래픽이 한 시설을 나와 외부 네트워크를 거친 뒤 다른 시설로 들어갈 수 있습니다. 리전 이름이 같다는 이유만으로 같은 시설, 같은 네트워크 운영사, 같은 중간 장비를 사용한다고 볼 수는 없습니다.

ERPC 스트림 또는 RPC 서비스와 ERPC VPS 또는 Bare Metal 호스트가 동일한 물리적 거점에 배치된 경우, 서비스 서버와 애플리케이션 서버는 서로 가까운 랙에 위치하며 둘 사이의 통신은 내부 네트워크를 이용합니다. 이것이 ERPC의 제로 디스턴스 통신이 지향하는 방식입니다. 같은 도시를 선택하는 데서 더 나아가 물리적 배치와 수신 애플리케이션까지의 경로를 함께 설계합니다.

외부 네트워크를 거치는 프랑크푸르트의 서로 다른 데이터센터 간 경로와, 동일한 거점 안에서 가까운 랙과 내부 경로를 이용하는 ERPC 구성을 비교한 개념도. Shreds, Yellowstone gRPC, RPC, 트랜잭션 제출에 사용하는 ERPC 서비스와 애플리케이션 서버를 다룹니다.

ERPC 서비스와 애플리케이션 서버 사이의 통신이 외부 네트워크를 경유하지 않으면 경로가 짧아지고, 해당 구간에서 외부 네트워크의 혼잡과 라우팅 변경에 영향을 받을 여지도 줄어듭니다. 짧은 경로에 수신 및 처리에 필요한 자원이 결합되면 빠른 스트림의 이점을 활용할 기반이 마련됩니다. 결과는 패킷 도착과 애플리케이션 처리 양쪽에서 검증해야 합니다.

네트워크 조건은 모든 통신 유형에 영향을 줍니다

Shreds에서는 조각 누락으로 문제가 눈에 드러나지만, 동일한 인프라의 품질은 더 넓은 범위의 데이터 수신, API 요청, 트랜잭션 제출에도 영향을 줍니다. 프로토콜에 따라 애플리케이션에서 나타나는 증상과 측정할 지점이 달라집니다.

통신	네트워크 영향이 나타나는 지점	애플리케이션에서 확인할 사항
Shreds / UDP	패킷 손실과 지연, 재구성에 필요한 조각의 도착 여부	유효한 Shreds와 데이터를 재구성할 수 있을 때까지 걸리는 시간
Geyser Yellowstone gRPC	TCP 재전송 대기, 스트림 적체와 지연	동일한 업데이트를 수신하고 처리하기까지 걸리는 시간
RPC, API 및 서비스 간 트래픽	요청과 응답의 왕복, 혼잡 시 대기	응답 시간과 그 변동
트랜잭션 제출	수신 노드까지의 요청 경로	제출 요청부터 노드 응답까지 걸리는 시간

가까운 배치와 적절한 운영 정책은 이러한 모든 트래픽을 뒷받침합니다. 수신 노드의 응답 시간은 트랜잭션이 블록에 포함되고 온체인에서 최종 확정되기까지 걸리는 시간과 구분하여 측정해야 합니다.

Gbps만으로는 PPS와 버스트를 모두 알 수 없습니다

대역폭은 일정 시간 동안 전달할 수 있는 데이터의 양을 나타냅니다. PPS는 초당 처리되는 패킷 수를 나타냅니다. 연결에 대역폭 여유가 있어도 초당 패킷 수 제한이나 UDP에 적용된 제한에 걸릴 수 있습니다. 클라우드 제공업체의 공식 문서도 대역폭과 PPS 허용량을 별개의 제약으로 다룹니다.[1]

Shreds가 항상 일정한 속도로 도착하는 것은 아닙니다. 버스트는 평균값에 드러나지 않는 큐 부하를 만들 수 있습니다. 네트워크 장비나 수신 측의 처리 속도보다 빠르게 패킷이 쌓이면, 큐 용량을 초과한 패킷이 버려질 수 있습니다.[2]

호스팅 제공업체에 지속적인 UDP 수신, 짧은 버스트, PPS 제한, DDoS 보호가 적용하는 규칙을 문의하세요. 목표는 보호 기능을 무분별하게 끄는 것이 아니라 필요한 트래픽을 안전하게 수용할 수 있는 조건을 마련하는 것입니다.

gRPC가 작동한다고 UDP 수신도 정상인 것은 아닙니다

TCP 기반 gRPC와 UDP로 전달되는 원시 Shreds는 서로 다른 전송 메커니즘을 사용합니다. TCP는 재전송과 순서 보장을 제공하며, 스트리밍 gRPC에는 수신 측 처리 용량을 고려하는 흐름 제어가 있습니다. UDP 자체는 누락된 패킷을 재전송하지 않으며, 수신 애플리케이션이 처리를 따라잡을 때까지 송신 측을 기다리게 하지도 않습니다.[3]

따라서 서버에서 gRPC가 작동한다고 해서 UDP 경로나 수신 측이 정상적으로 작동한다는 뜻은 아닙니다. 프로토콜별 필터, 포트, 전달 경로, 수신 구현을 각각 확인해야 합니다. gRPC 처리 지연 역시 대기 시간이나 연결 끊김으로 나타날 수 있습니다.

gRPC의 transactions/sec와 UDP의 packets/sec는 서로 다른 처리 단계에서 서로 다른 단위를 측정합니다. 이 둘을 직접 비교해 전달량이나 손실률을 계산할 수는 없습니다.

도착한 패킷이 사용 가능한 데이터가 되기까지

표준 UDP 소켓 수신기를 사용하는 경우, 도착한 패킷은 NIC, 커널, 소켓 수신 버퍼를 거친 뒤 애플리케이션에 도달합니다. 처리가 뒤처지면 호스트에 도착한 뒤에도 패킷이 버려질 수 있습니다. Linux 인터페이스의 수신 카운터에는 이후 단계에서 버려진 패킷도 포함되므로, 수신 카운트가 증가한다는 사실만으로 애플리케이션에 전달되었다고 판단할 수는 없습니다.[4]

전체 CPU 사용률이 낮아도 특정 수신 큐나 CPU 코어에 부하가 집중될 수 있습니다. NIC 큐, 인터럽트 배치, 단일 코어 성능을 확인하세요. 애플리케이션에서는 상황에 맞게 수신과 후속 작업을 분리하고, 부하가 큰 파싱이나 과도한 로깅을 수신 루프에서 제외하세요. 수신 버퍼를 크게 하면 일시적인 버스트를 흡수할 수 있지만, 지속적인 처리 용량 부족을 해결할 수는 없습니다.[5]

Shreds는 블록 데이터의 조각입니다. 순방향 오류 정정(FEC)은 같은 그룹의 data shreds와 coding shreds를 이용해 누락된 데이터를 복구할 수 있지만, 재구성에는 여전히 충분한 조각이 필요합니다. 중복 패킷이 더 많아져도 누락된 조각을 대신할 수는 없습니다.[6]

구현 방식에 따라 수신 측은 전체 슬롯이 완성되기 전에 확보한 조각으로 엔트리를 재구성할 수 있습니다.[9] 총 패킷 수와 함께 중복 없는 유효 Shreds, 재구성된 데이터, 애플리케이션이 필요한 이벤트를 인식하기까지 걸리는 시간을 측정하세요.

같은 시간 구간에서 각 단계를 측정하세요

양쪽의 목적지, 포트, 측정 시간 구간을 맞추세요. 다음 단계를 각각 기록하면 후속 조사의 범위를 좁힐 수 있습니다.

측정 지점	기록할 내용	확인할 수 있는 사실
송신 측	대상 목적지에 대한 기록과 카운터의 정의	어떤 송신 단계를 관찰했는지
수신 호스트 진입점	대상 UDP 트래픽 캡처, NIC 통계, 캡처 중 손실	해당 관측 지점에서 보인 트래픽의 양
OS와 소켓	UDP 오류, 수신 버퍼 드롭, 큐 변화	호스트 내부에서 수신이 적체되는지
Shreds 재구성	중복 없는 유효 Shreds, 재구성 성공 여부, 누락 데이터와 오류	패킷으로 필요한 데이터를 얻을 수 있는지
애플리케이션	처리 적체와 동일 이벤트의 감지 타임스탬프	도착 속도가 애플리케이션까지 이어지는지

캡처에서 패킷이 적게 보이면 먼저 필터, 관찰 중인 인터페이스, 캡처 손실, NIC 드롭을 확인하세요. 일부 OS 카운터는 호스트 전체나 네트워크 네임스페이스 전체를 대상으로 하므로, 집계 범위를 확인한 뒤 대상 애플리케이션의 측정값과 대조해야 합니다.[4][5]

제약이 발생하는 단계를 확인한 뒤 설정을 변경하세요. 버퍼나 링만 늘리면 병목이 다른 곳으로 이동하거나 대기 시간이 늘어날 수 있습니다. ERPC의 현재 수신 설정과 점검 방법은 다음 문서에서 확인할 수 있습니다:

https://erpc.global/ko/doc/shredstream/udp-forwarding/

서버와 함께 운영 정책도 선택하세요

Solana Foundation은 고성능 검증자 운영에서 NIC, 물리 코어, 드라이버, 네트워크를 제어할 수 있는 것이 중요하다고 설명합니다. 검증자 자체를 운영하는 데 필요한 이러한 요구 사항을 모든 Shreds 수신기에 일괄 적용해서는 안 됩니다. 수신 애플리케이션에는 자체 스트림과 처리 워크로드에 맞는 구성이 필요합니다.[7]

비용이나 전력 소비를 줄이는 것은 합리적인 운영 목표입니다. HFT와 실시간 애플리케이션에는 CPU의 빠른 응답, 지속적인 처리 용량, 짧은 네트워크 대기 시간도 필요합니다. 절전 상태에서 복귀하는 과정에는 지연 시간 측면의 절충이 따를 수 있습니다.[8]

CPU 모델과 코어 수뿐 아니라 자원 공유 방식, 지속적인 부하 처리 방식, UDP 트래픽에 적용되는 조건, 실제 네트워크 경로도 확인하세요.

ERPC는 스트림과 수신 환경을 함께 고려합니다

ERPC는 Solana 인프라와 가까운 데이터센터 선정, 네트워크 경로, 하드웨어, 운영 설정을 함께 고려하고, Shreds와 gRPC에 더해 VPS와 Bare Metal도 제공합니다. 처리 워크로드에 맞춰 VPS를 선택할 수 있으며, 물리 자원을 독점적으로 사용하고 싶다면 Bare Metal을 비교해 볼 수 있습니다.

저희가 제공하는 환경의 구성과 운영 방식을 이해하는 것은 기술적인 문제 해결에도 도움이 됩니다. 저희는 송신 측 기록과 수신 측 측정값을 비교하여 네트워크, OS, 애플리케이션에서 구체적으로 확인할 항목을 찾을 수 있습니다. 이 글에서 소개한 문의에서는 송신 측 측정값을 확인하고 수신 측에 추가 측정을 요청했습니다.

스트림, 수신 측 배치, 애플리케이션 구현을 함께 평가하면 선택한 서비스와 필요한 데이터 사이에서 무엇이 부족한지 더 쉽게 파악할 수 있습니다.

시간당 과금으로 현재 환경과 비교하세요

수신 환경에 확신이 없다면 시간당 과금으로 ERPC VPS 또는 Bare Metal 서버를 사용해 보고, 같은 스트림과 애플리케이션으로 비교해 보세요. 원하는 리전의 현재 가격, 가용 여부, 주문 조건은 대시보드에서 확인하세요.

사용 가능한 구성으로 시작해 수신 패킷 수, 재구성된 데이터, 처리 적체, 동일 이벤트의 감지 타임스탬프를 기록하세요. 호스트 간 타임스탬프를 비교할 때는 시계 동기화 정확도도 확인해야 합니다. 다른 시간에 테스트를 반복하고 경로의 어느 지점에서 결과가 달라지는지 비교하세요. 이러한 측정 결과를 바탕으로 애플리케이션에 맞는 서버와 데이터센터를 선택하세요.