Journal Archive

그림 3은 제안하는 회원가입 및 로그인 절차이다. 소비자는 상품조회만 가능하면 되기 때문에 꼭 회원가입이 필요하지 않지만, 생산자는 상품을 등록하고, 배송업체는 배달할 상품을 선택하여 배송출발 및 완료와 같이 상태정보를 수정해야 하며, 담당자 정보가 필요하므로 회원가입 및 로그인 절차가 필요하다. 생산자와 배송업체는 DApp을 통해 회원가입을 하면 회원 정보를 키 값 형태로 변환하고 AMB의 하이퍼레저 패브릭에 데이터유형에 맞게 블록 형태로 저장을 한다. 로그인시, 사용자는 아이디와 비밀번호를 입력하여 EC2서버에 전달하면, 대응되는 키 값의 요청주소로 데이터를 요청하여 입력한 데이터와 블록의 값을 비교하여 일치하였을 시, 유효한 접근으로 보고 로그인을 허용한다.

Fig. 3. 
Distributed ledger based join and login procedure

그림 4는 제안하는 상품 등록 절차이다. 생산자가 DApp을 통해 로그인 후 상품을 등록하면, 상품 데이터가 회원가입 및 로그인 절차와 동일하게 키 값으로 변환되어 하이퍼레저 패브릭에 블록 형태로 저장 한다. 로그인 절차와 마찬가지로 DApp을 통해 상품 정보를 요청했을 경우 키 값에 해당되는 요청 주소로 하이퍼레저 패브릭에 블록 값을 검색하게 되며, 해당 값을 회신받은 DApp은 화면을 갱신하여 상품 정보를 보여준다.

Fig. 4. 
Distributed ledger based registration procedure

그림 5는 제안하는 상품선택, 배송출발 및 완료 절차를 보여준다. 배송업체가 DApp에 로그인 하면 EC2서버가 배송되어야 할 상품 목록을 제공한다. 상품 목록에서 본인이 배달할 상품들을 선택하고, 배송 출발 버튼을 누르면 바로 다음 페이지에서 선택한 상품목록 정보를 제공하고, Maria DB에 저장된 해당 상품의 상태정보 값을 false에서 true로 변경한다. 이 정보가 변경되면 해당 상품에 부착된 IoT 센서노드에 연결된 온습도 센서가 동작을 시작하며 시간, 온도, 습도 및 이상여부 데이터를 Maria DB에 지속적으로 업로드 한다. 배송업체가 배달을 완료했을 경우, DApp의 배송 완료 버튼을 누르면 Maria DB의 상품 상태정보 값이 다시 false로 바뀌고 IoT 센서노드의 온습도 센서가 동작을 멈춘다.

Fig. 5. 
Distributed ledger based delivery select and complete procedure

그림 6은 제안하는 소비자 조회, 배상문의 절차이다. 소비자가 주문번호로 EC2 서버에 상품 조회 요청을 하면, 주문번호와 일치하는 상품의 상태 블록 값을 하이퍼레저 패브릭에서 가져와 제공한다. 배상문의 프로시저는 상품에 문제가 생겼을 시, 배상 문의 버튼을 누르면 EC2 서버가 해당 상품의 상태정보 중 이상여부를 나타내는 필드가 true인 데이터를 하이퍼레저 패브릭에 요청하여 그와 관련된 상품 데이터 및 담당자의 데이터를 DApp에 제공한다. 사용자는 자신의 상품에 이상상황이 발생한 데이터가 존재한다면, 제공받은 담당자 연락처를 통해 배상을 요청할 수 있다.

Fig. 6. 
Distributed ledger based delivery tracking and compensation procedure

그림 7은 제안하는 실시간 조회 절차 이다. 소비자가 실시간 조회를 요청했을 시, 온습도 센서와 마찬가지로 GPS 센서가 동작을 시작하며 위도, 경도 데이터를 Maria DB에 업로드한다. EC2 서버는 Maria DB에 저장된 위치 데이터들을 하이퍼레저 패브릭에 블록형태로 저장을 하고, 실시간 조회 요청이 들어왔을 때 EC2 서버가 이 정보를 하이퍼레저 패브릭에서 조회하여 DApp을 통해 사용자에게 알려준다.

Fig. 7. 
Distributed ledger based delivery tracking and location update procedure

