쿠버네티스로 확장 가능한 이더리움 밸리데이터 인프라 구축하기

Published in

A41 Tech Blog

29 min read4 days ago

A41의 이더리움 인프라 전환 기술 포스트는 총 5편으로 구성되어 있습니다. 각 글은 빠르게 증가하는 이더리움 검증인의 수에 대응하며 2024년 상반기에 A41이 마주한 문제들과 이를 해결한 전략들에 대해 소개합니다.
이번 글은 첫번째 편으로, 우리가 쿠버네티스 기반으로 인프라 환경을 전환한 이유와 선택들에 대해 소개합니다. A41의 환경에 특화된 결정들이 많고, 우리의 글에서 소개하는 아키텍쳐가 범용적인 상황을 아우르는 답이 될수 없음을 미리 밝힙니다.

Author: Hudson (@r2jamong)

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

1. Overview

백만 밸리데이터. 2024년 7월 기준 이더리움은 탈중앙화된 백만개의 밸리데이터가 운영하는 PoS(Proof of stake) 블록체인입니다. 이 백만개가 넘는 밸리데이터들 중에는 네트워크에 직접 참여하는 경험을 위해, 혹은 스스로의 자산을 직접 스테이킹하기 위해 자신의 자산으로 1~2개의 밸리데이터 키를 운영하는 선구적인 “솔로 밸리데이터” 분들도 있습니다. 하지만 대다수의 밸리데이터들은 Lido, Etherfi등 밸리데이터 풀의 전문 오퍼레이터 혹은 거래소의 스테이킹 풀에서 운영하고 있습니다.

Ethereum Staking 비율 현황(2024년 7월, 출처 : Dune)

거래소의 경우 많게는 13%에 달하는 즉, 13만개가 넘는 밸리데이터를 운영해야 하며 오퍼레이터들 중에는 4% 이상의 밸리데이터를 운영하는 경우도 있습니다. 이 때 대다수의 PoS블록체인(하나의 밸리데이터 키에 제한없는 스테이킹이 가능한)과 다르게 이더리움의 경우 32ETH마다 하나의 밸리데이터를 새롭게 추가해야 하죠. 게다가 이더리움은 매 블록마다 밸리데이터들에게 의무가 주어지고 이를 수행함에 따라 실시간으로 보상과 패널티가 부여됩니다. 이러한 PoS이더리움의 독특한 구조는 상대적으로 정형화 되어있던 블록체인 인프라 환경에 확장성, 가용성, 성능, 보안 등에서 많은 과제를 안겨주었습니다.

A41은 Lido, Mantle, Ether.fi와 같은 LSP(Liquid Staking Protocol)풀의 오퍼레이터로서, 2023년 9월 Lido 오퍼레이터로 선정된 이후 다양한 풀에 참여해 10개월만에 16,000개 이상의 밸리데이터 키를 운영하는 오퍼레이터로 성장했습니다. 우리 팀은 이더리움 네트워크에 참여하기 전에도 수십 개의 메인넷 블록체인의 검증인으로 활발하게 활동하며 풍부한 경험을 쌓아왔습니다. 그럼에도 이더리움 검증인 인프라를 준비하는 과정에서 독특하고 다양한 도전 요소들을 마주하게 되었습니다. 10개월이라는 짧은 시간 동안 A41이 전체 이더리움 스테이킹의 1.5%에 달하는 규모로 성장하며 직면한 문제들은 무엇이었고, 문제를 해결하기 위해 어떤 고민을 해왔는지, 그리고 그 결과로 탄생한 인프라 아키텍처는 어떤 모습인지를 총 다섯 편의 기술 블로그를 통해 설명하려 합니다. 이번 포스트는 그 첫 번째 글로, 우리가 확장 가능한 이더리움 밸리데이터 노드를 구축하기 위해 쿠버네티스를 인프라 솔루션으로 선택한 과정과 이유를 설명합니다.

2. Architecture overview

A41의 이더리움 밸리데이터 노드 운영을 위한 전체적인 아키텍처를 살펴보겠습니다. 인프라 아키텍처, 각 컴포넌트의 배치, 모니터링, 알림 시스템을 포함한 한눈에 볼 수 있는 오버뷰는 다음과 같습니다.

총 5편의 A41 기술 블로그 포스트를 통해 위 아키텍쳐의 항목들에 대해 하나씩 자세히 확인할 수 있습니다.
쿠버네티스와 관련된 구조와 설계는 이 글 전반에 걸쳐 설명합니다.
이더리움 배포와 관련된 내용은 “2.이더리움 밸리데이터 유연하고 안전하게 배포하기” 에서 설명합니다.
모니터링과 관련된 내용은 “3.효율적인 모니터링과 신속한 장애 대응이 곧 퍼포먼스다”와 “4.밸리데이터 인프라의 외부 모니터링 시스템 구축하기”에서 설명합니다.
이더리움 밸리데이터 키의 라이프사이클과 보상 분배와 관련된 내용을 “5. 이더리움 밸리데이터 키, 리워드와 패널티 추적하기”에서 설명합니다.

3. 이더리움 밸리데이터 인프라의 특징

