Harvey's TechNote

개인적으로 파이프라인을 구축하는 학습을 하며 쿠버네티스에 대한 전반적인 개념 정리가 필요할 듯하여 해당 글을 작성했습니다.

Kubernetes (K8s)는 컨테이너 관리 시스템으로, 여러 개의 컨테이너를 효율적으로 운영하고 관리하기 위한 플랫폼입니다. Kubernetes의 주요 목적은 클러스터에 정의된 “상태”를 지속적으로 유지하는 것입니다. 즉, 컨테이너가 중단되거나 상태가 변경될 경우, Kubernetes가 자동으로 이를 감지하고 원래의 정의된 상태로 복원합니다.

Kubernetes의 주요 개념

클러스터 (Cluster)

• 정의: 여러 노드(Node)의 집합입니다.
• 역할: 클러스터는 컨테이너화된 애플리케이션을 실행하기 위해 필요한 자원을 제공합니다.

Control Plane

• 정의: Kubernetes의 작업을 처리하는 구성 요소들의 집합입니다. 주요 구성 요소에는 etcd, Scheduler, API Server 등이 포함됩니다.
• 역할: 클러스터의 상태를 유지하고 관리합니다. Control Plane은 클러스터 내에서 반드시 실행됩니다.

노드 (Node)

• 정의: 물리적 하드웨어 또는 그 위에서 실행되는 가상 머신을 의미합니다.
• 역할: 컨테이너가 실행될 수 있도록 자원을 할당하는 역할을 합니다. 노드 중 하나는 Master Node로 간주되며, 이 노드는 Control Plane의 핵심 구성요소입니다. 일반적으로 Master Node는 클러스터의 API 서버, 스케줄러, 컨트롤러 매니저 등의 역할을 포함합니다.

Control Plane 구성 요소

1. etcd
   • 역할: 클러스터의 상태를 유지하는 key-value 저장소로, 모든 클러스터 데이터의 지속성을 보장합니다.
2. Scheduler
   • 역할: 클러스터에서 수행해야 하는 작업의 일정을 관리하여, 각 Pod이 적절한 노드에서 실행되도록 합니다.
3. Controller Manager
   • 역할: 클러스터의 상태를 모니터링하여, 정의된 상태가 유지되는지 확인합니다.
4. API Server
   • 역할: kubectl을 통해 들어온 명령을 실행하고 etcd를 업데이트하는 REST API를 제공합니다. kubectl과의 통신은 실제로 이 API Server와 이루어집니다.

Node 구성 요소

1. kubelet
   • 역할: Control Plane과 Node 간의 통신을 담당하며, Node에서 실행되는 Pod과 컨테이너를 관리합니다.
2. Container Runtime
   • 역할: 컨테이너를 실행하는 환경을 제공합니다. 예를 들어, Docker가 이에 해당합니다.
3. kube-proxy
   • 역할: 컨테이너, Pod 및 노드 간의 통신을 가능하게 합니다.

Kubernetes 객체

1. Pod

• 정의: 실행할 이미지의 래퍼(wrapper)로, 애플리케이션 컨테이너와 공유 자원(볼륨, 네트워크 등)의 그룹을 의미합니다.
• 역할: Pod yaml 파일을 통해 실행할 컨테이너의 이름, 사용할 이미지, 초기 및 최대 메모리 등을 정의합니다. Pod을 kubectl을 통해 생성하면 실제 Node에서 Pod이 실행됩니다.

2. ReplicaSet

• 역할: 동일한 여러 Pod이 동시에 실행되도록 관리합니다.

3. Deployment

• 역할: ReplicaSet 이후에 소개되었으며, ReplicaSet과 동일한 기능을 제공하면서 추가 기능을 제공합니다. 내부적으로는 ReplicaSet이 동작합니다.
• 내부적으론 ReplicaSet이 동작합니다

4. Service

• 정의: Pod에 접근하기 위한 안정적인 주소(IP Address)를 제공합니다. Pod가 다시 생성될 때마다 주소가 변경되기 때문에 Service가 필요합니다.
• 유형:
  • ClusterIP Service: 클러스터 내에서의 접근을 제공합니다.
  • NodePort Service: 클러스터 외부에서 접근할 수 있도록 합니다. NodePort의 범위는 30000에서 32767입니다.

5. Namespace

• 역할: 클러스터가 많아질 때, 목적에 따라 그룹화할 수 있도록 도와줍니다. 예를 들어, 개발 환경을 분리하거나 팀별로 애플리케이션을 그룹화할 수 있습니다. Namespace를 지정하지 않으면 자동으로 “default” Namespace가 사용됩니다.

