[블록체인] - 솔라나 메인넷 노드, RPC 트러블슈팅

솔라나 메인넷 노드 서버를 운영하기 위해서는 하드웨어 스팩이 좋아야 한다.

내가 관리하는 솔라나 서버는 Intel Xeon Gold 6442Y (48코어), 256GB RAM이라는 엄청난 스펙을 가지고 있지만 블록체인 노드의 지랄맞은 특성으로 인해 동기화 지연, Docker NAT 라우팅 문제, Nginx 포트 고갈(TIME_WAIT), I/O 최적화 과정까지 이슈가 있었다.

트러블슈팅 1. 점점 멀어지는 블록 동기화

노드를 설치하고 스냅샷을 다운받고 블록 동기화 진행 과정을 solana catchup 명령어로 모니터링을 하는데 블록이 점점 멀어졌다. 블록이 멀어진다는 것은 입금을 확인하는데 걸리는 시간이 지연되고, 출금도 지연되는 것이다. 즉 노드가 죽은거나 마찬가지였다. 

조치 1: --only-known-rpc 옵션 제거 

초기 validator.sh 스크립트에 --only-known-rpc 옵션이 들어가 있었다. 이 옵션은 노드에게 "내가 지정한 Validator 노드하고만 통신"하라고 강제하는 플러그이다. 만약 지정한 노드가 응답이 지연되면, 전 세계의 수많은 다른 노드들을 놔두고 응답을 기다리게된다. 솔라나의 강력한 가십(Gossip) 네트워크의 장점을 활용하지 못하게 된 것이다

> 물론 이 설정을 제거하면서 발생할 수 있는 문제가 있지만 블록 동기화가 지연되는것보다는 중요하지 않다는것이 판단이었다. 

트러블슈팅 2. Nginx Docker 환경의 curl: (7) 차단

동기화가 시작된 후, Nginx를 통해 외부 지갑 서비스에서 노드(3000번 포트)로 RPC 통신을 요청했다. 호스트 서버에서는 curl이 잘 먹히는데, Nginx Docker 컨테이너 내부에서만 curl: (7) Couldn't connect to server 에러가 발생하며 통신이 차단되었다.

원인: 도커 컨테이너의 아웃바운드 IP Masquerade

도커 컨테이너는 외부와 통신할 때 호스트 OS의 IP가 아닌, 가상 네트워크의 서브 IP(예: 51.89.x.x)로 변환(NAT)되어 나간다. 솔라나 서버의 iptables 방화벽에는 이러한 IP가 등록되어 있지 않아 차단당한것으로 보였다. 패킷 캡처(tcpdump)를 통해 추측이 확신이 되었다.

조치 : iptables 업데이트

도커 컨테이너 내부에서 curl ifconfig.me를 쳐서 나가는 아웃바운드 IP를 확인하고 솔라나 노드 서버의 iptable 에 해당 IP를 추가했다.

sudo iptables -I INPUT 1 -p tcp -s xx.xx.xxx.xx --dport 3000 -j ACCEPT

확인 : rpc 서버의 간혈적 응답지연

도커 내부에서 curl 을 반복적으로 요청하면 간혈적으로 되다가 안되고를 반복했다. 호스트 OS 에서는 간혈적으로 안되거나 하는 이슈가 없었다. 

트러블슈팅 3. 쏟아지는 Nginx 502 에러와 포트 고갈 (TIME_WAIT)

iptable 을 업데이트하고 이번엔 Nginx 로그에 502 Bad Gateway와  크리티컬([crit]) 로그가 생겼다. 

[crit] connect() to xxx.xxx.xxx.xxx:3000 failed (99: Cannot assign requested address) while connecting to upstream

원인: 월렛 서비스의 트래픽과 소켓 고갈

Cannot assign requested address 에러는 서버가 새로운 통신을 맺을 여유 포트(Socket)가 하나도 남지 않았을 때 발생한다. 프록시 서버의 접속 로그(access.log)를 분석해보니, 월렛 서비스의 워커에서 HTTP Keep-Alive를 사용하지 않고 1초에 수십 번씩 getBlock을 요청하고 있었다. 프록시 서버가 솔라나 노드와 연결을 맺고 끊기를 하다보면 소켓이 1분정도 TIME_WAIT 상태로 묶이게 되면서 사용 가능한 수만 개의 포트가 순식간에 사라진다. 