다양한 PoS(Proof of Stake) 체인이 존재하지만, 대부분의 블록체인의 인프라 환경과 이더리움은 몇 가지 중요한 차이가 있습니다. 이러한 차이점은 이더리움 밸리데이터 인프라를 구축하는 것을 상대적으로 복잡하게 만들며, 더 많은 고민을 요구합니다. 다음은 이더리움 밸리데이터를 운영하기 위해 반드시 고려해야 하는 몇 가지 독특한 특징들입니다.

직접 위임을 지원하지 않음
이더리움은 프로토콜 차원에서 “위임”을 지원하지 않습니다. 따라서, 블록체인의 동작을 위한 기본 컴포넌트 외에도, 위임을 지원하기 위한 추가적인 시스템 구축 혹은 중간자 시스템과의 통합이 필요합니다.
분리된 컴포넌트의 조합으로 구성된 아키텍처
대부분 하나의 실행 클라이언트로 동작하는 다른 체인과는 달리, 이더리움 클라이언트는 실행, 합의, 서명 등 역할에 따라 여러 컴포넌트로 분리되어 있습니다. 각 컴포넌트는 서로 다른 리소스 기준과 배포 환경을 요구하며, 이를 유연하게 배포하는 것은 경쟁력 있는 아키텍처를 구성하는 데 필수적입니다. 또한, 각 컴포넌트별로 모니터링 시스템을 구축할 필요가 있습니다.
다양한 클라이언트 지원
이더리움은 각 컴포넌트마다 다양한 클라이언트를 지원합니다. 클라이언트 다변화는 오픈소스 탈중앙 신뢰 네트워크인 이더리움에게 매우 중요한 요소입니다. A41 역시 이더리움 오퍼레이터로서 이더리움 네트워크의 건전성을 위해 다양한 클라이언트 조합에 대해 배포할 수 있는 환경을 구성해야 합니다. 모니터링 영역에서도 클라이언트가 하나가 아니라는 점은 큰 도전 요소입니다. 같은 기능을 하지만 서로 다른 컨트리뷰터들이 개발한 다양한 클라이언트들의 매트릭을 통합하는 것은 매우 어려운 부분입니다.
제한된 스테이킹 양
대부분의 PoS 체인은 하나의 검증인에 스테이킹할 수 있는 양이 무제한인 반면, 이더리움은 스테이킹을 하나의 검증인 키당 32 ETH로 제한하고 있습니다. 이는 이더리움 오퍼레이터들이 32 ETH마다 새로운 밸리데이터 키를 생성해야 함을 의미합니다. 따라서, 이더리움 검증인을 위한 인프라는 “경제적이고” “안전한” “확장성”을 고려해야 합니다.
더블 사이닝 방어
이더리움을 포함한 대부분의 PoS 체인에서는 검증인이 동일한 키로 서로 다른 서명을 두 번 이상 생성하여 제출하는 더블 사이닝은 가장 위험한 공격 행위로 간주되며, 이는 가장 큰 패널티(1 ETH 즉시 삭감 및 검증인에서 퇴출)를 부여합니다. 숙련된 전문 검증인들도 작업자의 실수나 잘못된 아키텍처로 인해 더블 사이닝으로 패널티를 받는 경우가 종종 있습니다.

이러한 특징들을 고려하여, A41은 이더리움 밸리데이터 인프라를 구축하고 운영하는 과정에서 쉽지 않은 도전과제들을 마주했습니다. 그리고 이를 해결하기 위해 시행착오를 겪었으며, 다양한 해결책과 대안들을 발견할 수 있었습니다. 다음 단락에서는 이러한 이더리움의 특징을 고려해 우리가 설계한 인프라의 전체적인 구성에 대해 살펴보겠습니다.

4. 기존 환경과 Kubernetes로의 전환

우리가 쿠버네티스 기반 구조로 전환하기 이전의 아키텍처에 대해 먼저 설명하겠습니다. 우리는 자체 데이터센터에 보유한 100여 대의 베어메탈 머신에서 쿠버네티스 등 오케스트레이션 도구를 사용하지 않은 컨테이너 환경으로 이더리움 밸리데이터 노드를 운영하고 있었습니다. 다음은 2024년 상반기까지의 이더리움 인프라 아키텍처의 모습입니다.

위와 같은 기존 구조는 빠르게 증가하는 위임량 수요와 앞서 설명한 이더리움 검증인 인프라의 특징을 고려할 때 안정성과 유지보수, 비용 등 여러 측면에서 더이상 적합하지 않다고 판단하게 되었습니다. 이에 우리 팀은 “이더리움의 운영 및 비용 효율화를 위한 기존의 환경 개선”을 2024년 상반기의 목표로 정했습니다. 그 첫번째 개선은 인프라 환경을 쿠버네티스로 전환하는 것이었습니다.

4.1. 쿠버네티스로 해결할수 있는 문제들

우리는 몇 가지의 검증을 거쳐 쿠버네티스 기반의 아키텍처로 전환할 것을 결정했으며, 이를 통해 다음과 같은 문제들을 해결할 수 있을 것으로 기대했습니다.

자원 활용의 문제

