취미가 좋다

kafka 카프카 쉬운 간단 정리

benlee73 — Thu, 21 Sep 2023 12:49:55 +0900

카프카

실시간으로 대용량 스트리밍 데이터를 처리하는 메시지 큐 플랫폼
풀어서 설명
- 데이터를 주고받는 굉장히 많은 어플리케이션과 DB 들이 있다.
- 이 많은 데이터 파이프라인을 관리하기란 어렵다.
- 파이프라인의 중간 통로로 카프카를 사용해서 데이터를 카프카에 넣고 데이터를 카프카로부터 꺼내가도록 한다.
- 높은 처리량, 확장성, 영속성, 고가용성의 장점을 통해 데이터 파이프라인을 안전하고 확장성 높게 운영할 수 있다.

브로커

데이터를 저장하고 관리하는 서버
주로 여러 서버를 묶어서 클러스터로 운영한다.

컨트롤러

클러스터 내 브로커 중 한 대가 수행
클러스터 내 브로커가 죽으면 그 브로커가 가진 리더 파티션을 재분배한다.

코디네이터

클러스터 내 브로커 중 한 대가 수행
컨슈머 그룹의 상태를 체크하고 파티션과 컨슈머를 매칭하는 리밸런싱을 수행한다.

토픽

데이터를 구분하는 단위
- RDB 의 테이블이라고 어렴풋이 생각하자

레코드

토픽에 들어가고 나오는 데이터 하나하나의 단위는 레코드라고 한다.

타임스탬프

메시지 키

메시지 값

오프셋

헤더

파티션

토픽의 레코드를 여러 브로커에 분포되어 저장되도록 한다.
카프카 병렬처리의 핵심이다.
적절한 파티션 개수
- 프로듀서 전송 데이터양 < 컨슈머 데이터 처리량 x 파티션 개수

토픽 삭제 정책

시간 or 용량을 기준으로 삭제
- 시간 : retention.ms 설정
- 용량 : retention.bytes 설정
세그먼트 단위로 토픽을 삭제
- 세그먼트 : 토픽 데이터를 저장하는 파일 시스템 단위
- 세그먼트의 이름은 가진 레코드의 오프셋 중 가장 작은 값 (ex. 04.log)

토픽 압축 정책

zip, snappy 의 압축과는 다르다.
같은 메시지 키를 가진 여러 레코드 중 최신 레코드만 남기고 삭제하는 정책

카프카 클러스터

클러스터에 4대의 broker 가 있다.
클러스터에 4개의 topic 이 있다.
각 토픽에는 2개의 partition 이 있다. 토픽의 레코드는 이 partition 에 나뉘어 저장된다.
partition 은 broker 에 분포되어 있다.
토픽의 replication 값에 따라 같은 레코드가 여러 partition 에 저장될 수도 있다.

프로듀서

프로듀서는 내부적으로 partitioner, accumulator 가 있다.
send() 를 호출하면 partiitioner가 어느 파티션으로 레코드를 전송할지 결정한다.
파티셔너로 구분된 레코드는 accumulator 에서 버퍼로 쌓이고 배치 단위로 브로커로 전송된다.

acks

얼마나 신뢰성 높게 저장할지 결정하는 옵션

acks	설명
0	프로듀서는 데이터가 잘 저장됐는지 확인하지 않는다.
1	프로듀서는 데이터가 '리더 파티션'에 저장됐는지 확인한다. 팔로워 파티션에 저장됐는지는 알 수 없다.
-1 (all)	프로듀서는 데이터가 '모든 파티션'에 저장됐는지 확인한다. (여기서 모든 파티션은 ISR 로 묶인 파티션들)

컨슈머

poll() 메서드 호출 시점에 카프카 클러스터에서 데이터를 가져오는 게 아니다.
컨슈머 어플리케이션이 실행되면 내부에서 fetcher 를 생성하고 미리 레코드를 내부 큐로 가져온다.
poll() 을 호출하면 내부 큐에서 레코드를 가져온다.
(이건 java 의 경우고 다른 언어의 라이브러리에서는 확인이 필요하다.)

