Blockchain & Devops, bitetiger

Golang x Blockchain 블록체인의 구조에 대해서 이해하더라도, 직접 코드로 구현해보는 것만큼 좋은게 없다. 이더리움도 Go로 개발할 정도로, Go는 빠른 처리속도를 자랑하기 때문에 다양한 블록체인 프로젝트에 Golang이 많이 사용된다. 간단한 구조로 구현해보고 개념도 학습해보자. Block 블록은 블록체인의 가치있는 정보를 저장하는 매개체다. 비트코인의 경우엔 트랜잭션같은 거래내역들이 저장된다. 외에도 version, timestamp, hash 들이 저장되어 개별 블록이 구분되고 연결될 수 있다. 블록의 기본적인 구성은 아래와 같다. type Block struct { Timestamp int64 Data []byte PrevBlockHash []byte Hash []byte } Time..

Geth(Go Ethereum)은 Go로 개발된 Ethereum client다. JSON-RPC를 이용해서 이더리움 콘솔에 접속할 수 있는 환경을 제공한다. + JSON-RPC? JSON으로 인코딩된 원격 프로시저 호출이다. 매우 간단한 프로토콜로, 소량의 데이터 타입과 명령어들만으로 정의한다. JSON-RPC는 알림을 허용하고, 다수의 호출이 서버로 전송되고 순서없이 응답한다. 참고 자료 : https://www.getoutsidedoor.com/2019/08/10/%EC%99%9C-json-rpc%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%A0%EA%B9%8C/ 기본적으로 Geth를 이용해서 Ethereum wallet 정보와, state를 확인할 수 있다. Geth 설치방법 $ s..

컨슈머의 주요 역할은 카프카에 저장된 메시지를 당겨오는 것이다. 메시지를 당기는데 중요한 요소인 오프셋과 그룹 코디네이터, 파티션 할당 전략을 간단히 정리해보려고 한다. 1) 오프셋 (Offset) 오프셋 관리는 컨슈머의 동작 중에 핵심이라고 볼 수 있다. 컨슈머는 카프카에 저장된 메시지를 꺼내기 때문에 컨슈머가 메시지를 어디까지 가져왔는지를 표시하고 확인하는 것은 중요하다. 여기서 메시지의 위치를 나타내는 것을 오프셋이라고 한다. 이 오프셋은 숫자 형태로 저장된다. 컨슈머 그룹은 오프셋 정보를 카프카의 토픽에 저장한다. (__consumer_offsets 토픽에 각 컨슈머 그룹 별 오프셋 위치 정보가 기록됨) 2) 그룹 코디네이터(Group Cordinator) 컨슈머 그룹에서 컨슈머들은 속한 컨슈머 ..

Producer 카프카의 토픽은 병렬처리가 가능하기 위해서 파티션으로 나뉘어, 최소 하나 이상의 파티션으로 구성된다. 그리고 프로듀서가 카프카로 전송한 메시지는 토픽 내 각 파티션의 로그 세그먼트에 저장된다. 그래서, 프로듀서는 토픽으로 보낼 때 토픽의 어느 파티션으로 메시지를 보내야할 지 결정해야하고 이 때 사용하는 것이 '파티셔너(Partitioner)'다. 그래서 파티션의 증가에 따라 관리자의 의도와 다르게 메시지 전송이 이뤄질 수 있기 때문에 되도록 파티션 수를 변경하지 않는 것이 좋다. 파티셔닝 방법 2가지 레코드들은 배치 처리를 위해서 프로듀서의 버퍼 메모리 영역에서 잠시 대기한 후에 카프카로 전송된다. 이 때 크게 두가지전략을 고려할 수 있다. 1) 라운드 로빈 전략 키 값을 지정하지 않은 ..

Producer와 Consumer는 Python으로 테스트, Broker와 Zookeeper는 Docker로 올려본다. 서버를 EC2로 올리는 건 비용이 들기 때문에 간단한 테스트용으로 추천한다. (Confluent-Kafka는 개발이 활발하고 다른 버전들보다 여러면에서 스펙이 가장 뛰어나기 때문에 Confluent버전을 사용함) 1) Confluent-kafka 설치 $ pip install confluent-kafka (consumer와 producer 어플리케이션을 위해) 2) Broker와 Zookeeper docker-compose로 올리기 # docker-compose.yml --- version: '3' services: zookeeper: image: confluentinc/cp-zooke..

여러 곳을 찾아봐도 깔끔하게 개념을 이해할 수 있는 정리된 자료가 없어서 직접 정리해보려고 한다. kafka는 높은 처리량과 가용성, 확장성을 지니고 있지만, 의외로 구조는 간단하기 때문에 쉽게 이해할 수 있으리라 생각함. 카프카를 구성하는 주요 요소들 1) 주키퍼(Zookeeper) 카프카의 메타데이터를 관리하고 브로커의 health check를 담당하는 역할을 한다. 주키퍼는 여러 대의 서버를 클러스터로 구성한다. 그래서 살아 있는 노드가 과반수 이상이면 유지될 수 있다. 그래서 홀수로 구성되어야 한다. Znode를 통해서 카프카의 메타정보가 주키퍼에 기록된다. 주키퍼는 지노드를 이용하여 브로커의 노드 관리부터, 토픽과 컨트롤러를 모두 관리할 수 있다. 2) 카프카(Kafka) 카프카 클러스터(Clu..

export GOROOT=/usr/local/go export GOPATH=$HOME/go export GOBIN=$GOPATH/bin export PATH=$GOROOT/bin:$GOBIN:$PATH GOROOT GOROOT는 go sdk를 설치한 디렉토리다. golang의 명령어, Package, Library 등이 있는 Directory다 GOPATH GOPATH는 GO 프로젝트의 import 위치를 정해준다. Go 소스코드와 외부 패키지, 모듈을 저장하는 Home Directory다. GOBIN go install을 사용해서 컴파일된 golang binary가 복사되는 Directory다. 위와 같은 오류는 GOROOT와 GOPATH의 설정이 잘못되었기 때문에 발생하는 에러다. 위의 GOROOT,..

the ecs service cannot be updated due to an unexpected error: TaskDefinition is inactive CodeDeploy로 ECS Blue-Green Service를 생성해서 테스트하는 와중에 발견한 에러다. Codebuild에서부터 Deploy까지 taskdef.json 파일도 Copy했는데 TaskDefinition이 비활성화되었다는 에러가 뜬다. taskdef.json 파일이 없는게 아니라, 설정에 문제가 발생했다는 의미다. 그래서 ECS Cluster를 통해서 Task를 실행하면 문제가 없지만, Codedeploy 혹은 Codepipeline을 통해서 서비스가 작동하면 문제가 발생한다. (taskdefinition 관련 설정이 실행되기 때문..

Dockerfile을 이용해서 이미지를 빌드하다 보면 최종 컨테이너 이미지에 필요 없는 환경과 파일이 포함될 수 있다. 이를 해결하기 위해서 빌드와 실행을 구분해 이미지를 빌드할 수 있는 'Multi-stage build' 기능을 이용하면 된다. 위처럼 빌드를 통해서 text 파일이 생성되면, 이 파일만 이용해서 내용을 추가하고 최종 스테이지에선 필요한 파일만 사용할 수 있게 된다. # syntax=docker/dockerfile:1 FROM golang:1.16 AS builder WORKDIR /go/src/github.com/alexellis/href-counter/ RUN go get -d -v golang.org/x/net/html COPY app.go ./ RUN CGO_ENABLED=0 go..