우리 자체 데이터센터의 100여 대의 장비는 이더리움 노드를 운영하기 위한 권장 사양을 훨씬 초과하는 고사양을 가지고 있습니다. 다른 PoS 블록체인들이 하나의 노드에서 모든 위임을 처리하는 것과 달리, 이더리움은 위임량에 따라 노드 수가 늘어나므로 리소스를 최대한 경제적으로 사용하는 것이 중요합니다. 쿠버네티스를 도입함으로써, 이러한 고사양 장비들을 보다 유연하게 활용할 수 있습니다.

확장성과 유지보수의 문제

Lido 오퍼레이터들의 데이터상으로 전문 이더리움 오퍼레이터들은 하나의 Validator client당 평균 500개의 밸리데이터를 운영하고 있습니다.

Lido 오퍼레이터 통계 (2024 1Q, 출처 : VaNOM: Lido on Ethereum Validator & Node metrics)

약 8개월 전, A41이 약 2,000개의 밸리데이터를 운영하던 상황에서는 굳이 우리 환경을 쿠버네티스로 클러스터링할 필요가 없었습니다. 그러나 불과 8개월만에 우리가 운영해야 하는 이더리움 밸리데이터의 수는 16,000개로 늘어났습니다. 우리는 빠르게 확장해야 했고, 이를 위해 많은 엔지니어들의 인적 리소스가 소모되었습니다. 유지보수의 경우에도 마찬가지입니다. 우리는 Dencun 업그레이드를 위해 서버 접근 권한을 가진 기술 관리자가 50대가 넘는 서버에 접속해 클라이언트를 업그레이드해야 했습니다. 쿠버네티스를 통해 각 서버의 컨테이너들을 오케스트레이션한다면 훨씬 더 안전하고 손쉽게 관리할 수 있습니다. 이에 더해 다음 글에서 설명할 Helm, ArgoCD등의 도구를 활용해 IaC(Infrastructure as Code)를 구성한다면 배포 및 유지보수를 더욱 편하게 할수 있을 뿐 아니라 인적 실수를 없애 더욱 안전한 관리가 가능해 집니다.

서버 접근 권한 문제

자체 데이터센터의 물리 서버에서 블록체인 노드를 운영하려면, 엔지니어들이 각 서버에 접근할 권한을 가져야 합니다. 보안 수준에 따라 접근할 수 있는 서버의 등급이 구분되어 있지만, 누군가는 물리 서버에 직접 접속할 수 있어야 설치 및 유지보수가 가능합니다. 이는 보안 측면에서 완벽하게 안전한 구조는 아니며, 서버 접근 권한을 가진 일부 인원들에게 유지보수에 대한 업무가 집중되는 문제도 있었습니다. 반면, 쿠버네티스를 이용한 클러스터 오케스트레이션의 경우, 극소수의 관리자를 제외하면 작업자는 어플리케이션의 배포 및 유지보수를 위해 서버에 직접 접속할 필요가 없습니다. 쿠버네티스의 컨트롤 플레인이 어플리케이션의 라이프사이클 관리를 대신해주며, 작업자는 배포할 어플리케이션에 대한 리소스 정의만 하면 됩니다. 또한, RBAC(Role Based Access Control)을 통해 리소스별 접근권한을 세부적으로 관리할 수 있기에 권한과 관련된 많은 문제들을 해결할 수 있습니다.

유연성이 필요한 아키텍처

앞서 이야기한 것처럼 이더리움은 프로토콜에서 위임 기능을 지원하지 않습니다. 때문에 사용자들에게 위임을 받고 이를 출금해주기 위한 다양한 중간자들이 존재합니다. 이들과의 통합을 위해서는 서로 다른 프로그램들을 우리의 이더리움 환경과 통합해야 합니다. 또한, 이더리움의 클라이언트는 그 역할에 따라 모듈화되어 있으며, 각 모듈별로 다양한 클라이언트들이 존재합니다. 이더리움 네트워크는 전 세계에 걸쳐 분산화된 노드들로 운영됩니다. 이 백만개에 달하는 밸리데이터 노드들의 대부분은 대형 오퍼레이터들에 의해 운영되고 있습니다. 그리고 각 노드는 다양한 조합의 이더리움 클라이언트 모듈들과 외부 연계를 위한 컴포넌트들로 이루어져 있죠. 마치 우주-은하계-태양계-지구의 구조와 같은 모습이죠!

대규모의 밸리데이터를 운영하는 오퍼레이터들은 이 다양한 조합의 노드 집단을 관리해야 합니다. 네트워크 상황과 리소스, 연계할 외부 컴포넌트에 따라 유연하게 대응할 수 있는 아키텍처를 구성하는 것이 매우 중요합니다. 예를 들어, Geth 클라이언트에 치명적인 문제가 발생할 경우, 빠르게 비컨 노드의 엔드포인트를 Geth가 아닌 Nethermind와 같은 다른 클라이언트로 교체해야 합니다. 이를 위해 쿠버네티스는 모듈화된 구조의 시스템을 유연하게 관리할 수 있는 환경을 제공합니다.

