SSAFY 특화 프로젝트 회고록(10기 블록체인 P2P)

탱귤생귤·2024년 4월 8일
0
post-thumbnail

1. 프로젝트 소개

이번 프로젝트에서는 인프라를 맡고 싶어서 인프라&프론트를 담당했다. 블록체인 기반 P2P를 주제로 하는 프로젝트를 골랐다. 블록체인에 대해 매우 기초적인 지식만 있었기 때문에 싸피에서 제공해주는 부트캠프 수업을 들으며 블록체인 프로젝트를 위한 스마트 컨트랙트 개발에 대한 지식을 쌓았다.

‘ArtChain’은 블록체인 기반 공연·전시·영화 조각투자 서비스로, Art와 BlockChain을 합쳐 만든 이름이다. 조각투자 서비스에 블록체인 기술을 도입해 투명하고 조작 불가능한 서비스를 만들었다. 또한, 자체 토큰인 ArtCoin을 만들어 서비스 내에서 사용 가능하다. 다른 투자 서비스에서는 보기 어려운 마켓 기능도 추가해 투자자 간 거래 서비스도 이용 가능하다.

2. 프로젝트 진행과정

2-1. 아이디어 선정

생각보다 아이디어 선정과정이 험난했다. 웬만한 아이디어가 나오더라도 굳이 블록체인을 사용해야 하나? 라는 생각이 들어서 오래 걸렸다. 컨설턴트님이 환전을 하는 거래소 아이디어가 좋다고 말해주셨지만, 현실적으로 어려울 것 같다는 컨트랙트 담당 팀원의 의견에 따라 다시 다른 아이디어들을 냈다. 그리고 결정된 것이 지금의 ArtChain이다.

2-2. 서비스 내용 정리

1. 자체 토큰인 ArtCoin 구매 가능

  • Ethereum 기반 테스트넷인 Sepolia에서 자체 ERC-20 토큰인 ArtCoin 발행
  • 카카오페이를 통해 코인 구매

2. ArtCoin으로 조각 투자

  • 투자기간 동안 ArtCoin으로 자체 ERC-20 토큰인 "조각"을 구매 가능
  • 투자 시 발생하는 트랜잭션 가스비는 테스트 Ethereum으로 지불
  • 실시간 블록체인 컨트랙트 메서드 호출을 위해 Server Sent Event(SSE) 사용해 투자 성공 시 조각 배분 및 정산 시 ArtCoin 배분

3. 구매한 조각으로 마켓에서 투자자 간 거래

  • 투자기간 이후 정산 되기 전 투자한 "조각"을 마켓에서 ArtCoin으로 거래 가능
  • 거래 시 트랜잭션 가스비는 테스트 Ethereum으로 지불

3. 프로젝트 후기

1️⃣ 프로젝트를 통해 얻은 것

  • 인프라 입문

💡 1. EC2, Docker, NginX, Jenkins에 대한 이해
말로만 듣던 배포 4인방이 무슨 역할을 하는 프로그램이고 어떤 작동을 하는 것인지 이해하게 됨. 특히 Docker, NginX에 대해 공부할 때 사용법에 대해 알게됐고 향후 더 발전한 방법을 프로젝트에 적용하고 싶음.
2. 수동 배포와 자동 배포
Jenkins를 이용해서 처음에는 프론트엔드 브랜치를 수동배포했음. Jenkins Script를 처음에는 적는 게 어려웠지만 차근차근 해야하는 단계에 맞춰 스크립트를 작성하니까 Groovy와 bash에 대해서도 배워가며 배포에 대한 이해도를 높일 수 있었음. 한번 스크립트를 완성하니까 자동 배포까지는 무난하게 됐다. 수동 배포에서 브랜치 Webhook만 걸면 자동 배포가 되는 거니까.
3. 무중단 배포
자동 배포를 하고 나니 배포가 될 때마다 서버가 멈추는 것이 불편했기 때문에 무중단 배포에 대해 공부했다. 무중단 배포 방식은 크게 3가지로 나뉘는데, Rolling, Blue/Green, Canary이다. Rolling과 Canary 방식은 구버전과 신버전에 동시에 돌아가기 때문에 호환성 문제가 있을 수 있다고 해서 우선은 무중단 배포가 처음인 나는 안전한 Blue/Green 방식을 택했다. 그리고 Blue/Green 방식의 단점인 리소스 확보에 대한 문제는 우리 프로젝트가 규모가 적어서 싸피에서 제공한 EC2의 서버크기를 넘을 가능성이 적기 때문에 신경쓰지 않았다.
무중단 배포는 처음에는 머리가 많이 복잡했는데, 차근차근 하고 싶은 단계를 나열하고 한 단계마다 해야 하는 것을 적으니까 머리가 정리되며 해결해야 하는 부분에 대해 집중하며 스크립트를 작성할 수 있었다. 그리고 처음에 잘 모를 때는 블로그 글을 마구잡이로 복사해서 사용해봤는데, 설정한 환경이 각자 다르기 때문에 이 분들의 방식을 차근차근 읽고서 우리 프로젝트 환경에 맞는 나만의 방식을 만들어서 스크립트를 작성했더니 무중단 배포에 성공했다.

  • 블록체인 기초 지식

