일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 코인
- 이더리움
- datacap
- 코로나
- 스토리지코인
- nft민팅
- Q-code
- nft
- 채산성
- 비트코인
- 스토리지
- 파일코인
- filfox
- 암호화폐
- FILECOIN
- 투자
- 채굴
- 알위브
- Mining
- Arweave
- 공증인
- 데이터캡
- 민팅
- 파일코인플러스
- 가상자산
- 바이낸스
- FIL
- BTC
- 레이어2
- MATIC
- Today
- 96
- Total
- 125,460
목록전체 글 (259)
Blockchain & Devops, bitetiger

쿠버네티스의 오브젝트는 컨테이너 워크로드를 처리하는데 사용되는 1) 워크로드용 객체, 네트워크 및 보안을 처리하는 2) 인프라 객체와 구분할 수 있다. 오브젝트 생성을 위해서는 YAML을 활용하고, API 서버를 통해서 요청된다. 그리고 생성전에 유효성 검증이 진행된다. Workload 1) Pod 파드는 작업의 기본 단위면서, k8s에서 생성하고 관리할 수 있는 가장 작은 단위의 유닛이다. 파드는 하나 이상의 컨테이너들의 그룹이며, 모두 스토리지와 네트워크 리소스를 공유한다. 굳이 비유를 하자면 '하나 혹은 여러 컨테이너들을 감싼 얇은 wrapper'다. 2) Deployment 디플로이먼트는 파드와 레플리카셋의 선언적인 설정을 제공한다. Deploy하여 레플리카셋보다 한 단계 높은 관리 오브젝트를 생..

쿠버네티스의 아키텍처는 크게 Control Plane, Node로 나뉜다. 아래 이미지를 보면 클러스터의 아키텍처를 쉽게 파악할 수 있다. Control Plane '마스터노드(Master Node)' 라고 불린다. Control Plane은 클러스터의 Work Node와 Pod를 관리한다. 프로덕션 환경에서, Control Plane은 일반적으로 여러 PC에서 실행되며 하나의 클러스터가 여러 노드들을 관리하여 고가용성과 내결함성을 제공한다. Control Plane CLI와 UI를 통해서 API 서버를 통해 Input 요청받는다. 또한, 마스터 노드에서는 사용자 workload를 사용하지 않는것이 좋다. Node '작업자 노드(Worker Node)'라고 불린다. 컨테이너화된 어플리케이션을 실행하는데 ..

윈도우에 mongodb를 설치하고 나서 실행할 때 아래와 같은 에러가 뜨게된다. 이 에러는 처음 설치할 때, 설정된 DB 디렉토리가 존재하지 않아서 발생하는 오류다. mongodb의 default DB 디렉토리 경로는 C:\data\db 기 때문에 C드라이브에 data/db 디렉토리를 생성하거나, 다시 설치해서 db 디렉토리 경로를 재설정하는 것이 좋다. 만약 Ubuntu일 경우, 아래 명령어로 디폴트 /data/db 생성 후 권한 설정 sudo mkdir -p /data/db sudo chown -R `id -un` /data/db + 윈도우 사용자라면 차라리 클라우드 상에서 만들거나, 도커 이미지를 활용하는 것이 간단함.

IBFT(이스탄불 비잔티움 결함 허용) 높은 보안과 투명성을 유지하면서, 공개를 통한 합의 신뢰모델을 채택하고 있다. 이는 합의 달성이 가능한 소수의 private 노드와 블록 생성 결과에 접근과 검증이 가능한 노드로 구성된다. 매 라운드마다 Proposer를 뽑고, 나머지 노드는 Validator가 되어 검증을 하게된다. x된 Validator3은 검증자로서 제대로 작동을 못하는 상태로 가정한다. (악의적인 공격도 포함) Proposer는 pre-prepare 단계에서 블록을 만들어서 다른 노드에 제안을 하게된다. prepare 단계에서 validator 1, 2은 자신을 제외한 다른 노드들에게 잘받았다는 메시지를 다시 보낸다. 단, Validator 3은 보내지 못한다. 마지막 commit 단계에서 ..

