Ethereum 생태계는 인프라의 기본 단위인 노드에 대해 주로 두 곳의 제공자에 의존하고 있습니다. 이 중 하나인 Parity Technologies가 다른 이니셔티브에 집중하기 위해 Ethereum 노드 소프트웨어 개발을 중단한다고 발표했습니다. 저희 Alchemy는 최근 Parity에서 또 다른 주요 옵션인 Geth로 전환하기로 결정했으며, 전담 팀에 의해 활발히 개발되고 있는 만큼 여러분도 같은 선택을 하실 것을 권합니다. 핵심 인프라를 마이그레이션하는 것은 매우 중요하고 세심한 주의가 필요한 작업입니다. 전 세계 유수 기업들에게 인프라를 제공해온 Alchemy의 오랜 경험을 바탕으로, Parity에서 Geth로 마이그레이션하는 이 가이드를 작성하여 모범 사례를 공유하고 성공적인 전환을 돕고자 합니다. 이 가이드를 엔지니어링 팀과 공유하시면 블록체인 노드의 세부 사항을 파악하고 핵심 인프라가 원활히 작동하도록 하는 데 도움이 될 것입니다.

‍

배경

기본 사항을 간단히 정리하겠습니다. 블록체인 애플리케이션은 블록체인을 읽고 쓸 수 있게 해주는 "노드"라는 서버를 운영해야 합니다. 이를 블록체인을 저장하는 데이터베이스라고 생각하시면 됩니다.

현재 노드 소프트웨어의 주요 옵션은 Parity와 Geth 두 가지입니다. 이 오픈소스 노드 클라이언트 소프트웨어를 구축하고 유지보수하는 두 팀 모두 전체 블록체인 생태계에 막대한 기여를 해왔으며, 이들이 없었다면 Ethereum은 존재하지 못했을 것입니다. Alchemy 팀은 두 팀 모두에게 깊은 감사를 전합니다.

Ethereum 블록체인 개발의 성장을 처음부터 크게 지원해온 Parity 팀은 최근 자체 체인에 집중하기 위해 이동하고 있습니다.

Peter와 Geth 팀 전체는 훌륭한 Ethereum 클라이언트를 구축하는 놀라운 작업을 해왔으며, 현재도 활발히 개발을 이어가고 있습니다.

Eth 노드 클라이언트 분포 (ethernodes.org/)

‍

왜 마이그레이션해야 할까요?

노드는 모든 블록체인 회사의 핵심 인프라입니다. 시스템이 블록체인에 정보를 읽거나 쓸 때마다 노드를 사용하게 됩니다.

전통적인 웹 인프라와 비교했을 때, 블록체인 노드는 관리하기가 훨씬 더 복잡하고 시간이 많이 소요됩니다. 또한 동기화 시간 때문에 새 노드를 설정하는 데 며칠에서 몇 주가 걸릴 수 있습니다. 즉, 노드 인프라에 문제가 생기면 제품이 몇 주 동안 작동하지 않을 수도 있다는 뜻입니다.

안정적이고 견고하며 확장 가능한 인프라를 확보하려면, 활발히 유지보수되는 노드 클라이언트를 운영하는 것이 필수적입니다.

Parity Technologies는 Parity Ethereum 코드베이스를 새로 만든 OpenEthereum DAO에 넘겼으며, 저희는 이 완전한 탈중앙화된 방식에서 이 노드 소프트웨어가 어떻게 발전해 나갈지 기대하고 있습니다. 반면 Ethereum Foundation은 앞으로도 계속해서 소프트웨어를 구축하고 개선할 전담 팀을 두고 있습니다.

활발히 개발되고 있는 프로젝트를 사용한다는 것은 버그, 안정성 문제, 포크 및 기타 예측하지 못한 문제들이 신속히 해결되고 소프트웨어가 계속 개선된다는 것을 의미합니다. 저희는 노드 인프라를 Geth로 전환하는 것을 적극 권장합니다.

이는 상당히 손이 많이 가는 작업이므로, 완전히 전환하는 데 2~4주 정도의 엔지니어링 시간을 예상하시는 것이 좋습니다.

마지막으로, 로우레벨 노드 인프라를 다루지 않고 핵심 제품 개발에만 집중하고 싶으시다면 저희에게 연락 주세요. Alchemy Blockchain Developer Platform은 누구나 훌륭한 블록체인 제품을 손쉽게 만들 수 있도록 처음부터 설계되었습니다.

자, 이제 기본 내용을 파악하셨으니 마이그레이션을 시작해 보겠습니다! ‍

Parity에서 Geth로 마이그레이션하는 방법

