밸리데이터 인프라의 외부 모니터링 시스템 구축하기

Published in

A41 Tech Blog

26 min read3 days ago

A41의 이더리움 인프라 전환 기술 포스트는 총 5편으로 구성되어 있습니다. 각 글은 빠르게 증가하는 이더리움 검증인의 수에 대응하며 2024년 상반기에 A41이 마주한 문제들과 이를 해결한 전략들에 대해 소개합니다.

Author: Ahri (@heysoahri)

확장 가능한 블록체인 인프라를 위한 A41 테크팀의 고민과 선택들에 대한 기술 포스트 목록입니다. 다른 편을 읽고 싶으시다면 아래의 리스트를 확인해주세요.

밸리데이터의 활동은 블록체인 네트워크의 안정성과 신뢰 유지에 직접적인 영향을 미치기 때문에, 성능을 지속적으로 모니터링하고 신속히 대응하는 것이 중요합니다. 우리는 이더리움과 코스모스를 비롯한 다양한 블록체인 네트워크에서 밸리데이터로 활동하며, 그 책임을 다하기 위해 체계적인 모니터링 시스템을 내외부에서 운영하고 있습니다.

이러한 모니터링 시스템 고도화의 일환으로, 우리는 내부 시스템을 상호 보완하는 외부 모니터링 시스템을 구축했습니다. 앞선 글에서는 장애 상황의 정의와 서비스 내부에서 밸리데이터 상태를 모니터링하고 대응하는 방법에 대해 알아보았습니다. 이번 글에서는 더 넓은 관점에서 안정적이고 유연한 모니터링을 가능케 하는 외부 모니터링 시스템에 다룰 것입니다. 외부 모니터링 시스템을 통해 우리의 모니터링 능력이 한층 강화하고, 보다 성숙한 밸리데이터 운영 경험을 얻게 된 그 여정을 소개하겠습니다.

외부 모니터링 시스템이란?

1. 외부 모니터링의 역할과 중요성

밸리데이터의 내부 모니터링 시스템은 주로 Prometheus와 같은 도구들로 구성됩니다. 이는 밸리데이터와 동일한 환경에서 설치되며, 서버의 디스크 사용량이나 CPU 활동과 같은 기본적인 시스템 메트릭부터 체인에 특화된 세부 메트릭까지 광범위한 데이터를 수집할 수 있습니다. 그러나 내부 모니터링 시스템만으로는 다음과 같은 한계점들이 존재합니다.

데이터 정합성 문제
내부 모니터링은 밸리데이터 자체의 상태만를 바라보기 때문에, 전체 네트워크와 데이터가 불일치하는 상황을 인지하기 어렵습니다. 예를 들어, 밸리데이터가 일시적으로 전체 네트워크와 동기화되지 않은 상태라면, 내부에서 수집된 데이터가 실제 네트워크 상황을 정확히 반영하지 못할 수 있습니다.
데이터 다양성의 제한
체인이 자체적으로 제공하는 메트릭만으로는 우리가 원하는 지표를 수집하기 어려울 수 있습니다. 외부 모니터링 시스템은 이러한 한계를 극복하고 추가적인 데이터 수집을 통해 더욱 세밀한 모니터링을 가능케 합니다. 이는 궁극적으로 성능 최적화와 신속한 장애 대응을 위한 지표로 활용될 수 있습니다.
내부 모니터링 장애 상황 대비의 필요성
내부 모니터링 시스템 자체에 문제가 발생할 경우, 실제 장애 상황인지 모니터링 시스템의 오류인지 판별하기 어려워집니다. 노드 이관이나 재시작 과정에서 내부 메트릭 접근이 일시적으로 불가능한 상황에서도, 외부 모니터링은 끊임없는 모니터링을 보장할 수 있습니다. 특히 지난 Ethereum Dencun 업그레이드와 같은 중요 이벤트로 인해 내부 메트릭 사용이 제한될 때, 외부 모니터링은 필수적인 보조 시스템으로 기능합니다.
인터페이스 다양성 관리
네트워크 안정성 강화를 위해 일부 체인, 특히 이더리움에서는 다양한 클라이언트 조합으로 운영하고 있습니다. 이로 인해 같은 체인에서도 서비스별, 클라이언트별로 다양한 모니터링 인터페이스가 존재하는 복잡성이 발생하여 모니터링 시스템 구축과 관리의 어려움을 가져옵니다.

