앱 안정성 확보하기: web3 성공의 핵심

많은 팀의 web3 앱은 실패할 운명에 있습니다.

왜일까요?

앱이 노드에 전적으로 의존하고 있고, 노드는 유지하기가 매우 어렵기 때문입니다. 몇 가지 이유는 다음과 같습니다:

1. 노드 신뢰성은 진공 상태에서 만들어질 수 없습니다. 신뢰성은 노드 확장성 및 데이터 정확성과 함께 확보되어야 합니다
2. 노드는 풀스케일 프로덕션 솔루션으로 설계되지 않았습니다
3. 노드는 너무 많은 일을 하도록 요구받습니다
4. 노드는 상시 유지보수가 필요합니다
5. 노드의 효율성은 예측 불가능한 시점에 일어나는 네트워크 업그레이드나 하드포크를 성공적으로 넘기는 데 달려 있습니다

이러한 복잡성 때문에 노드를 관리하고 유지하기가 어렵습니다.

하지만 노드 신뢰성, 즉 사용자가 필요할 때 여러분의 앱과 성공적으로 상호작용할 수 있는 능력을 크게 향상시키는 두 가지 아키텍처 차원이 있습니다:

• 이질성(Heterogeneity): 서로 다른 요청을 처리할 수 있는 다양하고 상호보완적인 시스템
• 중복성(Redundancy): 백업 시스템. 한 시스템이 다운되어도 다른 시스템은 계속 작동

web3에서 신뢰성 부족은 치명적인 결과를 초래할 수 있습니다.

신뢰할 수 없는 인프라를 사용한 잘 알려진 NFT 마켓플레이스를 예로 들어보겠습니다...

해당 플랫폼은 불안정했고, 다음과 같은 결과를 낳았습니다:

• 과도한 엔지니어링 부담
• 저하된 UX
• 단 한 분기 동안 190시간 이상의 다운타임

그 영향은 무엇이었을까요?** 600만 달러의 매출 손실이었습니다.**

여러분에게는 이런 일이 일어나지 않도록 하세요.

이 글에서는 다음을 다룹니다:

1. 노드 신뢰성 유지가 왜 어려운지
2. 흔히 쓰이는 노드 인프라 패턴과 그것들이 실패하는 이유
3. Alchemy가 신뢰성 문제를 어떻게 해결하고 대규모로 신뢰성을 구축하는지

노드 신뢰성 유지가 어려운 이유

web3에서 신뢰성을 유지하기 특히 어려운 데는 다섯 가지 주된 이유가 있습니다:

(1) 노드 신뢰성은 진공 상태에서 만들어질 수 없습니다. 신뢰성은 노드 확장성 및 데이터 정확성과 함께 확보되어야 합니다

고성능 앱을 만들려면 신뢰성에 확장성과 데이터 정확성이 함께 결합되어야 합니다.

• 확장성: 앱의 트래픽이 10배, 100배, 1000배 혹은 그 이상으로 확장되는 동안에도 블록체인과 계속 상호작용할 수 있는 능력.
• 데이터 정확성: 모든 사용자에게 앱이 정확하고 일관된 데이터를 반환하는 상태.

(2) 노드는 풀스케일 프로덕션 솔루션으로 설계되지 않았습니다‍

노드는 애초에 개인이 개인적, 소규모 용도로 운영하도록 설계되었습니다. 비용이 많이 들긴 하지만($1000/월), 그 제한된 용도에서는 충분한 신뢰성을 만들어내고 다음을 유지할 수 있습니다:

• 확장성; 요청량이 예측 가능한 범위에서 통제되기 때문에 필요한 확장성에 관련된 위험이 제한됩니다
• 데이터 정확성; 노드가 하나뿐이기 때문에 노드 간 데이터 불일치가 발생할 여지가 없습니다

하지만 개발 환경은 프로덕션 환경이 아니며, 프로덕션에는 매우 다른 툴링이 필요합니다.

(3)** **노드는 너무 많은 일을 하도록 요구받습니다

노드는 P2P 소프트웨어 실행, 확장 가능한 데이터베이스 역할, 임의 코드 실행 등 무한정 많은 일을 하도록 요구받습니다.

노드는 또한 무엇을 해야 하고 무엇을 하지 말아야 하는지에 대한 “의견”이 없습니다.