위와 같은 이유로 우리는 2024년 상반기에 걸쳐 우리 이더리움 검증인 노드들을 쿠버네티스 환경으로 이관할 것을 결정했습니다. 대부분의 서버를 이미 사용중인 환경에서 베어메탈 서버에 안전하고 안정적인 클러스터부터 구축하고, 모니터링 환경 및 DR 전략을 구축하고, 16,000Keys 에 달하는 기존 운영중인 검증인 노드들을 점진적으로 이관하는 것은 상당히 큰 작업이었습니다.

4.2. 고려사항

다음은 작업을 시작하기 전 우리가 쿠버네티스 환경으로 이관하기 위해 고려해야 했던 몇 가지 사항입니다.

베어메탈 클러스터 구축

우리는 기존 자체 데이터센터(IDC)의 머신들을 활용하여 쿠버네티스 클러스터를 구성해야 했습니다. 아시아, 특히 한국에서 AWS와 같은 클라우드 서비스에 종속되지 않는 오퍼레이터로서 A41의 강점을 유지하기 위함입니다. AWS의 EKS, GCP의 GKE와 같은 클라우드 서비스 프로바이더들이 제공하는 효율적인 클러스터 관리 도구들 없이도 유사한 수준의 클러스터를 구성해야 했습니다. 또한, 이더리움 검증인 노드를 운영하기 위한 최적의 환경으로 클러스터 도구를 준비하는 것도 도전 요소였습니다.

더블사이닝 방지

더블사이닝(Double Signing)은 블록체인 네트워크에서 치명적인 공격 행위이며, 네트워크 검증에 있어서 큰 위험 요소입니다. 쿠버네티스와 같이 배포의 많은 부분이 자동화된 환경에서는 잘못 설계된 아키텍처 혹은 인적 실수로 인해 더블사이닝이 발생할 위험이 큽니다. 따라서, 반드시 어떠한 상황에서도 더블사이닝을 방지할 수 있는 설계가 필요합니다.

코드화된 배포관리

배포 전 자동화된 테스트를 통해 인적 실수를 줄이고, 배포에 대한 이력 관리를 위해서는 리소스의 배포를 코드화하고 자동화할 필요가 있습니다. 이를 통해 배포 과정을 체계적이고 신뢰성 있게 관리할 수 있습니다.

퍼포먼스 유지

쿠버네티스로 전환하더라도 기존 환경과 동일하거나 더 향상된 퍼포먼스를 제공해야 합니다. 이더리움 밸리데이터는 매 블록마다 리워드와 패널티가 결정되기에 높은 퍼포먼스를 유지하는것이 중요합니다.

프로토콜별 격리

A41은 이더리움 밸리데이터 운영을 위해 다양한 경로로부터 위임을 받고 있습니다. A41이 직접 위임하는 자체적인 이더리움도 있지만, 대부분의 위임은 Lido, Mantle, Ether.fi 등 스테이킹 유동화 프로토콜(LSP)로부터 발생합니다. LSP마다 위임, Exit지원, 보상 관리 등을 위한 별도의 시스템과 연동하고 있습니다. 이들의 보안 수준은 모두 다르며, 이중에는 A41이 자체 개발한 도구들도 많습니다. 이러한 이유로 밸리데이터 노드들을 클러스터링 하더라도 각 프로토콜마다 운영 환경을 분리할 필요가 있습니다.

5. 이더리움 검증인 인프라를 위한 Kubernetes 클러스터 구성

5.1. kubespray (Ansible)

우리가 쿠버네티스 클러스터를 구성해야 했던 환경에 대해 다시 한 번 정리해 보겠습니다.

최소 60대에서 빠르게 확장 가능한 환경
A41이 운영중인 16,000 key 이상의 밸리데이터를 운영하기 위해서는 우리의 아키텍처를 기준으로 최소 40대 이상의 워커노드가 필요합니다. 이에 더해 LSP별 격리를 고려한다면 최소 60대 이상의 워커노드를 필요로 하며, 향후 증가하는 위임량에 따라 확장이 가능해야 합니다.
물리적으로 구분된 2곳의 데이터센터에 나눠져있는 머신들
우리의 데이터센터는 물리적으로 두 곳에 나누어져 있어, 분산된 환경에 존재하는 물리 서버들에 대한 클러스터 관리가 요구됩니다.
제한된 클라우드 서비스 도구 사용
우리는 모든 머신을 자체 데이터센터에서 운영합니다. 이는 AWS EKS, GCP GKE와 같은 클라우드 기반의 쿠버네티스 관리 도구를 사용하기 어렵게 만듭니다.
여러 클러스터를 동일한 구성으로 유지보수해야함
안정성과 테스트를 위해 프로덕션과 스테이징 클러스터를 동일한 구성으로 설치 및 유지보수해야 합니다.

이러한 환경에서 쿠버네티스 클러스터 초기 설치와 관리를 위해 몇 가지 옵션을 고려할 수 있었습니다.

kubeadm: 가볍고 유연한 설치

장점: 간단한 설치 프로세스, 기본적인 클러스터 구성 지원
단점: 클러스터의 확장성에 어려움이 있음, 수동 유지보수가 필요

2. Rancher: 편리한 인터페이스