AMB에서 지원하는 하이퍼레저 패브릭 프레임워크는 프라이빗 체인 네트워크 이므로 이를 선택하기 위해 먼저 블록체인 네트워크 배너의 ‘프라이빗 네트워크 생성’ 을 선택한다. 프라이빗 네트워크 생성을 위해서는 블록체인 프레임워크 버전, 네트워크 에디션, 네트워크 이름 및 설명, 투표 정책, 멤버 구성, 하이퍼레저 패브릭 Certificate Authority(CA), 로깅등을 설정한 후 ‘네트워크 및 멤버생성‘ 을 선택한다.

그림 9는 위와 같은 방법으로 생성된 네트워크의 세부 정보 화면이다. 생성된 네트워크의 ID, Amazon Resource Number(ARN), 합의를 위한 투표 정책 VPC 엔드포인트, 서비스 엔드포인트 및 프레임워크 버전 등의 다양한 세부 정보를 제공하고 있다[14].

Fig. 9. 
Detail information of AMB based private network

프라이빗 네트워크는 허용된 대상만을 네트워크를 구성하는 멤버로 인정하므로 여러 노드를 포함하는 네트워크를 구성하기 위해서는 블록체인 네트워크의 멤버를 추가해야 한다.

기존에 생성된 네트워크를 선택하면 네트워크 세부정보, 멤버정보, 제안구성 등의 기능이 제공된다. AMB 네트워크 세부 설정 화면에서 ‘멤버’ 버튼을 선택하여 다른 멤버를 추가하기 위한 초대 제안을 생성한다.

그림 10은 초대 제안을 생성하는 화면으로 AWS 계정 ID 입력 필드에 초대할 상대의 12자리 계정 ID를 입력하여 현재 생성한 네트워크로 상대방을 초대할 수 있다.

Fig. 10. 
Add member for AMB based Blockchain network

초대를 받은 계정에서 AMB 서비스 화면 우측의 초대 메뉴를 선택하면, 그림 11과 같이 현재 초대받은 네트워크의 정보를 확인할 수 있다. 여기서 초대 수락 버튼을 통해 아주 간단하게 해당 프라이빗 네트워크에 멤버로 참여할 수 있다.

Fig. 11. 
Member invitation accept for AMB based Blockchain network

멤버가 추가되면 네트워크를 구성할 피어노드를 생성해야 한다. 그림 12는 AMB 네트워크의 멤버 구성을 확인하는 화면으로 피어를 생성할 특정 멤버를 선택하여 간단히 피어노드를 생성할 수 있다.

Fig. 12. 
AMB Network member configuration details

그림 13은 피어노드 생성을 위한 단계를 보여준다. 먼저 해당 노드가 작동할 인스턴스 유형을 선택한다. 본 논문에서는 bc.t3.small 타입의 인스턴스를 선택하였다. AWS는 다양한 프로세서, 스토리지, 메모리 등의 조합으로 이루어 진 500개가 넘는 인스턴스를 제공한다. 이를 통해 범용 타입 뿐만 아니라 컴퓨팅, 메모리, 가속화, 스토리지 등에 최적화 된 인스턴스를 용도에 맞게 선택하여 활용할 수 있다. bc.로 표기된 인스턴스는 블록체인에 최적화된 인스턴스로 범용 모델인 T3타입, 인텔 제온 프로세서 기반의 범용 모델인 M5타입, 컴퓨팅 워크로드에 최적화된 C5 타입을 제공하고 있으며, bc.t3.small은 이중 가장 저렴한 타입으로 2개의 vCPU를 지원하며 2GB의 메모리를 탑재하고 있다. 인스턴스의 성능 및 용량이 높을수록 단위시간당 사용료 역시 높아진다[15].

Fig. 13. 
AMB peer node creation

결과적으로 멤버당 하나의 피어노드를 구성하여 그림 14와 같은 하이퍼레저 패브릭 네트워크를 클릭 몇 번을 통해 매우 손쉽게 구성하였다.

Fig. 14. 
AMB based Hyperledger fabric network configuration