💡 블록체인에 대해 아는 게 없었는데 프로젝트 아이디어를 생각하기 위해 블록체인을 어떤 방식으로 활용하면 좋을 지 생각하기 위해 블록체인이 무엇인지, 어떤 점이 장점이기 때문에 사용되는지, 어떻게 활용되는지에 대해 찾아보면서 블록체인에 대해 알게 됐다.
스마트 컨트랙트를 작성하기 위해서는 Solidity라는 언어를 사용해야 하고, remix같은 곳에서 배포까지 할 수 있다느 것을 알게 됨. 그리고 전자지갑인 MetaMask를 사용하기 위해 우리 도메인을 dApp화를 하며 dApp이 무엇이지도 알게 됨.

  • PortOne API 사용

💡 이번에 처음으로 결제 API를 사용해봤다. 저번 프로젝트 때 시간이 없어 사용하지 못했기 때문에 이번에는 꼭 구현을 해보고 싶었다. 포트원 v2를 쓰려다가 레퍼런스가 더 많은 v1을 사용했다. 포트원 API문서가 잘 작성되어 있어서 기본적인 결제는 빨리 끝낼 수 있었다. 결제 후 스마트 컨트랙트를 호출해야 했는데, 승우님이 미리 작성해준 스마트 컨트랙트 호출 코드를 이용해서 결제 후 구매 코인 정보와 지갑 주소를 보내서 토큰이 민팅된 후 트랜잭션 해시코드를 받았다.

2️⃣ 잘한 점

  • CI/CD
    • Certbot 대신 ZeroSSL 사용
    • 프론트엔드 브랜치를 Blue/Green 무중단 배포
  • P2P 거래
    • 자체 ERC-20 토큰인 ArtCoin을 제작해 서비스 내 화폐로 사용
    • ArtCoin으로 투자 후 투자 항목 별 자체 ERC-20 토큰인 조각을 분배 받음
    • 실시간 블록체인 컨트랙트 메서드 호출을 위해 Server Sent Event(SSE) 사용해 투자 성공 시 조각 배분 및 정산 시 ArtCoin 배분
    • 조각을 투자자들과 스마트 컨트랙트를 활용해 거래 가능