이를 보완하고 기존 시스템과 상호작용 하기 위한 외부 모니터링 시스템의 목표를 다음과 같이 정의할 수 있습니다. 밸리데이터 모니터링의 단일 실패 지점(Single point of failure) 문제를 해결하고 시스템의 중복성(Redundancy)을 강화하는 것입니다. 궁극적으로 이를 통해 밸리데이터의 의무를 더욱 체계적이고 신뢰 있게 수행할 수 있는 기반을 마련하는 것이 외부 모니터링 시스템의 존재 이유입니다.

2. 외부 모니터링의 필수 요구사항

따라서 외부 모니터링 시스템이 갖추어야 할 조건은 다음과 같습니다.

내부 모니터링과의 독립성
외부 모니터링 시스템은 내부 모니터링 시스템과는 다르게 데이터를 수집(예: 외부 RPC노드)해야 합니다. 또한, 내부 밸리데이터 노드와 물리적으로 분리된 곳에 구축되어 단일 실패 지점 문제를 해결해야 합니다.
밸리데이터 의무 모니터링
외부 모니터링 시스템의 주요 목표는 우리가 운영 중인 밸리데이터가 그 의무를 제대로 수행하고 있는지를 시스템 외부에서 객관적으로 감시하는 것입니다. 이를 위해 각 체인의 특성에 맞는 적절한 지표들을 수집하여 밸리데이터의 활동을 모니터링하고, 정확하게 평가할 수 있어야 합니다.
범용적인 모니터링 인터페이스
모든 환경에서 일관되게 적용할 수 있는 모니터링 방식을 구현해야 합니다. 이는 우리가 운영 중인 이더리움의 다양한 클라이언트와 서비스에서 동일한 인터페이스로 모니터링할 수 있게 합니다.
메트릭 시각화
외부 모니터링을 통해 수집한 메트릭을 Grafana 대시보드를 통해 직관적으로 시각화할 수 있어야 합니다.
알림 시스템
체인의 장애 상황을 신속하게 감지하여 알림을 발생시킴으로써, 즉각적인 대응이 가능하도록 해야 합니다.

이렇게 정의한 요구사항으로 구현된 외부 모니터링 시스템은 밸리데이터 운영의 안정성과 신뢰성을 한 단계 높여줍니다. 기존 시스템을 보완하고 다양한 환경에서 일관된 모니터링이 가능해져, 밸리데이터의 의무를 더 효과적으로 수행할 수 있게 됩니다. 이어서 실제 우리가 구현한 외부 모니터링 시스템의 구조와 핵심 기능에 대해 자세히 살펴보겠습니다.

A41의 외부 모니터링 시스템 소개

1. 이더리움 밸리데이터 모니터링

A41은 Lido, Mantle, Ether.fi 등 다양한 유동화 서비스 프로토콜의 운영자로 활발히 참여하고 있습니다. 또한, 네트워크 안정성 향상을 위해 클라이언트 다양성(Client Diversity)을 추구하며 여러 종류의 이더리움 클라이언트를 사용하고 있습니다. 이때, 기존의 오픈소스 모니터링 솔루션들은 특정 서비스에 국한되어 있거나 우리의 서비스 요구사항에 맞춰 수정하는 것이 쉽지 않았습니다. 또, 필요한 기능을 즉각적으로 제공받지 못하거나 운영하는 모든 서비스를 모니터링 하지 못하는 어려움이 있었습니다.

이런 한계를 극복하고자, 우리는 앞서 정의한 요구사항을 충족할 수 있는 맞춤형 이더리움 외부 모니터링 서비스를 자체 개발하였습니다. 이를 통해, 우리는 다양한 운영 환경을 통합적이고 세밀하게 모니터링할 수 있게 되었습니다.

