without haste but without rest

요약 Minikube는 로컬 환경에서 쿠버네티스를 실행할 수 있게 해준다. 기능이 제한적이지만, 쿠버네티스를 경험하는 것에 의의를 둔다. 설치 https://minikube.sigs.k8s.io/docs/start/ minikube start minikube is local Kubernetes minikube.sigs.k8s.io 튜토리얼 https://kubernetes.io/ko/docs/tutorials/hello-minikube/ Hello Minikube 이 튜토리얼에서는 Minikube와 Katacoda를 이용하여 쿠버네티스에서 샘플 애플리케이션을 어떻게 실행하는지 살펴본다. Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 참고: 로컬에서 kubernetes.io 자잘한 팁 ..

빅데이터를 지탱하는 기술, 니시다 케이스케 데이터 중복과 멱등한 조작 빅데이터를 다루는 시스템에서는 어느정도 중복을 허용하는 경향이 존재한다. 데이터 센터와 같은 안정된 회선의 경우 99% 이상의 신뢰성을 확보할 가능성이 높다. 따라서 이 정도의 오차는 허용하고, 멱등한 조작에 유의해서 중복 데이터가 생기더라도 문제가 되지 않는 시스템을 설계한다. (다만 과금 처리 같이 오차가 허용되어서는 안되는 경우는 트랜잭션 처리를 지원하는 데이터베이스를 사용하고, 이후에 벌크로 데이터를 전송해서 중복과 결손을 확실하게 피한다.) Exactly-once 의 단점 데이터 전송을 주고 받는 두 노드가 분산 코디네이터에 의존한다. 그러나 코디네이터에 장애가 발생하는 경우도 있으며, 이에 의존하기 때문에 성능과 트레이드하게..

빅데이터를 지탱하는 기술, 니시다 케이스케 Workflow Management 데이터 관리를 자동화하고 안정된 배치 처리를 실행하기 위해 워크 플로우 툴을 사용한다. 워크 플로우 툴은 정기적으로 태스크를 실행하고 비정상적인 상태를 감지하여 해결을 돕는 것이 목적이다. 워크로드 오류로부터 복구하는 방법 2가지 재시도 - 단순한 재실행 백필(backfill) - 일정 기간의 플로우를 연속해서 실행하는 구조 백필은 주어진 날짜 파라미터를 기준으로 일정 기간의 플로우를 다시 실행한다. 오류로 인해 태스크를 재실행 해야하거나 혹은 새롭게 만든 워크플로를 과거로 거슬러 올라가 실행해야할 때 사용한다. 만약 태스크가 업데이트가 되어서 한 달 전 데이터 부터 오늘 만든 새로운 태스크를 적용해야 한다고 가정해보자. 이전..

MySQL 컨테이너에 영구 볼륨을 요청해서 배포하는 yaml 파일 템플릿 # PVC apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-claim spec: accessModes: - ReadWriteOnce storageClassName: standard resources: requests: storage: 10Gi --- #Service apiVersion: v1 kind: Service metadata: name: mysql-service spec: type: NodePort selector: app: mysql ports: - name: mysql protocol: TCP port: 3306 --- # Deployment apiVer..

아파치 카프카 애플리케이션 프로그래밍 with 자바 Kafka Connect 카프카에 기본적으로 포함되어 있는 애플리케이션이다. 프로듀서, 컨슈머 애플리케이션을 직접 개발할 필요없이 템플릿 기반으로 사용할 수 있다. source, sink에 대한 플러그인은 confluent hub에서 검색해서 찾을 수 있다. 1. 아키텍처에 대한 간단한 요약 유저가 커넥트에 커넥터 생성을 요청하면 커넥트는 내부에 커넥터와 태스크를 생성한다. 커넥터는 태스크를 관리하고, 태스크는 커넥터에 종속되는 개념으로, 데이터를 처리를 담당 한다. 유저는 Converter와 Transform 기능을 옵션으로 추가할 수 있다. 컨버터는 데이터 처리를 하기 전에 스키마를 변경하도록 돕는다. JsonConverter, StringConve..

아파치 카프카 애플리케이션 프로그래밍 with 자바 MirrorMaker2 서로 다른 두 개의 카프카 클러스터 간 토픽을 복제하는 애플리케이션이다. (카프카 binary 디렉토리 내에 mirrormaker를 확인할 수 있다.) 프로듀서, 컨슈머 단에서 미러링을 구현할 수도 있지만, 파티셔닝 정보가 변경되는 등의 로직을 직접 구현하는 것이 쉽지 않다. 미러메이커2는 토픽의 데이터를 복제하고 설정까지도 복제해서 파티션의 변화, 토픽 설정값의 변화도 동기화하는 기능을 제공한다. + 미러메이커1은 복제하기 전 데이터와 복제된 데이터의 파티션 정보가 달랐으며 복제하는 토픽이 달라지면 수정하기 위해 애플리케이션을 재시작해야 했다. 또한 exactly-once 를 보장하지 못했다.

중단 배포 서비스를 완전히 내린 뒤 신규 버전으로 다시 올리는 방법 무중단 배포 블루/그린: 이전 버전과 신규 버전을 동시에 띄워두고 트래픽을 전환하는 방법 롤링: 파티션을 하나씩 바꿔가는 방법으로 규모가 크면 리밸런스에 시간이 오래 소요된다. 카나리: 파티션 개수가 많을 때 소수의 파티션만 먼저 수행한 뒤 나머지 파티션은 블루/그린 or 롤링 방법으로 배포한다. 100개의 파티션이 존재하면 1개의 파티션을 테스트하고 문제가 없으면 나머지를 배포한다.

Message Key 카프카 브로커에 메세지를 전송할 때 Topic, Key, Value 값을 보내게 된다. 이때 토픽과 밸류는 직관적이지만 키가 굳이 필요한 이유에 관해서 궁금했다. 왜 쓰는 걸까? Key는 메시지의 종류를 나타날 때 사용하고, 데이터의 처리 순서와 밀접한 관련이 있다. 동일한 키를 동일한 파티션으로 보내는 것이 주요한 목적이다. 간단한 예시로, 토픽의 파티션 개수가 2개 이상이 되는 순간 오프셋의 순서를 보장할 수가 없다. 따라서 트랜잭션 데이터의 순서가 뒤바뀔 수 있는 위험이 존재한다. 이때 레코드의 Primary와 같은 고유값을 키로 이용한다면 동일한 파티션으로만 전송하게 되므로 특정 파티션의 바틀넥 현상에 의해서 순서가 역전되는 문제를 회피할 수 있다. 예를 들어서 uuid가 0..