캡스톤 디자인이 시작되었다... 블록체인 도메인에 관심이 많고 웹 벡엔드나 프론트 앤드를 융합할 수 있고 실질적인 도움이 될만한 서비스들을 생각해보다 학생회를 위한 실시간 블록체인 장부 서비스를 기획하게 되었다. 이 포스트에서는 기획 단계에서 하였던 고민과 최종적인 아키텍쳐 설계에 대해서 써내려가 보자 한다.
1. 예상치 못한 문제
학생회가 사용하고 있는 은행계좌를 연동하는 API를 사용하면(계좌 거래 내역 조회 API) 그걸 그대로 우리가 사용할 허가형 블록체인에 저장하면 될 것이라고 생각하였다.
하지만 너무 순진했던 탓일 까 여러 금융 API를 살펴보아도 계좌의 내역을 조회하는 API는 쉽게 찾을 수 없었고 설사 찾더라도 마이데이터 사업자만 사용할 수 있는 형태였다.
2. 프로젝트 기획 수정
계좌의 거래 내역 데이터를 받아올 수 없는게 확정되었으니 자동화된 실시간 장부 서비스를 물 건너갔다고 생각하게 되었다. 이때 생각할 수 있는 대안은 총 두가지 였는데
1) mock 데이터를 만들어서 그 데이터를 또다른 API를 만들어서 지속적인 풀링하는 방식으로 마치 실시간으로 블록체인에 반영하는 것 처럼 하는 것
2) 장부에 학생이나 학생회가 입력할 수 있는 인터페이스를 만들어서 자동화된 장부 서비스는 포기해도 블록체인 방식의 전자 장부로 하는 것
팀원들과의 회의와 여러가지 생각을 통해 얻은 결과는 2) 주제의 프로젝트를 기획하기로 결정하였다.
이유는
1) 데이터는 실제 사용자에게 테스트 해볼 기간을 기획하였는데 그저 mock데이터를 계속해서 블록체인에 서버에서 넣을 뿐 사용자 입장에서 직접적으로 할 게 없었기 때문이다.
3. 프로젝트 아키텍쳐
3.1 왜 허가형 블록체인 인가?
기획단계에서 우리 팀은 허가형 블록체인을 사용 하기로 하였다.
그 이유는 우선 우리 학과 이외의 사람이 블록체인에 참여하여서 장부를 열람하는 것이 불가 해야하고 우리의 학과 사람이나 학생회 사람이라는 것이 허가 되야 함 때문이였다.
이를 만족하는 것이 허가형 블록체인이 였고 또 그에 걸맞는 것이 오픈 소스인 하이퍼 레저 패브릭이었다.
3.2 왜 하이퍼 레저 패브릭 인가?
여러 허가형 블록체인 중 하이퍼 레저 패브릭을 선택한 이유는 새로운 언어 학습의 러닝 커브에 대한 걱정 때문이었다.
하이퍼 레저 패브릭에서는 스마트 컨트렉트의 구현 언어와 게이트 웨이 언어의 많은 선택지가 있는데 내가 자주 사용하는 Go 언어와 typescript 언어를 사용하여서 구현할 수 있다는 점이 선택에 큰 작용을 하였다.
3.3 하이퍼 레저 패브릭 아키텍쳐
하이퍼 레저 패브릭 레이어 아키텍쳐는 크게 4가지로 구분할 수 있다.
1) Infra layer
클라우드 서비스(AWS, Azure) 등의 호스팅을 할 수 있는 클라우드나 환경을 말한다. 블록체인을 실질적으로 운영할 베이스을 말한다.
2) Blockchain layer
크게 4가지로 이루어 지는데
네트워크 레이어: 노드간의 연결 및 데이터 전송 관리
합의 레이어: 트랜잭션의 유효성 검증 및 블록체인 상태 업데이트
계약 레이어: 스마트 계약(체인 코드)을 실행하고 비즈니즈 로직을 정의
데이터 레이어: 블록체인 상태 데이터와 트랜잭션을 저장하는 데이터 베이스
이렇게 여러가지 레이어가 혼합되어서 존재한다.
3) Application layer
Spring Boot 나 nodejs express 와 같은 중개 서버를 포함해서 블록체인과 사용자 간의 데이터 전송을 처리하는 말 그대로 블록체인과 프론트엔드 사이의 중개 API 서버라고 할 수 있다.
기타 비즈니즈 로직 처리와 인터페이스의 직접적인 블록체인 접근을 제한하기위해 존재하는 서버라고 생각할 수 있다.
4) Presentation layer
사용자 인터테이스(UI)을 제공하여서, 웹 애플리케이션 또는 모바일 애플리케이션을 가진다. 직접적으로 사용자와 소통하는 창구하고 생각하면 된다. 웹 프레임 워크인 React, 앱 프레임워크인 React-native을 생각해보면 된다.
3.4 프로젝트 아키텍쳐
간단한 프레임워크 아키텍쳐는 다음과 같다.
4. 흐름도
4.1 초기 블록체인 세팅
학생회 조직과 학생 조직을 두가지 만든다. 그리고 학생회 조직에 초기 사용자가 존재해야 하기 때문에 특정 유저(이를테면 개발자)를 관리자 사용자로 정해 놓고 CA(인증기관)으로 부터 인증서를 받게 하여서 신원 확인을 할 수 있게 하고 체인코드를 통해 학생회 조직에 관리자 사용자를 등록한다.
4.2 학생회 사용자 가입 및 접근
최초의 사용자 이후 두번 째 사용자가 프론트엔드 접근하여 회원가입을 완료하는 과정을 나열해 보겠다.
1) 처음 가입을 하였다면 API가 그 사용자가 DB에 존재하는 학생, 학생회 일원들의 정보 검증를 한다
2) 검증이 완료되었다면 블록체인에 접근해서 CA를 통해 그 유저라는 인증서를 발급받도록 한다.
일련의 5번의 과정으로 이루어 지며 BlockChain에는 인증서에 대한 해시값을 저장하고 DB에는 인증서 자체를 저장하는 방식으로 진행한다.
3) 인증서를 가지고 학생회 조직에 가입해야하는 단계이다. 편의를 위해 초기 학생회 조직 일원(이미 존재하는 학생회 일원 유저)는 '유저1' 이전차의 과정을 통해 인증서를 발급받은 유저를 '유저2'라고 하겠다.
유저2의 흐름도는 아래와 같다
하지만 유저1의 흐름도에서 생각할 만한 것들이 굉장히 많고 선택지도 많은데
첫번째에서는 클라이언트에서 조직원이 추가 되었다는 체인코드가 실행될 때 클라이언트로 알람 이벤트를 보내고 클라이언트에서 그 알람을 감지하는 형태이다. Hyperledger Fabric SDK 에서는 이 과정을 수월하게 해놓았기에 개발 속도나 난이도는 낮을 것이라고 생각한다.
아래와 같은 형태이다. 이럴경우에는 큰 문제가 발생할 수 있는데 클라이언트의 복잡성을 굉장히 줄일 수 있는 있는 대신에 알람을 감지하고 API 서버에 보낼 수 있는 클라이언트가 1000개 라고 하면 블록체인으로 부터 온 알람 이벤트는 1개 경우에 1000개의 클라이언트가 그것을 감지고 API 서버에 요청을 보낸다면 같은 이벤트인데 1000개의 요청을 받게된다.
이는 굉장히 비효율적인 방식이고 만에 하나 이 방식을 선택하여서 같은 시간에 온 이벤트 중 하나 받게 하는 로직을 만들더라도 클라이언트 -> 서버 -> 클라이언트 -> 서버 -> 블록체인 이런 비효율적인 통신 반복이 일어나므로 선택을 하지 않게 되었따.
두번째에서는 API 서버에서 요청을 받고 클라이언트와 API Server 사이에서는 웹소켓으로 상태를 유지하여서 조직원에게만 알림을 보낼 수 있게하는 방법이다. 웹소켓을 사용해야하고 익숙해져야하는 만큼 개발 난이도는 적당히 있다고 생각한다.
위와같은 방식으로 이루어 지고 Polling 방식도 웹소켓와 통신 방식과 다를 뿐 사실과 둘은 방식은 비슷하므로 따로 Polling 방식에 대해선 기술하진 않겠다. 어찌보면 효율적이고 특정 사람들에게만 알림을 보낼 수 있다는 점에서 장점이 있으나 역시나 큰 단점이 존재한다. 서버에 통신 오버헤드가 연결된 클라이언트 수 가 많이 질 수록 굉장히 커진다는 것인데 세션 유지를 더 편하게 할 방법이 필요했다.
세번째에서는 Redis를 Inmemory DB로 사용하고 이벤트 발행, 세선 유지 오버헤드 감소를 할 수있는 절충안에 대해서 기술하겠다. 이는 Redis의 Pub/sub 을 사용하는 방식으로 유저가 클라이언트에 로그인하는 평균 시간을 TTL로 정한 뒤 캐시에 클라이언트 상태가 있는 클라이언트가 이벤트 채널을 구독하는 방식으로 알람을 주는 방식이다. 이는 서버의 부답을 줄일 수 있을 뿐만 아니라 Redis 사용의 장점을 가져갈 수 있을 것이라고 생각해서 정하게 되었다.
다음과 같은 이점을 얻을 수 있는 서버와 클라이언트 사이의 통신이 한번만으로 이루어 지는것을 볼 수 있다. 이를 통해 서버에 대한 부담을 덜 수있다. 하지만 개발 난이도가 문제라고 생각하는데 이 세가지들의 방법 중 팀원들과의 대화를 통해 절충안이나 한가지를 정해야하는 시간을 가져야 할 것으로 보인다.
학생회를 위한 블록체인 장부 서비스 너무 좋은 것 같아요!