정리

Kubernetes는 클러스터에서 컨테이너의 상태를 유지하고 관리하는 도구이다.
Kubernetes는 비교적 대규모 분산 애플리케이션을 효율적으로 관리하는 데 유용하다.

모듈형 블록체인

블록체인 트릴레마

확장성 : 블록체인이 얼마나 많은 트랜잭션을, 얼마나 빠르게 처리할 수 있는가?

탈중앙성: 특정 집단이 통제하는 것이 아닌 서로 다른 개별 참여자들이 합의를 통해 네트워크를 운영 및 관리할 수 있는가?

보안성:네트워크에 대한 공격으로부터 블록체인에 기록된 정보 및 자산을 안전하게 지킬 수 있는가?

"탈중앙성을 높이려 하면 확장성이 저하되고, 확장성을 높이려 하면 탈중앙성과 보안이 위협받는다."

기존 블록체인의 문제인 트릴레마에 대하여 모듈형 블록이 기존 체인과는 다른, 새롭고 흥미로운 방식을 제안한다.

기존의 모놀리틱 블록체인

모놀리틱 블록체인 구조란 기존 블록체인의 합의, 연산, 세틀먼트, 데이터 가용성(DA)을 같은 장소, 하나의 Layer1에서 전부 처리하는 것을 의미한다. -> 체인의 각 노드들, 즉 검증인들이 합의, 실행, 세틀먼트 , DA까지 모든 역할을 수행하게 되므로 확장성을 확보하는 과정에서 개별 유저들이 검증인으로 쉽게 참여할 수 있을 만큼 요구되는 검증인의 진입장벽이 높아지고 트릴레마 중 탈중앙성이 훼손된다. 빠른 연산을 위해 고가의 CPU나 블록 사이즈를 늘리기 위해 대용량의 RAM, SSD 등이 요구된다.

트릴레마 극복을 위한 이더리움 롤업 솔루션

확장성을 높이기 위한 롤업 솔루션, Layer2

이더리움은 노드의 수가 많아서 탈중앙성과 보안성은 뛰어나지만 수가 너무 많은 관계로 트랜잭션의 속도가 느려지고 수수료가 많이 증가해서 확장성 면에서 큰 문제를 맞이하고 있었다. -> 현재 Rollup 솔루션이 메인스트림으로 남아있다.    

롤업솔루션이란 별도 Layer2에서 트랜잭션 처리를 담당하는 연산 기능만을 수행하고 이 연산 결과를 시퀀서라 부르는 노드가 그 트랜잭션 정보들과 이로 인해 변화된 블록 상태 값들을 모아서 하나의 압축된 형태로 Batch로 묶는다. 그것을 이더리움 메인 넷인 Layer1에 제출하고 블록으로서 기록하게 된다. 이렇게 압축된 Batch에는 하나의 트랜잭션 정보만 들어가는 것이 아니라 대량의 트랜잭션 정보가 하나의 블록으로 묶여있어서 여러 트랜잭션을 한 번에 처리하는 효과를 만들어 보다 저렴하고 빠른 거래를 가능하게 함으로써 확장성 문제를 어느 정도 해결하게되었다. 하지만 이럼에도 트릴레마를 완벽하게 해결할수 없었던 이유는 확장성 부분은 어느정도 해결했지만 Layer2 자체가 어차피 트랜잭션을 빠르게 처리하기 위해서 결국 Layer1의 검증인 셋이 아닌 Layer2에서도 높은 하드웨어를 지닌 검증인들을 모집하게 되면서 결국 탈중앙성을 훼손하게 되었다.

모듈형 블록체인

모듈형 블록체인은 기존과는 달리 합의, 연산, 셔틀먼드, DA 이 4개의 Layer를 블록체인의 기능으로 구분하고 각각의 Layer에 맞는 블록체인을 각각 개별 하여 서로 유기적으로 상호작용하는 것을 목표로 하였다. 이런 모듈형 구조는 새로운 블록체인을 개발함에 있어서 처음부터 개발하는 것이 아니라 다른 솔루션의 모듈을 기반으로 개발할 수 있다는 장점이 있고 모듈을 기반으로 개발되었지만 독립적인 자주권을 갖는 별도의 블로체인이 될 수 있다. 모놀리틱 블록체인이 갖는 장점이었던 독립성, 자주성과 이 모듈들을 공유하는 블록체인 간의 통신을 이용한 상호운용성을 갖는다. 이러한 점을 바탕으로 모듈형 블록체인은 기존 블록체인이 넘지 못했던 블록체인 트릴레마를 해결할 수 있을 것으로 기대받고 있다.