효과적인 모니터링 시스템을 구축하기 위해서는 먼저 밸리데이터의 역할과 의무를 정확히 이해하는 것이 중요합니다. 이제 이더리움 밸리데이터의 주요 의무와 그에 따른 리워드 및 패널티 체계를 설명하고, 이를 기반으로 설정한 우리 모니터링 시스템의 핵심 지표들을 소개하겠습니다.

1.1 이더리움 밸리데이터의 의무와 Reward & Penalty

이더리움 밸리데이터는 네트워크에 참여하며 다음과 같은 활동에 대하여 리워드 혹은 패널티를 받게 됩니다.

Attestation
Active 상태의 밸리데이터는 매 Epoch(약 6분 24초)마다 네트워크에 Attestation(검증)을 제출해야 합니다. 밸리데이터들의 검증 정보가 종합되어 네트워크는 상태에 대한 합의를 이룰 수 있게 됩니다. Attestation은 다음 세 가지 투표(Vote)항목으로 세분화 되어 평가됩니다.

Source Vote: Source Checkpoint에 대한 투표
Target Vote: Target Checkpoint에 대한 투표
Head Vote: Head Block에 대한 투표

Attestation 보상은 밸리데이터 총 보상의 약 84.4%로 매우 큰 비중을 차지하고 있습니다. 보상을 받기 위해서는 정해진 Inclusion delay 이내에 블록에 포함되어야 하고 올바른 값으로 투표가 진행되어야 합니다. Inclusion delay란, Attestation이 생성된 슬롯과 해당 Attestation이 포함된 슬롯 번호와의 차이를 말하며, Inclusion distance라고 말하기도 합니다. 일반적으로 지연 없이 포함된 Attestation의 Inclusion delay는 1 입니다.

반대로 Attestation이 누락되고 지연되거나, 잘못된 투표가 이루어진 경우에는 패널티를 받게 됩니다.

각 투표 항목에 대해서 올바르게 투표했을 때, 리워드를 받을 수 있는 Inclusion delay는 다음과 같이 정의됩니다.

Source Vote: 5 Slot 이내
Target Vote: Inclusion delay와 무관
Head Vote: 1 Slot 이내

최근 Dencun 업그레이드에서 EIP-7045의 적용으로 해당 정의에 큰 변화가 있었습니다. Attestation이 포함 가능한 최대 슬롯이 기존 32 Slot 에서 다음 Epoch(Attestation한 슬롯이 있는 Epoch의 다음 Epoch)까지 확장되었습니다. Target Vote에 대해서도 기존에는 32 Slot 이내에 투표가 포함되어야 했지만, 이제는 Inclusion delay를 고려하지 않고 올바른 값으로 투표하기만 하면 리워드를 받을 수 있게 되었습니다.

이더리움의 최근 스펙을 참고하여 각 투표 시나리오 별 리워드와 패널티를 정리하면 다음과 같습니다.

Source Vote
Source Vote의 리워드를 받기 위해서는 올바른 값(Justified Checkpoint와 일치)으로 투표되어야 하고, 5 Slot 이내에 투표가 포함되어야 합니다. Source Vote의 유효성은 다른 투표에도 영향을 주는데, Source Vote가 올바르른 값으로 이루어지지 않으면 Target, Head Vote 유효하지 못한 투표로 간주됩니다. (Target Vote는 패널티를, Head Vote는 리워드를 받을 수 없습니다.)
Target Vote
Target Vote가 올바른 값(해당 Epoch의 Block Root와 일치)으로 투표되었다면, Dencun 업그레이드 이후부터는 Inclusion Delay에 상관없이 리워드를 받을 수 있습니다. Target Vote가 올바른 값으로 투표되었다는 것은 Source Vote도 올바른 값으로 투표되었다는 것을 전제로 합니다.
Head Vote
Head Vote 또한 리워드를 받기 위해서는 올바른 값(해당 Slot의 Block Root와 일치)으로 투표되어야 하고, 최소 Attestation Inclusion Delay(일반적으로 1 Slot) 이내에 투표가 포함되어야 합니다. Head Vote의 유효성은 Source, Target Vote가 모두 올바른 값으로 투표되었다는 것을 전제로 합니다.

