안녕하세요. 우리는 EOSeoul입니다.

우리는 이 글을 통해 WARP network을 제안하고 1차 실험 결과를 공유하고자 합니다.

네 줄 요약 (TL;DR)

WARP 네트워크는 Latency와 Jitter을 조금이라도 줄여보려는 노력이며, 인터넷보다 조금 더 빠릅니다.
튜토리얼은 Failover 기능까지 테스트를 마친 후 추후 포스트에 공개할 예정입니다.
WARP 네트워크를 사용할 BP 노드, 그리고 WARP 네트워크를 함께 구축해갈 믿음직한 BP 파트너를 초대할 예정입니다.
이 내용을 Worker Proposal로 제안할 계획입니다.

들어가기

이 문서에서 다루는 내용과 다루지 않는 내용은 아래와 같습니다.

다루지 않는 내용
- DDoS 방어
- IP 주소 은닉
Part 1(이 문서)에서 집중해서 다루는 내용
- WARP 네트워크를 제안하는 배경
- 실험을 통해 WARP 네트워크를 통한 Latency/Jitter 감소
Part 2(추후 공개될 포스트)에서 다룰 내용
- WARP 네트워크를 통한 Route Failover
- WARP 네트워크 참여 노드 설정 튜토리얼
- WARP 참여 노드 및 WARP 엔드포인트 피어 모집

WARP 네트워크란?

단순하게 말하면, 블록체인 노드 사이의 통신 지연 시간(latency)과 지연 시간 튐(jitter)을 줄이는 데 목적을 둔 글로벌 블록체인 네트워크 아키텍처입니다.

EOSeoul은 전세계에 걸친 안정적인 서비스를 가능하게 할 블록체인 네트워크 아키텍처를 구현하기 위해 다양한 실험을 진행하고 있습니다. 이 문서에서는 주로 클라우드 플랫폼, VPN, BGP 라우팅을 이용해서 Overlay 네트워크 구현을 다룹니다. 앞으로 Failover, 네트워크 가속 등의 기술을 통해서 WARP 네트워크는 업그레이드될 것입니다. 또한 다양한 보안 기술을 도입하는 실험을 이어갈 것입니다.

EOSIO 블록 생성 네트워크의 역할

[그림 1]

P2P 네트워크에 참여하는 모든 노드가 블록을 생성할 수 있는 비트코인이나 이더리움과 달리, EOS는 토큰을 가진 사람들이 투표로 뽑은 21개의 블록 프로듀서만 블록 생산에 참여할 수 있습니다. 21개의 블록 프로듀서가 선출되면, 차례대로 12개씩 블록을 생산한 후 다음 블록 프로듀서에게 생산 순서가 넘어갑니다. 이 블록은 정확히 500ms(0.5초) 마다 생성됩니다.

사용자들의 트랜잭션은 21개의 블록 프로듀서 전체에 브로드캐스트되고, 블록 프로듀서는 해당 트랜잭션을 처리해야 합니다. 블록 프로듀서는 수신한 트랜잭션 요청을 받아서 내용을 검증하고 실행한 후 블록을 생성하여 브로드캐스트합니다. 또한 다른 블록 프로듀서가 생성한 블록을 받아서 검증해야 합니다.

21개의 블록 프로듀서는, 자신이 블록을 생성하기 위해서 수행할 때에나, 다른 블록 프로듀서들이 만든 블록을 검증할 때나 위의 동작을 반복합니다. 이런 방법으로 21개 중 15개 이상의 블록 프로듀서가 검증을 마친 블럭은 비가역 상태가 됩니다.

이런 모든 과정은 그림 1과 같은 Full-mesh 형태의 블록 프로듀서 네트워크 위에서 이루어집니다.
지리적으로 전 세계에 널리 퍼져 있는 블록 프로듀서 사이에서 지연 시간이 낮고 안정적인 통신이 필요하고, 따라서 이를 구현하기 위한 네트워크 아키텍처 엔지니어링이 중요합니다.

고려사항

EOSeoul은 10년 이상의 기간 동안 BGP를 이용해서 네트워크를 다뤄왔습니다. BGP는 라우팅 프로토콜의 일종으로, 인터넷 서비스 제공자와 직접 네트워크를 연동하는 데 사용하는 표준 기술입니다. EOSeoul은 BGP를 이용해서 국제망 업링크와 국내망 업링크를 별도로 구축했고, 또 DDoS 대응을 비롯해서 다양한 트래픽 엔지니어링 작업을 진행해왔습니다.