먼저 DApp 서버용 EC2 인스턴스를 생성한다. AWS는 Linux, Linux2, Ubuntu, Windows, MacOS 등 다양한 Amazon Machine Image (AMI)를 제공한다[16]. 본 논문에서는 DApp 서버의 OS로 Linux2를 사용할 예정으로 인스턴스 생성 단계에서 프로젝트에 알맞은 AMI를 선택한다. 또한 인스턴스 타입, 보안 그룹, 인스턴스 세부정보, 스토리지, 태그를 설정하고 인스턴스를 생성한다. 해당 인스턴스는 DApp 클라이언트를 지원해야 하므로 보안 그룹 설정 시 반드시 HTTP, HTTPS 및 사용자 TCP/IP 포트를 추가한다. 그림 15는 이처럼 생성된 DApp 서버 인스턴스의 요약 정보를 보여준다. 생성된 EC2의 퍼블릭 DNS는 SSH로 EC2에 접속하거나 EC2가 서버로 구동시 DApp의 접속 주소가 된다.

Fig. 15. 
DApp server instance creation result

DApp 서버 인스턴스가 생성되었다면 라이브러리 설치를 위해 해당 EC2에 SSH로 접속한다. 이는 인스턴스 생성시 제공된 AWS-keypair 파일인 .pem파일을 통해 허가된다.

본 논문에서는 백엔드를 위해 16.x 버전의 Node.js를 설치하였고 프론트 단을 위해 Vue.js 를 설치하고 Webpack을 포함한 Vue 프로젝트를 생성한다[17]. $vue init webpack frontend 설치 명령에서 vue-router를 yes로 설정한다.

또한 HTTP 통신, 세션관리 등을 위해 Express.js를 설치하고 $express backend --view=pug backend 명령을 통해 Express프로젝트를 생성한다[18].

다음으로 EC2의 퍼블릭 DNS로 프로젝트의 결과를 출력하기 위해 백 엔드 디렉토리 안에 있는 app.js를 수정하여 listen 포트 번호를 설정한다. 또한 node.js 수정내용을 반영하기 위해 package.json파일의 start의 값을 “nodemon app.js”로 수정한다. 설정이 모두 끝났다면 백 엔드 디렉토리에서 $npm start 명령어로 서버를 구동할 수 있다.

Vue.js와 Express.js는 각각 프론트 엔드와 백 엔드의 기능을 수행한다. 따라서 Vue.js에서 만들어진 프로젝트는 $npm run build를 통해 node.js파일로 변환되어 Express.js의 public경로에 생성되고 Express.js는 이 파일을 가지고 서버를 구동한다.

또한 프론트 엔드와 백 엔드 모두 동일한 모듈을 가지고 있어야 프론트 엔드에서 빌드를 했을 때 백 엔드에서도 정상적으로 구동이 가능하다. 본 프로젝트에서는 프론트에서 vue2-google-maps, axios, mysql module을 사용하기 때문에 연동을 위해 다음 명령어를 각각의 폴더에서 실행하여 모듈을 설치한다.

• $sudo npm install vue2-google-maps
• $sudo npm install axios --save
• $sudo npm install mysql –save

본 서버는 Node.js 기반으로 다음과 같은 기능들을 REST API 형태로 제공한다.

• - blocklistener.js : 하이퍼레저 패브릭 네트워크 상에서 일어나는 블록 관련 이벤트 수신 기능 제공
• - connection.js : 현재 사용자가 하이퍼레저 패브릭 네트워크의 인증기관에 등록된 사용자인지 확인하고, 네트워크와 클라이언트를 연결
• - invoke.js : 블록체인 네트워크에 체인코드 제안을 전송
• - query.js : 블록체인 네트워크의 데이터를 쿼리
• - app.js : 배송서비스를 위한 사용자 등록 및 서비스 기능 제공 (하이퍼레저 패브릭 네트워크 인증기관에 사용자 등록, 생산자 및 사용자 코드 목록 반환, 특정 사용자 정보 및 주문 정보 질의, 배송 정보 및 IoT 센서노드로 부터 수집된 이상상황 데이터 업데이트)

AWS 데이터베이스 시스템 역시 다른 컴퓨팅 리소스와 동일하게 몇 번의 클릭만으로 구축이 가능하다. RDS는 AWS의 데이터베이스 시스템으로 EC2 생성과 동일하게 AWS 콘솔에서 생성한다. AWS 서비스 의 RDS 페이지에 접속하여 데이터베이스 생성을 클릭하면, 제원하는 데이터베이스 엔진을 선택할 수 있다[11]. 본 논문은 MariaDB를 선택하였으며, 데이터베이스 이름, 접속 계정 정보, 암호정보 등을 설정한다. 해당 데이터베이스 시스템이 배치될 VPC를 선택하고, 타 환경의 접속을 허용하기 위해 퍼블릭 액세스로 설정한다.