Source 및 Target Vote가 올바르게 이루어지지 않으면 보상을 받지 못할 뿐만 아니라 해당 값만큼 패널티가 부과됩니다. 하지만 Head Vote의 경우에 패널티는 부과되지 않으며, 올바르게 이루어졌을 때의 리워드만 주어집니다. 따라서 우리는 각 투표 항목에 대해 1. 올바른 값으로 투표되었는지, 그리고 2. 정의된 Inclusion delay 안에 슬롯에 포함되었는지 모두 모니터링해야합니다.

Block Proposing
밸리데이터는 평균적으로 약 57일마다 한 번씩 블록을 제안할 기회를 얻습니다. 블록을 놓친 경우에 대한 패널티는 없지만, 성공적으로 블록을 제안할 경우 상당한 양의 보상을 받을 수 있습니다. 따라서 블록을 제안할 기회가 주어졌을 때 성공적으로 블록을 제안했는지 모니터링하는 것이 중요합니다.

Sign Sync Committee Messages
매 256epoch마다 512개의 밸리데이터가 Sync Committee로 선발되어 매 슬롯마다 메세지를 검토하고, 올바른 헤드 블록에 서명함으로써 보상을 받습니다. 참여하지 않거나 잘못된 헤드 블록에 서명하게 되면 받을 수 있었던 보상과 동일한 페널티를 받게 됩니다. Sync Committee로 선발된 기간 동안 받는 보상 또한 매우 크기 때문에 퍼포먼스를 측정하는 것이 중요합니다.

Sync Committee로 참여 중인 밸리데이터의 리워드(좌) / 그렇지 않은 밸리데이터의 리워드(우)

이더리움 밸리데이터의 보상 및 패널티에 관련된 모든 활동을 종합적으로 모니터링하기 위해, 우리는 External Ethereum Watcher를 자체 개발했습니다.

위의 표에서는 External Ethereum Watcher가 모니터링하는 주요 항목들을 보여줍니다. 이 항목들은 밸리데이터의 성능과 보상 및 패널티에 직접적인 영향을 미치는 중요한 지표들입니다.

1.2 Architecture Overview

External Ethereum Watcher는 Go로 개발된 Prometheus 메트릭 Exporter 서비스로, 이더리움 밸리데이터의 Pubkey를 등록하여 성능을 모니터링합니다. 이를 통해 밸리데이터가 의무를 적절히 수행하고 있는지 실시간으로 파악할 수 있습니다.
개발 과정에서 우리는 다음과 같은 핵심 요구사항을 정의했습니다.

서비스에 무관한 유연성
특정 서비스나 클라이언트, 네트워크에 종속되지 않고 다양한 환경의 이더리움 밸리데이터를 모두 모니터링 할 수 있어야 합니다.
대규모 키 모니터링
현재 우리는 약 16,000개의 밸리데이터를 운영하고 있기 때문에, 이들을 모두 모니터링 할 수 있도록 설계해야 합니다. 또한, 효과적인 지표 수집과 분석을 위해 모니터링 대상을 유연하게 추가하고, 라벨링 할 수 있어야 합니다.
외부 모니터링
밸리데이터와 분리된 별도의 외부 데이터 소스로부터 이더리움 네트워크 정보를 가져올 수 있어야 합니다.
효율적인 리소스 사용
대규모 키 모니터링 시 API 요청 횟수가 기하급수적으로 늘어나는 문제를 해결할 수 있어야 합니다. 리소스 사용을 최소화하면서도 정확한 모니터링이 가능해야 합니다.

이러한 요구사항을 충족시킬 수 있도록 구성된 External Ethereum Watcher의 핵심 컴포넌트들은 다음과 같습니다.