우리가 보기에는, 블록 프로듀서 사이의 통신이 이용하는 통신 경로는, 상황에 따라 다르겠지만, 비교적 대역폭을 많이 사용할 일반 트래픽의 네트워크 통신 경로와 섞일 가능성이 높습니다. 예기치 못한 다양한 변수로 인해 네트워크 지연 시간 품질에 영향을 줄 가능성이 있습니다.

이와 같은 네트워크 지연 시간에 대한 검토는 EOSIO Dawn 2.0 출시 노트의 두 군데( 1, 2 )에서 찾아볼 수 있습니다.

원래는 블록 프로듀서 순서를 임의의 방식으로 랜덤하게 섞기로 했다가, 지역 안배를 하지 않은 상태에서 지구 반대편의 블록 프로듀서로 넘어가는 경우 Latency로 인해 데이터 전달 누락과 그로 인한 블록 누락이 예상되어, 순서 역시 투표로 정할 것이라는 계획입니다. 선출된 21개의 블록 프로듀서가 어떤 순서로 블록을 만들 것인지는 아직 명확하지는 않은 것으로 보입니다.

많은 블록 프류듀서가 AWS 클라우드를 이용해서 서비스를 준비하는 것으로 보입니다. 그렇기 때문에 대부분의 블록 프로듀서가 연결되는 망은 AWS가 피어링하는 라우트를 통해 P2P 토폴로지가 구성될 것 같습니다. 하지만 가용성과 보안에 많은 주의를 기울이고 인프라 운영에 정통한 블록 프로듀서들은 자체 데이터센터를 통해 블록 생산에 참여할 것입니다. 모든 블록 프로듀서는 시스템 엔지니어가 시스템을 설치하고 운영해나갈 것입니다.

과거에 많은 사람들이 EOS Developer 텔레그램 채널을 통해서 MPLS VPN과 같은 솔루션을 검토해왔습니다. MPLS VPN 구성은 값비싸고 비교적 구성이 복잡하며 전용회선과 전용 하드웨어가 필요합니다. 모든 블록 프로듀서는 시스템 엔지니어가 시스템을 설치하고 운영해나갈 것입니다. 그러나 경우에 따라 네트워크 엔지니어의 참여가 없는 블록 프로듀서가 선거에 참여할 수도 있습니다. 따라서 네트워크 엔지니어의 참여가 없더라도, 네트워크 지식이 있는 시스템 엔지니어가 구현할 수 있는 방법을 구상했습니다.

WARP network 실험

현재 블록 프로듀서 사이의 P2P 통신의 대부분은 별도의 최적화 없이 인터넷 서비스 제공자(ISP) 또는 클라우드에서 제공하는 인터넷을 사용합니다. 위에서 언급한 기술적인 고려사항들을 해소하기 위해 아래와 같이 WARP Network을 제안합니다.

이 실험에 사용하는 원천 기술 자체는 표준화된 통신 규약에 의해 검증된 기술입니다.
다만, EOS 환경에서는 이 기술이 효과를 발휘할 지는 확인 되지 않았기 때문에 EOSeoul 은 실제 라이브 환경과 유사한 구성으로 전 세계적으로 몇 군데의 지역 거점에 인프라를 구성하고 실험을 진행했습니다.

개념적으로는 아래와 같은 네트워크 아키텍처를 구성할 것이며, 글로벌 네트워크 인프라스트럭처를 구축/보유하고 있는 글로벌 클라우드 벤더, CDN, 인터넷 서비스 제공자와 협업해서 진행할 것을 고려하고 있습니다.

[그림 2]

실험 과정에서 발생하는 기술적인 의문점은 블록 프로듀서 뿐만 아니라 EOS 커뮤니티와 적극적으로 소통을 해 나갈 예정입니다. 이 모든 과정과 결과 모두 포스팅을 통해 여러분들에게 지속적으로 공개하겠습니다.

1차 실험 구성

구성도

[그림 3]

아키텍처