조치 1: 리눅스  커널 튜닝

프록시 서버에서 TIME_WAIT 상태의 소켓을 재사용하도록 커널을 수정했다. 

sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -p

조치 2: Upstream Keep-Alive 설정

프록시 서버가 매번 새로운 소켓을 열지 않고, 기존 연결을 재사용하도록 옵션에 keepalive 을 추가했다. 

upstream upstream-sol-mainnet {
    server xxx.xxx.xxx.xxx:3000;
    keepalive 64;             # 유지할 연결 수 추가
    keepalive_requests 1000;  # 한 연결당 처리할 요청 수
}

트러블슈팅 4. 자원 고갈과 스냅샷 다운로드 실패

통신 문제는 해결했지만, 노드를 켰더니 이번엔 장부(스냅샷)를 받아오지 못하고 무한 대기 상태에 빠졌다. 

[WARN] Failed to get RPC node version: error sending request for url... [INFO] Excluding <Node_ID> as a future RPC candidate

솔라나 노드가 주변 노드들에게 스냅샷을 요청했지만 응답을 받지 못해, '신뢰할 수 없는 노드'로 리스트에서 제외(Excluding)하고 있는 상태였다.

원인과 해결책

1. Dynamic Port 대역 추가: 초기 스크립트에 --dynamic-port-range 8000-8030 으로 31개가 설정되어 있어 가십 네트워크 통신에 병목 발생 가능성이 보여 --dynamic-port-range 8000-8200으로 증가시켰다. 
2. 다운로드 속도 제한 삭제: --minimal-snapshot-download-speed 50000000 (약 50MB/s) 옵션 때문에 네트워크가 지연되면 다운로드에 실패하는 이슈를 피하고자 해당 옵션을 삭제했다. 스냅샷 다운로드는 느릴지몰라도 스냅샷이 다운로드되어야 블록을 동기화할 수 있어서 빼버렸다. 

트러블슈팅 5. 그래도 멀어지는 블록 동기화 

할수있느 모든 조치를 했다고 생각이 들었지만 아직도 블록 동기화가 지연되지 않기 위해서는 새로운 작업이 필요해보였다. 

통신 이슈와 솔라나 validator 에 대한 모든 조치를 했음에도, 동기화가 조금씩 밀려나 동기화 속도를 최대한 끌어올려야 했다. 서버의 지리적 위치를 옮길수는 없으니 현재 주어진 자원에서 무언가를 해야했다.

1. 성능 최적화: 160GB 램디스크(tmpfs) 추가와 마운트

솔라나 노드가 계정(Accounts)의 상태를 디스크에 쓰고 지우는 I/O 작업으로도 동기화가 조금씩 밀릴 수 있었다. 현재 디스크는 NVMe 기반의 RAID 배열이자만 램 여유가 있어 램디스크를 추가했다. 

sudo mkdir -p /mnt/cryptocur-data/solana/accounts
sudo mount -t tmpfs -o size=100G tmpfs /mnt/cryptocur-data/solana/accounts

2. 스왑(Swap) 메모리 50GB 보험 추가 

램디스크를 쓰다가 순간적으로 메모리가 256GB를 꽉 채우면 리눅스의 OOM Killer가 노드를 죽여버릴 수 있어서 이를 방지하기 위해 NVMe 디스크 일부를 스왑 메모리로 수정했다. 

sudo fallocate -l 50G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

결론으로

솔라나 노드는 네트워크 성능, 소켓, 디스크 I/O 등 가장 지랄맞은 노드였다. 예전에는 동일한 문제가 있어 신뢰하는 노드와의 지리적 위치를 가까이 두었는데 전쟁때문에 그런가 석유가 없어서 전기가 약해져서 그런가(농담) 아무리 해도 문제가 해결되지 않는다.