8단계

1. Parity 전용 네임스페이스 메서드에 대한 의존성 제거
2. Parity 전용 응답 필드에 대한 의존성 제거
3. 잘못된 요청에 대한 API 전용 응답에 대한 의존성 제거
4. Parity 전용 에러 코드에 대한 의존성 제거
5. Geth 하드웨어 설정
6. Geth 소프트웨어 설정
7. 노드에서 애플리케이션별 트래픽 시뮬레이션 실행
8. 트래픽 전환 및 서비스 모니터링

‍

1. Parity 전용 네임스페이스 메서드에 대한 의존성 제거

Parity와 Geth는 둘 다 Ethereum Foundation이 제정한 범용 JSON-RPC Ethereum 프로토콜을 구현하며, 그 위에 각자의 보충 API 메서드를 추가합니다. parity_allTransactions 같은 Parity 네임스페이스 메서드가 있는데, 이는 Parity 노드 시점에서 대기 중인 모든 트랜잭션을 반환합니다. 기능적으로는 다른 패키지들에 걸쳐 Geth에 대응되는 기능이 있을 것입니다. Alchemy로 들어오는 트래픽 기준으로 볼 때, Geth에서 가장 크게 빠진 것은 trace 모듈이며, 이 메서드들은 debug 패키지로 옮겨졌습니다. 여기서 trace_replayTransaction 같은 인기 있는 trace 메서드를 유사한 _debug_traceTransaction_으로 대체할 수 있습니다.

‍

2. Parity 전용 응답 필드에 대한 의존성 제거

일관된 구현을 위해 최선을 다했음에도 불구하고, 몇 가지 사소한 차이가 있습니다. Geth 응답에서 생략된 필드에 의존하고 있지 않은지 확인하세요. 실제로 _eth_getLogs_의 logs 객체에서 반환되는 transactionLogIndex 필드처럼 특정 필드에 의존하는 사례를 본 적이 있습니다.

일반적으로 Geth는 노드의 상태를 유지하기 위해 오래 걸리는 호출을 잘라내고 실패시키는 경향이 있습니다.

‍

3. 잘못된 요청에 대한 응답 차이

형식은 올바르지만 EVM (Ethereum Virtual Machine)에서 어떤 이유로든 실패할 수 있는 요청은 다르게 동작할 수 있습니다. 잘못된 요청에 대해 Parity의 VM 실행 에러에 의존하고 있지 않은지 확인하세요. Geth에서는 일반적으로 0x 결과를 반환합니다. 잘못된 요청의 몇 가지 예시는 다음과 같습니다:

• 제공된 _eth_call_의 block number 매개변수가 pending 상태인 경우
• _eth_getLogs_의 block range를 노드에서 찾을 수 없는 경우
• 5초 이상 실행되는 _eth_call_은 EVM에 의해 자동으로 중단됩니다.

‍

4. Parity 전용 에러 코드

일부 클라이언트의 재시도 메커니즘은 특정 로직을 파악하기 위해 Parity 고유의 에러 코드에 의존합니다. Geth에서 달라질 수 있는 에러 코드에 의존하고 있지 않은지 확인하세요. Parity JSON-RPC 에러 코드의 더 자세한 목록은 여기에서 확인할 수 있습니다. 일반적으로 이러한 에러 중 일부는 구체성이 떨어지므로, 이러한 경우를 처리하기 위한 클라이언트 측 로직이 어느 정도 필요합니다.

‍

5. Geth 하드웨어 설정

Geth 노드는 기존에 Parity에 사용하던 것과 동일한 하드웨어에서 실행할 수 있어야 합니다. Geth 팀과 논의하며 발견한 몇 가지 주요 특성이 새로운 Geth 노드의 성능을 유지하는 데 도움이 됩니다. 주의 깊게 모니터링해야 할 시스템 지표는 두 가지입니다: CPU 사용률과 iowaits (시스템이 디스크에 쓰는 속도)입니다. 실제로 노드가 호출 실패를 일으키거나, 응답하지 않거나, 전반적으로 성능이 저하된 상태로 진입할 때 이 두 지표 사이에 강한 상관관계가 있는 것을 확인했습니다. CPU 사용률과 iowait 사용량은 사용 중인 하드웨어에 따라 달라집니다. EC2 m5.2x large 인스턴스의 경우, archive 노드에서 CPU 사용률이 약 65%, iowaits가 초당 1회 정도일 때 성능 저하가 발생하는 것을 일반적으로 확인했습니다.

‍

Alchemy 내부 Geth 노드 Iowaits ‍