모듈형의 시작은 지금부터

모듈러 블록체인 자체가 아직 개념조차 형성된 지 얼마 되지 않은 상태이다. 모듈형 블록체인이 처음 제안되었을 때에는 기본적인 합의, 연산, 세틀먼트, DA로 나뉘었지만 최근에는 더욱 다양하게 모듈형 스택이 나뉘고 발전되고 있다.

나이트크로우 글로벌과 CROW 토크노믹스 - 정찬홍

나이트크로우의 특징

• Token: 멀티 토크노믹스 채택을 통한 총 7개의 토큰, 이 중 "Crow"토큰이 기축통화로서 핵심 역할을 한다.
• LV 45 이상 달성 시 토큰 민팅 가능. LV 50 이상 달성 이후 캐릭터 NFT화 가능 -> 최소 1개월 소요
• Omnichain: 위믹스 이외 BNB, Polygon, Kroma, Avalanche, Ethereum 체인 지원

찬홍 님의 생각: WEB2 게임의 관점에서 본 "BM모델"에 대해서는 매우 괜찮은 게임이나 WEB3게임으로서는 결국 P2E 및 "BM모델"의 한계를 극복하지 못했다고 생각한다.

핵심은 게임 내에서 얻을 수 있는 재화인 "CROW" 토큰이다. Crow는 $0.75가 넘어가야만 Minitng이 될 수 있도록 시스템이 구축되어 있다. $0.75가 될 때마다 유저들이 Crow를 Minting 하기 때문에 0.75$를 넘어가지 않는 기간이 길다.

찬홍 님이 생각하시는 문제점 -> 게임사에선 인게임 상점을 통해 사용자들에게서 이익을 , 유저들은 Crow 판매를 통해 이익을 보려 하는 구조에서 Crow 소각처가 부족해지는 현상이 나타난다. 이를 해결하기 위해선 온 - 오프라인 토근 사용처 Building이 중요하다. 

CROW 거래는 PNIX에서 WEBIX 3.0 네트워크상에서만 가능해서 CROW(Kroma) -> CROW(WEMIX)로 SWAP 해야 한다.(다른 체인에서 굳이 민팅 할 이유가 없다.)

아직까지 진짜  WEB3 게임을 대표하는 게임이다 라고 할 정도의 게임은 나오지 않은듯 하다. 하지만 곧 WEB3를 대표할만한  의미있는 게임이 나오지 않을까 기대해본다.

https://www.youtube.com/@blpas

Web3 Community - 박민 님

WEB1/WEB2/WEB3 커뮤니티의 차이 

- WEB 1.0

중앙화된 기업, 집단을 사용자들이 단순 사용하는 콘텐츠이다.  사용자가 콘텐츠들을 읽는 형태. ex) 블로그나 CNN , 각종 언론사들

- WEB 2.0 

중앙화된 기업이 플랫폼들을 제공하면 참여자들이 자신들의 글이나 사진, 동영상 등을 통해 컨텐츠를 퍼블리싱하고 이를 다른 참여자들이 함께 상호작용하며 참여한다. ex) 페이스북, 인스타그램 , 유튜브 등

이러한 플랫폼들이 Web2.0에 머무를수밖에 없는 이유 : 플랫폼 제공자라는 거대 기업이 중앙에 있기 때문 

- WEB3.0

중앙화된 집단이나 기업이 아니라 사용자, 참여자들의 직접적인 연결을 통해 생태계가 이어지고 운영이 된다.

WEB3.0을 처음 얘기했던 Gavin Wood는 다음과 같이 말했다.
"Web1 : Read, Web2: Read-Write, Web3: Read-Write-Own"

WEB3 Community의 정의

 Decentralized-탈중앙성, Permissionless -개방성, Native Payments-자산이동의 편의성, Trustles - (비)신뢰성(신뢰성을 바탕으로 기업에 맡기거나 하는 것이 아니라 신뢰 자체가 필요 없다.)이 전체 Web3 Community의 중요한 구조적 틀이다.

Web2의 중앙 집중식 프레임워크에서 Web3의 분산 영역으로의 패러다임 전환은 단순한 기술적 도약이 아니다. 이는 디지털 커뮤니티가 디지털 세계를 형성하고, 운영하고, 영향을 미치는 방식에 대한 근본적인 변화이다.

Dao란?

Decentralized Autonomus Organizations

탈중앙화된 자율 조직

Smart Contracts를 기반으로 토큰 소유자들이 분산화된 의결권을 가지고 참여하는 형태

Web3 Community의 기본사항