리밸런싱

컨슈머 그룹에 컨슈머가 추가되거나 제거될 때 각 컨슈머에 파티션을 재분배하는 동작

커밋

컨슈머는 어떤 토픽을 어느 오프셋까지 읽었는지 기록한다.
로컬에도 기록하겠지만 브로커에도 기록해야 한다.
브로커에 어디까지 읽었다고 오프셋을 보내 기록하는 것을 커밋이라고 한다.
default 로 5초마다 커밋을 수행한다. (enable.auto.commit=true)
만약 커밋하기 전에 리밸런싱이 수행되거나 컨슈머 강제종료가 일어난다면 데이터가 재처리되거나 유실될 수 있다.
auto.commit 대신 동기/비동기로 직접 커밋을 수행할 수 있다.

버로우

컨슈머의 컨슈머 랙을 파악하는 방법은 여러 가지가 있지만 버로우를 사용해서 모니터링하는 것이 가장 좋다.
하나 이상의 카프카 클러스터에 버로우를 붙이면 REST API 로 컨슈머그룹, 토픽 별 컨슈머 랙을 쉽게 확인할 수 있다.
다만 데이터를 저장하는 기능은 없기 때문에 telegraf 로 저장소(ES, prometheus)에 저장하고 대시보드(그라파나, 키바나)로 보는 게 좋다.

기타

ISR (In-Sync-Replicas)
- ISR 로 리더 파티션과 팔로워 파티션을 묶으면 데이터를 동기화해서 일관성이 유지된다.
- 기본적으로 레코드마다 다른 파티션에 저장되지만 replication 을 사용할 경우 한 레코드가 여러 파티션에 저장된다.

카프카 스트림즈

토픽의 데이터를 실시간으로 변환하여 다른 토픽에 적재하는 라이브러리
- 스파크, 플링크로도 비슷한 동작 수행 가능
스트림즈 어플리케이션에는 1개 이상의 스레드가 있고 스레드는 1개 이상의 태스크(task)가 있다.
- 태스크는 사용하는 토픽의 파티션 개수만큼 생성된다.
- 토픽의 파티션과 task 를 늘려서 처리량을 높일 수 있다.

스트림즈에서는 토픽으로부터 가져온 데이터를 KStream, KTable, GlobalKTable 의 형태로 다르게 바라볼 수 있다.
카프카 스트림즈는 스트림즈DSL 과 프로세서 API 2가지 방법으로 구현할 수 있다.
- 스트림즈DSL 은 자주 사용될 기능들을 자체 API 로 만들어서 쉽게 개발할 수 있다.
- 프로세서 API 는 스트림즈DSL 이 제공하지 않는 기능들이 필요할 때 사용한다.

KStream	토픽에 있는 모든 레코드가 조회된다.
KTable	토픽에 있는 모든 레코드가 조회되고 메시지 키를 기준으로 최신 메시지 값으로 덮어 씌워진다.
GlobalKTable	KTable 과 동일하다. 다만 KTable 은 1개의 파티션이 1개의 task 에 할당되지만 이건 모든 파티션이 각 task에 할당된다.

코파티셔닝

조인을 하는 2개 데이터의 파티션 개수가 동일
파티셔닝 전략이 동일
GlobalKTable 이 아닌 이상 코파티셔닝이 되어야 두 토픽을 조인할 수 있다.

조인 예제

// 토폴로지 정의

StreamsBuilder builder = new StreamsBuilder();
KStream<String, String> stream1 = builder.stream(Topic1);
KStream<String, String> stream2 = builder.stream(Topic2);
KStream<String, String> stream3 = stream1.join(
    stream2,
    (val1, val2) -> val1 + " and " + val1
)
streams3.to(Topic3);

// config 정의