Key Service
Key Service를 통해 모니터링하고자 하는 밸리데이터의 Pubkey를 정해진 파일 형식에 따라 등록할 수 있습니다. 즉, 클라이언트, 서비스에 무관하게 오로지 Pubkey정보만을 가지고 모니터링이 가능 한 것 입니다. 이 과정에서 Pubkey를 라벨링할 수 있어, 노드 별 혹은 서비스별로 퍼포먼스 통계를 확인할 수 있습니다. Key Service는 Beacon Node로부터 밸리데이터의 상태와 밸리데이터 Index 정보를 받아옵니다. 이 정보는 다른 컴포넌트에서 사용되며, 모니터링 중인 밸리데이터의 상태를 메트릭으로 확인할 수 있도록 합니다.
Chain Watcher Service
매 Epoch마다 필요한 정보를 수집합니다. 이는 Epoch와 Slot의 정보, Attestation, Sync Committee에 관한 데이터를 포함하며, Beacon Node와 Beaconcha.in API를 통해 얻습니다. 수집된 정보는 Validator Watcher Service에서 활용됩니다.
Validator Watcher Service
Validator Watcher Service는 수집한 Attestation 정보를 분석하여, 모니터링 대상 밸리데이터들이 앞서 정의한 의무를 제대로 수행하고 있는지 확인합니다. 우리는 Validator Reward를 기반으로 확인하는 방식 대신, 매 슬롯의 Attestation 정보를 직접 분석하기로 했습니다. 이 접근 방식은 모니터링 대상 키가 증가해도 API 요청량이 비례하여 증가하지 않아, 대규모 모니터링에 효율적입니다.
Metric Service
마지막으로 Metric Service는 해당 Epoch에 대해 수집한 밸리데이터의 활동 지표를 Prometheus 메트릭으로 변환합니다.

매 Epoch마다 반복되는 서비스의 흐름은 다음과 같습니다.

매 Epoch마다 반복되는 External Ethereum Watcher 서비스의 흐름

1.3 Watching Validator Duty

위에서 언급한 바와 같이 External Ethereum Watcher는 효율적인 API 리소스 사용과 상세한 모니터링을 위해, 슬롯의 Attestation 정보를 통해 밸리데이터의 활동을 분석하는 방식을 채택했습니다.

Beacon Node API로부터 각 슬롯에 포함된 모든 Attestation 정보를 알 수 있습니다. 그 중 밸리데이터 의무 모니터링에 주요하게 사용하는 데이터들은 다음과 같습니다.

// Slot 정보
"execBlockHash": 현재 Slot의 포함된 Block
"blockroot": 현재 Slot의 BlockRoot
"epoch": 현재 Epoch
"exec_timestamp": Epoch의 Timestamp
"proposer": 현재 Slot의 블록 제안자
"slot": 현재 Slot
-------------------------------------
// Attestation 정보
"block_slot": Attestation이 포함된 Slot
"slot": Attestation이 이뤄진 Slot
"beaconblockroot": Head Vote한 Slot
"source_root": Source Vote한 Slot
"target_root": Target Vote한 Slot
"validators": 해당 Attestation에 참여한 밸리데이터 리스트

우선 현재 Epoch의 모든 Attestation 정보를 수집한 뒤, 우리가 모니터링 중인 밸리데이터의 Attestation만을 골라냅니다. 이 Attestation 값들을 분석하면, 다음 항목들에 대한 밸리데이터의 퍼포먼스를 확인할 수 있습니다.

Miss Block
만약 어떤 Slot의 블록이 비어있을 때, 즉 execBlockHash 의 값이 비어있을 때 proposer 가 모니터링 중인 밸리데이터라면, 해당 밸리데이터가 블록을 놓쳤다고 판단할 수 있습니다

Attestation
Attestation을 올바르게 수행하였는지 판단하려면, 세 개의 투표 항목(Head, Source, Target)에 대해서 정해진 Inclusion delay 안에 투표하였는지와 올바른 값으로 투표하였는지를 모두 확인해야 합니다.