아래와 같이 외부에서 mysql 서버에 접속하려고 하면 connection refused 에러가 뜬다. 난 pymysql 모듈로 어플리케이션과 mysql을 연결하려는 작업을 하려는 중이었고, mysql은 aws 클라우드에 설치되어 있다. 간략히 크게 2가지 원인으로 볼 수 있다. 1. AWS 보안그룹의 인바운드 설정 EC2의 보안그룹에서 mysql의 기본 port인 3306 인바운드를 열어준다. 2. mysqld.cnf 외부 허용 설정 mysqld.cnf 파일에서 bind-address 를 수정하여 외부 접속을 허용한다. 먼저, 외부 접속이 허용되는지 확인하려면 sudo netstat -ntlp | grep mysqld 명령어를 사용하여 확인한다.(수정 전) mysql 5.7 버전 이상인 경우, /etc..

Kinesis는 데이터를 실시간으로 수집하고 ETL과 전송까지 담당하는 AWS의 서비스다. Data Stream을 실시간으로 수집하는 Kinesis Data Stream은 레코드를 직접 수집하는 것도 가능하지만, API Gateway가 프록시하는 것도 가능하다. 단순히 PutRecord하는 것 뿐만아니라, API Gateway에서 요청에따라 Stream 생성과 삭제, ListRecord도 가능하다. 콘솔 상에서 설정하는 방법과 Terraform에서 어떻게 설정하는지도 정리해보려고 한다. Kinesis 데이터 스트림의 API Gateway 프록시를 생성해보자 1) REST API 생성 2) streams 리소스 생성후, 하위 리소스로 다음과 같이 Stream-name 리소스 생성 3) PutRecord를 ..

선물 DEX가 크게 주목을 받으면서 GMX 거래소와 GMX 토큰도 많은 관심을 받고 있다. GMX는 오라클 가격 데이터를 활용하기 때문에 실제가격과 거래가격의 차이를 의미하는 슬리피지가 발생하지 않으며, 비영구적 손실(Impermanent Loss)에서도 자유롭다. 모든 선물 DEX의 거래량이 하락하는 와중에도 꾸준히 거래량은 유지 혹은 미세한 증가를 이루고 있으며, 거래 수수료도 동시에 증가하고 있다. 기존 중앙화 거래소의 선물 거래보다, 앞으론 탈중앙화되고 먹튀 염려없는 GMX 거래소의 선물 거래를 하는 것이 좋을 수 있다. GMX 선물 거래하는 방법 1) GMX 거래소 공식 링크이다. 접속하면 위와 같은 화면이 뜨고, 'trade' 버튼을 클릭한다. 2) 위 화면의 'Connect Wallet' 버..

https://exerror.com/importerror-cannot-import-name-docevents-from-botocore-docs-bcdoc/ [Solved] ImportError: cannot import name 'docevents' from 'botocore.docs.bcdoc' - Exception Error To Solve ImportError: cannot import name 'docevents' from 'botocore.docs.bcdoc' Error You need to reinstall awscli. First of all, update your exerror.com 위 링크의 해결책들을 수행하면됨. 주로 aws-cli와 pip를 업데이트 문제인 것으로 보임.

매번 거래소 사이트에 접속해서 시세를 알아보는게 여간 귀찮은게 아니다. 5G가 아니면 접속하는데 은근히 시간이 많이 소요된다. 그래서 빠르게 응답할 수 있는 텔레그램 봇을 이용해서 원하는 코인 시세만 확인할 수 있는 서버를 만들었다. AWS lambda를 활용할 수 있도록 terraform도 구성해봤다. 사용한 라이브러리 : axios, node-telegram-bot-api 시세 API : upbit //app.js require("dotenv").config(); const axios = require("axios").default; const TelegramBot = require("node-telegram-bot-api"); const token = process.env.TOKEN; // Crea..
모든 프로세스에 DB를 거치기 때문에 시스템을 고성능으로 유지하기 위해선 DB의 구조와 매커니즘 또한 아주 중요한 요소 중 하나다. 문제상황 : 너무 많은 읽기 연산 해결책 : 데이터베이스 다중화 Primary를 복제해서 Secondary와 Teriary로 분할한다. 다중화(레플리케이션)의 이점 더 나은 성능(읽기 성능은 부 DB의 갯수와 비례한다)과 CQRS(commit command 책임 분리) 안정성 가용성 주 DB에 문제가 생기면 부 DB가 주 DB로 승격된다. 문제상황 : 너무 많은 데이터(~1TB) 해결책 : 파티셔닝(샤딩) 주 특징은 샤딩된, 나눠진 파티션은 고유한 data만 있다. 그래서 해당 DB를 가지고 하나의 노드를 만들어서 부하분산이 가능해진다. 문제 상황 : 낮은 검색 성능 해결책..