Properties configs = new Properties();
configs.put(APPLICATION_ID_CONFIG, APPLICATION_NAME);
...

// kafka streams 실행

KafkaStreams streams = new KafkaStreams(builder.build(), configs);
streams.start();

Topic1 과 Topic2 를 메시지 키 기준으로 조인하는 예제
조인된 레코드의 값을 and 로 이어서 Topic3 에 적재한다.
KStream-KStream 뿐 아니라 KStream-KTable, KStream-GloabalKTable 조인도 가능하다.

카프카 커넥트

커넥트는 카프카 클러스터와 연동되어 미리 정해놓은 동작을 수행하는 파이프라인들을 반복적으로 쉽게 생성할 수 있는 도구다.
커넥트는 하나의 프로세스고 여러 프로세스로 운영되는 분산 모드 커넥트가 주로 사용된다.
커넥트는 커넥터 생성, 조회, 수정, 삭제 등을 할 수 있는 REST API 를 제공한다.
파이프라인에는 소스 커넥터와 싱크 커넥터가 있다.
- 소스 커넥터 : 어플리케이션(DB) 으로부터 데이터를 가져와서 처리한 후 카프카 토픽에 저장
- 싱크 커넥터 : 카프카 토픽으로부터 데이터를 가져와서 처리한 후 어플리케이션(DB)에 저장

커넥터는 직접 구현할 수도 있고 공개된 오픈소스 커넥터를 가져와서 사용할 수도 있다.
jar 파일 형태로 제공되고 jar 파일이 있는 경로를 커넥트에게 알려주면 커넥트는 해당 커넥터 파이프라인을 생성할 수 있게 된다.

시나리오

카프카 커넥트(프로세스)를 실행한다.
REST API 를 통해 커넥트에 파이프라인 생성을 요청한다.
커넥트가 커넥터를 생성해서 파이프라인을 만든다.
지정한 task 개수만큼 커넥트에 새로운 task(스레드) 를 띄운다.
그 쓰레드들은 여러 커넥트(프로세스)에 띄워지게 된다.
파이프라인 용도에 맞게 데이터를 ETL 한다.

[git] 깃허브에 push 하기 전에 다른 커밋이 쌓였을 때

benlee73 — Sat, 4 Feb 2023 17:20:18 +0900

문제 상황

- 로컬 : C1 에서 작업해서 C3 커밋을 푸시하고 싶다.

- 원격 : C1 뒤에 누가 C2 커밋을 푸시했다.

- 따라서 현재 C3 가 push 되지 않는 상황

- 로컬로 C2 를 가져와서 merge/rebase 한 후 push 해야 한다.

rebase 후 push

// 1번 방법
git pull --rebase
git push

// 2번 방법
git fetch
git rebase o/main
git push

merge 후 push

// 1번 방법
git pull
git push

// 2번 방법
git fetch
git merge o/main
git push

git fetch / pull

benlee73 — Sat, 4 Feb 2023 17:03:36 +0900

git fetch

원격 저장소에는 있고 로컬 저장소에 없는 커밋을 다운로드 한다.
원격 브랜치들이 가리키는 곳들을 업데이트한다.

=> 즉, 원격 저장소의 상태를 로컬에 있는 원격 브랜치들에 반영한다.

=> 로컬 저장소의 상태(브랜치)를 변경하진 않는다.

git fetch

- 원격 저장소에서 데이터를 가져오는 명령어다.

- 왼쪽의 상태에서 오른쪽 상태가 된다.

- 커밋 C2, C3 를 로컬 저장소로 다운로드하고 o/main 브랜치를 업데이트한다.

git pull

git fetch 후 원격 브랜치와 로컬 브랜치들의 merge 까지 진행하는 명령

git fetch
git merge o/main

위 과정은 pull 명령어와 동일하다.

git pull

git 원격 저장소/브랜치

benlee73 — Sat, 4 Feb 2023 16:52:42 +0900

git 원격 저장소 / 브랜치