그림 16은 AWS의 RDS 인스턴스를 생성한 결과로, MariaDB 엔진을 사용하며, dapp-db 라는 이름으로 생성되었음을 확인할 수 있다. 외부 접속 허용을 위해 퍼블릭접근이 허용되었으며, 엔드 포인트 값을 통해 접속이 가능하다. 또한 생성할 때 입력한 마스터 사용자 이름 및 암호로 인증 후 접속할 수 있다.

Fig. 16. 
Database system creation result

하이퍼레저 패브릭 네트워크는 거래를 처리하기 위해 체인코드를 활용한다. 아래는 본 논문에서 정의한 체인코드를 설명하고 있다.

• - queryByKey : 특정 데이터 쿼리를 위한 체인코드로 데이터를 쿼리하는데 필요한 키(ex:orderID)를 전달받아 블록체인 네트워크에서 해당하는 데이터를 가져온다.
• - queryByString : 특정 데이터로 구분되어있는 데이터들을 모두 가져온다. (ex: 모든 주문 쿼리)
• - createProducer : producerID를 키로 생산자 데이터를 생성한다. 만약 네트워크에 해당 키의 데이터가 존재하면 중복 에러를 반환한다.
• - queryProducer/queryAllProducers : 특정 생산자 혹은 모든생산자 정보를 쿼리한다.
• - createCourier : 생산자 데이터 생성과 마찬가지로 배송자의 CourierID를 통해 데이터를 생성한다.
• - createOrder : 주문 데이터를 생성하며 성공시, 등록완료 상태정보와 등록 시간을 추가한다.
• - updateOrder : 주문의 배송상태와, 해당 주문의 배송 담당자의 정보를 업데이트한다.
• - createState : IoT데이터를 통한 물품의 상태 데이터를 생성한다. 이전 데이터를 덮어쓰지 않도록 배열 형태로 추가하고, 네트워크에 먼저 등록된 IoT 상태 데이터를 쿼리하여 추가할 IoT 상태 데이터와 병합하여 등록한다.

그림 17은 위에서 설명한 체인코드를 활용하여, 생산자 정보를 블록에 등록한 결과이다. REST API 형태로 호출된 createProducer 체인코드는 전달받은 생산자의 정보를 블록에 추가하며, 해당 트렌젝션은 7번 블록의 첫 번째 트렌잭션이며, 해당 요청이 성공적으로 등록되었음을 확인할 수 있다.

Fig. 17. 
Chain code based creator information update result

그림 18은 AWS 클라우드를 기반의 센서 데이터 수집 절차를 보인다. 라즈베리파이에서 수집되는 센서 데이터는 그 수집 간격이 매우 짧고 데이터 양이 많아 이를 직접적으로 AMB의 블록체인 네트워크에 적용하기는 효율적이지 않다. 따라서 본 논문에서는 센서노드에서 수집된 환경 데이터를 AWS의 데이터베이스 시스템인 RDS를 활용하여 1차적으로 저장한다. 이후 4-2장 및 4-3장에서 소개한 EC2 서버를 통해 중요 데이터를 AMB의 블록체인 네트워크에 저장한다.

Fig. 18. 
Cloud based sensor data collection procedure

그림 19는 제안하는 IoT 센서 노드의 환경정보 수집 및 전송 절차를 보이고 있다. 센서 노드는 온습도 센서를 통해 현재 상품이 노출되어 있는 온습도 정보를 수집하고 상품의 이상 상황을 판단하는 PBdata()함수를 통해 상품 상태값을 수집한다. 이후 GPS 센서를 통해 상품의 위치 정보를 수집한다. $GPGGA 값을 통해 실제 위치정보가 수집되지 않았다면 다시 센서 데이터 수집 단계를 반복한다[19]. 위치데이터가 유효하면 RDS의 MariaDB에서 현재 상품의 배송상태를 확인한다. 만약 해당 상품이 배송중이 아닐 경우, 실 데이터 전송은 하지 않고 대기하게 되며, 배송중일 경우 RDS에 배송상태, 날짜, 시간, 온도, 습도, 위치 데이터를 전송한다.

Fig. 19. 
Environmental information collecting and transmitting procedure of sensor node