- 참여와 투명성의 기반 구축

- 단순한 금전적 이상의 보상(인센티브)

- 교육과 비전 공유를 통한 역량 강화

- 더 깊은 참여를 위한 디지털 플랫폼 활용

Web3 Community의 과제

- 여전히 높은 진입장벽과 온보딩 피로도 축적

- 거버넌스의 중앙화적 퇴행 현상

- 다양한 기술적 한계와 제한된 유동성, 매크로 경제 상황의 변수

Q. NFT를 거래하거나 사용하는 플랫폼은 어떤 걸 중요하게 생각해야할지, 방향성을 어떻게 잡아야 할지에 대한 박민님의 생각이 궁금합니다.

      "NFT 시장은 소유권, 멤버십을 중요시한다. 멤버십이 어떻게 하면 극대화될 수 있을까? 에 대하여 고민하는 것이 중요하다."

우린 왜 디센트 지갑이 있는데도 위핀 지갑을 새로 만들었을까? - 유민호 님

-  콜드월렛 만들면서 WaaS 만든 이야기

블록체인 기술을 서비스에 접목하려는 팀들에게는 공통의 니즈가 있었다.

"서비스 내부에 지갑을 내장시키고싶다." 

기존 많은 지갑들은 모바일 앱이나 익스텐션 기반이었다. -> 설치가 필요했다. 

직접 서비스를 위한 지갑을 구축하는 것도 좋지만 이에 필요한 기술이나 정보가 많이 필요하기에 배보다 배꼽이 더 커질 수 있다.

-> 그래서 SaaS 형태의 솔루션, WaaS를 제공한다.

기존에 운영했던 디센트 지갑은 개인들을 위한 지갑에 중점을 뒀다면 새로운 위핀 지갑은 블록체인을 서비스에 활용하려는 기업들을 위한 지갑이다.

위핀이 제공하는 것 : 소셜 기능, 위젯 커스터마이징, 표준 인터페이스, 위젯 연동 방식 or API 연동 방식 둘 다 제공, 토큰 정보 제공 및 마케팅 도구 제공

// SPDX-License-Identifier: MIT
// Compatible with OpenZeppelin Contracts ^5.0.0
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Pausable.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol";

contract testToken is ERC721, ERC721Enumerable, ERC721URIStorage, ERC721Pausable, Ownable, ERC721Burnable {
    uint256 private _nextTokenId;
    mapping(string => uint256) public _mintedCounts;

    constructor(address initialOwner)
        ERC721("TEST TOKEN", "TTK")
        Ownable(initialOwner)
    {}

    function pause() public onlyOwner {
        _pause();
    }

    function unpause() public onlyOwner {
        _unpause();
    }

    function setMintedCount(string calldata mintType, uint256 count) public onlyOwner {
        _mintedCounts[mintType] = count;
    }

    function safeMint(address to, string memory uri) public onlyOwner {
        uint256 tokenId = _nextTokenId++;
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
        _mintedCounts[uri]++;
    }

    // The following functions are overrides required by Solidity.

    function _update(address to, uint256 tokenId, address auth)
        internal
        override(ERC721, ERC721Enumerable, ERC721Pausable)
        returns (address)
    {
        return super._update(to, tokenId, auth);
    }

    function _increaseBalance(address account, uint128 value)
        internal
        override(ERC721, ERC721Enumerable)
    {
        super._increaseBalance(account, value);
    }

    function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC721Enumerable, ERC721URIStorage)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

위 코드는 NFT 컬렉션내에서 Minting을 계속 하는 코드가 아니라 정해져있는 카테고리(3개의 메타데이터를 가지고 여러개씩 발행)의 같은 NFT들을 여러명에게 발행해주기 위해 만든 코드입니다. 그래서 baseURI가 아니라 setTokenURI방식을 택하여 Minting을 구현하였습니다. 

Remix로 NFT 컨트랙트 배포 및 Minting 하기

NFT를 폴리곤 네트워크상에서 사용자에게 민팅해주는 프로젝트를 진행하게 됐는데 실제 네트워크에 배포 및 실행하기 전 테스트넷(Sepolia)에서 테스팅을 한번 해보려 합니다.

저는 제 MetaMask지갑으로 연결하여 Sepolia테스트넷에 접근하는 방식을 선택했습니다.

먼저 배포하고자 하는 코드가 담겨있는 Solidity파일을 추가합니다.

그다음 제가 올려놓은 Solidity파일 컴파일합니다.

제가 올려놓은 코드는 배포 시 Owner 주소가 필요합니다.

MetaMask계정으로 컨펌하여 가스비를 지불하고 컨트랙트를 배포합니다.