이는 합쳐져서 두 가지 주요한 결과를 낳습니다:

• 확장성; 요청량이 늘어남에 따라 확장하려면 새 노드를 계속 띄워야 하고, 각 새 노드는 그 긴 기능 목록을 모두 포함하도록 구축되어야 하므로 비효율과 비용이 발생합니다 (다시 말하지만, 저렴한 쪽으로도 노드 운영에는 $1,000/월이 듭니다).
• 엣지 케이스; 노드에 기본적인 보호 장치가 없기 때문에 쿼리 하나만으로 노드 전체가 다운될 수 있습니다.

(4) 노드는 상시 유지보수가 필요합니다

평균적으로 5일마다 노드에서 다음과 같은 문제가 발생할 수 있습니다:

• 메모리 누수
• 데이터 저장소 문제
• CPU 과부하
• 불안정한 피어링
• 손상된 내부 데이터베이스
• 트랜잭션 브로드캐스트 문제
• 버그 및 리그레션
• “안정적 릴리스”의 6개 중 1개는 문제가 있음

각 문제는 진단, 문제 해결, 수정에 상당한 시간이 소요되며, 이는 프론트엔드 사용자 경험에 집중할 시간이 그만큼 줄어든다는 것을 의미합니다.

(5) 노드의 효율성은 예측 불가능한 시점에 일어나는 네트워크 업그레이드나 하드포크를 성공적으로 넘기는 데 달려 있습니다

네트워크 업그레이드와 하드포크는 여러분의 일정이 아니라 프로토콜의 일정에 따라 일어납니다. 각각은 상당한 준비를 필요로 하며, 이를 잘못 처리하면 노드가 다운되어 치명적인 영향을 미칠 수 있습니다.

흔히 쓰이는 인프라 아키텍처 패턴과 그것들이 실패하는 이유

신뢰할 수 있는 노드 인프라를 운영하는 것은 본질적으로 어려우며, 흔히 쓰이는 많은 web3 아키텍처는 신뢰성을 만들어내는 데 효과적이지 못합니다:

단일 노드 운영

설정은 더 간단하지만 단일 장애점(single point of failure)에 취약하며, 이질성과 중복성이 모두 결여되어 있습니다. 단일 노드의 가동시간은 낮게는 72%까지 측정되며, 단일 노드를 확장하는 것은 매우 비효율적입니다.

백업이 있는 노드 운영

이 방식은 단일 노드보다 약간 더 많은 중복성을 만들어내지만, 여전히 이질성(시스템의 다양성)은 없으며, 첫 번째 노드를 다운시키는 요청이 두 번째 노드도 다운시키는 경우가 많습니다. 확장성 문제는 여전히 존재하고, 데이터 정확성 문제까지 새로 생깁니다. 즉, 대부분의 시스템이 각 노드가 동일한 블록 헤드(혹은 심지어 동일한 체인)에 있다는 것을 보장할 수 없기 때문에 노드들이 서로 다른 응답을 반환하게 됩니다.

‍노드 여러 대에 걸친 로드밸런싱

이 모델은 더 많은 중복성을 만들어내지만, 여전히 이질성은 없습니다. 데이터 정확성과 확장성 문제는 여전히 남아 있습니다(연속된 재시도로 노드 전체 플릿이 다운될 수 있습니다).

노드는 자주 다운되고, 고치기가 정말**, 정말 번거롭습니다.**

아직 명확하지 않았다면 말씀드리자면, 블록체인 연결을 위한 많은 “솔루션”은 이질성이나 중복성을 충분히 제공하지 못하며, 그 때문에 결국 실패합니다. 실패의 결과는 심각합니다.

노드는 다시 정상 가동되기까지 며칠, 혹은 몇 주의 복구 시간이 필요할 수 있습니다. 이런 문제들은 비용이 많이 들고, 해결하기 어려우며, 팀 전체가 매달려야 하는 작업을 요구합니다.

2019년, BlockCypher는 Ethereum의 Constantinople 하드포크를 넘기려 했습니다. 이들은 데이터 누락 오류에 부딪혔고, 근본 원인을 진단하지 못했습니다. 그 결과 한 달 이상의 다운타임을 겪었고, 결국 사실상 처음부터 다시 시작해야 했습니다.

여러분에게는 이런 일이 일어나지 않도록 하세요 ;)