Inclusion Delay는 투표가 이루어진 슬롯(slot)과 포함된 슬롯(block_slot)의 차이로 알 수 있습니다. (만약 두 슬롯 사이에 블록이 없는 슬롯이 있다면 계산에서 제외해야 합니다.)

각 투표의 유효성은 Head, Source, Target Vote가 각각 정의에 맞는 올바른 값으로 투표되었는지 BeaconBlockRoot , SourceEpoch , TargetVote 값을 비교하여 확인 가능합니다.

현재 이더리움 스펙에 의하면 Attestation은 다음 Epoch까지 포함 될 수 있습니다. 만약 현재 모니터링 하고 있는 Epoch과 바로 다음 Epoch의 슬롯에 Attestation이 하나도 포함되지 않았다면, 해당 밸리데이터는 이번 Epoch에서 Attestation을 하지 못했다고 판단할 수 있습니다.

다음은 이더리움의 최근 consensus-specs을 참고하여, 우리의 External Ethereum Watcher에서 사용 중인 Attestation 확인 로직을 간단한 의사코드로 나타낸 것입니다.

function CheckAttestation(attestation, data, inclusionDelay) {
    isTimelySource = inclusionDelay <= 5
    isTimelyHead = inclusionDelay <= 1

    isSourceValid = attestation.source == data.justified_checkpoint
    isSourceRewardable = isSourceValid && isTimelySource

    isTargetRewardable = isSourceValid && attestation.target == data.target_epoch
    isHeadRewardable = isSourceValid && isTargetRewardable && 
                    attestation.head == data.slot_block_root && isTimelyHead
}

Sync committee
Sync Committee는 256 epoch마다 512개의 밸리데이터로 구성됩니다. 우리는 먼저 현재 Committee에 모니터링 대상 밸리데이터가 포함되었는지 확인합니다. 선발된 밸리데이터가 있다면, 해당 밸리데이터의 슬롯별 Sync Committee Reward 정보를 Beacon Node에 요청합니다. Reward 값이 음수인 경우, 해당 슬롯에서 밸리데이터가 올바르게 참여하지 못한 것으로 판단할 수 있습니다.

//Beacon Node로부터 받아오는 Sync Committee 정보
type SyncCommittee struct {
 EndEpoch   int
 Period     int
 StartEpoch int
 Validators []int //모니터링 중인 밸리데이터가 참여 중인지 확인
}

1.4 Prometheus Metric & Grafana

매 Epoch마다 추가된 모든 밸리데이터들의 활동을 모니터링 한 결과를 정의된 Prometheus 메트릭 타입대로 발생시킵니다.

type Metrics struct {
 keyStatus                        *prometheus.GaugeVec
 missedAttestation                *prometheus.CounterVec
 delayedAttestation               *prometheus.CounterVec
 invalidHeadVote                  *prometheus.CounterVec
 invalidSourceVote                *prometheus.CounterVec
 invalidTargetVote                *prometheus.CounterVec
 missedCommittee                  *prometheus.CounterVec
 missedBlock                      *prometheus.CounterVec
 ...
}

Prometheus 메트릭은 Grafana 대시보드를 통해 시각화됩니다. 이 대시보드는 네트워크 유형(Mainnet, Holesky)별로 구분되며, 시간에 따른 주요 지표들을 한눈에 파악할 수 있는 그래프와 표로 구성되어 있습니다.

실제 사용 중인 External Ethereum Watcher의 Grafana 대시보드 일부

대시보드는 모니터링 대상으로 등록된 밸리데이터들의 상태부터 앞서 정의한 각종 지표들의 메트릭을 매 Epoch마다 업데이트하여 보여줍니다.

server-1:
 - 0x123456
 - 0x234567
server-2:
 - 0x345678
 - 0x456789