AWS Region에 BP가 연결 될 EP(End Point) Instance를 구성하고, Region에 구성된 EP간 VPN/BGP 연동을 통해 Private Network를 구성함
AWS Region 중 지리적 위치를 고려하여 Test Region 4곳(Seoul, Oregon, Frankfurt, São Paulo)을 선정함
EP(End Point)역할의 Instance는 VPN과 BGP를 지원하는 상용 제품을 사용하거나 오픈 소스를 사용해서 구성함
EP의 OS로 AWS Marketplace에서 제공하고 있는 VyOS를 사용함. VyOS는 Debian GNU/Linux을 기반으로 하는 오픈 소스 시스템으로, BGP, OSPF, RIP등의 동적 라우팅과 IPSec, OpenVPN, firewall, NAT등의 기능을 지원함.
- 참고 : https://vyos.io/
EP Instance간에 OpenVPN으로 VPN Tunnel을 연결한 후, VPN Tunnel을 통해 EP간 Full mesh로 BGP Neighbor를 구성함
BP Instance에서는 OpenVPN과 Quagga를 사용하여 인접한 EP와 VPN으로 연결하고 BGP를 연동함
BP Instance에서는 BP간 P2P통신에 사용할 IP를 BGP를 통해 announce함으로써, 모든 BP는 통신할 상대 BP의 라우팅 정보를 학습함
BGP를 통해 전달된 라우팅 경로를 사용하여, BP Instance간 Latency를 측정하고 Public Internet망을 사용했을 때와의 차이를 비교함

EP-to-EP 연결 구성

EP Instance 정보
- Instance Type : t2.micro
  - ICMP를 사용해 RTT 측정이 주된 목적이므로, Instance Type은 큰 영향성이 없다고 판단하여 Instance는 t2.micro를 사용함
- Version : VyOS 1.1.8

EP-to-BP 연결 구성

EP Instance 정보
- Instance Type : t2.micro
- Version : VyOS 1.1.8
BP Instance 정보
- Instance Type : t2.micro
- Version : Ubuntu Server 16.04
- ICMP를 사용해 RTT 측정이 주된 목적이므로, Instance Type은 큰 영향성이 없다고 판단하여 t2.micro를 사용함

설정

WARP network에 연동하는 node의 VPN, BGP 설정은 튜토리얼의 형식으로 추후 포스트에서 공개할 예정입니다.

1차 실험 측정 및 결과

측정 방법 : Public Internet 망을 경유하였을 때와 EOS Warp Network를 경유하였을 때 RTT 값을 측정합니다.
측정 대상

Network	Source IP		Destination IP
Public Internet	EOSSeoul Public IP	<->	Frankfurt BP Public IP
Public Internet	EOSSeoul Public IP	<->	Oregon BP Public IP
Public Internet	EOSSeoul Public IP	<->	São Paulo BP Public IP
WARP Network	EOSSeoul Private IP	<->	Frankfurt BP Private IP
WARP Network	EOSSeoul Private IP	<->	Oregon BP Private IP
WARP Network	EOSSeoul Private IP	<->	São Paulo BP Private IP

기간 : 한국표준시 2018년 5월 10일 19시 53분 부터 2018년 5월 14일 12시 53분까지 2초 간격으로 RTT 측정
결과 통계

시나리오	WARP Network	Internet	비고
서울-프랑크푸르트
RTT 평균 (ms)	264.711303	287.348705	인터넷 경로가 8.55% 더 느림
RTT 표준편차 (ms)	4.254607	4.910796	Jitter의 측면에서 인터넷 경로가 약간 변동성이 있음
서울-오리건
RTT 평균 (ms)	135.543697	151.029003	인터넷 경로가 14.42% 더 느림
RTT 표준편차 (ms)	3.015122	3.192323	Jitter의 측면에서 인터넷 경로가 약간 변동성이 있음
서울-상파울로
RTT 평균 (ms)	296.071500	305.732230	인터넷 경로가 3.26% 더 느림
RTT 표준편차 (ms)	2.298818	5.425839	Jitter의 측면에서 인터넷 경로가 훨씬 변동성이 큼

1차 실험 고찰

