February 04, 2022
사실 블록체인 노드를 운영하는 주체와 이유는 아래 외에도 다양합니다.
필자는 그 중 “애플리케이션을 위해서” 노드를 운영한 경험이 있습니다. (모든 과정에 참여한 것도 아닙니다.)
물런 애플리케이션도 제가 개발합니다.
뭐 많이 해 본 것도 아니고, 다 아는 것도 아닌데 글을 쓰는 이유는… 그냥 쓰고 싶어서입니다.
코드 레벨 이해이나, 개발에 대한 이야기가 아닌 순수하게 운영에 대한 이야기입니다.
ethereum.org에서는 노드를 아래와 같이 설명합니다.
노드란 “실행 중”인 ‘클라이언트 소프트웨어’
사실 블록체인 노드 운영을 요약하면 아래와 같습니다.
농담 같지만 그렇네요…
조금 더 자세하게, 제가 한 업무를 설명해보면
블록체인 노드는 보통 오픈소스로 공개되어 있고 다수의 개발자들이 개발합니다.
최소한, 운영자는 노드를 실행하고 앞으로 겪을 문제 상황을 해결 할 지식을 필요로 합니다.
사실 너무 다양합니다. 설정을 비롯된 문제부터 성능 이슈…
한번 생각해보자면 아래와 같습니다
성능편
네트워크 이슈편
자잘한 이슈편
조금 더 디테일하게 XRP 노드를 운영하며 겪었던, 실제 케이스를 소개해보겠습니다.
당시 XRP 노드에서는 위 사진과 같이 주기적으로 Disk I/O와 CPU Usage가 크게 증가하고 다시 줄어드는 문제가 발생했습니다.
당시 슬랙방에 남긴 메세지
Git Issue, Docs 등을 정독하여 원인이 Online Deletion(DB Prunning)에 있다고 추측했고
오픈소스 개발자와의 대화를 통해 현재 상황에 알맞는 설정값을 찾아내고, 해당 문제를 최종 해결하였습니다.
Geth v1.10.15 Upgrade 후 노드를 실행하니 위와 같은 오류가 발생했습니다.
당시 팀원분의 슬랙 메시지
원인은 Github Issue에서 키워드 검색을 통해 쉽게 찾을 수 있었습니다. 릴리즈노트를 확인 후 업데이트를 진행하는데 당시 릴리즈 노트에는 Fast Sync Config를 없애는 점을 명시하지 않았습니다.
저는 당시 Geth의 Snapshot과 Snap Sync에 대해 학습을 마쳤기 때문에, 해당 설정에 대해 팀원분들께 설명 드렸습니다.
물런 이미 동기화(Sync)를 마친 상태의 노드였기 때문에, 동기화전략을 Fast => Snap/Full으로 바꿔도 어떠한 차이도 없습니다.
큰 문제를 해결한 이야기는 아니지만, 공식문서나 자료를 항상 잘 정독하면 무엇이 좋은지 보여주는 사례입니다.
당시 상황은 클레이튼이 죽었어요에서 확인 가능하다.
물런 정확히 ‘노드 운영’에 대한 이야기는 아니지만, 위와 같은 문제도 존재하는것을 소개하고 싶었습니다.
담지 못한 많은 사례들이 있지만, 문제에 잘 대응하기 위한 방법은 간단합니다.
언제나 정공법…
언제나 공식문서(Github, Running Guide 등)를 잘 읽어야 합니다.
모니터링을 잘 해야합니다. 사람은 잘 할 수 없으니, 도구를 잘 사용해야 합니다.
AWS와 같은 클라우드를 사용하면 좋겠죠? 그리고 스냅샷과, 이중화를 할 수 있다면 더더욱 좋습니다.
사실 목적에 맞고 Latency 이슈가 없다면 퀵노드, KAS와 같은 서비스를 사용하시는것도 좋습니다.
그리고 알 수 없는 문제 상황이 생기면 깃헙 이슈에 상세하게 제보하면 개발자분들께서 도와주십니다. 만세!
API를 입에 달고 살지만 블록체인 노드를 운영하면서 마치 ‘리모콘’을 사용하는 것과 같다고 자주 느낍니다.
노드라는 알 수 없는 ‘블랙박스’를 잘 동작 시키기 위해서 (겹겹이 쌓인 계층 위) 리모콘의 버튼을 열심히 눌러봅니다.
위에서 ‘버튼’을 이해해야 한다고 말했는데 그런 맥락에서 말씀드렸습니다.