EL-CL 모니터링 대시보드: Nimbus와의 협력 연구
StereumLabs 는 MigaLabs 와의 협력을 통해 여러 합의 및 실행 클라이언트의 지표를 모니터링하도록 설계된 포괄적인 Grafana 대시보드 제품군을 개발했습니다. 70개 이상의 클라이언트 조합(슈퍼 노드 포함)이 지속적으로 운영 및 관찰되어 실제 네트워크 환경에서 클라이언트 동작에 대한 광범위하고 대표적인 시각을 제공합니다.
클라이언트 지표의 의미와 운영상 영향을 이해하는 것은 종종 어려울 수 있으며, 특히 정상적인 변동과 실제 오류를 구분하기 어려울 때 더욱 그렇습니다. 이 글에서는 Nimbus 합의 클라이언트에 영향을 미치는 버그를 이러한 대시보드를 통해 명확하고 신속하게 식별하는 방법을 살펴보고, 실제 모니터링 시나리오에서 대시보드의 실질적인 가치를 보여줍니다.
이 분석의 목적은 특정 클라이언트를 지목하는 것이 아니라, 효과적인 관찰 도구를 통해 비정상적인 행동을 즉시 파악할 수 있음을 보여주는 것입니다. 상황은 몇 시간 내에 정상으로 돌아왔고, 이번 사건은 전반적으로 큰 영향을 미치지 않았습니다. 동시에, 이 사건은 이더리움 생태계 내에서 클라이언트 다양성을 유지하는 것이 얼마나 중요한지 다시 한번 상기시켜 줍니다.
님버스 팀과의 공동 검토 회의 중에 후속 님버스 릴리스에서 측정 지표 지원이 누락된 사실이 발견되었는데, 이는 지속적인 관찰 가능성과 팀 간 소통의 중요성을 더욱 강조하는 결과였습니다.
또한, 이 문서에서는 Nimbus 일반 노드와 슈퍼 노드 간의 비교 분석을 제시하며, 대시보드의 병렬 표시 기능을 활용하여 PeerDAS 사양으로 인해 발생하는 운영상의 차이점을 설명합니다.
님버스 합의 고객 서비스 중단 — 2026년 2월 8일
2026년 2월 8일 UTC 기준 01:00~02:00 사이에 Nimbus 합의 클라이언트에서 중요한 버그가 발생하여 이더리움 메인넷 참여가 일시적으로 중단되었습니다.
공식 부검 결과에 따르면:
"님버스 클라이언트가 메인넷 블록 잘못된 것으로 판단하여 거부하고 포크했습니다. 이는 님버스 구현의 머클 트리 해싱에서 발생하는 캐시 손상 때문인데, 메인넷에 나타난 SSZ 리스트 객체의 특정 크기 변경으로 인해 올바른 캐시 무효화가 우회되었기 때문입니다. 잘못 판단되어 유효하지 않은 것으로 판정된 블록 의 하위 객체들이 다음과 같은 이유로 문제가 발생할 수 있습니다.
프로토콜을 위반하지 않고는 처리할 수 없었기 때문에, 노드가 재시작될 때까지 Nimbus는 메인넷의 정규 체인을 계속 따라갈 수 없었습니다.
노드 수준에서 관찰 가능한 영향
네트워크 접속은 몇 시간 후 정상으로 돌아왔지만, Nimbus 메트릭을 내보내는 모니터링 시스템에서는 운영상의 영향이 즉시 나타났습니다. 메트릭 시각화만으로는 근본 원인을 파악하기에 충분하지는 않지만, 프로토콜에 대한 전문 지식이 부족한 운영자에게도 비정상적인 동작이 발생하고 있음을 신속하고 명확하게 알려주는 지표를 제공합니다.
가장 두드러진 지표 중 하나는 "슬롯 뒤처짐" 지표였습니다. UTC 기준 약 02:00에 이 예시의 해당 노드(Nimbus/Nethermind)는 클록 슬롯보다 171슬롯 뒤처진 것으로 관찰되었으며, 이는 정규 체인과의 동기화가 손실되었음을 분명히 나타냅니다.
많은 전문 스테이킹 투자자들이 자신만의 대시보드를 운영하지만, 자신이 운영하지 않는 노드에 대한 데이터는 볼 수 없습니다. 다시 말해, 자신이 운영하는 노드에 대한 데이터만 볼 수 있고, 운영하지 않는 다른 클라이언트의 데이터와 비교할 수는 없습니다. 이것이 핵심적인 차이점 입니다.
StereumLabs는 수많은 노드 조합을 운영하고 있기 때문에 다른 노드에도 영향이 있는지, 있다면 어떤 노드인지 신속하게 확인할 수 있습니다. 실제로, 개요 동기화 상태 테이블 대시보드에서 명확한 패턴이 드러났습니다. Nimbus 합의 클라이언트를 실행하는 모든 인스턴스가 클록 슬롯을 놓치고 있는 반면, 다른 합의-실행 클라이언트 조합은 정상적으로 작동하고 있었습니다. 이러한 비교를 통해 로그를 자세히 검사하거나 수동으로 노드 간 상관관계를 분석할 필요 없이, 이상 현상을 한눈에 파악하고 원인을 찾아낼 수 있었습니다.
이러한 관찰 결과는 다른 합의 클라이언트의 전용 대시보드에서도 더욱 확증되었는데, 해당 클라이언트들의 동기화, 블록 처리 및 네트워킹 지표가 동일한 시간 동안 안정적으로 유지되었습니다.
동시에 블록 처리가 사실상 중단되었습니다. 새로 처리된 블록이 없다는 사실은 블록 가져오기 지표에 직접적으로 반영되어 운영 관점에서 문제가 명확해졌습니다.
네트워크 및 피어 연결성 저하
불안정성은 네트워킹 계층에서도 나타났습니다. 클라이언트가 표준 연결 체인에서 벗어나면서, 유효한 피어 연결을 설정하려고 반복적으로 시도했습니다. 이러한 동작은 다음을 통해 명확하게 관찰할 수 있었습니다.
연결된 피어
대역폭 활용률
libp2p 메트릭
시스템 수준의 네트워크 사용량과 프로토콜별 지표 모두 노드가 정규 블록을 성공적으로 검증하고 전파할 수 없는 상황과 일치하는 비정상적인 패턴을 보였습니다.
데이터베이스 활동 정체
데이터베이스 관련 지표는 문제를 더욱 명확히 보여주었습니다. 쓰기 작업과 상태 업데이트가 크게 감소했는데, 이는 클라이언트가 더 이상 새로운 정규 데이터를 성공적으로 처리하지 못하고 있음을 반영합니다. 이러한 결과는 노드가 단순히 일시적인 네트워크 지연을 겪는 것이 아니라 사실상 멈춰버린 상태임을 추가적으로 확인시켜 주었습니다.
전반적으로 이 버그로 인한 영향은 매우 제한적이었으며, 노드를 재부팅하는 것만으로 해결되었습니다. Nimbus는 Beacon 체인이 처음 등장한 이후로 큰 문제 없이 업계에서 가장 안정적인 CL 클라이언트 중 하나로 남아 있습니다. 버그 수정 패치는 불과 며칠 만에 배포되었으며, 이후로는 어떠한 문제도 관찰되지 않았습니다.
측정 지표 지원의 인지되지 않은 손실
이상 탐지는 이러한 대시보드 모음의 중요한 사용 사례 중 하나이지만 유일한 사용 사례는 아닙니다. Nimbus 팀과 대시보드 적용 범위 및 메트릭 노출에 대해 간략한 기술적 의견을 교환하는 과정에서 특정 메트릭에 영향을 미치는 회귀 오류를 발견했습니다.
이전 버전에서 제공되었던 클라이언트별 연결된 피어 분포 지표가 더 이상 제대로 내보내지지 않는 문제가 발생했습니다. 버전 비교 및 과거 대시보드 데이터를 분석한 결과, 이 변경 사항은 2025년 말에 배포된 릴리스와 관련이 있는 것으로 나타났으며, 이는 해당 업데이트 주기 동안 의도치 않게 발생한 회귀 오류일 가능성이 높습니다. 모든 이더리움 클라이언트는 릴리스 전에 다양한 테스트를 실행하지만, 이러한 테스트는 일반적으로 합의, 완결성, 유효성 검사, 성능 등과 같은 복잡한 문제를 다루는 반면, 운영에 중요하지 않은 지표는 항상 테스트 대상에 포함되는 것은 아닙니다.
이러한 결과는 지속적인 버전 간 관찰 가능성의 가치를 더욱 명확히 보여줍니다. 포괄적인 대시보드는 런타임 오류를 감지하는 것 외에도, 그렇지 않으면 알아차리지 못할 수도 있는 미묘한 지표 수준의 불일치를 드러내는 데 도움이 됩니다.
Nimbus 일반 노드와 슈퍼노드 비교
Stereumlabs 대시보드는 일반 노드와 슈퍼노드를 나란히 비교할 수 있는 기능을 제공하여 운영자가 이 두 구성 간의 운영상의 차이점을 관찰하고 정량화할 수 있도록 합니다.
Nimbus에서 일반 노드와 슈퍼노드의 차이점은 Fusaka 업그레이드(이더리움 개선 제안(EIP)-7594)의 일부로 도입된 PeerDAS 사양에 근거합니다. 핵심적인 아키텍처적 차이점은 각 노드가 관리하고 피어 투 피어 네트워크를 통해 전파하는 블롭 데이터 열의 수에 있습니다. 일반 노드는 무작위로 할당된 8개의 열 서브넷의 하위 집합을 구독하는 반면, 슈퍼노드는 128개의 모든 열 서브넷을 구독하여 전체 데이터 세트를 관리합니다.
슈퍼노드가 관리하는 데이터 거래량 훨씬 많기 때문에 가장 두드러지고 즉각적으로 확인할 수 있는 차이점은 전반적인 네트워크 대역폭 사용량에서 나타납니다. 이는 대시보드의 최상위 네트워크 I/O 패널에서 확인할 수 있습니다.
또한 이는 노드의 가십 계층 참여를 반영하는 libp2p 대역폭 측정 결과에 의해서도 더욱 뒷받침됩니다.
슈퍼노드에서는 인바운드 및 아웃바운드 처리량이 모두 크게 증가하며, 컬럼 데이터가 수신 및 재전파될 때 슬롯 경계 부근에서 피크가 발생합니다. 직관적으로 슈퍼노드는 128개의 컬럼 서브넷을 모두 구독하는 반면 일반 노드는 8개만 구독하므로 대역폭이 일반 노드보다 약 16배 더 클 것으로 예상할 수 있지만, 실제로 관찰되는 배율은 훨씬 낮습니다. 이는 대역폭의 상당 부분이 서브넷 구독 수와 관계없이 고정된 네트워크 오버헤드(피어 관리, 인증, 블록 전파)에 의해 소모되는 데다, GossipSub 메시 토폴로지로 인해 노드가 특정 컬럼을 수신할 수 있는 피어 수가 제한되기 때문입니다. 이론적인 16배 비율은 대역폭이 고정 오버헤드 없이 순전히 컬럼 데이터 거래량 의 함수일 때만 성립하는데, 실제 P2P 네트워크에서는 그렇지 않습니다.
이 글을 작성하는 시점을 기준으로 7일간의 관찰 기간 동안, 평균 수신 및 송신 대역폭은 슈퍼 노드와 일반 노드 간에 약 40%의 차이를 보였습니다.
| 메가바이트/초 | 일반 최소 | 레귤러 맥스 | 정규 평균 | 슈퍼노드 최소 | 슈퍼노드 맥스 | 슈퍼노드 평균 | 델타 민 | 델타 맥스 | 델타 평균 |
|---|---|---|---|---|---|---|---|---|---|
| 받았다 | 5.7 | 10.1 | 7.65 | 10.8 | 81.4 | 18.9 | 52.78% | 12.41% | 40.48% |
| 전송됨 | 5.52 | 9.33 | 7.21 | 11.1 | 48.2 | 16.7 | 49.73% | 19.36% | 43.17% |
128개 열 서브넷 전체에 걸쳐 수행되는 KZG 셀 검증 및 가십 처리 작업 수가 더 많기 때문에 슈퍼 노드는 일반 노드보다 CPU 사용률이 더 높을 것으로 예상됩니다. 하지만 이 지표만으로는 두 구성 간의 확실한 차이를 구분할 수 없습니다.
정기적인:
슈퍼노드:
이 글을 작성하는 시점을 기준으로 7일간의 관찰 기간 동안, 특정 Nimbus/Nethermind 조합에서 슈퍼 노드와 일반 노드 간의 평균 CPU 사용률 차이는 1%포인트 미만(1.92% 대 2.74%)에 불과했습니다. 약 70%에 달하는 상대적 차이가 유의미해 보일 수 있지만, 절대값이 매우 낮다는 점을 고려해야 합니다. 1.92%에서 2.74%로의 증가는 실제 운영 환경에서 무시할 수 있는 수준입니다. 슈퍼 노드의 CPU 사용률이 약간 더 높은 것은 사실이지만, 실제 운영 환경에서는 우려할 만한 사항이 아닙니다.
| 정기적인 | 슈퍼노드 | 델타 | |
|---|---|---|---|
| CPU가 유휴 상태가 아닙니다. | 1.92% | 2.74% | 70.07% |
컬럼 관리 기간이 길어질수록 디스크 쓰기 처리량이 증가하고 합의 계층의 전체 스토리지 사용량도 늘어납니다. 슈퍼노드는 관리 기간 동안 모든 컬럼의 데이터를 유지하는 반면, 일반 노드는 할당된 하위 집합의 데이터만 관리하므로 디스크 사용량이 상대적으로 적습니다.
슈퍼노드에서 더 넓은 서브넷 참여는 더 크고 다양한 피어와의 상호 작용을 필요로 하므로 일반 노드에 비해 연결된 피어 수가 더 많습니다. 7일간의 관찰 기간 동안 일반 노드의 연결된 피어 수는 23~90개(평균 35개)였으며, 슈퍼노드의 연결된 피어 수는 50~161개(평균 112개)였습니다.
슈퍼노드는 128개 열 서브넷 모두를 구독하므로 활성 가십 토픽 구독 수가 훨씬 더 많습니다. 일반 노드는 할당된 8개 서브넷에만 참여하므로 가십 구독 지표에서 훨씬 낮은 값을 나타냅니다.
결론
이번 사건은 합의 클라이언트를 위한 포괄적인 관찰 가능성의 운영적 가치를 보여줍니다. 대시보드는 공식적인 디버깅이나 사후 분석을 대체할 수는 없지만, 클라이언트 상태 및 네트워크 참여에 대한 즉각적이고 실행 가능한 가시성을 제공합니다.
제시된 문제는 동기화 지연, 블록 처리, 피어 연결, 네트워크 활용률 및 데이터베이스 활동과 같은 여러 독립적인 측정 지표를 통해 명확하게 감지할 수 있었습니다. 이러한 다층적인 가시성을 통해 운영자는 이상 징후를 신속하게 파악하고 심각도를 평가하며 몇 시간이 아닌 몇 분 안에 시정 조치를 취할 수 있습니다.
또한, 2025년 말 릴리스 이후 누락된 연결된 피어 분포 메트릭을 확인한 것은 장기적인 메트릭 추적의 또 다른 핵심 이점을 보여줍니다. 버전 전반에 걸친 지속적인 모니터링은 런타임 오류를 감지하는 데 도움이 될 뿐만 아니라 회귀, 메트릭 불일치 및 관찰 가능성 자체의 의도치 않은 변경 사항도 드러냅니다. 구조화된 대시보드와 과거 비교 자료가 없다면 이러한 문제는 쉽게 간과될 수 있습니다.
숏, 잘 설계되고 지속적으로 관리되는 대시보드는 단순한 시각화 레이어가 아닙니다. 이는 이더리움 생태계에 필수적인 운영 인터페이스를 형성하여 검증 팀, 인프라 운영자 및 연구자들이 문제를 감지하고, 수정 사항을 검증하고, 클라이언트 동작을 비교하고, 안정성을 지속적으로 개선할 수 있도록 지원합니다.