web3 인프라가 더 이질적이고 중복될수록, 그만큼 더 신뢰할 수 있게 됩니다.

Alchemy가 대규모로 신뢰성을 구축하는 방법

Alchemy의 Cortex 엔진은 맞춤형의 확장 가능하고 분산된 시스템들을 결합하여 신뢰성과 확장성을 가능하게 하는 동시에, 저희 API가 단일 노드처럼 동작하게 함으로써 데이터 정확성을 보장합니다.

Cortex는 확장 가능하고 다양한 시스템으로 중복성과 이질성을 모두 달성합니다

노드에 대한 데이터 요청을 최소화하는 중복적이고 이질적인 시스템

Web2 인프라는 서버에서 데이터 저장을 분리하고 외부 스토리지 센터를 만듦으로써 신뢰성과 확장성을 확보합니다.

하지만 노드 아키텍처의 고유한 특성상, 노드에서 데이터 저장을 분리하는 것은 사실상 불가능합니다.

신뢰성과 확장성을 만들어내기 위해, Alchemy의 Cortex 엔진은 노드의 데이터를 복제하는 세컨더리 인프라(secondary infrastructure)라 불리는 고급 아키텍처를 사용합니다.

Cortex의 조정 레이어인 Vox Nodi는 세컨더리 인프라가 최신 데이터를 가지고 있는지 지속적으로 시스템 점검을 실행하여, 블록 번호, 트랜잭션 로그, 트랜잭션 영수증 등 어떤 데이터 요청이든 정확하도록 보장합니다.

요청을 우선 세컨더리 인프라로 라우팅함으로써, 노드는 보호되고 노드의 “작업 부하”는 줄어듭니다.

대부분의 요청은 세컨더리 인프라에서 처리될 수 있으며, 엣지 케이스만 노드로 라우팅됩니다.

예를 들어보겠습니다:

사용자들이 다양한 데이터 유형과 블록에 대한 정보를 요청합니다:

• 사용자 1은 블록 82까지의 트랜잭션 데이터를 요청합니다
• 사용자 2는 블록 85의 로그 데이터를 요청합니다
• 사용자 3은 블록 92의 블록 데이터를 요청합니다

사용자 1의 요청은 세컨더리 인프라 시스템에서 처리될 수 있습니다. (중요한 점은, 이런 요청이 노드에 직접 전달된다면 노드가 다운되겠지만, 세컨더리 인프라 시스템은 이 부하를 원활하게 처리할 수 있다는 것입니다).

사용자 2의 요청 역시 세컨더리 인프라에서 처리될 수 있습니다.

사용자 3의 요청은 세컨더리 인프라를 통해 처리될 수 없습니다. 시스템이 아직 블록 92의 최신 블록 데이터를 가지고 있지 않기 때문입니다. 사용자 3의 요청은 이제 노드에서 처리됩니다.

이 예시에서, 사용자 1, 2, 3의 경험은 완전히 동일합니다. 요청이 세컨더리 인프라를 통해 응답되든 노드에서 직접 응답되든 다운타임에 차이는 없습니다. 하지만 요청을 먼저 세컨더리 인프라 시스템으로 라우팅함으로써, 노드는 보호되고 노드의 “작업 부하”는 줄어듭니다.

코드 실행을 위한 중복적이고 이질적인 시스템

Ethereum Virtual Machine(EVM)이 튜링 완전하기 때문에, 노드에 코드 실행을 요청할 수 있습니다. 노드는 스스로를 제어할 수 없기 때문에, 임의의 요청이 노드 플릿 전체를 다운시킬 잠재적 위험이 항상 존재합니다.

이를 방지하기 위해, Alchemy는 저희 시스템이 이전에 응답했던 모든 요청을 중복 제거하여 저장합니다.

이는 고유하게 새로운 요청만 노드에서 실행되고, 그 외 대부분의 요청은 이 저장 시스템들이 처리할 수 있다는 것을 의미합니다.

서로 다른 요청에 특화된 이질적인 노드

세컨더리 인프라 시스템 외에도, Alchemy는 서로 다른 노드 유형을 추가하여 이질성을 확보합니다. 세컨더리 인프라가 요청에 응답할 수 없는 예외적인 상황에서, 시스템은 가장 확장성이 뛰어난 노드로 기본 설정됩니다.