git 을 사용할 때는 github 와 같은 원격 저장소를 주로 사용한다.

장점 1 : 백업의 역할을 한다. 로컬에서 코드가 실수로 삭제되어도 원격 저장소에 저장되어있다.
장점 2 : 공동 작업, 공유의 역할을 한다. 여러 명이 동시에 프로젝트를 하거나 코드를 공유할 때 유용하다.

로컬에서 원격 브랜치는 <remote name>/<branch name> 으로 표현된다.

git 은 원격 저장소를 clone 해 오면 원격 저장소의 이름을 자동으로 origin 으로 설정한다.

특징

HEAD 는 origin 브랜치를 가리킬 수 없다.
git 원격 작업들은 두 저장소 간의 데이터를 주고 받는 행위다.

git tag (태그) 간단 설명

benlee73 — Sat, 4 Feb 2023 15:51:04 +0900

git tag

- 깃의 branch 는 유동적으로 커밋을 가리킨다.

- 중요한 커밋을 영구적으로 가리키기 위해서는 태그를 사용할 수 있다.

git tag v1 C1

- "v1" 이라는 이름의 태그를 C1 커밋에 붙였다.

- 커밋 이름을 지정하지 않으면 현재 HEAD 가 가리키는 커밋에 태그가 생성된다.

- 만약 생성한 v1 태그로 switch / checkout 을 하게 되면 HEAD 가 분리되어 커밋에 붙는다.

- 태그 자체에 HEAD 가 붙을 수는 없다.

https://learngitbranching.js.org/?locale=ko

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org

git cherry-pick(체리픽) 간단 설명

benlee73 — Sun, 29 Jan 2023 11:08:29 +0900

git cherry-pick

현재 브랜치에서 필요한 커밋들을 가져와서 뒤로 붙인다.

- 왼쪽 main 에서 c2, c4 커밋을 가져와서 붙이려고 한다.

- rebase 와 비슷한 방법으로 붙는다.

- 충돌이 날 수 있다.

git cherry-pick c2 c4

(main 에서 c4 를 체리픽 했을 때 충돌을 보면 c4 만의 변경 사항을 가져오는 것이 아니라 현재 브랜치와 c4 브랜치와 차이를 비교하는 것 같다.)

그러나 실제로 테스트를 해봤을 때는 충돌이 발생한다.
예를 들어 c2, c3, c4 가 아래와 같이 수정 변화를 가지고 있다고 하자.
(1) 충돌이 발생하는 경우 : c2, c3, c4 가 같은 곳을 수정했을 때

// c2
a

// c3
a
b

// c4
a
b
c

(2) 충돌이 발생하지 않는 경우 : c2, c3, c4 가 다른 곳을 수정했을 때

// c2
a
b
c

// c3
aaa
b
c

// c4
aaa
b
ccc

(1) 의 경우는 같은 부분을 수정했다. c4의 변경사항인 "c 문자 추가"를 체리픽으로 가져오지 못하고 충돌이 발생한다.
- 같은 줄을 변경했다고 인식하는 것 같다. (충돌은 수정한 부분의 위치가 같으면 발생한다.)
- c2 의 "아무것도 변경하지 않음"의 상태와 "b, c를 추가한 상태" 를 같은 줄을 변경했다고 해서 어느 쪽을 선택할 것인지에 대한 충돌로 보인다.
(2) 의 경우는 "aaa" 변화와 "ccc" 변화가 따로 저장되는지 "ccc" 변화를 체리픽으로 가져올 수 있다.
혹여나 문제가 발생하면 --abort 옵션(or --skip)으로 되돌리면 된다.
- git cherry-pick --abort

https://learngitbranching.js.org/?locale=ko

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org

git 되돌리기(reset, revert) 간단 설명

benlee73 — Sun, 29 Jan 2023 10:41:40 +0900

git reset

브랜치를 지정한 커밋으로 이동한다.

지정한 커밋은 부모쪽 커밋일수도 자식쪽 커밋일수도 있다.