6. Geth 소프트웨어 설정

드물지만, Geth 노드가 임의의 시점(알 수 없는 block number)에서 동기화가 멈추는 경우를 본 적이 있습니다. 이런 경우, 인내심을 가지고 기다리면 결국 몇 시간 내에 동기화가 다시 시작됩니다.

Geth 프로세스를 시작할 때 몇 가지 주의할 점이 있는데, 이에 대해 아래에서 다루겠습니다. Geth가 지정하는 플래그 옵션은 매우 많습니다. --pprof 플래그는 peer count, tx_pool 등 노드 상태에 대한 유용한 정보를 많이 제공하며, 기본적으로 포트 9090에 노출됩니다. 또 하나 중요한 점은 kill signal을 KillSignal=SIGINT로 지정해야 한다는 것입니다. Geth를 재시작할 때 문제가 발생하는 경우를 발견했는데, 이는 Geth가 종료 시 메모리에 있는 블록이나 상태를 영구 디스크에 제대로 플러시하지 않아, 마지막 블록으로 되돌아가는 현상이었습니다.

‍

7. 노드에서 애플리케이션별 트래픽 시뮬레이션 실행

요청/응답 형식은 동일하지만 Parity 버전과 약간 다르게 동작하는 몇 가지 메서드를 Geth에서 확인했습니다. 실제로 발견한 사례는 다음과 같습니다: eth_gasPrice 및 이에 의존하는 eth_estimateGas 같은 gasPrice 추정 메서드는 Geth에서 Parity보다 낮은 gasPrice를 예측하는 경향이 있는 추정 모델을 사용합니다. 이로 인해 다음과 같은 예기치 않은 트랜잭션 실패가 발생합니다: Transaction gas price supplied is too low. There is another transaction with the same nonce in the queue. Try increasing the gas price or incrementing the nonce. gas price에 여유분을 두거나, Eth Gas Station 등의 다른 제3자 소스를 이용해 가격 추정치를 얻음으로써 이를 완화할 수 있습니다.

‍

8. 트래픽 전환 및 서비스 모니터링

드디어 전환할 시간입니다! 트래픽을 Geth로 옮기고 며칠 동안 주의 깊게 모니터링하세요. 예기치 못한 다른 문제가 발생하면, 언제든 Geth 팀에 문의하거나 저희에게 연락 주세요.

‍

더 쉬운 마이그레이션 방법을 원하시나요?

이 가이드가 Parity에서 Geth로의 마이그레이션 과정을 탐색하는 데 도움이 되었기를 바랍니다! 질문이나 어려움이 있으시면 언제든 저희에게 연락 주세요. 저희가 도와드리겠습니다.

또한, 노드 관리와 같은 로우레벨 작업을 처리할 필요 없이 블록체인 애플리케이션을 훨씬 더 쉽게 구축하고 출시할 수 있는 플랫폼으로 개발 속도를 한층 끌어올리고 싶으시다면, 저희에게 연락 주세요!

Alchemy는 개발자의 삶을 더 편하게 만들기 위해 처음부터 Blockchain Development Platform을 설계했습니다. 강력한 개발자 도구 모음, 24시간 연중무휴 지원, 전 세계적으로 확장 가능한 새로운 블록체인 인프라 플랫폼을 통해, 개발 시간을 수천 시간 절약하고, 애플리케이션을 107배 더 안정적으로 만들고, 사용자를 위한 훨씬 더 나은 제품을 만들 수 있습니다. 더 자세히 알고 싶으시면 연락 주세요!

Geth로의 마이그레이션에 행운을 빕니다.

2020년입니다. 건강 관리하시고, 노드도 건강하게 유지하세요!

‍

---

무료 Alchemy 계정을 만들고 싶으시면 여기를 클릭하세요.

‍

Alchemy 소개

Alchemy는 197개국 수백만 명의 사용자가 이용하는 제품을 지원하는 선도적인 Blockchain Development Platform을 제공합니다. Alchemy Platform의 새로운 인프라 엔진과 타의 추종을 불허하는 개발자 도구 모음은 창작자들이 훨씬 짧은 시간에 훌륭한 블록체인 기반 제품을 손쉽게 만들 수 있도록 지원합니다. Stanford University, Coinbase, Google 회장, Charles Schwab을 비롯한 기술 및 금융업계 최고 경영진의 지원을 받는 저희 팀은 Google, Microsoft, Facebook과 같은 기술 대기업에서 수십 년간 쌓은 경험을 바탕으로 블록체인 개발과 대규모로 확장 가능한 인프라에 대한 깊은 전문성을 갖추고 있습니다.