앞서 설명한 것처럼, IoT 센서 노드는 상품의 이상 여부를 주기적으로 판단한다. 식품같이 신선도가 있는 상품의 경우 온도와 습도가 일정 범위내 유지가 된 상태에서 배송되야 하기 때문에 그 온도를 벗어난다면 배송 과정 중 상품의 변형이 생길 수 있고 이로 인해 상품의 문제가 발생했다고 볼 수 있다. 추가적으로 가속도 센서 등을 활용하면, 배송중 충격에 의한 파손 이벤트를 감지할 수도 있다.

그림 20은 상품의 이상상황을 판단하는 절차를 보인다. 본 실험에서는 간단히 온습도의 정상 범위를 초과했을 때 이상상황에 노출된 것으로 구성하였다. 배송되는 상품의 종류에 따라, 온습도의 정상 범위 및 이상 상황 노출 시간 등 여러 조건을 추가할 수 있다.

Fig. 20. 
Product abnormality determination procedure

그림 21은 본 연구에서 수행한 배송추적 실험을 보여준다. 배송할 제품을 식품으로 간주하고 온습도 유지를 위해 스티로폼으로 정사각형의 박스를 제작하였다. 보온력 증대를 위해 상자 내부에 일정 공간을 두고 2차 상자를 제작하여 부착했으며, 용이한 실험을 위해 투명한 아크릴로 내부를 볼 수 있도록 하였다. 상자의 상단부에는 라즈베리파이 센서 노드를 부착하였고, 온습도 센서는 상자 내부 뚜껑부분에 설치하였다. 그림 21의 오른쪽은 해당 상자를 들고 실제 실외로 이동하면서, GPS 센서 데이터 수집을 테스트 하는 장면이다. 해당 실험 결과는 그림 26, 27과 같이 DApp을 통해 사용자가 배송중 이상여부를 판단하고 추적 결과를 확인 할 수 있다.

Fig. 21. 
IoT Sensor node based delivery tracking experimental environment

그림 23은 본 논문에서 구현한 DApp의 주요 기능 중 로그인 및 회원가입 기능을 보인다. 앞서 설명한 바와 같이, 생산자 및 배송자는 자신의 생산한 상품 또는 배달할 상품에 관한 관리 기능이 요구되므로, 회원가입 기능을 제공한다. ID, 이름, 비밀번호, 연락처를 입력받아 회원가입을 진행한다.

Fig. 23. 
Login and sign-up

로그인을 할 때는 회원가입시 저장한 값과 비교 후 일치하면 로그인을 허용한다.

그림 24는 상품 등록 및 주문내역 확인 기능의 구현결과를 보인다. 생산자는 상품 등록을 위해, 상품명 및 해당 상품을 주문한 소비자 정보를 입력하며, 오른쪽 화면과 같이 주문 상세 내역을 확인할 수 있다.

Fig. 24. 
Product registration and order

그림25는 배달상품 선택 및 배송중 상품 목록 기능을 보여준다. 배송자는 로그인시, 자신이 배달할 상품을 선택할 수 있다. 자신이 배달할 상품을 선택 후 배송출발 버튼을 누르면 IoT에 연결된 온습도 센서가 켜지면서 배송 상황 데이터 값이 Maria DB에 올라간다. 배송이 완료된 경우 특정 상품을 선택하고, 배송완료 버튼을 누르면, 해당 배송건에 대한 IoT 센서노드가 동작을 멈춘다.

Fig. 25. 
Delivery product select and delivery list

소비자는 배송업체가 자신에게 배송중인 상품의 배송 조회기능을 통해 상품의 상태를 실시간으로 확인할 수 있다.

만약 이상 여부가 true인 값이 있다면 상품의 품질에 악영향을 미칠 수 있는 상황이 발생한 것이다. 서비스는 배상문의 증명서를 통해 문제가 생긴 상품의 객관적 손해 및 파손 등의 책임소지 확인을 위한 각종 정보를 제공한다.

Fig. 26. 
Delivery tracking and compensation procedure

소비자가 주문번호로 상품조회를 하고 실시간 조회 기능을 선택하면, GPS 센서가 생성한 위치정보를 Maria DB에서 질의하여, 그림 27과 같이 구글 지도를 기반으로 현재 상품의 위치를 보여준다.

Fig. 27. 
Real-time delivery tracking