장점: 사용자 친화적인 인터페이스, 다중 클러스터 관리 기능
단점: 추가적인 리소스와 구성 요소 필요, 커스터마이징의 유연성이 제한적

3. Kubespray: 베어메탈 환경에 최적

장점: 커스터마이징이 유연하고 확장 가능한 설정, 다양한 환경 지원, Ansible 기반 자동화, 추가 리소스가 필요없는 가벼운 구성
단점: 초기 설정 복잡성, 사용자 학습 곡선

4. EKS Distro: AWS EKS와의 연동성

장점: AWS EKS의 강력한 기능을 자체 데이터센터에서 사용 가능, EKS와의 연동성
단점: AWS와의 높은 종속성

우리는 여러 옵션들에 대한 검증을 진행했고, 결과적으로 Kubespray를 선택하게 되었습니다. 그 이유는 Kubespray가 유연성과 확장성 측면에서 다른 선택지보다 유리하며, 자동화와 관리 용이성에도 장점을 갖기 때문입니다.

Ansible을 활용한 쿠버네티스 클러스터 배포 (출처, https://initmanfs.eu/)

유연성과 확장성: Kubespray는 Ansible 스크립트를 기반으로 쿠버네티스 설치 및 관리를 지원합니다. 때문에 스크립트에 대한 수정이 유연하고 목적에 따라 유연한 커스터마이징이 가능하죠. 이러한 장점들로 물리적으로 분리된 데이터센터에서도 유연하게 클러스터를 구성할 수 있으며, 이더리움 위임량의 증가에 따라 노드를 편리하게 증설할 수 있습니다.
자동화와 관리 용이성: Ansible을 기반으로 하여 설정 및 배포 작업을 자동화할 수 있으며, 클러스터를 쉽게 관리할 수 있습니다.

다른 옵션들을 선택하지 않은 이유는 다음과 같습니다.

kubeadm: 기본적인 설치와 구성을 지원하지만, 확장성과 복잡한 설정에 한계가 있어 대규모 노드 운영에 적합하지 않았습니다.
Rancher: 사용자 친화적인 인터페이스와 다중 클러스터 관리 기능은 매력적이었으나, Rancher를 위한 추가적인 리소스와 구성 요소가 필요하고, 커스터마이징 유연성이 제한적이었습니다. 또한 Rancher 서버의 다운이 클러스터 관리의 단일 실패지점이 될 수 있다는 것도 고려되었습니다.
EKS Distro: EKS와의 통합을 고려하고 있지 않기 때문에 우리의 요구사항과는 맞지 않았습니다.

이러한 이유로 우리는 Kubespray를 사용해 이더리움 검증인 인프라를 위한 Kubernetes 클러스터를 구성하게 되었습니다.

Kubespray 배포를 위한 환경 구성은 다음과 같습니다.

Ansible host: kubespray의 배포 스크립트로 구성된 Ansible을 구동하는 Host입니다. 클러스터별 격리를 위해 클러스터별로 별개의 Ansible host를 가집니다.
Bastion host: 데이터센터에 위치한 물리 서버의 ssh 방화벽 오픈을 최소화 하기 위해 모든 서버의 22번 포트는 AWS IAM으로 접근 권한을 관리하는 Bastion host로만 오픈되어 있습니다. Ansible host는 작업시 권한을 부여받아 이 Bastion host를 거쳐서 배포 작업을 수행하게 됩니다.

5.2. 클러스터 기본 구성

이더리움 검증인 노드 운영을 위한 우리의 기본 클러스터 구성은 다음과 같습니다:

3개의 마스터 노드
고가용성과 안정성을 보장합니다. etcd와 컨트롤 플레인이 배포되어 있습니다. 더 높은 가용성과 독립적인 확장성을 위해 etcd를 클러스터 외부에 두는 방법도 고려되었으나, 우리의 환경은 이더리움 검증인 노드 운영을 위한 클러스터로 제한되어 있기에 컨트롤 플레인 노드의 변경하거나 확장에 대한 수요가 적습니다. 때문에 아키텍처를 단순화하고 운영 비용을 최적화 하기 위해 동일한 노드에 두는 것이 더 적합하다 판단했습니다. 가용성의 경우 뒤에 설명할 DR전략으로 이를 충분히 보완할 수 있다 판단하였습니다.
2개의 시스템 노드
클러스터를 구성하는 시스템 컴포넌트들을 배포하기 위한 노드입니다. 어플리케이션 컨테이너들은 시스템 노드에 배포되지 않으며, 모니터링, argoCD, 각종 Operator 등 다양한 시스템 컴포넌트들이 배포됩니다. 어플리케이션이 배포될 노드와 분리되어 있기에 시스템 컴포넌트들은 어플리케이션의 동작에 영향을 받지 않으며, 리소스 측면에서도 간섭받지 않습니다. Failover를 위해 2개로 구성한 System node는 부하 증가에 따라 추가 증설할 수 있습니다.
워커 노드
각 워커 노드에는 1개 이상의 이더리움 Validator client가 배포됩니다. 일부 노드에는 비컨 클라이언트와 실행 클라이언트 및 MEV Boost가 배포되게 되죠. 이더리움 클라이언트에 대한 배포 전략은 다음 글인 “2.이더리움 밸리데이터 유연하고 안전하게 배포하기”에서 자세히 설명합니다.

5.3. Add-on

쿠버네티스는 수년에 걸쳐 전 세계에서 가장 사랑받는 컨테이너 오케스트레이션 도구입니다. 역사상 가장 성공적인 오픈소스 프로젝트로도 평가받죠. 때문에 쿠버네티스에서 제공하는 클러스터를 관리하기 위한 기본 컴포넌트들 이외에도 수많은 애드온들이 존재합니다. 우리는 이들 중에서 A41의 환경에서 이더리움 검증인 노드를 운영하기 위한 최소한의 애드온들을 설치해 활용하고 있습니다.

Local-path-provisioner

이더리움의 실행 클라이언트와 비컨 클라이언트는 각각 약 1.5TB와 500GB의 저장공간을 필요로 합니다. 컨테이너 환경에서 데이터의 영속성을 보장하기 위해서는 반드시 외부 저장공간 혹은 호스트 서버의 저장공간을 Volume을 통해 연결해 주어야 합니다. 쿠버네티스 환경에서는 PV(Persistent Volume) 리소스를 통해 미리 컨테이너가 사용할 저장공간을 준비해두고, 이를 PVC(Persistent Volume Claim) 리소스를 통해 사용합니다.
PV를 매번 별도로 관리하고 필요할 때마다 PVC를 따로 생성하는 것은 상황에 따라 유용할 수 있지만, 일반적으로는 불편합니다. Storage Class는 PV의 동적 프로비저닝(dynamic provisioning)을 가능하게 하는 리소스로, 사용자가 PVC를 생성할 때 자동으로 원하는 대상으로 PV를 생성하고 바인딩할 수 있도록 합니다. Storage Class는 저장소의 종류, 성능, 접근 모드 등을 정의하고 있으며, 다양한 저장소(AWS EBS, GCE Persistent Disks, NFS 등)를 대상으로 할 수 있습니다.
우리 데이터센터의 각 서버들은 3~5TB의 스토리지를 가지고 있습니다. 이런 상황에서 각 노드가 가지고 있는 호스트 스토리지를 사용할 수 있다면, 추가적인 스토리지에 대한 비용을 절감할 수 있고, 로컬 디스크를 사용해 높은 Disk IO 퍼포먼스를 확보할 수 있습니다. Local-path-provisioner 애드온을 클러스터에 설치하면 노드의 로컬 스토리지를 PVC로 동적 프로비저닝할 수 있는 Storage Class를 사용할수 있게 됩니다.

local-path Storage Class를 사용해 PV를 생성하면 실제 워커 노드의 지정된 디렉토리에 볼륨 데이터가 저장되는 것을 확인할 수 있습니다.

aws-iam-authenticator

AWS IAM Authenticator는 쿠버네티스 클러스터에서 AWS의 IAM을 활용하여 인증을 구현할 수 있게 해주는 도구입니다. 이를 통해 쿠버네티스 클러스터와 IAM을 통합하여, 기존 IAM 사용자 및 정책을 그대로 사용할 수 있습니다. 쿠버네티스 클러스터 관리를 위해 AWS 계정과 IAM 정책을 활용할 수 있게 되는 것이죠. 별도의 계정 관리가 필요하지 않으며, 기존 A41 인프라 환경에서 사용 중인 보안 정책을 일관되게 적용할 수 있는 장점도 있습니다. 쿠버네티스는 기본적으로 RBAC(Role-Based Access Control)를 지원합니다. AWS IAM Authenticator를 사용하면 AWS의 IAM과 쿠버네티스의 RBAC을 결합해 강력하고 유연한 보안 정책을 활용할 수 있습니다.

MetalLB

이더리움 노드들은 P2P(Peer-to-Peer) 통신을 통해 트랜잭션 데이터와 블록, Attestation 정보를 주고받습니다. 좋은 피어를 충분히 확보하는 것은 검증인 성능에 매우 중요한 역할을 합니다. 대부분의 이더리움 클라이언트는 피어셋을 좋은 노드들로 구성하기 위해 피어를 찾고 연결한 뒤, 별도의 스코어링을 통해 성능이 좋지 않은 피어들을 걸러내는 로직을 가지고 있습니다. 클라이언트는 직접 피어를 찾기도 하지만(outbound peer), 좋은 노드들이 나를 찾게 하는 것(inbound peer)도 중요합니다. 클라이언트별로 정책이 다르지만, 일반적으로 inbound와 outbound 피어의 수를 적절히 조절해 관리하는 로직도 포함하고 있습니다. inbound 접근이 불가능한 환경에서는 동일한 설정일지라도 피어수의 차이를 보입니다.

Inbound 접근이 가능한 환경과 불가능한 환경에서의 피어 수 차이 (좌: inbound 오픈, 우: inbound 방화벽)

때문에 높은 성능의 검증인 노드를 위해 반드시 필요한 것은 자신이 누구인지 네트워크에 알려 피어 탐색(peer discovery) 대상이 될 수 있게 하고, 좋은 성능의 피어로서 알려지는 것입니다. 그래야 더 좋은 피어셋을 구축해 높은 퍼포먼스를 낼 수 있습니다. 기본적으로 이더리움 클라이언트는 처음 실행될 때 호스트의 IP를 네트워크에 전파합니다. 하지만 쿠버네티스 컨테이너 환경에서 컨테이너의 IP는 외부에서 접근할 수 있는 주소가 아니기 때문에 inbound peering을 할 수 없습니다. 따라서 외부에서 접근할 수 있는 고정된 주소를 우리의 클라이언트에 할당할 필요가 있었습니다. 우리는 데이터센터에서 확보하고 있는 여분의 IP 대역이 충분했으며, 이를 쿠버네티스 클러스터 환경에서 Type LoadBalancer를 통해 사용하고자 했습니다.
MetalLB는 쿠버네티스 클러스터에 로드밸런싱 기능을 추가해주는 오픈 소스 프로젝트입니다. 이는 클러스터 외부에서 접근할 수 있는 고정된 IP 주소를 할당하고 관리할 수 있게 해줍니다. MetalLB를 사용하면, 쿠버네티스 클러스터 내의 서비스에 외부에서 접근할 수 있는 IP 주소를 쉽게 할당할 수 있습니다. MetalLB를 통해 서비스에 할당한 IP를 클라이언트 실행 옵션으로 지정하면 해당 IP를 피어 탐색을 위한 주소로 네트워크에 전파하게 됩니다. 예시) Teku : --p2p-advertised-ip / Lighthouse : --enr-address