Alchemy는 여러 유형의 노드를 운영합니다, 다음을 포함합니다:

• Light: 네트워크에서 트랜잭션을 수행하는 데 필요한 최소한의 데이터인 블록 헤더만 다운로드합니다. Light 노드는 네트워크와 효율적으로 상호작용할 수 있고 대역폭 수 메가바이트와 저장공간 수 기가바이트를 절약할 수 있지만, 전체 데이터에 접근할 수 없다는 한계가 있습니다.
• Full: 네트워크상의 블록들이 올바른지 검증하는 데 필요한 모든 것을 갖추고 있으며, 어떤 스마트 컨트랙트와도 상호작용하고 자체적으로 컨트랙트를 배포할 수 있습니다. Full 노드는 상당한 컴퓨팅 및 대역폭 자원을 필요로 합니다.
• Archive: Full 노드보다 한 단계 더 나아갑니다. Full 노드는 더 이상 검증에 필요하지 않은 항목들을 정리하지만, Archive 노드는 모든 것을 (테라바이트 단위의 추가 데이터를) 유지합니다. 이런 세부 정보는 정보를 더 효율적으로 조회하는 데 유용하고 일부 애플리케이션에 편리하지만, 대부분의 경우에는 과도합니다.
• Debug: Debug 노드는 Archive 노드보다 한 걸음 더 나아가, 어떤 노드 유형보다도 가장 많은 정보를 저장하므로 스마트 컨트랙트의 실행 과정을 극도로 상세하게 단계별로 추적할 수 있습니다.

노드 유형별로 서로 다른 특성 덕분에 각각이 잘하는 영역이 다르므로, 한 노드가 요청에 응답할 수 없더라도 다른 노드들은 여전히 정상 작동하며 응답에 적합할 가능성이 큽니다.

예를 들어, 세컨더리 인프라에 아직 기록되지 않았을 수 있는 최신 데이터에 대한 요청이 있는 경우, 그 요청은 fast 노드로 라우팅되어 archive 노드는 “보호”됩니다. archive 노드의 데이터를 뒤지는 것이 훨씬 더 비용이 많이 들기 때문입니다.

필요에 따라 새 노드를 더 쉽게 띄울 수 있도록, Cortex 엔진은 노드의 “스냅샷”을 찍어둡니다. 그래서 새 노드를 만들 때 시스템이 가장 최근의 “체크포인트”부터 시작할 수 있어 동기화 과정이 크게 단축됩니다.

버그의 영향을 완화하는 이질적인 클라이언트

마지막으로, Alchemy는 geth, Erigon, Parity를 포함해 Ethereum 클라이언트의 서로 다른 구현체들을 운영합니다. 이는 필요한 백엔드 유지보수 작업을 사실상 세 배로 늘리지만, 이질성을 확보하는 데 있어서는 매우 큰 가치가 있습니다. 이 클라이언트들이 동일한 버그를 가질 확률은 사실상 0이기 때문입니다.

중복성과 이질성을 통한 신뢰성 구축

Alchemy에서는 Cortex를 엔지니어링하는 데 수십만 시간을 투입했습니다. Cortex는 이질적이고 중복되도록 처음부터 새롭게 구축된 복잡한 시스템 집합으로, 장애 허용력을 크게 높이고 어떤 블록체인 요청에도 신뢰성 있게 응답할 수 있도록 보장합니다.

이러한 신뢰성을 가능하게 하는 복잡하고 상호의존적인 시스템을 구축하는 데는 수년이 걸렸습니다. 신뢰성을 확보하기 위해 구축하는 일은 매우 어렵지만, 신뢰할 수 있는 인프라를 활용하는 것은 여러분 앱의 성공에 필수적입니다.

인프라 옵션을 살펴볼 때, 제공업체에 가장 먼저 물어야 할 질문 중 하나는 다음과 같습니다: “귀사의 인프라는 얼마나 이질적이고 중복적입니까? 그리고 귀사 시스템의 신뢰성을 입증할 증거를 보여줄 수 있습니까?”

공개된 RPC 제공업체 벤치마크는 제공업체의 아키텍처 주장과 함께 지연 시간, 성공률, 실패한 요청을 평가하는 데 도움이 될 수 있습니다.

여러분 앱의 성공은 이 선택에 달려 있습니다. 저희가 어떻게 도움을 드릴 수 있을지 알려주세요!