3️⃣ 아쉬운 점

  1. Docker Compose를 제대로 잘 사용하지 못함

    NginX에 대한 정보는 적었지만, Jenkins나 이외의 컨테이너들에 대한 것을 적지 않고 docker-compose.yml을 끝냄. 뭔가 반쪽만 한 느낌

    ⇒ 다음 번에는 웬만한 컨테이너에 대해 써보는 연습을 해보겠음. 특히 볼륨을 유용하게 사용해보고 싶다. 이번에는 bind-mounting을 많이 사용했는데, 볼륨이 더 안정적이라니까 볼륨으로 처리하고 싶다.

  2. SSL 인증서를 Certbot에서 받지 못한 것

    계속해서 Certbot으로 인증서 받는 것이 오류가 나서 결국에는 ZeroSSL을 사용했음. 많이들 쓰는 인증서 발급 사이트이기 때문에 Certbot으로 성공하고 싶었는데…재신청 기간이 5일이나 걸려서 기다릴 수 없어서 포기했다.

    ⇒ Certbot 다음에는 해봐야지 뭐,,,

  3. K8S를 못해본 것

    이번에 처음하는 인프라 작업이기 때문에 각 기본 요소들을 알아가는 게 우선이라고 생각해서 우선 쿠버네티스는 제외하고 배포를 했다. NginX+Jenkins로도 무중단 배포를 했기 때문에 다음에는 쿠버네티스로 해보고 싶다.

    ⇒ 다음에는 하면 됨

4️⃣ 트러블 슈팅

NginX

1. Certbot으로 SSL 인증서가 받아지지 않음

이런 에러가 떴다. 이유를 확정할 수 없지만 나의 추측은 certbot 버전때문이라고 생각한다. 문제는 횟수 제한이 있는 줄 모르고 우리 도메인에 SSL받는 커맨드를 5번 날려버려서 5일동안 인증서를 받지 못하게 된 것이다. 그래서 ZeroSSL로 인증서를 받았다.

2. EC2내의 NginX와 Docker의 NginX와의 혼동

NginX reverse proxy를 설정할 때 계속해서 오류가 났었는데, 알고보니 설정파일을 작성할 때 EC2의 NginX와 Docker의 NginX를 구별하지 못했기 때문에 오류가 났던 것이었다. 나는 Docker의 NginX만 사용했는데, 자꾸 EC2의 것의 파일을 수정하니 원하는 대로 NginX가 바뀌지 않았던 것이다. 이유를 알게 된 후에는 수정할 부분을 정확히 알고서 파일을 재작성했다.

3. NginX reverse proxy 설정 시 no resolver defined to resolve 에러

기본 uri를 Jenkins uri로 포워딩할 때 일어난 에러다.

 location / {
        proxy_pass $service_url;
        #root   /usr/share/nginx/html;
        proxy_redirect off;
        #index  index.html index.htm;
        charset utf-8;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

    }

default.conf를 이렇게 작성을 했는데 났다. url을 외부 파일에서 변수화해서 받아오는 방식이다. 문제는 proxy_pass를 변수로 받으면 nginx의 기본 built-in resolver로 연결을 하기 때문에 resolver가 없다고 뜨는 것이었다. 때문에 resolver 1.1.1.1; 를 추가해서 해결해줬다.

location / {
        resolver 1.1.1.1;
        proxy_pass $service_url;
        #root   /usr/share/nginx/html;
        proxy_redirect off;
        #index  index.html index.htm;
        charset utf-8;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

    }

4. https에 웹소켓 연결되지 않은 오류

도메인을 켜면 잘 작동은 하지만 이런 에러창이 콘솔에 떴다.

처음에는 밑 부분의 hmr때문에 문제가 있는 줄 알고 그 부분을 고쳐봤지만, 해결되기는커녕 오히려 무한 로딩이 되며 악화됐다. 하지만 팀원들과 찬찬히 보니 웹소켓이 wss에 연결되지 않는 것이 문제였다. 때문에 nginx 설정파일에서 웹소켓 연결 관련 설정문을 추가로 적어주었다.

	#Websocket Setting
	proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

이것을 적는 이유는 HTTP에서 WebSocket으로 연결을 할 때 업그레이드 및 연결 헤더를 사용함. 그래서 NginX는 클라이언트의 Upgrade요청을 Upgrade하고 Connection 헤더를 Upgrade로 명시적으로 설정하는 것임

Metamask

1. 메타마스크- 모바일 웹 연동

모바일 웹에서 메타마스크를 연동하지 못해서 우리 도메인을 dApp화를 해야했다. https://metamask.github.io/metamask-deeplinks/ 에서 디앱 링크 생성 후 연결

0개의 댓글