Cert Manager

앞서 설명한 것처럼 다양한 외부 모듈들과 이더리움 노드들과의 연계가 필요하며, 이 과정에서 미들웨어가 Validator client를 호출해야 하는 경우도 있습니다. 또한, 클러스터에서 운영되는 각 컴포넌트 간의 보다 안전한 통신을 위해서는 TLS 사용이 필요하죠. 때문에 이더리움 밸리데이터 네트워크를 구성하는 과정에서 인증서 관리는 필수입니다. 이때 Cert Manager를 활용하면 이러한 인증서 관리를 자동화하고 효율적으로 처리할 수 있습니다.
Cert Manager는 쿠버네티스 클러스터에서 인증서를 자동으로 발급하고 갱신해주는 오픈 소스 도구입니다. 이를 통해 클러스터 내 모든 서비스 간의 TLS 통신을 쉽게 구현할 수 있습니다. 또한 쿠버네티스 환경에서 인증서 관리의 복잡성을 줄여주고, 인증서를 자동으로 갱신하여 보안성을 높여줄 뿐 아니라 인증서 만료로 인한 위험도 없앨수 있습니다. 즉, 클러스터에서 Https 통신이 필요하고 인증서 관리를 효과적으로 하기 위해서는 Cert Manager 애드온의 설치가 필요했습니다.