밸리데이터 키는 위와 같이 Label-Key 형태로 그룹화하여 등록하기 때문에, 대시보드에서 라벨별(서버 또는 서비스별) 밸리데이터 성능 지표를 확인할 수 있습니다. 이는 효과적인 성능 분석과 개선을 가능하게 합니다. 또한, 그라파나 대시보드에서 이더리움 익스플로러(beaconcha.in)로 직접 이동할 수 있는 UI를 제공하여, 밸리데이터의 비정상적인 활동을 신속하게 확인할 수 있습니다.

A41은 이더리움 외에도 다양한 블록체인 네트워크에서 밸리데이터로 활동하고 있습니다. 외부 모니터링의 필요성은 이더리움에 국한되지 않으며, 다른 체인들 또한 유사한 과제를 안고 있습니다. 이에 따라 우리는 공통화가 가능했던 Cosmos SDK 기반 체인들에 대한 외부 모니터링 시스템을 구축하였으며, 이어지는 내용에서 소개하고자 합니다.

2. 코스모스 SDK 기반 체인의 외부 모니터링

Cosmos SDK 기반 네트워크에서도 밸리데이터의 퍼포먼스를 모니터링하고 빠르게 대응하는 것이 매우 중요합니다. 이더리움과 달리 코스모스 기반 체인들은 밸리데이터의 의무 활동에 대해 즉각적인 리워드와 패널티를 부여하지는 않습니다. 그러나 특정 슬라이딩 윈도우 내에서 서명해야 할 블록 중 일정 비율 이상을 서명하지 못할 경우, 슬래싱이라는 매우 큰 패널티가 주어집니다. 또한, 밸리데이터의 업타임(Uptime)은 신뢰성에 중요한 지표로 작용합니다. 우리는 Cosmos SDK 기반 생태계에서 10개 이상의 메인넷과 테스트넷에서 밸리데이터로 참여하고 있기 때문에, 여러 체인에 대한 지표를 한 번에 확인하고 파악할 수 있는 시스템을 구축하는 것이 중요했습니다. 참여하고 있는 모든 체인에 대해서 지원 가능해야 하며, 기존 모니터링 시스템과 연동 가능해야 했습니다. 결론적으로, Cosmos SDK 기반 네트워크의 외부 모니터링에는 해당 요구사항을 모두 만족하는 Kiln의 오픈소스 서비스인 Cosmos Validator Watcher를 채택했습니다.

Cosmos Validator Watcher의 주요 특징은 다음과 같습니다.

Cosmos SDK 기반의 체인 모니터링
CometBFT 라이브러리를 사용한 모든 Cosmos SDK 기반 블록체인을 모니터링할 수 있습니다.
실시간 밸리데이터 모니터링
네트워크를 실시간으로 모니터링 하여 블록 서명 누락에 대해 즉각적으로 감지할 수 있습니다. 또 네트워크상에서 현재 밸리데이터의 상태(토큰, 밸리데이터 순위, Active, Jail 여부 등)를 확인할 수 있습니다.
외부 모니터링
네트워크의 상태를 받아올 RPC 앤드포인트를 지정할 수 있습니다. 외부 RPC 주소를 바라보도록 배포하여 우리가 필요로 하는 외부 모니터링의 목적을 이룰 수 있습니다.
Prometheus & Grafana
Prometheus에서 사용 가능한 메트릭 Exporter이며, 훌륭한 Grafana 대시보드를 기본적으로 제공합니다.
확장성
Cosmos Validator Watcher는 MIT라이센스 하에 오픈소스화 되어있습니다. 우리가 원하는 메트릭을 유연하게 추가하거나 수정해서 사용할 수 있도록 설계되어 있었습니다. 실제로 Initia Testnet을 모니터링 대상으로 추가할 때, 코드를 일부 수정하여 Initia가 별도로 사용하고 있는 Staking 모듈에 대해서 지원 가능하도록 했습니다.

Cosmos Validator Watcher를 활용하여 우리가 참여 중인 모든 Cosmos SDK 기반 체인에 대한 외부 모니터링 시스템을 구축했습니다. Grafana 대시보드를 통해 모든 체인의 퍼포먼스를 한눈에 확인할 수 있으며, Uptime이 낮은 장애 상황에서는 알림을 발생시켜 즉각적인 대응이 가능합니다.