Public Internet망을 통할 때 보다 WARP Network을 경유하는 것이 RTT latency와 Jitter 값이 더 낮음을 확인할 수 있습니다.
위의 구성은 AWS으로만 구현할 수 있는 것이 아닙니다. GCP/Azure등 어떠한 Public Cloud 환경에든 구성할 수 있습니다. 하지만 누군가 운영의 주체를 맡아야 하고 운영 거버넌스가 필요하며 비용 역시 고려할 필요가 있습니다.
BP 트래픽 양을 예측하고, 그에 적합한 인스턴스를 선택하여 검증할 필요가 있습니다.
만약 AWS에 동작하는 두 개의 BP 사이의 P2P 통신에서는, 이미 AWS region 사이의 네트워크를 이용할 것이기 때문에, WARP Network의 효과는 제한적일 것입니다.
WARP Network은 AWS region 사이의 네트워크를 이용하며, 이 네트워크는 BP가 제어할 수 있는 영역 밖에 있습니다.
지역적으로 가까운 두 개의 BP 사이에서 일어나는 통신에서는, 오히려 WARP network을 사용하지 않는 것이 좋을 수 있습니다. 만약 지역적으로 가까운 두 개의 BP 사이의 통신을 WARP network을 경유하도록 설정한다면 Latency가 증가하는 현상이 발생할 수 있습니다.
만약 BP간 연결을 Private IP 대역으로 진행한다면, IP 충돌을 막기 위해서 사용할 수 있는 IP 대역을 정하고 개별 IP를 할당하는 등 거버넌스가 필요합니다.
우리는 IP 중복을 막고 WARP network이 고장난 상황을 대비해 Failover 구성이 가능하도록 Public IP간 통신 아키텍처를 실험하고 이에 대한 노드 설정을 공유할 예정입니다.
즉, Public IP로 WARP Network을 거쳐 P2P 통신이 이루어지다가, WARP Network에 장애가 발생하면 효과적으로 Public Internet을 이용하여 통신이 이루어집니다.
또한 EP 장애 발생시를 대비한 이중화 구성 방안을 구현할 계획입니다.

Stay Tuned!

이로써 EOSeoul이 진행한 WARP network의 장점과 단점을 살펴보았습니다. 단점은, 노드 설정이 추가되고 WARP network의 End Point 비용이 소모되며 WARP network에 장애가 발생할 때 Failover가 가능해야 합니다. 장점은, 별도 네트워크 장비가 필요하지 않고 시스템 엔지니어가 기술적으로 충분히 구현할 수 있으며 Public Internet에 비해서 지연 시간이 줄어들고 지연시간 튐이 안정적입니다.

WARP network은 진화할 것입니다. BGP를 통해 Failover를 구현해서 장애에 대비할 것입니다. 다양한 터널링 소프트웨어와 가속 소프트웨어를 실험하여 더욱 빨라질 것입니다. 다양한 퍼블릭 클라우드를 검토하고 다양한 인터넷 서비스 제공자와 협력하여 더욱 가용성이 높아질 것입니다.

우리는 Part 2를 통해서 WARP network을 이용할 수 있는 설정과 튜토리얼을 공개할 예정입니다. 그와 동시에 WARP network을 경유할 전세계 블록 프로듀서들을 초대할 것입니다. 또, WARP 네트워크를 함께 구축해갈 믿음직한 블록 프로듀서 파트너를 초대할 예정입니다. 이어서 구체화된 내용을 바탕으로 Worker Proposal로 제안할 계획입니다.

앞으로 포스팅할 Part 2를 기대해주세요!

EOSeoul은 피드백을 기다립니다.

제안과 질문은 언제나 환영합니다. 주저하지 마시고 EOSeoul에게 의견을 주세요. 아래 텔레그램 그룹에 가입하시면 EOSeoul의 최신 뉴스와 EOS와 관련된 기술적인 토의를 나누실 수 있습니다.

감사합니다!

EOSeoul 드림

Telegram (General Talk, 한국어) : https://t.me/eoseoul Telegram (Developer Talk, 한국어) : https://t.me/eoseoul_testnet Telegram (English) : http://t.me/eoseoul_en Telegram (简体中文) : http://t.me/eoseoul_cn Telegram (日本語) : http://t.me/eoseoul_jp Steemit : https://steemit.com/@eoseoul Github : https://github.com/eoseoul Twitter : https://twitter.com/eoseoul_kor Facebook : https://www.facebook.com/EOSeoul.kr EOSeoul 기술 문서 저장소 : https://github.com/eoseoul/docs

[Worker Proposal] WARP Network을 제안합니다 - Part 1