배포 성공 후 위와 같이 로그가 뜨고 Deployed Contrancts에서 배포한 컨트랙트를 실행할 수 있습니다.

그다음 safeMint로 원하는 주소에 NFT를 Minting 해주었습니다

Owner계정으로 컨펌 후 Etherscan을 통해 확인합니다.

메타마스크 NFT 화면 하단에서 NFT 가져오기 클릭 후 NFT ID와 Contract주소를 입력해 주면 Minting 받은 계정에서 NFT를 확인할 수 있습니다.

Error

Vercel에서 Front를 배포하던 중 다음과 같이 Error 코드가 났다.

Couldn't find any versions for "@solana/fast-stable-stringify" that matches "workspace:*"

Error가 발생하는 시점을 확인해보니 Vercel에서 앱을 Build할시에 발생하는 Error였다.
먼저 로컬 환경에서 Build시에는 Error가 나지 않았고 Vercel 공식 문서를 찾아보았는데 처음에는 Vercel에서 지원하는 Yarn의 Version문제인 듯하여서 로컬환경의 Yarn을 Downgrade를 시키고 작업을 해야 하나 하던 찰나 Vercel공식문서에서 해결법을 찾았다.

https://vercel.com/guides/deploying-yarn-monorepos-to-vercel#connect-all-the-pieces-with-yarn-workspaces

Connect all the pieces with Yarn workspaces

"workspaces": [
  "apps/*",
  "packages/*"
]

위 코드를 package.json에 추가해주고 다시 푸시해 주었더니 해결되었다.

위 코드를 추가해야 Yarn 의 workspaces 를 Vercel에서 배포하는 환경에서도 적용 가능한듯 하였다.

ERROR

Failure while executing; `/bin/launchctl bootstrap gui/501 /Users/j/Library/LaunchAgents/homebrew.mxcl.mariadb.plist` exited with 5.

 MariaDB를 설치하고 실행 하는데 위와 같은 오류가 났다.

이전에 시도 했던 방법들은 아래와 같다.

• MariaDB Restart 하기 -> Restart 하면 잠깐 MariaDB가 started상태로 들어가고 이후에 바로 stopped상태로 자동 변경 되었다.
• 기존에 깔려 있던 MySQL과의 충돌이 문제라 생각하여 관련 MySQL관련 폴더 삭제 후 MariaDB 재설치하기
  https://bsscl.tistory.com/128
  

위 방법들을 시도해도 같은 에러가 떴고 결국 Homebrew를 통째로 삭제 후 다시 설치하기로 결정했다. 기존 DB에 중요한 정보는 없어 따로 백업을 하진 않았다.

Solve

Homebrew  삭제

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall.sh)"

Homebrew  관련 폴더 삭제

sudo rm -rf /opt/homebrew

Homebrew 설치

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

MariaDB 설치

brew install mariadb

설치 후 초기 root 계정 password 설정

sudo mysql -u root 를 통해 접속.
-> USE mysql
-> SELECT User, Host, plugin FROM mysql.user;
->ALTER user 'root'@'localhost' identified by '설정할 비밀번호';

새로 입사하게 된 회사에서 다른 DB들과 함께 MariaDB를 사용한다. MariaDB를 처음 사용 해보고 접해보는 입장에서 MySQL과 크게 다르지 않아보이는 MariaDB를 왜 사용하는지, 무슨 장점이 있는지, 앞으로 어떻게 써나가야 하는지에 대해 공부하고 싶어 블로그에 글을 남긴다.

MariaDB란 무엇인가?

MariaDB는 오픈 소스 관계형 데이터베이스(RDBMS)로 MySQL에서 분기된(Fork) 프로젝트이다. 인기 RDBMS였던 MySQL의 여러 포크 버전들 중 하나인 것.

MariaDB를 사용하는 이유

• 호환성
  
  • MariaDB는 MySQL과 완벽 호환 및 기존 MySQL을 사용하던 프로젝트들을 쉽게 이전 가능하다.
• 성능
  • 상황에 따라 MySQL보다 더 빠른 성능을 제공한다. 일부 쿼리 및 작업에 최적화가 되어있다. (이게 우리 회사에서 사용하는 가장 큰 이유일듯 하다.)
• 보안
  • 데이터베이스 암호와, SSL 지원 등을 통해 보안을 강화할 수 있다.
• 활발한 커뮤니티, 오픈 소스 프로젝트로 인한 많은 개발자들의 참여(많은 정보들로 인한 개발의 편리함), 관리 툴등의 장점은 MySQL과 동일하다.