쿼크체인 설명서 Part 2 : 샤딩의 간략한 소개와 블록체인 샤딩의 과제
쿼크체인 설명서 Part 2 :
샤딩(Sharding)의 간략한 소개와 블록체인 샤딩의 과제
(확장성에 대한 이야기가 궁금하시다면 이전 칼럼인 쿼크체인 설명서 Part 1 : 블록체인의 확장성에 대한 간략한 소개, 그리고 쿼크체인 을 참조해 주세요)
현재까지 나온 확장성에 대한 여러가지 대안들 중 샤딩(Sharding)은 수평적 확장성을 가능하게 하는 어쩌면 가장 많은이에게 채택되고 있는 대안 중 하나일 것입니다. 샤딩의 기본적인 개념은 전체 시스템의 상태(Global System State)를 샤드(Shards)라고 하는 다수의 하위 상태(Sub-States)로 분할하여 상대적으로 독립적인 각 샤드에서 트랜잭션을 처리하는 것입니다. 적절한 샤딩 기술의 설계를 통해 샤드의 갯수나 프로세서(노드)의 갯수가 증가할 수록 시스템의 수용력(Capacity)은 증가하는, 바꿔말해 선형비례(Linear Scale)하는 수용력을 가지게 될 것입니다.
샤딩을 적용하기 위해서는 두 가지 핵심 질문에 대한 답이 필요합니다.
전체 시스템의 상태는 무엇이며 어떻게 시스템의 상태를 변경할 수 있습니까?
· 예를 들어 BigTable과 Cassandra와 같은 중앙화된 시스템에서는 분산 키 값(KV) 저장소에서의 시스템의 상태는 키(Key)라고 하는 임의의 바이트에서 값(Value)라고 하는 임의의 바이트로 연결(Map)하는 작업을 이야기 하며, 시스템 상태를 변경하는 작업은 작성(Create), 읽기(Read), 업데이트(Update) 그리고 삭제(Delete)들로 CRUD 작업이라고 합니다.
· 또다른 시스템 상태변경의 예는 구글 파일 시스템(Google File System, GFS)나 하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS)과 같이 파일을 추가만 할 수 있는 시스템에서 찾아볼 수 있는데, 이 곳에서 시스템의 상태는 디렉토리나 파일들의 묶음으로 존재하며, 상태를 변경하는 동작에는 1) 작성, 삭제, 디렉토리내 정렬이나 2) 열기, 추가, 읽기, 파일 닫기 동작와 같은 두 가지 각기 다른 세트로 존재하고 있습니다.
모든 동작이 정확하고 효율적으로 처리될 수 있으려면 시스템의 상태를 샤드로 어떻게 분할해야 할까요?
시스템의 상태를 분할하는 방법은 시스템의 성능에 매우 치명적인 영향을 끼치게 됩니다. 만약 분할에 대한 설계가 부적절 하다면, 시스템의 성능은 매우 저하될 것입니다. 다음은 상태 분할을 설계할 때 고려해야할 몇가지 중요한 점입니다.
· 분할할 상태 : 시스템의 상태 중 어떤 부분을 분할해야 할까요? 시스템의 모델을 단순화 하기 위해서는 1) 싱글노드에서 존재하기에 너무 크기가 크거나 혹은 2) 매우 빠른 초당 동작 속도를 필요로 하는 일부 시스템의 상태에 대해서 분할해야 합니다. 반면, 단일기기로 처리하기에 충분히 작은 크기이거나 동작이 자주 일어나지 않는 일부 시스템의 상태는 분할을 고려할 필요가 없을 것입니다. 이러한 모델의 예로는 디렉토리의 데이터 크기가 상대적으로 작거나 자주 쓰이지 않던 디렉토리를 제외한 나머지 파일의 데이터만 분할하던 초기버전의 구글 파일 시스템(GFS) 과 하둡 분산 파일 시스템(HDFS)을 꼽을 수 있겠습니다.
· 동작(트랜잭션) 시맨틱스* 확보 : 시스템의 상태를 어떻게 분할해야 동작 시맨틱스를 만족시킬 수 있을까요? 동작 시맨틱스의 핵심 중 하나는 원자성(Atomicity)**으로, 어떤 동작이 다수의 샤드에서 원자적(Atomically)으로 상태를 변경하기 위해서는 샤드간의 적절한 코디네이션을 요하며, 이는 많은 비용이 발생할 수 있습니다. 결과적으로는 샤드간 코디네이션을 통한 성능의 향상은 기대하기 어려우며, 때로는 성능이 저하되기도 합니다. 이러한 문제점을 피하기 위해서 대부분의 현대 샤딩 기술은 한개의 샤드에 원자적 배치 동작(Atomic Batch Operation)을 통해 복잡한 멀티 샤드 원자성 문제를 상위 레이어 애플리케이션으로 보내 처리합니다.
* 역자주 : 동작 시맨틱스는 프로그램이 정확성, 안정성, 보안성 등과 같이 원하는 속성을 가질 수 있도록 하는 정식 프로그래밍 언어 체계의 범주로서 수학적인 의미를 덧붙이는 대신 실행과 절차와 같은 동작에 대한 논리적인 설명으로부터 증명을 구성하여 검증하는 방식입니다. 바꿔말하면 상태의 전이를 통해서 프로그램이 실행되는 원리를 설명할 수 있습니다.
** 역자주 : ACID(원자성, 일관성, 고립성, 지속성)은 데이터베이스의 트랜잭션이 안전하게 수행된 다는 것을 보장하기 위한 성질을 가리키는 약어입니다. 이 중 원자성(Atomicity)은 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력입니다. 예를 들면 자금 이체는 성공할수도 실패할 수도 있지만, 보내는 쪽에서 돈을 빼오는 작업만 성공하고 받는 쪽에서 돈을 넣는 작업을 실패해서는 안된다는 개념입니다. 원자성은 이와 같이 중간 단계까지 실행되고 실패하는 일이 없는 신뢰있는 네트워크가 가져야 하는 의미론적 속성 중 하나입니다. (출처 : https://ko.wikipedia.org/wiki/ACID)
· 부하/크기의 균형 : 시스템의 상태를 어떻게 분할해야만이 a) 모든 샤드간의 네트워크 부하가 통계적으로 고루 분포 되거나, b) 분할된 시스템 상태의 크기가 모든 샤드에 걸쳐 고루 분포되도록 할 수 있을까요? 이 두가지 조건을 달성하는 것은 수용력의 선형적 비례를 위한 핵심 전제조건입니다. 바꿔말해 새로운 샤드를 더 추가한 후에도 부하/크기가 고르게 분포되어 있어야만 새로 추가된 샤드를 처리할 수 있는 더 많은 노드를 추가하여 시스템의 수용력(Capacity)이 비례하여 증가할 수 있습니다. 주의할 점은 부하/크기의 분산의 정도는 사용자의 동작패턴에 매우 깊은 관계가 있기 때문에 만약 사용자의 동작 패턴이 시간이 지남에 따라 많이 변화한다면 (일시적이거나 혹은 영원히) 불균형한 부하 분포를 불러오게 될 것입니다.
· 재샤드(Reshard) : 어떻게 더 많은 샤드를 추가할때 새로운 노드들이 추가된 샤드를 위해 일할 수 있게 할 수 있을까요? 더 많은 샤드를 추가하고 나면, 새로운 샤드들은 오래된 샤드의 상태를 어느정도 보유한 채 새로운 노드로 이주하게 될 것입니다. 만약 재샤딩을 하는 동안에 새 노드로 이주를 한다면 아마 시간이 아주 오래 걸리거나 혹은 현재의 서비스가 멈추게 되는 결과를 초래할 수 도 있습니다. 게다가 리샤드의 전이나 리샤드의 후에는 지원되는 지원동작 시맨틱스를 확보할 필요가 있습니다.
앞서 언급했던 쿼크체인에 대한 질문들에 대해 대답 하기 이전에 현존하는 블록체인에서의 샤딩의 시스템 모델과 어려움에 대해서 소개하고자 합니다.
기존 블록체인의 시스템 상태 및 트랜잭션
우리는 시스템의 상태가 기본적으로 주소에서 계정데이터로의 키(Key)와 값(Value)의 연결(Map)인 이더리움과 유사한 계정 기반의 블록체인 모델을 고려하고 있습니다. 주소에는 두 가지 형태가 있습니다.
· 사용자 주소
· 스마트 컨트랙트 주소
그리고 계정데이터는 다음과 같이 구성되어 있으며, 이 중 사용자 주소의 코드와 저장소는 비어 있습니다.
· 잔고
· 난수(Nonce)
· 코드
· 저장소
아래와 같이 CRUD 작업의 다양한 조합을 지원하는 두가지 유형의 트랜잭션이 있습니다.
1. 두 개 주소의 잔고와 발신자의 난수를 업데이트 하는 두 사용자 계정간의 전송 트랜잭션
2. 아래와 같은 스마트 컨트랙트 트랜잭션
· 발신자의 난수 업데이트
· 다양한 유저 주소의 잔고 업데이트
· 콜(Call)이나 위임콜(Delegate Call)을 통한 다수의 스마트 컨트랙트 잔고와 저장소 업데이트
· 다중 사용자 주소 및 계정 데이터 생성
· 다중 스마트 컨트랙트 생성
블록체인 샤딩의 과제
현존하는 확장성 문제의 해결책들과 비교하여 좋은 점은 블록체인의 시스템 상태는 분산화 키값(KV) 저장소인 BigTable이나 Cassandra와 완벽하게 일치한다는 점입니다. 그러나 트랜잭션의 시맨틱스는 단순 CRUD 작업에 비해 매우 어렵다는 단점이 있습니다. 스마트 컨트랙트 트랜잭션이 잠재적으로 어떠한 시스템 상태의 키-값 쌍에 대응하는 CRUD 작업을 수행할 수도 있을 것입니다. 그러나 만약 상태가 다른 하위 상태인 샤드로 분할 되었다면 여러 샤드들에 거쳐 원자성을 확보하는 것과 같이 확장하기는 매우 어려울 것입니다. (아마 대부분의 시간 동안은 불가능 할 수도 있습니다) 블록체인의 원장을 어떻게 분할한 것인가는 블록체인 샤딩의 기본적인 문제입니다.
탈중앙화 환경에서의 더욱 더 커다란 과제는 보안이 보장되는 방법으로 모든 샤드에서의 트랜잭션을 처리하기 위한 적절한 컨센서스(Consensus)를 구축하는 것일입니다. 새로운 샤딩 컨센서스는 새로운 공격에 대한 가능성을 열어버립니다. 스레드(Thread) 모델에 대한 포괄적인 분석이 없다면, 샤드는 쉽게 손상이 될 것이고 이에 따라 전체 네트워크도 쉽게 손상이 될 것입니다.
분할과 합의에 대한 과제 이외에도, 샤딩의 공통된 샤드간 트랜잭션(Cross-shard Transaction)과 같은 샤드간의 상호 운용성(interoperability)에 대한 문제가 있습니다. 기본 로직은 운용성입니다. 사용자는 모든 샤드에 분포되어 있는 스마트 컨트랙트나 다른 사용자의 계정을 포함은 모든 리소스에 접속할 수 있어야 합니다. 어떻게 효율적이고 안전하게 샤드간 트랜잭션을 개발할 것인지는 가장 중요한 주제입니다.
다음 칼럼을 통하여 우리는 블록체인에서의 샤딩의 이러한 과제들에 대한 쿼크체인의 해결책에 대해서 이야기를 해 볼 것입니다. 더불어 우리는 유사한 점과 차이점에 대하여 각기 대응하는 곳에 대한 설명을 하는 방법을 통해 구글 BIgTable과 같이 현존하는 중앙화 시스템과 쿼크체인간의 비교도 해 볼 것입니다.
더욱 더 많은 것을 배워보고 싶다면 우리의 다음 글인 쿼크체인 설명서 Part 3 : 쿼크체인의 상태 분할 샤딩을 참조해 주시기 바랍니다.
쿼크체인이란?
쿼크체인은 수평 확장성 기술을 확용하여 블록체인의 확장성 문제를 해결하는 것을 목표로 합니다. 쿼크체인의 사명은 이 세계의 누구나 언제 어디서든 블록체인 기술사용할 수 있게 하는 것입니다. 쿼크체인에 관심이 있으시다면 아래의 링크를 따라 더 많은 정보를 확인해 주세요.
홈페이지 https://www.quarkchain.io
텔레그램(ENG) https://t.me/quarkchainio
텔레그램(KOR) https://t.me/quarkchainkorea
카카오톡 https://open.kakao.com/o/gP54vQW
트위터 https://twitter.com/Quark_Chain
Steemit https://steemit.com/@quarkchain
Medium https://medium.com/quarkchain-official
Reddit https://www.reddit.com/r/quarkchainio/
Weibo https://weibo.com/QuarkChain