옵션

- hard : 돌아가려는 커밋 이후의 모든 내용들이 사라진다.

- soft : 돌아가려는 커밋으로 돌아가고 이후의 모든 내용들이 stage 상태로 남아있다. (git add 된 상태) 커밋을 다시 할 수 있는 상태

- mixed : 돌아가려는 커밋으로 돌아가고 이후의 모든 내용들이 unstage 상태로 남아있다. (git add 이전 상태) (default)

(hard 옵션은 git branch -f main main~1 와 같은 것 같다.)

(hard 옵션은 변경사항 다 무시하고 해당 브랜치, 커밋으로 이동시킨다.)

git reset main~1
git reset main^

git reset HEAD~1
git reset HEAD^

git reset c1

- 돌아가고 싶은 커밋이나 브랜치를 입력한다.

- reset 은 git push 을 하기 전에 사용한다.

git revert

- git revert 는 입력한 버전의 이전 버전으로 되돌리는 명령어다.

- 입력한 버전에 적용된 변경사항만 적용되는 것을 주의해야 한다.

- 따라서 여러 커밋을 건너 뛰기 위해서는 git revert 를 여러번 해야한다.

git revert HEAD
git revert main

- 되돌리고 싶은 커밋을 입력한다.

- c2 를 입력하면 c2 에 저장된 c1 으로부터 변경 사항들을 되돌려서 c2' 커밋을 만드는 것

- c1 처럼 중간에 껴있는 커밋을 제거할 수 있다. (충돌이 날 수 있다.)

- 제거했다는 이력이 남는 것이 reset 과의 차이점이다.

https://learngitbranching.js.org/?locale=ko

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org

git HEAD 간단 설명

benlee73 — Tue, 24 Jan 2023 11:17:54 +0900

HEAD

현재 작업중인 커밋을 가리킨다.
커밋을 직접 가리킬 수도 있지만 일반적으로 커밋을 가리키는 브랜치를 가리킨다.

HEAD → main → c1

- HEAD 는 * 표시로 표현된다.

- 현재 HEAD 는 main 브랜치를 가리킨다.

- 현재 main 브랜치는 c1 커밋을 가리킨다.

git checkout c1
or
git switch c1

HEAD → c1

main → c1

- HEAD 가 브랜치가 아니라 커밋을 직접 가리키도록 분리됐다.

HEAD 이동

- HEAD 를 옮기기 위해서는 캐럿(^) 과 틸드(~) 를 사용한다.

- 이를 상대 참조 라고 한다.

- 커밋의 해시를 직접 작성하기엔 어렵기 때문에 많이 사용한다.

- switch 나 checkout 명령어를 사용하면 된다. (둘의 차이는 나중에 살펴보자.)

- 현재 HEAD 는 c3 커밋의 main 브랜치를 가리킨다.

- c0 커밋을 가리키도록 수정해보자.

git switch HEAD^^^
git switch main^^^
git switch HEAD~3
git switch main~3

브랜치 옮기기

- main 브랜치가 c1 을 가리키도록 만들어보자.

- branch -f 명령어를 사용한다. (강제로 옮긴다.)

- 상대 참조를 사용한다.

- (HEAD 가 가리키는 현재 브랜치가 아닌 브랜치만 강제 이동이 가능한 것 같다.)

git branch -f main HEAD^^^
git branch -f main main^^^
git branch -f main bugFix^^^

git branch -f main HEAD~3
git branch -f main main~3
git branch -f main bugFix~3

- switch 나 checkout 은 브랜치의 변화 없이 HEAD 만 변경하는 작업이다.

- HEAD 가 특정 커밋을 가리키게 하거나 특정 브랜치를 가리키도록 한다.

- 브랜치를 이동하고 싶으면 branch -f 명령어를 사용해야 한다.

https://learngitbranching.js.org/?locale=ko

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org

git rebase 간단 설명