Prometheus

Prometheus 시스템 모니터링과 Alert을 위한 오픈 소스 솔루션입니다. 클러스터 환경에서 메트릭 데이터를 수집, 저장, 분석하여 실시간으로 모니터링하고 Alert을 발송할 수 있게 해줍니다. 클러스터의 모니터링뿐 아니라 이더리움 클라이언트들을 포함한 어플리케이션들에 대해서도 모니터링을 수집할수 있어 편리하게 모니터링 시스템을 구축할수 있습니다. 상세한 내용은 “3.효율적인 모니터링과 신속한 장애 대응이 곧 퍼포먼스다” 에서 확인할수 있습니다.

Helm/ArgoCD

리소스를 안전하고 유연하게 배포하기 위해 설치합니다. 배포 과정에 대한 자세한 설명은 “2.이더리움 벨리데이터 유연하고 안전하게 배포하기”에서 자세히 설명합니다.

5.4. 클러스터 작업 검증을 위한 스테이징 클러스터

쿠버네티스 환경에서 컨트롤 플레인 영역의 변경, MetalLB와 같은 시스템 컴포넌트의 수정, 권한 레벨의 변경 등은 클러스터에서 운영 중인 애플리케이션들에 치명적인 영향을 줄 수 있습니다. 또한, 보안 취약점 등의 원인으로 쿠버네티스 버전을 업그레이드해야 하는 경우도 발생할 수 있습니다. 이러한 이유로, 클러스터 레벨에서의 변경정을 사전에 테스트하기 위해 스테이징 클러스터를 구축하는 것이 필요했습니다.

우리는 프로덕션 클러스터와 동일한 환경으로 스테이징 클러스터를 구성하여 클러스터 차원의 변경점과 시스템 컴포넌트 배포 전, 모든 변경 사항과 업그레이드를 테스트하고 있습니다. 이를 통해 클러스터 레벨의 변경점을 사전에 검증하고, 문제를 발견하여 해결할 수 있습니다. 스테이징 클러스터는 안전하고 신뢰할 수 있는 운영 환경을 유지하는 데 중요한 역할을 합니다.

6. DR(Disaster Recovery)