실제 사용 중인 Cosmos Validator Watcher의 Grafana 대시보드 일부

실제로 내부 모니터링을 사용 할 수 없는 장애 상황에서, 외부 모니터링 시스템이 그 역할을 대신할 수 있도록 대시보드와 알러트 시스템이 구축되어 있습니다. 이를 통해 모니터링의 부재나 빈틈이 없는 견고하고 안정된 모니터링이 가능합니다.

외부 모니터링과 내부 모니터링이 동시에 장애 상황을 감지하고 알림을 발생하는 예시

마치며

외부 모니터링 시스템의 도입은 내부 모니터링 시스템을 보완하고, 다양한 측면에서 밸리데이터 운영의 안정성을 크게 향상했습니다.

데이터 다양성
외부 모니터링 시스템을 통해 내부 및 외부 데이터를 모두 수집하여 더 다양하고 신뢰할 수 있는 데이터를 확보하게 되었습니다. 특히, 직접 개발한 External Ethereum Watcher는 이더리움 운영에서 팀 내부의 요구사항과 필요로 하는 지표를 신속하게 추가하고 확인할 수 있는 유연한 서비스를 제공합니다. 이를 통해 더 고도화되고 효과적인 모니터링이 가능해졌습니다.
단일 인터페이스로 모든 밸리데이터를 모니터링
기존에는 서비스별로 제공된 외부 모니터링 오픈소스에 의존해야 했기 때문에, 모니터링 하지 못하는 밸리데이터들이 존재했습니다. 오픈소스는 우리가 필요로 하는 데이터를 제공하지 않거나, 밸리데이터를 원하는 대로 그룹화하여 지표를 확인할 수 없는 불편함이 존재했습니다. 하지만 새로 개발한 외부 모니터링 시스템을 통해 다양한 클라이언트 및 서비스에 관계없이 운영 중인 모든 밸리데이터의 퍼포먼스를 하나의 인터페이스에서 확인할 수 있게 되어 운영 효율성을 크게 향상했습니다. 특히 이더리움 서비스를 베어베탈 환경에서 클러스터 환경으로 이관하는 과정에서도 그 장점을 발휘할 수 있었습니다. External Ethereum Watcher에 클러스터로 이관하는 밸리데이터를 빠르게 추가할 수 있었고, 버킷 별로, 또 기존 베어메탈 환경과 퍼포먼스를 비교하며 발생하는 문제를 해결하고, 안정적인 이관이 가능하도록 했습니다.
장애 상황에서의 대응
체인의 상태가 불안정하거나, 내부 메트릭의 접근이 어려운 상황에서는 외부 모니터링 시스템을 통해 밸리데이터의 상태를 정확하게 체크할 수 있었습니다. 실제로, Berachain Testnet 운영 중 내부 메트릭이 정상적인 데이터를 수집하지 못하던 상황에서는 외부 모니터링에 의존하여 퍼포먼스를 확인하고 문제를 해결할 수 있었습니다.

종합적으로, 외부 모니터링 시스템의 도입은 밸리데이터 운영의 안정성을 크게 향상했습니다. 앞으로도 우리는 모니터링 시스템을 지속적으로 개선하여 최적의 퍼포먼스를 유지하고, 블록체인 네트워크의 안정성과 신뢰성을 강화하기 위해 노력할 것입니다.

다음 글에서는 이번 글에서 가볍게 다뤘던 밸리데이터의 리워드와 패널티 시스템에 대해 보다 더 자세히 살펴보겠습니다. 또한 우리가 전문 밸리데이터 운영자로서 수익을 어떻게 정확하게 추적하고 관리하는지, 그 과정에서 마주친 과제들과 해결 방안에 대해 공유합니다. 해당 시리즈를 통해 전문 밸리데이터로서의 운영 경험을 더욱 깊이 있게 전달할 수 있기를 기대합니다.