benlee73 — Tue, 24 Jan 2023 11:08:28 +0900

git rebase

git merge 와 같이 두 커밋을 합치는 작업이다.

git rebase 는 커밋들을 한 줄로 깔끔하게 만들고 커밋의 순서를 만들어준다는 특징이 있다.

아래 예시를 보며 쉽게 이해해보자.

- 왼쪽처럼 c2, c3 커밋을 각각 가리키는 bugFix, main 브랜치가 있다고 하자.

- 현재 가리키고 있는 브랜치는 bugFix 이다.

- git rebase 명령어로 2개를 합쳐보자.

git rebase main

- main 과 bugFix 는 따로 작업했지만 순서대로 작업한 것처럼 보이게 된다.

- 기존에 있던 c3 커밋은 없어지지 않았지만 가리키는 브랜치가 없어서 흐릿해진 상황이다.

- 같은 방법으로 main 을 c3' 커밋으로 옮겨보자.

git switch main
git rebase bugFix

- main 이 bugFix 의 부모에 있는 상황에서는 rebase 했을 때 자식 커밋으로 이동하는 것이 전부다.

- merge 는 어느쪽으로 머지해도 결국 같은 커밋이 만들어졌다.

- 하지만 rebase 는 순서에 따라 만들어지는 브랜치가 다르다.

- 더 최근에 작업한 것처럼 보여지고 싶은 커밋이 있다면 그 커밋을 가리킨 상태에서 rebase 를 해야한다.

git rebase -i

- 왼쪽을 오른쪽으로 바꾸는 방법이다.

git rebase -i main

- "-i" 옵션이 없을 때는 Current branch b1 is up to date. 라고 나올 것이다.

- "-i" 옵션을 붙이면 b1 과 main 사이의 커밋들의 순서를 바꾸거나 커밋을 제거할 수 있다.

- 위 명령어의 의미는

-> 현재 브랜치(b1)를 지정한 브랜치(main) 뒤에 붙일 것이다.

-> 그러면 c2, c3, c4 를 붙여야 한다.

-> 이 커밋들을 그대로 붙일 수도 있지만 수정할 수 도 있다.

-> 제거하고 싶은 커밋은 제거하고 순서를 변경해서 붙인다.

-> 만약 c2, c3, c4 를 그대로 붙인다면 "-i" 옵션이 붙지 않았을 때와 동일하며 변경 사항 없이 현재 상태가 유지된다.

- 예시 하나만 더 보자.

git rebase -i main

-> b1 브랜치를 main 뒤에 붙이자.

-> 두 브랜치의 가장 가까운 공통 부모는 c1 이다.

-> c1 부터 b1 까지의 커밋 c2, c3, c4 를 main 뒤에 붙이자.

-> 제거하고 싶은 커밋 c3 를 제거한다.

-> c2, c4 의 순서를 바꿔서 붙이자.

https://learngitbranching.js.org/?locale=ko

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org

git merge 간단 설명

benlee73 — Tue, 24 Jan 2023 10:54:58 +0900

git merge

2개의 커밋을 부모로 갖는 새로운 커밋을 만드는 작업이다.

2개의 커밋을 합친다고 생각해도 된다.

- 왼쪽처럼 c2, c3 커밋을 각각 가리키는 bugFix, main 브랜치가 있다고 하자.

- 현재 가리키고 있는 브랜치는 main 이다.

- git merge 명령어로 2개를 합쳐보자.

git merge bugFix

- c2, c3 를 부모로 갖는 새로운 커밋 c4 가 생성됐다.

- 기존에 가리키고 있던 main 브랜치가 c4 를 가리키게 됐다.

- 같은 방법으로 git merge 로 bugFix 도 c4 를 가리키게 해보자.

git switch bugFix
git merge main

- 이를 통해 알 수 있는 것은 어디서 어디로 merge 하든 결국 같은 커밋이 만들어진다는 것이다.

https://learngitbranching.js.org/?locale=ko

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org