A41의 서버들은 물리적으로 구분된 두 개의 데이터센터에 분산되어 있습니다. 이는 데이터센터의 장애 상황에도 대응할 수 있는 서버들이 존재한다는 뜻입니다. 즉, 각 데이터센터가 서로의 DR(Disaster Recovery) 환경이 되어줄 수 있는 것입니다. 이는 쿠버네티스로 전환하기 전 기존 구조의 매우 큰 장점이었습니다. 쿠버네티스로 전환 후 한 가지 문제점은 클러스터의 장애 상황이 단일 실패지점이 될 수 있다는 것입니다. 우리는 이를 해결하기 위해 기존 구조에서의 장점을 활용하는 방식을 선택했습니다. (각 컴포넌트의 배포 전략에 관한 자세한 내용은 “2.이더리움 벨리데이터 유연하고 안전하게 배포하기”를 참고해 주세요.)

베어메탈 서버에 Execution client와 Beacon client 구동

Disaster 상황에서 가장 문제가 되는 것은 많은 저장공간을 사용하는 영속적인 데이터(Persistent Volume)가 필요한 Execution client와 Beacon client입니다. 클러스터 환경에서도 Local-path-provisioner를 활용한 PV를 사용하지만, 베어메탈 환경은 클러스터 장애 상황과 분리되어 있어 백업 노드로 활용할 수 있습니다. 이 노드들은 두 개의 데이터센터에 분산되어 있어 더욱 안전합니다. 우리는 이 베어메탈 환경에서 구동하는 Beacon 노드를 평시에는 클러스터에서 동작하는 Validator client의 fallback 엔드포인트로 활용합니다.

Validator client와 Signer는 클러스터에서만 구동

Validator client와 Signer는 영속적인 데이터 스토리지를 필요로 하지 않습니다. 다음 글에서 자세히 설명하겠지만, 우리의 배포 스크립트는 모두 Helm 스크립트로 코드화되어 있어 Validator client와 Signer는 클러스터 환경에 빠르게 재배포가 가능합니다.

운영 클러스터 장애 상황 시 스테이징 클러스터를 DR 환경으로 활용

우리는 운영 클러스터와 동일하게 구성된 스테이징 클러스터를 갖추고 있습니다. 운영 클러스터 전체에 문제가 발생한 Disaster 상황에서 코드화된 배포를 통해 Validator client를 스테이징 클러스터에 빠르게 배포하고, Beacon 엔드포인트는 기존에 fallback으로 활용하던 베어메탈 환경의 클라이언트를 사용합니다.

이와 같은 DR 전략을 통해 우리는 쿠버네티스 클러스터의 유연성과 베어메탈 서버의 안정성을 결합하여 Disaster 상황에 견고한 환경을 구축할 수 있었습니다.

7. 마치며

1~2개의 밸리데이터를 운영하는 솔로 밸리데이터로서 이더리움 노드를 셋업하고 운영하는 것은 비교적 쉽습니다. 이를 편하게 도와주는 솔루션들도 다양하죠. 단일 노드가 성능에 따라 검증인 1,000개 이상을 감당할 수 있기 때문에, 여기까지도 큰 문제가 되지 않습니다. (1,000개의 검증인을 운영하려면 32,000 ETH, 2024년 7월 현재 시세로 약 1억 달러를 스테이킹해야 합니다.) 즉, 그 이상의 스테이킹 자산을 운영하는 대규모의 기업형 오퍼레이터, 특히 꾸준히 확장하는 오퍼레이터들만이 이더리움 검증인 인프라의 확장성을 포함한 다양한 문제들에 직면할 수 있습니다. A41은 현재 16,000개 이상의 밸리데이터를 운영하고 있습니다. 우리는 확장하는 동안 마주한 문제들을 해결하기 위해 쿠버네티스로의 전환을 결정했고, 그 과정에서의 고민과 선택들에 대해 이 글을 통해 소개했습니다.

쿠버네티스로의 전환을 통해 우리는 자원 활용, 확장성과 유지보수, 권한 관리, 유연성과 같은 문제들을 해결할 수 있었습니다. 하지만 대규모의 이더리움 검증인 노드를 운영하는 데 있어서 만날 수 있는 문제들은 단순히 쿠버네티스로 인프라를 전환한다고 해서 모두 해결되는 것은 아닙니다. 자동화된 배포 과정에서 발생할 수 있는 더블사이닝의 위험을 제로로 만들면서도 유지보수가 편리한 배포 환경을 구축해야 하며, 규모가 커진 환경에 맞는 다변화된 이더리움 노드의 모니터링 시스템을 구축해야 합니다. 또한, 우리 노드들로부터 발생하는 보상과 패널티를 정확하게 측정할 수 있는 도구들도 필요합니다.

우리 팀이 경험한 문제들과 이를 해결하기 위한 선택의 결과들에 대해 이 글을 포함해 총 5편의 포스트로 준비했습니다. 물론, 이 선택들은 A41의 특수한 환경들(예를 들어 IDC에서 운영해야 하는 것과 같은)에 깊게 연관되어 있기에 모든 오퍼레이터들에게 정답이 되지는 못할 것입니다. 그럼에도 우리의 포스팅들이 이더리움 검증인을 준비하는 많은 분들께 참고가 되었으면 합니다.